VivaLinux!

La historia reciente del proyecto de MySQL no estuvo libre de altibajos después de pasar por las administraciones de Sun Microsystems y hoy en día también Oracle. Pero siendo todavía la base de datos Open Source más popular de todas, y con forks apareciendo a diestra y siniestra, a muchos nos gustaría saber por dónde realmente está su desarrollo activo más pragmático.

Afortunadamente, por lo menos un administrador de base de datos en Yahoo! cree haber encontrado la respuesta y la comparte en su blog:

"Uno de mis roles en Yahoo! es proveer una infraestructura sólida como una roca para proyectos basados en MySQL".

"Después de alrededor de un año de intentar administrar la infraestructura, y siguiendo las sagas de MySQL, mi trabajo se está haciendo más fácil gracias a empresas como Facebook y Percona como también gracias a mi predecesor, por liberar código de calidad que extiende MySQL en tantas maneras que sólo performance".

"He sido capaz de tomar el mejor código de cada empresa y moldear una versión interna que satisface a toda la gente. MySQL/Oracle deberían hacer lo mismo".

El administrador hace referencia a los parches para MySQL que Facebook comenzó a liberar desde el 2009 y a Percona, que además de ofrecer soporte y consultoría para esa base de datos, también tiene un repositorio público con los paquetes de su propio fork de MySQL.

Cuando todavía era Director de Arquitectura en MySQL AB, Brian Aker develó Drizzle, una versión de "MySQL a dieta" especialmente diseñada para la Web 2.0 y la nube computacional. Pero a principios de este año, Aker se dejó de trabajar en Sun Microsystems, prometiendo que sin embargo continuaría desarrollando la nueva base de datos "forkeada" del código de MySQL 6.0.

Hoy sus novedades son mucho mejores: Aker está trabajando en Rackspace Cloud, el mismo proveedor de hosting que el año pasado se hizo cargo de la creciente demanda de tráfico e infraestructura de GitHub. Según otro desarrollador de Rackspace:

"Rackspace reconoce que los puntos dolorosos que sienten con el MySQL tradicional no pueden ser resueltos con hacks simples y atajos, y que para servir las necesidades de sus clientes necesitan un servidor de base de datos que piense en sí mismo como una pieza amigable de su infraestructura y no como el conductor de sus aplicaciones. Los principios fundamentales de Drizzle de flexibilidad y enfoque en la escalabilidad se alinean con los objetivos que Rackspace Cloud tiene para el futuro de su plataforma.

Rackspace también está muy comprometido con Cassandra, y vé la integración de Drizzle con Cassandra como una manera principal para agregar valor a sus plataformas y en consecuencia a sus clientes".

Así que de la mano de Rackspace, Drizzle parece tener un futuro mucho más promisorio del que tenía en MySQL AB, Sun y luego Oracle. Para comenzar, toda la administración del desarrollo del proyecto se mudó a Lauchpad para darle más transparencia y fomentar el crecimiento de su comunidad.

El domingo pasado en nuestro tradicional "Alrededor de la Red" publicamos un enlace a la notica de que Twitter se cambiaba de MySQL a una arquitectura de NoSQL basada en el proyecto de Cassandra.

Cassandra es un sistema de administración de base de datos distribuído diseñado para manejar enormes cantidades de información replicadas en varios servidores comunes y corrientes. Básicamente es una base con el modelo de datos del BigTable de Google ejecutando sobre una infraestructura similar a la de Dynamo usada por los servicios web de Amazon como S3.

Pero lo más importante es que, como una solución NoSQL, Cassandra rompe con la larga historia y teoría de las bases de datos relacionales por otro modelo con un almacenamiento híbrido del tipo "clave ⇒ valor", totalmente descentralizado y mucho más fácil de escalar que MySQL.

Por ese motivo es que ahora Digg quiere alejarse tanto como puedan de LAMP, comenzando por cambiar MySQL por Cassandra:

“Nuestra principal motivación para alejarnos de MySQL es la creciente dificultad de construir una aplicación de alta performance con escrituras intensivas en un conjunto de datos que crece rápidamente, sin un final a la vista.

A medida que nuestro sistema crece, es importante abarcar múltiples data centers para redundancia y performance de la red, para agregar capacidad o reemplazar sin downtimes nodos que hayan fallado. Planeamos continuar usando hardware común y continuar asumiendo que fallará regularmente. Todo esto es crecientemente difícil con MySQL”.

Cassandra fué desarrollado por Facebook, pero ahora es de código abierto amparado bajo la licencia de Apache. Digg también prometió comenzar a contribuir sus propias mejoras y modificaciones.

La semana pasada se llevó a cabo en Bruselas un evento hasta ahora único en su tipo: el equipo de MySQL se reunió con desarrolladores de las principales distribuciones de GNU/Linux (Mandriva, Ubuntu, Gentoo, OpenSUSE y Debian) para mejorar su comunicación y exponer sus diferencias y problemas a la hora incluir y empaquetar esa popular base de datos.

Básicamente el principal problema es que las distribuciones incluyen el software de MySQL con diferentes criterios y distintos grados de madurez, según sus propios planes y objetivos, pero generalmente muy diferente a lo que puede encontrarse en la página de descargas oficiales de MySQL. Esto frecuentemente resulta en que la versión de MySQL que llega a los usuarios está retrasada desde algunos meses, en el mejor de los casos, hasta varios años, en el peor. Pero también hay otros problemas:

• La lista de errores en MySQL es distinta para cada distribución, y éstos son corregidos independientemente por cada una. Los errores de seguridad, por ejemplo, son "invisibles" hasta que MySQL libera un parche, que no todas las distribuciones aplican.
• Los paquetes del MySQL Cluster distribuídos siempre están desactualizados, pero a partir de ahora todos acordaron incluir por lo menos la versión 7.x.
• El MySQL Workbench incluye código que no es GPL que debe ser eliminado antes de ser incluído en Debian y sus derivados.
• Las herramientas gráficas todavía son distribuídas, a pesar de que ya no son activamente desarrolladas.

Aunque la solución de estos problemas sin duda llevarán un tiempo, el hecho de que hayan sido oficialmente reconocidos e identificados es un enorme paso hacia adelante, que increíblemente nunca se había dado hasta ahora.

Finalmente Michael "Monty" Widenius anunció así el muy anticipado primer Release Candidate (RC) de su "fork" de MySQL: MariaDB 5.1.41 RC ya está disponible para descargarse y probarse, y además de sus fuentes también hay paquetes binarios para las arquitecturas i686 y x86-64, pero sólo para Linux.

MariaDB 5.1.41 RC es supuestamente compatible con MySQL 5.1, pero además incluye nuevas características y parches disponibles para esa versión de MySQL desde hace tiempo, por lo que se espera que, a pesar de su status de "RC", sea razonablemente estable.

Pero la principal novedad en MariaDB es su máquina de almacenamiento transaccional Maria, que reemplaza a la típica MyISAM de MySQL. También, en lugar de InnoDB (que ya había sido comprada por Oracle en el 2005) incluye la variante XtraDB que Monty espera que ofrezca la performance de InnoDB planeada para MySQL 5.4. Otras máquinas de almacenamiento incluyen también a PrimeBase XT (PBXT) y FederatedX, esta última basada en el discontinuado proyecto Federated de Sun.

Para el futuro, la próxima MariaDB 5.2 traerá parches adicionales que todavía no fueron integrados en la versión oficial de MySQL.

Sin duda queriendo capitalizar la incertidumbre alrededor del futuro de MySQL, Microsoft acaba de presentar una herramienta para ayudar a que los usuarios de MySQL migren sus datos a SQL Server. El nuevo SQL Server Migration Assistant for MySQL (SSMA) "dramáticamente reduce el esfuerzo, costo y riesgo de migrar desde MySQL a SQL Server 2003, 2008 y SQL Azure".

Al asistente, que está disponible como un Community Technology Preview (CTP), funcionaría con las versiones 4.1, 5.0 y 5.1 de MySQL, pero es de código cerrado y requiere una licencia (gratuita) de uso.

Como parte de su insistente campaña en contra de la fagocitación de MySQL por parte de Oracle después de la compra de Sun, el cada vez más pintoresco Michael "Monty" Widenius, creador original de la todavía popular base de datos, advierte en un provocador comentario a esta noticia que PostgreSQL también puede ser matado:

“Sí, PostgreSQL también puede ser matado. Para probarlo, piensen que pasaría si alguien se las arreglara para asegurarse que los 20 principales desarrolladores de PostgreSQL no pudieran desarrollarlo más, o si cada uno de ellos lo dividieran (fork) en su propio proyecto”.

Pero la comunidad de PostgreSQL no se quedó silenciosa, uno de sus partidarios salió a aclarar porqué la base de datos del elefante no es lo mismo que MySQL:

“El punto es ser capaz de realmente detener a esas 20 personas para que no trabajen en PostgreSQL. Hay básicamente 2 formas de hacer esto: Oracle podría comprar una compañía, o podría contratar (comprar) a una persona. El primer problema es que la comunidad de PostgreSQL está ampliamente distribuída. Si uno ve a la gente en la página de contribuyentes verá a 32 personas que trabajan para 24 compañías diferentes. Más aún, ninguna compañía tiene la mayoría: el promedio es sólo una persona por cada una, con la mayor aportando sólo 3 desarrolladores”.

Así queda claro que el modelo de desarrollo actual de PostgreSQL asegura que ninguna única entidad pueda desviarlo en el mismo destino que MySQL; sin embargo, eso sí podría suceder en otros proyectos donde una sola empresa ostente su control principal.

El Departamento de Justicia de Estados Unidos puede haber aprobado la compra de Sun por parte de Oracle, pero en el viejo continente la Comisión Europea todavía tiene abierta una investigación sobre la legalidad competitiva de esa operación que últimamente está alcanzando ribetes de culebrón.

Es que Michael "Monty" Widenius, el creador original de MySQL, publicó en su blog, bajo el título de "Ayuda a salvar a MySQL", un llamado público para iniciar una campaña de correos masivos dirigidos a la Comisión pidiéndole que garantice el futuro Open Source de la base de datos.

Luego, quizás apresurándose a los eventos, Oracle publicó un comunicado de prensa donde se compromete oficialmente a cosas como:

• Asegurar la disponibilidad de las APIs de las máquinas de almacenamiento.
• Continuar mejorando MySQL en el futuro bajo la GPL, incluyendo a su versión 6.
• Invertir más en el desarrollo de MySQL de lo que lo hizo Sun en el último año fiscal (U$S 24 Millones).
• No requerir que los clientes contraten los servicios de soporte de Oracle para obtener una licencia comercial de MySQL.
• Fundar un Consejo Asesor constituído por clientes y usuarios para que ayuden a dirigir las prioridades del desarrollo de MySQL.

¿Será eso suficiente para revertir los resultados de un reciente estudio que dice que los usuarios se inclinarán menos a usar MySQL después de la adquisición de Oracle?

MySQL 5.0 fué originalmente presentado hace más de cuatro años y, aunque todavía es el motor de base datos detrás de una buena parte de la web, su soporte activo llegará a su fin el próximo 31 de Diciembre, concluyendo en esa fecha su desarrollo efectivo y también la disponibilidad de sus paquetes binarios oficiales actualizados.

A partir del próximo 1 de Enero del 2010 MySQL 5.0 caerá efectivamente dentro del programa de "Soporte Extendido" de Sun Microsystems, y por los siguientes dos años, hasta el 31 de Diciembre del 2011, sólo errores serios y vulnerabilidades de seguridad serán corregidos pero sólo para clientes que hayan pagado por alguno de sus contratos de mantenimiento "Silver" (U$S 1.999 por año), "Gold" (U$S 2.999 por año) o "Platinum" (U$S 4.999 por año).

A todos los que no quieren o no pueden pagar por los contratos de mantenimiento anteriores, Sun recomienda actualizarse a la más reciente MySQL 5.1. Sin embargo, a esa versión, liberada a finales del mes de Noviembre del año pasado, le llegará el fin a medidados del próximo mes de Diciembre del 2010.

Nadie menos que Facebook anunció así que creó el proyecto MySQL at Facebook en Launchpad para publicar sus parches para MySQL. Los parches, que están liberados bajo una licencia BSD, están basados en el código de MySQL 5.0.84 e incluyen cambios para agregar contadores de performance en la máquina de almacenamiento transaccional InnoDB. El anuncio dice que su intención es hacer que InnoDB sea más rápida y este cambio hace que sea más fácil entender dónde consume más tiempo.

Parte del código inicial está derivado de parches liberados anteriormente por Google y estos no serán los últimos: Facebook promete publicar más.