Version imprimable
Bonjour,
Analysant un base de donnèes de calcul de trajets avec beaucoup de paramètres, je pense avoir trouver une source de problème de performance:
La clé primaire utilisée pour tous les objets est une clé fonctionnelle dont les valeurs sont par ex:
1050000001, 210000149 ...
Pour collecter un seul trajet, la requete a mis 4mn7s....
est ce que lún déntre vous pourrait svt me confirmer que cela doit etre modifié en utilisant une clé primaire interne auto-incrémentée ?
Merci :lol:
Peut-être si vous pouvez justifier qu'"une clé primaire auto-incrémentée" est la source du problème.
Bonjour,
Non,au contraire. Ca va juste rajouter une colonne de plus, un index de plus, des jointures de plus, ...Citation:
Envoyé par hemeury
Si la clé fonctionnelle est connue dés l'insert et ne change plus ensuite, c'est la bonne clé.
Cordialement,
Franck.
Merci Pachot pour ton conseil mais j'avais toujours entendu qu'une clé primaire doit etre concise ...
Alors j'insiste, cette clé primaire (ATTR_X) contient les valeurs suivantes:
1050000001
100060
dans la meme table
Cette donnee fonctionnelle est utilisee comme cle primaire pour une trentaines de tables.
Il y a des requetes de 4 jointures et des conditions telles que: ATTR_X >= 1100000001 and ATTR_X <= 1149999999
Afin de ne pas avoir de trop grosses tables, les attributs d'un objet B ont ete regroupes dans 4 tables differentes, en fonction de leur type: domains, date, char et numeric.
Avec ce fameux attribut comme clé primaire.
Les perfos sont catastrophiques ...
Serait ce du a ce découpage en attribut ou a l'utilisation de cette clé priöaire fonctionnelle ?
Je suis entrain de regénérer les statistiques et referai des tests de perfos ensuite...
Merci pour votre contribution !!!
Les deux !
1) plus une clef est grosse moins elle est performante. En seek, pas très important. En scan beaucoup plus.
2) une modélisation doit se faire selon les formes normales avant tout, par à la façon paire clef/valeur, sinon, passer à un SGBD spécialisé NoSQL qui sait faire ce genre de chose....
A +
C'était prévisible. Lisez Bad CaRMa pour comprendre dans quelle galère vous vous trouvez, c'est assez amusant.Citation:
Envoyé par hemeury
Mouais, en fonction des requêtes le gain de sera de null à faible, pour le travail que ça engage et les risques, je ne suis pas convaincu que modifier la PK soit la bonne idée.
Je n'ai pas bien compris le concept niveau modélisation, on est plutôt sur du partitionnement vertical ou sur du modèle EAV ?
Si c'est du partitionnement vertical, je trouve étrange de le faire sur le type de données.
L'EAV, c'est globalement contre performant.
Vous pouvez nous en dire plus ?
Il n'y a vraiment aucune raison à ça.Citation:
Envoyé par hemeury
La comparaison de nombres de 4 ou 20 chiffres ne fera quasi pas de différence. Ce ne sont pas ces microsecondes qui vont poser un problème. Quand on parle d'accès par clé primaire, on parle de 100aine de microsecondes (si en cache) ou de millisecondes (si sur disque).
Tout le secret de l'optimisation, c'est de stocker ensemble ce qui va être interrogé ensemble. Donc tout découper pour se retrouver à faire des jointures à chaque requêtes, c'est pas une bonne idée.Citation:
Envoyé par hemeury
Wahooouuu ! Merci pour vos réponses !
Effectivement c'est un modèle EAV et d'après: http://www.magentix.fr/divers/modele...-database.html
"Quels sont les inconvénients du modèle EAV ?
L'inconvénient majeur du modèle EAV est sa vitesse. La répartition des données impose un nombre conséquent de jointure lors d'un enregistrement ou d'une sélection."
Donc j'ai dèjà 2 bonnes raisons pour expliquer ce pb de perf:
- modèle EAV
-clè primaire fonctionnelle trop grosse
je vais creuser aussi coté exploitation: modèle du serveur, RAM dispo, vitesse de rotation
( Merci Frédéric Brouard pour les cours dispo pour tous ! Synthétiques, bien écrit, vraiment une grande grande aide !)
et expliquer à mon responsable ces soucis !
Encore merci pour votre réactivité et le partage de vos connaissances et expèrience !
P.S: Je commence à lire BadCarMa...
Vous ne lisez que ce qui vous arrange dites-donc.
On vous dit que la clef primaire trop grosse n'est pas un vrai problème.
J'aime beaucoup votre lien sur Magento :
Et quatre lignes plus loin :Citation:
Le modèle EAV est utilisé car il est beaucoup plus souple et évolutif qu'un modèle de base de données habituel. Nous pouvons ajouter indéfiniment des attributs sans jamais modifier la structure même de la base (ALTER TABLE par exemple n'est jamais utilisé).
Du coup, quand ils rajoutent un attribut à un produit, ils ont droit aux requêtes pénibles et alambiquées ET à l'alter table dans le modèle "flat".Citation:
Pour palier au problème de performance, Magento a imaginé un système de FLAT. Le FLAT rassemble au sein d'une même table l'ensemble des données. Magento offre donc la souplesse d'un modèle EAV associé à la rapidité d'un modèle de base classique !
Chapeau ! :applo: