PostgreSQL surpasse-t-il MySQL et MariaDB en lecture ?
Un ingénieur logiciel partage son test de performance des trois SGBD

Le , par Victor Vincent, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de escartefigue escartefigue - Expert confirmé https://www.developpez.com
le 13/02/2016 à 22:08
Bonsoir,

quelques remarques concernant ce sujet :
Citation Envoyé par Victor Vincent  Voir le message
Faire le choix de la base de données à utiliser dans un projet peut être un choix difficile pour un développeur

- 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é
Avatar de fsmrel fsmrel - Expert éminent sénior https://www.developpez.com
le 14/02/2016 à 3:06
Bonsoir,

Citation Envoyé par Victor Vincent
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 base de données respecte les standards SQL, en tout cas plus que les deux autres.



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...

Citation Envoyé par escartefigue
Si la performance des requêtes est un critère de choix, alors pourquoi privilégier les requêtes 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é.



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)...
Avatar de escartefigue escartefigue - Expert confirmé https://www.developpez.com
le 14/02/2016 à 10:18
Citation Envoyé par fsmrel  Voir le message
Voilà des paroles frappées au coin du bon sens !

Attention, ces propos étaient les miens, Victor Vincent pourrait en prendre ombrage
Avatar de solstyce39 solstyce39 - Membre régulier https://www.developpez.com
le 14/02/2016 à 10:22
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 SGBD
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 14/02/2016 à 10:24
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 : Sélectionner tout
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-commit Bon 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

Postgres en lecture
Postges par rapport aux deux autres

Postgres par rapport aux deux autres
Avatar de MaitrePylos MaitrePylos - Responsable Livres https://www.developpez.com
le 14/02/2016 à 10:59
Citation Envoyé par Gugelhupf

Par contre MySQL bat PostgreSQL sur ce type de requête simple

Avec quel moteur ? myIsam ou InnoDb ?
Avatar de fsmrel fsmrel - Expert éminent sénior https://www.developpez.com
le 14/02/2016 à 12:50
Bonjour,

Citation Envoyé par escartefigue
Attention, ces propos étaient les miens, Victor Vincent pourrait en prendre ombrage



Dont acte, distraction de ma part, merci à Victor Vincent d'avoir rectifié...
Avatar de Artemus24 Artemus24 - Expert éminent https://www.developpez.com
le 14/02/2016 à 14:27
Salut à tous.

@ Gugelhupf : tu ne serais pas lorrain, par hasard ? Je dis cela car en Alsace, on écrit plutôt kouglouf, et en Allemagne Kugelhupf.

J'ai regardé ton benchmark que je trouve bien plus intéressant que le message de "Victor Vincent".
J'ai jeté un coup d’œil dans la partie MySql et je trouve que rien n'est optimisé. Inversement, je ne connais pas Postgre.

Voici quelques remarques (juste un survol) concernant les différents points de ton sujet :

1) hormis les primary key et foreign key de tes trois tables, je ne voie rien concernant le choix du moteur, du charset, du collation, ainsi que l'usage de la compression ou pas.
Il serait plus opportun d'adapter tes tables à chaque SGBDR au lieu de faire quelque chose de standard.

Concernant les déclaratives de tes index (une foreign key, c'est déjà un index), il ne manque rien, vis-à-vis de tes requêtes.
Il suffit de faire un explain pour se rendre compte de son utilisation.

2) tu fais usage des nombres aléatoires, d'accord.
Mais pour tester les performances, il faut que tes données soient aussi exactement les mêmes.
Or cela ne sera pas le cas ! Il faut adopter une autre méthode que les nombres aléatoires.

3) tes deux premiers tests sont très similaires dans la façon dont tu gères les insertions
Je fais aussi une procédure stockée afin de simuler les insertions.
Je prends un exemple que j'ai fait chez moi, j'ai charger dans une table 'test' 1.000.000 de lignes.
Heure Début : 13:15:32,53
Heure Fin : 13:16:33,78

Soit en gros 1 Minute 1 Seconde et 25 Centièmes ! Alors que tu indiques 25 min 4.53 sec !
Il y a un très sérieux problème avec l'optimisation !!!

4) tu fais "select *". Il faut éviter d'extraire des colonnes dont tu n'as pas besoin.

5) tu fais une jointure, d'accord, mais j'aimerai que tu précises quel type de jointure.
Un "inner join", un "left outer join", autre chose ... Je n'aime pas les déclaratives par défaut.

6) quand tu as trois tables en jointure, il y a un ordre à respecter.
En général, on commence par la table charnière (je réutilise ton vocabulaire).
Et ensuite, on fait le jointure sur les autres tables.
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
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 
INNER JOIN t_patient P  
ON P.id = MP.id_patient;
Inversement, si tu veux optimiser tes accès, commence par les tables les plus petites.

7) Un exemple mal formulé :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
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 
INNER JOIN t_patient P  
ON P.id = MP.id_patient 
WHERE M.id  = 40;
Pourquoi faire un "where M.id = 40" ?
Car en faisant cela, tu récupères tout, puis ensuite, tu sélectionnes ce dont tu as besoin.
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
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;
8) il y a des images qui ne s'affichent plus dans ton didacticiel. Du coup, je voie nul part tes explain ???
Il serait très utile de voir ce qui a été fait sur ce point.

9) tu as fait l'effort de créer un benchmark entre MySql et Postgre. C'est très bien d'avoir pris le temps de le faire.
Mais tu devrais donner les valeurs moyennes en lançant, disons un milliers de fois, chaque test !
Un seul test par cas n'est pas représentatif d'un bon benchmark.

10) qu'est-ce qui a été fait en terme de paramétrage système pour MySql et Postgre ?
C'est le cœur même du SGBD qui va rendre optimal tes accès.
Tu as beau rajouter des index, ou faire des explains, si le paramétrage est mal fait, tu n'obtiendras rien de bon.

10) en conclusion, je considère que vos tests ne sont pas très représentatif de ce que l'on peut obtenir.
C'est comme si tu veux comparer une ferrari et une 2CV. Et pour ce faire, tu conduis en restant que sur la premier vitesse.

@+
Avatar de lecbee lecbee - Membre du Club https://www.developpez.com
le 14/02/2016 à 15:01
Citation Envoyé par fsmrel  Voir le message
Bigre ! Qu’est-ce que la norme SQL vient faire dans cette histoire ?

Rien effectivement, l'auteur du blog n'a jamais dit ça... Victor Vincent ne lit probablement pas très bien l'anglais d'où sa confusion.
Avatar de RyzenOC RyzenOC - Membre émérite https://www.developpez.com
le 14/02/2016 à 15:16
Pour faire des benchmark correcte faudrait prendre compte le dommaine d'application (site wordpress ou bigdata) et aussi utiliser des syntaxe optimisé (pour Orable DB par exemple)
Par exemple les SGBD les plus performant pour des requêtes simple (un simple select par exemple) c'est la famille NoSQL, c'est très utilisé en big data.

Sinon je m'étais laissé entendre dire que pour des petites BDD, Mysql était plus performant que postgres et inversement.
J'imagine que les perf dépende aussi de la taille des tables.

Concernant MySQL, c'est un sgbd un peu spéciale, car on peut choisir son moteur. MyIsam ou InnoDB, les 2 ont leurs forces et leurs faiblesses en terme de perf.
Offres d'emploi IT
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY
Data scientist senior H/F
Safran - Ile de France - Magny-les-Hameaux (Saclay)
Responsable protection des données H/F
Safran - Ile de France - Magny-les-Hameaux (78114)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil