[optimisation] votre avis sur le temps d'execution d'un exemple

[Satch]

Bonjour,

Je me retrouve dans un cas qui ne s'était jamais présenté à moi et que je ne peux pas tester maintenant.

J'aurai besoin d'une estimation de votre part sur le temps que peut prendre une requête (assez optimisée).

Voici les données :
- Jointures sur 7-8 tables
- 3 requêtes imbriquées
- des index sur les clef primaires
- 200 000 enregistrements environt
- le retour comportera une centaine de lignes, dont on aura une quinzaine de champs, répartis sur les différentes tables qu'on a dans les jointures


Je sais parfaitement qu'il est impossible de prédire le temps d'execution à partir de ces données, mais d'après vous, quelle temps à peu pres cela peut-il prendre ?
10 secondes ?
une minute ? 2 minutes ?

A vrai dire j'en ai aucune idée.

[qi130]

... c'est comme le fût du canon: un certain temps


qui va dépendre aussi des index positionnés sur les colonnes utilisées dans les WHERE (et peut-être aussi GROUP ?, me souviens plus )

et du taux de désorganisation des tables.

[Satch]

Les index il n'y en a que sur les id.

Dans le where il n'y aura que des champs=qqch ou champ n'a pas d'index.

et admettons que les tables soient toutes fraîches, donc bien organisées.

Est-ce que ça peut donner une meilleure idée ?

[qi130]

A priori, non, et je doute que tu puisses obtenir un résultat sérieux qui résiste à l'analyse du "comment il a été obtenu".

En vrac, et au delà de la seule base, il y a aussi le SGBD qui est à considérer, et au delà de lui, le serveur:
est-il dédié ?
quelle est/sera sa puissance ? sa capacité RAM ?
Quelle rapidité des HD ?
quelle typologie réseau ? (accès direct en LAN ou passage par un WAN, débit théorique/pratique, Qos (paquets perdus ?), etc...

bref, à moins d'avoir des dons particuliers, la tâche est impossible

Le seul "truc" sera de faire un benchmark à 10% de remplissage de la base, puis tenter d'extrapoler le résultat, mais c'est pas fiable à 100% car le SGBD peut décider de changer son mode d'accès aux données (d'où l'utilité d'un suivi de tuning des bases avec les fameux explains afin de vérifier la pertinence des index par rapport aux requètes qu'ils sont censés améliorer).

[yizashi]

Le nombre de lignes retournées et le nombre d'attributs du Select je crois que ça n'a que très peu d'influence.

Tu dis faire 7 jointures mais quelle est la taille des tables? Si elles font toutes 200 000 lignes c'est plus long que si y'a une table de 200 000 et 6 de 5000 lignes.

Quoiqu'il en soit je pense que ça restera en dessous des 10 secondes. Au hasard je dirais 4.5 secondes.

Je sais pas si tu sais ce que c'est un index mais s'ils sont bien fait ça doit permettre à la base de données de sélectionner une ligne (parmi 200 000) en 15 tentatives, ce qui se fait très vite.

Ce que je peux te dire par exemple c'est que sélectionner une ligne parmis 20 000 lignes c'est instantané sur un P3 500mb (bon ok peut-être 1/4 secondes j'ai jamais compté).

[Satch]

Je ne peux malheureusement rien changer dans la base. Les index sont ce qu'ils sont et le resteront.

En fait mon problème se résume à ceci :
je dois aller voir un peu tout ce qu'il y a dans la base afin de compter certaines choses et d'extraire certains champs.
2 solutions donc :
- Je parcours tout comme un bourrin, et je fais le tri en programmation (JAVA).
- Je fais des requêtes bien spécifiques qui me retourneront exactement ce que je veux. Mais certaines requêtes seront presques semblables.

La 2ème solution semble bien entendu la meilleure. Mais les requêtes devront être optimisées au top.

Après réflexion, je pars sur la 2ème.

[qi130]

Je ne comprends pas ce qui peut empêcher l'ajout d'index...

Il ne s'agit pas de mettre le modèle par-terre, juste d'améliorer les performances.

Si le proprio de la base comprend ça, c'est gagné, et je ne connais pas de responsable qui "cracherait" sur un gain de 50% en temps de réponse

[Luc Orient]

Pour moi, il faut coder la requête et demander au SGBD (c'est lequel d'ailleurs ?) qu'il indique les chemins d'accès choisis (en DB2, par exemple ça s'appelle la fonction EXPLAIN).
Ce n'est qu'à partir de cet élément de base qu'on peut raisonnablement donner une estimation crédible.

Je ne peux malheureusement rien changer dans la base. Les index sont ce qu'ils sont et le resteront.

Avec ce postulat de départ, aucun travail sérieux d'optimisation de la requête ne peut être effectué. C'est comme vouloir courir le marathon en s'imposant dès le départ un sac à dos de 30 kilos ...

[Satch]

Je n'ai pas de SGBD en particulier. ça DOIT être portable. Donc il faut que j'optimise les choses optimisables indépendamment du SGBD.

Finalement pour les index, ça pourra se faire.

J'avoue que je ne sais pas vraiment quoi indexer.
Si j'ai bien compris, pour des perfs optimale, il faudrait que ce soit les champs qui servent aux jointures qui soient indexés ?

[Luc Orient]

Envoyé par Satch

Je n'ai pas de SGBD en particulier. ça DOIT être portable. Donc il faut que j'optimise les choses optimisables indépendamment du SGBD.

C'est curieux comme démarche ...
On peut tout à fait écrire du SQL portable et c'est même plutôt sympathique comme idée mais à un moment ou un autre il faut bien "incarner" la requête sur un SGBD donné ...
De plus et comme je l'indiquais les SGBD disposent de cette fonction de détermination des chemins d'accès.

Finalement pour les index, ça pourra se faire.

J'avoue que je ne sais pas vraiment quoi indexer.
Si j'ai bien compris, pour des perfs optimale, il faudrait que ce soit les champs qui servent aux jointures qui soient indexés ?

Oui c'est une bonne méthode d'indexer les prédicats de jointure.
On peut éviter les index:
- sur les petites tables
là ça veut dire que la performance n'est pas un problème vu la volumétrie
- si les colonnes en cause si elles sont peu sélectives
là c'est pas forcément une bonne nouvelle car ça veut simplement dire que la présence d'un index n'améliore pas de manière significative la performance qui n'est pas terrible au départ

[Satch]

Envoyé par Luc Orient

C'est curieux comme démarche ...
On peut tout à fait écrire du SQL portable et c'est même plutôt sympathique comme idée mais à un moment ou un autre il faut bien "incarner" la requête sur un SGBD donné ...

Hé bien non justement. C'est une application qui DOIT tourner sur tous les SGBD courants.

En tout cas merci pour les infos.

[WOLO Laurent]

Envoyé par Satch

Bonjour,

- des index sur les clef primaires
A vrai dire j'en ai aucune idée.

Il est unitile et contre performance d'ajouter un index à une clé primaire car par définition, une clé primaire est un index primaire étendu.

[Luc Orient]

Envoyé par WOLO Laurent

Il est unitile et contre performance d'ajouter un index à une clé primaire car par définition, une clé primaire est un index primaire étendu.

C'est quoi un "index primaire étendu" ?

Pour moi une clé primaire au niveau du MLD/MPD se traduira au niveau du DDL par la création d'un ordre tel que (exemple tiré de DB2 for z/OS que je connais) :

Code :

1
2
3
 
CREATE UNIQUE INDEX
 index-name ON table-name (col1, col2, ... ) ;

Effectivement, on ne peut pas ajouter un index à une clé primaire puisque c'est déjà un index ...

A vue de nez et d'après expérience professionnelle ça risque de ramer pas mal si tu as 200.000 enregistrements et surtout des jointures...

Faut s'attendre à des temps de traitements supérieurs à 5 min.
Maintenant c'est une estimation qui tient qu'à moi.
J'ai surement tout faux en disant-cela
Faut voir le serveur , les performances du SGBD...

Solution : faire des procédures SQL et apprendre PL-SQL sous Oracle ou Transact-SQL sous SQL-Server par exemple .
Sous MySQL on peut faire des scripts en C pour optimiser je crois
Mais c'est pas portable

[WOLO Laurent]

Il y'a un article de sqlpro sur l'optimisation des performances.