Discussion :

[Guizmo95]

Bonjour,

J'ai actuellement quelques requêtes qui contiennent plus de 8 jointures entre différentes tables permettant par exemple de ressortir tous les utilisateurs actifs, avec leurs données (sur plusieurs tables), qui ne sont pas banni,...

J'ai plusieurs questions :

1) Est-il plus performant de passer par une vue matérialisée rafraichie toutes les 6 heures (par exemple), ce qui va m'éviter au moins 5 jointures? ou bien garder ma requête avec toutes mes jointures (avec recalcule de l'age...) ?

2) S'il est plus performant d'utiliser une VM (vue matérialisée) : Mysql ne gère pas forcement les VM pour le moment, donc je dois créer une table que je rafraichirais toutes les 6 heures (via une vue par exemple). Avez vous une idée de la meilleure méthode pour rafraichir une table?

- Supprimer toutes les données de la table VM puis recopier toutes les données du résultat de la vue?
OU
- Faire la différence entre le résultat de la vue et les données sur la table VM. Dans ce cas comment faire la différence? existe-t-il un moyen pour faire cela??

Le nombre de données est important et je pense que la VM m'aiderait (des données déjà calculées et des jointures en moins pour de la consultation pure... Normalement ça devrait être plus rapide, non?)

Merci par avance pour l'aide que vous pourrez m'apporter.

[ericd69]

salut,

bon je me lance alors...

oui... et non... ça dépend de ton environnement, etc...

ce que tu gagnes en ressources d'un coté tu vas en grande partie le reperdre sur une super table comme ça... rien qu'en y réfléchissant:

• la taille de ta table final équivaut à la somme (à peu près) à celles de toutes les table nécessaires...
• tu génère une table qui bouffe autan de ressources mais permanente...
• parfois ça peu vraiment aider parfois moins...
• il faut que tu mettes à jour par cron ou événement...
• ça t’empêche pas de devoir faire ces mise à jour...

faut voir la gueule des requêtes... elles sont peut-être améliorables... l'environnement peut être mieux configuré, etc...

[Guizmo95]

Bonjour,

Merci pour ton retour

Ma problématique est la suivante :
Si je veux récupérer un ou plusieurs utilisateur avec sa photo de profil (dans la table photo), son type de forfait (dans la table forfait), uniquement s'il n'est pas banni (table ban),....
Je dois faire plusieurs jointure pour une seule donnée par table.

Je me suis dis "hey! mais si je met tout dans une table ça peut être plus rapide?". La question derrière est finalement la suivante :
"
Quelle est la solution qui demandera moins de ressources sachant que les données sont récupérées 500 fois par minutes :

• Faire 8 jointures dans une requête pour récupérer une seule donnée par table. Et donc, pour les données calculer (age, autre...), refaire le calcul.

ou

• Faire une table contenant 10 champs au maximum, contenant les données nécessaires déjà calculées et rafraichies toutes les 6 heures.

"
Pour information, les jointures sont plutôt basique avec parfois un ou deux condition supplémentaire sur la jointure (exemple fictif: AND photoProfil = 1)

Mon raisonnement tient-il la route?

[ericd69]

rien de traumatisant avec de bons index...
d'éventuels réglages sur le serveur si besoin...

après si ça suffit vraiment pas pourquoi pas...

impossible de te donner une réponse définitive donc...

faut voir les temps pour les requêtes...

c'est presque sur que ta vue matérialisée sera potentiellement plus rapide...

à tester donc...

[CinePhil]

Quel volume de données est à traiter par ce genre de requête ?

les données sont récupérées 500 fois par minutes

Ça veut dire qu'il y a 500 utilisateurs qui se connectent par minute ?

Normalement, si une même requête revient très régulièrement, le SGBD la reconnaît et ne recalcule pas son plan d'exécution. Et comme les données sont encore probablement en mémoire, l'accès aux données est très rapide.

Maintenant, avec le mauvais MySQL, il faut s'attendre à tout !

[Guizmo95]

Merci pour vos réponses.

La requête sera difficilement la même étant donné que c'est une requête adaptée en fonction de la recherche que l'utilisateur fait, cad que selon les critères qu'il renseigne, la requête ajoutera ou non des jointures pour aller récupérer les données nécessaires.

Donc pour faire général :

1) Si j'ai une base de 500 000 utilisateurs. Et qu'il y a 500 requêtes par minutes sur une recherche contenant des jointures en plus ou en moins en fonction des critères que l'utilisateur a choisi alors il est préférable d'utiliser une vue matérialisée?

2) Si j'ai une base de 5 000 utilisateurs. Et qu'il y a 5 requêtes par minutes sur une recherche contenant des jointures en plus ou en moins en fonction des critères que l'utilisateur a choisi alors il est préférable de garder les jointures sans la vue matérialisée?

[CinePhil]

Ce que je voulais dire, c'est que j'étais étonné qu'il y ait 500 nouvelles connexions d'utilisateurs par minute qui nécessiterait d'aller chercher en une minute les informations de 500 utilisateurs différents.

Parce que pour un utilisateur, une fois connecté, tu peux enregistrer ses infos en sessions pour éviter d'aller rechercher ses infos dans la base à chaque fois qu'il fait une action.

[ericd69]

ce sera toujours plus ou moins les mêmes requêtes...

si tu engendre une requête paramétrique avec 1 à 3 critères possibles alors tu n'engendre en fait que 6 requêtes possibles en terme de plan d'exécution...
le nombre de permutation possible pour les critères est n(n-1)... soit environ n²...
donc l'optimiseur va pas mémoriser des milliers de requêtes...

après tout est interdépendant:

• ta compétence sql...
• le matériel
• la configuration...
• le volume des données...

bref aucune réponse garantie ou définitive surtout sur des suppositions aussi lights en info...

après la probabilité qu'une donnée soit récupérable sans lire les fichiers des tables dépend aussi de plein de choses...
si tu démarres le sgbd alors tu es dans le pire, tous les buffers sont vides et donc ce sera les temps d'exécutions les plus poussif
sinon c'est très aléatoire vu que ça dépend des réglages de buffers et de la répétitivité de l'accès à ces données et évidemment de l'indexage fait...

[SQLpro]

le principe d'une vue matérialisée (Oracle) ou indexées (SQL Server) est effectivement de contenir les données ce qu'une vue ordinaire ne fait pas.
MAIS, la particularité est que les données sont recalculées par différence et non pas par ré-exécution de la vue....

Imaginez ce que cela couterait sur une table de 100 millions de lignes !!!

Autrement dit votre solution n'est pas viable car mySQL implémente pas ce genre de technique...

A +

[Guizmo95]

Merci à vous pour vos réponses
Je vais donc rester avec plusieurs jointures et je vais optimiser au mieux la config, le serveur, la requête...