Schéma de sous-table de sous-base de données MySQL et sharding-spher (2)

6. Résumé de la sous-base de données et du sous-tableau

Considérez le partitionnement vertical et le partitionnement vertical dans la conception de la base de données

Au fur et à mesure que la quantité de données de base de données augmente, n'envisagez pas immédiatement le partitionnement horizontal. Envisagez d'abord le traitement du cache, la séparation lecture-écriture et utilisez des index. Si ces méthodes ne peuvent pas fondamentalement résoudre le problème, envisagez le partitionnement horizontal de la base de données et le partitionnement horizontal des tables.

  1. Pour sous-base de données et sous-table, vous devez d'abord savoir où se trouve le goulot d'étranglement, puis vous pouvez le diviser raisonnablement (sous-base de données ou sous-table ? Horizontal ou vertical ? Combien ?). Et il ne peut pas être divisé pour la sous-table de sous-base de données.
  2. Il est très important de sélectionner une clé, non seulement pour prendre en compte la répartition égale, mais également pour prendre en compte la requête de clé non partitionnée.
  3. Tant que les exigences peuvent être remplies, plus les règles de fractionnement sont simples, mieux c'est.

7. Exemple de sous-bibliothèque et sous-table

Exemple d'adresse GitHub : GitHub - littlecharacter4s/study-sharding : Sharding-JDBC learning

八、Sharding-JDBC

8.1 Présentation de ShardingSphere

8.1.1 Présentation de ShardingSphere

Apache ShardingSphere est un écosystème de solutions de bases de données distribuées open source. Il se compose de trois produits : JDBC , Proxy et Sidecar (en planification), qui peuvent être déployés indépendamment ou en conjonction avec des déploiements mixtes. Ils fournissent tous des fonctions telles que l'expansion horizontale des données standardisées, les transactions distribuées et la gouvernance distribuée, et peuvent être appliqués à divers scénarios d'application tels que l' isomorphisme Java , les langages hétérogènes et le cloud natif.

Apache ShardingSphere vise à utiliser pleinement et raisonnablement les capacités de calcul et de stockage des bases de données relationnelles dans des scénarios distribués, plutôt que de mettre en œuvre une toute nouvelle base de données relationnelle. Les bases de données relationnelles occupent encore aujourd'hui une énorme part de marché et sont la pierre angulaire des systèmes centraux d'entreprise, et elles seront difficiles à ébranler à l'avenir.Nous accordons plus d'attention à fournir des incréments sur la base d'origine plutôt qu'une subversion. La version Apache ShardingSphere 5.x a commencé à se concentrer sur l'architecture enfichable, et les composants fonctionnels du projet peuvent être étendus de manière flexible de manière enfichable. À l'heure actuelle, des fonctions telles que le partage des données, la séparation lecture-écriture, le cryptage des données et les tests de pression de la base de données fantôme, ainsi que la prise en charge de SQL et de protocoles tels que MySQL , PostgreSQL , SQLServer et Oracle , sont toutes intégrées au projet via plug -ins. Les développeurs peuvent personnaliser leur propre système unique comme des blocs de construction. Apache ShardingSphere fournit actuellement des dizaines de SPI en tant que points d'extension système, et leur nombre ne cesse d'augmenter. ShardingSphere est devenu un projet de haut niveau de l' Apache Software Foundation le 16 avril 2020 .

Principalement sur les trois points suivants :

  1. Un ensemble de solutions middleware de bases de données distribuées open source
  2. Il existe trois produits : Sharding-JDBC et Sharding-Proxy sont principalement utilisés
  3. Positionné comme middleware de base de données relationnelle, utiliser raisonnablement les opérations de base de données relationnelle dans un environnement distribué

Pour plus de détails, veuillez vous référer au document officiel : https://shardingsphere.apache.org/document/5.0.0/cn/user-manual/shardingsphere/

8.1.2 Présentation de ShardingSphere-JDBC

Positionné comme un framework java léger, comme spring et mybatis , il fournit des services supplémentaires sur la couche JDBC de java . Il utilise le client pour se connecter directement à la base de données et fournit des services sous la forme de packages jar sans déploiement ni dépendances supplémentaires. Il peut être compris comme une version améliorée du pilote JDBC et est entièrement compatible avec JDBC et divers frameworks ORM .

  • Applicable à tout framework ORM basé sur JDBC , tel que : JPA, Hibernate, Mybatis, Spring JDBC Template ou utiliser JDBC directement .
  • Prend en charge tout pool de connexion de base de données tiers, tel que : DBCP, C3P0, BoneCP, Druid, HikariCP , etc.
  • Prend en charge toute base de données qui implémente la spécification JDBC, prend actuellement en charge MySQL , Oracle , SQLServer , PostgreSQL et toute base de données qui suit la norme SQL92 .

8.1.3 Présentation de ShardingSphere-Proxy

Positionné comme un agent de base de données transparent, il fournit une version serveur qui encapsule le protocole binaire de la base de données pour supporter des langages hétérogènes. Actuellement, les versions MySQL et PostgreSQL sont fournies.Il peut utiliser n'importe quel client d'accès compatible avec le protocole MySQL/PostgreSQL (tel que : MySQL Command Client, MySQL , Workbench, Navicat , etc.) pour exploiter les données, ce qui est plus convivial pour DBA .

Il est complètement transparent pour l'application et peut être directement utilisé comme MySQL/PostgreSQL .

Applicable à tout client compatible avec le protocole MySQL/PostgreSQL .

Installation de ShardingSphere-Proxy

Adresse de téléchargement : Index de /dist/shardingsphere/4.1.1

8.2 Concepts de base

8.2.1SQL

tableau logique

Terme générique désignant la même logique et la même table de structure de données d'une base de données divisée horizontalement (table).

Exemple : ordonner les données en fonction de la fin de la clé primaire

Divisé en 10 tables, à savoir t_order_0 à t_order_9 , et leur nom de table logique est t_order .

vrai tableau

Tables physiques qui existent réellement dans une base de données partitionnée. C'est-à -dire t_order_0 à t_order_9 dans l'exemple précédent .

nœud de données

La plus petite unité de partage de données. Il se compose d'un nom de source de données et d'une table de données, par exemple : ds_0.t_order_0 .

tableau de reliure

La table principale et la sous-table avec les mêmes règles de partitionnement. Par exemple : la table t_order et la table t_order_item sont divisées en fonction de order_id

tranche, les deux tables sont des relations de table liées. Il n'y aura pas d'association de produits cartésiens dans une requête d'association multi-tables entre des tables liées, et l'efficacité de la requête d'association sera grandement améliorée.

tableau de diffusion

Fait référence aux tables qui existent dans toutes les sources de données fragmentées, et la structure de la table et les données dans les tables sont complètement cohérentes dans chaque base de données.

Il convient aux scénarios où la quantité de données n'est pas importante et doit être associée à des tables de données massives. Une table de dictionnaire est un scénario typique.

8.2.2 Fragmentation

​ 1 ) Clé fragmentée

Le champ de base de données utilisé le champ clé pour diviser horizontalement la base de données ( table ) . Exemple : Si la mantisse de la clé primaire dans la table de commande est modulo-partagée, la clé primaire de la table de commande est un champ fragmenté. S'il n'y a pas de champ de fragmentation dans SQL , un routage complet sera effectué et les performances seront médiocres. Outre la prise en charge des champs de partition unique, ShardingSphere prend également en charge le partitionnement basé sur plusieurs champs.

2 ) Algorithme de fragmentation

​Shard data by = , >= , <= , > , < , BETWEEN and IN sharding. L'algorithme de partitionnement doit être implémenté par les développeurs d'applications eux-mêmes, et la flexibilité réalisable est très élevée.

​Actuellement, 4 algorithmes de sharding sont fournis. Étant donné que l'algorithme de partitionnement est étroitement lié à la mise en œuvre de l'entreprise, aucun algorithme de partitionnement intégré n'est fourni, mais divers scénarios sont extraits via des stratégies de partitionnement, un niveau d'abstraction plus élevé est fourni et une interface est fournie pour que les développeurs d'applications implémentent eux-mêmes le partitionnement. algorithme.

Algorithme de fragmentation précis

​Correspondant à PreciseShardingAlgorithm , il est utilisé pour gérer le scénario de sharding avec = et IN en utilisant une seule clé comme clé de sharding . Il doit être utilisé avec StandardShardingStrategy .

algorithme de partitionnement de plage

​Correspondant à RangeShardingAlgorithm , il est utilisé pour traiter le scénario BETWEEN AND , > , < , >= , <= en utilisant une seule clé comme clé de sharding . Il doit être utilisé avec StandardShardingStrategy .

Algorithme de fragmentation composite

​Correspondant à ComplexKeysShardingAlgorithm , il est utilisé pour gérer des scénarios dans lesquels plusieurs clés sont utilisées comme clés de partitionnement pour le partitionnement. La logique consistant à inclure plusieurs clés de partitionnement est plus compliquée et les développeurs d'applications doivent gérer eux-mêmes la complexité. Il doit être utilisé avec ComplexShardingStrategy .

Algorithme de fragmentation des indices

​Correspond à HintShardingAlgorithm , qui est utilisé pour gérer les scénarios qui utilisent le partitionnement de ligne Hint . Il doit être utilisé avec HintShardingStrategy .

3 ) Stratégie de fragmentation

Contient la clé de partitionnement et l'algorithme de partitionnement, qui sont séparés indépendamment en raison de l'indépendance de l'algorithme de partitionnement. Ce qui peut vraiment être utilisé pour les opérations de partitionnement, c'est la clé de partitionnement + l'algorithme de partitionnement, c'est-à-dire la stratégie de partitionnement. Actuellement, 5 stratégies de partitionnement sont fournies.

Stratégie de fragmentation standard

​Correspondant à StandardShardingStrategy . Prise en charge des opérations de partitionnement de =, >, <, >=, <=, IN et BETWEEN AND dans les instructions SQL . StandardShardingStrategy ne prend en charge qu'une seule clé de partition et fournit deux algorithmes de partitionnement, PreciseShardingAlgorithm et RangeShardingAlgorithm . PreciseShardingAlgorithm est obligatoire et est utilisé pour traiter les fragments = et IN . RangeShardingAlgorithm est facultatif et est utilisé pour traiter BETWEEN AND, >, <, >=, <= fragmentation. Si RangeShardingAlgorithm n'est pas configuré , BETWEEN AND dans SQL sera traité en fonction de l'itinéraire complet de la base de données.

Stratégie de fragmentation composite

​Correspondant à ComplexShardingStrategy . Stratégie de partitionnement composite. Prise en charge des opérations de partitionnement de =, >, <, >=, <=, IN et BETWEEN AND dans les instructions SQL . ComplexShardingStrategy prend en charge plusieurs clés de partitionnement. Étant donné que la relation entre plusieurs clés de partitionnement est complexe, elle n'effectue pas trop d'encapsulation, mais transmet directement de manière transparente la combinaison clé-valeur de partitionnement et l'opérateur de partitionnement à l'algorithme de partitionnement, qui est entièrement développé par l'application ou obtenir une flexibilité maximale.

Stratégie de fragmentation des expressions de ligne

​Correspondant à InlineShardingStrategy . À l'aide d'expressions Groovy , il prend en charge les opérations de partitionnement de = et IN dans les instructions SQL , et ne prend en charge qu'une seule clé de partitionnement. Pour les algorithmes de sharding simples, une configuration simple peut être utilisée pour éviter le développement fastidieux du code Java , comme : t_user_$->{u_id % 8} signifie que la table t_user est divisée en 8 tables selon u_id modulo 8 , et le nom de la table est t_user_0 à t_user_7 .

Stratégie de fragmentation des indices

​Correspondant à HintShardingStrategy . Une stratégie de partitionnement en spécifiant la valeur de partitionnement via Hint au lieu d'extraire la valeur de partitionnement de SQL .

8.3 Présentation de ShardingSphere-JDBC

Positionné comme un framework java léger, comme spring et mybatis , il fournit des services supplémentaires sur la couche JDBC de java . Il utilise le client pour se connecter directement à la base de données et fournit des services sous la forme de packages jar sans déploiement ni dépendances supplémentaires. Il peut être compris comme une version améliorée du pilote JDBC et est entièrement compatible avec JDBC et divers frameworks ORM .

Applicable à tout framework ORM basé sur JDBC , tel que : JPA, Hibernate, Mybatis, Spring JDBC Template ou utiliser JDBC directement .

Prend en charge tout pool de connexion de base de données tiers, tel que : DBCP, C3P0, BoneCP, Druid, HikariCP , etc.

Prend en charge toute base de données qui implémente la spécification JDBC, prend actuellement en charge MySQL , Oracle , SQLServer , PostgreSQL et toute base de données qui suit la norme SQL92 .

Processus d'opération ShardingSphere – JDBC , et le but principal de son utilisation est de nous aider à simplifier les opérations liées aux données après la sous-table de sous-base de données.

8.4 Configuration de la fragmentation

Je suppose que tu aimes

Origine blog.csdn.net/2301_76957510/article/details/130926459
conseillé
Classement