À la mi-juin, MariaDB a présenté la disponibilité générale de MariaDB Community Server 10.6. Le peu de nouveautés révèle pour les équipes de l’éditeur la nécessité de changer de cycle de mise à jour.
Selon MariaDB, la version 10.6 est une itération majeure de l’édition communautaire de la base de données SQL. Max Mether, cofondateur et vice-président en charge des produits serveurs chez MariaDB Corporation, se veut plus prudent auprès du MagIT. « Nous ne pensions pas au départ disposer de caractéristiques réellement nouvelles à mettre en avant », confie le responsable.
« Les développeurs évoquaient des dettes techniques en interne. Nous avons beaucoup travaillé sur cet aspect qui n’est pas du tout visible dans la release note », ajoute-t-il.
Finalement, le communiqué de presse vante trois aspects principaux, c’est-à-dire le support de tables JSON, la compatibilité avec l’extension propriétaire PL/SQL d’Oracle et la prise en charge du langage DDL dans sa forme atomique.
Community Server 10.6 : à l’ouest, rien de nouveau ?
« Avec les tables JSON, nous complétons le support de ce format dans MariaDB », estime Max Mether. Cela n’a pourtant rien de nouveau dans ce SGBD. L’éditeur a lancé ce projet dans le cadre de la version 10.2 du Community Server, soit en avril 2016. « Un SGBDR est assez rigide. Cela permet d’apporter d’ajouter des attributs à une base de données relationnelle, donc de la flexibilité sans avoir à changer la structure », considère Max Mether.
En l’occurrence, MariaDB entend offrir la possibilité de créer une table à partir d’un string JSON, plus spécifiquement d’extraire des données de ce type dans une table relationnelle. « Ensuite, on peut traiter les strings JSON dans n’importe quelle requête SQL ».
De même, la prise en charge de PL/SQL est proposée depuis la version 10.3, dès 2017. « À l’origine, c’était un client, une banque à Singapour, qui souhaitait migrer des bases de données Oracle vers MariaDB, mais cette étape est complexe. Il avait 150 000 lignes de PL/SQL à convertir, il aurait fallu cinq ans pour le faire. Nous avons donc estimé que de développer un parser demanderait moins de temps », raconte Max Mether. Ce parser correspond à un mode SQL interchangeable afin de conserver les données en provenance de bases Oracle. « Nous avons greffé quelques fonctionnalités pour faciliter les migrations », assure le responsable.
Les ajouts autour du langage de définition des données (DDL) en mode atomique visent, eux, à assurer la reprise après panne. « Les transactions simples comme des changements dans les tables ne posaient pas de problème. En revanche, il n’y avait pas de règles très établies quand un crash avait lieu au moment de remplacer des données dans plusieurs tables à la fois », évoque Max Mether. Dans certains cas, la moitié des changements étaient validés, les autres, non. En 10.6, désormais, s’il y a un crash, soit la requête est complétée, soit les ajustements ne sont pas effectués sur les différents nœuds d’un serveur leader. Pour l’instant, cette fonctionnalité est prise en charge pour les moteurs de stockage InnoDB et Aria.
Un nouveau cycle de mise à jour à imaginer chez MariaDB
Cette faible quantité d’ajouts peut s’expliquer par le cycle de mise à jour de la version communautaire et la relation établie avec celui des versions entreprises (Enterprise Server et SkySQL). « Nous réalisons une mise à jour majeure par an », rappelle Max Mether. « Nous aimerions proposer plus régulièrement de nouvelles caractéristiques, accélérer notre rythme d’innovation. Il arrive que certaines capacités soient prêtes et qu’il faille attendre 11 mois avant de les proposer parce que la prochaine mise à jour est prévue l’année suivante », déplore-t-il.
Pour autant, Community Server 10.6 ne sera pas considéré comme stable avant trois ou quatre évolutions mineures, si l’on se réfère au calendrier habituel de l’éditeur, c’est-à-dire dans environ six mois.
« Nous comptons trouver un bon compromis entre une cadence accélérée et une fin de vie légèrement plus courte pour la version Community Server. »
Max MetherCofondateur et vice-président en charge des produits serveurs, MariaDB Corporation
MariaDB évalue la possibilité de réaliser des mises à jour trimestrielles ou semestrielles. « Nous sommes en train d’observer les différents modèles. Les versions entreprises et communautaires sont sensiblement différentes. Nous regardons de près l’approche du projet Fedora, où la version communautaire obtient plus rapidement les caractéristiques, mais n’est pas maintenue aussi longtemps que la version entreprise dont le cycle de mise à jour est plus lent », indique le cofondateur.
C’est ce type de changement que Red Hat a opéré avec le passage de CentOS Linux à CentOS Stream. Les utilisateurs reprochaient alors à la filiale d’IBM de ne plus vouloir proposer une version open source utilisable en production. « Nous ne souhaitons pas que la version communautaire soit expérimentale », prévient d’emblée Max Mether. « Nous comptons trouver un bon compromis entre une cadence accélérée et une fin de vie légèrement plus courte pour la version Community Server ».
Simplifier la transition entre les moteurs de stockage
Reste à savoir dans quels domaines MariaDB souhaite « innover ». Les autres éditeurs de bases de données SQL se penchent désormais sur l’apport de fonctionnalités inspirées par la blockchain. C’est le cas chez Oracle depuis la disponibilité d’Oracle 21c et chez Microsoft dans Azure SQL Database.
« Pour l’instant, nous avons été contactés par des sociétés éditrices de blockchain, mais nous n’avons pas trop vu l’intérêt. Les clients n’ont pas évoqué ce sujet », constate Max Mether.
La priorité de MariaDB, c’est de travailler sur l’adaptabilité de son SGBD. « Nous avons plusieurs moteurs de stockage, mais nous voulons que les utilisateurs et les clients puissent employer la même interface sans changer quoi que ce soit au niveau de l’application, au moment d’alterner entre un moteur ou un autre », indique le responsable. « En clair, nous souhaitons que des requêtes identiques s’exécutent avec des moteurs de stockage différents ». Cela demande de déplacer des caractéristiques contenues dans ces moteurs vers une couche supérieure indépendante.
« Nous n’avons pas de solutions de backups pour tous les moteurs de stockage. Nous voulons qu’une seule interface suffise pour gérer toutes les sauvegardes », illustre Max Mether.
Si la plupart des clients emploient un seul stockage à la fois par application, les gros usages en production réclament non pas de supporter plusieurs moteurs à la fois, mais « d’adoucir les transitions entre les moteurs ». « Il y a encore du boulot sur ce point », prévient Max Mether.
« Nous avons été un peu en retard concernant certaines fonctionnalités avancées de SQL, mais nous rattrapons les grands éditeurs », ajoute-t-il.
Le vice-président en charge des produits serveurs voit l’essor des bases de données distribuées. « Cela a commencé avec MongoDB, une base de données orientée documents, mais il y a de plus en plus de SBGD SQL distribués comme Snowflake, Yugabyte, Cockroach et les autres. Je pense qu’avec Xpand [un moteur de distribution de requêtes SQL, N.D.R.], nous sommes déjà prêts, mais l’usage va encore fortement progresser », anticipe le responsable.
Il faut dire que l’avenir des bases de données se joue dans les DbaaS. « Il n’y a quasiment pas de croissance sur site, tout se passe désormais dans le cloud », tranche Max Mether. « Cela nous pousse à proposer des fonctionnalités d’automatisation. Les bases de données sont déployées par les développeurs qui ne veulent pas connaître les milliers de paramètres à configurer. C’est un peu l’idée que nous avons avec SkySQL », ajoute-t-il.
