Die verteilten Lösungen in MySQL sind tatsächlich recht umfangreich. Lassen Sie uns heute kurz über das Verständnis verteilter Lösungen sprechen.
Empfohlene Kurse: MySQL-Tutorial
Zuallererst ist eine Datenbank eine Software, und ihre grundlegendsten Funktionen sind die Datenspeicherung und Datenabfrage. Im Allgemeinen werden Datenverarbeitungsmethoden in Lesen und Schreiben unterteilt, sodass viele Szenarien verteilter Lösungen tatsächlich auf diesen beiden Dimensionen basieren.
Bevor wir mit der verteilten Lösung beginnen, sprechen wir darüber, warum es eine verteilte Lösung gibt. Wenn eine einzelne Maschine etwas lösen kann, besteht eigentlich überhaupt keine Notwendigkeit, über eine verteilte Verarbeitung nachzudenken. Wenn sie geteilt sind, können sie nicht auf natürliche Weise kombiniert werden. Auch dies ist ein Gleichgewicht, das bei verteilten Lösungen gemeistert werden muss. Die in der Branche derzeit erwähnte HTAP-Lösung ist tatsächlich ein Szenario, das OLTP+OLAP integriert. Aus eigenständiger Sicht ist Oracle definitiv die beste HTAP-Lösung. Aber neben dem Preisproblem in Oracle gibt es noch ein weiteres Problem, nämlich die Skalierbarkeit. Lassen Sie uns vorerst nicht über die Details des Shardings sprechen. Die Designidee in Oracle besteht darin, alles zu teilen, daher ist die Partitionstabellenlösung noch angemessener .
Aber MySQL ist offensichtlich nicht gut, weil man fast nie von Partitionstabellenlösungen hört, die in der Internetbranche verwendet werden, denn egal wie aufgeteilt oder erweitert, die Daten befinden sich alle auf einer einzigen Maschine und die Leistung von Die Einzelmaschine ist nicht zufriedenstellend. Daher stellen sowohl die Kapazität einer einzelnen Maschine als auch die Leistung einer einzelnen Maschine einen Engpass dar, sodass es zwei oder mehr Instanzen geben kann, die den Druck teilen.
Lassen Sie mich Ihnen ein einfaches Beispiel geben. Aus Sicht der Datenverarbeitung stellen Daten Lese- und Schreibanforderungen, sodass unsere Anforderungen auf Leseanforderungen bzw. Schreibanforderungen erweitert werden können.
Die Erweiterung der Leseanforderungen ist relativ einfach und wird oft als Trennung von Lesen und Schreiben bezeichnet. Diese Art allgemeiner Middleware kann dies unterstützen.
Wie in der unteren linken Ecke der Lösung unten gezeigt, können die Leseanforderungen einfach erweitert werden. Die Leseerweiterung erfolgt hier linear, nicht exponentiell und ist für das Unternehmen transparent.
Die Schwierigkeit besteht darin, Erweiterungen zu schreiben. Wenn Sie es nicht aufteilen können, können Sie es nicht aufteilen Teilen Sie es in verschiedene Dimensionen auf, z. B. Daten vom Pipeline-Typ. Dieser Datentyp weist eine sehr geringe Abhängigkeit auf, sodass die Schreibanforderung eingefügt werden muss und die Schreibanforderung relativ einfach ist. Diese Methode kann durch Middleware-Lösungen unterstützt werden, um Sharding-Sharding-Lösungen zu erreichen. Viele der verteilten Lösungen, die wir normalerweise verstehen, sprechen tatsächlich darüber. Die Erweiterung dieser Lösung erfolgt exponentiell, zum Beispiel werden aus 2 Knoten 4, aus 4 werden 8 usw., was für das Unternehmen transparent ist.
Aber es gibt einen komplexeren Typ, nämlich Statusdaten. Wir können sie nicht direkt aufteilen oder entsprechend der Dimension des Unternehmens aufteilen . Diese Art der Aufteilung wird nicht empfohlen, um Middleware direkt zu verwenden. Wenn beispielsweise ein Unternehmen aufgeteilt wird, kann es in Unternehmen 1, Unternehmen 2 und Unternehmen 3 aufgeteilt werden. . . Geschäft 8, dann wird nicht empfohlen, die Split-Logik dieser 8 Unternehmen in eine glatte Hash-Methode umzuwandeln, sondern entsprechend der Priorität der Geschäftslogik und anderen Dimensionen zu kombinieren. Wenn beispielsweise Geschäft 1 eine hohe Priorität hat, Dann kann es ein unabhängiger Knoten sein. Wenn das Datenvolumen und die Priorität von Business 3-Business 6 unterschiedlich sind, können sie ein Knoten sein. Es wird empfohlen, die Routingregeln für das Schreiben von Daten über die Anwendungsschicht zu verarbeiten. Dies ist eine besser kontrollierbare Lösung. Diese Erweiterungslösung ist für den Antrag nicht transparent und erfordert die Mitarbeit und Bearbeitung des Antrags. Aber das Einkommen ist offensichtlich der beste Gleichgewichtszustand. Beispielsweise ist das in der Spielebranche sehr verbreitete Konzept der Spieleserver auf diese Weise unterteilt, sodass die Erweiterung linear erfolgen kann.
Wenn wir auf dieser Grundlage von einer verteilten Lösung sprechen, behandelt sie einen Cluster oder ein Unternehmen tatsächlich als transparenten Knoten und verwendet andere Hilfslösungen, um den Erweiterungsbedarf zu erfüllen. Es handelt sich größtenteils um eine relationale verteilte Lösung beim statischen Routing, das noch viel zusätzlichen Aufwand für die Kapazitätserweiterung erfordert und keine reibungslose Elastizität erreichen kann. Hier kommen natürlich NoSQL und NewSQL ins Spiel.
Bei der Auswahl einer Lösung muss man also einen Gesamtüberblick und eine höhere Vision haben. Es ist natürlich gut, sich tiefer damit zu befassen Lösungen.
Das obige ist der detaillierte Inhalt vonUnterstützt MySQL die Verteilung?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
