Discussion :

[mickael.camelot]

Bonjour,

Je cherche depuis plusieurs jours à optimiser une Jointure classique entre deux tables afin que celle ci dure moins de 0.10sec

Cette jointure est exécutée 2.700.000 de fois avec des paramètres variants à chaque fois.
à 0.10sec par requête cela ferait un traitement de 3 jours.
J'en suis très loin ! ma jointure prends généralement 0.5 voir plus (jusqu'à 1.5sec) soit une estimation de 20 jours.

La Question est :
Est il envisageable de réaliser via Mysql, une Jointure simple entre deux tables "volumineuses" contenant respectivement chacune 3.000.000 d'un côté (table de sélection) et 8.000.000 de l'autre (table de liaison) le tout en moins de 0.10sec ? (sans cache, il s'agit de requêtes uniques)

Cela vous parait il raisonnable ou il est normal qu'une jointure de ce type mette autant de temps ?

cordialement

[manzeki]

Bonjour,

Je cherche depuis plusieurs jours à optimiser une Jointure classique entre deux tables afin que celle ci dure moins de 0.10sec

Cette jointure est exécutée 2.700.000 de fois avec des paramètres variants à chaque fois.
à 0.10sec par requête cela ferait un traitement de 3 jours.
J'en suis très loin ! ma jointure prends généralement 0.5 voir plus (jusqu'à 1.5sec) soit une estimation de 20 jours.

La Question est :
Est il envisageable de réaliser via Mysql, une Jointure simple entre deux tables "volumineuses" contenant respectivement chacune 3.000.000 d'un côté (table de sélection) et 8.000.000 de l'autre (table de liaison) le tout en moins de 0.10sec ? (sans cache, il s'agit de requêtes uniques)

Cela vous parait il raisonnable ou il est normal qu'une jointure de ce type mette autant de temps ?

cordialement

Les tables sont trop grandes pour atteindre ce genre de performance. Je pense qu'il faut revoir la modélisation pour baisser le coût d'exécution des requête. et aussi vu que c'est un traitement batch, il faudra penser peut-être lancer plusieurs process en parallèle.

[mickael.camelot]

Bonjour,

malheureusement c'est le découpage le plus fin que nous puissions faire.
Il s'agit d'une simple table de liaison.

Une vidéothèque doit avoir le même problème.
un film peut appartenir à plusieurs genres.

SELECT ID_FILM
FROM FILM_GENRE
WHERE ID_GENRE IN (1,2,3,4,5,6,7,8,9,10)

C'est un processus métier très commun, je ne comprends pas que ce processus soit aussi long.

Vous me confirmez donc que ce genre de traitement a un temps d'exécution proportionnel au volume de données ?

[punkoff]

bonjour,

la question que je me pose, c'est pourquoi vouloir exécuter 2.700.000 fois une requête ..? (même si certain paramètre varie.)

Ca ressemble à un traitement itératif, alors que sql est un langage ensembliste.

[tse_jc]

Bonjour,

N'oubliez pas que MySQL reste MySQL, et à ce titre l'optimiseur va vous scanner la table temporaire dans le cadre d'un WHERE .... IN

Avec MySQL privilégiez toujours la jointure à ce genre de structure de requête.

Cordialement,

Jc.

[SQLpro]

...
Vous me confirmez donc que ce genre de traitement a un temps d'exécution proportionnel au volume de données ?

Oui dans MySQL, non dans la plupart des vrais SGBD Relationnels.

En effet, MySQL dispose d'un optimiseur très pauvre par rapport à la concurrence et surtout il ne sait pas faire des requêtes multithreadées.
Par exemple dans oracle ou SQL Server, dès que le volume est important, la requête est distribuée sur tous les CPU ce qui divise d’autant les temps de réponse.
En sus, Oracle ou SQL Server savent faire des vues indexées (ou matérialisées) qui précaculent en temps réel, des données venant de requêtes. Dans ce cas, le résultat est instantané quelque soit la volumétrie !

A +

[skuatamad]

Je suis d'accord avec Punkoff, d'où viennent ces 2 700 000 exécutions...
Par ailleurs comment sont passés ces paramètres ? La requête est elle bien préparée puis exécutée 2 millions de fois ?
Je ne sais pas si ça fait une grosse différence sur mysql mais en général, c'est capitale de préparer la requête.