Tout en conservant le classique soubassement relationnel (à l'inverse des tentatives du mouvement NoSQL) ces nouveaux concurrents font le pari de l'ouverture et de la modernité par rapport à leurs prédécesseurs plus anciens.
Tout le monde le sait, le projet MySQL est actuellement dans l'expectative : le rachat de MySQL AB par Sun et le rachat de Sun par Oracle ont jeté un doute sur sa pérennité à long terme (voir cet article LWN et ses commentaires qui seront accessibles le jeudi 24). En outre, la qualité technique du code est remise en cause et les orientations futures sont incertaines. Comme MySQL reste toutefois le plus connu des SGBD libres, il n'est pas étonnant de constater que les nouveaux entrants, MariaDB et Drizzle, sont des rejetons de MySQL, qui cherchent à reprendre ce qu'il y a de mieux dans son code et à reconstruire un projet qui fédère une large communauté de développeurs.
Nous examinerons dans la suite de la dépêche ces deux projets et nous évaluerons leurs chance de s'imposer dans le monde très concurrentiel des gestionnaires de base de données. Place donc à MariaDB et à Drizzle. MariaDB
Le créateur du projet MariaDB n'est autre que Monty Widenius, l'homme qui est à l'origine de MySQL. Cela peut sembler un peu bizarre pour un fondateur de forker son propre projet mais il faut savoir que Monty n'est plus impliqué dans la vie de MySQL depuis longtemps. Après la création de MySQL AB, Monty a tout revendu à Sun et a lancé MariaDB dans la foulée. Pour l'anecdote Maria est la seconde fille de Monty alors que la première se nomme, vous l'aurez deviné, My.
L'idée avec MariaDB est de proposer une version complètement compatible avec MySQL qui est considéré comme l'upstream du projet. Le code de MariaDB sera périodiquement mis à jour avec le code upstream afin de récupérer les corrections de bugs et les nouveautés. Les versions de MariaDB suivent la numérotation de MySQL : On a ainsi MariaDB 5.1 qui se base sur MySQL 5.1 (et est donc placé sous la même licence GPLv2).
Pour les utilisateurs cette compatibilité est un atout puisque toutes les commandes et les interfaces sont les mêmes. Mais, quels sont alors les avantages à utiliser MariaDB au lieu de MySQL ?
Selon la FAQ comparative du projet, le principal changement est le moteur de base de données sous-jacent. MariaDB n'utilise pas MyISAM ni InnoDB et repose sur un moteur original nommé Maria conçu comme étant "crash safe" (restauration d'un état sain après un crash de l'application).
La version 1.5 du moteur Maria ne gère pas encore les transactions mais la version 2.0 (prévue pour MariaDB 6.0) atteindra la parité fonctionnelle complète avec InnoDB. Comme Maria peut également fonctionner en mode non transactionnel, il remplace aussi MyISAM.
Le code de MariaDB, tout en restant pleinement compatible avec l'upstream, a été également optimisé sur plusieurs points. Les requêtes complexes sont plus rapides et de nombreux cas d'interblocages sont corrigés.
Un réservoir de processus légers (thread pool), comme sur le futur MySQL 6.0, permet de se charger des requêtes de façon plus efficace.
MariaDB incorpore aussi directement les moteurs alternatifs XtraDB et PBXT ce qui offre un plus grand choix aux utilisateurs.
Monty Widenius souhaite qu'une communauté se forme autour du développement de MariaDB et encourage donc les contributions externes. Le projet dispose d'un site Launchpad et il suffit d'envoyer ses patchs sur la liste de diffusion et de convaincre un des "captains" de MariaDB pour voir son code accepté.
La principale force de MariaDB est donc d'être une version plus ouverte et plus communautaire de MySQL. Les divergences techniques sont transparentes pour l'utilisateur et la présence de Monty et d'autres anciens développeurs de MySQL ne peut que rassurer sur le plan technique.
Si Oracle décide un jour de jouer au plus fin avec MySQL alors MariaDB est bien placé pour reprendre le flambeau.
Drizzle
Le cas de Drizzle est un peu différent de celui de MariaDB, car les changements par rapport à MySQL sont bien plus radicaux. Le projet Drizzle a été lancé par Brian Aker en 2008, avec l'idée de faire une version allégée et plus rapide de MySQL. Brian était directeur de l'architecture chez MySQL AB et on peut penser qu'il avait donc une bonne connaissance des forces et des faiblesses du code quand il a pris la décision de forker à partir de la version de développement MySQL 6.0.
Drizzle repose sur l'idée d'un micro-noyau de base de données, au dessus duquel gravitent divers modules fonctionnels qui communiquent avec le micro-noyau via une API. Les développeurs espèrent ainsi obtenir un tout petit SGDB très optimisé qui sera à même de répondre aux besoins des applications réseaux ou de cloud computing et d'exploiter au maximum les architectures multi-cores. Comme le dit Brian dans son post d'annonce du projet : "Nous avons repris l'idée de Linux et d'Apache d'avoir un design modulaire".
Drizzle est placé sous licence GPLv2 (étant un fork de MySQL il n'y a pas le choix) et se conforme à la norme POSIX. Pour l'instant, il ne fonctionne que sur les plateformes UNIX (pas de compatibilité Windows pour le moment), mais des discussions sont en cours. Le code est écrit en C++, avec une grande attention portée à la propreté et la maintenabilité (usage de la STL) et à la réduction des goulets d'étranglement de l'architecture.
Évidemment, quand on a pour but d'alléger le code d'un vieux projet (Less code, more modularity), il faut choisir ce qu'on va enlever, ce qui n'est pas crucial et qui pourra être intégré plus tard sous forme de module externe. Voici donc ce qui change :
- Disparition des procédures stockées, des triggers et du cache des requêtes.
- Suppression du moteur MyISAM au profit exclusif d'InnoDB.
- Réécriture complète des vues avec une nouvelle architecture plus propre.
- Gestion de la réplication de façon modulaire en se basant sur le code Protocol Buffers de Google.
- Abandon du format de table .frm au profit, là aussi, d'une utilisation de la bibliothèque de sérialisation Protocol Buffers.
- Réduction des types d'objets, encodage de caractères uniquement en UTF-8, etc.
Bien entendu, le projet étant récent à l'échelle des exigences de stabilité des gestionnaires de base de données, il n'est pas encore conseillé de l'utiliser en production. Des snapshots de test sont régulièrement proposés sur le site launchpad du projet.
En résumé, Drizzle semble être un projet intéressant de rénovation complète de MySQL. Le design modulaire et l'attention portée aux performances sur les processeurs multi-coeurs lui assurent certainement un avenir brillant une fois que suffisamment de greffons externes seront disponibles et stabilisés.
Conclusions
Le point commun à ces deux projets alternatifs à MySQL est d'encourager plus franchement les contributions externes. Le développement de MySQL est vu comme trop fermé, trop corporate (allez donc voir le site officiel) et les choix effectués sont jugés peu transparents. Les deux challengers veulent changer cette situation.
Une attention plus grande est aussi portée aux bugs et aux régressions...du moins c'est ce qui est affirmé, il faudra vérifier avec le temps. La qualité du code de MySQL a été critiquée avec des arguments solides et les managers sont souvent pointés du doigts comme les vrais responsables de cet état de fait en fixant des objectifs de date sans tenir compte de l'avis des développeurs. MariaDB et Drizzle se veulent des méritocraties techniques non soumises aux desiderata absurdes d'un Pointy-Haired Boss.
Au niveau des critiques on peut toutefois relever plusieurs choses qui sont à garder à l'esprit si on veut utiliser ou contribuer à ces projets.
Tout d'abord, pour les contributeurs potentiels à MariaDB, il faut avoir conscience que leur code sera placé sous licence BSD ou bien qu'ils devront signer un accord qui donne un copyright complet et séparé aux deux parties. Pourquoi Monty Program AB, la société de Monty Widenius, n'accepte pas simplement les patchs externes sous GPLv2 ?
Pour Drizzle c'est la même chose (contributions externes sous BSD) ce qui est quelque peu incompréhensible. Tout changement de licence ultérieur est de toute façon impossible du fait du fork originel à partir d'un projet GPLv2 alors pourquoi utiliser obligatoirement la licence BSD pour les ajouts venant de l'extérieur ?
Ensuite, coté technique, MariaDB et Drizzle sont très jeunes et doivent encore faire leurs preuves avant d'être utilisés avec confiance en production. Le moteur Maria n'est pas complètement terminé et, coté Drizzle qui a choisi l'innovation technique, on en est encore à attendre la première version officielle qui sera de toute façon incomplète sans les indispensables greffons.
En dépit de ces réserves les deux projets constituent une avancée pour le libre et leur éventuel succès ne pourra que renforcer notre écosystème et offrir plus de choix aux utilisateurs.
Aller plus loin
- MariaDB (50 clics)
- Comparaison MariaDB/MysQL (91 clics)
- Drizzle (71 clics)
- Comparaison Drizzle/MysQL (60 clics)
# Belle dépêche
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 5.
Un petit truc m'étonne (Less code, more modularity)[...]Disparition des procédures stockées, des triggers et du cache des requêtes
Je ne suis pas un grand fan de l'implémentation de la logique métier en base de données mais faut avouer que les procédures stockées et triggers ont quand même une utilité (et son parfois le seul moyen disponible).
Pour ce qui est du cache de requêtes... ce n'est pas censé être quelque chose de cruciale pour les perfs ?
Alexandre COLLIGNON
[^] # Re: Belle dépêche
Posté par Brioche4012 (site web personnel) . Évalué à 2.
[^] # Re: Belle dépêche
Posté par patrick_g (site web personnel) . Évalué à 4.
Faudra voir les perfs de ce pari architectural quand même. Pour les OS ça n'a jamais vraiment marché (au sens de "ça n'a jamais vraiment apporté de truc qui fait la différence").
[^] # Re: Belle dépêche
Posté par Julien04 (site web personnel) . Évalué à 3.
[^] # Re: Belle dépêche
Posté par patrick_g (site web personnel) . Évalué à 6.
[^] # Re: Belle dépêche
Posté par cortex62 . Évalué à 3.
Que de chemin parcouru... et encore tant à faire.....
C' est une idée, et elle mérite de faire son chemin....Même s' il est court.
Va savoir....
[^] # Re: Belle dépêche
Posté par Gniarf . Évalué à 1.
[^] # Re: Belle dépêche
Posté par barret benoit . Évalué à 0.
[^] # Re: Belle dépêche
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Je dirais plutôt que si on a besoin de triggers et de procédures stockées, alors il vaut mieux utiliser PostgreSQL, et réserver MySQL ou ses dérivés pour des cas d'utilisation plus simples.
[^] # Re: Belle dépêche
Posté par __o . Évalué à 4.
Et la mise à jour d’une seule ligne d’une seule table invalide le cache de toutes les requêtes qui touchent un peu à cette table.
Du coup il n’est pas si efficace que ça et comme le problème d’invalidation est difficilement évitable on peut considérer que l’application sera en mesure de gérer le cache beaucoup mieux de son côté.
À un moment il était prévu de réintroduire quelque chose ressemblant à un cache de requêtes sous forme de greffon aussi, mais je ne sais pas si c’est toujours d’actualité.
[^] # Re: Belle dépêche
Posté par netsurfeur . Évalué à 4.
Comme souvent, la réponse est « ça dépend ».
Le cache n'est efficace que sur des tables fréquemment lues et rarement mises à jour. Dans le cas inverse, désactiver le cache peut améliorer les performances.
# Merci
Posté par Brioche4012 (site web personnel) . Évalué à 5.
# Fusion ?
Posté par vida18 . Évalué à 1.
[^] # Re: Fusion ?
Posté par Croconux . Évalué à 5.
# Prononciation
Posté par VoixOff . Évalué à 2.
On prononce comment Drizzle ?
[^] # Re: Prononciation
Posté par fleny68 . Évalué à 4.
[^] # Re: Prononciation
Posté par VoixOff . Évalué à 2.
[^] # Re: Prononciation
Posté par Sylvain Sauvage . Évalué à 2.
# Monty
Posté par fedorat . Évalué à 2.
[http://www.itrmanager.com/articles/98022/mariadb-nouvel-espo(...)]
Personnage attachant, nous avons bu ensemble, à la fin de sa prestation, une mixture alcoolisée au gout de réglisse. Il faut dire qu'il n'avait pas l'air au mieux de sa forme durant sa conférence.
Pour ceux que ça intéresse et pour archivage, voila un lien vers les photos que j'ai fait ce jour là :
[http://82.247.160.14/MONTY/]
Ce que je retiens de cette rencontre, c'est que cette homme est un passionné, que MySQL EST son enfant et qu'il n'acceptera jamais que celui-ci disparaisse ou soit malencontreusement 'oublié' par Oracle.
[^] # Re: Monty
Posté par vermillon . Évalué à 7.
Enfin comme le dit la dépêche, il a quand même vendu sa première fille à Sun et en a fait une deuxième!
==>[ ]
[^] # Re: Monty
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 2.
Alexandre COLLIGNON
[^] # Re: Monty
Posté par FantastIX . Évalué à 0.
Un pastaga, quoi?
[^] # Re: Monty
Posté par Antoine . Évalué à 6.
C'est pour ça qu'il l'a revendu ? Il se moque un peu du monde avec ses larmes de crocodile...
# Save mySQL
Posté par Cambien Cyril . Évalué à 1.
http://monty-says.blogspot.com/2009/12/help-saving-mysql.html
[^] # Re: Save mySQL
Posté par patrick_g (site web personnel) . Évalué à 4.
A garder à l'esprit donc....et article LWN à lire car très intéressant.
[^] # Re: Save mySQL
Posté par vjm . Évalué à 3.
De toute façon depuis les engagements pris par Oracle vis-à-vis de MySQL pour convaincre la Commission Européenne (et qui rompus risqueraient fort d'entraîner une action antitrust), les protestations de Monty sonnent de plus en plus creuses : http://www.oracle.com/us/corporate/press/042364
# Si je n'avais pas lu ce jounal...
Posté par Bruce Le Nain (site web personnel) . Évalué à 5.
Ça va me faire un sujet de discussion au repas de noël.
[^] # Re: Si je n'avais pas lu ce jounal...
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 7.
Alexandre COLLIGNON
[^] # Re: Si je n'avais pas lu ce jounal...
Posté par FantastIX . Évalué à 1.
Oui, enfin, même une dinde est malgré tout plus facile à placer dans un repas de Noël...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.