Tests de perf Oracle/PostgreSQL/MySQL [Résolu]

[champijulie]

Bonjour à tous,

J'ai créé 3 schémas différents sous PostgreSQL et trois bases différentes sous Oracle et MySQL qui correspondent aux schémas de PostgreSQL. Pour comparer les performances des SGBDR, j'applique à ces bases 6 requêtes différentes que je vous donne ici:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
SELECT nomdossier FROM Dossier WHERE id_dossier = 12500;
SELECT nomdossier FROM Dossier WHERE nomdossier LIKE 'PC%';
SELECT count(DISTINCT nomdossier) FROM Dossier WHERE nomdossier LIKE 'PC%';
SELECT count(DISTINCT nomdossier) FROM Dossier D, Modele M WHERE D.id_modele = M.id_modele AND M.codeADS = 'PC';
SELECT count(*) FROM 
( SELECT d.id_dossier, nomdossier
FROM Dossier D, DossierEtat DE
WHERE D.id_dossier = DE.id_dossier (+)
AND (DE.id_etat = 2 OR DE.id_etat IS NULL));
SELECT DISTINCT D.Id_dossier, DE1.DateLimiteLegale  , DE1.DateLimitePrevue  , DE1.DateEffective  , DE2.DateLimiteLegale  , DE2.DateLimitePrevue  , DE2.DateEffective  , DE3.DateLimiteLegale  , DE3.DateLimitePrevue  , DE3.DateEffective  , DE4.DateLimiteLegale  , DE4.DateLimitePrevue  , DE4.DateEffective  
FROM Dossier D  , DossierEtat DE1 , DossierEtat DE2 , DossierEtat DE3 , DossierEtat DE4 
WHERE D.id_dossier IN 
	(  SELECT DISTINCT DE.id_dossier FROM DossierEtat DE,  Dossier VLD WHERE DE.id_dossier = VLD.id_dossier  AND VLD.CodeADS = 'PC' AND id_etat = 1 
	AND DateEffective BETWEEN to_date('01/12/2002','DD/MM/YYYY')  AND to_date('01/01/2003','DD/MM/YYYY')  
AND DE.id_dossier IN  
	(SELECT DE.id_dossier FROM dossieretat DE WHERE id_etat = 30 AND DateEffective BETWEEN to_date('01/12/2002','DD/MM/YYYY')  
	AND to_date('01/01/2003','DD/MM/YYYY')  
AND DE.id_dossier NOT IN  
	(SELECT id_dossier FROM dossieretat WHERE id_etat = 150 AND DateEffective IS NOT NULL)  
AND DE.id_dossier NOT IN  
	(SELECT id_dossier FROM dossieretat WHERE id_etat = 152 AND DateEffective IS NOT NULL) ) )   
AND D.Id_Dossier = DE1.Id_Dossier (+)  AND DE1.id_etat (+) = 1 AND D.Id_Dossier = DE2.Id_Dossier (+)  
AND DE2.id_etat (+) = 30 AND D.Id_Dossier = DE3.Id_Dossier (+)  AND DE3.id_etat (+) = 150 
AND D.Id_Dossier = DE4.Id_Dossier (+)  AND DE4.id_etat (+) = 152 ORDER BY DE1.DateEffective;

Je sais que la dernière est imbuvable... J'ai adapté les requêtes en fonction du SGBDR que j'utilisait et il n'y a pas d'erreur de syntaxe. J'exécute ces requêtes avec un nombre et une taille de données équivalentes pour chacune des bases (ou schémas) bien entendu. Et je trouve les résultats suivants:

Pour la petite base (110 Mo de données):
Oracle: 15ms 16ms 15ms 15ms 31ms 31ms
Postgre: 16ms 16ms 31ms 31ms 31ms 31ms
Mysql: 16ms 02ms 05ms 03 ms

Comme les deux dernières requêtes sont des requêtes imbriquées, elles ne sont pas prises en compte par MySQL.

Pour la moyenne base (2Go de données):
Oracle: 15 ms 16 ms 47 ms 140 ms 500 ms 859 ms
Postgre: 15ms 265ms 125ms 141ms 1391ms 1072ms
MySQL: 03 ms 30 ms 20 ms 22 ms

Pour la plus grosse base (8 Go de données):
Oracle: 15 ms 16 ms 700 ms 1 s 2 s 4 s
Postgre: 16ms 1735ms 750ms 0.92s 4.34s 14s
MySQL: 06 ms 1.20s 6.89s 7.41s

Et là, on voit bien que MySQL est plus performant qu'Oracle sur la petite et la moyenne base alors cela m'étonne beaucoup et je voulais savoir si c'était normalou si il y a quelque chose (un facteur par exemple) que j'ai négligé.

J'attends vos réponses à ce sujet. Peut-être que quelqu'un a pu trouver des résultats similaires.
Merci d'avance
champijulie.

[orafrance]

est-ce que tu as créé des indexes ?

[champijulie]

Oui,

les index sont créés et présents sur chacunes des bases ou schémas. En fait, quel que soit le SGBDR, les bases (ou schémas) ont la même structure et les mêmes contraintes. C'est pour ça que je ne comprends pas. Je pensais avoir des résultats où Oracle était le plus performant et MySQL était le moins performant.

Voilà
champijulie.

[orafrance]

c'est effectivement très étonnant, que MySQL soit plus performant pourquoi pas mais surement pas avec un tel écart. T'es sûr que les indexes sont bien utilisés ?

[champijulie]

Sous Oracle et PostgreSQL je suis sur que oui car j'ai vu le plan d'exécution des différentes requêtes mais par contre je n'ai pas vu sous MySQL.
Je vais voir ça.
Il n'a peut être pas le même plan d'exécution.

@+
champijulie.

[orafrance]

les stats sont calculées ? Tu peux montrer le plan Oracle STP ?

[champijulie]

En fait je croi que j'ai trouver d'où ça vient.
Il s'agirait d'une erreur d'uniformisation d'écriture de temps .

Je m'explique. Les "requêteurs" d'Oracle et de MySQL écrivent les temps sous la forme:
00:00:00.00 (heure, minute, secondes, millisecondes) et c'est de là que vient le hic. Si on se réfère aux grandeurs, on voit qu'une seconde est égale à 1000ms (1ms=10^(-3)s)
Or sous Oracle (SQL plus) cette règle n'est pas respectée. Si on trouve un temps égale à 0.31 s, ça correspondra à 31 ms et non à 310 ms. Mais par contre Mysql applique cette règle ce qui veut dire que quand je trouve un résultat d'exécution à 0.03s cela correspond à 30 ms. Je m'en suis rendu compte quand j'ai fait les tests par le lien ODBC.

J'espère que tu as tout compris.
A la prochaine .
champijulie.

[orafrance]

non 0.31 = 310ms... même sous Oracle

comment tu affiches ces temps ?

[titides]

Comme les deux dernières requêtes sont des requêtes imbriquées, elles ne sont pas prises en compte par MySQL

si MySQL ne prend pas en compte certaines requêtes, c'est pas un peu normal que ca va plus vite ?
Moins on en fait, plus vite on va non ?

[champijulie]

Envoyé par orafrance

comment tu affiches ces temps ?

En fait, sous SQL + tu tappes la requête set timing on pour avoir le temps qui s'affiche et ensuite tu tappes ta requête. Moi, j'ai remarqué la différence quand je suis passée par l'intermédiaire de l'ODBC. J'avais des temps quasi équivalent sous Postgre alors que ce n'était pas le cas sous Oracle. Et si j'applique la solution plus haut, on trouve des ecarts similaires pour Oracle comme pour PostgreSQL. Et c'est pareil avec MySQL quand j'applique la solution énoncée plus haut. Sinon et si je suis ton raisonnement, la requête serait plus rapide à effectuer avec le pilote ODBC que sans le pilote. Je suis perdue

Envoyé par titides

si MySQL ne prend pas en compte certaines requêtes, c'est pas un peu normal que ca va plus vite ?

En fait, je regarde les temps d'exécution de chacunes des 6 requêtes que j'exécute. Dans les requêtes 5 et 6, j'ai des sous requêtes. Donc je ne peut donc pas avoir de résultats pour les deux dernières requêtes. Mais les tests que je fais ici sont sur une requête indépendante de toutes les autres. Je ne sais pas si je me suis bien exprimée mais bon...

Voilà.
@+
champijulie[/quote]

[orafrance]

Envoyé par champijulie

En fait, sous SQL + tu tappes la requête set timing on pour avoir le temps qui s'affiche et ensuite tu tappes ta requête.

ha OK, je comprend

SQL> set timing on
SQL> select sysdate from dual;

SYSDATE
--------
21/07/05

Ecoulé : 00 :00 :00.01

En effet c'est heure : minute : seconde . centiseconde

Oracle aime bien les centisecondes

Donc en effet 00.01 = 0 s et 1 cs soit 10 ms

Ca donne quoi les temps du coups ?

PS : non, ODBC est plus lent bien entendu

[champijulie]

Donc maintenant, les temps ça donne:
j'ai mis pour simplifier:
O pour Oracle, P pour postgreSQL et M pour MySQL
Tous les temps sont en millisecondes

Pour la petite base:
O:15 16 15 15 31 31
P:16 23 16 16 31 31
M:16 60 50 30 00 00
Pour la base moyenne:
O:15 016 047 140 0500 0860
P:15 250 110 140 1390 1200
M:30 300 200 220 0000 0000
Pour la grosse base:
O:15 0016 0700 1000 2000 04000
P:15 1730 0750 0900 4340 14000
M:60 1200 6890 7410 0000 00000

Voilà les résultats que j'obtiens et les courbes ont le même aspect par les connections ODBC avec des temps un peu plus important mais pas beaucoup plus.
Donc je pense que c'est OK .
Je ferais plus attention la prochaine fois .

@+
champijulie

[orafrance]

winner is Oracle 8)

[titides]

Envoyé par orafrance

winner is Oracle 8)

il est content le p'tit Orafrance

[champijulie]

C'est normal que le winner sois Oracle.
Il est plus complet.
De toute façon, on ne peut pas avoir deux produits avec les mêmes performances et les mêmes possibilités avec une aussi grande différence de prix...
Mais moi je vois une bonne chose. Ces performances sont les résultats finaux de mon stage donc j'ai réussi ma mission...

@ la prochaine (pas avant septembre... vive les vacances )
champijulie

PS: Continuer ce sforum, c'est vraiment super pour se former. On y aprrends plein de trucs.

[Maître Kenobi]

moi, ce que je vois, c'est que PostreSQL se place très bien derrière Oracle ! et c'est un sgbd open source en plus !

[gregory.broissard]

ben effectivement la comparaison n'est pas vraiment à faire. Les SGBDR comparées sont tellement différents.

Comparer Mysql et Oracle c'est un peu comparer les vitesses de pointe d'une ferrari et d'une 2CV...

Maintenant si des gens ont les moyens de tester DB2/Oracle/Sql Server, je pense que les résultats seraient intéressants .

je peux pas moi, j'ai que du DB2 sous z/OS et du Oracle sous Unix. Il faudrait comparer sur des plate formes identiques...

[Benoit_Durand]

Envoyé par champijulie

Comme les deux dernières requêtes sont des requêtes imbriquées, elles ne sont pas prises en compte par MySQL.

MySQL 4.1.12 accepte bien les requête imbriquées non ?
J'aurais bien voulu qu'il donne les versions des SGBD, pas grave toujours sympa comme info.

Je dois faire un entrepôt de données MySQL qui sera attaqué par BO, ça va être poilant. Les utilisateurs vont pouvoir sortir les cartes

[Maximilian]

MySQL 4.1.12 accepte bien les requête imbriquées non ?

Oui, dans sa version stable depuis l'année dernière.

Le comparatif est très intéressant mais je pense que pour être tout à fait complet il lui manque quelques précisions : hardware utilisé, plateformes, versions, réglages système effectués sur les SGBD (ou non), etc.