Erste Schritte mit MySQL Sharding

Vorwort

Relationale Datenbanken werden eher zu Systemengpässen. Die Speicherkapazität, die Anzahl der Verbindungen und die Verarbeitungsleistung einer einzelnen Maschine sind begrenzt. Wenn die Datenmenge und die Parallelität zunehmen, muss die Datenbank segmentiert werden.

Beim Daten-Sharding werden die Datenbank und die Tabelle in verschiedene Teile aufgeteilt. Beim Sharding von Bibliotheken und Tabellen gibt es zwei Aspekte. Es kann sich um Sharding von ausschließlich Bibliotheken ohne Sharding von Tabellen oder um Sharding von ausschließlich Tabellen ohne Sharding von Bibliotheken handeln.

Der Kerninhalt der Datenbankverteilung ist nichts anderes als die Datensegmentierung sowie die Positionierung und Integration der Daten nach der Segmentierung.

Warum müssen wir die Datenbank in verschiedene Tabellen aufteilen?

Untertabelle

Wenn die Datenmenge in einer einzelnen Tabelle zu groß ist, wird die Leistung der SQL-Ausführung erheblich beeinträchtigt. Wenn eine einzelne Tabelle mehrere Millionen erreicht, ist die Leistung im Allgemeinen relativ schlecht und dann ist es notwendig, die Tabelle in Untertabellen aufzuteilen.

Beim Aufteilen von Tabellen werden die Daten einer Tabelle in mehrere Tabellen aufgeteilt und anschließend nur eine Tabelle abgefragt. Teilen Sie die Tabelle beispielsweise nach der Projekt-ID auf: Platzieren Sie eine feste Anzahl von Projektdaten in einer Tabelle, sodass die Datenmenge in jeder Tabelle innerhalb eines kontrollierbaren Bereichs gesteuert werden kann.

Teilbibliothek

Erfahrungsgemäß muss eine Datenbank erweitert werden, wenn sie maximal 2000 gleichzeitige Anfragen unterstützt, und der Gleichzeitigkeitswert einer gesunden Einzeldatenbank sollte am besten bei etwa 1000 gehalten werden. Anschließend können Sie die Daten einer Bibliothek auf mehrere Bibliotheken aufteilen und müssen beim Zugriff nur auf eine Bibliothek zugreifen.

Dies nennt man Sharding der Datenbank und der Tabellen. Warum müssen wir die Datenbank und die Tabellen sharden?

• Verbessern Sie die Möglichkeiten zur gleichzeitigen Unterstützung
• Reduzieren Sie die Festplattennutzung
• Verbessern der SQL-Ausführungsleistung

So teilen Sie die Datenbank und die Tabelle auf

Schauen Sie sich direkt das Bild an:

Bei vertikaler Aufteilung wird empfohlen, die Tabelle bereits zu Beginn der Systemgestaltung sorgfältig zu entwerfen, um eine vertikale Aufteilung der Tabelle zu vermeiden.

Die horizontale Aufteilung kann nach Bereich oder nach einem bestimmten Feld-Hash erfolgen. Der Vorteil der Division nach Bereich besteht darin, dass die Kapazitätserweiterung einfach ist und Sie nur eine neue Tabelle oder Datenbank vorbereiten müssen. Allerdings können dadurch leicht Probleme entstehen, daher sollte es bei der tatsächlichen Verwendung in Kombination mit Geschäftsszenarien betrachtet werden. Der Vorteil der Division durch Hash besteht darin, dass der Anforderungsdruck jeder Datenbank oder Tabelle gleichmäßig verteilt werden kann. Der Nachteil besteht darin, dass die Kapazitätserweiterung schwierig ist und die vorherigen Daten erneut gehasht werden müssen, was einen Datenmigrationsprozess beinhaltet.

Probleme durch Sharding

Unterdatenbanken und Untertabellen können den Druck auf Netzwerk-E/A, Hardwareressourcen und die Anzahl der Verbindungen, die von einer einzelnen Maschine und einer einzelnen Datenbank bereitgestellt werden, effektiv verringern. Aber es brachte auch einige Probleme mit sich.

• Probleme mit der Transaktionskonsistenz werden durch verteilte Transaktionen oder die Gewährleistung einer eventuellen Konsistenz gelöst.
• Knotenübergreifende Assoziationsabfrage, Verbindungsproblem bei globalen Tabellen, Feldredundanz, Datenassemblierung, ER-Fragmentierung
• Probleme mit knotenübergreifender Paging-, Sortier- und Aggregationsfunktion. Führen Sie zunächst eine Abfrage auf verschiedenen Shard-Knoten durch und fassen Sie die Ergebnisse anschließend zusammen oder führen Sie sie zusammen.
• Problem der globalen Vermeidung doppelter Primärschlüssel Verschiedene Algorithmen zur verteilten ID-Generierung
• Wenn das Problem der Datenmigration und -erweiterung eine Bereichsteilung ist, müssen Sie nur Knoten hinzufügen, um die Kapazität zu erweitern.
  Wenn es sich um Hash handelt, besteht die allgemeine Vorgehensweise darin, zuerst die historischen Daten auszulesen und die Daten dann gemäß den angegebenen Sharding-Regeln in jeden Shard-Knoten zu schreiben.

Datenmigration

Es werden zwei Datenmigrationslösungen vorgestellt.

Die einfachste Lösung besteht darin, das System für eine Weile herunterzufahren, ein vorgefertigtes Datenimporttool zu verwenden, um die Daten aus einer einzelnen Tabelle zu extrahieren und sie in die Unterbibliothek und Untertabelle zu schreiben.

Die zweite Lösung klingt zuverlässiger, die Dual-Write-Migrationslösung. Im Online-System werden alle Stellen, an denen zuvor Daten geschrieben wurden, die Hinzufügungs-, Lösch- und Änderungsvorgänge zusätzlich zum Hinzufügen, Löschen und Ändern der alten Datenbank zum Hinzufügen, Löschen und Ändern der neuen Datenbank hinzugefügt. Dies ist das sogenannte Doppelschreiben. Führen Sie nach der Bereitstellung des Systems das Datenimporttool in Lösung 1 aus, um die alte Datenbank zu lesen und die neue Datenbank zu schreiben. Beim Schreiben sollte der letzte Änderungszeitpunkt der Daten anhand von Feldern wie gmt_modified ermittelt werden. Die Daten werden nur geschrieben, wenn die neue Datenbank die Daten nicht enthält oder die Daten neuer sind als die Daten der neuen Datenbank. Einfach ausgedrückt ist es nicht zulässig, neue Daten mit alten Daten zu überschreiben.

Nach einer Schreibrunde können immer noch Inkonsistenzen vorhanden sein. In diesem Fall führt das Programm automatisch eine neue Überprüfungsrunde durch und vergleicht jedes Datenelement in jeder Tabelle der neuen und alten Datenbank. Wenn es Unterschiede gibt, liest das Programm die Daten aus der alten Datenbank und schreibt sie erneut. Wiederholen Sie den Zyklus, bis die Daten vollständig konsistent sind.

Middleware

Die gebräuchlichere Middleware für Unterbibliotheken und Untertabellen ist:

• Cobar: Es wurde vom B2B-Team von Alibaba entwickelt und als Open Source bereitgestellt. Es handelt sich um eine Proxy-Layer-Lösung, die sich zwischen dem Anwendungsserver und dem Datenbankserver befindet. Die Anwendung greift über den JDBC-Treiber auf den Cobar-Cluster zu. Cobar zerlegt das SQL gemäß den SQL- und Datenbankpartitionierungsregeln und verteilt es dann zur Ausführung an verschiedene Datenbankinstanzen im MySQL-Cluster. Vorgänge wie Lese-/Schreibtrennung, gespeicherte Prozeduren, datenbankübergreifende Verknüpfungen und Paging werden nicht unterstützt. Es wurde in den letzten Jahren nicht aktualisiert und wird nicht von vielen Leuten verwendet.
• TDDL: Es handelt sich um eine vom Taobao-Team entwickelte Client-Layer-Lösung. Es unterstützt die grundlegende CRUD-Syntax und die Trennung von Lesen und Schreiben, jedoch keine Syntax wie Join- und Multi-Table-Abfragen. Es wird derzeit nicht viel verwendet, da es immer noch auf dem Diamant-Konfigurationsverwaltungssystem von Taobao basiert.
• Atlas: 360 Open Source, gehört zur Proxy-Layer-Lösung. Es wurde seit mehreren Jahren nicht mehr gepflegt und wird heute nur noch von sehr wenigen Unternehmen genutzt.
• Sharding-jdbc: Die Open-Source-Client-Layer-Lösung von Dangdang wurde jetzt in ShardingSphere umbenannt. Es unterstützt eine breite Palette von SQL-Syntaxen ohne zu viele Einschränkungen, einschließlich Sharding von Datenbanken und Tabellen, Trennung von Lesen und Schreiben, verteilte ID-Generierung und flexible Transaktionen (Best Effort Delivery-Transaktionen, TCC-Transaktionen). Darüber hinaus nutzen es viele Unternehmen und die Community ist aktiv.
• Mycat: Basiert auf Cobar und gehört zur Proxy-Layer-Lösung. Die unterstützten Funktionen sind sehr umfangreich. Im Vergleich zu Sharding-jdbc ist es jünger.

Zusammenfassend sind Sharding-jdbc und Mycat die Optionen, die in Betracht gezogen werden können.

Die Vorteile von Client-Layer-Lösungen wie Sharding-jdbc bestehen darin, dass keine Bereitstellung erforderlich ist, geringe Betriebs- und Wartungskosten anfallen, keine sekundäre Weiterleitung auf der Proxy-Ebene erforderlich ist und eine hohe Leistung gewährleistet ist. Der Nachteil ist die Kopplung.
Der Nachteil der Proxy-Layer-Lösung von Mycat besteht darin, dass Sie einen Satz Middleware selbst bereitstellen und warten müssen, was hohe Betriebs- und Wartungskosten verursacht. Der Vorteil besteht jedoch darin, dass sie für das Projekt transparent ist.

MySQL-Partitionierung (veraltet)

Die Partitionierung wird hier hauptsächlich eingeführt, um Verwechslungen mit Konzepten wie Aufteilen, Datenbank- und Tabellen-Sharding usw. zu vermeiden.
MySQL unterstützt die Partitionsfunktion seit Version 5.1. Partitionierung bedeutet, dass die Datenbank eine Tabelle nach bestimmten Regeln in mehrere kleinere und besser handhabbare Teile zerlegt. Für Anwendungen, die auf die Datenbank zugreifen, gibt es logischerweise nur eine Tabelle oder einen Index, tatsächlich kann diese Tabelle jedoch aus mehreren physischen Partitionen bestehen, was für die Anwendung transparent ist.
Die MySQL-Partitionierung führt das Konzept des Partitionsschlüssels ein und verfolgt einen Teile-und-herrsche-Ansatz, der sich für die Verwaltung sehr großer Tabellen eignet. Der Partitionsschlüssel wird verwendet, um Daten basierend auf einem bestimmten Intervallwert, einer bestimmten Werteliste oder einer HASH-Funktion zu aggregieren, sodass die Daten gemäß Regeln auf verschiedene Partitionen verteilt werden. In MySQL 5.7 sind sechs Hauptpartitionstypen verfügbar:

• RANGE-Partitionierung: Ordnen Sie Daten basierend auf einem gegebenen kontinuierlichen Intervallbereich verschiedenen Partitionen zu.
• LIST-Partitionierung: Ähnlich wie die RANGE-Partitionierung, der Unterschied besteht darin, dass die LIST-Partitionierung auf der Listenpartitionierung mit aufgezählten Werten basiert, während RANGE auf einer gegebenen kontinuierlichen Intervallbereichspartitionierung basiert.
• COLUMNS-Partitionierung: Ähnlich wie RANGE und LIST, der Unterschied besteht darin, dass der Partitionsschlüssel mehrere Spalten umfassen oder nicht ganzzahlig sein kann.
• HASH-Partitionierung: Basierend auf der angegebenen Anzahl von Partitionen werden die Daten modulo verschiedener Partitionen verteilt.
• KEY-Partitionierung: Ähnlich wie HASH-Partitionierung, verwendet jedoch die von MySQL bereitgestellte Hash-Funktion.
• Unterpartitionierung: wird auch zusammengesetzte Partition oder kombinierte Partition genannt. Das bedeutet, dass unter der primären Partition eine weitere Partition erstellt wird, um die Daten erneut aufzuteilen.

Hier ist ein Beispiel für eine LIST-Partition:

Tabelle erstellen orders_list (
  id INT AUTO_INCREMENT,
  Kunde_Nachname VARCHAR(30),
  Store-ID INT,
  Verkäufer-ID INT,
  Bestelldatum DATUM,
  Beachten Sie VARCHAR(500),
  INDEX idx (ich würde)
) ENGINE = INNODB
  PARTITION BY LIST(store_id) (
  PARTITION p1
  WERTE IN (1, 3, 4, 17)
  INDEX-VERZEICHNIS = "/var/orders/district1"
  DATENVERZEICHNIS = '/var/orders/district1',
  TEILUNG p2
  WERTE IN (2, 12, 14)
  INDEX-VERZEICHNIS = "/var/orders/district2"
  DATENVERZEICHNIS = '/var/orders/district2',
  PARTITION p3
  WERTE IN (6, 8, 20)
  INDEX-VERZEICHNIS = "/var/orders/district3"
  DATENVERZEICHNIS = '/var/orders/district3',
  TEILUNG p4
  WERTE IN (5, 7, 9, 11, 16)
  INDEX-VERZEICHNIS = "/var/orders/district4"
  DATENVERZEICHNIS = '/var/orders/district4',
  TEILUNG p5
  WERTE IN (10, 13, 15, 18)
  INDEX-VERZEICHNIS = "/var/orders/district5"
  DATENVERZEICHNIS = '/var/orders/district5'
);

Vorteile der Partitionierung:

• Erweitern Sie die Speicherkapazität.
• Abfragen optimieren. Wenn die WHERE-Klausel Partitionsbedingungen enthält, können nur die erforderlichen Partitionen gescannt werden, um die Abfrageeffizienz zu verbessern. Wenn Abfragen mit Aggregatfunktionen wie SUM() und COUNT() ausgeführt werden, können sie auf jeder Partition parallel verarbeitet werden.
• Bei Datenpartitionen, deren Gültigkeit abgelaufen ist oder die nicht mehr gespeichert werden müssen, können Sie die Daten schnell löschen, indem Sie die Partition löschen.
• Verteilen Sie Abfragedaten auf mehrere Festplatten, um einen höheren Abfragedurchsatz zu erzielen.

Zusammenfassen

Dies ist das Ende dieses Artikels über MySQL-Sharding. 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!