En los días en que alguien decía MySQL, solo existía MySQL. Puede elegir diferentes versiones (4.0, 4.1) pero el proveedor es el mismo. Esto cambió alrededor de MySQL 5.0/5.1 cuando Percona decidió lanzar su propia versión de MySQL:Percona Server. Un poco más tarde, MariaDB se unió a MariaDB 5.1 y la diversión (o la confusión) aumentó. ¿Qué versión debo usar? ¿Cuál es la diferencia entre MySQL 5.1, Percona Server 5.1 y MariaDB 5.1? ¿Cuál es más rápido? ¿Cuál es más estable? ¿Cuál tiene una funcionalidad superior? Con el tiempo, esto empeoró a medida que se introdujeron más y más cambios en cada uno de los sabores. Esta publicación de blog será nuestro intento de resumir las características clave que los diferencian. También intentaremos darte algunas sugerencias sobre qué sabor puede ser el mejor para un determinado tipo de proyecto. Comencemos.
Oracle MySQL
Solía ser MySQL, ahora es upstream. La mayor parte del desarrollo comienza aquí, cada versión a partir de la 5.6 resuelve algunas disputas internas y brinda un mejor rendimiento. También se agregan nuevas características de forma regular. MySQL 5.6 nos trajo (entre otros) GTID y una implementación inicial de replicación paralela. También nos dio la capacidad de ejecutar la mayoría de los ALTER en línea. Echemos un vistazo a las características de la última versión de MySQL:MySQL 5.7
Características de MySQL 5.7
Uno de los principales cambios son los cambios en el proceso de implementación:en lugar de diferentes scripts, simplemente puede ejecutar mysqld --initialize para configurar MySQL desde cero. Otro cambio muy importante:la replicación en paralelo basada en un reloj lógico. Finalmente, podemos usar la replicación paralela en todos los casos, sin importar si usa múltiples esquemas o no. Otra mejora de la replicación es la replicación de varias fuentes:un esclavo 5.7 puede tener varios maestros; es una característica excelente si desea crear un esclavo de agregación y, digamos, combinar datos de varios clústeres independientes.
InnoDB comenzó a admitir tipos espaciales, el grupo de búfer de InnoDB finalmente se puede cambiar de tamaño en tiempo de ejecución, los ALTER en línea se han mejorado para admitir más casos como particiones y ALTER no operativos.
MySQL comenzó a admitir tipos de datos JSON de forma nativa junto con varias funciones nuevas que se enfocan en agregar funcionalidad alrededor de JSON. La seguridad de sus datos es muy importante en estos días, MySQL 5.7 admite el cifrado de datos en reposo para espacios de tabla de archivo por tabla. También se han agregado algunas mejoras a la compatibilidad con SSL (SSL se configurará si las claves están en su lugar, se incluye un script que se puede usar para crear certificados). Desde la perspectiva de la gestión de usuarios, se ha agregado la configuración de la duración de la contraseña, lo que debería facilitar un poco el diseño de las políticas de caducidad de la contraseña.
Otra característica que pretende ayudar a los administradores de bases de datos es el esquema 'sys', un conjunto de vistas diseñado para facilitar el uso del esquema de rendimiento. Ha sido incluido por defecto en MySQL 5.7.
Finalmente, MySQL Group Replication (y eventualmente MySQL InnoDB Cluster) se ha agregado a MySQL 5.7. Funciona como un complemento y está incluido en las versiones recientes de la rama 5.7, pero ese es un tema aparte. En resumen, Group Replication le permite crear un clúster síncrono "virtualmente".
Definitivamente, esta no es una lista completa de características; si está interesado en todas ellas, puede consultar la documentación de MySQL 5.7.
Servidor Percona
Al principio, había un conjunto de parches para aplicar al código fuente de MySQL que añadía algunas mejoras de rendimiento y funcionalidad. En algún momento, Percona decidió lanzar su propia compilación de MySQL que incluía estos parches. Con el tiempo, se dispuso de más recursos de desarrollo, por lo que se agregaron más y más funciones.
En general, puede ver Percona Server como la última versión de MySQL con múltiples parches/mejoras. Con el tiempo, algunas de las mejoras de las funciones de Percona Server se reemplazan por funciones anteriores, cada vez que Oracle desarrolla una función que reemplaza una de las funcionalidades agregadas en Percona Server. Siempre que la implementación esté a la par, Percona elimina su propio código en favor del código del upstream. Esto hace que Percona Server sea básicamente un reemplazo directo para MySQL de Oracle. Una de las áreas en las que se han realizado importantes mejoras de rendimiento es InnoDB. Se ha modificado lo suficiente como para marcarlo como XtraDB. Actualmente es totalmente compatible con InnoDB pero no siempre ha sido así. Por ejemplo, algunas características de Percona Server 5.5 no eran compatibles con MySQL 5.5. También es cierto para las versiones más recientes de Percona Server. Lo que es importante es que, de forma predeterminada, Percona Server viene con todas las funciones incompatibles deshabilitadas:facilita probarlo y volver a MySQL de Oracle si es necesario. Teniendo en cuenta todo lo anterior, aún debe tener cuidado cuando planee migrar de Percona Server a MySQL, ya que alguien podría haber habilitado una de las funciones incompatibles.
Lo que vale la pena destacar es que Percona se esfuerza por volver a implementar las características empresariales del upstream. En el caso de MySQL, los ejemplos son la implementación de un grupo de subprocesos o un complemento de autenticación PAM. Echemos un vistazo rápido a algunas de las características del servidor Percona.
Características de Percona Server 5.7
Una de las características principales de XtraDB es la escalabilidad mejorada del grupo de búfer:aunque cada vez hay menos contención debido al trabajo que Oracle realiza en cada versión de MySQL, el equipo de ingeniería de Percona se esfuerza por impulsar aún más el rendimiento y eliminar los mutex adicionales que pueden limitar el rendimiento. Además, se escriben más datos en el monitor InnoDB (accesible a través de SHOW ENGINE INNODB STATUS) con respecto a las contenciones dentro de InnoDB; por ejemplo, se ha agregado una sección sobre semáforos.
Se ha realizado otro conjunto de mejoras en el área de E/S. En InnoDB, puede establecer un método de vaciado solo para los espacios de tabla de InnoDB y esto provoca el almacenamiento en búfer doble para los registros de rehacer de InnoDB. XtraDB hace posible usar O_DIRECT también para esos archivos. También agrega más datos sobre puntos de control a la salida de SHOW ENGINE INNODB STATUS. Además de eso, se han implementado un búfer de doble escritura paralelo y un lavado LRU de subprocesos múltiples para reducir la contención en las operaciones de E/S dentro de InnoDB.
El grupo de subprocesos es otra función que Percona Server pone a disposición. En Oracle MySQL está disponible solo en la edición Enterprise. Aquí puedes usar la implementación de Percona gratis. En general, el grupo de subprocesos reduce las contenciones mientras atiende una gran cantidad de conexiones desde la aplicación al reutilizar las conexiones existentes a la base de datos.
Dos características más son reemplazos directos de características de la versión Enterprise de MySQL. Uno de ellos es el complemento de autenticación PAM que ha sido desarrollado por Percona y está diseñado para permitir el uso de muchas opciones de autenticación diferentes como LDAP, RSA SecurID o cualquier otro método compatible con PAM. La segunda característica también está relacionada con la seguridad:complemento de registro de auditoría. Creará un archivo con un registro de las acciones realizadas en el servidor de la base de datos.
De vez en cuando, Percona introduce mejoras significativas en otros motores de almacenamiento, como los cambios realizados en el motor MEMORY, que permitía utilizar datos de tipo VARCHAR o BLOB.
La introducción de bloqueos de respaldo también fue una mejora bastante significativa. En Oracle y MariaDB, el único método de bloquear la tabla para obtener una copia de seguridad consistente era usar FLUSH TABLES WITH READ LOCK (FTWRL). Es bastante pesado y obliga a MySQL a cerrar todas las tablas abiertas. Los bloqueos de copia de seguridad, por otro lado, utilizan un enfoque más ligero de bloqueos de metadatos. En muchos casos, el servidor con mucha carga que ejecuta FTWRL tarda demasiado (y bloquea el servidor durante demasiado tiempo) para que se considere factible, mientras que los bloqueos de copia de seguridad permiten realizar una copia de seguridad mediante mysqldump o xtrabackup.
Percona también está abierta a portar funciones de otros proveedores. Un ejemplo de ello es el puerto de COMENZAR TRANSACCIÓN CON INSTANTÁNEAS CONSISTENTES de MariaDB. Esta característica también está relacionada con las copias de seguridad:con su ayuda, puede realizar una copia de seguridad lógica coherente (usando mysqldump) sin ejecutar FLUSH TABLE WITH READ LOCK.
Finalmente, tres características que mejoran la observabilidad:primero:estadísticas de usuario. Esta es una función bastante liviana que recopila datos sobre usuarios, índices, tablas e hilos. Le permite encontrar índices no utilizados o determinar qué usuario es responsable de la carga en el servidor. Actualmente es parcialmente redundante para performance_schema pero es un poco más ligero y fue creado en los días de MySQL 5.0 - 5.1, donde nadie soñaba con performance_schema.
Segundo:registro mejorado de consultas lentas. Nuevamente, se agregó en momentos en que la granularidad más alta de long_query_time era de 1 segundo. Con esta adición, tenía una granularidad de microsegundos y un montón de datos adicionales sobre las estadísticas de InnoDB por consulta o sus características de rendimiento general. ¿Creó una tabla temporal? ¿Utilizó un índice? ¿Se ha almacenado en caché en la caché de consultas de MySQL?
Tercera característica que mencionamos un par de veces anteriormente:Percona Server expone significativamente más datos en SHOW ENGINE INNODB STATUS que en el upstream. Definitivamente ayuda a comprender mejor la carga de trabajo y detectar más problemas antes de que se desarrollen.
Por supuesto, esta no es una lista completa; si está interesado en obtener más detalles, puede consultar la documentación de Percona Server.
MariaDB
MariaDB comenzó como una bifurcación de MySQL pero, con parte del equipo de desarrollo de MySQL original uniéndose a MariaDB, rápidamente se centró en agregar funciones. En MariaDB 5.3, se agregaron muchas características al optimizador:acceso de clave por lotes, lectura de rango múltiple, inserción de condición de índice, por nombrar algunas. Esto permitió que MariaDB sobresaliera en algunas cargas de trabajo en las que MySQL o Percona Server tendrían dificultades. Hasta ahora, algunas de esas funciones se han agregado a MySQL (principalmente en MySQL 5.6), pero algunas siguen siendo exclusivas de MariaDB.
Otra característica importante que introdujo MariaDB fue el ID de transacción global. No mucho después, Oracle lanzó su propia implementación, pero MariaDB fue la primera en tenerla. Una historia similar ocurre con otra función de replicación:la replicación de múltiples fuentes:MariaDB la tenía antes que Oracle. Ahora, MariaDB 10.2 recientemente lanzado también contiene características que estarán disponibles en MySQL 8.0, que aún está en desarrollo. Estamos hablando, por ejemplo, de expresiones de tablas comunes recursivas o funciones de ventana.
Características de MariaDB 10.2
Como mencionamos, MariaDB 10.2 presenta funciones de ventana y expresiones de tablas comunes recursivas, mejoras en SQL que deberían ayudar a los desarrolladores a escribir consultas SQL más eficientes.
Un cambio muy importante es que MariaDB 10.2 usa InnoDB. Hasta 10.1, se ha utilizado XtraDB como almacenamiento predeterminado. Desafortunadamente, esto hace que las funciones añadidas en el último XtraDB no estén disponibles para los usuarios de MariaDB 10.2.
Se han realizado mejoras en las columnas virtuales:se han eliminado más limitaciones en 10.2.
Por último, se ha agregado soporte para múltiples disparadores para el mismo evento; ahora puede crear varios, por ejemplo, disparadores ON UPDATE en la misma tabla.
Los desarrolladores deberían beneficiarse de la compatibilidad con JSON, junto con un par de funciones relacionadas con ella. También les deberían gustar las nuevas funciones que les permiten exportar datos espaciales en formato GeoJSON. Hablando de JSON, se han realizado mejoras en la salida EXPLAIN FORMAT=JSON:se muestran más datos.
En cuanto a la seguridad, se ha agregado soporte para OpenSSL 1.1 y LibreSSL.
Por supuesto, esta lista no está completa y si está interesado en lo que se ha agregado a MySQL 10.2, puede consultar la documentación.
Además de las nuevas funciones, MariaDB 10.2 se beneficia de las funciones implementadas en versiones anteriores. Repasaremos los más importantes.
Las características más importantes de MariaDB 10.1
En primer lugar, MariaDB desde 10.1 viene incluido con el clúster de Galera; no es necesario instalar bibliotecas adicionales, todo está listo para usar.
MariaDB 10.1 trajo la implementación del cifrado de datos en reposo. En comparación con la función implementada en MySQL de Oracle, MariaDB la tiene más extendida. No solo cifra los espacios de tabla, sino que también cifra los registros de rehacer, los archivos temporales y los registros binarios. Esto viene con algunos problemas:las herramientas CLI como mysqldump o xtrabackup no pueden acceder a los registros binarios y pueden tener problemas para realizar copias de seguridad de las instancias cifradas (esto es especialmente cierto para xtrabackup; recientemente MariaDB creó una bifurcación xtrabackup llamada MariaDB Backup que admite datos en reposo cifrado).
Vale, ¿qué sabor debo usar?
Como suele ser, la respuesta correcta sería:“Depende” :-). Compartiremos algunas de nuestras observaciones que pueden o no ayudarlo a decidir, pero, al final, depende de usted ejecutar pruebas comparativas y encontrar la opción que funcione mejor para su entorno y aplicación.
En primer lugar, hablemos del flujo. Oracle lanza una nueva versión, digamos MySQL 5.7. En cuanto al rendimiento, en ese momento, esta es la variante de MySQL más rápida del mercado. Esto se debe a que solo Oracle tiene suficientes recursos para trabajar en mejorar InnoDB hasta ese punto. En un par de meses (en el caso de 5.7, fueron 4 meses), Percona lanza Percona Server 5.7 con su conjunto de mejoras; según el tipo de carga de trabajo, puede ofrecer un rendimiento incluso mejor que el anterior. Finalmente, MariaDB adopta una nueva versión upstream y construye su nueva versión sobre ella.
Así es como se veía en un calendario (todavía estamos hablando de MySQL 5.7).
MySQL 5.7 GA:21 de octubre de 2015
Percona Server 5.7 GA:23 de febrero de 2016
MariaDB 10.2 GA:23 de mayo de 2017
Tenga en cuenta cuánto tardó MariaDB en lanzar una versión basada en MySQL 5.7; todas las versiones anteriores se basaron en MySQL 5.6 y, obviamente, ofrecieron un rendimiento inferior al de MySQL 5.7. Por otro lado, se ha lanzado MariaDB 10.2 con InnoDB reemplazando a XtraDB. Si bien es cierto que Oracle cerró en su mayoría la brecha de rendimiento entre MySQL y Percona Server, todavía es solo "en su mayoría". Como resultado, MariaDB 10.2 puede ofrecer un rendimiento inferior al de Percona Server en algunos casos (y mejor en otros casos, debido al trabajo de optimización realizado en MariaDB 5.3, parte del cual aún no se ha recreado en MySQL).
En cuanto a las características, es más complejo. MariaDB ha estado agregando muchas funciones, por lo que si está interesado en algunas de ellas, definitivamente puede considerar usar MariaDB. También hay un inconveniente. Percona Server tenía una gran cantidad de características que lo diferenciaban de MySQL upstream, pero cuando Oracle comenzó a implementarlas en MySQL, Percona decidió depreciar sus implementaciones a favor de usar la implementación upstream. Esto redujo la cantidad de código que es diferente entre MySQL y Percona Server, facilita el mantenimiento del código de Percona Server y, lo que es más importante, hace que Percona Server sea 100 % compatible con MySQL.
Desafortunadamente, esto no es cierto para MariaDB. MariaDB introdujo GTID primero, eso es cierto, pero después de que Oracle desarrolló su versión de GTID, MariaDB decidió ceñirse a su propia implementación. Este blog no es el lugar para decidir qué implementación es mejor, pero como resultado tenemos que administrar dos sistemas GTID diferentes e incompatibles:agrega una carga a cualquier herramienta que administre la replicación y reduce la interoperabilidad. Cumplir con la replicación:compromiso grupal y replicación paralela:tanto Oracle como MariaDB tienen su propia implementación y si trabaja con ambos, debe aprenderlos a ambos para aplicar el ajuste requerido:las perillas son diferentes y funcionan de una manera diferente. Un caso similar es con el soporte de columnas virtuales:dos implementaciones diferentes, no 100% compatibles que, como resultado, hicieron que no fuera posible volcar fácilmente datos de MariaDB y cargarlos en MySQL de Oracle (y viceversa) porque la sintaxis es ligeramente diferente. Por lo tanto, si decide usar una versión de MariaDB para alguna función nueva, es posible que termine quedándose con ella, incluso si desea volver a migrar a MySQL para usar la implementación de Oracle. En el mejor de los casos, la migración requeriría mucho más esfuerzo para ejecutarse. Por supuesto, si permanece en un entorno todo el tiempo, es posible que no le afecte gravemente. Pero incluso entonces, notará una falta de compatibilidad, aunque solo sea mientras lee blogs en Internet y encuentra soluciones que no son realmente aplicables a su versión de MySQL.
Entonces, para resumir, si está interesado en mantener la compatibilidad con MySQL, Percona Server (o MySQL mismo, por supuesto) probablemente sea el camino a seguir. Si está interesado en el rendimiento, siempre que haya un servidor Percona construido sobre la última versión de MySQL, puede ser el camino a seguir. Por supuesto, es posible que desee comparar MariaDB y ver si su carga de trabajo no puede beneficiarse de algunas de las optimizaciones que aún son exclusivas de MariaDB. Desde el punto de vista operativo, probablemente sea bueno ceñirse a uno de los entornos (Oracle/Percona o MariaDB), el que funcione mejor para usted. MySQL o Percona Server tienen la ventaja de que se usan más comúnmente y es un poco más fácil integrarlos con herramientas externas (porque no todas las herramientas admiten todas las características de MariaDB). Si se beneficiaría de una característica nueva y brillante que acaba de implementarse en MariaDB, debe considerarla, teniendo en cuenta cualquier posible problema de compatibilidad y un posible rendimiento más bajo.
Esperamos que esta publicación de blog le haya dado algunas ideas sobre las diferentes opciones que tenemos en el mundo de MySQL y los diferentes ángulos desde los cuales puede compararlas. Al final del día, será su tarea decidir qué es lo mejor para su configuración. Puede que no sea fácil, pero aún así debemos estar agradecidos de tener una opción y podemos elegir lo que funciona mejor para nosotros.
