Zusammenfassung der häufig verwendeten Datenbank- und Tabellen-Sharding-Lösungen von MySQL

1. Datenbank-Engpass

Unabhängig davon, ob es sich um einen E/A-Engpass oder einen CPU-Engpass handelt, führt dies letztendlich zu einem Anstieg der Anzahl der aktiven Verbindungen der Datenbank und nähert sich dann dem Schwellenwert der Anzahl aktiver Verbindungen, die die Datenbank unterstützen kann, oder erreicht diesen sogar. Aus Sicht der Business Services stehen nur wenige oder gar keine Datenbankverbindungen zur Verfügung. Sie können sich vorstellen, was als Nächstes passieren wird (Parallelität, Durchsatz und Abstürze).

1. IO-Engpass

Der erste Typ: Engpass bei der Festplatten-Lese-E/A. Es gibt zu viele Hot Data und der Datenbank-Cache kann sie nicht speichern. Jede Abfrage generiert eine große Menge an E/A, was die Abfragegeschwindigkeit verringert -> Sharding und vertikales Sharding.

Der zweite Typ: Netzwerk-E/A-Engpass, es werden zu viele Daten angefordert und die Netzwerkbandbreite reicht nicht aus -> Sharding.

2. CPU-Engpass

Der erste Typ: SQL-Probleme, wie etwa SQL mit Join, Group By, Order By, bedingten Abfragen nicht indizierter Felder usw., die die CPU-Rechenvorgänge erhöhen -> SQL-Optimierung, Erstellen geeigneter Indizes und Ausführen von Geschäftsberechnungen auf der Geschäftsdienstebene.

Der zweite Typ: Die Datenmenge in einer einzelnen Tabelle ist zu groß, während der Abfrage werden zu viele Zeilen gescannt, die SQL-Effizienz ist gering und die CPU ist der erste Engpass -> Horizontale Tabellenpartitionierung.

2. Unterbibliothek und Untertisch

1. Horizontale Datenbank

Konzept: Teilen Sie die Daten in einer Datenbank basierend auf Feldern und bestimmten Strategien (Hash, Bereich usw.) in mehrere Datenbanken auf.

Ergebnis:

• Die Struktur jeder Bibliothek ist gleich;
• Die Daten in jeder Datenbank sind unterschiedlich und es gibt keine Überschneidungen.
• Die Gesamtheit aller Bibliotheken ergibt die vollständigen Daten.

Szenario: Die absolute Parallelität des Systems hat zugenommen, und das Problem der Tabellenteilung kann grundsätzlich nur schwer gelöst werden. Darüber hinaus besteht keine klare Geschäftszugehörigkeit zur vertikalen Teilung der Datenbank.

Analyse: Mit mehr Bibliotheken kann der Druck auf IO und CPU exponentiell verringert werden.

2. Horizontaler Tisch

Konzept: Teilen Sie die Daten einer Tabelle basierend auf Feldern und gemäß bestimmter Strategien (Hash, Bereich usw.) in mehrere Tabellen auf.

Ergebnis:

• Die Struktur jeder Tabelle ist gleich;
• Die Daten in jeder Tabelle sind unterschiedlich und es gibt keine Überschneidungen.
• Die Vereinigung aller Tabellen ergibt die vollständigen Daten.

Szenario: Die absolute Parallelität des Systems hat nicht zugenommen, aber die Datenmenge in einer einzelnen Tabelle ist zu groß, was die SQL-Effizienz beeinträchtigt und die CPU-Belastung erhöht, was zu einem Engpass führt. Empfohlen: Eine Analyse der Prinzipien der SQL-Abfrageoptimierung

Analyse: Die Datenmenge in der Tabelle wird reduziert und die Effizienz der einzelnen SQL-Ausführung ist hoch, was natürlich die Belastung der CPU verringert.

3. Vertikale Unterdatenbank

Konzept: Basierend auf der Tabelle werden verschiedene Tabellen entsprechend unterschiedlicher Geschäftsattribute in unterschiedliche Datenbanken aufgeteilt.

Ergebnis:

• Jede Bibliothek ist anders strukturiert;
• Auch sind die Daten in jeder Datenbank unterschiedlich und es gibt keine Überschneidungen.
• Die Gesamtheit aller Bibliotheken ergibt die vollständigen Daten.

Szenario: Die absolute Parallelität des Systems hat zugenommen und separate Geschäftsmodule können abstrahiert werden.

Analyse: An diesem Punkt kann es grundsätzlich in einen Dienst umgewandelt werden.

Beispielsweise gibt es mit der Entwicklung des Geschäfts immer mehr öffentliche Konfigurationstabellen und Wörterbuchtabellen. Zu diesem Zeitpunkt können diese Tabellen in separate Bibliotheken aufgeteilt oder sogar in Dienste umgewandelt werden. Darüber hinaus können im Zuge der Geschäftsentwicklung und der Entwicklung neuer Geschäftsmodelle die zugehörigen Tabellen in separate Datenbanken aufgeteilt oder sogar in Dienste umgewandelt werden.

4. Vertikaler Tisch

Konzept: Basierend auf den Feldern und entsprechend der Aktivität der Felder werden die Felder in der Tabelle in verschiedene Tabellen (Haupttabelle und erweiterte Tabelle) aufgeteilt.

Ergebnis:

• Jede Tabelle ist anders strukturiert;
• Auch die Daten in jeder Tabelle sind unterschiedlich. Im Allgemeinen haben die Felder jeder Tabelle mindestens eine Spalte, die sich überschneidet. Dabei handelt es sich normalerweise um den Primärschlüssel, der zur Verknüpfung der Daten verwendet wird.
• Die Vereinigung aller Tabellen ergibt die vollständigen Daten.

Szenario: Die absolute Parallelität des Systems hat nicht zugenommen. Die Tabelle enthält nicht viele Datensätze, aber viele Felder. Hot-Data und Nicht-Hot-Data werden zusammen gespeichert, sodass der für eine einzelne Datenzeile erforderliche Speicherplatz groß ist. Dies führt dazu, dass die Anzahl der Datenzeilen im Datenbankcache reduziert wird und beim Lesen von Festplattendaten während Abfragen eine große Menge zufälliger Lese-E/A-Vorgänge generiert wird, was zu einem E/A-Engpass führt.

Analyse: Zum besseren Verständnis können Sie Listenseiten und Detailseiten verwenden. Das Prinzip der vertikalen Tabellenaufteilung besteht darin, Hot Data (Daten, die redundant sein können und oft zusammen abgefragt werden) als Haupttabelle zusammenzufassen und Nicht-Hot Data als erweiterte Tabelle zusammenzufassen. Auf diese Weise können mehr Hot Data zwischengespeichert und dadurch der zufällige Lese-E/A-Aufwand reduziert werden. Wenn Sie nach der Aufteilung alle Daten erhalten möchten, müssen Sie die beiden Tabellen verbinden, um die Daten zu erhalten.

Denken Sie aber daran, niemals einen Join zu verwenden, da dieser nicht nur die CPU-Belastung erhöht, sondern auch die beiden Tabellen miteinander verknüpft (müssen sich auf einer Datenbankinstanz befinden). Für verknüpfte Daten sollten Sie auf der Business-Service-Ebene arbeiten, die Daten der Haupttabelle und der erweiterten Tabelle separat abrufen und dann die verknüpften Felder zum Zuordnen verwenden, um alle Daten abzurufen.

3. Tools zum Sharding von Bibliotheken und Tabellen

• sharding-sphere: jar, früher sharding-jdbc;
• TDDL: jar, verteilte Datenschicht von Taobao;
• Mycat: Middleware.

Hinweis: Bitte informieren Sie sich selbst über die Vor- und Nachteile des Tools, wobei die offizielle Website und die Community Vorrang haben.

4. Schritte zum Aufteilen von Datenbanken und Tabellen

Bewerten Sie die Anzahl der Shards oder Tabellen basierend auf der Kapazität (aktuelle Kapazität und Wachstum) -> Schlüssel auswählen (gleichmäßig) -> Regeln für die Tabellen-Sharding-Regelung (Hash oder Bereich usw.) -> Ausführen (im Allgemeinen doppeltes Schreiben) -> Probleme bei der Kapazitätserweiterung (Datenbewegung minimieren).

5. Probleme mit Sharding

1. Abfrageproblem bei Nicht-Partitionsschlüsseln

Die Aufteilungsstrategie basiert auf horizontaler Datenbank- und Tabellenteilung und ist die häufig verwendete Hash-Methode.

Neben dem Partitionsschlüssel gibt es auf dem Client nur einen Nicht-Partitionsschlüssel als Bedingung für die Abfrage

Zuordnungsmethode

Genetische Methode

Hinweis: Beim Schreiben wird die Benutzer-ID mit der genetischen Methode generiert, wie in der Abbildung dargestellt. Wenn man beispielsweise das x-Bit-Gen in 8 Tabellen unterteilt, ergibt sich 23 = 8, also ist x 3, was ein 3-Bit-Gen ist. Bei Abfragen basierend auf der Benutzer-ID kann das Modul direkt an die entsprechende Unterbibliothek oder Untertabelle weitergeleitet werden.

Wenn Sie eine Abfrage basierend auf dem Benutzernamen durchführen, generieren Sie zuerst den Benutzernamencode über die Funktion zur Generierung des Benutzernamencodes, nehmen Sie dann den Modul und leiten Sie ihn an die entsprechende Unterbibliothek oder Untertabelle weiter. Der häufig verwendete Snowflake-Algorithmus zur ID-Generierung.

Neben dem Partitionsschlüssel gibt es mehrere Nicht-Partitionsschlüssel als Voraussetzung für die Abfrage auf dem Client

Zuordnungsmethode

Redundanzmethode

Hinweis: Bei einer Abfrage nach „order_id“ oder „buyer_id“ wird die Abfrage an die Datenbank „db_o_buyer“ weitergeleitet. Bei einer Abfrage nach „seller_id“ wird die Abfrage an die Datenbank „db_o_seller“ weitergeleitet. Es fühlt sich ein bisschen so an, als würde man den Karren vor das Pferd spannen! Gibt es eine andere gute Möglichkeit? Wie wäre es mit einer Änderung des Technologie-Stacks?

Neben dem Partitionsschlüssel gibt es im Hintergrund auch verschiedene Abfragen für Kombinationsbedingungen für Nicht-Partitionsschlüssel

NoSQL-Ansatz

Redundanzmethode

2. Problem bei datenbank- und tabellenübergreifenden Paging-Abfragen ohne Partitionsschlüssel

Die Aufteilungsstrategie basiert auf horizontaler Datenbank- und Tabellenteilung und ist die häufig verwendete Hash-Methode.

Hinweis: Gelöst mithilfe von NoSQL-Methoden (ES usw.).

3. Probleme bei der Kapazitätserweiterung

Die Aufteilungsstrategie basiert auf horizontaler Datenbank- und Tabellenteilung und ist die häufig verwendete Hash-Methode.

Horizontale Erweiterung der Datenbank (Upgrade von der Datenbankmethode)

Hinweis: Die Erweiterung ist exponentiell.

Horizontale Erweiterungstabelle (Double-Write-Migrationsmethode)

Schritt 1: (Synchronisiertes Dualschreiben) Ändern Sie die Anwendungskonfiguration und den Code, fügen Sie Dualschreiben hinzu und stellen Sie es bereit.

Schritt 2: (Synchronous Dual Write) Kopieren Sie die alten Daten der alten Datenbank in die neue Datenbank.

Schritt 3: (Synchronisiertes duales Schreiben) Überprüfen Sie die alten Daten in der neuen Datenbank basierend auf der alten Datenbank.

Schritt 4: (Synchronisiertes Doppelschreiben) Ändern Sie die Anwendungskonfiguration und den Code, entfernen Sie das Doppelschreiben und stellen Sie es bereit.

Hinweis: Doppeltes Schreiben ist eine gängige Lösung.

6. Zusammenfassung der Unterbibliothek und des Untertisches

Um die Datenbank und die Tabellen aufzuteilen, müssen Sie zunächst wissen, wo der Engpass liegt, und dann können Sie eine sinnvolle Aufteilung vornehmen (Datenbank aufteilen oder Tabelle aufteilen? Horizontal oder vertikal? Wie oft?). Und es kann nicht zum Zweck der Trennung von Datenbank und Tabelle aufgeteilt werden.

Die Wahl des Schlüssels ist sehr wichtig. Dabei müssen sowohl gleichmäßige Aufteilungen als auch nicht partitionierte Schlüsselabfragen berücksichtigt werden.

Sofern die Voraussetzungen erfüllt sind, sollten die Aufteilungsregeln möglichst einfach sein.

Damit ist dieser Artikel mit der Zusammenfassung häufig verwendeter MySQL-Sharding-Lösungen abgeschlossen. Weitere Informationen zu MySQL-Sharding finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!