MariaDB 11 est déjà sortie et voici ses nouveautés

MariaDB 11

MariaDB 10.0.0 est sortie il y a plus de dix ans (12 novembre 2012)

10 ans après la création de la branche 10.x, enfin la nouvelle version et branche de MariaDB 11.0.0 a été publiée, qui apporte plusieurs améliorations importantes et rompt les changements de compatibilité.

MariaDB 11 est déjà sorti et ce sont ses nouvelles et il sera prêt pour une utilisation en production après stabilisation. La prochaine branche importante de MariaDB 12, contenant des changements qui rompent la compatibilité, devrait avoir au plus tôt 10 ans (en 2032).

Pour ceux qui ne connaissent pas le projet MariaDB, sachez que il développe un fork de MySQL qui maintient la rétrocompatibilités dans la mesure du possible et se distingue par l'intégration de moteurs de stockage supplémentaires et de fonctionnalités avancées.

Le développement de MariaDB est supervisée par la fondation indépendante MariaDB, suivant un processus de développement ouvert et transparent indépendant des fournisseurs individuels. MariaDB est livré à la place de MySQL sur de nombreuses distributions Linux.

Principales nouveautés de MariaDB 11

Dans cette nouvelle version de MariaDB 11, l'une des principales améliorations de la branche est la traduction de l'optimiseur de requête à un nouveau modèle de pondération (modèle de coût), qui fournit une prédiction plus précise des poids de chaque plan d'exécution de requête. Bien que le nouveau modèle supprime certains goulots d'étranglement de performances, il peut ne pas être optimal dans tous les scénarios et certaines requêtes peuvent ralentir, les utilisateurs sont donc encouragés à participer aux tests et à informer les développeurs en cas de problème.

Le modèle ci-dessus a bien fonctionné pour trouver l'indice optimal, mais avait des problèmes avec l'applicabilité des analyses de table, des analyses d'index ou des recherches de plage. Dans le nouveau modèle, cet inconvénient est éliminé en modifiant le grammage des opérations avec le moteur de stockage.

évaluations des performances pour les opérations gourmandes en disque telles que les analyses d'écriture séquentielles, maintenant, ils supposent que les données sont stockées sur un SSD avec une capacité de lecture de 400 Mo par seconde. De plus, d'autres paramètres de poids de l'optimiseur ont été affinés, ce qui a permis par exemple d'implémenter la possibilité d'utiliser des index pour les opérations "ORDER BY/GROUP BY" dans les sous-requêtes et d'accélérer le travail avec de très petites tables.

Une autre nouveauté qui se démarque est que le nouveau modèle de pondération permettra de choisir un plan d'exécution de requête plus optimal dans les situations suivantes :

  • Lors de l'utilisation de requêtes qui s'étendent sur plus de 2 tables.
  • Lorsqu'il existe des indices qui contiennent un grand nombre de valeurs identiques.
  • Lorsque vous utilisez des plages qui couvrent plus de 10 % de la table.
  • Lorsque vous avez des requêtes complexes où toutes les colonnes utilisées ne sont pas indexées.
  • Lors de l'utilisation de requêtes impliquant différents moteurs de stockage (par exemple, lorsqu'une requête contient un accès aux tables des moteurs InnoDB et Mémoire).
  • En utilisant FORCE INDEX pour améliorer le plan de requête.
  • Lorsque le plan de requête est déclassé dans le cas de l'utilisation de "ANALYZE TABLE".
  • Lorsque la requête s'étend sur un grand nombre de vues (grand nombre de SELECT imbriqués).
  • Lors de l'utilisation de clauses ORDER BY ou GROUP BY qui correspondent à des index.

De la part de rupture de compatibilité Dans cette nouvelle version de MariaDB 11, les breaks suivants que l'on retrouvera dans cette nouvelle branche sont mentionnés :

  • Les droits SUPER ne vous permettent plus d'effectuer des actions pour lesquelles des privilèges définis séparément sont disponibles. Par exemple, changer le format des journaux binaires nécessitera les droits BINLOG ADMINISTRATOR.
  • Suppression de l'implémentation du tampon de modification dans InnoDB.
  • innodb_flush_method et innodb_file_per_table obsolètes.
  • La prise en charge des noms mysql* est obsolète.
  • Définition obsolète de explicit_defaults_for_timestamp sur 0.
  • Les liens symboliques ont été déplacés vers un package séparé pour la compatibilité avec MySQL.
  • La valeur du paramètre innodb_undo_tablespaces est passée de la valeur par défaut à 3.

Enfin si vous souhaitez en savoir plus à propos de cette nouvelle version, vous pouvez vérifier les détails dans le lien suivant


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.