Se ha introducido una nueva rama importante del DBMS MariaDB 11

Diez años después de la fundación de la rama 10.x, se lanzó MariaDB 10, que ofreció varias mejoras y cambios importantes que rompieron la compatibilidad. La rama se encuentra actualmente en calidad de lanzamiento alfa y estará lista para su uso en producción después de la estabilización. Se espera que la próxima rama importante de MariaDB 11.0.0, que contenga cambios que rompan la compatibilidad, no antes de 12 años a partir de ahora (en 10).

El proyecto MariaDB está desarrollando una bifurcación de MySQL, manteniendo la compatibilidad con versiones anteriores siempre que sea posible y presentando la integración de motores de almacenamiento adicionales y capacidades avanzadas. El desarrollo de MariaDB es supervisado por la Fundación MariaDB independiente, siguiendo un proceso de desarrollo abierto y transparente que es independiente de los proveedores individuales. El DBMS MariaDB se suministra en lugar de MySQL en muchas distribuciones de Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) y se ha implementado en proyectos tan grandes 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 peso (modelo de costo), que proporciona una predicción más precisa de los pesos de cada plan de consulta. Si bien el nuevo modelo puede aliviar algunos cuellos de botella en el rendimiento, puede que no sea óptimo en todos los escenarios y puede ralentizar algunas consultas, por lo que se anima a los usuarios a participar en las pruebas y notificar a los desarrolladores si surgen problemas.

El modelo anterior era bueno para encontrar el índice óptimo, pero tenía problemas con la aplicabilidad de los escaneos de tablas, escaneos de índices u operaciones de búsqueda de rangos. En el nuevo modelo, este inconveniente se elimina cambiando el peso base de las operaciones con el motor de almacenamiento. Al evaluar el rendimiento de las operaciones que dependen de la velocidad del disco, como los escaneos de escritura secuencial, ahora asumimos que los datos se almacenan en un SSD que proporciona velocidades de lectura de 400 MB por segundo. Además, se ajustaron otros parámetros de peso del optimizador, lo que, por ejemplo, permitió implementar la capacidad de utilizar índices para operaciones "ORDER BY/GROUP BY" en subconsultas y acelerar el trabajo con tablas muy pequeñas.

Cabe señalar que el nuevo modelo de ponderación le permitirá elegir un plan de ejecución de consultas más óptimo en las siguientes situaciones:

  • Cuando se utilizan consultas que abarcan más de 2 tablas.
  • Cuando tiene índices que contienen una gran cantidad de valores idénticos.
  • Cuando se utilizan rangos que cubren más del 10% de la tabla.
  • Cuando tiene 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 una consulta accede a tablas en los motores InnoDB y Memoria).
  • Al utilizar FORCE INDEX para mejorar el plan de consulta.
  • Cuando el plan de consulta se deteriora al utilizar "ANALYZE TABLE".
  • Cuando la consulta abarca una gran cantidad de tablas derivadas (gran cantidad de SELECT anidados).
  • Cuando se utilizan expresiones ORDER BY o GROUP BY que se encuentran bajo índices.

Principales problemas de compatibilidad en la rama MariaDB 11:

  • Los derechos SUPER ya no le permiten realizar acciones para las cuales están disponibles privilegios establecidos por separado. Por ejemplo, para cambiar el formato de los registros binarios, necesitará derechos BINLOG ADMIN.
  • Se eliminó la implementación del búfer de cambios en InnoDB.
  • Innodb_flush_method e innodb_file_per_table han quedado obsoletos.
  • La compatibilidad con nombres MySQL* ha quedado obsoleta.
  • Establecer explicit_defaults_for_timestamp en 0 ha quedado obsoleto.
  • Los enlaces simbólicos se incluyen en un paquete separado para compatibilidad con MySQL.
  • El valor predeterminado del parámetro innodb_undo_tablespaces se ha cambiado a 3.

Fuente: opennet.ru

Añadir un comentario