Anwendungsszenarien und Entwurfsmethoden für MySQL-Tabellen- und Datenbank-Sharding

Viele Freunde haben in Foren und Nachrichtenbereichen gefragt, unter welchen Umständen MySQL sharded werden muss und welche Entwurfsmethode die beste Wahl ist. Basierend auf diesen Fragen hat der Herausgeber einige Anwendungsszenarien und Beispiele der besten Entwurfsmethoden für MySQL-Sharding zusammengestellt.

1. Untertabelle

Szenario: Bei umfangreichen Internetanwendungen kann die Anzahl der Datensatzzeilen in einer einzelnen Datenbanktabelle mehrere zehn oder sogar hundert Millionen betragen und auf die Datenbank treten extrem viele gleichzeitige Zugriffe auf. MySQL-Architektur mit Master-Slave-Replikationsmodus,

Nur das Lesen der Datenbank kann erweitert werden, während der Schreibvorgang der Datenbank weiterhin auf den Master konzentriert ist. Darüber hinaus ist es unmöglich, eine unbegrenzte Anzahl von Slaves auf einem einzigen Master zu montieren. Die Anzahl der Slaves wird durch die Fähigkeiten und die Auslastung des Masters begrenzt.

Daher muss die Datenbankdurchsatzkapazität weiter ausgebaut werden, um den Anforderungen an hohe gleichzeitige Zugriffe und massive Datenspeicherung gerecht zu werden!

Bei einer einzelnen Tabelle, auf die sehr häufig zugegriffen wird und die eine riesige Datenmenge enthält, müssen wir zunächst die Anzahl der Datensätze in der einzelnen Tabelle reduzieren, um die für die Datenabfrage erforderliche Zeit zu verkürzen und den Datenbankdurchsatz zu verbessern. Dies ist das sogenannte Table-Sharding!

Bevor Sie eine Tabelle sharden, müssen Sie zunächst eine geeignete Sharding-Strategie auswählen, damit die Daten gleichmäßig auf mehrere Tabellen verteilt werden können, ohne normale Abfragen zu beeinträchtigen!

Bei Internetunternehmen sind die meisten Daten mit Benutzern verknüpft, daher ist die Benutzer-ID das am häufigsten verwendete Untertabellenfeld. Da die meisten Abfragen eine Benutzer-ID benötigen, hat dies keine Auswirkungen auf die Abfrage und kann zu einer Ausgewogenheit der Daten führen.

Verteilt auf die einzelnen Tabellen (natürlich kann die Verteilung der heißen und kalten Daten in manchen Szenarien unausgewogen sein), wie in der folgenden Abbildung dargestellt:

Angenommen, es gibt eine Bestelltabelle, in der die Kaufinformationen des Benutzers aufgezeichnet werden. Da die Bestelltabelle zu viele Datensätze enthält, wird sie in 256 Tabellen aufgeteilt.

Die geteilten Datensätze werden gemäß der Benutzer-ID %256 in der entsprechenden Tabelle gespeichert, und die Front-End-Anwendung findet die entsprechende Auftragsspeichertabelle und greift gemäß der entsprechenden Benutzer-ID %256 darauf zu.

Auf diese Weise wird die Benutzer-ID zu einer notwendigen Abfragebedingung, da sonst nicht auf die Daten zugegriffen werden kann, da die Tabelle, in der die Daten gespeichert sind, nicht gefunden werden kann.

Hinweis: Die Anzahl der Tabellen nach der Aufteilung beträgt im Allgemeinen 2 hoch n, weshalb oben auch die Aufteilung in 256 Tabellen erfolgt!

Nehmen wir an, dass die Struktur der Bestelltabelle wie folgt ist:

Tabelle erstellen order_( 
 order_id bigint(20) Primärschlüssel auto_increment, 
 Benutzer-ID bigint(20), 
 Benutzer_Nick varchar (50), 
 Auktions-ID bigint(20), 
 Auktionstitel bigint(20), 
 Preis bigint(20), 
 Auktionskategorie varchar(200), 
 Verkäufer-ID bigint(20), 
 Verkäufer_Nick varchar(50) 
)

Nachdem die Tabelle aufgeteilt wurde, müssen Sie unter der Annahme von user_id = 257 und auction_id = 100 die entsprechenden Bestellinformationen basierend auf auction_id abfragen. Die entsprechende SQL-Anweisung lautet wie folgt:

Wählen Sie * aus Bestellung_1, wobei Benutzer-ID = 257 und Auktions-ID = 100 ist.

Unter diesen wird order_1 basierend auf 257 % 256 berechnet, was der ersten Auftragstabelle nach der Partition entspricht.

2. Datenbankabteilung

Szenario: Durch Tabellen-Sharding lässt sich das Problem der verringerten Abfrageeffizienz aufgrund übermäßiger Datenmengen in einer einzelnen Tabelle lösen, es kann jedoch keine qualitative Verbesserung der gleichzeitigen Verarbeitungskapazität der Datenbank herbeigeführt werden. Angesichts der hohen Anzahl gleichzeitiger Lese- und Schreibzugriffe, wenn der Datenbankmaster

Wenn der Server dem Druck der Schreibvorgänge nicht standhalten kann, ist es sinnlos, den Slave-Server zu erweitern, egal wie Sie es machen.

Daher müssen wir unser Denken ändern und die Datenbank aufteilen, um die Schreibfähigkeit der Datenbank zu verbessern. Dies ist die sogenannte Datenbankpartitionierung!

Ähnlich wie bei der Strategie des Tabellen-Shardings kann beim Datenbank-Sharding eine Schlüsselwort-Modulo-Methode zum Routen des Datenzugriffs verwendet werden, wie in der folgenden Abbildung dargestellt:

Unter Verwendung der vorherigen Reihenfolgetabelle und der Annahme, dass der Wert des Felds user_id 258 beträgt, wird die ursprüngliche einzelne Datenbank in 256 Datenbanken aufgeteilt. Anschließend wird die Zugriffsanforderung der Anwendung an die Datenbank an die zweite Datenbank weitergeleitet (258 % 256 = 2).

3. Unterbibliothek und Untertisch

Szenario: Manchmal ist die Datenbank dem Druck eines hohen gleichzeitigen Zugriffs und der Notwendigkeit ausgesetzt, große Datenmengen zu speichern. In diesem Fall ist es notwendig, sowohl die Tabellen-Sharding-Strategie als auch die Bibliotheks-Sharding-Strategie für die Datenbank anzuwenden, um das System gleichzeitig zu erweitern.

Gleichzeitige Verarbeitungsfunktionen und die Verbesserung der Abfrageleistung einer einzelnen Tabelle werden als Sharding bezeichnet.

Die Sharding-Strategie ist komplizierter als die vorherige Strategie des reinen Shardings oder des reinen Shardings. Eine Routing-Strategie des Shardings sieht wie folgt aus:

1. Zwischenvariable = user_id % (Anzahl der Unterdatenbanken * Anzahl der Tabellen in jeder Datenbank)

2. Bibliothek = Ganzzahl (Zwischenvariable / Anzahl der Tabellen in jeder Bibliothek)

3. Tabelle = Zwischenvariable % Anzahl der Tabellen in jeder Bibliothek

Verwenden Sie auch user_id als Routing-Feld. Verwenden Sie zunächst user_id, um die Anzahl der Bibliotheken * die Nummer jeder Bibliothekstabelle zu modulieren, um eine Zwischenvariable zu erhalten. Teilen Sie dann die Zwischenvariable durch die Nummer jeder Bibliothekstabelle und runden Sie sie auf, um zu erhalten

Die entsprechende Bibliothek; und die Zwischenvariable modulo die Nummer jeder Bibliothekstabelle, d. h. die entsprechende Tabelle wird erhalten.

Der detaillierte Prozess der Datenbank- und Tabellen-Sharding-Strategie ist wie folgt:

Angenommen, die ursprüngliche Reihenfolge der einzelnen Datenbanken und Tabellen ist in 256 Bibliotheken mit jeweils 1024 Tabellen aufgeteilt. Gemäß der oben genannten Routing-Strategie lautet der Routing-Berechnungsprozess für den Zugriff auf user_id = 262145 wie folgt:

1. Zwischenvariable = 262145 % (256 * 1024) = 1

2. Bibliothek = gerundet (1/1024) = 0

3. Tabelle = 1 % 1024 = 1

Dies bedeutet, dass die Abfrage und Änderung des Bestelldatensatzes von user_id=262145 zur Ausführung an die erste Tabelle order_1 in der 0. Datenbank weitergeleitet wird! ! !