Todo lo que deberías saber sobre Linux y MySQL y nunca te atreviste a preguntar

Yoshinori Matsunobu es Principal Infrastructure Architect en DeNA, habiendo sido previament MySQL Lead Consultant en MySQL/Oracle/Sun, aunque ahora he visto en su blog que es Oracle ACE Director. Hace unas semanas me topé con unas transparencias de un tutorial de 3 horas que dió en la MySQL Conference and Expo 2011, y que sin ninguna duda es la biblia de MySQL y Linux.

SSD vs. memoria RAM en MySQL

Interesante reflexión en el blog de Percona sobre si tener más memoria RAM tiene ya sentido cuando los discos SSD están cada vez más baratos.

En sus pruebas crearon un conjunto de datos de 230Gb. y empezaron a darle caña al MySQL
variando el tamaño del buffer de datos de memoria. Aquí están los resultados:

MySQL y los pools de Threads

Estaba repasando algunas entradas en la red sobre MySQL y me he encontrado sobre este artículo que habla del problema que tiene MySQL con la gestión de Threads y en particular con la plataforma Java.

Básicamente el problema es que MySQL se ejecuta como un único proceso. Este proceso crea un Thread para cada una de las conexiones que recibe. En MySQL lo implementaron de este modo porque parece que era realmente rápido. Pero entonces se encontraron con esas plataformas que, como Java, están llenas de pools de conexiones.

Para los que no estéis familiarizados con este concepto, la idea de un pool de conexiones consiste en reservar de antemano las conexiones a recursos externos como son las bases de datos. El conectarse a un recurso externo suele ser una tarea costosa en cuanto a tiempo, y por lo tanto el mantener una estructura de memoria donde se guarden conexiones abiertas que se puedan reutilizar cada vez que nuestro programa accede a ese recurso, parece una buena idea. Cualquier servidor de aplicaciones Java que utilicéis funciona de este modo, Tomcat, Glassfish, WebSphere, WebLogic, el que sea. En otros lenguajes como .NET o Rails también es algo típico.

Y ese es básicamente el problema. La persona que administra el servidor de aplicaciones puede decidir el crear un pool grande: "Voy a reservar 500 conexiones porque vamos a tener muchos usuarios concurrentes". Lo que hará el servidor de aplicaciones es abrir 500 conexiones y mantenerlas abiertas de por vida, aunque no se utilicen. Como consecuencia en MySQL se abren 500 threads, aunque no se utilicen.

Lo ideal sería que MySQL tuviese también un pool de conexiones, pero por ahora va a ser que no. Parece que MySQL 6.0 sí lo va a tener aunque están resolviendo algunos problemillas.

Por cierto si utilizáis MySQL, el blog de Percona tiene dos artículos bastante interesantes:

1 - MySQL utilizado como base de datos NoSQL en memoria SSD
2 - Percona como alternativa a Oracle tras el lio de los precios con InnoDB

Lo más visto en Pensamientos Ágiles en el 2009

Bueno, primeramente Feliz 2010, que ya tocaba decirlo. Y seguidamente continuo con mi tradicional lista para los más curiosos de lo más visto en el blog en el 2010:

• Notas sobre la arquitectura de facebook, una presentación con algunos detalles técnicos sobre la arquitectura de Facebook.


• Spring Roo, ¿Competencia para Grails?, con detalles sobre el anuncio de Spring Roo. Creo que este post seguramente haya sido popular más por llegadas sobre Grails que sobre Roo.


• Programadores españoles vs programadores europeos, mi visión sobre como nos vemos a nosotros mismos los programadores españoles y sobre como nos ven fuera de España.


• La historia de HOTorNOT, un resumen de la entrevista al fundador de HOTorNOT que hicieron en Mixergy.


• Como hacer un backup seguro de MySQL de la forma más simple, su nombre lo dice todo y Google lo ha puesto en el quinto puesto de este particular ranking :)

Este año la actividad de posteo ha decrecido considerablemente debido a Jobsket y parece que el 2010 tiene la misma pinta así que intentaré ser un poco más selectivo con las publicaciones. Muchísimas gracias a todos por las 37000 visitas que ha tenido este blog este 2009, casi nada. Casi tanto como los más de 800 subscriptores al RSS. Cifras increibles para este pequeño espacio y que son un reto para este año. ¡A ver si soy capaz de mejorarlas!

¡Feliz Año!

Domingo de escalabilidad

Cuanta información y que poco tiempo para poder empaparse de ella. Dos de los sitios que leo frecuentemente han dedicado sus últimos post a recopilar información sobre charlas de escalabilidad en tres eventos relacionados muy con el tema: Hadoop Summit 2008, Data-Intensive Computing Symposium 2008 y la MySQL Conference 2008.

Por una parte High-Scalability hace una excepcional recopilación de charlas y enlaces a información interesante presentada en la MySQL Conference. La lista es enorme: "Scaling MySQL and Java in High Write Throughput Environments", "scaling heavy concurrent writes in real time", "Exploring Amazon EC2 for Scale-out Applications", y mucho más. ¡Fenomenal recopilación!

Por otra parte, en el blog de Yahoo Developer Network anuncian la disponibilidad de las transparencias de la Hadoop Summit 2008 (y de bonus las del Data-Intensive Computing Symposium 2008 que también están por ahí). "Hadoop Overview" o "GrepTheWeb- Hadoop on AWS" entre otras que parecen interesantes. Lo mejor de estas transparencias es que los videos están disponibles.

Pues si alguien buscaba algo sobre escalabilidad para leer u ojear para la semana da la impresión de que alguna de estas presentaciones pueden ser una buena opción.

El nuevo motor de almacenamiento de MySQL se llama Maria

Vaya nombre ha escogido Michael Videnius para lo que es el nuevo y reluciente motor de almacenamiento MySQL. Según comenta en su blog, aunque el trabajo lo comenzaron hace un par de años, sólo ha sido en los últimos cuatro meses cuando se han puesto realmente serios con él.

Maria viene a sustituir al ya vetusto y siempre criticado MyISAM, pero no será parte estándar de las distribución hasta MySQL 6.0. La idea es la de proporcionar un motor rápido y compacto como MyISAM para modos no-transaccionales pero al mismo tiempo solucionar las carencias de éste como son la falta de transaccionalidad. Pero eso todavía será para Maria 2.0. Por ahora la versión que han lanzado es una alternativa a MyISAM pero con tolerancia a caidas del servidor.

Muchos bloggers se han hecho eco de esta noticia, aunque creo que no demasiados sitios web ya que sólo he visto la noticia en Artima. Kevin Burton comenta por ejemplo que al menos tenemos una opción más, aunque habrá que esperar hasta que podamos tirar a la basura MyISAM e InnoDB. Por su parte, Colin Charles y Giuseppe Maxia han han estado intentando romper Maria pero parece que realmente el motor sobrevive a fallos.

La verdad es que el motor promete bastante. A ver si con suerte, ahora que Sun Microsystems está detrás de la compañía quizás esto avance incluso más rápido.

Oracle compra BEA. SUN compra MySQL

Hay días en que parece que la gente se levanta juguetona; con ganas de dar noticias vamos. Y eso parece ser que es lo que han pensado a la vez SUN, BEA, Oracle y MySQL.

Por una parte tenemos que Sun Microsystems compra MySQL. Está claro que la compañía americana no pierde el tiempo y ya que este año pasado ha tenido beneficios todos sus trimestres, pues hay que gastárselo en algo. Que mejor que comprar MySQL. Un producto tan relacionado con su mercado.... ejem.

Bueno está claro que sus razones tendrán. En un inicio la compañía se especulaba que iba a salir a bolsa, así que supongo que es mejor comprarla ahora que cuando valga cuatro veces más cara. Pero, ¿se va a dedicar Sun ahora a vender bases de datos? ¿va a mejorar su integración con Solaris? Quien sabe. Desde luego si Sun tenía ya ventaja en la cantidad de Open Source que aportaba a la industria, ahora tiene mucha más. Será muy interesante ver como evoluciona el producto.

Y ya que comentaba lo de salir a bolsa. De enhorabuena están los accionistas de BEA con su 24.4% de premium. Oracle ha comprado BEA y ahora si que es de verdad. Parece que los directivos de BEA han sabido negociar y han conseguido un extra de 1.200 millones de dólares respecto a la oferta del año pasado.

La verdad es que en un único día desaparecen dos de las compañías más punteras en cuanto desarrollo de software y que mejor estaban funcionando para integrarse en dos enormes gigantes. La verdad es que Oracle es famoso por gafar todo lo que toca. Vamos que salvo la base de datos que no cabe duda de que es lo que realmente mueve la compañía, pues los otros productos que ha ido comprando han ido desvaneciéndose con el tiempo. Incluso... este año casi no se ha hablado de Coherence desde su compra.

Sería un buen tópico de discusión. ¿Ahogan los departamentos legales y de marketing a estas compañías?

Las claves en la arquitectura de base de datos de digg: memcached y sharding

Leo en ComputerWorld que el pasado Martes, Eliott White III estuvo hablando en la conferencia anual de MySQL. Ahí estuvo comentando algunos detalles interesantes sobre la arquitectura de digg que parece que ha llegado ya a los 1.2 millones de usuarios registrados. Me permito recapitular aquí algunos datos:

• 100 servidores desplegados sobre varios data center alojando 30 gb de datos.


• Un balanceador de carga que envia las consultas a servidores PHP. Servidores MySQL esclavos proveen de datos a los servidores PHP, mientras que uns ervidor MySQL maestro provee de datos a los servidores esclavos.


• Para evitar el sobrecargar la base de datos con consultas utiliza memcached. Memcached almacena porciones compactas de datos que se pueden utilizar para crear dinámicamente una página web. Esto lo diferencia de servidores de cache web tradicionales que almacenan la página completa. Otros sitios conocidos que utilizan memcached son Wikipedia, Sourceforge, Slashdot o Livejournal.


• Para hacer las consultas más eficientes hacen lo que se ha denominado recientemente como Sharding. Consiste en dividir una base de datos enorme en varias bases de datos más pequeñas de modo que el acceso sea mucho más eficiente. La base de datos se puede dividir por tablas, rangos, fechas, usuarios, etc. MMORPGs populares como EVE Online o World of WarCraft utilizan esta técnica para controlar las ingentes cantidades de datos que manejan.
  
  Los comentarios de White sobre Sharding son muy interesantes. Como bien dice, existen diferencias fundamentales entre particionar una base de datos y realizar sharding, siendo quizás la más importante que los shards suelen estar en máquinas diferentes, como sería por ejemplo el tener mundos diferentes en data centers diferentes en un MMORPG.
  
  White añade que el concepto de Sharding pone complejidad sobre el desarrollo ya que imposibilita el hacer operaciones habituales como joins sobre tablas.
  
  Aparentemente ingenieros de Google fueron los que acuñaron el término de Sharding. Este artículo en ZDNet muestra su uso dentro de su sección financiera. Hace poco Google contribuyó un proyecto de Shards en Hibernate.
  


• 20 servidores de bases de datos.


• 30 servidores web.


• Varios servidores de búsqueda ejecutando Lucene.


• Todos los servidores menos uno corren sobre MySQL 5. Los servidores con más carga transaccional así como las unidades de backup utilizan el motor InnoDB, mientras que los servidores OLAP utilizan MyISAM.


• Arquitectura inusual ya que el 98% de las operaciones son lecturas.

Interesante.