Comment le partitionnement de table aide-t-il?

J'ai du mal à saisir l'idée des avantages et des inconvénients du partitionnement de table. Je suis sur le point de commencer à travailler sur un projet qui comporterait 8 tableaux et l'un d'eux sera le tableau de données principal qui contiendra 180 à 260 millions d'enregistrements. Comme ce sera une table correctement indexée, je pense donc à limiter les enregistrements de table à 20 millions de cette façon, je devrais créer 9-13 tables.

Mais je ne sais pas trop comment cela améliorera les performances car ils seront assis sur la même machine (32 Go de RAM)?

J'utilise MySQL et les tables seraient MyISAM et une grande table aurait un index sur le champ id et il n'y a pas d'autres complexités comme la recherche en texte intégral, etc.

Veuillez également faire la lumière sur le partitionnement de table par rapport au partitionnement de base de données.

Ce qui suit est juste fou furieux et délirant ...

Si vous laissez toutes les données dans une table (pas de partitionnement), vous aurez des temps de recherche O (log n) à l'aide d'une clé. Prenons le pire indice du monde, l'arbre binaire. Chaque nœud d'arbre a exactement une clé. Un arbre binaire parfaitement équilibré avec 268 435 455 (2 ^ 28 - 1) nœuds d'arbre aurait une hauteur de 28. Si vous divisez cet arbre binaire en 16 arbres distincts, vous obtenez 16 arbres binaires chacun avec 16 777 215 (2 ^ 24 - 1) nœuds d'arbre pour une hauteur de 24. Le chemin de recherche est réduit de 4 nœuds, soit une réduction de hauteur de 14,2857%. Si le temps de recherche est en microsecondes, une réduction de 14,2857% du temps de recherche est nulle à négligeable.

Maintenant dans le monde réel, un index BTREE aurait des treenodes avec plusieurs clés. Chaque recherche BTREE effectuerait une recherche binaire dans la page avec un décent possible dans une autre page. Par exemple, si chaque page BTREE contenait 1024 clés, une hauteur d'arbre de 3 ou 4 serait la norme, une hauteur d'arbre courte en effet.

Notez qu'un partitionnement d'une table ne réduit pas la hauteur du BTREE qui est déjà petit. Étant donné un partitionnement de 260 milliions de lignes, il existe même une forte probabilité d'avoir plusieurs BTREE avec la même hauteur. La recherche d'une clé peut passer à travers toutes les pages BTREE racine à chaque fois. Un seul remplira le chemin de la plage de recherche nécessaire.

Développez maintenant ceci. Toutes les partitions existent sur la même machine. Si vous n'avez pas de disques séparés pour chaque partition, vous aurez des E / S de disque et des rotations de broches comme goulot d'étranglement automatique en dehors des performances de recherche de partition.

Dans ce cas, le partitionnement par base de données ne vous rapporte rien non plus si id est la seule clé de recherche utilisée.

Le partitionnement des données doit servir à regrouper les données qui sont logiquement et cohérentes dans la même classe. Les performances de recherche de chaque partition ne doivent pas être la principale considération tant que les données sont correctement regroupées. Une fois que vous avez atteint le partitionnement logique, concentrez-vous sur le temps de recherche. Si vous séparez simplement les données par identifiant uniquement, il est possible que de nombreuses lignes de données ne soient jamais accessibles en lecture ou en écriture. Maintenant, cela devrait être une considération majeure: localisez tous les identifiants les plus fréquemment consultés et partitionnez en conséquence . Tous les identifiants moins fréquemment utilisés doivent résider dans une grande table d'archives qui est toujours accessible par la recherche d'index pour cette requête "une fois dans une lune bleue".

L'impact global devrait être d'avoir au moins deux partitions: une pour les identifiants fréquemment utilisés et l'autre parité pour les autres identifiants. Si les identifiants fréquemment utilisés sont assez volumineux, vous pouvez éventuellement le partitionner.

200 millions de lignes sont certainement dans la plage où vous pourriez bénéficier du partitionnement de table. Selon votre application, vous pouvez parier certains des avantages énumérés ci-dessous:

• Facilité de purge des anciennes données Si vous devez effacer des enregistrements datant de plus de (disons) 6 mois, vous pouvez partitionner la table à la date, puis échanger les anciennes partitions. Ceci est beaucoup plus rapide que la suppression de données d'une table et peut souvent être effectué sur un système en direct. Dans le cas de l'OP, cela peut être utile pour la maintenance du système.

• Plusieurs volumes de disque Le partitionnement vous permet de fractionner les données pour répartir le trafic sur plusieurs volumes de disque pour plus de rapidité. Avec un contrôleur RAID moderne, ce n'est probablement pas un problème pour l'OP.

• Des analyses de table et de plage plus rapides Vraiment, un système opérationnel ne devrait pas faire ce genre de chose, mais un entrepôt de données ou un système similaire fera ce genre de requête en quantité. Les analyses de table utilisent principalement un trafic de disque séquentiel, c'est donc généralement le moyen le plus efficace de traiter une requête qui renvoie plus de quelques pour cent des lignes d'une table.
  
  Le partitionnement par un filtre commun (généralement basé sur le temps ou la période) permet d'éliminer de gros morceaux de la table de ces requêtes si le prédicat peut être résolu par rapport à la clé de partitionnement. Il permet également de diviser la table sur plusieurs volumes, ce qui peut donner des gains de performances significatifs pour les grands ensembles de données. Normalement, ce n'est pas un problème pour les systèmes opérationnels.

Aux fins de l'OP, le partitionnement n'est pas susceptible de générer beaucoup d'avantages en termes de performances pour les requêtes opérationnelles, mais il peut être utile pour la gestion du système. S'il existe une obligation importante de signaler des agrégats sur de grands volumes de données, un schéma de partitionnement approprié peut vous y aider.

Le partitionnement permet des réorganisations simultanées par partition, si tous vos index sont partitionnés. Sinon, les partitions sont encore beaucoup plus petites et utilisent moins d'espace de travail pour réorganiser. Et, en interne, tout "bon" SGBD peut faire des choses en parallèle avec les tables partitionnées. Cela n'inclut probablement PAS MySQL ou MyISAM, mais ...