Performances comparées de MySQL et PostgreSQL

Le seul test de vitesse Open Source

que nous connaisssons et qui peut être utilisé pour tester les performances de MySQL et de PostgreSQL (et d'autres bases de données) est le nôtre. Il est disponible à l'adresse http://www.mysql.com/information/benchmarks.html .

Nous avons demandé de nombreuses fois aux développeurs de PostgreSQL et aux utilisateurs de PostgreSQL de nous aider à développer et améliorer ce test, pour en faire le meilleur test possible, mais nous n'avons pas reçu de réponse de leur part.

Nous, les développeurs MySQL, avons, à cause de cela, passé de nombreuses heures à obtenir les meilleures performances de PostgreSQL pour ces tests, mais comme nous ne connaissons pas intimement le serveur PostgreSQL, nous sommes certains d'être passé à coté de certains points. Sur la page de test, nous avons documenté exactement comment nous avons exécuté le test, pour qu'il soit facile à tout le monde de reproduire et de confirmer nos résultats.

Les tests sont généralement exécutés avec et sans l'option −−fast

. Lorsque l'option −−fast

est utilisée, nous tentons d'utiliser tous les trucs connus du serveur pour que l'exécution soit aussi rapide que possible. L'idée 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éveloppeur utilise toutes les extensions du serveur pour accélérer son application. Lorsque nous exécutons PostgreSQL avec l'option −−fast

, nous exécutons la commande VACUUM

après chaque modification importante de la table, et après l'effacement de table, pour conserver la base dans un état parfait pour les prochaines sélections. Le temps nécessaire à l'exécution de la commande VACUUM

est mesuré séparément.

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émon PostgreSQL) s'est arrété, et la base était tellement corrompue qu'il a été impossible de redémarrer le postmaster. Après un deuxième problème identique, nous avons décidé de reporter les tests −−fast

jusqu'à la prochaine version de

PostgreSQL. Les détais sur la machine avec laquelle nous avons exécuté 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étails sur le contexte des tests.

Il est très facile d'écrire 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ène à un seul chiffre, c'est encore plus facile.

Cela revient à mesurer la vitesse de MySQL par rapport à PostgreSQL en regardant simplement 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ûr, faux. Nous pourrions même rendre les choses encore pires en prenant les tests où 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ûr, dans le sens inverse. Un optimiseur SQL est un programme complexe, et une

compagnie peut passer des années à le rendre de plus en plus rapide.

Lorsque vous regardez les résultats des tests, vous devriez vous limiter aux opérations que vous utilisez dans votre application, et utiliser simplement ces résultats pour décider quelle base de données est la plus adaptée à vos besoins. Les résultats de tests vous montrent quelles opérations sont le point faible de chaque base, et vous donnent des indications sur ce qu'il faudra éviter 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âche énorme de le faire pour que ce soit équitable pour chaque base.

Le premier est le test payant, effectué pour Great Bridge, une entreprise qui a tenté durant 16 mois de bâtir un modèle d'affaires avec PostgreSQL mais qui a désormais cessé les opérations. C'est probablement le pire test que nous ayons jamais vu. Non seulement ce test était bâti pour ne tester que les points forts de PostgreSQL, mais il était totalement déloyal pour toutes les autres bases de données utilisées dans le test.

Note : nous savons aussi que même certains des développeurs principaux de PostgreSQL n'ont

pas aimé la manière avec laquelle Great Bridge a dirigé le test, et nous ne blâmons pas l'équipe de PostgreSQL pour ces tests.

Ce test a été condamné dans de nombreux articles et groupes d'utilisateurs, et nous ne citerons que quelques−uns des points qui étaient incorrects.

Les tests ont été exécutés avec un outil commercial très cher, qui rendent impossibles aux entreprises Open Source

comme nous de vérifier les résultats ou même de voir comment les tests ont été mis en place. L'outil n'était même pas un véritable 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érité.

•

Great Bridge a admis qu'ils ont optimisé le serveur PostgreSQL (avec VACUUM

avant le test) et optimisé le démarrage pour les tests, ce qu'ils n'ont pas fait pour les autres bases. Ils disent ``Ce processus optimise les index et libère un peu d'espace sur le disque. Les index

optimisés améliorent les performances marginalement''. Nos tests indiquent clairement la différence lorsqu'on exécute une série de sélections sur une base qui a été entretenue avec

VACUUM

ou pas : le facteur peut atteindre 10.

•

Les résultats des tests étaient eux−même très étranges. La documentation de tests AS3AP mentionne qu'ils sont des ``sélections, jointures simples, projections, agrégations,

modification d'une ligne et modifications massives''. PostgreSQL est bon pour les SELECT

s et les JOIN

s (spécialement après l'exécution de la commande VACUUM

), mais n'est pas très performant pour les INSERT

s ou les UPDATE

. Les tests semblent indiquer que seuls des SELECT

ont été exécutés. Cela peut facilement expliquer le nombre de bons résultats pour PostgreSQL dans ce test. Les mauvais résultats de MySQL seront évident un peu plus bas, dans ce document.

•

Ils ont exécuté 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é entre les clients et le serveur, plutôt que le serveur lui−même.

•

Lorsque les tests ont été exécutés avec Oracle et MS−SQL (Great Bridge a indirectement indiqué que ces bases étaient utilisées dans les tests), ils n'ont pas utilisé le protocole natif

•

mais ODBC. Toute personne qui a utilisé Oracle sait que toutes les vraies applications utilisent l'interface native au lieu d'ODBC. Faire un test via ODBC et dire que les résultats sont comparables avec les situations d'utilisation de la base dans le monde réel ne peut être considéré comme équitable. Ils auraient dû faire deux tests, avec et sans ODBC, pour fournir des faits (après que leurs experts aient optimisé les serveurs, bien sûr).

Ils font référence au tests TPC−C, mais ils ne mentionnent nulle part que le test n'était pas un vrai test TPC−C et qu'ils n'étaient pas autorisés à dire que c'était un tel test. Un test TPC−C ne peut être conduit que par les règles approuvées par le TPC Council (

http://www.tpc.org/ ). Great Bridge ne l'a pas fait. Ils ont donc violé la marque commerciale de TPC et discrédité leurs propres tests. Les règles dictées par le TPC Council sont très strictes pour s'assurer que personne ne produit de faux résultats ou tire des conclusions invérifiables. Apparemment, Great Bridge n'était pas interessé par cela.

•

Après le premier test, nous avons contacté Great Bridge et nous leur avons mentionné les erreurs évidentes qu'ils avaient faits avec le serveur MySQL :

Travailler avec une version beta de notre pilote ODBC.

♦

Travailler avec un système Linux qui n'était pas optimisé pour les threads.

♦

Utiliser une vieille version de MySQL alors qu'il en existait une nouvelle.

♦

Ne pas démarrer MySQL avec les bonnes options pour gérer les environnements fortement multi−utilisateurs (la configuration par défaut est optimisée pour

consommer le moins de ressources).

♦

Great Bridge a exécuté un nouveau test, avec notre nouveau pilote ODBC, et avec de meilleures options de démarrage de MySQL mais ils ont refusé d'utiliser notre librairie glibc ou notre binaire standard (utilisé par 80% de nos utilisateurs), qui étaient statiquement compilé avec la librairie glibc.Selon nos sources, Great Bridge n'a rien fait pour s'assurer que les autres bases de données étaient correctement configurées pour leur environnement de tests. Nous sommes certains qu'ils n'ont pas contacté Oracle ou Microsoft pour leur demander des conseils de configurations.

•

Le test était payé par Great Bridge, et ils ont décidé de publier une partie des résultats, bien choisis (au lieu de tous les publier).

•

Tim Perdue, un inconditionnel de PostgreSQL et un utilisateur réticent 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éléphoné à Tim Perdue à ce propos, car il y avait de nombreux résultats étranges dans ses publications. Par exemple, il statuait que MySQL avait un problème 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és, et 400 requêtes par secondes. (Dans ce cas, la limite est la bande passante du réseau, pas le serveur SQL).

Il semblait qu'il utilisait un noyau Linux qui avait des problèmes avec les threads, comme les noyaux avant le 2.4 qui avait des problèmes avec les threads sur les machines à plusieurs processeurs. Nous avons documenté dans le manuel comment corriger ce problème, et Tim devrait être bientôt au courant de ce problème.

Les autres problèmes possibles pourraient provenir d'une vieille librairie glibc ou du fait que MySQL n'utilise pas une version exécutable de notre site web, qui est bâtie avec une version corrigée de glibc library. Dans ces cas, les symptômes sont ceux que Tim a mesuré.

Nous avons demandé à Tim d'avoir accès a ses données pour que nous puissions reproduire le test, et s'il pouvait vérifier 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 à ce jour.

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

Avec le temps qui passe, les technologies évoluent, et les tests précédents ne sont désormais plus valables. Le serveur MySQL dispose d'un jeu de gestionnaires de tables, avec des choix très différents sur la vitesse et les fonctionnalités. Types de tables MySQL . Il serait intéressant de voir comment les tests ci−dessus s'effectuent avec les différents gestionnaires de tables de MySQL. PostgreSQL a aussi, bien sûr, de nouvelles fonctionnalités depuis que ces tests ont été menés. 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éléchargement pour tous, et que vous pouvez exécuter avec MySQL, PostgreSQL sont les tests de MySQL. Chez MySQL AB, nous croyons que les bases de données Open Source

devraient être testées 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ître le fond des choses, il est impossible de répondre à une telle déclaration.

Ce que nous trouvons étrange est que chaque test que nous avons vu à propos de PostgreSQL est impossible à reproduire, et indique que PostgreSQL est le meilleur dans la plupart des tests, alors que les nôtres , 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âches (il l'est !!), ou qu'il n'est pas plus rapide que MySQL dans certaines conditions. Nous voulons juste voir un test

équitable où PostgreSQL se comporte bien, pour que nous puissions avoir une compétition amicale !

Pour plus d'informations sur nos tests, voyez La suite de tests comparatifs de MySQL . 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 à la suite.

Ce chapitre décrit comment obtenir et installer MySQL :

Pour une liste de sites à partir desquels vous pouvez obtenir MySQL, voyez How to Get MySQL .

•

Pour savoir quelles plate−formes sont supportées, voyez Operating Systems Supported by MySQL . Veuillez noter que tous les systèmes supportés ne sont pas tous aussi bons pour faire fonctionner MySQL. Certains sont plus robustes et efficaces que d'autres, voyez Operating Systems Supported by MySQL pour davantage d'informations.

•

Plusieurs versions de MySQL sont disponibles à la fois sous forme de binaires ou de code source. Nous fournissons aussi un accès public à notre arbre source aux personnes

souhaitant suivre les derniers développements et nous aider à tester le nouveau code. Pour déterminer quelle version et quel type de distribution vous devriez utiliser, voyez Which MySQL Version to Use . En cas de doute, utilisez la distribution binaire.

•

Les instructions d'installation à partir des binaires ou des sources sont données dans Installing a MySQL Binary Distribution , et Installer MySQL à partir des sources . Chacun de ces jeux d'instructions inclut une partie sur des problèmes spécifiques que vous pourriez rencontrer.

•

Pour les procédures consécutives à l'installation, voyez Configuration et tests consécutifs à l'installation . Ces procédures s'appliquent à la fois si vous installez MySQL à partir des sources ou à partir des binaires.

•