MariaDB 10.4 es una rama de desarrollo actual de MariaDB. Recientemente, el 21 de mayo, se lanzó el tercer Release Candidate (10.4.5), acercándonos al lanzamiento oficial. Por eso pensamos que sería una buena idea echar un vistazo a las nuevas características de 10.4. También compartiremos algunos pensamientos sobre una publicación de blog reciente publicada por MariaDB Corporation. Para obtener información sobre el lanzamiento en sí, puede encontrar todos los detalles en el registro de cambios de MariaDB 10.4.0.
Cambios de rendimiento
Los juegos de caracteres Unicode suelen ser más lentos que los juegos de caracteres como latin1, principalmente debido a su tamaño. MySQL 8.0 trajo mejoras significativas en esta área, y MariaDB 10.4 también debería ser notablemente más rápido que 10.3 en este sentido. Es una mejora bastante importante:a la gente le encanta usar emojis, que requieren que UTF8 esté habilitado. Se han realizado algunos trabajos en el optimizador:MariaDB 10.4 debería funcionar mejor para las subconsultas IN(), ya que ahora es posible introducir condiciones en las subconsultas materializadas.
Iniciar y detener InnoDB puede llevar un tiempo, según la cantidad de datos en los registros de rehacer. MariaDB 10.4 mejorará el inicio, el apagado y la purga. Tales mejoras son especialmente importantes dada la popularidad de las herramientas de copia de seguridad activa como mariabackup y xtrabackup. Esas herramientas, al final, pasan por el proceso de inicio de InnoDB desde un apagado incorrecto cuando aplican registros de rehacer, por lo tanto, cada mejora en esa área debería reducir el tiempo necesario para restaurar las copias de seguridad.
Cambios de InnoDB
MariaDB 10.4 ha recibido una operación DROP COLUMN instantánea. Ahora también es posible reordenar las columnas de la tabla sin necesidad de reconstruirla. No podemos enfatizar lo importante que es esto. Quizás se pregunte cuáles son las operaciones más comunes que realiza en el entorno de producción. Diríamos que es agregar o quitar un índice. Otra operación más común serían las operaciones en las columnas:agregar una nueva columna y eliminar la columna existente. Hasta ahora, el enfoque más común era usar herramientas externas para hacer el trabajo:pt-online-schema-change o, más recientemente, gh-ost. Ambos tienen sus limitaciones (gh-ost no funciona para Galera Cluster, por ejemplo) que pueden hacer que sea imposible usarlos en su sistema. Especialmente difíciles son las claves foráneas. Con DROP COLUMN instantáneo (instant ADD COLUMN ya está disponible), una gran parte de los cambios de esquema se pueden realizar ad hoc, sin programación ni planificación detalladas, como se tiene que hacer ahora. Es importante tener en cuenta que los cambios instantáneos son lo que queremos tener. Hay cambios de esquema que no bloquean, como la creación de un índice, pero tales operaciones plantean un serio desafío cuando se usa la replicación, ya que inducen un retraso en la replicación. Por lo tanto, aunque la operación podría haberse ejecutado en un sistema en vivo, preferimos usar soluciones alternativas como pt-online-schema-change para mantener un mejor control sobre el proceso.
Esta no es la única mejora en cómo se ejecutan los cambios de esquema. MariaDB 10.4 se beneficiará de una extensión más rápida de las columnas VARCHAR, además, los cambios en el juego de caracteres y la intercalación en las columnas no indexadas serán instantáneos.
Cambios generales
Uno de los mayores cambios son los cambios en la gestión de usuarios. No se creará la tabla mysql.host, la tabla mysql.user está en desuso. Las cuentas de usuario y los privilegios globales se mantendrán en la tabla mysql.global_priv. Esto es potencialmente un cambio serio para todas las herramientas (incluido ClusterControl), que tienen una opción para administrar usuarios de MySQL y MariaDB:se deberán escribir nuevos casos para cubrir la administración de usuarios en MariaDB 10.4 y posteriores. Si bien reconocemos que se necesitan cambios, esto definitivamente no ayuda a mantener las herramientas tanto para MariaDB como para MySQL, lo que hace que el panorama de las herramientas esté aún más dividido de lo que ya está. Hablando de usuarios, MariaDB 10.4 viene con una opción para caducar la contraseña del usuario. Definitivamente, este es un paso en una buena dirección:ayuda a aplicar buenas prácticas con respecto a la administración de contraseñas.
Aunque lo cubriremos en un blog separado con más detalle, tenemos que mencionar aquí la compatibilidad con Galera 26.4:MariaDB 10.4 se beneficiará de una nueva versión de Galera con características como replicación de transmisión o SST mejorado gracias a los bloqueos de respaldo.
Finalmente, en MariaDB 10.4 puede establecer sql_mode=MSSQL. Esta es una implementación inicial, pero sql_mode=ORACLE también fue una implementación inicial en algún momento. Esto muestra el enfoque de MariaDB en los clientes empresariales:si los clientes de Oracle deciden migrar, es muy probable que la adopción de MariaDB entre Microsoft SQL Server también crezca a medida que se agreguen más funciones y la migración se convierta en un problema menor.
MariaDB siendo un tenedor
Recientemente vimos una publicación de blog que explicaba la postura de MariaDB sobre los cambios y la compatibilidad de InnoDB. La esencia es que MariaDB ya no fusionará las características de InnoDB de MySQL, el enfoque estará en la mejora de la estabilidad y el rendimiento realizada por MariaDB. Básicamente, esto significa que MariaDB se volverá incompatible con MySQL. Incluso si pudiera hacer la actualización binaria en el pasado, esto no será posible en el futuro. Incluso en este momento puede ser complicado de ejecutar. Esto aumenta la importancia de herramientas como mydumper/myloader, ya que la copia de seguridad lógica será la única forma de migración. Lo que es bueno, MariaDB podrá poseer la estabilidad de su bifurcación de InnoDB:no tendrán que lidiar con los problemas introducidos por los desarrolladores ascendentes, por lo que podemos esperar que se introduzcan menos errores.
En cuanto al rendimiento, tenemos que esperar a los puntos de referencia, pero dados los datos históricos, podemos suponer que MariaDB será más lento que MySQL. En los puntos de referencia anteriores, lo que normalmente vemos es que el aumento del rendimiento de MariaDB se activa cuando se integra la versión más reciente de InnoDB. Este ya no será el caso, lo que nos hace preguntarnos cómo le irá a MariaDB en la comparación de rendimiento a partir de ahora y si las mejoras introducidas por MariaDB serán suficientes para mantenerse al día con MySQL 8.0 y versiones posteriores.
Para nosotros, los usuarios, todo esto significa que MariaDB 10.4 debería ser más estable que las versiones anteriores. También significa que eventualmente tendremos que aprender los aspectos internos de dos motores de almacenamiento diferentes, especialmente si nos preocupamos por el rendimiento. Esto está lejos de ser ideal, pero así son las cosas. Las herramientas deberán diseñarse para funcionar con una u otra versión de InnoDB (o se deberá agregar trabajo adicional para admitir MySQL y MariaDB). Estaremos atentos a cómo progresará esto. Cuando lo piensa, no es un movimiento tan sorprendente:MariaDB siempre tuvo que tomarse su tiempo para integrarse con la versión más reciente de InnoDB. Con más y más funciones incompatibles que se agregan a MariaDB y grandes cambios introducidos en MySQL 8.0, tiene sentido centrarse en desarrollar nuevas funciones en lugar de portar InnoDB incompatible desde MySQL ascendente.
Esperamos que esta breve publicación de blog le haya dado una idea de los cambios que afectarán a los sistemas de producción cuando vaya a MariaDB 10.4.
