1. M
ySQL ha sido indiscutiblemente
durante años la base de datos
más popular del mundo. Mucho
ha tenido que ver con ello la proliferación
de sistemas LAMP (Linux, Apache,
MySQL, PHP/Python/Perl) usados para la
implementación de sitios web de todos los
tamaños. Esta posición dominante proba-
blemente haya sido el motivo de preocupa-
ción para muchos – primero, cuando Sun
Microsystems adquirió MySQL Ab (la
empresa que había detrás de MySQL), y
luego cuando Oracle compró Sun. Un
grupo de, en su mayoría, empleados origi-
nales de MySQL AB, liderado e iniciado por
el cofundador de MySQL Michael “Monty”
Widenius, tuvo la determinación de dejar
Sun/Oracle, crear una nueva empresa,
Monty Program, y crear una rama de
MySQL llamada MariaDB.
MariaDB
El objetivo general de MariaDB es el de ser
una alternativa a MySQL – eso sí, con más
funcionalidades y mejor rendimiento que
éste.
MariaDB está basado en la versión
homóloga de MySQL, si ésta existe. Por
ejemplo, MariaDB 5.1.53 está basada en
MySQL 5.1.53, con algunas soluciones a
errores, motores de almacenamiento adicio-
nales, nuevas funcionalidades y mejoras en
el rendimiento. Las versiones de MariaDB
que no tienen una versión equivalente en
MySQL (como por ejemplo MariaDB 5.2.4)
contienen nuevas funcionalidades lo sufi-
cientemente importantes como para que
sus desarrolladores decidan incrementar el
PRÁCTICO • MariaDB vs. MySQL
44 Número 73 W W W. L I N U X - M A G A Z I N E . E S
número de versión. Dado que MariaDB es
“MySQL más unas cuantas cosas más”, lo
más lógico es que nos centremos en esas
funcionalidades adicionales que tiene
MariaDB y de las que carece MySQL.
Diferencias y
Funcionalidades
Como hemos dicho, las actuales versiones
estables de cada base de datos son MySQL
5.5.8 y MariaDB 5.2.4. Las versiones de
MariaDB suelen tardar en salir algo más
que sus equivalentes en MySQL, motivo
por el cual aún no se ha publicado
MariaDB 5.5.8. Este retardo suele ir desde
un par de semanas hasta dos o tres meses,
lo que le permite a sus desarrolladores inte-
grar adecuadamente el nuevo código de
MySQL en el árbol de fuentes de MariaDB
y probarlo en busca de regresiones en el
rendimiento o de nuevos bugs.
En una primera toma de contacto, uno
puede pensar que no ha habido muchos
cambios. El servidor se sigue llamando
mysqld, el cliente de línea de comandos se
llama mysql, el archivo de configuración
principal sigue siendo my.cnf, y todos los
conectores, como el de PHP o el de Python,
funcionan sin ningún tipo de problema.
El cambio más visible, al menos para los
usuarios del cliente mysql, es puramente
estético. El intérprete ha sido modificado
para que sea más informativo, indicando si
estamos conectados a una base de datos
MariaDB o MySQL. Además muestra el
nombre de la base de datos a la que esta-
mos conectados – o (none) si no estamos
conectados a ninguna base de datos especí-
fica. Otra nota sobre la aplicación cliente:
debido a la especial atención que ponen los
desarrolladores de MariaDB en mantener la
compatibilidad retroactiva con MySQL,
ambas aplicaciones cliente funcionan con
cualquiera de las dos bases de datos, como
se puede ver en las Figuras 1 y 2.
El siguiente cambio visible es que
MariaDB incluye varios motores de alma-
cenamiento adicionales (cuya lista se
puede mostrar con el comando show sto-
rage engines;). Entre otros, se incluyen los
motores Aria, XtraDB (una versión mejo-
rada y ampliada de InnoDB), PBXT, Fede-
ratedX (una alternativa a Federated),
OQGRAPH y SphinxSE. Todos ellos están
disponibles para MySQL, pero para usarlos
necesitamos compilarlos o instalarlos
nosotros mismos. Con MariaDB, están
todos disponibles desde el momento de la
instalación. Naturalmente, todos los moto-
res que se incluyen en MySQL (MyISAM,
blackhole, CSV, Memory, etc.) están inclui-
dos en MariaDB.
También se han realizado mejoras en
INFORMATION_SCHEMA, que proporciona
los datos de la base de datos. MariaDB ha
añadido más datos a varias tablas. Pri-
mero, la tabla INFORMATION_ SCHEMA.
PLUGINS tiene dos nuevas columnas, PLU-
GIN_MATURITY y PLUGIN_AUTH_VER-
SION, en las que se pueden ver los núme-
ros de versión de los plugins, así como la
madurez del plugin instalado, stable, beta
u otra calidad.
Otra mejora consiste en la adición de
una nueva columna, TIME_MS, a la tabla
INFORMATION_SCHEMA.PROCESSLIST.
MaximKazmin,123RF
Comparamos MariaDB y MySQL
CARA A CARA
MariaDB es primo hermano de MySQL – pero no un hermano gemelo.
POR DANIEL BARTHOLOMEW

2. 45Número 73W W W. L I N U X - M A G A Z I N E . E S
Esta columna proporciona la misma infor-
mación que la columna TIME, pero en uni-
dades de milisegundos y con una precisión
de microsegundos; la columna TIME tiene
una precisión de 1 segundo, que es tam-
bién la unidad de ésta.
El registro de consultas lentas también
ha sido mejorado. En MariaDB podemos
establecer la verbosidad, filtrar las consul-
tas que no queremos que se registren o
limitar la tasa de registros, por ejemplo,
para que sólo se registre una cuarta parte
de las consultas en vez de todas ellas. Igual
que ocurre con el resto de nuevas funcio-
nalidades de MariaDB, no se habilita por
defecto en el archivo de configuración pre-
determinado, a fin de mantener la máxima
compatibilidad con el comportamiento de
MySQL [1].
Otros Cambios
Hay otros muchos cambios en MariaDB
que no son tan visibles, pero que ayudan
ya sea a mejorar el rendimiento de
MariaDB, a dotarlo de una mayor flexibili-
dad, o a ambas cosas. Un ejemplo de
mejora en el rendimiento es la nueva fun-
cionalidad de “eliminación de tablas”. A
menudo, cuando se tienen datos muy nor-
malizados [2] en la base de datos se usan
las “vistas” (view) para hacer las consultas.
Una vista es una especie de consulta
almacenada. Considerémosla como un
modo particular de ver los datos conteni-
dos en la base de datos. Las vistas vienen
muy bien si se usan correctamente, pero
tienen un coste en cuanto a rendimiento.
Cada vez que se usa una de ellas, se con-
sultan todas las tablas con las que está
conectada, incluso aunque la consulta no
solicite datos de todas ellas. La funcionali-
dad de “eliminación de tablas” de MariaDB
ha sido diseñada con el objetivo de detec-
tar cuándo una consulta no utiliza unas
tablas determinadas y eliminarlas así del
plan de consulta. La mejora en el rendi-
miento puede llegar a ser tremenda, depen-
diendo del uso que se le dé a la base de
datos.
Si se usa el motor de almacenamiento
MyISAM para las tablas de la base de
datos, la segmentación de la caché de cla-
ves MyISAM nos puede venir bien. La
caché de claves MyISAM puede verse afec-
tada por retenciones derivadas de bloqueos
cuando hay muchas aplicaciones acce-
diendo a la caché simultáneamente. Seg-
mentando la caché de claves se consigue
aliviar el problema dividiéndola en seg-
mentos menores. Se pueden especificar
hasta 64 segmentos. No todas las aplicacio-
nes se beneficiarán de esta funcionalidad,
pero cuando el bloqueo de la caché de cla-
ves se convierte en el cuello de botella, es
una genial forma de mejorar el rendi-
miento sin tener que cambiar nada en la
aplicación. Una vez más, en pos de la com-
patibilidad con MySQL, viene desactivada
por defecto.
En cuanto a mejora en la flexibilidad de
MariaDB, una de las nuevas funcionalida-
des son las columnas virtuales, que son
columnas que se calculan y actualizan a
tiempo real. Hace tiempo, allá en 2008,
Andrey Zhakove compartió con MySQL
una versión inicial de esta funcionalidad,
pero nunca llegaron a distribuirla con la
versión estable.
Lo más frecuente es dejar toda la lógica
en las aplicaciones y que las bases de datos
sólo hagan eso, alojar datos. Sin embargo,
otras veces puede resultar beneficioso dele-
gar en la base de datos algunos cálculos.
Por ejemplo, si tenemos varias aplicaciones
interactuando con la base de datos, dejar
que ésta lleve a cabo algunos cálculos
puede redundar en una mayor simplifica-
ción del esfuerzo de desarrollo y en una
mejor integridad de los datos.
Otra nueva funcionalidad de MariaDB
tiene como objetivo hacer que el código
sea más modular y prepararlo para desa-
rrollos futuros. Un ejemplo de ello puede
ser la nueva funcionalidad CREATE Table
específica de cada motor de almacena-
miento. Anteriormente, si un motor de
almacenamiento quería implementar una
funcionalidad que requiriese de nuevas
opciones para el comando CREATE table,
había que aplicar un parche a esa sección
del código del servidor.
Idealmente, el código del motor de alma-
cenamiento debería estar lo suficiente-
mente aislado como para que se pueda
añadir sin afectar al resto del servidor en
caso de que no se use. Si un motor de
almacenamiento parchea alguna parte del
código del servidor, ya no se podrán incluir
con seguridad motores de almacenamiento
en estado beta o alpha en una versión esta-
ble. En MariaDB existe actualmente un
modo estándar a través del cual los moto-
res de almacenamiento pueden ampliar la
directiva CREATE table, manteniendo ais-
lado e independiente el código del motor
de almacenamiento. A partir de ahora es
posible incluir nuevos motores de almace-
MariaDB vs. MySQL • PRÁCTICO
Figura 1: Clientes de MariaDB 5.2.4 (arriba) y MySQL 5.5.8
conectando con un sevidor MySQL 5.5.8. Como no se ha seleccionado
ninguna base de datos, el cliente mysql de MariaDB muestra “(none)”
en el espacio para el nombre de la base de datos abierta.
Figura 2: Clientes de MariaDB 5.2.4 (arriba) y MySQL 5.5.8
conectando con un sevidor MariaDB 5.2.4. Como no se ha selec-
cionado ninguna base de datos, el cliente mysql de MariaDB muestra
“(none)” en el espacio para el nombre de la base de datos abierta.

3. ción, encargados de actualizar los datos
cuando es necesario, ha hecho que sea
más fácil actualizar de MySQL 5.0 a
MariaDB 5.1, que de MySQL 5.0 a MySQL
5.1.
La política estándar para cualquier
nueva funcionalidad es la siguiente: si la
nueva funcionalidad introduce algún pro-
blema de compatibilidad, la configuración
predeterminada de MariaDB, o bien la des-
habilita completamente, como en el caso
de la segmentación de la caché de claves, o
la configura para que actúe como la ver-
sión equivalente de MySQL.
Dado que no siempre es posible el cum-
plimiento de esta política estándar, existen
algunas incompatibilidades inevitables
entre MariaDB y MySQL. Por ejemplo, en
caso de que estemos usando una librería
para un motor de almacenamiento de sólo
binarios, debe recompilarse específica-
mente para la versión de MariaDB que
estemos utilizando, debido a ciertos cam-
bios internos en la API del motor de alma-
cenamiento. Además, la salida producida
por algunos componentes, como la del
registro de consultas lentas o los resultados
del comando CHECKSUM TABLE, varían.
Por tanto, si nuestros scripts parsean estas
salidas, no hay más remedio que adaptar-
los.
Una última nota acerca de la compatibili-
dad: si empezamos a usar cualquiera de las
nuevas funcionalidades u opciones de
configuración de MariaDB, no es fácil vol-
ver siquiera a una versión equivalente de
MySQL.
Conclusión
Sólo la situación de cada cual puede deter-
minar si se ha de optar por MariaDB en
lugar de MySQL. Si tenemos un contrato de
soporte con Oracle, entonces la elección ya
está hecha; no soportan MariaDB. Sin
embargo, hay varias empresas, como
SkySQL, que ofrecen soporte completo 24/
7 tanto para MariaDB como para MySQL.
MariaDB sigue la pista a las últimas ver-
siones oficiales de MySQL, publicando
desde dos semanas después hasta dos o
tres meses, dependiendo de cómo de gran-
des hayan sido los cambios producidos
entre las versiones. Por otro lado, MariaDB
incluye muchas funcionalidades que no se
encuentran en MySQL, e irá incluyendo
otras nuevas a medida que vayan siendo
probadas y aprobadas.
Una razón para elegir MySQL sobre
MariaDB es la omnipresencia de MySQL en
los repositorios oficiales de todas las distri-
buciones de Linux. Instalar MySQL es tan
sencillo como hacer apt-get o yum.
MariaDB está trabajando por su inclusión
en los repositorios oficiales, pero por
ahora, sólo se encuentra en unas pocas [6].
Otra razón para continuar usando
MySQL puede ser que ya dispongamos de
una licencia comercial de Oracle que nos
permita incluir MySQL en una aplicación
privativa. Los desarrolladores de MariaDB
están sujetos a los términos de la licencia
GPL y no pueden publicar MariaDB con
doble licencia.
Finalmente, sea cual sea la elección
última, la competencia entre MariaDB y
MySQL siempre es buena. Después de
todo, nadie puede decir que Internet Expo-
rer no saliera beneficiado de su rivalidad
con Firefox. I
namiento en una fase más temprana de su
desarrollo, ya que en caso de no usarse no
tendrán efecto alguno sobre el resto del ser-
vidor.
Todas las funcionalidades mostradas
aquí, así como otras que no hemos visto,
se pueden consultar con mayor detalle en
la base de conocimiendo de MariaDB [3].
Compatibilidad
Con MariaDB, cada esfuerzo se ha hecho
teniendo en cuenta la compatibilidad y
haciendo que las nuevas funcionalidades
sean lo más transparentes posible para el
usuario para que cualquier desarrollo pre-
vio sea completamente válido. A este
efecto:
• Los datos y archivos de definición de
tablas (.frm) son binariamente compati-
bles.
• Todas las APIs de clientes, protocolos y
structs son idénticas.
• Todos los nombres de archivo, rutas,
puertos, sockets, etc., son exactamente
iguales.
• Todos los conectores de MySQL (PHP,
Perl, Python, Java, MyODBC, Ruby, C,
etc.) funcionan sin problemas con
MariaDB.
• Los paquetes mysql-client funcionan con
MariaDB y viceversa.
Por tanto, en la mayoría de los casos se
puede desinstalar MySQL e instalar
MariaDB, y todo seguirá funcionando
como si nada. Si se usa la misma versión,
no hay que convertir los archivos de
datos, igual que si se estuviese actuali-
zando desde una versión 5.1.x de MySQL
a otra.
Además, gran parte del esfuerzo hecho
en el desarrollo de los scripts de actualiza-
PRÁCTICO • MariaDB vs. MySQL
46 Número 73 W W W. L I N U X - M A G A Z I N E . E S
[1] Manual de referencia para MySQL:
http://dev.mysql.com/doc/refman/5.
5/en/
[2] Artículo en Wikipedia sobre normali-
zación de bases de datos: http://en.
wikipedia.org/wiki/
Database_normalization
[3] Base de conocimiento de MariaDB:
http://kb.askmonty.org/v/mariadb
[4] Contribuciones externas para
MySQL 5.5: http://www.lenzg.net/
archives/
325-A-quick-summary-of-patch-cont
ributions-included-in-MySQL-5.5.
html
[5] Contribuciones externas para
MariaDB 5.2: http://askmonty.org/
blog/
mariadb-5-2-is-released-as-stable
[6] Distros con MariaDB: http://kb.
askmonty.org/v/
where-can-i-download-mariadb
RECURSOS
Una de las razones por las que MariaDB
cuenta con funcionalidades que MySQL no
tiene es porque el proyecto MySQL adopta
muy lentamente el código proveniente de
las contribuciones externas. Por ejemplo,
en la publicación de la versión 5.5.8 GA de
MySQL, las contribuciones externas eran,
en su mayoría, menores (más que nada
unos cuantos arreglos de fallos [4]), mien-
tras que en MariaDB 5.2 se introdujeron
varias nuevas funcionalidades con código
proveniente de contribuciones ajenas a
Monty Program [5]. Entre estas nuevas fun-
cionalidades se cuentan las estadísticas de
usuario, la segmentación de la caché de
claves, autenticación modular (Pluggable
Authentication), el motor de almacena-
miento OQGraph y el cliente de SphinxSE.
Los motivos que los desarrolladores de
MariaDB aducen para incluir tal cantidad de
código externo son de naturaleza pragmá-
tica: si el código es lo suficientemente
bueno como para ejecutarse en productivo
en empresas como Google, Facebook u
otras, entonces es lo suficientemente
bueno para ser incluido en MariaDB.
Aunque dicha aseveración no siempre sea
cierta, en las contribuciones se llevan a
cabo una serie de rigurosas pruebas y de
revisión del código. Incluso cuando una
contribución no alcanza el nivel de calidad
óptimo, se puede modificar hasta que
alcance dicho nivel de calidad para su inclu-
sión. Un ejemplo de ello es la funcionalidad
que aportan las columnas virtuales, que fue
reescrita sobremanera para mejorar su ren-
dimiento, funcionalidad, fiabilidad e inte-
gración con MariaDB.
Contribuciones Externas