Table de partition de base de données de partition de partitionnement MySQL

Une fois que la quantité de données dans la base de données atteint un certain niveau, afin d'éviter les goulots d'étranglement dans les performances du système. Les données doivent être traitées au moyen de partitionnement, de partitionnement, de bases de données et de tables.

Cours recommandé : Tutoriel MySQL.

Partage (similaire à une sous-bibliothèque)

Le partage consiste à étendre la base de données à plusieurs nœuds physiques. C'est une méthode efficace manière, et son objectif principal est de briser les limitations de capacité d'E/S d'un serveur de base de données à nœud unique et de résoudre le problème d'évolutivité de la base de données. Le mot fragment signifie « fragment ». Si une base de données est traitée comme un gros morceau de verre et que le verre est brisé, alors chaque petit morceau est appelé un fragment de la base de données (Database Shard). Le processus consistant à diviser l'ensemble de la base de données en morceaux est appelé sharding, qui peut être traduit par sharding.

Formellement, le partitionnement peut être simplement défini comme un schéma de partitionnement qui distribue une grande base de données sur plusieurs nœuds physiques. Chaque partition contient une certaine partie de la base de données, appelée tranche. La méthode de partitionnement peut être arbitraire et ne se limite pas au partitionnement horizontal et vertical traditionnel. Un fragment peut contenir le contenu de plusieurs tables ou même de plusieurs instances de base de données. Chaque fragment est placé sur un serveur de base de données. Un serveur de base de données peut gérer une ou plusieurs fragments de données. Un serveur est requis dans le système pour le routage et le transfert des requêtes, et est responsable du transfert de la requête vers le fragment ou le nœud de collecte de fragments contenant les données auxquelles la requête accède pour exécution.

Scale Out/Scale Up et division verticale/scission horizontale

Les solutions d'expansion de MySQL incluent Scale Out et Scale Up.

Scale Out (expansion horizontale) signifie que l'application peut être étendue dans le sens horizontal. De manière générale, pour les applications de centre de données, Scale-out signifie que lorsque davantage de machines sont ajoutées, l'application peut toujours faire bon usage des ressources de ces machines pour améliorer sa propre efficacité et atteindre une bonne évolutivité.

Scale Up (expansion verticale) signifie que l'application peut se développer dans le sens vertical. De manière générale, pour une seule machine, Scale Up en vaut la peine. Lorsqu'un nœud informatique (machine) ajoute plus de cœurs de processeur, de périphériques de stockage et utilise une plus grande mémoire, l'application peut utiliser pleinement ces ressources pour améliorer son efficacité. bonne évolutivité.

La stratégie de partitionnement de MySQL comprend le partitionnement vertical et le partitionnement horizontal.

Répartition verticale (verticale) : fait référence à la division par modules fonctionnels pour résoudre la compétition io entre les tables. Par exemple, elle est divisée en base de données de commandes, base de données de produits, base de données d'utilisateurs... De cette façon, les structures de tables de plusieurs bases de données sont différentes.

Répartition horizontale (horizontale) : enregistrez les données de la même table en blocs et enregistrez-les dans différentes bases de données pour résoudre la pression de l'augmentation du volume de données dans une seule table. Les structures de tables dans ces bases de données sont exactement les mêmes.

La structure de la table est conçue pour être divisée verticalement. Certains scénarios courants incluent

a). La segmentation verticale de grands champs. Créez des champs volumineux séparément dans une autre table pour améliorer les performances d'accès de la table de base. En principe, les champs volumineux dans la base de données doivent être évités dans les applications critiques en termes de performances

b). Par exemple, les attributs matériels de l'entreprise peuvent être segmentés verticalement selon les attributs de base, les attributs de vente, les attributs d'achat, les attributs de fabrication, les attributs de comptabilité financière, etc.

c). Par exemple, dans les systèmes de commerce électronique et Web 2.0, s'il existe de nombreux paramètres d'attributs utilisateur, les attributs de base fréquemment utilisés et les attributs rarement utilisés peuvent être séparés verticalement

et la structure du tableau conçue pour être divisée horizontalement. . Certains scénarios courants incluent

a). Par exemple, dans un site Web de commerce électronique en ligne, la quantité de données du tableau de commande est trop importante et est divisée en niveaux annuels et mensuels

b) .Utilisateurs enregistrés sur le site Web 2.0, en ligne Il y a trop d'utilisateurs actifs En fonction de la plage d'ID utilisateur, etc., segmentez horizontalement les utilisateurs concernés et les tableaux étroitement liés à l'utilisateur

c). le message du haut du forum, car cela implique des problèmes de pagination, chaque page Il est nécessaire d'afficher le message épinglé. Dans ce cas, le message épinglé peut être divisé horizontalement pour éviter de lire le tableau de tous les messages lors de la récupération du message épinglé. 🎜>En apparence, le fractionnement de table signifie diviser une table en plusieurs petites tables, tandis que le partitionnement signifie diviser les données d'une table en N blocs. Ces blocs peuvent se trouver sur le même disque ou sur des disques différents.

La différence entre les tables fractionnées et les partitions

1. En termes d'implémentation

les tables fractionnées de MySQL sont de véritables tables fractionnées une fois qu'une table est divisée en plusieurs tables. , Chaque petite table est une table complète et correspond à trois fichiers (moteur MyISAM : un fichier de données .MYD, un fichier d'index .MYI et un fichier de structure de table .frm).

2. En termes de traitement des données

Une fois la table divisée, les données sont stockées dans la table. La table principale n'est qu'un shell et l'accès aux données s'effectue dans chaque table. Il n'y a pas de concept de partitionnement de table dans le partitionnement. Le partitionnement divise simplement le fichier stockant les données en plusieurs petits blocs. La table partitionnée est toujours une table et le traitement des données est toujours effectué par vous-même.

3. Amélioration des performances

Après avoir divisé les tables, la capacité de concurrence d'une seule table a été améliorée et les performances d'E/S du disque ont également été améliorées. La partition surmonte le goulot d'étranglement des E/S du disque et je souhaite améliorer les capacités de lecture et d'écriture du disque pour augmenter les performances de MySQL.

À ce stade, l'objectif des tests des partitions et des sous-tables est différent. L'objectif des sous-tables est de savoir comment améliorer la simultanéité de MySQL lors de l'accès aux données et, pour les partitions, comment briser les capacités de lecture et d'écriture ; du disque, améliorant ainsi les performances de MySQL.

4. En termes de difficulté de mise en œuvre,

Il existe de nombreuses façons de diviser les tables. Utiliser la fusion pour diviser les tables est le moyen le plus simple. Cette méthode est aussi simple que le partitionnement et peut être transparente pour le code du programme. Si vous utilisez d'autres méthodes de partitionnement de table, cela sera plus gênant que le partitionnement. L'implémentation du partitionnement est relativement simple. La création d'une table partitionnée n'est pas différente de la construction d'une table ordinaire, et elle est transparente du côté du code.

Scénarios applicables pour le partitionnement

1. La vitesse de requête d'une table est devenue si lente qu'elle affecte son utilisation.

2. Les données du tableau sont segmentées

3. Les opérations sur les données n'impliquent souvent qu'une partie des données, pas toutes les données

CREATE TABLE sales (

    id INT AUTO_INCREMENT,

    amount DOUBLE NOT NULL,

    order_day DATETIME NOT NULL,

    PRIMARY KEY(id, order_day)

) ENGINE=Innodb

PARTITION BY RANGE(YEAR(order_day)) (

    PARTITION p_2010 VALUES LESS THAN (2010),

    PARTITION p_2011 VALUES LESS THAN (2011),

    PARTITION p_2012 VALUES LESS THAN (2012),

PARTITION p_catchall VALUES LESS THAN MAXVALUE);

Applicabilité des sous-tableaux Scénarios.

1. La vitesse de requête d'une table est devenue si lente qu'elle affecte son utilisation.

2. Lors d'une insertion fréquente ou d'interrogations conjointes, la vitesse ralentira.

La mise en œuvre des sous-tables nécessite une combinaison de mise en œuvre métier et de migration, ce qui est relativement complexe.

Sous-table et sous-base de données

La sous-table peut résoudre le problème de la réduction de l'efficacité des requêtes causée par un volume de données excessif dans une seule table, mais elle ne peut pas s'améliorer la simultanéité de la base de données. Les capacités de traitement apportent des améliorations qualitatives. Face à un accès en lecture et en écriture hautement concurrent, lorsque le serveur maître de base de données ne peut pas supporter la pression des opérations d'écriture, cela n'a aucun sens, quelle que soit la manière d'étendre le serveur esclave. Par conséquent, nous devons changer notre façon de penser et diviser la base de données pour améliorer la capacité d'écriture de la base de données. C'est ce qu'on appelle la sous-base de données.

Semblable à la stratégie de partitionnement de table, le partitionnement peut utiliser un mot-clé modulo pour acheminer l'accès aux données.

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!