J'ai une grande table (plusieurs 100 millions de lignes) que je voudrais partitionner efficacement. Ma question est de savoir s'il existe un compromis entre la taille de la partition et le nombre de partitions. Pour autant que je sache, la plupart des requêtes sur une colonne utilisée dans la partition seront plus rapides car la requête (pour la plupart des requêtes) devra uniquement rechercher dans la partition applicable à la requête. Ainsi, il serait logique que, pour maximiser l'efficacité, vous devez diviser une grande table en nombre maximal de partitions, par conséquent, en faisant chaque partition aussi petite que possible. Dans le cas de MySQL, cela signifie 1024 partitions. Mais y a-t-il un inconvénient de performances à avoir un grand nombre de partitions? Est-ce le cas, comment trouve-t-on le nombre optimal de partitions?

Remarque: Il y a déjà une question quelque peu similaire sur stackoverflow , mais une seule réponse, qui (de mon point de vue) manque la cible. Je vais donc poser la question à ma façon ... j'espère que c'est plus clair

Comparons-les

TAILLE DE LA PARTITION

Si vous disposez des éléments suivants:

• 100 millions de lignes dans une table
• Indexation BTREE
• Chaque page du BTREE contient 1024 clés

À quoi ressembleraient les mesures?

Puisque LOG (100000000) / LOG (2) = 26.575424759099, un index BTREE avec 1024 clés par page treenode aurait une hauteur d'arbre de seulement 3 (CEILING (LOG (100000000) / LOG (1024))). Avec seulement trois nœuds de pages, une recherche binaire de la clé nécessaire dans chaque treenode accédé entraînerait un élagage et une isolation d'environ 30 clés.

NOMBRE DE CLOISONS

Si vous disposez des éléments suivants:

• 100 millions de lignes dans une table
• Indexation BTREE
• Chaque page du BTREE contient 1024 clés
• Vous créez 1024 partitions

Les chiffres seraient légèrement différents.

Chaque partition doit avoir environ 97656 lignes. Que deviendraient les mesures maintenant?

Puisque LOG (97656) / LOG (2) = 16.575421065795, un index BTREE avec 1024 clés par page treenode aurait une hauteur d'arbre de seulement 2 (PLAFOND (LOG (97656) / LOG (1024))). Avec seulement deux nœuds de pages, une recherche binaire de la clé nécessaire dans chaque treenode accédé entraînerait un élagage et une isolation d'environ 20 clés.

CONCLUSION

La répartition des clés supprime simplement un niveau d'arborescence mais crée essentiellement 1024 index. Les requêtes ne connaîtront pas la différence. Le temps de recherche serait probablement au mieux nominal en faveur des partitions. Cependant, assurez-vous que toutes les données sont actives. Sinon, vous pouvez ne toucher que quelques partitions, tandis que d'autres partitions avec des données rarement utilisées prennent juste de l'espace et ne sont jamais consultées assez fréquemment pour justifier le partitionnement . Vous pouvez avoir différentes mesures de performances à craindre qui sont plus flagrantes (telles que la défragmentation interne dans XFS , ext3 vs ext4, etc.) Vous devez également vous soucier du moteur de stockage que vous utilisez, car:

• L'indexation InnoDB serait un peu plus compliquée par rapport à MyISAM en raison de la gestion d'un index clusterisé
• InnoDB effectue une double écriture des données dans ibdata1 ainsi que dans le fichier journal actuel (ib_logfile0 ou ib_logfile1)