PostgreSQL surpasse-t-il MySQL et MariaDB en lecture ?
Un ingénieur logiciel partage son test de performance des trois SGBD
Le 2016-02-13 17:55:20, par Victor Vincent, Expert éminent sénior
Un ingénieur logiciel partage son test de performance des trois systèmes de gestion de bases de données
Faire le choix de la base de données à utiliser dans un projet peut être un choix difficile pour un développeur dans des petites équipes de développements où une même personne peut accumuler plusieurs rôles à la fois. Dans certaines équipes il n’est pas rare que le développeur joue en même temps le rôle de concepteur de bases de données par exemple. Pour aider ses pairs dans leur choix technologique, un ingénieur logiciel partage les résultats de son test de performance avec la communauté. Ce qui a retenu son attention, souligne-t-il, c’est les performances de Postgres en lecture. D’après les résultats publiés par l’auteur du test de performance, MariaBD et MySQL ont pris les devants quand il s’agit des requêtes d’écriture en base de données. Cependant pour les requêtes de lecture en base de données, Postgres s’est démarqué de manière assez nette des deux autres aussi bien pour des requêtes simples que les requêtes complexes.
L’environnement utilisé par l’auteur du Benchmark est Ubuntu Wily Werwolf qui est la version 15.10 du système d’exploitation utilisé sur une machine avec un environnement processeur monocœur et une capacité de 1024 Mo de mémoire RAM. Pour les versions des systèmes de gestion de bases de données utilisés, il s’agit de la version 10.1.11 de MaraiDB, la version 5.7.10 de MySQL et de la version 9.5.0 de Postgres. La figure suivante représente les différentes requêtes de lecture en base de données qui ont été faites sur les trois systèmes de gestion de bases de données.
Les bons résultats obtenus avec Postgres pourraient s’expliquer d’après l’auteur du benchmark par le fait que ce système de gestion de bases de données respecte les standards SQL, en tout cas plus que les deux autres.
Source : résultats du benchmark
Et vous ?
Avez-vous testé les performances de ces différents systèmes de gestion de bases de données ?
Vos résultats confirment-ils les performances de Postgres par rapport aux deux autres ?
Voir aussi
la rubrique Bases de données
Faire le choix de la base de données à utiliser dans un projet peut être un choix difficile pour un développeur dans des petites équipes de développements où une même personne peut accumuler plusieurs rôles à la fois. Dans certaines équipes il n’est pas rare que le développeur joue en même temps le rôle de concepteur de bases de données par exemple. Pour aider ses pairs dans leur choix technologique, un ingénieur logiciel partage les résultats de son test de performance avec la communauté. Ce qui a retenu son attention, souligne-t-il, c’est les performances de Postgres en lecture. D’après les résultats publiés par l’auteur du test de performance, MariaBD et MySQL ont pris les devants quand il s’agit des requêtes d’écriture en base de données. Cependant pour les requêtes de lecture en base de données, Postgres s’est démarqué de manière assez nette des deux autres aussi bien pour des requêtes simples que les requêtes complexes.
L’environnement utilisé par l’auteur du Benchmark est Ubuntu Wily Werwolf qui est la version 15.10 du système d’exploitation utilisé sur une machine avec un environnement processeur monocœur et une capacité de 1024 Mo de mémoire RAM. Pour les versions des systèmes de gestion de bases de données utilisés, il s’agit de la version 10.1.11 de MaraiDB, la version 5.7.10 de MySQL et de la version 9.5.0 de Postgres. La figure suivante représente les différentes requêtes de lecture en base de données qui ont été faites sur les trois systèmes de gestion de bases de données.
Les bons résultats obtenus avec Postgres pourraient s’expliquer d’après l’auteur du benchmark par le fait que ce système de gestion de bases de données respecte les standards SQL, en tout cas plus que les deux autres.
Source : résultats du benchmark
Et vous ?
Voir aussi
-
fsmrelExpert éminent séniorBonsoir,
Envoyé par Artemus24
Pourquoi respecter un tel ordre ? Et s’il y a 10 tables « charnières » à joindre, par quel bout commence-t-on ? Au passage, je fais observer que la jointure naturelle est une opération commutative et associative, faisant que l’ordre ne joue pas.Envoyé par Artemus24
S’il s’agit là encore d’un ordre à respecter, autant dire qu’un optimiseur s’en tamponne le coquillard ! Il sait ce qu’il a à faire et comment le faire.Envoyé par Gugelhupf
Vous avez parfaitement raison, Gugelhupf, c’est bien le SGBD qui optimise.
En fait, "where M.id = 40" correspond à l’opération relationnelle de restriction. Il est évident qu’un optimiseur quel qu’il soit va commencer par effectuer cette opération qui est la plus rentable de toutes quant aux performances (sous réserve bien sûr que l’on ait défini l’index ad-hoc).
Ainsi, que l’on code « Belle Marquise, vos beaux yeux me font mourir d’amour » :Ou bien « D’amour mourir me font, belle Marquise, vos beaux yeux » :SELECT P.*, M.nom AS nom_medecin, M.prenom AS prenom_medecin FROM t_medecin M JOIN t_charniere_medecin_patient MP ON M.id = MP.id_medecin JOIN t_patient P ON P.id = MP.id_patient WHERE M.id = 40 ;
ou encore « Vos yeux beaux d’amour me font, belle Marquise, mourir » :SELECT P.*, M.nom AS nom_medecin, M.prenom AS prenom_medecin FROM t_medecin M, t_charniere_medecin_patient MP, t_patient P WHERE M.id = MP.id_medecin AND P.id = MP.id_patient AND M.id = 40 ;
Eh bien, un optimiseur n’en a cure car, comme aurait dit Monsieur de La Palice, sa mission c’est ... d’optimiser ! Dans tous les cas, il applique donc d’abord la restriction très juteuse « where M.id = 40 », ce que montre bien un EXPLAIN, même avec MySQL :SELECT P.*, M.nom AS nom_medecin, M.prenom AS prenom_medecin FROM t_charniere_medecin_patient MP INNER JOIN t_medecin M ON M.id = MP.id_medecin AND M.id = 40 INNER JOIN t_patient P ON P.id = MP.id_patient WHERE M.id = 40;
1re requête :
2e requête :
3e requête :Envoyé par Artemus24
Les auteurs de MySQL en ont certes décidé ainsi, mais c’est un diktat insupportable, une erreur de leur part, ils confondent les niveaux, relationnel d’une part, physique d’autre part. Une clé étrangère (foreign key) d’une table T1 n’est pas un index, mais une référence à une clé candidate (voire une surclé) d’une table T2 (non nécessairement distincte de T1). On est en l’occurrence au niveau relationnel. Sorti de MySQL, que le DBA décide au niveau physique de mettre en œuvre pour T1 un index dont les colonnes sont celles de la clé étrangère, pourquoi pas, mais seulement en cas de nécessité, il est le seul juge.
Par exemple, avec PostgreSQL, sans index sur la colonne id_medecin, la requête ci-dessous va provoquer un balayage complet de la table t_charniere_medecin_patient :select * from t_charniere_medecin_patient where id_medecin = 40 ;
=>"Seq Scan on t_charniere_medecin_patient "
Avec un tel verdict de la part de l’optimiseur, on créera un index, mais là encore, c’est une décision du DBA (après tout, pour une table de quelques lignes, genre titres de civilité, le jeu n’en vaut sans doute pas la chandelle). Dans le cas présent, avec PostgreSQL, on codera par exemple :create index t_charniere_medecin_patient_x1 on t_charniere_medecin_patient (id_medecin) ;
Et notre DBA peaufinera dans la soute, jusqu’à ce qu’il obtienne la performance recherchée. En passant, avant de s’occuper de la performance, afin d’éviter que cette table ne se transforme en « sac à tuples » (présence de doublons, donc mise en danger de l’algèbre relationnelle qui ne sait opérer correctement que sur des ensembles), il la dotera d’une clé primaire {id_medecin, id_patient} (avec pour conséquence la mise en œuvre implicite ou non de l’index de type UNIQUE correspondant...)Envoyé par
Les sentiments ne sont pas de mise ! SQL est un langage pour lequel il existe une norme, et il y est écrit (cf. par exemple WG3:HBA-003 = H2-2003-305 = 5WD-02-Foundation-2003-09, WD 9075-2 (SQL/Foundation), September, 2003, aux pages 312-313) :
7.7 <joined table>
Function
Specify a table derived from a Cartesian product, inner join, or outer join.
Format
<joined table> ::=
<cross join>
| <qualified join>
| <natural join>
<cross join> ::=
<table reference> CROSS JOIN <table factor>
<qualified join> ::=
<table reference> [] JOIN <table reference> <join specification>
<natural join> ::=
<table reference> NATURAL [] JOIN <table factor>
<join specification> ::=
<join condition>
| <named columns join>
<join condition> ::= ON <search condition>
<named columns join> ::= USING <left paren> <join column list> <right paren>
<join type> ::=
INNER
| <outer join type> [ OUTER ]
<outer join type> ::=
LEFT
| RIGHT
| FULL
<join column list> ::=
<column name list>
Syntax Rules
[...]
3) If a <qualified join> or <natural join> is specified and a <join type> is not specified, then INNER is implicit.
[...]
La norme ayant décrété (dès SQL:1992, il y a donc belle lurette !) qu’INNER était implicite, chacun est libre d’en faire usage ou non. Maintenant, si les règles en vigueur dans l’entreprise imposent INNER (ou NATURAL ou USING, etc.), chacun devra évidemment se conformer à ces règles.le 15/02/2016 à 3:32 -
GugelhupfModérateur
Avez-vous testé les performances de ces différents systèmes de gestion de bases de données ?
Oui, j'ai même réalisé un benchmark (fin 2014) mais comme les données avaient étés généré aléatoirement et que le système de transaction par défaut diffère entre les deux bases, je considère remettre à jour mon article car tel qu'il est je le considère un peu obsolète.Vos résultats confirment-ils les performances de Postges par rapport aux deux autres ?
Oui et non. L'auteur a fait en sorte de prendre les cas où Postgres bat ses concurrents. Par expérience je peux dire que Postgres gère mieux quand :
- Une requête contient des fonctions d’agrégat (sum, max etc)
- Une requête retourne plusieurs centaines de tuples.
- Une requête contient beaucoup de jointure.
Par contre MySQL bat PostgreSQL sur ce type de requête simple :
Code SQL : SELECT champ1, champ2 FROM ma_table WHERE id = 1;
Pas de fonction d'agrégat, simple tuple en retour (généralement moins de 50 tuples), pas (ou peu) de jointure.
Pour ce qui est des insertions mon test mettait en avant PostgreSQL, mais je n'avais pas pris en compte que MySQL faisait des auto-commitBon après pour le cas d'une base entre insertion et lecture, on sait que les cas de lecture sont plus importants que l'écriture.
Ma conclusion : PostgreSQL reste plus polyvalent, MySQL semble plus adapté pour les sites web simples qui ne nécessitent pas de requêtes complexes.
PS :
Coquilles :
Psostgres en lecture
Postges par rapport aux deux autres
le 14/02/2016 à 10:24 -
GugelhupfModérateur
Envoyé par MaitrePylos
@Artemus24,
1. Comme indiqué dans l'en-tête du tableau, il s'agit d'InnoDb, pour ce qui est du charset ou collation j'ai laissé les valeurs par défaut, je doute que ce soit un critère important car je ne fais pas de traitement particulier sur les chaines.
2. C'est bien ce que je dis, je n'ai pas utilisé un fichier statique pour charger les données mais utilisé une fonction qui génère des valeurs random (même si on obtient le même nombre de tuple entre les deux bases), d'où 1 des 2 défauts que j'ai cité concernant mon benchmark.
3. Ce n'est pas un défaut d'optimisation, c'est un problème chaise-clavier (moi). Là tu fais référence au 2ème défaut de mon benchmark, je suis en mode auto-commit true, d'où le fait d'avoir un temps d'insertion aussi conséquent.
4. Je fais SELECT * pour PostgreSQL et MySQL donc pas de souci, on considère qu'il faut récupérer tous les champs.
5. Il s'agit d'une jointure interne, c'est la jointure par défaut (SQL-92 : If a <qualified join> is specified and a <join type> is not specified, then INNER is implicit).
6. Je ne savais pas qu'il y avait un ordre à respecter (si tu as une référence n'hésite pas), moi j'ai tendance à commencer par la table la plus importante. Le terme "table charnière" ne vient pas de moi mais de mes professeurs.
7. Pourquoi faire un "where M.id = 40" ? : parce que id = 40 n'est pas une condition de jointure, mais un élément variable. Je n'ai pas testé la différence entre les performances entre ON et WHERE, mais je suis sur que le SGBD optimise cela à la lecture de la requête.
8. Les images font références à mon ancien site qui n'existe plus. Voici l'extrait du benchmark qui t'intéresse.
9. Je dirais que c'est le 3ème défaut de ce benchmark, mais je vais être honnête, pour faire un vrai benchmark il faudrait des outils adaptés, à l'époque je n'en connaissais pas et nous étions à court de temps pour fournir nos benchmark, et second problème ces outils sont spécifiques aux bases, ils sont tous différents et on ne sait pas comment ils sont implémentés. Mais bon j'ai tout de même exécuté ces requêtes plusieurs fois, il n'y avait pas de grosses différences.
10.1. Aucune optimisation particulière n'a été effectuée, nous avons les paramètres par défaut pour les deux systèmes (si tu connais aussi bien MySQL tu sais tout). J'imagine que les éditeurs font en sorte de distribuer leurs logiciels avec les paramètres les plus nazes qui soient, et que ce soit à nous de tuner leur outil.
Bon je dis ça pour plaisanterN'hésite pas à dire comment tu aurais tuné pour faire le benchmark.
10.2. Critique subjective, n'hésite pas à nous faire un benchmark, nous verrons ce qu'il vaut.
Non je ne suis pas lorrain, je pensais à l'Alsace lorsque j'ai créé mon pseudo, je ne suis pas alsacien non plus, juste un gueux de parisienle 14/02/2016 à 16:52 -
fsmrelExpert éminent séniorBonsoir,
Envoyé par Victor Vincent
Bigre ! Qu’est-ce que la norme SQL vient faire dans cette histoire ? Elle traite du Quoi, plutôt que du Comment ! Si l’auteur parlait de la supériorité de l’optimiseur du SGBD, de la structure des espaces physiques, index et autres éléments sous le capot, soit. Mais pour comparer, encore faut-il être très pointu à la fois sur toutes ces choses quant aux SGBD dont il est question, or il est pratiquement impossible d’être spécialiste dans les tréfonds de plus d’un SGBD. Ainsi, il est des études comparatives et autres benchmarks qui laissent songeur, tel celui-ci...Envoyé par escartefigue
Voilà des paroles frappées au coin du bon sens !
Pour ce qu’il en est de lire le plus vite possible des tables comme celle du benchmark (j’utilise le singulier : « celle », car je n’ai pas vu de jointure ou d’union, mais peut-être suis-je mauvaise langue, la table « testing » est-elle en fait une vue de jointure et/ou d’union ?), les fichiers plats (même sophistiqués comme ceux qui utilisent VSAM d’IBM) sont sans doute les meilleurs candidats...
Mais, comme le sous-entend escartefigue, faire des mises à jour concurrentes, avec célérité, en toute sécurité et sans gêner les voisins, c’est une autre paire de manches, comparer en toute objectivité devient bigrement compliqué, il faut faire intervenir des DBA expérimentés, spécialistes de leur SGBD respectif...
Cela dit, comme le fait encore observer escartefigue, MySQL est sans doute un choix risqué, mais, pour ma part, ne l’ayant pas suffisamment secoué pour prétendre être véritablement spécialiste de ce SGBD, je suis obligé de suivre la proposition 7 de Wittgenstein (même chose au sujet de PostgreSQL)...le 14/02/2016 à 3:06 -
solstyce39Membre confirméquand on voit pour la même requête :
MariaDB : 741 ms
Mysql : 6686 ms
PostgreSQL : 229.33 ms
voir un tel écart avec mysql sur la même requête et la même architecture physique, ça me laisse seulement penser qu'il y a un soucis ailleurs et me fait douter fortement du benchmarK
Après je n'ai pas une connaissance assez approfondie des SGBDle 14/02/2016 à 10:22 -
berceker unitedExpert éminent-4000 .Nimp ! Lorsque tu créés une jointure c'est pas toi qui décide, c'est le moteur qui décide du meilleur ordre de lecture de la table à moins que tu le forces via un mot clé à placer dans la requête mais c'est extrêmement rare de l'employer.le 15/02/2016 à 21:02
-
fsmrelExpert éminent séniorBonsoir,
Envoyé par JPLAROCHE
... DB2 qui va avoir 32 ans en juillet prochain...
Quoi qu'il en soit, époque héroïque pour les DBA, quand pour étudier les performances de DB2, EXPLAIN n’existait pas encore, quand les cours spécialisés et pointus, dédiés à la performance étaient seulement en préparation chez IBM, quand des outils comme Detector n’existaient pas non plus...le 22/02/2016 à 15:39 -
escartefigueModérateurBonsoir,
quelques remarques concernant ce sujet :
- Les développeurs n'ont jamais eu leur mot à dire quand au choix de la base de données
- Les performances sont rarement le critère de choix de la base, le budget intervient le plus souvent en premier, et les compétences en interne dans l'entreprise sont en général le 2eme critère
- Si la performance des requetes est un critère de choix, alors pourquoi privilégier les requetes en lecture, plutôt que celles en màj ? pour des infocentres, oui, mais en ce cas aucun des 2 sgbd cités n'est concerné
- toutes choses égales par ailleurs, My SQL présente de telles lacunes, que le choisir pour une base de données d'entreprise est un choix risquéle 13/02/2016 à 22:08 -
MaitrePylosModérateur
Envoyé par Gugelhupf le 14/02/2016 à 10:59 -
fsmrelExpert éminent séniorBonsoir,
Envoyé par lecbee
L’auteur du benchmark, a bien fait mention de la norme SQL, je le cite :« As a result, I think that choosing PostgreSQL is a better options for RDBMS - provided that PostgreSQL comes with more features and following standard SQL. »le 14/02/2016 à 20:39