{"id":106286,"date":"2022-12-28T15:36:45","date_gmt":"2022-12-28T13:36:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11"},"modified":"2022-12-28T15:36:45","modified_gmt":"2022-12-28T13:36:45","slug":"predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/predstavlena-novaya-znachitelnaya-vetka-subd-mariadb-11","title":{"rendered":"Se presenta una nueva versi\u00f3n significativa del SGBD MariaDB 11","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de 10 a\u00f1os desde el lanzamiento de la rama 10.x, se presenta la versi\u00f3n 11.0.0 de la base de datos MariaDB, que ofrece varias mejoras significativas y cambios que rompen la compatibilidad. Esta rama todav\u00eda tiene la calidad de una versi\u00f3n alfa y estar\u00e1 lista para aplicaciones de producci\u00f3n despu\u00e9s de un proceso de estabilizaci\u00f3n. Se espera que la siguiente rama importante de MariaDB 12, que contendr\u00e1 cambios que rompen la compatibilidad, no est\u00e9 disponible antes de 10 a\u00f1os (en 2032). <\/p>\n
El proyecto MariaDB es una bifurcaci\u00f3n de MySQL que busca mantener la compatibilidad hacia atr\u00e1s y se distingue por la integraci\u00f3n de motores de almacenamiento adicionales y capacidades ampliadas. El desarrollo de MariaDB es supervisado por la organizaci\u00f3n 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. <\/p>\n
Una mejora clave en la rama MariaDB 11 es la transici\u00f3n del optimizador de consultas a un nuevo modelo de costos, que proporciona una predicci\u00f3n m\u00e1s precisa de los costos de cada plan de ejecuci\u00f3n de consultas. Aunque el nuevo modelo ayuda a eliminar algunas limitaciones de rendimiento, no se puede descartar que no sea \u00f3ptimo en todos los escenarios, y podr\u00eda haber una desaceleraci\u00f3n en algunas consultas. Por lo tanto, se recomienda a los usuarios participar en las pruebas y notificar a los desarrolladores en caso de problemas. <\/p>\n
El modelo utilizado anteriormente era adecuado para encontrar el \u00edndice \u00f3ptimo, pero ten\u00eda problemas con la aplicabilidad de las operaciones de escaneo de tablas, escaneo de \u00edndices o selecci\u00f3n por rangos. En el nuevo modelo, esta desventaja se ha corregido 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 acceso al disco, como el escaneo secuencial de registros, ahora se asume que los datos se almacenan en unidades SSD que proporcionan una velocidad de lectura de 400 MB por segundo. Adem\u00e1s, se han ajustado otros par\u00e1metros de peso del optimizador, lo que, por ejemplo, permiti\u00f3 implementar la posibilidad de usar \u00edndices para operaciones \u00abORDER BY\/GROUP BY\u00bb en subconsultas y acelerar el trabajo con tablas muy peque\u00f1as. <\/p>\n
Se observa que el nuevo modelo de pesos permitir\u00e1 seleccionar un plan de ejecuci\u00f3n de consulta m\u00e1s \u00f3ptimo en las siguientes situaciones: <\/p>\n
\n
Cuando se utilizan consultas que abarcan m\u00e1s de 2 tablas.\n
Cuando hay \u00edndices que contienen un gran n\u00famero de valores id\u00e9nticos.\n
Cuando se utilizan rangos que abarcan m\u00e1s del 10% de la tabla.\n
Cuando hay consultas complejas en las que no todas las columnas utilizadas est\u00e1n indexadas.\n
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).\n
Cuando se usa FORCE INDEX para mejorar el plan de consulta.\n
En caso de deterioro del plan de consulta al utilizar \u00abANALYZE TABLE\u00bb.\n
Cuando la consulta abarca un gran n\u00famero de tablas derivadas (un gran n\u00famero de SELECT anidados).\n
Cuando se utilizan expresiones ORDER BY o GROUP BY que caen bajo los \u00edndices. <\/ul>\n
Las principales violaciones de compatibilidad en la rama MariaDB 11: <\/p>\n
\n
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\u00e1n permisos de BINLOG ADMIN.\n
Se ha eliminado la implementaci\u00f3n del b\u00fafer de cambios en InnoDB.\n
Se han declarado obsoletas innodb_flush_method y innodb_file_per_table.\n
Se ha declarado obsoleta la compatibilidad con nombres mysql*.\n
Se ha declarado obsoleta la configuraci\u00f3n del par\u00e1metro explicit_defaults_for_timestamp en 0.\n
Se han extra\u00eddo los enlaces simb\u00f3licos en un paquete separado para compatibilidad con MySQL.\n
El valor del par\u00e1metro innodb_undo_tablespaces por defecto se ha cambiado a 3. <\/ul>\n<\/ul>\n