MariaDB et Drizzle : Pour repartir sur de bonnes bases !

Posté par (page perso) . Modéré par Nÿco.
Tags : aucun
33
21
déc.
2009
Base de données
Alors que le paysage des logiciels libres de gestion de base de données est souvent réduit à MySQL et PostgreSQL, de nouveaux entrants innovants tentent d'émerger.
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 :D'après l'avis de nombreux participants au projet, ce qui change le plus par rapport à MySQL est le degré d'ouverture du projet et son refus de critères extra-techniques pour prendre les décisions. Plus d'assignation de copyright, acceptation rapide des patchs externes (placés sous licence BSD par défaut), ferme de test accessible, tout warning est considéré comme un bug et toute régression doit être corrigée avant d'autoriser un seul nouveau commit.
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.
  • # Belle dépêche

    Posté par (page perso) . Évalué à 5.

    En voilà une belle dépêche ! <- serais je le premier à le dire sur celle ci ?

    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 (page perso) . Évalué à 2.

      Je n'ai pas trouvé d'informations plus détaillées, mais vu l'approche du projet, on peut estimer que les triggers et procédures n'ont à priori rien à faire dans un noyau de base de données. Peut être que c'est là la raison de ce retrait.
      • [^] # Re: Belle dépêche

        Posté par (page perso) . Évalué à 4.

        A priori ce sera réintroduit mais sous forme de greffon externe par dessus le micro-noyau.
        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 (page perso) . Évalué à 3.

          tu sous entends que hurd apporte rien ? ;-)
          • [^] # Re: Belle dépêche

            Posté par (page perso) . Évalué à 6.

            Faudra voir quand la version 1.0 sera dispo :-)
            • [^] # Re: Belle dépêche

              Posté par . Évalué à 3.

              oui, patrick, soit pas vache quand même. je (on) sais que c'est pas gagné , mais quand même.... il y a de l'espoir... et il faut le garder...... quand linux 1.0 est sorti y avait il vraiment un espoir ...
              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 . Évalué à 1.

                faites comme KDE, sortez une version $n.0 pas bien démoulée du tout, personne ne s'en apercevra et tout le monde applaudira, promis !
              • [^] # Re: Belle dépêche

                Posté par . Évalué à 0.

                <?troll aaah les vaporware comme hurd...?>
      • [^] # Re: Belle dépêche

        Posté par (page perso) . Évalué à 4.

        Je n'ai pas trouvé d'informations plus détaillées, mais vu l'approche du projet, on peut estimer que les triggers et procédures n'ont à priori rien à faire dans un noyau de base de données. Peut être que c'est là la raison de ce retrait.

        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 . Évalué à 4.

      Le cache de requêtes a pas mal de problèmes: lock contention assez important (il doit y avoir un verrou global interdisant plus d’un accès à la fois), fragmentation de la mémoire, etc.

      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 . Évalué à 4.

      Pour ce qui est du cache de requêtes... ce n'est pas censé être quelque chose de cruciale pour les perfs ?

      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 (page perso) . Évalué à 5.

    Un grand merci pour cette dépêche. C'est une bonne nouvelle de savoir que le futur est assuré quand au maintient de SGBD compatible avec MySQL. Le rachat par Oracle faisait un peu épée de Damoclès quand même.
  • # Fusion ?

    Posté par . Évalué à 1.

    Peut-être qu'il y aura une fusion de MariaDB et Drizzle ? Après tout, l'union fait la force.
    • [^] # Re: Fusion ?

      Posté par . Évalué à 5.

      Je n'y crois pas trop. Les deux semblent avoir des buts complètement opposés. MariaDB vise à supporter tout ce que supporte MySql avec quelques plus, Drizzle supprime du code pour obtenir un mini serveur plus léger.
  • # Prononciation

    Posté par . Évalué à 2.

    Super niouze :-)

    On prononce comment Drizzle ?
  • # Monty

    Posté par . Évalué à 2.

    J'ai rencontré Monty lors du dernier forum PHP. J'ai enregistré l'interview effectué par ma copine et dont la transcription se trouve ici :

    [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 . Évalué à 7.

      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.

      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 (page perso) . Évalué à 2.

      Je pensai au moins voir ta copine l'interviewer. La déception est grande. Snif snif

      Alexandre COLLIGNON

    • [^] # Re: Monty

      Posté par . Évalué à 0.

      nous avons bu ensemble [...] une mixture alcoolisée au gout de réglisse

      Un pastaga, quoi?
    • [^] # Re: Monty

      Posté par . Évalué à 6.

      c'est que cette homme est un passionné, que MySQL EST son enfant et qu'il n'acceptera jamais

      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 . Évalué à 1.

    Lire l'appel à l'aide de Monty pour sauver mySQL


    http://monty-says.blogspot.com/2009/12/help-saving-mysql.html
    • [^] # Re: Save mySQL

      Posté par (page perso) . Évalué à 4.

      Dans l'article LWN que je donne en lien dans la news (et qui sera accessible jeudi) plusieurs commentateurs critiquent la position de Monty et notamment se demande de passer MySQL en BSD. Plusieurs personnes pensent qu'il ne demande ça que pour pouvoir faire des extensions sous double licence GPL-Proprio (comme il l'avait fait au temps de MySQL AB).
      A garder à l'esprit donc....et article LWN à lire car très intéressant.
      • [^] # Re: Save mySQL

        Posté par . Évalué à 3.

        L'origine des critiques est probablement le document que Monty a envoyé à la Commission Européenne au début du mois dans le cadre de l'évaluation qu'elle fait de la fusion Oracle-Sun. Groklaw en a fait une analyse peu flatteuse : http://www.groklaw.net/article.php?story=20091208104422384

        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 (page perso) . Évalué à 5.

    ...je n'aurais jamais su que My était en fait un prénom.
    Ça va me faire un sujet de discussion au repas de noël.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.