Introduction
Pour un système, le volume actuel de données de commande a atteint des centaines de millions, et il augmente à un rythme de millions chaque jour, et il pourrait même atteindre des dizaines de millions à l'avenir.
Face à une telle quantité de données, une fois que la quantité de données augmente énormément, cela entraînera inévitablement un ralentissement de la lecture et de l'écriture.
Alors, pour permettre au système de résister à la pression de dizaines de millions de volumes de données, quelles sont les solutions ?
2. Sous-table et sous-base de données
Lorsque la lecture et l'écriture des tables de la base de données sont lentes, la première chose que nous envisageons est d'optimiser les modules de lecture et d'écriture du programme et d'ajuster l'architecture logicielle ; je ne peux pas le supporter, et l'effet d'optimisation n'est limité que par le logiciel.
La solution que nous souhaitons introduire ici est la suivante : sous-table et sous-base de données, c'est-à-dire diviser d'abord la table, puis effectuer un stockage distribué.
3. Sélection de la technologie pour le stockage fractionné
Il existe quatre solutions couramment utilisées pour diviser le stockage, notamment : la technologie de partitionnement MySQL, NoSQL, NewSQL et la sous-table et la sous-base de données basées sur MySQL.
3.1 Technologie de partition MySQL
Examinons d'abord le diagramme d'architecture MySQL du document officiel MySQL.
À partir du diagramme d'architecture MySQL ci-dessus, il n'est pas difficile de constater que le partitionnement de MySQL se situe principalement dans la couche de stockage de fichiers. Il peut stocker différentes lignes d'une table dans différents fichiers de stockage. . Dans les applications pratiques, la technologie de partitionnement MySQL n'est pas recommandée pour trois raisons principales :
- Il n'y a qu'une seule instance MySQL, qui ne distribue que le stockage et ne peut pas distribuer la charge des requêtes.
- Le partitionnement de MySQL est transparent pour les utilisateurs, de sorte que les utilisateurs y prêtent souvent peu d'attention lors des opérations réelles, ce qui fait que les opérations inter-partitions affectent sérieusement les performances du système.
- MySQL a d'autres limitations, telles que la non-prise en charge du cache de requêtes, des expressions d'opération de bit, etc.
3.2 NoSQL
Un NoSQL typique est MongoDB.
La fonction de partitionnement de MongoDB peut déjà répondre aux besoins généraux de grandes quantités de données du point de vue de la concurrence et des données.
Cependant, vous devez toujours faire attention aux trois points principaux suivants :
- Considérations sur les contraintes : MongoDB n'est pas une base de données relationnelle, mais une base de données documentaire. Chaque ligne de son enregistrement est un Json avec une structure flexible. Par exemple, lors du stockage de commandes très importantes, MongoDB ne peut pas être utilisé, car les données de la commande doivent être stockées dans une base de données relationnelle fortement contrainte.
- Considérations sur les fonctions métier : les opérations telles que les transactions, les verrous, SQL et les expressions ont été vérifiées dans MySQL, et MySQL peut répondre à toutes les exigences métier. MongoDB ne peut pas.
- Considérations de stabilité : MySQL a été testé dans la pratique, et NoSQL n'a pas encore été vérifié.
3.3 NouveauSQL
La technologie NewSQL est encore relativement nouvelle, mais après avoir considéré la stabilité et l'évolutivité fonctionnelle, elle n'a finalement pas été utilisée pour des raisons spécifiques similaires à MongoDB.
3.4 Sous-base de données de table basée sur MySQL
Qu'est-ce qu'une sous-table et une sous-base de données ?
Le fractionnement de table consiste à fractionner et à stocker les données d'une grande table en plusieurs tables fractionnées avec la même structure ; le
fractionnement de base de données consiste à fractionner une grande base de données en plusieurs petites bases de données avec la même structure.
Les sous-bases de données et les sous-tables dépendent moins des tiers, et la logique métier est flexible et contrôlable. Elle ne nécessite pas de principes sous-jacents très compliqués, ni de refaire la base de données. Elle utilise simplement différentes instructions SQL et sources de données. selon des logiques différentes.
4. Exigences générales pour la technologie des sous-bases de données et des sous-tableaux
Si des sous-bases de données et des sous-tables sont utilisées, trois exigences techniques générales doivent être mises en œuvre :
1) Combinaison SQL : la représentation associée étant dynamique, le SQL dynamique doit être assemblé selon la logique ;
2) Routage de la base de données : car le nom de la base de données est également dynamique, il est donc nécessaire d'utiliser différentes bases de données via différentes logiques ;
3) Consolidation des résultats d'exécution : certaines exigences doivent être exécutées via plusieurs sous-bases de données, puis fusionnées et collectées.
À l'heure actuelle, les intergiciels du marché capables de résoudre les problèmes ci-dessus sont divisés en deux catégories : le mode proxy et le mode client .
4.1 Mode proxy
Empruntez le diagramme dans le document officiel de ShardingSphere pour illustrer, en vous concentrant sur la couche Sharding-Proxy.
Ce mode stocke toutes les fonctions telles que la combinaison SQL, le routage de la base de données et la fusion des résultats d'exécution dans un service proxy, ainsi que toute la logique de traitement liée à la sous-couche. -table et sous-base de données sont stockées dans un autre service. L'avantage de ce mode est qu'il n'y a pas d'intrusion dans le code métier, et la valeur métier n'a qu'à se focaliser sur sa propre logique métier.
4.2 Mode client
Emprunter des diagrammes aux documents officiels de ShardingSphere à titre d'illustration.
Ce mode place la logique liée à la sous-table et à la sous-base de données sur le client. Généralement, l'application du client référencera un jar, puis traitera la combinaison SQL, le routage de la base de données, le résultat de l'exécution fusion et autres fonctions connexes dans le pot.
Sur le marché, les intergiciels des deux modes ci-dessus sont :
Proxy et Mode Client Comparaison des Avantages et des Inconvénients :
Dans les applications pratiques, nous pouvons choisir le mode qui nous convient en fonction de nos besoins.
Cinq idées de réalisation de sous-table de sous-base de données
5.1. Quel champ utiliser comme clé de partition
Prenons le formulaire de commande suivant et choisissons d'utiliser le mode Client comme exemple pour illustrer.
Divisez les données de la table ci-dessus en une table de commande. La structure de données principale de la table est la suivante :
Lors de la sélection d'un champ en tant que clé de partition, trois exigences doivent être prises en compte :
1) Les données doivent être réparties uniformément dans différentes tables ou bibliothèques ;
2) Minimiser les requêtes inter-bases de données ;
3) La valeur de ce champ ne changera pas.
Dans le tableau ci-dessus, nous utilisons user_id comme clé primaire de partitionnement, pourquoi est-il si divisé ? Principalement basé sur les besoins de l'entreprise.
Comme certaines exigences commerciales courantes :
- L'utilisateur doit interroger toutes les commandes et les données de commande doivent contenir une heure_commande différente ;
- L'arrière-plan doit interroger les commandes locales en fonction de la ville ;
- L'arrière-plan doit compter la tendance de la commande de chaque période.
Selon les exigences ci-dessus, déterminez la priorité et l'opération de l'utilisateur est la première exigence qui doit être satisfaite en premier.
À ce stade, si user_id est utilisé comme champ de partitionnement de la commande, il peut être garanti que les données peuvent être obtenues dans une sous-table d'une sous-base de données chaque fois que l'utilisateur interroge les données.
Utilisez user_id comme clé primaire de partition. Lors d'une requête dans des sous-tables et des sous-bases de données, user_id sera d'abord transmis en tant que paramètre.
5.2 Quelle est la stratégie de fragmentation
Les stratégies de partitionnement courantes sont divisées en : partitionnement par plage, partitionnement par valeur de hachage et partitionnement par valeur de hachage et plage.
1) Fragmentation selon la plage
Si l'ID utilisateur est un nombre auto-incrémenté, nous divisons l'ID utilisateur dans une bibliothèque en fonction de 100 w de partages, et divisons chaque 10 w de partages en une table pour le partitionnement :
2) Le sharding en fonction de la valeur de hachage
fait référence au sharding en fonction de la valeur de hachage de l'ID utilisateur mod un nombre spécifique (pour l'expansion, généralement plusieurs puissances de 2).
3) Fragmentation basée sur la valeur de hachage et la plage La segmentation
est d'abord effectuée en fonction de la plage, puis le partitionnement modulo en fonction de la valeur de hachage.
Par exemple : table name=order_#user_id%10#_#hash(user_id)%8, elle est divisée en 10*8=80 tables. Afin de faciliter votre compréhension, nous dessinons une image pour illustrer, comme le montre la figure suivante :
Comment choisir une stratégie de sharding ?
Comment choisir les trois stratégies de partitionnement différentes ci-dessus ?
Nous n'avons qu'à considérer un point : en supposant que la quantité de données devient plus importante, nous devons diviser le tableau en détails plus fins. À ce stade, nous devons seulement nous assurer que les données migrées sont aussi petites que possible.
Par conséquent, lors du partitionnement basé sur la valeur de hachage, il est généralement recommandé de diviser en tables de puissance 2 N, par exemple, tables 8. Lors de la migration des données, chaque table d'origine est divisée en deux pour former une nouvelle table, de sorte que la quantité de la migration des données est faible.
Valeur d'expérience du projet : selon la valeur de hachage de l'ID utilisateur, prenez le modulo 32, divisez les données en 32 bases de données, et chaque base de données est ensuite divisée en 16 tables.
Un calcul simple peut être effectué :
en supposant que le volume de commande quotidien est de 10 millions, l'augmentation quotidienne de chaque entrepôt est de 10 millions/32 = 312 500, et l'augmentation quotidienne de chaque table est de 10 millions/32/16 = 19 500.
Si le volume de commande quotidien est de 10 millions, le volume de données de chaque table après 3 ans sera de 1,95 x 3 x 365 = 21,35 millions, ce qui reste dans la plage contrôlable.
Si l'entreprise se développe très rapidement et que l'exploitation et la maintenance peuvent encore le gérer, afin d'éviter des problèmes d'expansion à l'avenir, il est recommandé d'allouer autant de bibliothèques que possible.
5.3 Comment modifier le code métier
La modification de la partie code métier est fortement liée au métier, et la façon de la modifier n'est pas informative. Inutile de prêter attention aux points suivants :
- Pour la sous-table et la sous-base de données d'une table spécifique, l'impact du micro-service est uniquement dans le service où se trouve la table, s'il s'agit d'une application à architecture unique, ce sera plus gênant ;
- Dans l'architecture Internet, les contraintes de clé étrangère ne sont fondamentalement pas applicables ;
- Avec la popularité de la séparation des requêtes, de nombreuses opérations dans le système d'arrière-plan nécessitent des requêtes inter-bases de données, ce qui entraîne de mauvaises performances du système. À l'heure actuelle, les sous-tables et les sous-bases de données dissocient généralement la séparation des requêtes et fonctionnent ensemble : premier index tout données dans ES, puis utilisez les données ES Query directement en arrière-plan. Si la quantité de données de commande est importante, il existe une autre pratique courante : stockez d'abord le champ d'index dans ES (le champ utilisé comme condition de requête), puis placez les données détaillées dans HBase.
5.4. Migration des données historiques
L'idée de base de la migration des données :
les données de stockage sont directement migrées, les données incrémentielles sont surveillées dans le binlog, puis le programme de migration est averti de déplacer les données via le canal. La nouvelle base de données contient la quantité totale de données et le trafic est progressivement commuté après la réussite de la vérification.
Étapes détaillées de la solution de migration de données :
- Lancer le canal et déclencher la migration des données incrémentielles via le canal ;
- Une fois le test du script de la base de données de migration réussi, migrez les anciennes données vers la nouvelle sous-table et sous-base de données ;
- Faites attention à la différence de temps entre les données de migration et la migration des anciennes données, pour vous assurer que toutes les données sont migrées sans omission ;
- Une fois les étapes 2 et 3 terminées, la nouvelle sous-table et la nouvelle sous-base de données contiennent déjà la totalité des données. À ce stade, nous pouvons exécuter le programme de vérification des données pour nous assurer que toutes les données sont stockées dans la nouvelle base de données ;
- À ce stade, la migration des données est terminée, puis la nouvelle version du code sera lancée. Quant au téléchargement en niveaux de gris ou direct, il doit être décidé en fonction de la situation réelle, et le plan de restauration est le même.
5.5 Quel est le futur plan d'expansion
Avec le développement des affaires, si la conception de sharding d'origine ne peut plus répondre à la demande croissante de données, il est nécessaire d'envisager une extension, qui dépend des deux points suivants :
- Si la stratégie de partitionnement peut faire de la source de migration des nouvelles données de table une seule ancienne table au lieu de plusieurs anciennes tables, c'est pourquoi il est recommandé d'utiliser 2 à la Nième table de puissance ;
- Migration des données : Il est nécessaire de migrer les données des anciens shards vers les nouveaux shards, cette solution est la même que la migration des données historiques évoquée plus haut.