No obstante, la historia quiso que MySQL AB, la empresa que se creó para comercializar la idea de la base de datos rápida para webs, fuese finalmente adquirida por Sun Microsystems, para dar un supuesto impulso a su integración con el mundo de Java. A lo que respondió otro de los grandes del sector, finalmente, comprando a la propia Sun Microsystems.

En el momento en el que MySQL pasó a ser de Sun, comenzaron las tiranteces, de forma que, Monty, uno de los fundadores y responsable del desarrollo inicial de MySQL, que comentó que el nombre, precisamente, provenía de una de sus hijas (llamada My), hizo un fork, dándole el nombre de MariaDB (otra de sus hijas).

El caso es que, por ética profesional y propia, al final, he decidido abandonar definitivamente MySQL para usar única y exclusivamente MariaDB en lo que concierne a base de datos tipo MySQL… ya que, también hay otras como PostgreSQL que siguen siendo una muy buena opción a considerar, según el caso que se dé.

Migrando

Lo primero, veo que en la propia página de Monty dedicada a MariaDB, hay un configurador bastante bueno de elegir la distribución, la versión de MariaDB a instalar y el mirror más cercano. Con esto tenemos que la instalación en mi Debian Squeeze, por ejemplo, se basa en poner los repositorios correspondientes y hacer el apt-get install para mariadb-server-5.3 (por ejemplo).

Tanto si se instala de forma automática, como de forma manual, si tenemos corriendo un MySQL 5.1 (por ejemplo), el sistema se encarga de desinstalarlo, poner en su lugar MariaDB y ejecutar un script llamado mysql_upgrade (que en caso de la instalación desde apt-get install se realizará de forma automática).

El servidor se levanta de forma rápida y tenemos un MySQL completamente funcional con la base de datos instalada y funcionando. El corte casi que ni se nota.

No obstante, siempre es deseable tener una copia de seguridad por lo que pudiera pasar. Está el caso de éxito de SpamExperts que migraron cerca de 300 servidores en más o menos tres horas y sin complicaciones.

Las ramas de MariaDB

Actualmente hay disponibles tres ramas de MariaDB, la versión 5.1, la versión 5.2 y la versión 5.3.

• La versión 5.1 es una versión prácticamente igual que la versión 5.1 de MySQL, solo que con muchas correcciones de errores realizadas.
• La versión 5.2 es la siguiente evolución, que consta con muchas de las características que querrían haber introducido sus creadores en la versión anterior, pero no pudieron por falta de tiempo.
• La versión 5.3 es la actual, que integra muchas mejoras y cosas que en MySQL solo están en la versión comercial.

La versión 5.3, que es la última y la más avanzada, tiene cosas como:

• Optimizaciones en subconsultas, de siempre en SQL, el hecho de realizar subconsultas es algo que da un poco de miedo, porque, además de que puede ser lioso el hecho de construir una gran consulta con subconsultas dentro, tiene penalización en rendimiento. Pues bien, esta versión está optimizada para el uso de subconsultas de modo que, con respecto a MySQL (la versión normal) mejora el rendimiento sustancialmente.
• Interfaz NoSQL… bueno, realmente, sigue siendo SQL, pero permite redefinir y aumentar la base de datos de forma fácil en cada UPDATE e INSERT. Un ejemplo puede verse en esta página.
• Nuevos engines (realmente esto es de la 5.2), permite usar OQGRAPH, que es un engine preparado para el almacenamiento de elementos jerárquicos y grafos; y SphinxSE que integra un sistema de búsqueda de texto muy parecida al FTS de PostgreSQL enlazando con el servidor de Sphinx.
• Autenticación por plugins: permite tener autenticación vía PAM, LDAP, etc.

Conclusiones

MariaDB se mueve en un entorno ágil con mucha gente que lo mantiene desde su comunidad, y sobretodo, con el apoyo y liderazgo de quien comenzó en su día MySQL, por lo que, es más que posible que dentro de unos cuantos meses o años, se comience a escuchar hablar más de MariaDB que de MySQL. Además, migrar ahora es fácil, ya que las versiones 5.1 en ambos elementos son muy parecidos (son casi iguales), pero ya con la versión 5.5 de MySQL (han saltado de la 5.1 a la 5.5 directamente) y la 5.3 de MariaDB, cada vez se irán distanciando más.

Mi consejo: ¡actualiza ya!

El problema real vino cuando Sun Microsystems fue adquirida por Oracle. Esta adquisición puso a MySQL en la duda de si seguiría siendo lo que es, o pasaría a ser otro producto más recortado en su versión comunitaria y ofrecido por un precio medio/alto a empresas que se lo puedan permitir. Como si de una versión light de Oracle DB se tratase.

Entre todo este tumulto, en parte levantado por Monty, uno de los principales desarrolladores de MySQL, que se fue de la empresa cuando comenzó todo el lío, surgen varias versiones de MySQL, forks, que prometen seguir la línea original y seguir apostando por el crecimiento de este sistema dentro de la comunidad y el software libre.

Una de las apuestas es MariaDB, promovida por el propio Monty, es un fork del último código estable de MySQL, agregando todos los patchs que no se incluyeron en MySQL y dando soporte a problemas que parece que los desarrolladores principales de MySQL han olvidado.

En otro punto se sitúa el proyecto Drizzle, que intenta seguir los ideales iniciales de MySQL en un punto en los que muchos de los desarrolladores que pertenecían a esta comunidad, consideran que se torció el desarrollo principal.

Con esto podemos decir que el espíritu de MySQL no ha muerto, ni morirá, puesto que seguirá vivo en dos ramas separadas de su código original en los momentos clave en los que cada comunidad vió que era el momento de un cambio.

Como nota curiosa, el ecosistema de protección de los sistemas gestores de base de datos abiertas (Open Database Alliance), se encarga de la promoción entorno a los sistemas gestores de las base de datos. Una propuesta interesante que promete un poco de seguridad dentro de este entorno.

Los sistemas libres han hecho gala del uso de LAMP (Linux, Apache, MySQL y PHP) para el desarrollo rápido de webs. Estos sistemas son fáciles, rápidos y cómodos para usuarios nóveles, dan mucho control sobre el desarrollo y permiten, gracias a la cantidad de proyectos ya desarrollados, tener a disposición Foros, Bitácoras, CMS, ERP, CRM y muchos más tipos de webs.

La elección de estos elementos es algo que se suele dejar al administrador de la máquina. No solo hay que instalarlos, eso tan solo se hará una vez, sino que hay que mantenerlos, y eso se debe de hacer de una forma reiterada. Por lo que la elección del sistema operativo: Windows, Linux, BSD, Solaris…; es algo que debe de decidir quien lo vaya a administrar, al igual que el servidor propio web, ya que si se usa solo para servir páginas HTML y PHP, puede emplearse cualquier servidor web: Apache, Cherokee, Lighttpd, Caudium, Yaws, etc.

El empleo del lenguaje de programación viene determinado por lo que se vaya a emplear. Como es lógico, sino sé programar y quiero usar WordPress, es normal que instale PHP, ya que sino es completamente imposible. Pero si sé programar en Java, C#, Ruby, Python, Perl, o cualquier lenguaje de scripting actual, es muy posible hacerlo, con los módulos correspondientes o sistemas de CGI.

Entonces, después de esto, nos centramos en la base de datos. Elegir un SGBD es algo que no se debe de considerar trivial, puesto que de su elección derivarán los problemas o virtudes que podamos tener a la hora de administrar el sistema, hacer copias de seguridad, etc.

SQLite

Por ejemplo, para una web a la que solo tenemos acceso para escribir artículos nosotros, los comentarios son moderados y no hay mucho tráfico, se puede configurar, sin ningún tipo de problemas, para usar SQLite. Usar este sistema nos asegura mayor facilidad a la hora de realizar copias de seguridad y nos quita un punto único de fallo, puesto que sino hay conexión con la base de datos, no hay posibilidad de que falle.

Lo mejor de todo es la cantidad de integración de SQL que tiene el motor, ya que permite una integridad referencial bastante buena, procedimientos almacenados, triggers y otras bondades muy deseables en un SGBD.

Lo peor es que si el tráfico de nuestro sitio web sube, y/o la información a guardar comienza a subir demasiado, como todo se guarda en un único fichero, el sistema podría verse ralentizado.

MySQL

Para sistemas web de alto número de visitas, con gran cantidad de datos en modificación, inserción y consulta, se desarrollo este SGBD: MySQL.

MySQL destaca de la mayoría de SGBD en su velocidad cuando se emplean las tablas MyISAM, puesto que, para su aceleración, hace omisión de uso de muchas características típicas en SGBD, como es el caso de la integridad referencial, la cual solo está disponible si se usa el engine de InnoDB.

Con una máquina de un solo procesador, tablas MyISAM y las acciones básicas de consulta, inserción, borrado y actualización, MySQL ha demostrado que es de los SGBD más rápidos del mercado, incluidos los SGBD privativos. Por lo que para el uso de webs de estas características, principalmente bitácoras, algunos tipos de CMS, foros y similares, este SGBD está muy indicado.

El punto débil, no obstante, es precisamente su libertad, la falta de integridad referencial controlada por el SGBD y su escalabilidad. MySQL dispone de un engine específico para montar clústers, pero su uso es aún un poco básico y con muchos flecos que remendar.

Otro punto positivo de MySQL es su gran cantidad de documentación, tanto en inglés como en castellano y otros idiomas que está en su propia página web.

PostgreSQL

Para altas cargas y sistemas de gran actividad concerniente a la base de datos, ya sea por consultas complejas, integridad referencial o gran cantidad de consultas, está mejor indicado PostgreSQL.

Este SGBD tiene una gran cantidad de mejoras con respecto a la concurrencia, escalabilidad y alta carga, que da un nivel de confiabilidad mucho mayor que los dos sistemas mencionados anteriormente. En principio, el hecho de que una consulta de gran tamaño no bloquee una tabla, sino que se vayan acumulando operaciones de lectura y escritura como si commits de un sistema de control de versiones se tratara, da un gran nivel de concurrencia, al mismo tiempo que permite procesar consultas mucho más eficientemente y rápidamente.

Por otro lado, la gran cantidad de proyectos que giran entorno al sistema, han hecho que dispongan de herramientas que le permitan estar configurado en forma de clúster y reaccione de la misma forma, pero con mucha más capacidad, haciendo su rendimiento creciente de forma logarítmica, ha demostrado que, en varias máquinas con varios procesadores, reacciona de una forma más eficiente y rápida incluso que MySQL.

El punto negativo de este SGBD es que no está tan facilitada su instalación y configuración, ya que se basa en unos principios que hay que conocer previamente. Lo bueno, a este respecto, es que dispone de gran cantidad de documentación, incluso en castellano.

Conclusiones

Para sistemas pequeños, de poca carga, sin duda, yo empleo siempre que puedo SQLite. En caso de desbordar, extraer una copia y ponerla en un sistema como MySQL o PostgreSQL no es nada complicado.

Para sistemas CMS, Bitácoras, Foros y sitios simples en Internet que tengan previsión de carga, siempre es mejor montar un SGBD y, si se quiere hacer simple, lo mejor es usar MySQL.

Cuando ya intervienen factores como que la base de datos tiene muchas tablas, está muy normalizada y tiene riesgos de que se pierda su integridad referencial, así como es el caso de la programación de un CRM, ERP o programa orientado a la empresa o red social, en ese caso es mejor emplear PostgreSQL, ya que dará mayor seguridad, al mismo tiempo que mayores prestaciones en caso de necesitar escalar.