Discussion :

[domi65]

Le test ne signifie pas grand chose dans la mesure où on ne nous dit pas quel moteur de table a été utilisé par MySQL.
N'oublions pas que MySQL est un SDGB permettant d'utiliser plusieurs moteurs.
Selon le moteur utilisé les perfs peuvent être très différentes entre MySQL et... MySQL.
On ne sait pas non plus si les tables étaient indexées, ce qui peut influer les comparaisons des résultats.
Et comme l'on fait remarquer mes prédécesseurs, le choix des requêtes est un peu court.
Ce test laisse plus d'interrogations qu'il donne de réponses.

EDIT: Il n'y avait que très peu de messages précédent le mien lorsque j'ai écrit cette bafouille. Elle n'apporte donc rien et des réponses ont été données pour certains points. Bref : post à oublier.

[Logan Mauzaize]

sur une machine avec un environnement processeur monocœur et une capacité de 1024Mo de mémoire RAM.

Je suis le seul que cela fait tilté ? D'ailleurs je constate qu'il ne joue qu'une seule requête à la fois et sur une seule table. Et avec un volume plutôt faible pour un BDD.
Je suis pas spécialiste MySQL et Postgres mais sur Oracle avec de tels paramètres il charge tout dans son cache et basta. Les écritures hormis les journaux se font en différer.
Bref ce n'est que du microbenchmark et il n'y a rien à en tirer.

D'ailleurs je pense qu'il serait également de faire le test hors Docker car celui-ci utilise un système de fichier virtualisé. Certains logiciels sont capables de détecter le type de partition et de s'adapter, d'autres non.

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.

Je vois pas trop le rapport strict entre respect des standards et performance (si ce n'est une meilleure intéprétation du sens des requêtes et un meilleur travail de l'optimiseur). Mais cela soulève également un autre point dans le choix d'une base de données (SGBDR ou pas) : choisir aussi ses fonctionnalités.

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.

Cela peut définir la taille et l'organisation du stockage des caractères et donc influencés les tests. De même valider l'adéquation entre les paramètres du client et ceux du serveur pour limiter un overhead de codage/décodage.

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.

Le mieux serait de générer un fichier d'entrée aléatoirement et de le réutiliser pour tous les scénarios.

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)

Tout à fait. Tout test de performance doit prendre en compte un scénario réel. Donner le débit/temps sur des fragments unitaires ne dit pas grand chose. Comment le SGBD gère les actions concurrentes (row/block/page/table contention, buffer, etc.) sont des éléments invisibles dans le microbenchmark.

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.

Ou même pour des requêtes plus complexes ou l'écriture. Mais il faut savoir que la plupart des solutions ont sacrifiés des fonctionnalités (persistence, transaction, journalisation, etc.). Il faut donc comparer ce qui est comparable.

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.

En fait ce n'est pas spécifique à MySQL et on peut parfois même tuner pas mal de paramètre concernant le stockage. Je prends pour exemple les très nombreux paramètres "physique" sous Oracle 12 : http://docs.oracle.com/database/121/...2.htm#i2126711
Dans des cas d'utilisation spécifique ou de fortes sollicitations, un paramétrage aux petits oignons peut faire une grande différence ! A condition d'avoir un bon DBA ou un expert sous la main ...

[JPLAROCHE]

BONJOUR,

MySQL semble plus adapté pour les sites web simples qui ne nécessitent pas de requêtes complexes.

reponse je fais avec Postgresql du web et cela me vas très bien.

quand je li que l'on ne peu connaître qu'une bd j poufffffff
j'ai travaillé pendant plus de 40ans avec DB2 , j'étais bien content lors des début de PHP d'avoir Mysql, et depuis la reprise de Mysql par oracle , je me suis penché sur Postgresql je peux dire qu'elle est très performante.
une BD aussi vrais qu'elle le soit , n'ai pas réservé a tel type de programmation ou tel secteur d'application. Allons allons ne vous emballer pas. je n'ai pas parler de SQLite (qui pour moi n'ai pas un sgbd tel que postgrsql...) par contre n'a pas son pareil pour quelque chose d'embarqué. Ou pour faire un outil indépendant.... bref comparer des SGBD il aurait fallu mette Oracle MSsql en plus mais cela n'est que mon avis.
@bientôt

[ddoumeche]

Vous n'êtes pas autorisés à publier les résultats des benchmarks de Sql Server ou Oracle sans autorisation de l'éditeur :

http://stackoverflow.com/questions/1...rformance-test

Je n'ai pas compris pourquoi l'auteur n'avait pas utilisé sysbench.

[fsmrel]

Bonsoir,

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

[Artemus24]

Salut Fsmrel.

Désolé de te contredire, mais dans le livre de Gabrielle Wiorkowski "DB2 for Z/OS & OS/390, development for performance", à la page 42 du tome 1, je lis :

DB2 was first announced as a product by IBM in June of 1983. There have been numerous various and releases since the original announcement as summarized below. More are expected in the futur :
V1.1 : June 1983
V1.2 : Feb. 1986
V1.3 : May 1987
V2.1 : April 1988.
V2.2 : October 1988
V2.3 : September 1990
V3.1 : March 1993
V4.1 : September 1994
V5.1 : April 1996
V6.1 : May 1998
V7.1 April 2000

Comme mon livre est la quatrième édition, je n'ai pas la suite des mises en service des autres versions.

ET pour être encore plus précis sur DB2, la version 1 release 1 a été annoncée le 7 juin 1983.

On retrouve cette information dans : https://www.redbooks.ibm.com/redbooks/pdfs/sg246763.pdf
en faisant une recherche sur 1983.

@+

[fsmrel]

Bonsoir,

ET pour être encore plus précis sur DB2, la version 1 release 1 a été annoncée le 7 juin 1983.

On retrouve cette information dans : https://www.redbooks.ibm.com/redbooks/pdfs/sg246763.pdf
en faisant une recherche sur 1983.

Pas la peine d’aller dans les Red Books, la lettre d’annonce est ici.


Les choses sont plus subtiles. DB2 a un copyright de 1982. La première annonce fut prévue pour septembre 1983, puis avancée au 7 juin, afin de sensibiliser les utilisateurs potentiels avant les vacances.

Mais annoncer n’est pas synonyme de mettre à disposition. A cette époque, seuls des privilégiés purent utiliser DB2, en « limited availability » et nous, les utilisateurs ordinaires, avons dû attendre la « general availability », prévue pour le « third quarter 1984 ». Et on a attendu jusqu’à ce fameux 3e trimestre...


Dans le même sens, la V2 de DB2 fut annoncée pour avril 1988 : en juin de cette année-là, il fallait que je secoue cette V2, mais elle n’était pas disponible. Toutefois, comme je binômais avec des gens d’IBM et qu’il y avait urgence, ceux-ci ont fait en sorte qu’on m’envoie la bande depuis les États-Unis.

Toujours dans le même sens, la lettre d’annonce de la V12 de DB2 est manifestement datée du 6 octobre 2015, mais ça n’est pas pour autant que cette version est aujourd’hui disponible :

« IBM will make DB2 12 for z/OS available to a select group of clients in a closed Early Support Program (ESP) on March 4, 2016. »

D'ici quelques jours, ces heureux élus pourront s’éclater, nous autres, on attendra (six mois, un an ?)


Ayons une pensée pour Gabrielle, qui nous a quittés il y a 4 ans à quelques jours près...

[Gugelhupf]

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 - Visualiser dans une fenêtre à part

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