MySQL prend-il en charge la distribution ?

Les solutions distribuées dans MySQL sont en fait assez riches. Aujourd'hui, parlons brièvement de la compréhension des solutions distribuées.

Cours recommandés : Tutoriel MySQL

Tout d'abord, une base de données est un logiciel, et ses fonctions les plus basiques sont le stockage de données et requête de données. De manière générale, les méthodes de traitement des données sont divisées en lecture et en écriture, c'est pourquoi de nombreux scénarios de solutions distribuées reposent en réalité sur ces deux dimensions.

Avant de démarrer la solution distribuée, parlons de pourquoi il existe une solution distribuée. Si une seule machine peut résoudre quelque chose, il n’est en réalité pas nécessaire d’envisager un traitement distribué. S’ils sont divisés, ils ne peuvent pas être combinés naturellement. C’est aussi un équilibre qu’il faut maîtriser dans les solutions distribuées. La solution HTAP mentionnée actuellement dans l'industrie est en fait un scénario intégrant OLTP+OLAP. D'un point de vue autonome, Oracle est certainement la meilleure solution HTAP. Mais en plus du problème de prix dans Oracle, il y a un autre problème, celui de l'évolutivité. Ne parlons pas pour l'instant des détails du sharding. L'idée de conception chez Oracle est de tout partager, donc la solution de table de partition est encore plus appropriée. .

Mais MySQL n'est évidemment pas bon, car on n'entend presque jamais parler de solutions de table de partition utilisées dans l'industrie Internet, car peu importe leur division ou leur expansion, les données sont toutes sur une seule machine, et les performances de la machine unique n'est pas satisfaisante. Par conséquent, la capacité et les performances d’une seule machine constituent toutes deux des goulots d’étranglement, de sorte qu’il peut y avoir deux instances ou plus pour partager la pression.

Laissez-moi vous donner un exemple simple. Du point de vue du traitement des données, les données ont des exigences de lecture et d'écriture, nos besoins peuvent donc être étendus respectivement aux exigences de lecture et d'écriture.

L'expansion des exigences de lecture est relativement simple, ce que l'on appelle souvent la séparation de la lecture et de l'écriture. Ce type de middleware général peut le prendre en charge.

Comme indiqué dans le coin inférieur gauche de la solution ci-dessous, les exigences de lecture peuvent être facilement étendues. L'expansion de la lecture ici est linéaire, non exponentielle et transparente pour l'entreprise.

La difficulté réside dans l'écriture d'extensions. Le cœur de l'écriture d'extensions est la partie impliquant les transactions distribuées. Si vous ne pouvez pas la diviser, ne la divisez pas. Si vous voulez vraiment la diviser, alors nous pouvons. divisez-les en différentes dimensions, telles que les données de type pipeline, ce type de données a une très faible dépendance, donc l'exigence d'écriture est d'insertion et l'exigence d'écriture est relativement simple. Cette méthode peut être assistée par des solutions middleware pour réaliser des solutions de partitionnement. La plupart des solutions distribuées que nous comprenons habituellement parlent en réalité de cela. L'expansion de cette solution est exponentielle, par exemple, 2 nœuds deviennent 4, 4 deviennent 8, etc., ce qui est transparent pour le métier.

Mais il existe un type plus complexe, celui des données d'état. Nous ne pouvons pas les diviser directement, ni les diviser directement en fonction des dimensions de l'entreprise. , ce type de scission n'est pas recommandé pour utiliser directement le middleware. Par exemple, si une entreprise est scindée, elle peut être divisée en entreprise 1, entreprise 2 et entreprise 3. . . Business 8, il n'est pas recommandé de transformer la logique divisée de ces 8 entreprises en une méthode de hachage fluide, mais de la combiner en fonction de la priorité de la logique métier et d'autres dimensions. Par exemple, si l'entreprise 1 a une priorité élevée, alors il peut s'agir d'un nœud indépendant. Si le volume de données et la priorité de Business 3-Business 6 sont différents, ils peuvent constituer un seul nœud. Il est recommandé que les règles de routage d'écriture des données soient traitées via la couche application. Il s'agit d'une solution plus contrôlable. Cette solution d'extension n'est pas transparente pour la candidature et nécessite la coopération et le traitement de la candidature. Mais le revenu est évidemment le meilleur état d'équilibre. Par exemple, le concept de serveurs de jeux, très courant dans l'industrie du jeu, est divisé de cette manière, de sorte que l'expansion peut être linéaire.

Si nous parlons d'une solution distribuée basée sur cela, elle traite en fait un cluster ou une entreprise comme un nœud transparent et utilise d'autres solutions auxiliaires pour répondre aux besoins d'expansion. Il s'agit principalement d'une solution distribuée relationnelle. sur le routage statique, qui nécessite encore beaucoup de travail supplémentaire pour l'expansion de la capacité et ne peut pas atteindre une élasticité douce. C’est là que NoSQL et NewSQL entrent naturellement en jeu.

Ainsi, lorsque vous choisissez une solution, vous devez avoir une vue d'ensemble et une vision plus élevée. Il n'est pas nécessaire que ce soit MySQL ou Oracle. Il est naturellement bon d'approfondir celle-ci. Vous pouvez également en envisager d'autres meilleures. solutions.

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!