Stratégies pour résoudre les difficultés techniques dans les sous-bases de données et les sous-tables de la base de données MySQL

Sous-base de données et schéma de table de base de données MySQL, une fois que la base de données est trop volumineuse, en particulier lorsque les écritures sont trop fréquentes et qu'elle est difficile à prendre en charge par un seul hôte, nous serons toujours confrontés à des goulots d'étranglement d'expansion. À l'heure actuelle, nous devons trouver d'autres moyens techniques pour résoudre ce goulot d'étranglement, à savoir la mauvaise technologie de segmentation des données que nous présenterons dans ce chapitre.

Segmentation de la base de données MySQL

Avant-propos

L'expansion réalisée grâce à la fonction MySQLReplication sera toujours limitée par la taille de la base de données. Une fois que la base de données est trop volumineuse, surtout lorsque les écritures sont trop fréquentes et qu'il est difficile d'être prise en charge par un seul hôte, nous serons toujours confrontés à des goulots d'étranglement d'expansion. À l'heure actuelle, nous devons trouver d'autres moyens techniques pour résoudre ce goulot d'étranglement, à savoir la mauvaise technologie de segmentation des données que nous présenterons dans ce chapitre.

Qu'est-ce que la segmentation des données

De nombreux lecteurs ont peut-être vu à plusieurs reprises des articles sur la segmentation des données sur Internet ou dans des magazines, mais ils sont simplement appelés fragmentation des données. En fait, qu’on l’appelle Sharding of data ou segmentation of data, le concept est le même.

En termes simples, cela signifie disperser les données que nous stockons dans la même base de données vers plusieurs bases de données (hôtes) via certaines conditions spécifiques pour obtenir l'effet de disperser la charge d'un seul appareil. La segmentation des données peut également améliorer la disponibilité globale du système après la panne d'un seul appareil. Seule une partie des données globales n’est pas disponible, mais pas la totalité des données.

Le partage des données est basé sur le type de règle de partage. Il peut être divisé en deux modes de segmentation.

La première consiste à le diviser en différentes bases de données (hôtes) selon différentes tables (ou schémas). Ce type de fractionnement peut être appelé fractionnement vertical (vertical) des données. L'autre consiste à diviser les données d'une même table en plusieurs bases de données (hôtes) selon certaines conditions basées sur la relation logique des données dans la table. Une telle segmentation est appelée segmentation horizontale (horizontale) des données.

La plus grande caractéristique de la segmentation verticale est que les règles sont simples et la mise en œuvre est plus pratique. Elle est particulièrement adaptée au couplage très faible entre diverses entreprises. Un système avec très peu d’interaction et une logique métier très claire. Dans un tel système, il est très simple de diviser les tables utilisées par différents modules métier dans différentes bases de données. Répartir selon différents tableaux. L’impact sur l’application sera également moindre et les règles de fractionnement seront plus simples et plus claires.

La segmentation horizontale est comparée à la segmentation verticale. Relativement parlant, c'est un peu plus compliqué. Étant donné que différentes données d'une même table doivent être divisées en différentes bases de données, pour l'application, les règles de fractionnement elles-mêmes sont plus compliquées que la répartition basée sur les noms de table, et la maintenance ultérieure des données sera également plus compliquée.

Lorsque la quantité de données et l'accès à une (ou plusieurs) de nos tables sont particulièrement importants et qu'ils ne peuvent toujours pas répondre aux exigences de performances après les avoir découpés verticalement sur un appareil indépendant, alors nous devons effectuer un découpage vertical et horizontal. être combinés. Coupez d'abord verticalement, puis horizontalement. Ce n'est qu'ainsi que nous pourrons résoudre le problème de performances d'une table aussi grande.

Ci-dessous, nous procéderons à une analyse correspondante sur la mise en œuvre de l'architecture des trois méthodes de segmentation des données de segmentation verticale, horizontale et combinée et l'intégration des données segmentées.

Segmentation verticale des données

Voyons d'abord ce qu'est la segmentation verticale des données. Découpage vertical des données. On peut aussi l’appeler segmentation verticale. Considérez une base de données comme étant composée de nombreux « morceaux de données » (tables), un morceau à la fois. Nous coupons ces « morceaux de données » verticalement et les répartissons sur plusieurs hôtes de base de données. Une telle méthode de segmentation est une segmentation verticale (longitudinale) des données.

Un système d'application avec une meilleure conception architecturale. Sa fonction globale doit être composée de nombreux modules fonctionnels. Les données requises par chaque module fonctionnel correspondent à une ou plusieurs tables de la base de données.

Dans la conception architecturale, plus les points d'interaction entre chaque module fonctionnel sont unifiés et moins nombreux, plus le couplage du système est faible, et meilleures sont la maintenabilité et l'évolutivité de chaque module du système. Un tel système. Il sera plus facile de réaliser une segmentation verticale des données.

Lorsque nos modules fonctionnels seront plus clairs et que le couplage sera plus faible, les règles de segmentation verticale des données seront plus faciles à définir. Les données peuvent être segmentées selon les modules fonctionnels. Les données des différents modules fonctionnels sont stockées dans différents hôtes de bases de données, ce qui peut facilement éviter l'existence de jointures entre bases de données. Dans le même temps, l’architecture du système est également très claire.

Bien sûr. Il est très difficile pour un système de rendre complètement indépendantes les tables utilisées par tous les modules fonctionnels, sans avoir besoin d'accéder aux tables des uns et des autres ou aux tables de deux modules pour les opérations de jointure. Dans ce cas, nous devons évaluer et peser en fonction du scénario d’application réel. Décidez si vous souhaitez autoriser l'application à stocker toutes les données associées des tables qui doivent être jointes dans la même base de données, ou laisser l'application faire beaucoup d'autres choses, c'est-à-dire que le programme obtient les données de différentes bases de données entièrement via l'interface du module, et puis dans le programme L'opération Join est terminée.

D'une manière générale. Supposons qu'il s'agisse d'un système avec une charge relativement légère et que les associations de tables soient très fréquentes. La base de données peut alors céder. La solution consistant à fusionner plusieurs modules liés entre eux pour réduire le travail de l’application peut réduire encore plus la charge de travail. est une solution réalisable.

Bien sûr. Grâce à la concession de la base de données, permettant à plusieurs modules de partager de manière centralisée des sources de données, elle introduit en fait brièvement le développement d'un couplage accru de l'architecture de chaque module, ce qui pourrait rendre la future architecture de pire en pire. Surtout lorsqu'elle atteint un certain stade de développement, on constate que la base de données ne peut pas supporter la pression apportée par ces tables. Je dois à nouveau affronter le temps de la séparation. Le coût de la transformation structurelle peut être bien supérieur au coût initial.

Alors. Lorsque la base de données est segmentée verticalement, comment la segmenter et dans quelle mesure constitue un problème difficile. Cela ne peut être réalisé qu’en équilibrant les coûts et les avantages de tous les aspects dans des scénarios d’application réels. Ce n’est qu’alors que vous pourrez analyser un plan fractionné qui vous convient vraiment.

Par exemple, analysons brièvement l'exemple de base de données du système de démonstration utilisé dans ce livre. Concevez ensuite une règle de segmentation simple pour effectuer une division verticale.

Les fonctions du système peuvent être essentiellement divisées en quatre modules fonctionnels : utilisateurs, messages de groupe, albums photo et événements. Par exemple, ils correspondent aux tables suivantes :

1. Table du module utilisateur : user, user_profile, user_group, user_photo_album

2. Table de discussion de groupe : groups, group_message, group_message_content, top_message

3. Table associée à l'album photo : photo, photo_album, photo_album_relation, photo_comment

4. Table d'informations sur l'événement : event

À première vue, aucun module ne peut exister indépendamment des autres modules, il existe des relations entre les modules. Se pourrait-il qu'il ne puisse pas être divisé ?

Bien sûr que non. Faisons une analyse un peu plus approfondie et nous pouvons constater que même si les tableaux utilisés par chaque module sont liés, la relation est relativement claire et simple.

◆ Le module de discussion de groupe et le module utilisateur sont principalement liés via des relations d'utilisateur ou de groupe. Généralement, l'association se fait via l'identifiant ou surnom de l'utilisateur et l'identifiant du groupe. L'implémenter via des interfaces entre modules ne posera pas trop de problèmes.

◆ Le module album photo est uniquement lié au module utilisateur via l'utilisateur. L'association entre ces deux modules est essentiellement liée au contenu via l'ID utilisateur. Simple et claire, l'interface est claire ;

◆ Le module d'événements peut être lié à chaque module, mais ils se concentrent uniquement sur les informations d'identification des objets dans chaque module. Il peut également être divisé très facilement.

Alors. Notre première étape peut être de diviser verticalement la base de données selon des tableaux liés aux modules fonctionnels. Les tables impliquées dans chaque module sont stockées dans une base de données distincte et les relations entre les tables entre les modules sont gérées via des interfaces côté système d'application. Par exemple, comme vous pouvez le voir sur l'image ci-dessous :

Après une telle segmentation verticale. Services qui n’étaient auparavant disponibles que via une base de données. Il a été divisé en quatre bases de données pour fournir des services, et les capacités de service ont naturellement été augmentées plusieurs fois.

Avantages de la segmentation verticale

◆ Le fractionnement de la base de données est simple et clair, et les règles de fractionnement sont claires

◆ Les modules d'application sont clairs et faciles à intégrer ;

◆ La maintenance des données est pratique et facile à localiser.

Inconvénients du partitionnement vertical

◆ Certaines associations de tables ne peuvent pas être réalisées au niveau de la base de données. Il doit être complété dans le programme.

◆ Pour les tables consultées extrêmement fréquemment et contenant de grandes quantités de données, il existe toujours une accalmie de performances, qui ne répond pas nécessairement aux exigences.

◆ Le traitement des transactions est relativement plus complexe ;

◆ Une fois que le partitionnement atteint un certain niveau, l'évolutivité rencontrera des limites

◆ Le partage en lecture excessive peut entraîner des transitions système complexes ; et difficile à entretenir.

Pour une segmentation verticale qui peut rencontrer des problèmes de segmentation des données et de transactions, il est vraiment difficile de trouver une meilleure solution au niveau de la base de données. Dans les cas d'application réels, la segmentation verticale de la base de données correspond principalement aux modules du système d'application. Les sources de données d'un même module sont stockées dans la même base de données, ce qui peut résoudre le problème de l'association des données au sein du module. Entre les modules, les données requises sont fournies entre elles via des programmes d'application sous forme d'interfaces de service.

Même si cela augmentera effectivement le nombre global d'opérations sur la base de données, c'est intentionnel en termes d'évolutivité globale du système et de modularisation de l'architecture. Le temps de réponse unique de certaines opérations peut être légèrement augmenté. Cependant, les performances globales du système seront très probablement améliorées dans une certaine mesure. Et le problème du goulot d’étranglement de l’expansion. Ce problème ne peut être surmonté qu’en s’appuyant sur l’architecture de segmentation horizontale des données qui sera présentée dans la section suivante.

Segmentation horizontale des données

La section ci-dessus analyse et présente la segmentation verticale des données. Cette section analysera la segmentation horizontale des données. La segmentation verticale des données peut fondamentalement être simplement comprise comme la segmentation des données selon des tableaux et des modules, tandis que la segmentation horizontale n'est plus segmentée selon des tableaux ou des modules fonctionnels. D'une manière générale, le partitionnement horizontal simple consiste principalement à disperser une table avec un accès extrêmement médiocre en plusieurs tables selon certaines règles d'un certain domaine. Chaque table contient une partie des données.

En termes simples. Nous pouvons comprendre la segmentation horizontale des données comme une segmentation selon les lignes de données. Cela signifie que certaines lignes de la table sont divisées en une seule base de données et que d'autres lignes sont divisées en d'autres bases de données. Bien entendu, afin de déterminer facilement dans quelle base de données chaque ligne de données est divisée, la division doit toujours être effectuée selon certaines règles.

Si un champ de type numérique est modulo un nombre spécifique, la plage d'un champ de type horaire. Ou la valeur de hachage d'un champ de type caractère. On suppose que la plupart des tables principales de l'ensemble du système peuvent être liées via un certain champ. Alors ce champ est naturellement le meilleur choix pour le partitionnement horizontal. Bien entendu, s'il est très spécial et ne peut pas être utilisé, vous ne pouvez en choisir qu'un autre.

D'une manière générale, comme les sites de type Web2.0 qui sont très populaires sur Internet aujourd'hui. Fondamentalement, la plupart des données peuvent être associées via les informations des utilisateurs membres, et de nombreuses tables principales peuvent être très adaptées à la segmentation horizontale des données via les ID de membre.

Et comme un système de discussion communautaire sur un forum. Il est encore plus simple de segmenter. Il est très simple de segmenter horizontalement les données selon le numéro du forum.

Il n'y aura fondamentalement aucune interaction entre les bibliothèques après la segmentation.

Comme notre système de démonstration. Toutes les données sont associées aux utilisateurs. Nous pouvons ensuite effectuer une répartition horizontale en fonction des utilisateurs et diviser les données de différents utilisateurs dans différentes bases de données. Bien entendu, la seule différence est que le tableau des groupes dans le module utilisateur n'est pas directement lié aux utilisateurs. Par conséquent, les groupes ne peuvent pas être divisés horizontalement en fonction des utilisateurs. Pour ces cas particuliers, nous pouvons être totalement autonomes. Placé séparément dans une base de données distincte.

En fait, on peut dire que cette approche utilise la méthode de « segmentation verticale des données » introduite dans la section précédente. Dans la section suivante, je présenterai plus en détail la méthode de segmentation conjointe utilisée à la fois pour la segmentation verticale et la segmentation horizontale.

Ainsi, pour notre exemple de base de données de démonstration, la plupart des tables peuvent être segmentées horizontalement en fonction de l'ID utilisateur. Les données liées aux différents utilisateurs sont segmentées et stockées dans différentes bases de données. Par exemple, tous les identifiants utilisateur sont pris modulo 2 puis stockés dans deux bases de données différentes.

Chaque table associée à un identifiant utilisateur peut être segmentée de cette manière. De cette façon, pratiquement toutes les données relatives aux utilisateurs. Ils sont tous dans la même base de données, et même s’ils doivent être liés, ils peuvent l’être très facilement.

Nous pouvons afficher les informations pertinentes de la segmentation horizontale de manière plus intuitive grâce à la figure suivante : Avantages de la segmentation horizontale

◆ L'association de tables peut essentiellement se faire dans le base de données Toutes les applications de bout en bout sont terminées ;

◆ Il n'y aura pas de problèmes de goulot d'étranglement pour certains très gros volumes de données et les tables à forte charge

◆ Il y a relativement peu de changements à apporter ; l'architecture globale de l'application est

◆ Le traitement des transactions est relativement simple

◆ Tant que les règles de segmentation peuvent être définies ; Il est fondamentalement difficile de rencontrer des limitations d'évolutivité ;

Inconvénients du partitionnement horizontal

◆ Les règles de partitionnement sont relativement plus complexes et il est très difficile d'abstraire une règle de partitionnement qui puisse satisfaire l'ensemble de la base de données. ;

◆ La difficulté de conserver les données au cours de la période ultérieure a augmenté et il est plus difficile de localiser manuellement les données

◆ Le degré de couplage de chaque module du système d'application est élevé ; , ce qui peut entraîner certains problèmes lors de la migration et des difficultés de fractionnement des données ultérieures.

Utilisation combinée de la segmentation verticale et horizontale

Dans les deux sections ci-dessus. Nous avons respectivement pris connaissance de la mise en œuvre des deux méthodes de segmentation « verticale » et « horizontale » et de l'information architecturale après segmentation. Parallèlement, les avantages et les inconvénients des deux architectures ont également été analysés. Mais dans les scénarios d'application réels, la charge n'est pas trop importante, sauf pour ceux-là. Les systèmes dotés d'une logique métier relativement simple peuvent résoudre les problèmes d'évolutivité grâce à l'une des deux méthodes de segmentation ci-dessus. Je crains que la plupart des autres systèmes dotés d'une logique métier légèrement plus complexe et d'une charge système plus importante ne puissent atteindre une meilleure évolutivité grâce à l'une des méthodes de segmentation des données ci-dessus. Il est nécessaire de combiner les deux méthodes de segmentation ci-dessus et d'utiliser différentes méthodes de segmentation dans différents scénarios.

Dans cette rubrique. Je combinerai les avantages et les inconvénients du découpage vertical et du découpage horizontal pour améliorer encore notre architecture globale et améliorer encore l'évolutivité du système.

D'une manière générale. Il est très difficile de connecter toutes les tables de notre base de données via un (ou plusieurs) champs, il est donc très difficile de résoudre tous les problèmes simplement par segmentation horizontale des données. Le partitionnement vertical ne peut résoudre qu'une partie du problème. Pour les systèmes soumis à des charges très élevées, même une seule table ne peut pas supporter sa charge via un seul hôte de base de données.

Nous devons combiner les méthodes de fractionnement « vertical » et « horizontal » en même temps pour exploiter pleinement les atouts des deux et éviter leurs défauts.

La charge de chaque système d'application augmente progressivement. Lorsqu'ils commencent à rencontrer des goulots d'étranglement en termes de performances, la plupart des architectes et des administrateurs de base de données choisiront d'abord de diviser verticalement les données, car ce coût est le plus élevé. Il correspond le mieux au ratio entrées-sorties maximal recherché au cours de cette période. Cependant. Alors que l'entreprise continue de se développer. À mesure que la charge du système continue de croître, une fois le système stable pendant un certain temps, le cluster de bases de données qui a été divisé verticalement peut être à nouveau submergé et rencontrer un goulot d'étranglement en termes de performances.

Comment choisir en ce moment ? Faut-il encore subdiviser les modules ou chercher d’autres solutions ? En supposant que nous continuions à subdiviser les modules et à effectuer une segmentation verticale des données comme nous l'avons fait au début, nous pourrions rencontrer dans un avenir proche les mêmes problèmes auxquels nous sommes confrontés aujourd'hui. Et avec le perfectionnement continu des modules, l'architecture du système d'application deviendra de plus en plus complexe, et l'ensemble du système pourrait très bien devenir incontrôlable.

En ce moment, nous devons profiter de la segmentation horizontale des données pour résoudre les problèmes rencontrés ici. De plus, nous n'avons pas besoin de renverser les résultats précédents de la segmentation verticale des données lors de l'utilisation de la segmentation horizontale des données. Au lieu de cela, nous utilisons les avantages de la segmentation horizontale pour éviter les inconvénients de la segmentation verticale. Résolvez le problème de la complexité croissante du système.

Les inconvénients du fractionnement horizontal (les règles sont difficiles à unifier) ​​ont également été résolus par le fractionnement vertical précédent. Facilitez le fractionnement horizontal.

Pour notre base de données d'exemples de démonstration. Supposons au début. Nous avons effectué une segmentation verticale des données. Cependant, à mesure que l'entreprise continuait de croître, le système de base de données a rencontré des goulots d'étranglement. Nous avons donc choisi de reconstruire l'architecture du cluster de bases de données. Comment refactoriser ? Considérant que la segmentation verticale des données a déjà été effectuée et que la structure des modules est claire.

Et la dynamique de croissance des entreprises est de plus en plus forte. Même si les modules sont désormais divisés davantage, cela ne durera pas longtemps.

Nous avons choisi de diviser horizontalement en fonction de la segmentation verticale.

Après division verticale, chaque cluster de bases de données ne possède qu'un seul module fonctionnel. Fondamentalement, toutes les tables de chaque module fonctionnel sont associées à un certain champ. Par exemple, tous les modules utilisateur peuvent être segmentés par ID utilisateur, et les modules de discussion de groupe peuvent tous être segmentés par ID de groupe. Le module album photo est segmenté en fonction de l'ID de l'album. Le tableau d'informations de notification d'événement final prend en compte la limite de temps des données (seules les informations d'un segment d'événement récent seront accessibles), il est donc considéré comme divisé par le temps.

La figure suivante montre l'ensemble de l'architecture après segmentation :

En fait, dans de nombreux systèmes d'applications à grande échelle, la segmentation verticale et la segmentation horizontale sont ces deux les méthodes de segmentation des données coexistent fondamentalement. Et elles sont souvent réalisées en alternance pour ajouter continuellement les capacités d'extension du système. Lorsque nous traitons de différents scénarios d’application, nous devons également pleinement prendre en compte les limites et les avantages de ces deux méthodes de segmentation. Utilisez différentes méthodes de collage à différents moments (pression de charge).

Avantages du partage conjoint

◆ Peut exploiter pleinement les avantages du découpage vertical et du découpage horizontal pour éviter leurs défauts respectifs

◆ Maximiser l'amélioration culturelle de l'évolutivité du système ;

Inconvénients de la scission syndicale

◆ L'architecture du système de base de données est relativement complexe. L'entretien est plus difficile.

◆ L'architecture de l'application est également relativement plus complexe

Solution de segmentation et d'intégration des données

À travers les chapitres précédents. Nous avons déjà indiqué très clairement que la segmentation des données via la base de données peut grandement améliorer l'évolutivité du système. Cependant, une fois les données de la base de données stockées dans différents hôtes de base de données via une segmentation verticale et/ou horizontale, le plus gros problème rencontré par le système d'application est de savoir comment mieux intégrer ces sources de données. C’est peut-être aussi une question qui préoccupe beaucoup de lecteurs. Notre objectif principal dans cette section est d'analyser les différentes solutions globales qui peuvent être utilisées pour nous aider à réaliser la segmentation et l'intégration des données.

L'intégration des données est très difficile pour obtenir cet effet en s'appuyant sur la base de données elle-même, bien que MySQL dispose d'un moteur de stockage fédéré qui peut résoudre certains problèmes similaires. Cependant, il est très difficile de bien l’utiliser dans des scénarios d’application réels. Alors comment intégrer ces sources de données dispersées sur différents hôtes MySQL ?

En général, il existe deux solutions :

1. Configurez et gérez une (ou plusieurs) sources de données dont vous avez besoin dans chaque module d'application. Accédez directement à chaque base de données et complétez l'intégration des données dans le module ;

2. Unifiez et gérez toutes les sources de données via la couche proxy intermédiaire. Le cluster de bases de données back-end est transparent pour l'application front-end

Peut-être que plus de 90 % des personnes auront tendance à choisir l'autre face aux deux solutions ci-dessus, d'autant plus que le système continue de s'agrandir. et plus complexe quand.

En effet. Il s’agit d’un choix très correct, même si le coût à court terme peut être relativement plus élevé, mais il est très utile pour l’évolutivité de l’ensemble du système.

Par conséquent, je ne vais pas trop analyser ici la première solution. Ci-dessous, je me concentrerai sur l'analyse de certaines solutions dans une autre solution.

★ Couche proxy intermédiaire auto-développée

Après avoir décidé d'utiliser la couche proxy intermédiaire de la base de données pour résoudre l'orientation architecturale de l'intégration des sources de données, de nombreuses entreprises (ou entreprises) ont choisi de développer lui-même. Applications de couche proxy qui répondent à des scénarios d'application spécifiques.

En développant votre propre couche proxy intermédiaire, vous pouvez répondre au maximum aux spécificités de vos propres applications. La personnalisation maximisée répond aux besoins individuels et peut répondre avec flexibilité aux changements. Il faut dire que c’est le plus grand avantage du développement de votre propre couche proxy.

Bien sûr, tout en choisissant de développer par vous-même et de profiter du plaisir de maximiser la personnalisation personnalisée, vous devrez naturellement investir de nombreux autres coûts dans la recherche et le développement précoces et dans les mises à niveau et améliorations continues ultérieures. Et le seuil technique lui-même peut être supérieur à celui des simples applications Web. Par conséquent, avant de décider de le développer vous-même, vous devez toujours procéder à une évaluation plus complète.

Depuis de nombreuses fois, lorsque vous vous développez vous-même, vous réfléchissez à la manière de mieux vous adapter à votre propre système d'application et de faire face à vos propres scénarios commerciaux, il n'est donc pas facile de trop analyser ici. Plus tard, nous analyserons principalement plusieurs solutions d'intégration de sources de données actuellement populaires.

★ Utilisez MySQLProxy pour réaliser la segmentation et l'intégration des données

MySQLProxy est un produit de couche proxy de base de données officiellement fourni par MySQL, comme MySQLServer, c'est également un produit open source basé sur l'accord open source GPL. . Peut être utilisé pour surveiller, analyser ou transmettre des informations de communication entre eux. Sa flexibilité vous permet de l'utiliser au maximum. Ses fonctions actuelles incluent principalement le routage des connexions, l'analyse des requêtes, le filtrage et la modification des requêtes et l'équilibrage de charge. Ainsi que le principal mécanisme HA, etc.

En fait, MySQLProxy lui-même n'a pas toutes les fonctions ci-dessus. Au lieu de cela, il fournit la base pour la mise en œuvre des fonctions ci-dessus.

Pour réaliser ces fonctions, nous devons écrire nos propres scripts LUA.

MySQLProxy établit en fait un pool de connexions entre la requête du client et MySQLServer. Toutes les demandes des clients sont envoyées à MySQLProxy, puis l'analyse correspondante est effectuée via MySQLProxy. Il est déduit s'il s'agit d'une opération de lecture ou d'écriture, et distribué au serveur MySQL correspondant. Pour les clusters esclaves multi-nœuds, il peut également réaliser un équilibrage de charge. Voici le schéma d'architecture de base de MySQLProxy :

Via le schéma d'architecture ci-dessus. Nous pouvons voir très clairement la position de MySQLProxy dans les applications pratiques et les choses de base qu'il peut faire.

À propos des détails d'implémentation plus spécifiques de MySQLProxy, il existe des introductions et des exemples de démonstration très spécifiques dans la documentation officielle de MySQL. Les lecteurs intéressés peuvent le télécharger gratuitement directement depuis le site officiel de MySQL ou le lire en ligne. Je n'entrerai pas dans le gaspillage de papier ici.

★Utilisez Amoeba pour réaliser la segmentation et l'intégration des données

Amoeba est un framework open source développé sur la base de Java et axé sur la résolution de programmes proxy d'intégration de sources de données de bases de données distribuées. Il est basé sur l'accord open source GPL3. À l'heure actuelle, Amoeba dispose déjà du routage des requêtes, du filtrage des requêtes, de la séparation lecture-écriture, de l'équilibrage de charge et du mécanisme HA ainsi que d'autres contenus associés.

Amoeba résout principalement les problèmes suivants :

1. Intégrer des sources de données complexes après la segmentation des données

2. la base de données.

3. Réduisez le nombre de connexions entre la base de données et le client.

4. Routage de séparation lecture-écriture ;

Nous pouvons voir que ce que fait Amoeba est exactement ce dont nous avons besoin pour améliorer l'évolutivité de la base de données grâce à la segmentation des données.

Amoeba n'est pas un programme proxy de couche proxy, mais un cadre de développement pour développer des programmes proxy de couche proxy de base de données. Actuellement, il existe deux programmes proxy développés sur la base d'Amoeba : AmoebaForMySQL et AmoebaForAladin.

AmoebaForMySQL est principalement une solution spécifiquement pour la base de données MySQL. Le protocole demandé par l'application front-end et la base de données source de données pour la connexion back-end doit être MySQL. Pour toute application client, il n'y a aucune différence entre AmoebaForMySQL et une base de données MySQL. Toute demande client utilisant le protocole MySQL peut être analysée par AmoebaForMySQL et traitée en conséquence. Ce qui suit peut nous indiquer les informations architecturales d'AmoebaForMySQL (du blog des développeurs Amoeba) :

AmoebaForAladin est une information plus largement applicable. Un programme proxy plus puissant.

Il peut se connecter simultanément à des sources de données dans différentes bases de données pour fournir des services pour les applications frontales, mais n'accepte que les demandes d'applications client conformes au protocole MySQL. En d'autres termes, tant que l'application frontale est connectée via le protocole MySQL, AmoebaForAladin analysera activement l'instruction Query et identifiera automatiquement la source de données de la requête en fonction des données demandées dans l'instruction Query sur un hôte physique. La figure suivante montre les détails architecturaux d'AmoebaForAladin (du blog des développeurs Amoeba) :

À première vue, les deux semblent être exactement les mêmes. Après un examen plus approfondi, vous constaterez que la principale différence entre les deux réside uniquement après le traitement via MySQLProtocalAdapter. La base de données source de données est déduite sur la base des résultats de l'analyse. Sélectionnez ensuite un pilote JDBC spécifique et le protocole correspondant pour vous connecter à la base de données principale.

En fait, à travers les deux schémas d'architecture ci-dessus, vous avez peut-être découvert les caractéristiques d'Amoeba. Il s'agit simplement d'un framework de développement. En plus des deux produits qu'il a fournis, ForMySQL et ForAladin. Elle peut également réaliser le développement secondaire correspondant en fonction de ses propres besoins. Obtenez un programme proxy plus adapté à nos propres caractéristiques d'application.

Lors de l'utilisation de la base de données MySQL. AmoebaForMySQL et AmoebaForAladin peuvent être très bien utilisés. Bien entendu, étant donné que plus un système est complexe, ses performances subiront certainement une certaine perte et le coût de maintenance sera naturellement relativement plus élevé. Par conséquent, lorsque vous avez uniquement besoin d’utiliser la base de données MySQL, je recommande toujours d’utiliser AmoebaForMySQL.

AmoebaForMySQL est très simple à utiliser. Tous les fichiers de configuration sont des fichiers XML standard, et il y a quatre fichiers de configuration au total. Ce sont :

◆ amoeba.xml : fichier de configuration principal, configure toutes les sources de données et les propres paramètres d'Amoeba.

◆ Rule.xml : configurez toutes les informations sur les règles de routage des requêtes.

◆ functionMap.xml : configurez la classe d'implémentation Java correspondant à la fonction dans Query ;

◆ rullFunctionMap.xml : configurez la classe d'implémentation des fonctions spécifiques qui doivent être utilisées dans les règles de routage ;

En supposant que vos règles ne soient pas trop compliquées, il vous suffit d'utiliser les deux premiers des quatre fichiers de configuration ci-dessus pour terminer tout le travail. Les fonctionnalités souvent utilisées par les programmes proxy incluent la séparation de la lecture et de l’écriture. L'équilibrage de charge et d'autres configurations sont effectués dans amoeba.xml. aussi. Amoeba prend déjà en charge son propre routage actif qui implémente le partage vertical et horizontal des données. Les règles de routage peuvent être définies dans Rule.xml.

Les principales lacunes d'Amoeba pour le moment sont ses fonctions de gestion en ligne et la prise en charge des transactions. J'ai fait des suggestions pertinentes lors du processus de communication avec les développeurs concernés dans le passé, et j'espère fournir un système capable de fonctionner. maintenance et gestion en ligne. L'outil de gestion en ligne de commande est pratique pour la maintenance en ligne. Les retours reçus sont qu'un module de gestion dédié a été inclus dans le calendrier de développement. De plus, en termes de prise en charge des transactions, Amoeba n'est toujours pas en mesure de le faire. Même si l'application client inclut des informations sur la transaction dans la demande soumise à Amoeba, Amoeba ignorera les informations relatives à la transaction. Bien sûr, après une amélioration continue, je pense que la prise en charge des transactions est définitivement une fonctionnalité qu'Amoeba envisagera d'ajouter.

Les lecteurs peuvent obtenir une utilisation plus spécifique d'Amoeba via le manuel d'utilisation fourni sur le blog des développeurs d'Amoeba (http://amoeba.sf.net), qui ne sera pas décrit en détail ici.

★Utilisez HiveDB pour réaliser la segmentation et l'intégration des données

Comme les précédents MySQLProxy et Amoeba, HiveDB est également un framework open source basé sur Java qui fournit la segmentation et l'intégration des données pour la base de données MySQL. HiveDB ne prend actuellement en charge que la segmentation horizontale des données.

Résout principalement le problème de l'évolutivité des bases de données et de l'accès aux données hautes performances sous de gros volumes de données, tout en prenant en charge la redondance des données et le principal mécanisme HA.

Le mécanisme d'implémentation de HiveDB est quelque peu différent de MySQLProxy et Amoeba. Il n'utilise pas la fonction de réplication de MySQL pour obtenir la redondance des données, mais implémente son propre mécanisme de redondance des données, et sa couche sous-jacente est principalement basée sur HibernateShards pour y parvenir. travail de segmentation des données.

Dans HiveDB, les données sont dispersées sur plusieurs serveurs MySQL via diverses clés de partition définies par l'utilisateur (en fait, il s'agit de formuler des règles de segmentation des données). Au moment de la visite. Lors de l'exécution d'une requête Query. Il analysera activement les conditions de filtrage par lui-même, lira les données de plusieurs serveurs MySQL en parallèle, fusionnera les ensembles de résultats et les renverra à l'application client.

En termes purement fonctionnels, HiveDB n'est peut-être pas aussi puissant que MySQLProxy et Amoeba, mais ses idées de segmentation des données ne sont pas essentiellement différentes des deux précédentes. De plus, HiveDB n'est pas seulement un contenu partagé par des passionnés de l'open source, mais un projet open source soutenu par des sociétés commerciales.

Ce qui suit est une image du premier chapitre du site officiel de HiveDB, qui décrit les informations de base sur la façon dont HiveDB organise les données. Bien qu'il ne puisse pas afficher spécifiquement trop d'informations architecturales, il peut essentiellement montrer son utilisation dans les données. . L'aspect segmentation est unique.

★ Intégration de données mycat : spécifique http://www.songwie.com/articlelist/11

★ Autres solutions de segmentation et méthodes d'intégration de données

En plus des solutions globales de segmentation et d'intégration des données présentées ci-dessus, il existe de nombreuses autres solutions qui offrent la même segmentation et intégration des données. Par exemple, HSCALE est encore étendu sur la base de MySQLProxy et SpockProxy est construit via Rails. Ainsi que des Pyshards basés sur Pathon et plus encore.

Quelle que soit la solution que vous choisissez d'utiliser, l'idée globale de conception ne devrait fondamentalement pas changer du tout. Il s'agit d'améliorer les capacités globales de service de la base de données grâce à la segmentation verticale et horizontale des données, afin que l'évolutivité globale du système d'application puisse être améliorée autant que possible. La méthode d'expansion est aussi pratique que possible.

Tant que nous utilisons l'application proxy de couche intermédiaire pour mieux surmonter les problèmes de segmentation des données et d'intégration des sources de données. L’évolutivité linéaire de la base de données sera alors très simple pour être aussi pratique que notre application. En ajoutant simplement un serveur PCServerserver bon marché, la capacité globale de service du cluster de base de données peut être augmentée de manière linéaire, de sorte que la base de données ne devienne plus facilement le goulot d'étranglement des performances du système d'application.

Problèmes possibles de segmentation et d'intégration des données

Ici. Chacun doit avoir une certaine compréhension de la mise en œuvre de la segmentation et de l'intégration des données. Peut-être que de nombreux lecteurs et amis ont essentiellement choisi une solution adaptée à leurs propres scénarios d'application en fonction des avantages et des inconvénients des caractéristiques respectives des différentes solutions. Le travail ultérieur consiste principalement à préparer la mise en œuvre.

Avant de mettre en œuvre le plan de segmentation des données, nous devons encore faire quelques analyses sur certains problèmes possibles.

D'une manière générale, les principaux problèmes que nous pouvons rencontrer sont les suivants :

◆ Le problème de l'introduction des transactions distribuées.

◆ Le problème de la jointure entre nœuds

◆ Le problème du tri et de la pagination par fusion entre nœuds.

1. Le problème de l'introduction de transactions distribuées

Une fois les données segmentées et stockées sur plusieurs serveurs MySQL, quelle que soit la perfection de nos règles de segmentation (en fait, ce n'est pas le cas). règle de segmentation), cela peut faire que les données impliquées dans certaines transactions précédentes ne se trouvent plus dans le même serveur MySQL.

Dans ce scénario, supposons que notre application suit toujours l'ancienne solution. Il faut alors introduire des transactions distribuées pour le résoudre. Parmi les différentes versions de MySQL, seules les versions à partir de MySQL 5.0 ont commencé à prendre en charge les transactions distribuées, et actuellement, seul Innodb prend en charge les transactions distribuées. Pas seulement ça. Même si nous utilisons une version de MySQL prenant en charge les transactions distribuées. Dans le même temps, le moteur de stockage Innodb a également été utilisé. Les transactions distribuées elles-mêmes consomment beaucoup de ressources système et les performances elles-mêmes ne sont pas trop élevées. Et l’introduction des transactions distribuées elle-même apportera davantage de facteurs difficiles à contrôler en termes de gestion des exceptions.

Que faire ? En fait, nous pouvons résoudre ce problème grâce à une solution de contournement. La première chose à considérer est la suivante : la base de données est-elle le seul endroit où les transactions peuvent être résolues ? En fait, ce n’est pas le cas. Nous pouvons résoudre complètement le problème en combinant à la fois la base de données et l’application. Chaque base de données gère ses propres affaires. Utilisez ensuite l'application pour contrôler les transactions sur plusieurs bases de données.

C'est à dire. Juste si nous le voulons. Il est tout à fait possible de diviser une transaction distribuée sur plusieurs bases de données en plusieurs petites transactions qui n'existent que sur une seule base de données. Et utilisez l'application pour contrôler diverses petites transactions.

Bien entendu, la condition préalable est que notre application russe soit suffisamment robuste. Bien entendu, cela entraînera également quelques difficultés techniques pour l’application.

2. Problèmes de jointure entre nœuds

Ce qui précède présente les problèmes qui peuvent introduire des transactions distribuées. Examinons maintenant les problèmes qui nécessitent une jointure entre nœuds.

Après segmentation des données. Cela peut entraîner la non-utilisation de certaines anciennes instructions Join. Parce que la source de données utilisée par Join peut être divisée en plusieurs serveurs MySQL.

Que dois-je faire ? Du point de vue de la base de données MySQL, si ce problème doit être résolu directement du côté de la base de données, je crains qu'il ne puisse être surmonté que via Federated, un moteur de stockage spécial de MySQL. Le moteur de stockage fédéré est la solution de MySQL à des problèmes similaires à DBLink d'Oracle.

La principale différence avec OracleDBLink est que Federated enregistrera localement une copie des informations de définition de la structure de la table distante. À première vue, Federated est en effet une très bonne solution pour rejoindre plusieurs nœuds. Mais nous devons également être clairs : il semble que si la structure de la table distante change, les informations de définition de la table locale ne changeront pas en conséquence. Il est supposé que les informations de définition de la table fédérée locale ne sont pas mises à jour lors de la mise à jour de la structure de la table distante. Il est très probable que des erreurs d'exécution de requête se produiront et que des résultats corrects ne seront pas obtenus.

Pour résoudre ce genre de problème, je recommande toujours de le gérer via le programme d'application. Tout d'abord, récupérez le jeu de résultats du pilote correspondant à partir du serveur MySQL où se trouve la table des pilotes. Récupérez ensuite les données correspondantes du serveur MySQL où se trouve la table pilotée en fonction du jeu de résultats du pilote. De nombreux lecteurs peuvent penser que cela aura un certain impact sur les performances. Oui, cela aura effectivement un certain impact négatif sur les performances, mais à part cette méthode, il n'y a fondamentalement pas beaucoup d'autres meilleures solutions.

Et comme la base de données est mieux étendue, la charge de chaque serveur MySQL peut être mieux contrôlée. Pour une seule requête, le temps de réponse peut être plus élevé qu'avant sa segmentation, de sorte que l'impact négatif sur les performances n'est pas trop important. sans parler de. Il n'y a pas trop d'exigences pour une jointure entre nœuds similaire à celle-ci. Par rapport à la performance globale, cela ne représente peut-être qu’une très petite partie. Donc, dans un souci de performances globales, sacrifiez parfois un peu. Cela en vaut vraiment la peine. Après tout, l’optimisation du système elle-même est un processus comportant de nombreux compromis et équilibres.

3. Problèmes de tri et de pagination par fusion entre nœuds

Une fois les données divisées horizontalement, il se peut que ce ne soit pas seulement la jointure entre nœuds qui ne peut pas être exécutée normalement, mais aussi certains tris et pagination des instructions de requête. La source de données peut également être divisée en plusieurs nœuds. La conséquence directe de ceci est que ces requêtes de tri et de pagination ne peuvent pas continuer à s'exécuter normalement. En fait, c'est la même chose que la jointure entre nœuds. La source de données existe sur plusieurs nœuds et doit être résolue via une requête, ce qui est la même opération qu'une jointure entre nœuds. De même, Federated peut également le résoudre partiellement. Bien sûr, il existe également des risques.

Toujours le même problème, que dois-je faire ? Je continue toujours à recommander de le résoudre via l'application.

Comment le résoudre ? L'idée de la solution est généralement similaire à la solution de jointure entre nœuds, mais il y a une chose qui est différente de la jointure entre nœuds. Rejoindre a souvent une relation axée sur le conducteur. Par conséquent, la lecture des données entre plusieurs tables impliquées dans la jointure elle-même a généralement une relation séquentielle. Mais la pagination de tri est différente. La source de données de la pagination de tri peut essentiellement être considérée comme une table (ou un ensemble de résultats). Il n'y a pas de relation séquentielle en soi, de sorte que le processus de récupération de données à partir de plusieurs sources de données peut être complètement parallélisé.

Par ici. Nous pouvons atteindre une plus grande efficacité dans la récupération des données de pagination triées que la jointure entre bases de données. Par conséquent, la perte de performances provoquée est relativement moindre et, dans certains cas, elle peut être plus efficace que dans la base de données d'origine sans segmentation des données.

Bien sûr, qu'il s'agisse d'une jointure entre nœuds ou d'un tri et d'une pagination entre nœuds. Cela amènera notre serveur d'applications à consommer beaucoup d'autres ressources, en particulier des ressources mémoire, car le processus de lecture, d'accès et de fusion des jeux de résultats nous oblige à traiter beaucoup plus de données qu'auparavant.

Après avoir analysé ce point, de nombreux lecteurs constateront peut-être que tous les problèmes ci-dessus sont essentiellement résolus grâce aux applications. Tout le monde commence peut-être à murmurer dans son cœur. Est-ce parce que je suis DBA que je laisse beaucoup de choses aux architectes et développeurs d’applications ?

En fait, ce n'est pas du tout le cas. Tout d'abord, l'application est due à sa particularité. Il est très simple d’obtenir une très bonne évolutivité, mais la base de données est différente. L’expansion doit être réalisée de bien d’autres manières. Et dans ce processus d'expansion, il est très difficile d'éviter des situations qui peuvent être résolues dans une base de données centralisée mais qui deviennent un problème difficile après avoir été divisées en un cluster de bases de données.

Pour maximiser l'expansion globale du système, nous ne pouvons permettre à l'application que de faire beaucoup d'autres choses. Pour résoudre des problèmes qui ne peuvent pas être correctement résolus par les clusters de bases de données.

Résumé

Divisez un grand serveur MySQL en plusieurs petits serveurs MySQL grâce à la technologie de segmentation des données, qui non seulement résout le problème des goulots d'étranglement des performances d'écriture, mais améliore également une fois de plus l'évolutivité de l'ensemble du cluster de base de données. Que ce soit par segmentation verticale ou par segmentation horizontale. Tout cela peut rendre le système moins susceptible de rencontrer des goulots d’étranglement. Surtout lorsque nous utilisons une combinaison de méthodes de découpage vertical et horizontal, nous ne rencontrerons théoriquement plus de goulots d’étranglement en matière d’expansion.

Recommandations associées :

Sous-base de données et méthode de sous-table de la base de données MySQL (couramment utilisées)_MySQL

Base de données maître-esclave MySQL , sous-base de données sous-base de données Notes sur tables_MySQL

Vidéo mysql du vieux garçon : Méthode de dépannage des problèmes de démarrage multi-instance de la base de données MySQL et pratique dépannage

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!