MySQL-Partage d'astuces pour les sous-bases de données et les sous-bases de données de tables

Le partage est un bon moyen de répartir la pression sur la base de données.

La signification la plus simple est de diviser une structure de table en plusieurs tables, qui peuvent ensuite être placées dans la même bibliothèque ou dans des bibliothèques différentes.
Bien sûr, il faut d'abord savoir dans quelles circonstances vous devez diviser la table. Personnellement, je pense que lorsque le nombre d'enregistrements dans une seule table atteint des millions voire des dizaines de millions, il est nécessaire d'utiliser des sous-tables.
1. Classification des sous-tableaux
1> Le sous-tableau vertical
divise artificiellement le contenu qui pourrait se trouver dans un même tableau en plusieurs tableaux. (Ce qu'on appelle l'original signifie que selon les exigences du troisième paradigme de base de données relationnelle, elles doivent être dans la même table.)
Raison du fractionnement des tables : Séparer en fonction de l'activité des données (car différentes données actives ont différentes méthodes de traitement sont différentes)
Cas :
Pour un système de blog, le titre de l'article, l'auteur, la catégorie, l'heure de création, etc., la fréquence des changements est lente, le nombre de requêtes est élevé, et il Il est préférable d'avoir de bonnes données en temps réel, nous appelons cela des données froides. Nous appelons données actives le nombre de vues du blog, le nombre de réponses, les informations statistiques similaires ou d'autres données qui changent à une fréquence relativement élevée. Par conséquent, lors de la conception de la structure de la base de données, vous devez considérer le partitionnement des tables. Le premier est le traitement du partitionnement vertical des tables.
Après avoir divisé la table verticalement de cette manière :
Tout d'abord, le moteur de stockage est utilisé différemment. MyIsam peut être utilisé pour les données froides afin de mieux interroger les données. Pour les données actives, vous pouvez utiliser Innodb, qui peut avoir une meilleure vitesse de mise à jour.
Deuxièmement, configurez davantage de bases de données esclaves pour les données froides, car davantage d'opérations sont interrogées, accélérant ainsi la vitesse des requêtes. Pour les données chaudes, il peut y avoir un traitement de sous-table relativement plus horizontal dans la base de données principale.
En fait, pour certaines données actives spéciales, vous pouvez également envisager d'utiliser des caches tels que memcache et redis, puis mettre à jour la base de données lorsque l'accumulation atteint un certain montant. Ou une base de données nosql telle que mongodb. Ceci n'est qu'un exemple, donc je n'en parlerai pas en premier.
2> Division horizontale de la table
Comme vous pouvez le voir d'après le sens littéral, il s'agit de couper horizontalement une grande structure de table en différentes tables de la même structure, telles que la table d'informations utilisateur, user_1, user_2, etc. La structure du tableau est exactement la même, mais le tableau est divisé selon certaines règles spécifiques, telles que la division modulaire basée sur l'ID utilisateur.
Raison du fractionnement des tables : divisez en fonction de la taille du volume de données pour garantir que la capacité d'une seule table n'est pas trop grande, garantissant ainsi les requêtes et autres capacités de traitement d'une seule table.
Cas : identique à l'exemple ci-dessus, système de blog. Lorsque le volume de blogs atteint un niveau important, une segmentation horizontale doit être adoptée pour réduire la pression sur chaque table et améliorer les performances. Par exemple, si la table de données froides d'un blog est divisée en 100 tables, lorsque 1 million d'utilisateurs naviguent en même temps, s'il s'agit d'une seule table, 1 million de requêtes seront effectuées. Mais maintenant, une fois les tables divisées, cela peut être pour chaque table. Faites 10 000 demandes de données (car il est impossible d'obtenir une moyenne absolue, juste une hypothèse), donc la pression sera considérablement réduite.

La réplication de bases de données peut résoudre le problème d'accès, mais elle ne peut pas résoudre le problème de l'écriture simultanée à grande échelle. Pour résoudre ce problème, nous devons considérer la segmentation des données MySQL

Segmentation des données, comme son nom. suggère que les données sont dispersées et que les données sur un hôte sont distribuées sur plusieurs hôtes pour réduire la pression de charge sur un seul hôte. Il existe deux façons de diviser les données. La première consiste à diviser la base de données en plusieurs bases de données en fonction de l'entreprise. Les tables sont différentes. Une autre méthode consiste à diviser les données en différents hôtes selon certaines règles ou logiques métier. Les tables sur chaque hôte sont les mêmes.

La sous-bibliothèque est aussi appelée partitionnement vertical. Cette méthode est relativement simple à mettre en œuvre. L'important est d'affiner le métier, il faut penser clairement à l'interaction entre les modules métiers de chacun. module pour éviter d'écrire des programmes à l'avenir. Il y a trop d'opérations entre bases de données.

Le partitionnement de table est également appelé partitionnement horizontal. Cette méthode est plus compliquée à mettre en œuvre que le partitionnement vertical, mais elle peut résoudre le problème que le partitionnement vertical ne peut pas résoudre, c'est-à-dire que l'accès et l'écriture d'une seule table sont très difficiles. A cette époque, les tables peuvent être divisées selon certaines règles commerciales (PS : par exemple, la notion de niveau d'adhésion du forum Internet BBS : les tables sont divisées selon le niveau d'adhésion. Cela peut réduire la pression sur un). table unique et résoudre les conflits fréquents entre les différents modules.

Les avantages de la sous-base de données sont : une mise en œuvre simple, des limites claires entre les bibliothèques et une maintenance facile. L'inconvénient est qu'elle n'est pas propice aux opérations fréquentes entre les bases de données et le problème du grand volume de données dans un. une seule table ne peut pas être résolue.

L'avantage de la sous-table est qu'elle peut résoudre les défauts de la sous-base de données, mais l'inconvénient est exactement l'avantage de la sous-base de données. La mise en œuvre d'une sous-table est plus compliquée, notamment la division des. les sous-règles de table, l'écriture de programmes et la migration et la maintenance ultérieures de la base de données.

Dans les applications pratiques, la voie générale des sociétés Internet consiste à diviser d'abord la base de données, puis à diviser le tableau. Les deux sont utilisés en combinaison pour apprendre des forces de chacun. extension de MySQL, mais l'inconvénient est que l'architecture est volumineuse et complexe. L'écriture d'applications est également plus compliquée.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!