IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

678PARTAGES

3  1 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 15/02/2016 à 3:32
Bonsoir,

Citation Envoyé par Artemus24
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.


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.

Citation Envoyé par Artemus24
Inversement, si tu veux optimiser tes accès, commence par les tables les plus petites.


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.

Citation Envoyé par Gugelhupf


Citation Envoyé par Artemus24

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.


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.


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 » :


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 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, t_charniere_medecin_patient MP, t_patient P 
WHERE M.id = MP.id_medecin 
AND P.id = MP.id_patient
AND 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_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;

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 :

1re requête :



2e requête :



3e requête :



Citation Envoyé par Artemus24
une foreign key, c'est déjà un index


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

Citation Envoyé par
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.


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.
10  0 
Avatar de 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
4  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 14/02/2016 à 16:52
Citation Envoyé par MaitrePylos
Avec quel moteur ? myIsam ou InnoDb ?

InnoDb (c'était indiqué dans l'en-tête du tableau dans mon article).

@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 plaisanter N'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 parisien
4  0 
Avatar de 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)...
3  0 
Avatar de solstyce39
Membre confirmé 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
3  0 
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 15/02/2016 à 21:02
Citation Envoyé par Artemus24 Voir le message
Salut à tous.
...
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.
....
@+
-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.
4  1 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 22/02/2016 à 15:39
Bonsoir,

Citation Envoyé par JPLAROCHE
j'ai travaillé pendant plus de 40 ans avec DB2


... 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...
3  0 
Avatar de escartefigue
Modérateur 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é
7  5 
Avatar de MaitrePylos
Modérateur 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 ?
2  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 14/02/2016 à 20:39
Bonsoir,

Citation Envoyé par lecbee

Citation Envoyé par fsmrel

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.


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. »
2  0