Faites-vous des test de volume sur votre base ?

[berceker united]

Bonjour,
Je voulais savoir si vous faisiez des test de volume. C'est à dire, placer une grande quantité d'information afin de savoir si la structure tien le coup, s'il y a moyen d'optmiser la structure les requêtes. Si oui que faite -vous exactement

Dans ce domaine "qui peut le plus peut le moin" est-ce vrai pour le SGBD. Ce que je veux dire par là qu'une requête peut donner de très bon resultat pour de fort volume mais pour un petit volume cela peut donner des performances médiocre.
vrai, faux ?
Par contre l'inverse je dirais vrai. C'est à dire qu'une requête pour faible nombre d'enregistrement peut avoir des resultats catastrophique sur du gros volume.
Merci

[kazhar]

Je confirme pour la dernière partie. Avec peu d'enregistrements, un accès à un document XML sera plus rapide qu'un accès à une base de données.
Après, si cela devient trop important, la recherche dans le document XML prends trop de temps.

Généralement, si tu es sur d'avoir moins de 50 n-uplets, tu peut utiliser un document xml.

[fsmrel]

Bonjour Berceker united,

Si vous-même ou votre DBA ne faites pas de tests de comportement du SGBD dans un contexte à faible ou à grande volumétrie, partez du principe que vous êtes mort !

Les SGBD dits relationnels sont dotés d’algorithmes d’optimisation plus ou moins intelligents qui se basent sur la présence de composants déterminants pour la performance : essentiellement des index. Mais cela ne suffit pas : ils se basent sur des données statistiques telles que le nombre de lignes dans les tables, le rendement (facteur de filtrage) des index, la distribution des clés dans ces index et mille autres éléments orientés performance.

Supposons que le SGBD sache que votre table comporte un million de lignes pour un million de clients. Supposons encore qu’il existe un index de type UNIQUE sur le N° de client. Une requête du genre

SELECT col1, col2, ..., coln FROM CLIENT WHERE N°Client = 123

alors la réponse sera (en principe) instantanée.

Supposons maintenant que la clé de l’index soit composée (dans l’ordre) du type de client, suivi du N° de client : pour chaque type de client, le SGBD ira vérifier s’il existe un client 123. Il balaiera probablement la grande majorité des feuilles de l’index, avant de plonger dans les données à extraire, ce qui risque d’être long.

Supposons maintenant que le SGBD ne sache pas que votre table comporte réellement un million de lignes, tout simplement parce qu’on ne le lui a jamais dit. En supposant qu’à la création de la table, il utilise une valeur par défaut pour le nombre de lignes de cette table, par exemple 25 lignes : il se dira qu’en une ou deux entrées/sorties il aura chargé la table complète en mémoire et se dispensera en conséquence des services de l’index, au bénéfice d’un balayage de la table. En l’occurrence les temps de réponse seront catastrophiques. Moralité, il est nécessaire que le catalogue relationnel soit au courant de l’ordre de grandeur de la volumétrie de la table.

Avec mon SGBD, à savoir DB2 for z/OS cela est simple : il est des colonnes de tables du catalogue relationnel que j’ai le droit de mettre à jour (sous réserve que le DBA m’ait donné les autorisations), notamment et comme par hasard, le nombre de lignes de la table. Donc juste après avoir créé ma table, elle est vide, mais je peux dire au SGBD qu’elle contient un million de lignes. Si le SGBD que vous utilisez ne vous autorise pas cette facilité, alors constituez un jeu d’essai pertinent en terme de volumétrie (disons 20 000 clients dans mon exemple) et exécutez l’utilitaire de prise de statistiques (RUNSTATS, UPDATE STATISTICS, ...)

Une fois que le SGBD a connaissance des informations à caractère statistique, vous pourrez lui soumettre vos requêtes et lui demander comment il se charge de les exécuter, notamment dans sa façon d’utiliser vos index (instructions EXPLAIN, SHOWPLAN, ...)

Si je me rends compte que la performance ne sera pas au rendez-vous, je reverrai mes requêtes, mettrai en œuvre les index qui vont bien, etc. jusqu’à ce que tout aille bien. En cas d'insuccès, cela peut aussi inciter à demander à l'utilisateur de revoir ses délires à la baisse...

[berceker united]

Merci beaucoup de ton intervention car je connaissais pas cette partie des SGBD qui la connaissance du volume d'une ou des tables à parcourir. Dans mon projet j'utilise mysql 5 et SqlServer. Je sais que EXPLAIN permet de retourner des informations très importante mais je ne sais pas forcement bien l'interpréter. Je pense qu'il y a des tuto sur ça.

J'ai besoin de ces réponses car je conçois un application e-commerce générique et il faut que ça puisse être fluide même avec du gros volume.
bien souvent un développeur php ne se préocupe pas trop de ce genre de détail et s'appuys beaucoup sur les performances de la machine.