Une clé primaire de 5+ colonnes est-elle mauvaise pour une grande table (100 millions +)?

Je lisais quelques problèmes de base de données réels, et un projet avait une table de 100 millions de lignes plus qui avait 5 colonnes comme principal. Je pense que c'est mauvais, mais quelqu'un peut-il me dire exactement pourquoi?

La table était une sorte de micro table de cumul / agrégation, donc les 5 colonnes étaient comme (jour, market_id, product_id ...). Au début, je pensais qu'une clé primaire à 5 colonnes n'était pas idéale, mais plus je pensais, je ne pouvais pas vraiment trouver une bonne raison pour laquelle elle était mauvaise.

C'était dans une discussion de fin de soirée avec la moitié des ingénieurs de l'entreprise. Quelqu'un vient de mentionner que c'était une mauvaise conception, a reconnu un ingénieur senior, mais personne n'a vraiment expliqué pourquoi. Essayant ainsi de rechercher la question par moi-même!

Il existe des problèmes de performances avec des clés primaires très complexes. Et il se peut qu'il ne se défende pas contre la duplication aussi bien qu'une clé primaire plus simple.

Cependant, il existe un modèle de conception qui produit fréquemment des tables avec une clé primaire composée de six composants environ. Ce sont des tables de faits de schéma en étoile. Si la table de faits d'un schéma en étoile a six dimensions, alors la clé primaire aura six composants. Je n'ai jamais vu de table de faits sans clé primaire déclarée, et je pense que cela en vaut la peine, même si le processus ETL doit encore être rédigé avec beaucoup de soin.

Certaines bases de données de rapports imitent le modèle du schéma en étoile, même s'il n'est pas explicitement conçu de cette façon.

Plus de 100 millions de lignes ne sont pas trop grandes pour une table de faits, en particulier avec les mégadonnées d'aujourd'hui.

La table en question était une table de cumul / agrégation.

Alors ce n'est pas seulement bien, c'est "juste".

Et cela sent comme un tableau récapitulatif, car il commence par day.

Avez-vous des index secondaires? N'oubliez pas que si vous utilisez InnoDB, le reste des colonnes PRIMARY KEY sera collé à la fin de l'index secondaire. Encore une fois, ce n'est pas nécessairement un problème.

100 millions de lignes, c'est beaucoup pour un cumul. On dirait que la table est trop fine. Autrement dit, peut-être que si (date, a, b, c, d) vous devez avoir 4 cumuls avec des PK comme (date, a, b, c), (date, b, c, d), (date, c, d, a), (date, d, a, b) (ou certaines combinaisons appropriées). Je fais cela, chacun peut ne faire que 10 millions de lignes, ce qui rend les rapports encore plus rapides, tout en ayant presque autant de flexibilité dans les rapports.

Ou peut-être passer à (semaine, a, b, c, d), conduisant à peut-être seulement 14 millions de lignes. (Probablement plus.)

Utilisation de PARTITION pour faciliter l'élagage --- Ingestion à grande vitesse --- Conseils pour l'entrepôt de données --- Tableaux récapitulatifs . Celles-ci résument bon nombre des techniques que j'ai développées dans plusieurs projets DW. Comme vous pouvez le déduire, chaque projet est différent. Le nombre «typique» de tableaux récapitulatifs (d'après mon expérience) est de 3-7. La cible dans le résumé est 10 lignes de faits -> 1 ligne de résumé. (Cela peut être une «médiane».) Dans un cas rare, j'ai résumé un tableau récapitulatif. Dans un autre cas rare, j'ai PARTITIONNÉ un tableau récapitulatif à bon escient; généralement, les tableaux récapitulatifs sont suffisamment petits pour être assez rapides pour un accès direct à partir d'une interface utilisateur.

Eh bien, avoir un PK avec plus de 5 colonnes n'est pas nécessairement mauvais en soi.

Cela devient mauvais une fois que le PK est également l'index clusterisé car celui-ci compterait comme identifiant de ligne et serait donc ajouté à chaque ligne dans un index NC. Cela augmenterait considérablement l'espace requis.

Ce serait également mauvais une fois que vous utilisez réellement le PK par un autre FK, car vous devez avoir les données de toutes les 5+ colonnes dans le tableau actuel ainsi que celui qui fait référence. Encore une fois, cela augmentera considérablement le stockage!

En termes de performances, ce sera mauvais une fois que le PK sera utilisé comme index - qu'il soit uniquement dans la table ou en conjonction avec un FK - car une clé PK plus grande contenant plus de 5 colonnes prendra plus d'espace, donc moins d'entrées seront tenir dans une page et désormais plus de pages doivent être lues pour analyser l'index.

Cela dit - il pourrait toujours y avoir une bonne raison de le faire de toute façon, comme par exemple une table de faits. Par conséquent, la meilleure réponse serait en fait comme dans la plupart des cas: cela dépend!

Cordialement Dennis

Depuis plus de 15 ans, je n'ai pas eu besoin d'une telle clé, je l'ai vue parfois et cela ne faisait que causer des problèmes. Beaucoup de problèmes. Tout d'abord, la clé primaire sert à conserver l'intégrité des données et doit être syntaxique. Ils ne devraient pas avoir de lien avec le monde réel. Pourquoi ? Une fois que le monde réel aura changé, il sera certain que votre clé primaire aura disparu et que vous devrez la mettre à jour, ainsi que toutes les informations associées.

Imaginez que vous devez vous souvenir de ce ker dans une autre table / base de données / service au lieu d'un champ dont vous devez copier plusieurs, et vous pouvez oublier de copier certains d'entre eux. Au lieu de cela, la clé primaire sysntetic n'est qu'un élément de données que vous devez fournir. Je ne mentionne pas l'unicité de l'index, qui peut être un autre sujet de discussion énorme.

Donc bref résumé, la clé primaire syntaxique (incrémentation automatique, guid, ..) est simple à maintenir, à copier, ...

Je considère donc la clé primaire syntaxique et une autre clé pour 5 colonnes que vous avez mentionnées.

Enfin, si la table est uniquement agrégée, et que jamais personne n'aura besoin de référencer une ligne par clés (mais le monde change, croyez-moi, ce sera, au moins pour moi, il change de façon permanente), je le laisserai probablement tel quel (principal clé à cinq rangées), mais dans le cas où nous en avions, cela causera toujours beaucoup de problèmes. Alors je te l'ai dit.