Entretien avec Michael Widenius, fondateur de MySQL et MariaDB

Entretien avec Michael Widenius, fondateur de MySQL et MariaDB

MariaDB à l'assaut du monde

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

27/03/2013 7 minutes
71

Entretien avec Michael Widenius, fondateur de MySQL et MariaDB

En visite à Paris pour une importante conférence, le fondateur de MySQL et MariaDB, Michael Widenius, a répondu à nos questions. Création de MariaDB, protection du produit, volonté de ne pas reproduire le passé et arrivée du cloud sont autant de points que nous avons souhaité aborder.

mariadb

Au départ un simple fork de MySQL

MariaDB est un « fork » du système de gestion de bases de données (SGBD) MySQL. Son créateur, Michael Widenius (le plus souvent surnommé Monty) était également l’auteur de MySQL, et lorsque celui-ci fut racheté par Sun en janvier 2008 pour un milliard de dollars, Widenius travailla un temps pour la firme. Le 5 février 2009, il annonce sa démission et fondera peu après sa propre société, Monty Program AB.

 

Le Finlandais souhaitait alors reprendre le développement d’un SGBD dans la lignée de MySQL, Sun ayant été racheté entre temps par Oracle. Widenius a toutefois adopté un modèle particulier pour ses activités : la totalité du code source est sous licence GPL mais tout code produit par les développeurs tiers doit être validé par son entreprise pour garder une cohérence. Entreprise qui, par ailleurs, appartient à ses employés, Widenius n’ayant lui-même aucune part.

 

L’objectif de MariaDB est de progresser tout en gardant une compatibilité absolue avec MySQL. Cela comprend notamment une équivalence des bibliothèques, des API et des commandes. Une équivalence qui permet à MariaDB d’arriver comme remplaçant de MySQL sans nécessiter de trop grands travaux. Wikipedia a d’ailleurs franchi le pas en décembre 2012. D’autres sociétés ont également été séduites : Particuliers à Particuliers, Pierre et Vacances, Center Parc, Paybox ou encore la RTBF (Radio Télévision Belge Francophone).

 

Aujourd’hui aura également lieu une conférence durant laquelle de grands noms, intéressés par MariaDB, viendront prendre la température : les ministères de l’Industrie et de la Défense, l’ANSSI, Viadeo, la Fnac, l’UNESCO ainsi que plusieurs opérateurs tels que Free et Orange. À cette occasion, Michael Widenius est en visite à Paris et nous lui avons posé quelques questions au sujet de MariaDB.

Michael Widenius ne souhaite pas reproduire le passé 

michael wideniusInterrogé sur le pourquoi de MariaDB, Widenius explique qu’il a « travaillé sur le code de MySQL depuis 2001. Je ne voulais pas voir tout ce travail disparaître parce qu’il était tombé dans de mauvaises mains. C’est la première raison ». Et par mauvaises mains, il faut bien comprendre Sun et donc Oracle. Il poursuit : « Ensuite, nous ne voulions pas perdre les connaissances accumulées avec les années par le groupe constitué d’amis et de collègues. Nous sommes devenus proches et je connais certains depuis 1995 ».

 

Deux éléments qui sont donc « les raisons pour lesquelles MariaDB a été créé, au sein d’une entreprise possédée intégralement par les employés. Le but était également de ne pas reproduire le passé de MySQL. C’est pourquoi nous avons choisi l’open source et la licence GPL, car la seule raison à un arrêt du projet serait que l’on perde nos développeurs. »

 

Nous avons voulu en savoir davantage sur le côté open source justement, et comment MariaDB et MySQL s’échangeaient éventuellement des technologies et des fonctionnalités. La situation est en fait ici relativement à sens unique : « Nous réalisons une intégration une fois par mois pour que MariaDB soit toujours en phase avec MySQL. De manière basique, nous intégrons tout ce qu’ils proposent, et bien davantage. Ils ne prennent en revanche rien de nous, à l’exception de quelques éléments mineurs ».

 

Il y a bien entendu une raison logique à ceci : MySQL n’est plus un projet à 100 % open source car il est distribué sous une licence double. Michael Widenius indique à ce sujet : « Oracle ne peut pas prendre notre code car il est en GPL. MySQL n’est plus vraiment open source mais open core, et des fonctionnalités sont en sources fermées ».

Plusieurs défenses pour préserver le produit 

Mais finalement, comment MariaDB pourrait-il se défendre contre un avenir identique à celui de MySQL ? Widenius nous explique à ce propos que c’est précisément la raison pour laquelle l’entreprise Monty Program AB appartient à ses employés : pour éviter les offres agressives de rachat comme ce fut le cas avec MySQL. En outre, « MariaDB est sous licence GPL, et cela ne peut pas être changé ».


Une autre couche de protection a en outre été mise en place : « Même le nom du produit ne peut pas être changé, car nous avons créé la MariaDB Foundation qui protège justement tout ce qui est lié au projet ». En plus de protéger l’identité et le code source du projet, cette fondation assure également la promotion en étant la figure de proue de MariaDB, pour centraliser notamment les questions, les sponsors, ou encore pour vérifier que le produit reste dans sa ligne directrice.

 

L’impact de MariaDB actuellement sur le monde des bases de données est intéressant car il évolue rapidement et sur la base d’une vraie qualité selon Widenius. La migration de Wikipedia, nous précise-t-il, s’est faite très rapidement, mais il note surtout que l’encyclopédie en ligne utilisait une version de MySQL agrémentée de très nombreuses modifications pour optimiser les performances, réalisées en interne. Dans le cas de MariaDB, aucune modification n’a été réalisée, et c’est bien la version de base qui se trouve sur les serveurs.

La tâche d'huile des distributions Linux et le cloud 

Un autre changement important est désormais l’inclusion par défaut dans une partie des distributions Linux. C’est le cas en particulier d’OpenSuse, Mageia, Gentoo, Slackware ou encore Arch Linux. On trouve en outre le SGBD dans les dépôts de pratiquement toutes les autres, notamment Fedora et Ubuntu. Fedora 19 franchira d’ailleurs le pas de l’intégration en mai prochain lors de la sortie de la version 19.

 

Et en ce qui concerne le Cloud ? Selon les précisions de Widenius, MariaDB a bien des projets en ce sens, et il faut d’ailleurs considérer deux axes principaux. Le premier concerne les améliorations propres au SGBD, à commencer par l’extensibilité, autrement dit la capacité du produit à s’adapter automatiquement à une montée en charge. Un critère majeur dans le cloud puisque les services distants sont souvent utilisés par des dizaines, voire des centaines de milliers de postes clients en même temps.

 

L’autre axe concerne le choix de MariaDB par des fournisseurs d’instances dans le cloud tels que Microsoft et Amazon. Les deux proposent ainsi des instances MySQL, mais qu’en est-il de MariaDB ? Michael Widenius nous indique à ce sujet que des discussions sont ouvertes pour travailler sur ce point. Amazon en particulier s’appuie beaucoup sur les distributions Linux pour MySQL : « plus les distributions migreront vers MariaDB, plus vite Amazon le proposera ». Pour Widenius, cela ouvrirait d’ailleurs une nouvelle page de l’histoire du produit car une collaboration avec Amazon par exemple permettrait une meilleure optimisation pour le cloud.

 

Quoi qu’il en soit, le futur semble ouvrir ses bras à MariaDB et il n’est pas impossible que le produit ait totalement remplacé MySQL dans les années qui viennent. MariaDB se retrouvera progressivement en confrontation directe avec de gros produits tels qu’Oracle et SQL Server, mais également avec d’autres issus du monde open source, tels que Cassandra de la fondation Apache. Enfin, ceux qui se demandent pourquoi MariaDB s’appelle ainsi, sachez qu’il s’agit simplement du prénom de la plus jeune fille de Michael Widenius. La recette fut la même à l’époque de MySQL : My est le prénom de sa fille aînée, et il se prononce d’ailleurs « Mi ».

 

Sur le site officiel, on pourra télécharger la dernière version stable du produit.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Au départ un simple fork de MySQL

Fermer

Commentaires (71)


Moi qui croyais que Monty avait lancé Python <img data-src=" />


Merci pour cet article,

Je m’étais arrêté au lancement du projet et j’avais pas suivit depuis.

Du coup je vais regarder plus en détail.


Je n’avais jamais eu le temps de me pencher sur la question MariaDB, merci pour l’article Vincent, très instructif.


C’est quand même bête toute cette histoire… devoir repartir (pas de zéro heureusement) tout ça parce que la boîte d’origine a été rachetée… (mais alors pourquoi l’avoir laissé se faire acheter… peut-être qu’ils n’imaginaient pas Sun se ferait ensuite racheter par Oracle….? <img data-src=" /> )








philoxera a écrit :



Moi qui croyais que Monty avait lancé Python <img data-src=" />





<img data-src=" />







seb2411 a écrit :



Merci pour cet article,

Je m’étais arrêté au lancement du projet et j’avais pas suivit depuis.

Du coup je vais regarder plus en détail.





La même pour moi, c’est une très bonne chose ce qui se passe pour MariaDB. Le prochain SGBD que j’aurai à monter sera sûrement sous MariaDB :).









philoxera a écrit :



Moi qui croyais que Monty avait lancé Python <img data-src=" />





<img data-src=" />









philoxera a écrit :



Moi qui croyais que Monty avait lancé Python <img data-src=" />





<img data-src=" />









maxxyme a écrit :



C’est quand même bête toute cette histoire… devoir repartir (pas de zéro heureusement) tout ça parce que la boîte d’origine a été rachetée… (mais alors pourquoi l’avoir laissé se faire acheter… peut-être qu’ils n’imaginaient pas Sun se ferait ensuite racheter par Oracle….? <img data-src=" /> )









Vincent a écrit :



Widenius nous explique à ce propos que c’est précisément la raison pour laquelle l’entreprise Monty Program AB appartient à ses employés : pour éviter les offres agressives de rachat comme ce fut le cas avec MySQL.





<img data-src=" /> (après, je n’ai pas trouvé ous quel régime était l’“entreprise” MySQL)



Je pense que ce week-end ça va être transfère de MySQL vers MariaDB sur mon serveur.


Dommage pour le nom quand même <img data-src=" />








philoxera a écrit :



Moi qui croyais que Monty avait lancé Python <img data-src=" />







+1



Y a des distrib qui intègrent par défaut un SGBD ??? Vous êtes sur pour Gentoo ? Je ne connais pas trop les autres distrib mais Gentoo n’intègre quasiment rien par défaut…


Il est fou, l’monty !








maxxyme a écrit :



C’est quand même bête toute cette histoire… devoir repartir (pas de zéro heureusement) tout ça parce que la boîte d’origine a été rachetée… (mais alors pourquoi l’avoir laissé se faire acheter… peut-être qu’ils n’imaginaient pas Sun se ferait ensuite racheter par Oracle….? <img data-src=" /> )







Du blabla tout ça. C’est juste une question d’argent pis c’est tout.





l’inclusion par défaut dans une partie des distributions Linux. C’est le cas en particulier d’OpenSuse, Mageia, Gentoo, Slackware ou encore Arch Linux.



Pour Archlinux, la migration date d’avant-hier seulement. <img data-src=" />







c’est précisément la raison pour laquelle l’entreprise Monty Program AB appartient à ses employés : pour éviter les offres agressives de rachat





Et si Oracle (ou une autre entreprise) propose une forte somme d’argent à chaque employé de l’entreprise ? La « défense » de MariaDB tiendrait-elle longtemps ?








CryoGen a écrit :



Y a des distrib qui intègrent par défaut un SGBD ??? Vous êtes sur pour Gentoo ? Je ne connais pas trop les autres distrib mais Gentoo n’intègre quasiment rien par défaut…







Ça m’étonne un peu aussi, sauf peut-être avec un KDE qui demande un SGBD pour utiliser pleinement Akonadi.

Je pense que MariaDB est juste dispo dans les dépôts pour les distributions citées (parfois même à la place de MySQL).



Tfaçon, PostegreSQL, c’est plus mieux. <img data-src=" />








atem18 a écrit :



Tfaçon, PostegreSQL, c’est plus mieux. <img data-src=" />







+1 <img data-src=" />







DorianMonnier a écrit :



Ça m’étonne un peu aussi, sauf peut-être avec un KDE qui demande un SGBD pour utiliser pleinement Akonadi.

Je pense que MariaDB est juste dispo dans les dépôts pour les distributions citées (parfois même à la place de MySQL).







Ou alors c’est le choix par défaut quand un programme demande “mysql” en dépendance de proposer mariadb pour virtual/mysql si rien n’occupe encore cette place (Gentoo et il y a surement des équivalences pour les autres distrib). Si c’est çà la phrase de l’article est quand même très mal tournée <img data-src=" />









Skeeder a écrit :



Dommage pour le nom quand même <img data-src=" />







Peut être un fan de Mariah Carrey <img data-src=" />



Na sans de’c ça va niveau logeur, 5 caractère tout comme MySQL même si c’est peux commun.



J’attends de voir comment il sera intégré dans les autres logiciel et OS Linux une bonne alternative à MySQL si Oracle décide dans un futur d’une commercialisations des nouvelles fonctionnalités.



J’avais la perspective de faire un/des projet(s) perso pour me remettre dans le bain , du coup il faudrait passer à MariaDB et lâché MySQL que je connais assez bien ( si je fais qu’un projet ? ) pour le futur








atem18 a écrit :



Tfaçon, PostegreSQL, c’est plus mieux. <img data-src=" />





Oui pourquoi se tourner vers MySQL ou MariaDB alors qu’il y a la solution PostgreSQL ?

Trop de gens formé sur le couple PHP/MySQL ?









Sylvain_Blandel a écrit :



Pour Archlinux, la migration date d’avant-hier seulement. <img data-src=" />









Et si Oracle (ou une autre entreprise) propose une forte somme d’argent à chaque employé de l’entreprise ? La « défense » de MariaDB tiendrait-elle longtemps ?





L’entreprise tomberais mais jamais mariaDB ne serait aquis de cette façon licence GPL tout ça…









youtpout978 a écrit :



Trop de gens formé sur le couple PHP/MySQL ?







Ça, ça ne fait aucun doute. <img data-src=" />



Pour beaucoup, un site web, c’est forcément PHP & MySQL côté serveur.

Alors que bon, niveau stockage de données, y’a du choix entre tous les SGBD, les bases noSQL, les fichiers qui pourraient convenir dans pas mal de cas, etc.

Et niveau langage, des trucs comme Node.js, Django (Python), RoR (Ruby), etc. sont vraiment très intéressants.









philoxera a écrit :



Il est fou, l’monty !





<img data-src=" />







sniperdc a écrit :



Peut être un fan de Mariah Carrey <img data-src=" />

(…)





<img data-src=" />



ça y va <img data-src=" />









DorianMonnier a écrit :



Ça, ça ne fait aucun doute. <img data-src=" />



Pour beaucoup, un site web, c’est forcément PHP & MySQL côté serveur.

Alors que bon, niveau stockage de données, y’a du choix entre tous les SGBD, les bases noSQL, les fichiers qui pourraient convenir dans pas mal de cas, etc.

Et niveau langage, des trucs comme Node.js, Django (Python), RoR (Ruby), etc. sont vraiment très intéressants.







Django (+ south pour les migrations de models) + Postgresql <img data-src=" />



En tout cas PHP/MYSQL a vraiment occupé le terrain, au point que même les hébergeurs proposent directement php/mysql dans leurs offres… rare sont ceux proposant autre chose.









CryoGen a écrit :



Django (+ south pour les migrations de models) + Postgresql <img data-src=" />.







<img data-src=" /> <img data-src=" />



J’approuve totalement, Django m’a redonné goût au développement web ! <img data-src=" />





My est le prénom de sa fille aînée, et il se prononce d’ailleurs « Mi ».





<img data-src=" />



Ca c’est ZE révélation quand même ! Il ne faut pas dire “MaïeSQL” mais “MiSQL” !



Actu intéressante, ça fait plaisir de voir que le projet avance ! J’ai justement installé MariaDB hier sur mon Ubuntu <img data-src=" /> Mais il n’est pas encore proposé dans les paquets officiels, dommage.


Bon aller je me la claque un peu :

J’habite en Finlande et j’etudie l’informatique a Turku (5eme ville de Finlande)



Bref, tout ca pour dire qu’ici les informaticiens et les profs que j’ai rencontres sont super interesses par l’open source et meme les entreprises ouvrent leur code



Sinon,



My est le prénom de sa fille aînée, et il se prononce d’ailleurs « Mi ».



Je pense que c’est faux.

En Finnois, le “y” se prononce comme notre “u”..du coup la fille du gars doit s’appeler probablement “Mu” (en phonetique a la Francaise)

Mais bon j’peux me gourrer, particulirement si le gars est d’origine Suedoise (implique une prononciation different)








CryoGen a écrit :



Y a des distrib qui intègrent par défaut un SGBD ??? Vous êtes sur pour Gentoo ? Je ne connais pas trop les autres distrib mais Gentoo n’intègre quasiment rien par défaut…





C’est pas inclus dans l’install par défaut. <img data-src=" />

C’est sur les dépôts que tu trouves MariaDB… en unstable (tout comme mysql dans les versions récentes). <img data-src=" />









-DTL- a écrit :



C’est pas inclus dans l’install par défaut. <img data-src=" />

C’est sur les dépôts que tu trouves MariaDB… en unstable (tout comme mysql dans les versions récentes). <img data-src=" />







Oui je m’en doute bien, c’est l’article qui dit çà pas moi d’où mon interrogation…









philoxera a écrit :



Moi qui croyais que Monty avait lancé Python <img data-src=" />





<img data-src=" /><img data-src=" />



sinon c’est quoi les avantages de MariaDB car bon mysql a part être lourd c’est quand même très bien.



Si quelqu’un peut m’éclairer ?


J’avoue que j’ignorais totalement l’existence de MariaDB, merci. <img data-src=" />








elroy_INPACT a écrit :



sinon c’est quoi les avantages de MariaDB car bon mysql a part être lourd c’est quand même très bien.





Lourd ? Dans quel sens ?

Non parce que le principal reproche qui est fait à MySQL c’est d’exploser dès que les tables ont un nombre conséquent d’enregistrements (au dessus de quelques millions), mais la lourdeur… Lourdeur de quoi ? du code ? de l’exécution ?









elroy_INPACT a écrit :



sinon c’est quoi les avantages de MariaDB car bon mysql a part être lourd c’est quand même très bien.



Si quelqu’un peut m’éclairer ?







https://kb.askmonty.org/en/mariadb-versus-mysql-features/



Je m’y connais pas assez pour te décrire dans le détails les améliorations.









youtpout978 a écrit :



Oui pourquoi se tourner vers MySQL ou MariaDB alors qu’il y a la solution PostgreSQL ?

Trop de gens formé sur le couple PHP/MySQL ?





Et pourquoi se tourner vers PostgreSQL ? Je veux dire MySql fonctionne très bien. Du coup y’a pas forcement d’intérêt a changer. Surtout qu’une base de donnée c’est assez critique.









seb2411 a écrit :



Et pourquoi se tourner vers PostgreSQL ? Je veux dire MySql fonctionne très bien. Du coup y’a pas forcement d’intérêt a changer. Surtout qu’une base de donnée c’est assez critique.





Cas assez simple : t’es libraire et ton catalogue en ligne contient 15 millions ou plus de référence.

Un simple select et MySQL pleure.



Pour info Percona suit la même trajectoire… sauf qu’ils sont clairement pour un objectif commercial… mais ils intègrent régulièrement des ajouts faits côté MariaDB.

Personnellement, à mon travail, j’ai migré les MySQL vers Percona pour une raison très bête : ce sont les seuls à maintenir un repository à jour pour Centos/Redhat…








youtpout978 a écrit :



Oui pourquoi se tourner vers MySQL ou MariaDB alors qu’il y a la solution PostgreSQL ?

Trop de gens formé sur le couple PHP/MySQL ?







Je le pense en effet. Et je plussoie mes collegues inpactiens du haut, Django + South + PSQL m’a aussi redonné envie de faire du web.









tass_ a écrit :



Cas assez simple : t’es libraire et ton catalogue en ligne contient 15 millions ou plus de référence.

Un simple select et MySQL pleure.





Non enfin pas chez moi.









seb2411 a écrit :



Non enfin pas chez moi.





Vite publie, commit, fait des papiers alors ! Parce que c’est LE problème de TOUS les gros systèmes à base de MySQL et tu serais le seul à avoir trouvé LA solution, alors que depuis bien 5 ans tous les DT des SSII et des web agencies se cassent les dents sur le sujet ^^.









tass_ a écrit :



Cas assez simple : t’es libraire et ton catalogue en ligne contient 15 millions ou plus de référence.

Un simple select et MySQL pleure.





Comment faire Wikipédia avec des tables encore plus grosses. Puis même en postgre, j’ai une table avec 1,3 millions d’entrée, sur certains select je pleure aussi.









tass_ a écrit :



Vite publie, commit, fait des papiers alors ! Parce que c’est LE problème de TOUS les gros systèmes à base de MySQL et tu serais le seul à avoir trouvé LA solution, alors que depuis bien 5 ans tous les DT des SSII et des web agencies se cassent les dents sur le sujet ^^.





<img data-src=" /> J’ai déjà eu a traiter des champs de recherche rapide en mysql pour trouver des noms de villes sur une base de plus de 10.000.000 et j’avais pas de problème. Et je ne suis pas le seul sur la planète a traiter des base de données avec beaucoup d’enregistrement en Mysql. Et pourtant je suis pas un spécialiste SQL.



Ta remarque est d’autant plus idiote que le résultat va aussi dépendre du serveur que tu as derrière.









zefling a écrit :



Comment faire Wikipédia avec des tables encore plus grosses. Puis même en postgre, j’ai une table avec 1,3 millions d’entrée, sur certains select je pleure aussi.





Je suis pas vraiment spécialiste SGBD, je ne fais que les utiliser… POur wikipedia je cite l’article “mais il note surtout que l’encyclopédie en ligne utilisait une version de MySQL agrémentée de très nombreuses modifications pour optimiser les performances, réalisées en interne.”



J’ai pas trop testé PostGre en conditions réelles, les boîtes dans les quelles j’ai bossé / bosse ne sont pas chaudes pour faire la transition.







seb2411 a écrit :



<img data-src=" /> J’ai déjà eu a traiter des champs de recherche rapide en mysql pour trouver des noms de villes sur une base de plus de 10.000.000 et j’avais pas de problème. Et je ne suis pas le seul sur la planète a traiter des base de données avec beaucoup d’enregistrement en Mysql. Et pourtant je suis pas un spécialiste SQL.





Ha oui une simple recherche sur un champ texte… C’est pas souvent aussi simple hein… Quand t’as des données complexes et que tu fait des join de partout, là tu exploses.





seb2411 a écrit :



Ta remarque est d’autant plus idiote que le résultat va aussi dépendre du serveur que tu as derrière.





Sans blague ? La remarque était à serveur égal, ça allait de soi….



doublon








tass_ a écrit :



Ha oui une simple recherche sur un champ texte… C’est pas souvent aussi simple hein… Quand t’as des données complexes et que tu fait des join de partout, là tu exploses.





Oui oui mais ca c’est pareil partout si tu fais de grosses requêtes bien grasses faudra soit mettre de la puissance soit être patient. Je connais pas PostgreSql mais de que j’ai pu lire c’est pas forcement la référence niveau performances.







tass_ a écrit :



Sans blague ? La remarque était à serveur égal, ça allait de soi….





Tu as des Bench a montrer ?









seb2411 a écrit :



Oui oui mais ca c’est pareil partout si tu fais de grosses requêtes bien grasses faudra soit mettre de la puissance soit être patient. Je connais pas PostgreSql mais de que j’ai pu lire c’est pas forcement la référence niveau performances.





Ou mettre du Oracle (oui bon faudra augmenter la puissance aussi sûrement :p). Bizarre moi de ce que j’ai entendu de PostGre c’est que les performances étaient bien meilleures que MySQL pour les grosses tables.







seb2411 a écrit :



Tu as des Bench a montrer ?





Pas là non, mais je vais voir si y en a à la DT.









tass_ a écrit :



J’ai pas trop testé PostGre en conditions réelles, les boîtes dans les quelles j’ai bossé / bosse ne sont pas chaudes pour faire la transition.





Perso, je pensais faire la transition MySQL vers posgreSQL, mais quand j’ai vu qu’il fallait que je vois complètement certains trucs, j’ai abandonné. Trop long. En plus les perfs on sacrement augmenté j’ai l’impression.



http://blog.mariadb.org/mariadb-5-3-optimizer-benchmark/









tass_ a écrit :



Lourd ? Dans quel sens ?

Non parce que le principal reproche qui est fait à MySQL c’est d’exploser dès que les tables ont un nombre conséquent d’enregistrements (au dessus de quelques millions), mais la lourdeur… Lourdeur de quoi ? du code ? de l’exécution ?







lourd dans le sens ou cela consomme pas mal de ressource sur un serveur et aussi par rapport au table volumineuse.



Exemple tu as un petit vps ou raspberry pi bah mysql c’est la m* !!!

cela te bouffe trop de mémoire.

je testerai mariadb pour voir ce que cela vaut



Le 27/03/2013 à 16h 35

avec oracle ct couru d’avance. Bon, pour ma part, je préfère postgresql car en C. La contrepartie, hélas, est de perdre la GNU GPL.








tass_ a écrit :



Ou mettre du Oracle (oui bon faudra augmenter la puissance aussi sûrement :p). Bizarre moi de ce que j’ai entendu de PostGre c’est que les performances étaient bien meilleures que MySQL pour les grosses tables.





Perso j’ai pas trouve d’info vraiment intéressantes sur le sujet. Enfin des trucs récents. Et les trucs que j’avais pu lire c’est que PostgreSql a l’avantage niveau fonctionnalité mais perd l’avantage niveau performances face a MySql, mais ca commence a dater un peu. Donc je sais pas ce qu’il en est aujourd’hui.



Si on reprend l’article MariaDb pourrait être plus optimise a ce niveau ?



Mais encore une fois je vois pas d’avantage significatif de postgreSql par rapport a MariaDb. Après si c’est mieux niveau rapidité je suis preneur. Sachant que j’ai un forum a migrer avec une table de 1Go et 700.000 enregistrement qui me donne quelques sueurs froides.



Et Oracle mis a part se dire que c’est mieux parce que c’est Oracle y’a vraiment une différence ?







tass_ a écrit :



Pas là non, mais je vais voir si y en a à la DT.





Fait tourner ^^









tass_ a écrit :



Cas assez simple : t’es libraire et ton catalogue en ligne contient 15 millions ou plus de référence.

Un simple select et MySQL pleure.











tass_ a écrit :



Bizarre moi de ce que j’ai entendu de PostGre c’est que les performances étaient bien meilleures que MySQL pour les grosses tables.







Affirmer sur des bruits de couloir….

Je dev un site à très fort traffic dont la base MySQL (Percona - InnoDb) contient plusieurs très grosses tables dont une de plus de 100 Millions de rows, les requêtes sont instantanées (&lt;50ms) et ce avec des gros volumes d’insert/select.



Il ne risque pas un procès avec les brevets s’il “copie” MySQL ?








tass_ a écrit :



Je suis pas vraiment spécialiste SGBD, je ne fais que les utiliser… POur wikipedia je cite l’article “mais il note surtout que l’encyclopédie en ligne utilisait une version de MySQL agrémentée de très nombreuses modifications pour optimiser les performances, réalisées en interne.”



J’ai pas trop testé PostGre en conditions réelles, les boîtes dans les quelles j’ai bossé / bosse ne sont pas chaudes pour faire la transition.







Je ne connais pas trop Postgres mais j’ai une base de prod à mon taff qui tourne dessus.

Elle se prend en moyenne + 400k enregistrements par jours, on garde un historique de 3 mois (c’est un système de suivi d’activité applicative). Les select galèrent pas mal dès que la requête commence à avoir plusieurs critères de recherche (genre plage de date, champs textes…), pouvant durer jusqu’à 5 minutes lorsqu’on fait une assez grosse extraction de données.



Bon, la machine qui la fait tourner commence à accuser un petit âge (5 ans, sous Red Hat, un bi Xeon avec 6Go de RAM, disques SAN), la base et la config de Postgres a été revue pour les capacités du serveur. Je pense qu’il peut y avoir matière à optimiser encore un peu plus, que ce soit les schémas de base ou la config du serveur, mais j’avoue ne pas avoir de grande maitrise du produit.



La base est répliquée sur une autre en MySQL (c’est un bricolage pour effectuer des cartographies et analyses avec des données safes sans impacter la prod) et je trouve que les requêtes select avec pas mal de critères sont déjà plus véloces dessus, bien que ça mette quand même un peu de temps aussi (compter une à deux minutes max).

Sachant que ce serveur fait travailler également plusieurs autres bases MySQL (machine de supervision, elle collecte des données sur toutes les infras de notre périmètre). Certes la machine est plus récente et un poil plus performance (lame IBM HS22 avec 24Go de RAM et du bi Xeon), mais ce serveur est avant tout un ESX dédié à des VM de supervision et purement techniques, ce qui fait qu’au final notre VM sous Red Hat se rapproche du serveur physique en termes de capacité (elle a même moins de RAM dédiée, 4Go).



Donc de ma petite expérience avec Postgres versus MySQL, je serais tenté de dire que c’est kif kif…



C’est mon impression aussi mais je connais mal postgres.



une bd ne se résume pas des select simple. Les performances dépendent principalement des lock contention de toute manière.



En tant que repository, une base nosql tel que Riak (write optimisitc) ou newsql comme voltDb (single sequential writer) peut être très très intéressante



Oracle brille par trois choses choses. Son optimiseur, ses outils, et son prix. Son optimiseur est pafois hallucinant pour de grosses query très complexe et hétérogènes (fonction dans la where clause). Même si dans la 11 il part souvent en vrille, et ne prend pas en compte la probabilité que de données soient contiguës sur un segment, mais je m’égare… Oracle offre aussi plein d’options de gestion automatisé intéressant, les jobs, flashback, etc, et a des outils tel plsqldeveloper qui sont pas mal du tout. D’ailleurs plsql est LA raison qui rend oracle intéressant. Passablement d’entreprises ont des tonnes de règles de gestion dans du code plsql.



En mysql, c’est exclu. Une simple vue voit ses performances se dégrader avec le temps, les join imbriqué l’envoie au kansas, etc, etc, etc, et je parle pas même pas des procédures/fonctions T_T. Du coup, avec mysql, l’intelligence est en php/java. Et du coup l’intérêt d’avoir le modèle encré dans un schéma relationnel diminue fortement.



C’est d’ailleurs est une des raisons qui pousse les bases nosql, ou les objets sont inlinés (clé/valeur). L’autre raison c’est les lock contention, les bases nosql sont write optimisitic, autrement dit eventualy consistent, ce qui permet de sharder horizontalement sans risque de bottleneck sur un node et d’avoir un bon débit. Mais c’est aussi pour ça que la transition est extrêmement compliquée, et a ne faire qu’avec grande parcimonie depuis une architecture conventionnelle, pour les grosses tables contenant des blobs et images.



Personnellement, je ne jure plus que par Datomic, une base immutable, sans structure (tag sur les atoms, stou), et “newsql”, même si beaucoup de chemin reste à faire.



mais bref, je me suis égaré dans mon égarement. MySql vs MariaDb? MariaDb all the way. MySql a plus de route, et google vous sort de presque toute les situations, mais Maria est largement plus développé aujourd’hui, mysql se meurt à petit feu, et au fur et à mesure que les grands comptes se passent de mysql, les améliorations vont diminuer. Mais pour un site web basique, hosté gratuitement ou presque, mysql fait très bien l’affaire.








kochka22 a écrit :



Affirmer sur des bruits de couloir….

Je dev un site à très fort traffic dont la base MySQL (Percona - InnoDb) contient plusieurs très grosses tables dont une de plus de 100 Millions de rows, les requêtes sont instantanées (&lt;50ms) et ce avec des gros volumes d’insert/select.







Ouais mais lui il bosse avec un eZPublish, hors les requêtes d’eZ c’est à base de temporary table et de grosses jointures bien grasses dans tous les sens… et ça sur des tables un tant soit peu conséquentes, mySQL aime pas, mais alors pas du tout… particulièrement sur les sites à fort trafic, y compris avec un très gros serveur dédié à ça et un admin compétent.



et histoire de relancer le débat sur postgres :http://www.postgresql.org/about/



voilà voilà, les connaisseurs pourront comparer avec My/Maria.



question eau que je peux apporter au moulin, dans un projet qui remonte à plus de cinq ans, mysql ne tenait pas la comparaison face à postgres sur une base de quelques millions de lignes. et PG était plus intéressant en termes de features aussi (m’enfin il manquait la réplication gérée en interne quand meme à l’époque ^^‘).



C’était comme ça pour My/PG dans ce cas particulier à ce moment particulier, et je n’ai aucune idée de comment tout ce petit monde a bien progressé de son coté. Et les DB j’en mange un peu mais c’est pas vraiment mon rayon préféré.


et histoire de relancer le débat sur postgres :http://www.postgresql.org/about/



voilà voilà, les connaisseurs pourront comparer avec My/Maria.



question eau que je peux apporter au moulin, dans un projet qui remonte à plus de cinq ans, mysql ne tenait pas la comparaison face à postgres sur une base de quelques millions de lignes. et PG était plus intéressant en termes de features aussi (m’enfin il manquait la réplication gérée en interne quand meme à l’époque ^^‘).



C’était comme ça pour My/PG dans ce cas particulier à ce moment particulier, et je n’ai aucune idée de comment tout ce petit monde a bien progressé de son coté. Et les DB j’en mange un peu mais c’est pas vraiment mon rayon préféré.


Le 27/03/2013 à 22h 00







zefling a écrit :



Comment faire Wikipédia avec des tables encore plus grosses. Puis même en postgre, j’ai une table avec 1,3 millions d’entrée, sur certains select je pleure aussi.







La ça devient sur du NoSQL qu’il faut se tourner pour les BDD giganstesques



et histoire de relancer le débat sur postgres :http://www.postgresql.org/about/



voilà voilà, les connaisseurs pourront comparer avec My/Maria.



question eau que je peux apporter au moulin, dans un projet qui remonte à plus de cinq ans, mysql ne tenait pas la comparaison face à postgres sur une base de quelques millions de lignes. et PG était plus intéressant en termes de features aussi (m’enfin il manquait la réplication gérée en interne quand meme à l’époque ^^‘).



C’était comme ça pour My/PG dans ce cas particulier à ce moment particulier, et je n’ai aucune idée de comment tout ce petit monde a bien progressé de son coté. Et les DB j’en mange un peu mais c’est pas vraiment mon rayon préféré.


err37


err37


Au passage je viens de voir le passage à MariaDB depuis MySql ça à l’air assez transparent.








philoxera a écrit :



Moi qui croyais que Monty avait lancé Python <img data-src=" />





<img data-src=" />



S’il suffit d’un bête /export/ d’un côté, et d’une importation de l’autre pour migrer .. ça va se faire de mon côté je pense








roselan a écrit :











Merci pour les infos. <img data-src=" />







Par contre j’avais pas fait attention au logo… Si MySQL tire son nom de sa première fille, le logo en dauphin signifie-t-il qu’il la voit comme tel ?

Que penser de Maria qu’il voit comme une otarie ? <img data-src=" /><img data-src=" />









Fuinril a écrit :



Ouais mais lui il bosse avec un eZPublish, hors les requêtes d’eZ c’est à base de temporary table et de grosses jointures bien grasses dans tous les sens… et ça sur des tables un tant soit peu conséquentes, mySQL aime pas, mais alors pas du tout… particulièrement sur les sites à fort trafic, y compris avec un très gros serveur dédié à ça et un admin compétent.





Ezpublish c’est pas le pire encore, dans le genre y a Magento (ecommerce) aussi… Qui fait des requêtes qui tiennent pas sur 2 pages A4…

Et oui les temporary tables ça aide pas en plus des joins de porcs.









tass_ a écrit :



Ezpublish c’est pas le pire encore, dans le genre y a Magento (ecommerce) aussi… Qui fait des requêtes qui tiennent pas sur 2 pages A4…

Et oui les temporary tables ça aide pas en plus des joins de porcs.







<img data-src=" />



Pas d’accord, hasard : je suis en train de monter un site sous Magento. Bon c’est des grosses requêtes mais rien à voir avec eZ, une requête basée sur une collection d’EAV avec beaucoup de critères c’est 4-5 lignes max.



A noter que j’en avais fait y a quelques années et que j’en conservais effectivement un souvenir de bouzin lourdingue, là je suis heureusement étonné : c’est bien plus léger et manipulable que dans mes souvenirs (ça reste lourd ceci étant).









Fuinril a écrit :



<img data-src=" />



Pas d’accord, hasard : je suis en train de monter un site sous Magento. Bon c’est des grosses requêtes mais rien à voir avec eZ, une requête basée sur une collection d’EAV avec beaucoup de critères c’est 4-5 lignes max.



A noter que j’en avais fait y a quelques années et que j’en conservais effectivement un souvenir de bouzin lourdingue, là je suis heureusement étonné : c’est bien plus léger et manipulable que dans mes souvenirs (ça reste lourd ceci étant).





Hum tu as quelle version de magento aussi ? On n’est pas sur la dernière ici (en plus il est “injecté” dans eZ par des blocs ESI, je t e laisse imaginer :p).









tass_ a écrit :



Hum tu as quelle version de magento aussi ? On n’est pas sur la dernière ici (en plus il est “injecté” dans eZ par des blocs ESI, je t e laisse imaginer :p).





Pareil, je bosse aussi sur du Magento et c’est louuuuuuuuuuuuuuuuurd.