21 règles pour vous aider à "jouer" sous-tableau de sous-base de données

Un si bon système, pourquoi avons-nous besoin de diviser les bases de données et les tables ?

Nous combinons des scénarios métier spécifiques et t_orderprenons des tables comme exemple pour optimiser l'architecture. Depuis que la quantité de données a atteint le niveau de 100 millions, les performances des requêtes ont sérieusement diminué, nous avons donc adopté la technologie des sous-bases de données et des sous-tables pour résoudre ce problème. Plus précisément, nous avons divisé la bibliothèque unique d'origine en deux bibliothèques, à savoir DB_1et DB_2, et avons effectué à nouveau un traitement de division de table dans chaque bibliothèque pour générer t_order_1et t_order_2deux tables pour réaliser la sous-base de données et le traitement de table de la table de commande.

partage de données

Habituellement, lorsque nous nous référons à des sous-bases de données et des tables, nous utilisons principalement le mode de segmentation horizontale (sous-base de données horizontale, sous-table) comme base. Le partage de données divise une table avec une grande quantité de données pour générer plusieurs petites tables de volume  t_order de données (tables fractionnées)  avec exactement la même structure de tablet_order_0 , t_order_1, ... , t_order_n, chaque table ne stocke qu'une partie des données dans la grande table d'origine.

nœud de données

Un nœud de données est une plus petite unité indivisible (table) dans une partition de données, qui se compose d'un nom de source de données et d'une table de données. Par exemple, dans la figure ci-dessus, il représente un nœud de  DB_1.t_order_1données DB_2.t_order_2 .

tableau logique

La table logique fait référence au nom logique d'une table divisée horizontalement avec la même structure.

Par exemple, si nous divisons la t_order table des commandes en  10 tables telles que t_order_0 ...  t_order_9, cette table n'existe plus dans notre base de données  t_order, et elle est remplacée par plusieurs t_order_ntables.

La sous-base de données et la sous-table sont généralement non intrusives pour le code métier. Les développeurs se concentrent uniquement sur le codage SQL de la logique métier. Nous écrivons toujours SQLen  t_orderfonction du code et l'analysons dans l'exécution réelle de la base de données correspondante avant d'exécuter le SQL logique. SQL. À ce stade, t_order est la table fractionnée 逻辑表.

logique métier SQL

select * from t_order where order_no='A11111'

Exécution réelle de SQL

select * from DB_1.t_order_n where order_no='A11111'

vrai tableau

Une table réelle est une table physique qui existe réellement dans la base de données DB_1.t_order_n.

tableau de diffusion

Une table de diffusion est un type spécial de table dont la structure de table et les données sont totalement cohérentes dans toutes les sources de données de partition. Par rapport à la table fractionnée, la table de diffusion a un volume de données plus petit et une fréquence de mise à jour plus faible, et est généralement utilisée dans des scénarios tels que des tables de dictionnaire ou des tables de configuration. Puisqu'il a des copies sur tous les nœuds, il peut réduire considérablement JOINla surcharge réseau des requêtes associées et améliorer l'efficacité des requêtes.

Il convient de noter que l'opération de modification de la table de diffusion doit assurer la synchronisation pour assurer la cohérence des données sur tous les nœuds.

Caractéristiques de la table de diffusion :

• Dans toutes les sources de données fragmentées, les données de la table de diffusion sont totalement cohérentes. Par conséquent, les opérations sur la table de diffusion (telles que l'insertion, la mise à jour et la suppression) seront effectuées dans chaque source de données de partition en temps réel pour garantir la cohérence des données.

• Pour l'opération de requête de la table de diffusion, elle ne doit être exécutée qu'une seule fois dans n'importe quelle source de données de partition.

• Il est possible d'effectuer une opération JOIN avec n'importe quelle autre table, car les données de la table de diffusion sont cohérentes sur tous les nœuds, de sorte que les mêmes données sur n'importe quel nœud sont accessibles.

Quel type de table peut être utilisé comme table de diffusion ?

Dans le système de gestion des commandes, il est souvent nécessaire d'interroger et de compter les données de commande d'une certaine zone urbaine, ce qui impliquera la table de zone de province t_cityet la table de flux de commandes DB_n. t_order_nPour la requête JOIN, il peut être envisagé de concevoir la table de zone de province car 广播表l'idée de base est d'éviter l'opération JOIN entre bases de données .

Note : Nous avons mentionné plus haut que l'insertion, la mise à jour et la suppression de données de la table de diffusion seront exécutées en temps réel sur chaque source de données de partition, c'est-à-dire que si vous avez 1000 sources de données de partition, alors la modification de la table de diffusion sera exécuté 1000 fois SQL, essayez donc de ne pas le faire dans un environnement concurrent et pendant les pics d'activité, afin de ne pas affecter les performances du système.

table unique

La table unique fait référence à la seule table (table sans fragmentation) parmi toutes les sources de données fragmentées, qui convient aux tables avec un petit volume de données et sans besoin de fragmentation.

Si le volume de données d'une table est estimé à plusieurs dizaines de millions et qu'il n'est pas nécessaire d'effectuer des requêtes associées avec d'autres tables fractionnées, il est recommandé de la définir comme un type de table unique et de la stocker dans les données de partition par défaut. source.

clé fragmentée

La clé de partition détermine où les données atterrissent, c'est-à-dire à quel nœud de données les données seront allouées pour le stockage. Par conséquent, le choix de la clé de partition est très important.

Par exemple, après  t_order avoir partitionné la table, lors de l'insertion d'une donnée de commande pour exécuter SQL, nous devons calculer dans quelle partition les données doivent tomber en analysant la clé de partition spécifiée dans l'instruction SQL. En prenant les champs de la table comme exemple, nous pouvons obtenir le numéro de partition en  order_noprenant une opération modulo (par exemple  ), puis affecter des données à l'instance de base de données correspondante (par exemple  , et  ) en fonction du numéro de partition. Les tables fractionnées sont également calculées de la même manière.order_no % 2DB_1DB_2

Dans ce processus, order_no il s'agit  t_order de la clé de partition de la table. En d'autres termes, la valeur de chaque donnée de commande  order_no détermine l'instance de base de données et la table dans laquelle elle doit être stockée. Le choix d'un champ qui convient comme clé de partitionnement permet de mieux tirer parti de l'amélioration des performances apportée par le partitionnement horizontal.

De cette façon, les données pertinentes de la même commande tomberont dans la même base de données et la même table. Lors de l'interrogation de la commande, le calcul est similaire et l'emplacement des données peut être directement localisé, ce qui améliore considérablement les performances de récupération des données et évite de balayer toute la table de la base de données.

De plus,  ShardingSphere il prend également en charge la fragmentation basée sur plusieurs champs en tant que clé de fragmentation, qui sera décrite en détail dans les chapitres correspondants suivants.

Stratégie de fragmentation

Stratégie de fragmentation pour spécifier quel algorithme de fragmentation utiliser, quel champ choisir comme clé de fragmentation et comment distribuer les données aux différents nœuds.

La stratégie de partitionnement est composée de 分片算法et 分片健, et divers algorithmes de partitionnement et opérations sur plusieurs clés de partitionnement peuvent être utilisés dans la stratégie de partitionnement.

La configuration de la stratégie de partitionnement pour la partition de base de données et la partition de table est relativement indépendante, et différentes stratégies et algorithmes peuvent être utilisés respectivement. Chaque stratégie peut être une combinaison de plusieurs algorithmes de partitionnement, et chaque algorithme de partitionnement peut être utilisé pour plusieurs clés de partitionnement. jugement.

Algorithme de fragmentation

L'algorithme de fragmentation est utilisé pour opérer sur la clé de fragmentation et diviser les données en nœuds de données spécifiques.

Il existe de nombreux algorithmes de fragmentation couramment utilisés :

• Hash sharding : Selon la valeur de hachage de la clé de shard, il est déterminé sur quel nœud les données doivent tomber. Par exemple, le partage de hachage est effectué sur la base de l'ID utilisateur, et les données appartenant au même utilisateur sont allouées au même nœud pour faciliter les opérations de requête ultérieures.

• Partage de plage : les valeurs de clé de partition sont allouées à différents nœuds selon des plages de plage. Par exemple, le partage en fonction de l'heure de création de la commande ou de l'emplacement géographique.

• Partitionnement modulo : prenez la valeur modulo de la valeur de la clé de partition et le nombre de partitions, et utilisez le résultat comme numéro de nœud auquel les données doivent être allouées. Par exemple, order_no % 2 répartit les données de commande sur l'un des deux nœuds.

• .....

La logique du sharding dans le développement commercial réel est beaucoup plus compliquée. Différents algorithmes conviennent à différents scénarios et besoins, et doivent être sélectionnés et ajustés en fonction de la situation réelle.

tableau de reliure

Les tables de liaison sont un groupe de tables de partitionnement avec les mêmes règles de partitionnement. Étant donné que les règles de partitionnement sont cohérentes, la position d'arrivée des données est la même, ce qui permet d'éviter efficacement les opérations entre bases de données lors deJOIN requêtes conjointes .

Par exemple : t_order la table de commande et  t_order_item la table d'articles de commande  order_no utilisent toutes deux des champs comme clé de partition et  order_no sont associées l'une à l'autre, de sorte que les deux tables sont liées l'une à l'autre.

Lors de l'utilisation d'une table liée pour une requête d'association multitable, vous devez utiliser la clé de partition pour l'association, sinon une association de produit cartésien ou une association entre bases de données se produira, ce qui affectera l'efficacité de la requête.

Lors de l'utilisation  t_order d'une  t_order_item table pour une requête conjointe multitable, exécutez le SQL logique de la requête conjointe comme suit.

SELECT * FROM t_order o JOIN t_order_item i ON o.order_no=i.order_no

Si la relation de table de liaison n'est pas configurée, la table de base de données entière sera interrogée si l'emplacement des données des deux tables est incertain, et la requête liée au produit cartésien générera les quatre éléments suivants SQL.

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_no=i.order_no 
SELECT * FROM t_order_0 o JOIN t_order_item_1 i ON o.order_no=i.order_no 
SELECT * FROM t_order_1 o JOIN t_order_item_0 i ON o.order_no=i.order_no 
SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_no=i.order_no 

Lorsque vous configurez la relation de table de liaison, puis effectuez une requête associée, les données générées par les règles de partitionnement cohérentes tomberont dans la même table de base de données, vous n'avez donc qu'à l'associer à   la t_order_n table  de la base de données actuelle.t_order_item_n

SELECT * FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id 
SELECT * FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id 

Remarque : Il est utilisé comme table principale de l'ensemble de la requête conjointe lors de la liaison des requêtes  t_order . Tous les calculs de routage associés utilisent uniquement la stratégie de la table principale, et t_order_item les calculs liés au partitionnement de table utiliseront également  t_order les conditions, il est donc nécessaire de s'assurer que les clés de partitionnement entre les tables de liaison sont exactement les mêmes.

Analyse SQL

Lors de l'exécution d'une instruction SQL au niveau de l'application après la sous-table de sous-base de données, il faut généralement passer par les six étapes suivantes : SQL 解析 ->  执⾏器优化 -> ->  SQL 路由 -> -  SQL 改写 >  SQL 执⾏ ->  结果归并 .

insérez la description de l'image ici

Le processus d'analyse SQL est divisé 词法解析en 语法解析deux étapes. Par exemple, la requête SQL suivante pour les commandes des utilisateurs est d'abord désassemblée en unités atomiques indivisibles par une analyse lexicale. Dans les dictionnaires fournis par différents dialectes de bases de données, ces unités sont classées en mots-clés, expressions, variables ou opérateurs.

SELECT order_no FROM t_order where  order_status > 0  and user_id = 10086 

Ensuite, l'analyse de la syntaxe convertira les mots clés SQL fractionnés en une arborescence de syntaxe abstraite. En parcourant l'arborescence de syntaxe abstraite, le contexte requis pour la fragmentation est extrait. Le contexte comprend les informations de champ de requête ( ), les informations de table ( ) et les conditions de Fieldrequête Table( Condition) , les informations de tri ( Order By), les informations de regroupement ( Group By) et les informations de pagination ( Limit), etc., et marquez les positions dans SQL qui peuvent nécessiter une réécriture.

arbre de syntaxe abstraite

Optimisation de l'exécuteur

L'optimisation de l'exécuteur consiste à sélectionner et à exécuter le plan de requête optimal en fonction des caractéristiques de la requête SQL et des statistiques d'exécution. Par exemple, si un user_idchamp possède un index, les positions des deux conditions de requête seront ajustées, principalement pour améliorer l'efficacité de l'exécution SQL.

SELECT order_no FROM t_order where user_id = 10086 and order_status > 0

Routage SQL

Les données de contexte de partitionnement sont obtenues via l'analyse SQL ci-dessus. Après avoir fait correspondre la stratégie de partitionnement et l'algorithme configurés par l'utilisateur, un chemin de routage peut être calculé et acheminé vers le nœud de données correspondant.

Une compréhension simple consiste à obtenir des informations telles que la clé de partitionnement configurée dans la stratégie de partitionnement, à trouver la valeur du champ de clé de partitionnement correspondant à partir du résultat de l'analyse SQL et à calculer dans quelle base de données et table le SQL doit être exécuté, ainsi que le routage SQL. est basé sur S'il y a une clé de fragment est divisé en  分片路由 une somme  广播路由.

Une route avec une clé de partition est appelée une route de partition, qui est subdivisée en trois types : route directe, route standard et route de produit cartésien.

routage standard

Le routage standard est la méthode de partitionnement la plus recommandée et la plus couramment utilisée, et son champ d'application est SQL qui n'inclut pas les requêtes associées ou n'inclut que les requêtes associées entre les tables liées.

Lorsque l'opérateur de la clé de partitionnement SQL = est , le résultat du routage tombe dans une seule base de données (table). Lorsque l'opérateur de partitionnement est compris  BETWEEN entre ou  IN égal, le résultat du routage ne tombe pas nécessairement dans la seule base de données (table). Un SQL logique peut éventuellement être divisé en plusieurs SQL réels pour l'exécution.

SELECT * FROM t_order  where t_order_id in (1,2)

Après le traitement du routage SQL

SELECT * FROM t_order_0  where t_order_id in (1,2)
SELECT * FROM t_order_1  where t_order_id in (1,2)

routage direct

Le routage direct est une méthode de partitionnement qui achemine directement SQL vers des bases de données et des tables spécifiées, et le routage direct peut être utilisé dans des scénarios où la clé de partitionnement n'est pas dans SQL, et peut également exécuter des situations complexes, y compris des sous-requêtes et des fonctions personnalisées.

Routage de produit cartésien

Le routage cartésien est généré par des requêtes d'association entre des tables non liées. Par exemple, la t_order clé de partition de la table de commande est la même que la clé de partition de t_order_id table des utilisateurst_userlat_order_id 

SELECT * FROM t_order_0 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_0 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_0 u ON u.user_id = t.user_id WHERE t.user_id = 1
SELECT * FROM t_order_1 t LEFT JOIN t_user_1 u ON u.user_id = t.user_id WHERE t.user_id = 1

Le routage sans clé de partition est également appelé routage de diffusion, qui peut être divisé en cinq types : routage de table de base de données complète, routage de base de données complète, routage d'instance complète, routage unicast et routage de blocage.

Routage complet de la table

Le routage complet des tables de base de données vise des opérations  telles que la base de données  DQL et  DML,  etc. Lorsque nous exécutons une table logique SQL,  elle sera exécutée une par une dans les  tables   réelles correspondantes  de toutes les bases de données fragmentées  .DDLt_ordert_order_0t_order_n

Routage complet de la bibliothèque

Le routage complet de la base de données concerne principalement les opérations au niveau de la base de données, telles que  SET les commandes de gestion de base de données du type base de données et les instructions de contrôle des transactions telles que TCL.

Après avoir défini  autocommit l'attribut sur la bibliothèque logique, cette commande est exécutée dans toutes les bibliothèques réelles correspondantes.

SET autocommit=0;

Routage d'instance complet

Le routage d'instance complète est une opération DCL pour les instances de base de données (définir ou modifier les autorisations d'utilisateur ou de rôle de la base de données), telles que : créer une commande d'utilisateur, cette commande sera exécutée dans toutes les instances de base de données réelles, afin de s'assurer que l'utilisateur de la commande peut accèdent normalement à chaque instance de base de données.

CREATE USER [email protected] identified BY '程序员小富';

routage monodiffusion

Le routage unicast est utilisé pour obtenir des informations sur une table réelle, telles que les informations de description de la table :

DESCRIBE t_order; 

t_order La table réelle de est  t_order_0 ...  t_order_n, leur structure de description est exactement la même, nous n'avons besoin de l'exécuter qu'une seule fois sur n'importe quelle table réelle.

routage de bloc

Utilisé pour protéger les opérations SQL sur la base de données, par exemple :

USE order_db;

Cette commande ne sera pas exécutée dans la base de données réelle, car  ShardingSphere le schéma logique (organisation et structure de la base de données) est adopté, il n'est donc pas nécessaire d'envoyer la commande pour basculer la base de données vers la base de données réelle.

Réécriture SQL

Une fois le SQL analysé, optimisé et routé, l'emplacement d'exécution spécifique des fragments a été déterminé, puis le SQL développé sur la base de la table logique doit être réécrit dans une instruction pouvant être correctement exécutée dans la base de données réelle. Par exemple, pour interroger  t_order la table de commande, le SQL dans notre développement actuel est  t_order écrit selon la table logique.

SELECT * FROM t_order

A ce stade, il est nécessaire de réécrire le nom de la table logique dans la configuration de la sous-table en nom de table réel obtenu après le routage.

SELECT * FROM t_order_n

Exécution SQL

Le code SQL réel acheminé et réécrit est envoyé en toute sécurité et efficacement à la source de données sous-jacente pour exécution. Cependant, ce processus ne peut pas envoyer directement SQL à la source de données via JDBC pour exécution. Il doit équilibrer la consommation de création de connexion de source de données et l'utilisation de la mémoire. Il équilibrera automatiquement le contrôle des ressources et l'efficacité de l'exécution.

Fusionner les résultats

La fusion des ensembles de résultats multi-données obtenus à partir de chaque nœud de données dans un grand ensemble de résultats et son renvoi correct au client demandeur est appelée fusion de résultats. Les syntaxes de tri, de regroupement, de pagination et d'agrégation dans notre SQL sont toutes opérées sur le jeu de résultats fusionné.

clé primaire distribuée

Une fois les données fragmentées, une table logique ( t_order) correspond à plusieurs tables réelles ( t_order_n). Puisqu'elles ne peuvent pas se percevoir, les ID de clé primaire sont accumulés à partir de la valeur initiale, donc des ID de clé primaire en double se produiront inévitablement, et la clé primaire n'est plus unique Alors cela n'a pas de sens pour les affaires.

Bien que vous puissiez   éviter les collisions d'ID en définissant la somme de clé primaire d'auto-incrémentation de la table, cela augmentera les coûts de maintenance et une mauvaise évolutivité 初始值 . 步⻓

À ce stade, nous devons attribuer manuellement un ID global unique à un enregistrement de données. Cet ID est appelé un ID distribué et le système qui produit cet ID est généralement appelé un émetteur.

désensibilisation des données

La désensibilisation des données des sous-bases de données et des sous-tableaux est une mesure efficace de protection des données, qui peut garantir la confidentialité et la sécurité des données sensibles et réduire le risque de fuite de données.

Par exemple, nous pouvons spécifier quels champs de la table sont des colonnes désensibilisées lorsque nous divisons la base de données et la table, et définir l'algorithme de désensibilisation correspondant. Lorsque les données sont fragmentées, nous analysons les champs à désensibiliser dans le SQL d'exécution, et le champ les valeurs seront désensibilisées directement.Ensuite, écrivez dans la table de la bibliothèque.

Pour les informations personnelles de l'utilisateur, telles que le nom, l'adresse et le numéro de téléphone, etc., elles peuvent être désensibilisées en cryptant, en randomisant ou en remplaçant par des données pseudo-aléatoires pour garantir la protection de la vie privée de l'utilisateur.

transaction distribuée

Le problème central des transactions distribuées est de savoir comment mettre en œuvre des opérations atomiques sur plusieurs sources de données.

Étant donné que différents services utilisent souvent différentes sources de données pour stocker et gérer les données, les opérations entre les sources de données peuvent entraîner un risque d'incohérence ou de perte de données. Par conséquent, il est très important d'assurer la cohérence des transactions distribuées.

En prenant le système de commande comme exemple, il doit appeler plusieurs systèmes tels que le système de paiement, le système d'inventaire et le système de points, et chaque système maintient sa propre instance de base de données, et les systèmes échangent des données via des interfaces API.

Afin de garantir que plusieurs systèmes appellent avec succès en même temps après la passation de la commande, vous pouvez utiliser 强一致性事务le protocole XA, ou 柔性事务l'outil représentatif Seata, pour assurer la cohérence des transactions distribuées. Ces outils peuvent aider les développeurs à simplifier la mise en œuvre des transactions distribuées, à réduire les erreurs et les vulnérabilités et à améliorer la stabilité et la fiabilité du système.

Après sous-table de sous-base de données, la difficulté du problème est encore améliorée. Son propre service de commande doit également gérer les opérations entre les sources de données. En conséquence, la complexité du système augmente considérablement. Par conséquent, il est préférable d'éviter la solution de sous-base de données et de sous-table à moins qu'il ne s'agisse d'un dernier recours.

migration de données

Il y a toujours un casse-tête après la sous-table de sous-base de données, c'est-à-dire la migration des données.Afin de ne pas affecter le système d'entreprise existant, un nouveau cluster de base de données est généralement créé pour migrer les données. Migrez les données de la base de données et des tables de l'ancien cluster vers les sous-bases de données et les tables du nouveau cluster. 数据量Il s'agit d'un processus relativement compliqué, et de nombreux facteurs tels que , 数据一致性, etc. doivent être pris en compte lors du processus de migration 迁移速度.

La migration concerne principalement  le traitement 存量数据 et  增量数据 le traitement. Les données de stock font référence aux données historiques existantes et précieuses dans l'ancienne source de données. Les données incrémentielles font référence à la croissance continue actuelle et aux données commerciales générées à l'avenir.

Les données d'inventaire peuvent être migrées à intervalles réguliers et par lots, et le processus de migration peut durer plusieurs jours.

Les données incrémentielles peuvent adopter le nouveau et l'ancien mode de double écriture du cluster de base de données. Une fois la migration des données terminée et l'entreprise vérifie la cohérence des données, l'application peut directement changer de source de données.

Plus tard, nous combinerons des outils tiers pour démontrer le processus de migration.

bibliothèque d'ombres

Qu'est-ce qu'une bibliothèque fantôme ( Shadow Table) ?

La base de données fantôme est une instance avec la même structure de base de données que l'environnement de production. Elle existe pour vérifier l'exactitude de la migration de la base de données ou d'autres opérations de modification de la base de données, ainsi que des tests de contrainte complets sans affecter le système en ligne. Les données stockées dans la bibliothèque fantôme sont régulièrement copiées depuis l'environnement de production, mais elles n'ont aucun impact sur les activités en ligne et ne sont utilisées qu'à des fins de test, de vérification et de débogage.

Avant d'effectuer des opérations telles que la mise à niveau de la base de données, le changement de version et le réglage des paramètres, des problèmes potentiels peuvent être détectés en simulant ces opérations sur la base de données fantôme, car les données de l'environnement de test ne sont pas fiables.

Lorsque vous utilisez des bibliothèques fantômes, les principes suivants doivent être suivis :

• La structure de la base de données de l'environnement de production doit être totalement cohérente, y compris la structure de la table, l'index, la contrainte, etc. ;

• Les données doivent être cohérentes avec l'environnement de production, ce qui peut être réalisé grâce à une synchronisation régulière ;

• Les opérations de lecture et d'écriture n'affecteront pas l'environnement de production. En général, les opérations telles que la mise à jour et la suppression sur la bibliothèque miroir doivent être interdites ;

• En raison des caractéristiques des données de la base de données fantôme, les droits d'accès doivent être strictement contrôlés et seul le personnel autorisé est autorisé à accéder et à opérer ;