Une nouvelle branche significative de la base de données MariaDB 11 a été présentée.

Dix ans après la création de la branche 10.x, la version 11.0.0 de la base de données MariaDB a été publiée, proposant plusieurs améliorations et modifications significatives, affectant la compatibilité. La branche a actuellement une qualité alpha et sera prête pour des applications de production après stabilisation. La formation de la prochaine branche significative MariaDB 12, contenant des modifications affectant la compatibilité, n'est pas attendue avant 10 ans (en 2032).

Le projet MariaDB développe une dérivation de MySQL, qui conserve autant que possible la compatibilité rétroactive tout en intégrant des moteurs de stockage supplémentaires et des fonctionnalités avancées. Le développement de MariaDB est supervisé par l'organisation indépendante MariaDB Foundation, selon un processus de développement ouvert et transparent, sans dépendance à des fournisseurs spécifiques. La base de données MariaDB remplace MySQL dans de nombreuses distributions Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) et est intégrée dans de grands projets tels que Wikipedia, Google Cloud SQL et Nimbuzz.

L'amélioration clé de la branche MariaDB 11 est la transition de l'optimiseur de requêtes vers un nouveau modèle de coût (cost model), offrant une prédiction plus précise des coûts de chaque plan d'exécution de requête. Bien que le nouveau modèle permette de surmonter certains goulets d'étranglement en matière de performance, il se pourrait qu'il ne soit pas optimal dans tous les scénarios, et il est possible que certains requêtes soient ralenties. Les utilisateurs sont donc invités à participer aux tests et à informer les développeurs en cas de problèmes.

Le modèle précédemment utilisé était bien adapté pour trouver l'index optimal, mais présentait des problèmes d'applicabilité pour les opérations de scan de table, de scan d'index ou de sélection par plage. Dans le nouveau modèle, ce défaut a été corrigé grâce à un ajustement du poids de base des opérations avec le moteur de stockage. Lors de l'évaluation des performances des opérations dépendant de la vitesse d'accès au disque, telles que le scan séquentiel des enregistrements, on suppose maintenant que les données sont stockées sur un SSD, offrant une vitesse de lecture de 400 Mo par seconde. De plus, un réglage a été effectué sur d'autres paramètres de poids de l'optimiseur, permettant par exemple d'utiliser les index pour les opérations « ORDER BY/GROUP BY » dans des sous-requêtes et d'accélérer le travail avec des tables très petites.

Il est noté que le nouveau modèle de poids permettra de choisir un plan d'exécution de requête plus optimal dans les situations suivantes :

• Lors de l'utilisation de requêtes impliquant plus de 2 tables.
• Lorsqu'il existe des index contenant un grand nombre de valeurs identiques.
• Lors de l'utilisation de plages couvrant plus de 10 % de la table.
• Lors de la présence de requêtes complexes où toutes les colonnes utilisées ne sont pas indexées.
• Lorsqu'il existe des requêtes faisant appel à différents moteurs de stockage (par exemple, lorsqu'une requête accède à des tables dans les moteurs InnoDB et Memory).
• Lors de l'utilisation de FORCE INDEX pour améliorer le plan de requête.
• Lors de la dégradation du plan de requête en cas d'utilisation de « ANALYZE TABLE ».
• Lorsque la requête couvre un grand nombre de tables dérivées (un grand nombre de SELECT imbriqués).
• Lors de l'utilisation d'expressions ORDER BY ou GROUP BY qui sont couvertes par des index.

Les principales violations de compatibilité dans la branche MariaDB 11 :

• Les droits SUPER ne permettent plus d'effectuer des actions pour lesquelles des privilèges séparés sont requis. Par exemple, pour modifier le format des journaux binaires, des droits BINLOG ADMIN seront nécessaires.
• La mise en œuvre d'un tampon de changements dans InnoDB a été supprimée.
• innodb_flush_method et innodb_file_per_table ont été déclarés obsolètes.
• Le support des noms mysql* a été déclaré obsolète.
• Le paramètre explicit_defaults_for_timestamp ne peut plus être défini à 0.
• Les liens symboliques pour la compatibilité avec MySQL ont été déplacés vers un paquet séparé.
• La valeur par défaut du paramètre innodb_undo_tablespaces a été modifiée à 3.

Source : opennet.ru