Después de 10 años desde el lanzamiento de la rama 10.x, se presenta la versión 11.0.0 de la base de datos MariaDB, que ofrece varias mejoras significativas y cambios que rompen la compatibilidad. Esta rama todavía tiene la calidad de una versión alfa y estará lista para aplicaciones de producción después de un proceso de estabilización. Se espera que la siguiente rama importante de MariaDB 12, que contendrá cambios que rompen la compatibilidad, no esté disponible antes de 10 años (en 2032).
El proyecto MariaDB es una bifurcación de MySQL que busca mantener la compatibilidad hacia atrás y se distingue por la integración de motores de almacenamiento adicionales y capacidades ampliadas. El desarrollo de MariaDB es supervisado por la organización independiente MariaDB Foundation, siguiendo un proceso de desarrollo abierto y transparente que no depende de proveedores individuales. La base de datos MariaDB se incluye en muchos distribuidores de Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) y se ha implementado en importantes proyectos como Wikipedia, Google Cloud SQL y Nimbuzz.
Una mejora clave en la rama MariaDB 11 es la transición del optimizador de consultas a un nuevo modelo de costos, que proporciona una predicción más precisa de los costos de cada plan de ejecución de consultas. Aunque el nuevo modelo ayuda a eliminar algunas limitaciones de rendimiento, no se puede descartar que no sea óptimo en todos los escenarios, y podría haber una desaceleración en algunas consultas. Por lo tanto, se recomienda a los usuarios participar en las pruebas y notificar a los desarrolladores en caso de problemas.
El modelo previamente utilizado era adecuado para encontrar el índice óptimo, pero tenía problemas con la aplicabilidad de las operaciones de escaneo de tablas, escaneo de índices o extracción por rangos. En el nuevo modelo, esta desventaja se ha eliminado mediante el cambio del peso base de las operaciones con el motor de almacenamiento. Al evaluar el rendimiento de las operaciones que dependen de la velocidad de trabajo con el disco, como el escaneo secuencial de registros, ahora se supone que los datos se almacenan en un disco SSD que proporciona una velocidad de lectura de 400 MB por segundo. Además, se ha ajustado el resto de los parámetros de peso del optimizador, lo que, por ejemplo, ha permitido implementar la posibilidad de usar índices para las operaciones de "ORDER BY/GROUP BY" en subconsultas y acelerar el trabajo con tablas muy pequeñas.
Se observa que el nuevo modelo de pesos permitirá seleccionar un plan de ejecución de consulta más óptimo en las siguientes situaciones:
- Cuando se utilizan consultas que abarcan más de 2 tablas.
- Cuando hay índices que contienen un gran número de valores idénticos.
- Cuando se utilizan rangos que abarcan más del 10% de la tabla.
- Cuando hay consultas complejas en las que no todas las columnas utilizadas están indexadas.
- Cuando se utilizan consultas que involucran diferentes motores de almacenamiento (por ejemplo, cuando en una consulta hay referencias a tablas en los motores InnoDB y Memory).
- Cuando se usa FORCE INDEX para mejorar el plan de consulta.
- Cuando se deteriora el plan de consulta al usar "ANALYZE TABLE".
- Cuando la consulta abarca un gran número de tablas derivadas (un gran número de SELECT anidados).
- Cuando se utilizan expresiones ORDER BY o GROUP BY que caen bajo los índices.
Las principales violaciones de compatibilidad en la rama MariaDB 11:
- Los permisos SUPER ya no permiten realizar acciones que requieren privilegios otorgados por separado. Por ejemplo, para cambiar el formato de los registros binarios, se requerirán permisos de BINLOG ADMIN.
- Se ha eliminado la implementación del búfer de cambios en InnoDB.
- Se han declarado obsoletas innodb_flush_method y innodb_file_per_table.
- Se ha declarado obsoleta la compatibilidad con nombres mysql*.
- Se ha declarado obsoleta la configuración del parámetro explicit_defaults_for_timestamp en 0.
- Se han extraído los enlaces simbólicos en un paquete separado para compatibilidad con MySQL.
- El valor del parámetro innodb_undo_tablespaces por defecto se ha cambiado a 3.
Fuente: opennet.ru
