Méthode MySQL pour mettre en œuvre la segmentation des données : 1. Utiliser la segmentation verticale des données ; 2. Utiliser la segmentation horizontale des données ; 3. Utiliser le proxy MySQL pour réaliser la segmentation et l'intégration des données ; 5. Utilisez HiveDB pour réaliser la segmentation et l'intégration des données.
Plus de recommandations d'apprentissage gratuites connexes : tutoriel mysql (Vidéo)
Comment MySQL implémente la segmentation des données :
Qu'est-ce que la segmentation des données
Pour En termes simples, cela signifie disperser les données stockées dans la même base de données vers plusieurs bases de données (hôtes) dans certaines conditions spécifiques pour obtenir l'effet de disperser la charge d'un seul appareil. Le découpage des données peut également améliorer la disponibilité globale du système, car après la panne d'un seul appareil, seule une certaine partie des données globales est indisponible, et non la totalité des données.
Le partage de données (Sharding) peut être divisé en deux modes de partage selon le type de ses règles de partage. L'une consiste à le diviser en différentes bases de données (hôtes) selon différentes tables (ou schémas). Cette division peut être appelée division verticale (verticale) des données ; relation logique, les données d'une même table sont divisées en plusieurs bases de données (hôtes) selon certaines conditions. Ce type de segmentation est appelé 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 plus pratique. Elle est particulièrement adaptée aux systèmes avec un très faible couplage entre différentes entreprises, peu d'influence mutuelle et une logique métier très claire. Dans ce type de système, il est facile de diviser les tables utilisées par différents modules métier dans différentes bases de données. Le fractionnement selon différentes tables aura moins d'impact sur l'application, et les règles de fractionnement seront plus simples et plus claires.
La segmentation horizontale est légèrement plus compliquée que la segmentation verticale. É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 répartition 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 le volume de données et le volume d'accès d'une certaine (ou de plusieurs) table(s) sont particulièrement importants et que les exigences de performances ne sont toujours pas satisfaites après un découpage vertical et son placement sur un appareil indépendant, un partitionnement vertical combiné doit être effectué. avec la segmentation horizontale, la segmentation verticale d'abord, puis la segmentation horizontale peuvent résoudre le problème de performances de cette très grande table.
Ce qui suit est une analyse correspondante de la mise en œuvre de l'architecture des trois méthodes de segmentation des données de segmentation verticale, horizontale et combinée et de l'intégration des données segmentées.
Segmentation verticale des données
Voyons d'abord comment se fait la segmentation verticale des données. La segmentation verticale des données peut également être appelée segmentation verticale. Considérez la base de données comme étant constituée de nombreux « blocs de données » (tables), un par un. Coupez ces « blocs de données » verticalement, puis répartissez-les sur plusieurs hôtes de base de données. Une telle méthode de découpage est le découpage vertical (longitudinal) des données.
La fonction globale d'un système d'application avec une architecture bien conçue doit être composée de nombreux modules fonctionnels, et 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 degré de couplage du système est faible et meilleures sont la maintenabilité et l'évolutivité de chaque module du système. Un tel système facilite la réalisation d’une segmentation verticale des données.
Plus les modules fonctionnels sont clairs et plus le couplage est faible, plus il est facile de définir les règles de segmentation verticale des données. Les données peuvent être segmentées en fonction de modules fonctionnels. Les données de différents modules fonctionnels sont stockées dans différents hôtes de bases de données. Les jointures entre bases de données peuvent être facilement évitées et l'architecture du système est également très claire.
Bien sûr, il est difficile pour un système de rendre les tables utilisées par tous les modules fonctionnels complètement indépendantes, et il n'est pas du tout nécessaire d'accéder aux tables des autres, ou il est nécessaire de joindre les tables des deux modules. Dans ce cas, l’évaluation et les compromis doivent être effectués sur la base de scénarios d’application réels. Décidez si vous souhaitez accueillir l'application et stocker les modules associés des tables qui doivent être jointes dans la même base de données, ou laisser l'application faire plus de choses - obtenez des données de différentes bases de données entièrement via l'interface du module, puis effectuez l'opération de jointure dans le programme. .
D'une manière générale, s'il s'agit d'un système avec une charge relativement légère et des associations de tables très fréquentes, alors la base de données peut céder et fusionner plusieurs modules liés ensemble pour réduire le travail de l'application. Avec plus de charge de travail, c'est faisable. solution.
Bien sûr, grâce à la concession de la base de données, permettre à plusieurs modules de partager de manière centralisée des sources de données acquiesce en fait indirectement au développement d'un couplage accru de chaque architecture de module, ce qui pourrait aggraver les architectures futures. Surtout lorsqu'elle atteint un certain stade de développement et qu'on découvre que la base de données ne peut pas supporter la pression exercée par ces tables et doit être à nouveau segmentée, le coût de la transformation architecturale peut être bien plus élevé que la conception architecturale initiale utilisant la segmentation.
Ainsi, lorsque la base de données est segmentée verticalement, comment la segmenter et dans quelle mesure est un problème difficile. Ce n'est qu'en équilibrant les coûts et les avantages de tous les aspects dans des scénarios d'application réels que nous pourrons analyser un plan de fractionnement qui nous convient vraiment.
Par exemple, dans la base de données d'exemple du système exemple utilisé dans cet article, nous l'analysons brièvement, puis concevons une règle de segmentation simple pour effectuer une division verticale.
Les fonctions du système peuvent être essentiellement divisées en 4 modules fonctionnels : utilisateurs, messages de groupe, albums photos et événements, qui correspondent aux tableaux suivants :
Tableau des modules utilisateur : user,user_profile,user_group,user_photo_album
Table de discussion de groupe : groups,group_message,group_message_content,top_message
Tableau associé à l'album : photo, photo_album, photo_album_relation, photo_comment
Tableau d'informations sur l'événement : événement
À première vue, aucun module ne peut exister indépendamment des autres modules et il existe un. relation entre les modules. Est-il impossible de les séparer ?
Bien sûr que non. Après une analyse un peu plus approfondie, vous constaterez que même si les tableaux utilisés par chaque module sont liés les uns aux autres, 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 le pseudo de l'utilisateur et l'identifiant du groupe. La mise en œuvre via l'interface entre les modules ne posera pas trop de problèmes.
Le module album photo n'a qu'une association utilisateur avec le module utilisateur. L'association entre ces deux modules concerne essentiellement uniquement le contenu associé à l'ID utilisateur, qui est simple et clair, et 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, qui sont également plus faciles à diviser.
Par conséquent, la première étape peut être de diviser verticalement la base de données selon les tables liées aux modules fonctionnels. Les tables impliquées dans chaque module sont divisées dans une base de données distincte. L'association des tables entre les modules se fait dans l'application. Le côté système est géré via l’interface. Comme le montre le diagramme schématique de la segmentation verticale des données (Figure 1) :
Après une telle segmentation verticale, les services qui ne pouvaient être fournis que via une seule base de données auparavant ont été divisés en quatre bases de données pour fournir des services. augmenté plusieurs fois.
Avantages de la segmentation verticale :
Inconvénients de la segmentation verticale :
- Certaines associations de tables ne peuvent pas être complétées au niveau de la base de données et doivent être complétées dans le programme
- Pour les tables consultées extrêmement fréquemment et contenant de grandes quantités de données, il existe toujours des goulots d'étranglement en termes de performances, qui ne répondent pas nécessairement aux exigences
- Transaction ; le traitement est relativement complexe ;
- Une fois que la segmentation atteint un certain niveau, l'évolutivité sera limitée
- Une segmentation excessive peut rendre le système trop complexe et ; difficile à entretenir.
Au vu des problèmes de segmentation des données et de transactions qui peuvent être rencontrés en segmentation verticale, 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, cela est bénéfique 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é, mais les performances globales du système sont susceptibles d'être améliorées dans une certaine mesure. Le problème du goulot d’étranglement de l’expansion ne peut être résolu 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 la segmentation verticale des données, et cette section analyse la segmentation horizontale des données. La segmentation verticale des données peut simplement être comprise comme la division des données selon des tableaux ou des modules, tandis que la segmentation horizontale est différente. D'une manière générale, le partitionnement horizontal simple consiste principalement à disperser une table avec un accès extrêmement trivial en plusieurs tables selon certaines règles d'un certain champ, et chaque table contient une partie des données.
Pour faire simple, la segmentation horizontale des données peut être comprise comme une segmentation en fonction des lignes de données, c'est-à-dire que certaines lignes du tableau sont segmentées dans une base de données et d'autres lignes sont segmentées dans d'autres bases de données. . Bien entendu, afin de déterminer facilement dans quelle base de données chaque ligne de données a été découpée, le découpage doit toujours être effectué selon certaines règles : par exemple, prendre un modulo basé sur un nombre précis basé sur un champ de type numérique, une certaine heure La plage de champs de type ou la valeur de hachage d'un champ de type caractère. Si la plupart des tables principales de l'ensemble du système peuvent être reliées via un certain champ, alors ce champ est naturellement le meilleur choix pour le partitionnement horizontal, sauf bien sûr dans des cas très particuliers où il ne peut pas être utilisé.
De manière générale, comme les sites Web 2.0 très populaires actuellement, la plupart des données peuvent être associées via les informations des utilisateurs membres. Peut-être que de nombreuses tables principales sont très adaptées à la segmentation horizontale des données via les identifiants des membres. Par exemple, le système de discussion de la communauté du forum est plus facile à segmenter. Il peut être segmenté horizontalement en fonction du numéro du forum. Après le fractionnement, il n'y aura pratiquement aucune interaction entre les bibliothèques.
Si toutes les données de l'exemple de système sont associées à des utilisateurs, alors la répartition horizontale peut être effectuée en fonction des utilisateurs et les données des différents utilisateurs peuvent être divisées en 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, les groupes ne peuvent donc pas être divisés horizontalement en fonction des utilisateurs. Pour ce cas particulier, la table peut être complètement séparée et placée dans une base de données indépendante. 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. Cette méthode de segmentation conjointe qui utilise à la fois la segmentation verticale et la segmentation horizontale sera présentée plus en détail dans la section suivante. section.
Ainsi, pour l'exemple de base de données, la plupart des tables peuvent être divisé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 divisée comme ceci. De cette façon, pratiquement toutes les données relatives aux utilisateurs se trouvent dans la même base de données, et même si une corrélation est nécessaire, elle est très facile à mettre en œuvre.
Vous pouvez afficher les informations liées à la segmentation horizontale de manière plus intuitive grâce au diagramme de segmentation horizontale (Figure 2) :
Avantages de la segmentation horizontale :
Association de tables peut essentiellement être complété du côté de la base de données
Il n'y aura pas de problème de goulot d'étranglement pour certains très gros volumes de données et tables à charge élevée
L'architecture globale de l'application présente relativement peu de changements ;
Le traitement des transactions est relativement simple
Tant que les règles de segmentation peuvent être définies ; Eh bien, fondamentalement, il est plus difficile d’atteindre les limites d’évolutivité.
Inconvénients de la segmentation horizontale :
Les règles de segmentation sont relativement complexes, et il est difficile d'abstraire une règle de segmentation qui puisse satisfaire l'ensemble base de données ;
La difficulté de conserver les données dans la période ultérieure a augmenté et il est plus difficile de localiser manuellement les données
La base de données ; Le degré de couplage de chaque module du système d'application est élevé, ce qui peut entraîner certaines difficultés lors de la migration et du fractionnement ultérieurs des données.
L'utilisation de la segmentation combinée verticale et horizontale
Dans les deux sections précédentes, nous avons découvert les deux termes « vertical » et « horizontal " respectivement. La mise en œuvre de chaque méthode de segmentation et les informations architecturales après segmentation, ainsi que les avantages et inconvénients respectifs des deux architectures. Cependant, dans les scénarios d'application réels, à l'exception des systèmes où la charge n'est pas trop importante et la logique métier est relativement simple, ce qui peut résoudre le problème d'évolutivité grâce à l'une des deux méthodes de segmentation ci-dessus, je crains que la plupart des autres systèmes avec des La logique métier et la logique métier complexe peuvent résoudre le problème d'évolutivité.Les systèmes avec des charges lourdes ne peuvent pas obtenir une meilleure évolutivité grâce à l'une des méthodes de segmentation des données ci-dessus. Cela nécessite une combinaison des deux méthodes de segmentation ci-dessus, et différents scénarios utilisent différentes méthodes de segmentation.
Cette section combinera les avantages et les inconvénients du découpage vertical et du découpage horizontal pour améliorer encore l'architecture globale et améliorer l'évolutivité du système.
De manière générale, il est difficile de connecter toutes les tables de la base de données via un certain (ou quelques) champs, donc seule la segmentation horizontale des données ne peut pas résoudre tous les problèmes. 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. Il est nécessaire de combiner les deux méthodes de segmentation « verticale » et « horizontale » pour exploiter pleinement les avantages des deux et éviter leurs inconvénients.
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 c'est le coût le plus bas, ce qui est le plus conforme à celui-ci. le rapport entrées-sorties maximal recherché au cours de cette période. Cependant, à mesure que l'activité continue de se développer et que la charge du système continue d'augmenter, 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 ? Devons-nous subdiviser davantage le module ou rechercher d’autres solutions ? Si nous continuons à subdiviser les modules et à effectuer une segmentation verticale des données comme nous l'avons fait au début, nous pourrions rencontrer les mêmes problèmes auxquels nous sommes confrontés aujourd'hui dans un avenir proche. De plus, à mesure que les modules continuent d'être perfectionnés, l'architecture du système d'application deviendra de plus en plus complexe et l'ensemble du système risque de devenir incontrôlable.
En ce moment, vous devez profiter de la segmentation horizontale des données pour résoudre les problèmes rencontrés. De plus, il n'est pas nécessaire 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 pouvons utiliser les avantages de la segmentation horizontale pour éviter les inconvénients de la segmentation verticale et résoudre le problème de la complexité toujours croissante de la segmentation. question 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, facilitant ainsi le fractionnement horizontal.
Pour l'exemple de base de données, on suppose que les données étaient segmentées verticalement au début. Cependant, à mesure que l'entreprise continuait de croître, le système de base de données a rencontré des goulots d'étranglement et nous avons choisi de reconstruire l'architecture du cluster de base de données. Comment refactoriser ? Étant donné que la segmentation verticale des données a déjà été effectuée, que la structure des modules est claire et claire et que la dynamique de croissance de l'entreprise devient de plus en plus forte, même si les modules sont à nouveau divisés maintenant, cela ne durera pas longtemps. Nous avons donc choisi d’effectuer une segmentation horizontale sur la base d’une segmentation verticale.
Chaque base de données du cluster de bases de données qui a subi une segmentation verticale n'a qu'un seul module fonctionnel, et toutes les tables de chaque module fonctionnel sont essentiellement associées à un certain champ. Par exemple, tous les modules utilisateur peuvent être segmentés par ID utilisateur, les modules de discussion de groupe peuvent être segmentés par ID de groupe et les modules d'album photo peuvent être segmentés par ID d'album. Le tableau d'informations de notification d'événement final prend en compte la limite de temps des données. (Accédez uniquement aux informations d'un segment d'événement récent), elles sont divisées par temps.
La segmentation combinée montre l'architecture entière après la segmentation :
En fait, dans de nombreux grands systèmes d'application, la segmentation verticale et la segmentation horizontale sont fondamentalement coexistantes et sont souvent effectuées en alternance pour augmenter les capacités d'expansion 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, et utiliser différentes méthodes à différentes périodes (pression de charge).
Avantages du tranchage en joint :
Inconvénients du partitionnement conjoint :
À travers les chapitres précédents, il est clair que la segmentation des données via la base de données peut grandement améliorer les performances 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 après 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. Cela peut également être une grande préoccupation pour de nombreux lecteurs. Une question. Le contenu principal de cette section est d'analyser diverses solutions globales qui peuvent nous aider à réaliser la segmentation et l'intégration des données.
L'intégration des données est difficile à réaliser 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, il est 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 :
Configurer et gérer 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 les données. intégration au sein du module ;
Gérez toutes les sources de données de manière uniforme via la couche proxy intermédiaire, et le cluster de base de données back-end est transparent pour l'application front-end.
Peut-être que plus de 90 % des gens auront tendance à choisir la deuxième solution face à ces deux solutions, surtout lorsque le système continue de devenir plus grand et plus complexe. En effet, il s’agit d’un choix très correct, même si le coût à court terme peut être relativement important, il est très utile pour l’évolutivité de l’ensemble du système.
Par conséquent, je n’analyserai pas trop la première solution. Concentrons-nous sur l’analyse de certaines solutions dans la deuxième idée.
Développez votre propre couche proxy intermédiaire
Après avoir décidé de choisir l'orientation architecturale de l'intégration des sources de données via la couche proxy intermédiaire de la base de données, de nombreuses entreprises (ou entreprises) Nous avons développé nos propres applications de couche proxy qui correspondent à nos scénarios d'application spécifiques.
La couche proxy intermédiaire auto-développée peut répondre au maximum aux caractéristiques de sa propre application, maximiser la personnalisation des besoins personnalisés et peut également réagir de manière flexible face aux changements. Cela devrait être le plus grand avantage du développement de votre propre couche proxy.
Bien sûr, tout en choisissant de vous développer et de profiter au maximum du plaisir de la personnalisation personnalisée, vous devrez naturellement investir plus de coûts dans les premières recherches et développements et dans les mises à niveau et améliorations continues ultérieures, et votre propre seuil technique peut être plus élevé que les applications Web simples sont plus élevés. Par conséquent, avant de décider de vous développer vous-même, vous devez toujours procéder à une évaluation plus complète.
Étant donné que l'auto-développement réfléchit souvent à la manière de mieux s'adapter à son propre système d'application et de faire face à ses propres scénarios commerciaux, il n'est pas facile d'analyser trop de choses ici. Ce qui suit analysera principalement plusieurs solutions d'intégration de sources de données actuellement populaires.
Utilisez MySQL Proxy pour réaliser la segmentation et l'intégration des données
MySQL Proxy est un produit de couche proxy de base de données officiellement fourni par MySQL, comme MySQL Server, il est également basé sur GPL. Produits open source sous licences open source. Peut être utilisé pour surveiller, analyser ou transmettre des communications entre eux. Sa flexibilité lui permet d'être utilisé au maximum et ses fonctions actuelles incluent principalement le routage des connexions, l'analyse des requêtes, le filtrage et la modification des requêtes, l'équilibrage de charge et les mécanismes de base de haute disponibilité.
En fait, MySQL Proxy lui-même ne possède pas toutes les fonctions ci-dessus, mais fournit la base pour implémenter les fonctions ci-dessus. Pour réaliser ces fonctions, nous devons également écrire nous-mêmes des scripts LUA.
MySQL Proxy établit en fait un pool de connexions entre la requête du client et MySQL Server. Toutes les requêtes des clients sont envoyées au proxy MySQL, puis le proxy MySQL effectue l'analyse correspondante pour déterminer s'il s'agit d'opérations de lecture ou d'écriture, et les distribue au serveur MySQL correspondant. Pour les clusters esclaves multi-nœuds, il peut également réaliser un équilibrage de charge. Par exemple, le schéma d'architecture de base du proxy MySQL (Figure 4) :
Grâce au schéma architectural ci-dessus, vous pouvez voir clairement la position du proxy MySQL dans les applications pratiques et les choses de base qu'il peut faire. Les détails détaillés de l'implémentation de MySQL Proxy sont présentés de manière très détaillée et des exemples dans la documentation officielle de MySQL. Les lecteurs intéressés peuvent le télécharger directement depuis le site officiel de MySQL gratuitement ou le lire en ligne, je n'entrerai donc pas dans les détails ici.
Utilisez Amoeba pour réaliser la segmentation des données
Amoeba est un framework open source développé sur la base de Java et axé sur la résolution du problème de l'intégration de sources de données de bases de données distribuées. est open source basé sur le protocole 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, comme le montre la figure 5.
Amoeba résout principalement les problèmes suivants :
Intégration de sources de données complexes après segmentation des données
Fournir une segmentation des données séparée ; règles et réduire l'impact des règles de segmentation des données sur la base de données
Réduire le nombre de connexions entre la base de données et le client
Séparer ; routage de lecture et d'écriture.
On peut voir que ce que fait Amoeba est exactement ce qui est nécessaire 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 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 : Amoeba pour MySQL et Amoeba pour Aladin.
Amoeba For MySQL est 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 connectée par le back-end doivent être MySQL. Pour toute application client, il n'y a aucune différence entre Amoeba For MySQL et une base de données MySQL. Toute demande client utilisant le protocole MySQL peut être analysée par Amoeba For MySQL et traitée en conséquence. Amoeba For peut nous donner les informations architecturales d'Amoeba For MySQL (sur le blog des développeurs Amoeba) :
Amoeba For Aladin est un programme proxy plus largement applicable et 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, Amoeba For Aladin analysera automatiquement l'instruction Query et identifiera automatiquement quel hôte physique de quel type de base de données la source de données Query est basée sur les données demandées dans l'instruction Query supérieure. Le diagramme d'architecture Amoeba For Aladdin (Figure 6) montre les détails architecturaux d'Amoeba For Aladdin (du blog des développeurs Amoeba).
À première vue, les deux semblent être exactement les mêmes. Si vous regardez attentivement, vous constaterez que la principale différence entre les deux est qu'après le traitement par MySQL Protocol Adapter, la base de données source de données est déterminée en fonction des résultats de l'analyse, puis un pilote JDBC spécifique et le protocole correspondant sont sélectionnés pour se connecter. la base de données back-end.
En fait, vous avez peut-être découvert les caractéristiques d'Amoeba à travers les deux schémas d'architecture ci-dessus. Il s'agit simplement d'un framework de développement en plus de choisir les deux produits qu'il a fournis, pour MySQL et pour Aladin, nous pouvons. utilisez-le également sur la base de Réalisez un développement secondaire en fonction de vos propres besoins et obtenez un programme proxy plus adapté aux caractéristiques de votre application.
Mais pour utiliser la base de données MySQL, Amoeba For MySQL et Amoeba For Aladin peuvent être 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 plus élevé. Par conséquent, lorsque vous avez uniquement besoin d’utiliser la base de données MySQL, il est recommandé d’utiliser Amoeba For MySQL.
L'utilisation d'Amoeba For MySQL est très simple. Tous les fichiers de configuration sont des fichiers XML standards. Il y en a 4 au total, comme suit :
amoeba.xml—— Configuration principale. fichier, configure toutes les sources de données et les propres paramètres d'Amoeba
rule.xml - configure les informations de toutes les règles de routage des requêtes
functionMap. xml - configurez la classe d'implémentation Java utilisée pour analyser les fonctions dans Query ;
rullFunctionMap.xml - configurez l'implémentation de fonctions spécifiques qui doivent être utilisées dans le type de règles de routage.
Si vos règles ne sont pas trop complexes, en gros, il suffit d'utiliser les deux premiers des 4 profils ci-dessus pour tout faire. Les fonctions couramment utilisées des programmes proxy, telles que la séparation lecture-écriture, l'équilibrage de charge et d'autres configurations, sont toutes configurées dans amoeba.xml. De plus, Amoeba prend déjà en charge le routage automatique pour la segmentation verticale et horizontale des données. Les règles de routage peuvent être définies dans Rule.xml.
Utilisez HiveDB pour réaliser la segmentation et l'intégration des données
Comme les précédents MySQL Proxy et Amoeba, HiveDB est également un framework open source basé sur Java qui fournit la segmentation et l'intégration des données pour les bases de données MySQL. Cependant, le HiveDB actuel ne prend en charge que la segmentation horizontale des données. Il résout principalement les problèmes d'évolutivité des bases de données et d'accès aux données hautes performances sous de grands volumes de données, tout en prenant en charge la redondance des données et le mécanisme HA de base.
Le mécanisme d'implémentation de HiveDB est quelque peu différent de MySQL Proxy 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. La couche inférieure est principalement basée sur le travail de segmentation des données. sur les fragments Hibernate.
Dans HiveDB, les données sont dispersées sur plusieurs serveurs MySQL via diverses clés de partition définies par l'utilisateur (c'est-à-dire la formulation de règles de segmentation des données). Lorsque vous exécutez une requête de requête pendant l'accès, les conditions de filtre seront automatiquement analysées, les données seront lues à partir de plusieurs serveurs MySQL en parallèle et l'ensemble de résultats sera fusionné et renvoyé à l'application client.
D'un point de vue purement fonctionnel, HiveDB n'est peut-être pas aussi puissant que MySQL Proxy 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.
Le diagramme d'architecture HiveDB (Figure 7) sur le site officiel de HiveDB décrit les informations de base sur la façon dont HiveDB organise les données. Bien qu'il ne puisse pas montrer les informations architecturales en détail, il peut essentiellement montrer son rôle dans la découpe des données. a un aspect unique.
Autres solutions pour la segmentation et l'intégration des données
En plus des plusieurs solutions globales pour la segmentation et l'intégration des données présentées ci-dessus, il existe de nombreuses autres solutions, telles que HSCALE qui est encore étendu sur la base du proxy MySQL, du proxy Spock construit via Rails et des Pyshards basés sur Pathon, etc.
Quelle que soit la solution que vous choisissez d'utiliser, il ne devrait fondamentalement y avoir aucun changement dans l'idée globale de conception, c'est-à-dire que grâce à la segmentation verticale et horizontale des données, les capacités globales de service de la base de données sont améliorées, de sorte que le système d'application global La capacité d'expansion doit être améliorée autant que possible et la méthode d'expansion doit être aussi pratique que possible.
Tant que les problèmes de segmentation des données et d'intégration des sources de données sont bien résolus via l'application proxy de couche intermédiaire, la capacité d'expansion linéaire de la base de données sera aussi pratique que l'application : simplement en ajoutant un serveur PC bon marché serveur, c'est-à-dire qu'il peut augmenter linéairement la capacité globale de service du cluster de base de données, 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, tout le monde devrait 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 sont basés sur les avantages et les avantages. contre diverses solutions, vous avez essentiellement sélectionné une solution adaptée à votre scénario d'application. L'étape suivante consiste à préparer la mise en œuvre.
Avant de mettre en œuvre le plan de segmentation des données, certains problèmes possibles doivent encore être analysés. De manière générale, les principaux problèmes que vous pouvez rencontrer sont les suivants :
Une fois que les données sont divisées et stockées sur plusieurs serveurs MySQL, quelle que soit la conception des règles de division, peu importe même si c'est parfait (en fait, il n'y a pas de règle de segmentation parfaite), 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 un tel scénario, si l'application suit toujours l'ancienne solution, des transactions distribuées doivent être introduites pour la résoudre. Parmi les différentes versions de MySQL, seules les versions à partir de MySQL 5.0 prennent en charge les transactions distribuées, et actuellement, seul Innodb prend en charge les transactions distribuées. Cependant, même si nous utilisons une version de MySQL qui prend en charge les transactions distribuées et utilisons également le moteur de stockage Innodb, la transaction distribuée elle-même consomme beaucoup de ressources système et les performances ne sont pas très élevées en termes d'introduction de transactions distribuées en termes de gestion des exceptions. Cela entraînera de nombreux problèmes difficiles à contrôler.
Que faire ? En fait, ce problème peut être résolu 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 capable de résoudre les transactions ? En fait, ce n’est pas le cas. Ce problème peut être résolu en combinant la base de données et le programme d’application. Chaque base de données résout ses propres transactions et les applications contrôlent les transactions sur plusieurs bases de données.
En d'autres termes, tant que nous le souhaitons, nous pouvons diviser une transaction distribuée sur plusieurs bases de données en plusieurs petites transactions qui ne se trouvent que sur une seule base de données et contrôler chaque petite transaction via l'application. Bien entendu, cela nécessite que l’application soit suffisamment robuste, et bien sûr, cela entraînera également certaines difficultés techniques pour l’application.
Problèmes avec la jointure entre nœuds
Ce qui précède a introduit des problèmes pouvant introduire des transactions distribuées. Examinons maintenant les problèmes qui nécessitent une jointure entre nœuds. Une fois les données divisées, certaines anciennes instructions Join peuvent ne plus être utilisées car la source de données utilisée par Join peut être divisée en plusieurs serveurs MySQL.
Que 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 résolu 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 à ceux de DB Link d'Oracle. La principale différence par rapport à Oracle DB Link est que Federated enregistre 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 sur le fait que si la structure de la table distante change, les informations de définition de la table locale ne changeront pas en conséquence. Si 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, la requête risque de ne pas s'exécuter correctement et de ne pas obtenir de résultats corrects.
Pour résoudre ce type de problème, il est recommandé de le résoudre via le programme d'application, récupérez d'abord l'ensemble de résultats de pilotage sur le serveur MySQL où se trouve la table de pilotage, puis récupérez le résultat correspondant. défini à partir du serveur MySQL où se trouve la table pilotée en fonction de l'ensemble de résultats de pilotage. De nombreux lecteurs peuvent penser que cela aura un certain impact sur les performances. Oui, cela aura effectivement un certain impact négatif, mais à part cela, il n'y a fondamentalement pas beaucoup d'autres meilleures solutions. De plus, une fois la base de données bien étendue, la charge de chaque serveur MySQL peut être mieux contrôlée. Pour une seule requête, son temps de réponse peut être légèrement plus élevé qu'avant sa segmentation, de sorte que les performances sont réduites à néant. trop génial. De plus, la demande pour des jointures entre nœuds comme celle-ci n'est pas excessive, et elle ne représente peut-être qu'une petite partie par rapport aux performances globales. Par conséquent, pour le bien des performances globales, cela vaut la peine de sacrifier un peu de temps en temps. Après tout, l'optimisation du système elle-même est un processus impliquant de nombreux compromis et équilibres.
Problèmes de tri et de pagination de fusion entre nœuds
Une fois les données divisées horizontalement, ce n'est peut-être pas seulement la jointure entre nœuds qui ne peut pas fonctionner correctement, mais aussi certains problèmes de tri et de pagination. La source de données de l'instruction Query peut également être divisée en plusieurs nœuds, la conséquence directe est que ces requêtes de tri et de pagination ne peuvent pas continuer à s'exécuter normalement. En fait, cela équivaut à une jointure entre nœuds. La source de données existe sur plusieurs nœuds et doit être résolue via une requête, qui est une opération de jointure entre nœuds. De même, Federated peut aussi le résoudre en partie, mais les risques sont les mêmes. Mais il y a une différence : la jointure a souvent une relation pilotée par le pilote, de sorte que la lecture des données entre les multiples tables impliquées a généralement une relation séquentielle. Mais le tri et la pagination sont différents. La source de données du tri et de la pagination peut essentiellement être considérée comme une table (ou un ensemble de résultats), et il n'y a pas de relation séquentielle, de sorte que le processus de récupération des données à partir de plusieurs sources de données peut être complètement parallèle. . De cette façon, l'efficacité de la récupération des données de pagination triées peut être supérieure à celle de la jointure entre bases de données, de sorte que la perte de performances causée est relativement faible. Dans certains cas, elle peut être plus efficace que dans la base de données d'origine sans segmentation des données. Bien entendu, qu'il s'agisse d'une jointure entre nœuds ou d'un tri et d'une pagination entre nœuds, le serveur d'applications consommera plus de ressources, en particulier de ressources mémoire, car le processus de lecture, d'accès et de fusion de l'ensemble de résultats nécessite plus de données que sans traitement de fusion. .
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!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
