Performances compar´ees de MySQL et

Le seul test de vitesse Open Source que nous connaisssons et qui peut ˆetre utilis´e pour tester les performances de MySQL et de PostgreSQL (et d’autres bases de donn´ees) est le nˆotre. Il est disponible `a l’adresse http://www.mysql.com/information/benchmarks.html. Nous avons demand´e de nombreuses fois aux d´eveloppeurs de PostgreSQL et aux utilisateurs de PostgreSQL de nous aider `a d´evelopper et am´eliorer ce test, pour en faire le meilleur test possible, mais nous n’avons pas re¸cu de r´eponse de leur part.

Nous, les d´eveloppeurs MySQL, avons, `a cause de cela, pass´e de nombreuses heures `a obtenir les meilleures performances de PostgreSQL pour ces tests, mais comme nous ne connaissons pas intimement le serveur PostgreSQL, nous sommes certains d’ˆetre pass´e `a cot´e de certains points. Sur la page de test, nous avons document´e exactement comment nous avons ex´ecut´e le test, pour qu’il soit facile `a tout le monde de reproduire et de confirmer nos r´esultats. Les tests sont g´en´eralement ex´ecut´es avec et sans l’option --fast. Lorsque l’option --fast est utilis´ee, nous tentons d’utiliser tous les trucs connus du serveur pour que l’ex´ecution soit aussi rapide que possible. L’id´ee est que le mode normal doit montrer comment le serveur devrait se comporter avec une configuration normale, et le mode --fast montre comment le serveur se comporte si le d´eveloppeur utilise toutes les extensions du serveur pour acc´el´erer son application.

Lorsque nous ex´ecutons PostgreSQL avec l’option --fast, nous ex´ecutons la commande VACUUM apr`es chaque modification importante de la table, et apr`es l’effacement de ta- ble, pour conserver la base dans un ´etat parfait pour les prochaines s´elections. Le temps n´ecessaire `a l’ex´ecution de la commande VACUUM est mesur´e s´epar´ement.

Lorsque PostgreSQL 7.1.1 fonctionne, nous n’avons pu le faire fonctionner avec l’option --fast car durant les test d’INSERT, le postmaster (d´emon PostgreSQL) s’est arr´et´e, et la base ´etait tellement corrompue qu’il a ´et´e impossible de red´emarrer le postmaster. Apr`es un deuxi`eme probl`eme identique, nous avons d´ecid´e de reporter les tests --fast jusqu’`a la prochaine version de PostgreSQL. Les d´etais sur la machine avec laquelle nous avons ex´ecut´e les tests sont disponible sur la page de tests.

Avant de passer aux autres tests de performances que nous connaissons, nous souhaitons vous donner des d´etails sur le contexte des tests.

Il est tr`es facile d’´ecrire un test qui montre que toutes les bases du monde sont les meilleures, en se limitant simplement aux points forts de la base, et en ne testant rien qui soit une faiblesse. De plus, si la conclusion se ram`ene `a un seul chiffre, c’est encore plus facile. Cela revient `a mesurer la vitesse de MySQL par rapport `a PostgreSQL en regardant sim- plement les temps moyens des tests de MySQL sur notre page. En se basant sur ces informations, notre serveur MySQL serait 40 fois plus rapide que PostgreSQL, ce qui est, bien sˆur, faux. Nous pourrions mˆeme rendre les choses encore pires en prenant les tests o`u PostgreSQL a les pires performances, et dire que MySQL est plus de 2000 fois plus rapide que PostgreSQL.

Le fait est que MySQL fait un certain nombre d’optimisation que PostgreSQL ne fait pas. C’est aussi vrai, bien sˆur, dans le sens inverse. Un optimiseur SQL est un programme complexe, et une compagnie peut passer des ann´ees `a le rendre de plus en plus rapide. Lorsque vous regardez les r´esultats des tests, vous devriez vous limiter aux op´erations que vous utilisez dans votre application, et utiliser simplement ces r´esultats pour d´ecider quelle

base de donn´ees est la plus adapt´ee `a vos besoins. Les r´esultats de tests vous montrent quelles op´erations sont le point faible de chaque base, et vous donnent des indications sur ce qu’il faudra ´eviter de faire.

Nous connaissons deux tests de performances qui indiquent que PostgreSQL est plus rapide que MySQL. Ces deux tests sont faits dans un environnement multi-utilisateur, un test que nous, chez MySQL AB, nous n’avons pas eu le temps de mettre en place car c’est une tˆache ´enorme de le faire pour que ce soit ´equitable pour chaque base.

Le premier est le test payant, effectu´e pour Great Bridge, une entreprise qui a tent´e durant 16 mois de bˆatir un mod`ele d’affaires avec PostgreSQL mais qui a d´esormais cess´e les op´erations. C’est probablement le pire test que nous ayons jamais vu. Non seulement ce test ´etait bˆati pour ne tester que les points forts de PostgreSQL, mais il ´etait totalement d´eloyal pour toutes les autres bases de donn´ees utilis´ees dans le test.

Note : nous savons aussi que mˆeme certains des d´eveloppeurs principaux de PostgreSQL n’ont pas aim´e la mani`ere avec laquelle Great Bridge a dirig´e le test, et nous ne blˆamons pas l’´equipe de PostgreSQL pour ces tests.

Ce test a ´et´e condamn´e dans de nombreux articles et groupes d’utilisateurs, et nous ne citerons que quelques-uns des points qui ´etaient incorrects.

• Les tests ont ´et´e ex´ecut´es avec un outil commercial tr`es cher, qui rendent impossibles

aux entreprises Open Source comme nous de v´erifier les r´esultats ou mˆeme de voir comment les tests ont ´et´e mis en place. L’outil n’´etait mˆeme pas un v´eritable outil de test de performances, mais une application de mise en place et de tests. Dire que c’est un outil “standard” de tests est bien loin de la v´erit´e.

• Great Bridge a admis qu’ils ont optimis´e le serveur PostgreSQL (avec VACUUM avant le

test) et optimis´e le d´emarrage pour les tests, ce qu’ils n’ont pas fait pour les autres bases. Ils disent “Ce processus optimise les index et lib`ere un peu d’espace sur le disque. Les index optimis´es am´eliorent les performances marginalement”. Nos tests indiquent clairement la diff´erence lorsqu’on ex´ecute une s´erie de s´elections sur une base qui a ´et´e entretenue avec VACUUM ou pas : le facteur peut atteindre 10.

• Les r´esultats des tests ´etaient eux-mˆeme tr`es ´etranges. La documentation de tests AS3AP mentionne qu’ils sont des “s´elections, jointures simples, projections, agr´egations, modification d’une ligne et modifications massives”.

PostgreSQL est bon pour les SELECTs et les JOINs (sp´ecialement apr`es l’ex´ecution de la commande VACUUM), mais n’est pas tr`es performant pour les INSERTs ou les UPDATE. Les tests semblent indiquer que seuls des SELECT ont ´et´e ex´ecut´es. Cela peut facilement expliquer le nombre de bons r´esultats pour PostgreSQL dans ce test. Les mauvais r´esultats de MySQL seront ´evident un peu plus bas, dans ce document.

• Ils ont ex´ecut´e les soi-disant tests depuis une machine sous Windows vers un serveur

Linux, via ODBC, une configuration que personne n’utiliserait pour un environnement multi-utilisateur. Cela testait surtout le pilote ODBC et le protocole Windows utilis´e entre les clients et le serveur, plutˆot que le serveur lui-mˆeme.

• Lorsque les tests ont ´et´e ex´ecut´es avec Oracle et MS-SQL (Great Bridge a indirectement

indiqu´e que ces bases ´etaient utilis´ees dans les tests), ils n’ont pas utilis´e le protocole natif mais ODBC. Toute personne qui a utilis´e Oracle sait que toutes les vraies appli- cations utilisent l’interface native au lieu d’ODBC. Faire un test via ODBC et dire que les r´esultats sont comparables avec les situations d’utilisation de la base dans le monde

r´eel ne peut ˆetre consid´er´e comme ´equitable. Ils auraient dˆu faire deux tests, avec et sans ODBC, pour fournir des faits (apr`es que leurs experts aient optimis´e les serveurs, bien sˆur).

• Ils font r´ef´erence au tests TPC-C, mais ils ne mentionnent nulle part que le test n’´etait

pas un vrai test TPC-C et qu’ils n’´etaient pas autoris´es `a dire que c’´etait un tel test. Un test TPC-C ne peut ˆetre conduit que par les r`egles approuv´ees par le TPC Council (http://www.tpc.org/). Great Bridge ne l’a pas fait. Ils ont donc viol´e la marque commerciale de TPC et discr´edit´e leurs propres tests. Les r`egles dict´ees par le TPC Council sont tr`es strictes pour s’assurer que personne ne produit de faux r´esultats ou tire des conclusions inv´erifiables. Apparemment, Great Bridge n’´etait pas interess´e par cela.

• Apr`es le premier test, nous avons contact´e Great Bridge et nous leur avons mentionn´e

les erreurs ´evidentes qu’ils avaient faits avec le serveur MySQL :

− Travailler avec une version beta de notre pilote ODBC.

− Travailler avec un syst`eme Linux qui n’´etait pas optimis´e pour les threads. − Utiliser une vieille version de MySQL alors qu’il en existait une nouvelle.

− Ne pas d´emarrer MySQL avec les bonnes options pour g´erer les environnements

fortement multi-utilisateurs (la configuration par d´efaut est optimis´ee pour con- sommer le moins de ressources).

Great Bridge a ex´ecut´e un nouveau test, avec notre nouveau pilote ODBC, et avec de meilleures options de d´emarrage de MySQL mais ils ont refus´e d’utiliser notre li- brairie glibc ou notre binaire standard (utilis´e par 80% de nos utilisateurs), qui ´etaient statiquement compil´e avec la librairie glibc.

Selon nos sources, Great Bridge n’a rien fait pour s’assurer que les autres bases de donn´ees ´etaient correctement configur´ees pour leur environnement de tests. Nous sommes certains qu’ils n’ont pas contact´e Oracle ou Microsoft pour leur demander des conseils de configurations.

• Le test ´etait pay´e par Great Bridge, et ils ont d´ecid´e de publier une partie des r´esultats,

bien choisis (au lieu de tous les publier).

Tim Perdue, un inconditionnel de PostgreSQL et un utilisateur r´eticent de MySQL, publia une comparaison sur PHPbuilder (http://www.phpbuilder.com/columns/tim20001112.php3). Lorsque nous avons eu connaissance de la comparaison, nous avons t´el´ephon´e `a Tim Perdue `a ce propos, car il y avait de nombreux r´esultats ´etranges dans ses publications. Par exemple, il statuait que MySQL avait un probl`eme avec 5 utilisateurs durant ses tests, alors que nous avons des utilisateurs avec des machines similaires, qui utilisent MySQL avec plus de 2000 utilisateurs simultan´es, et 400 requˆetes par secondes. (Dans ce cas, la limite est la bande passante du r´eseau, pas le serveur SQL).

Il semblait qu’il utilisait un noyau Linux qui avait des probl`emes avec les threads, comme les noyaux avant le 2.4 qui avait des probl`emes avec les threads sur les machines `a plusieurs processeurs. Nous avons document´e dans le manuel comment corriger ce probl`eme, et Tim devrait ˆetre bientˆot au courant de ce probl`eme.

Les autres probl`emes possibles pourraient provenir d’une vieille librairie glibc ou du fait que MySQL n’utilise pas une version ex´ecutable de notre site web, qui est bˆatie avec une version corrig´ee de glibc library. Dans ces cas, les symptˆomes sont ceux que Tim a mesur´e.

Nous avons demand´e `a Tim d’avoir acc`es a ses donn´ees pour que nous puissions reproduire le test, et s’il pouvait v´erifier la version de MySQL sur sa machine pour voir ce qui n’allait pas. Il a promis qu’il nous contacterait mais n’a rien fait `a ce jour.

A cause de cela, nous ne pouvons pas non plus avoir confiance en ce test.

Avec le temps qui passe, les technologies ´evoluent, et les tests pr´ec´edents ne sont d´esormais plus valables. Le serveur MySQL dispose d’un jeu de gestionnaires de tables, avec des choix tr`es diff´erents sur la vitesse et les fonctionnalit´es. Voir Chapitre 7 [Table types], page 531. Il serait int´eressant de voir comment les tests ci-dessus s’effectuent avec les diff´erents ges- tionnaires de tables de MySQL. PostgreSQL a aussi, bien sˆur, de nouvelles fonctionnalit´es depuis que ces tests ont ´et´e men´es. Comme ces tests ne sont pas publiquement disponibles, il n’y a pas moyen pour nous de savoir comment les bases se comportent de nos jours avec ces tests.

Conclusion :

Les seuls tests qui existent aujourd’hui, disponibles au t´el´echargement pour tous, et que vous pouvez ex´ecuter avec MySQL, PostgreSQL sont les tests de MySQL. Chez MySQL AB, nous croyons que les bases de donn´ees Open Source devraient ˆetre test´ees avec des outils Open Source ! C’est le seul moyen de nous assurer que personne ne peut faire de tests que personne ne peut reproduire, et les utiliser pour proclamer que sa base est meilleure que les autres. Sans connaˆitre le fond des choses, il est impossible de r´epondre `a une telle d´eclaration.

Ce que nous trouvons ´etrange est que chaque test que nous avons vu `a propos de PostgreSQL est impossible `a reproduire, et indique que PostgreSQL est le meilleur dans la plupart des tests, alors que les nˆotres , que tout le monde peut reproduire, montrent le contraire. Avec cela, nous ne voulons pas dire que PostgreSQL n’est pas bon dans de nombreuses tˆaches (il l’est !!), ou qu’il n’est pas plus rapide que MySQL dans certaines conditions. Nous voulons juste voir un test ´equitable o`u PostgreSQL se comporte bien, pour que nous puissions avoir une comp´etition amicale !

Pour plus d’informations sur nos tests, voyez Section 5.1.4 [MySQL Benchmarks], page 360. Nous travaillons actuellement sur une suite de tests de perfomance qui inclue des tests multi utilisateurs, et une meilleure documentation sur les tests individuels pour indiquer ce qu’ils font et comment ajouter d’autres tests `a la suite.

2 Installation de MySQL

Ce chapitre d´ecrit comment obtenir et installer MySQL :

• Pour une liste de sites `a partir desquels vous pouvez obtenir MySQL, voyez Section 2.2.2

[Getting MySQL], page 73.

• Pour savoir quelles plate-formes sont support´ees, voyez Section 2.2.3 [Which OS],

page 74. Veuillez noter que tous les syst`emes support´es ne sont pas tous aussi bons pour faire fonctionner MySQL. Certains sont plus robustes et efficaces que d’autres, voyez Section 2.2.3 [Which OS], page 74 pour davantage d’informations.

• Plusieurs versions de MySQL sont disponibles `a la fois sous forme de binaires ou de

code source. Nous fournissons aussi un acc`es public `a notre arbre source aux personnes souhaitant suivre les derniers d´eveloppements et nous aider `a tester le nouveau code. Pour d´eterminer quelle version et quel type de distribution vous devriez utiliser, voyez Section 2.2.4 [Which version], page 76. En cas de doute, utilisez la distribution binaire.

• Les instructions d’installation `a partir des binaires ou des sources sont donn´ees dans

Section 2.2.8 [Installing binary], page 82, et Section 2.3 [Installing source], page 84. Chacun de ces jeux d’instructions inclut une partie sur des probl`emes sp´ecifiques que vous pourriez rencontrer.

• Pour les proc´edures cons´ecutives `a l’installation, voyez Section 2.4 [Post-installation],

page 97. Ces proc´edures s’appliquent `a la fois si vous installez MySQL `a partir des sources ou `a partir des binaires.