Zusammenfassung zum Sharding von MySQL-Datenbanken und -Tabellen

Während der Projektentwicklung werden unsere Datenbankdaten immer größer und daher befinden sich zu viele Daten in einer einzelnen Tabelle. Dies hatte zur Folge, dass Abfragen langsamer wurden und der Anwendungsbetrieb aufgrund des Tabellensperrmechanismus erheblich beeinträchtigt wurde, was zu einem Engpass bei der Datenbankleistung führte.

In diesem Fall können wir eine Aufteilung der Datenbank oder Tabelle in Betracht ziehen, d. h. eine Aufteilung einer einzelnen Datenbank oder Tabelle in mehrere Bibliotheken und mehrere Datentabellen. Wenn Benutzer dann zugreifen, können sie basierend auf bestimmten Algorithmen und Logiken auf verschiedene Bibliotheken und verschiedene Tabellen zugreifen. Auf diese Weise werden die Daten auf mehrere Datentabellen verteilt, wodurch der Zugriffsdruck auf eine einzelne Datentabelle verringert wird. Verbesserte Leistung beim Datenbankzugriff.

Nachfolgend finden Sie eine Zusammenfassung der Unterbibliotheken und Untertabellen im Projekt:

Einzelne Datenbank und einzelne Tabelle

Die gängigsten Datenbankdesigns sind Einzeldatenbanken und Einzeltabellen. Beispielsweise gibt es in der Datenbank db eine Benutzertabelle, und alle Benutzer sind in der Benutzertabelle in der db-Bibliothek zu finden.

Einzelne Datenbank mit mehreren Tabellen

Mit zunehmender Benutzeranzahl wird die Datenmenge in der Benutzertabelle immer größer. Wenn die Datenmenge eine bestimmte Höhe erreicht, werden die Abfragen der Benutzertabelle allmählich langsamer, was sich auf die Leistung der gesamten Datenbank auswirkt. Wenn Sie MySQL verwenden, gibt es ein ernsteres Problem. Wenn Sie eine Spalte hinzufügen müssen, sperrt MySQL die Tabelle und alle Lese- und Schreibvorgänge müssen warten.

Der Benutzer kann auf irgendeine Weise horizontal aufgeteilt werden, um zwei Tabellen mit genau derselben Tabellenstruktur zu erzeugen, z. B. user_0000 und user_0001. Die Daten von user_0000 + user_0001 + ... sind genau ein vollständiger Datensatz.

Mehrere Datenbanken und mehrere Tabellen

Wenn die Datenmenge zunimmt, reicht der Speicherplatz einer einzelnen Datenbank möglicherweise nicht mehr aus. Wenn die Anzahl der Abfragen zunimmt, kann ein einzelner Datenbankserver diese möglicherweise nicht mehr unterstützen. Zu diesem Zeitpunkt kann die Datenbank horizontal differenziert werden.

Regeln für das Sharding

Beim Entwerfen einer Tabelle müssen Sie die Regeln für die Aufteilung der Tabelle in verschiedene Datenbanken und Tabellen festlegen. Wenn sich beispielsweise ein neuer Benutzer anmeldet, muss das Programm bestimmen, zu welcher Tabelle die Benutzerinformationen hinzugefügt werden sollen. Ebenso müssen wir beim Anmelden über die Kontonummer des Benutzers den entsprechenden Datensatz in der Datenbank finden, und all dies muss nach bestimmten Regeln erfolgen.

Routenplanung

Der Prozess des Suchens der entsprechenden Tabellen und Bibliotheken durch die Bibliotheks- und Tabellenpartitionierungsregeln. Wenn beispielsweise die Regel zum Aufteilen von Datenbanken und Tabellen „user_id mod 4“ lautet und ein Benutzer ein neues Konto mit der Konto-ID 123 registriert, können wir „id mod 4“ verwenden, um festzulegen, dass dieses Konto in der Tabelle „User_0003“ gespeichert werden soll. Wenn sich Benutzer 123 anmeldet, überprüfen wir, ob der Datensatz in User_0003 vorhanden ist, indem wir 123 Mod 4 ausführen.

Probleme und Vorsichtsmaßnahmen durch Unterbibliotheken und Untertabellen

1. Probleme mit den Abmessungen von Unterbibliotheken und Untertabellen

Wenn ein Benutzer ein Produkt kauft, muss der Transaktionsdatensatz gespeichert und abgerufen werden. Wenn die Tabelle nach dem Breitengrad des Benutzers aufgeteilt ist, wird der Transaktionsdatensatz jedes Benutzers in derselben Tabelle gespeichert, sodass der Kaufstatus eines Benutzers schnell und bequem ermittelt werden kann. Der Kaufstatus eines bestimmten Produkts ist jedoch wahrscheinlich auf mehrere Tabellen verteilt, was die Ermittlung schwieriger macht. Wenn Sie die Tabelle hingegen nach Produktdimensionen aufteilen, können Sie den Kaufstatus dieses Produkts leicht ermitteln. Schwieriger ist es jedoch, den Transaktionsdatensatz des Käufers zu finden.

Die gängigen Lösungen sind also:

a. Lösen Sie das Problem, indem Sie die Tabelle scannen. Diese Methode ist grundsätzlich unmöglich und die Effizienz zu gering.

b. Erfassen Sie zwei Datensätze, einen entsprechend der Benutzerdimension und einen entsprechend der Produktdimension.

c. Lösen Sie es über Suchmaschinen. Wenn jedoch die Echtzeitanforderung sehr hoch ist, hängt dies mit der Echtzeitsuche zusammen.

2. Probleme mit gemeinsamen Abfragen

Union-Abfragen sind grundsätzlich nicht möglich, da die zusammengehörenden Tabellen nicht unbedingt in der gleichen Datenbank liegen.

3. Vermeiden Sie datenbankübergreifende Transaktionen

Vermeiden Sie es, Tabellen in db1 zu ändern, während Sie Tabellen in db0 in einer Transaktion ändern. Dies erschwert den Vorgang und beeinträchtigt die Effizienz.

4. Versuchen Sie, denselben Datensatz auf demselben DB-Server abzulegen

Wenn beispielsweise die Produkte und Transaktionsinformationen von Verkäufer A in db0 abgelegt sind, können die zugehörigen Informationen von Verkäufer A bei einem Ausfall von db1 normal verwendet werden. Damit ist zu verhindern, dass Daten einer Datenbank von Daten einer anderen Datenbank abhängig sind.

Ein Master, mehrere Backups

In praktischen Anwendungen überwiegen die Lesevorgänge in den meisten Fällen die Schreibvorgänge bei weitem. MySQL bietet einen Lese-/Schreibtrennungsmechanismus. Alle Schreibvorgänge müssen dem Master entsprechen. Lesevorgänge können auf den Master- und Slave-Maschinen ausgeführt werden. Die Struktur des Slaves ist genau die gleiche wie die des Masters. Ein Master kann mehrere Slaves haben, und es können sogar Slaves an den Slave angeschlossen werden. Diese Methode kann die QPS des DB-Clusters effektiv verbessern.

Alle Schreibvorgänge werden zuerst auf dem Master ausgeführt und dann mit dem Slave synchronisiert, sodass es bei der Synchronisierung vom Master- zum Slave-Rechner zu einer gewissen Verzögerung kommt. Wenn das System sehr ausgelastet ist, wird das Verzögerungsproblem schwerwiegender, und die Zunahme der Anzahl der Slave-Rechner wird dieses Problem ebenfalls verschärfen.

Darüber hinaus ist ersichtlich, dass der Master der Engpass des Clusters ist. Wenn zu viele Schreibvorgänge stattfinden, wird die Stabilität des Masters ernsthaft beeinträchtigt. Wenn der Master ausfällt, funktioniert der gesamte Cluster nicht richtig.

Also

1. Wenn der Lesedruck sehr hoch ist, können Sie das Problem lösen, indem Sie Slave-Maschinen hinzufügen. Wenn die Anzahl der Slave-Maschinen jedoch ein bestimmtes Niveau erreicht, müssen Sie eine Aufteilung der Datenbank in Betracht ziehen.

2. Wenn der Schreibdruck sehr hoch ist, ist Datenbank-Sharding erforderlich.

Warum sollte MySQL in Datenbanken und Tabellen unterteilt werden?

Man kann sagen, dass überall, wo MySQL verwendet wird, bei großen Datenmengen sofort ein Problem auftritt, nämlich die Aufteilung der Datenbank in Tabellen.

Hier ist eine Frage: Warum müssen wir die Datenbank in verschiedene Tabellen aufteilen? Kann MySQL keine großen Tabellen verarbeiten?

Tatsächlich ist es möglich, große Tabellen zu verarbeiten. In den Projekten, die ich erlebt habe, beträgt die physische Dateigröße einer einzelnen Tabelle mehr als 80 G, die Anzahl der Datensätze in einer einzelnen Tabelle beträgt mehr als 500 Millionen, und diese Tabelle ist eine sehr zentrale Tabelle: die Freundschaftsbeziehungstabelle.

Diese Methode ist jedoch nicht die beste. Dateisysteme wie das Ext3-Dateisystem haben ebenfalls viele Probleme bei der Verarbeitung großer Dateien. Diese Ebene kann durch ein xfs-Dateisystem ersetzt werden. Wenn jedoch eine einzelne MySQL-Tabelle zu groß ist, gibt es ein Problem, das schwer zu lösen ist: Vorgänge im Zusammenhang mit der Anpassung der Tabellenstruktur sind grundsätzlich unmöglich. Daher müssen bei großen Elementen bei der Verwendung von Datenbanken und Tabellen Sharding angewendet werden.

Innodb selbst hat nur zwei Sperren für den B-Baum der Datendatei, die Blattknotensperre und die Kindknotensperre. Wie Sie sich vorstellen können, können bei einer Seitenaufteilung oder dem Hinzufügen eines neuen Blatts keine Daten in die Tabelle geschrieben werden. Daher ist Sharding die bessere Wahl.

Wie viele Unterbibliotheken und Untertabellen sind also angemessen?

Der Test zeigt, dass die Schreib- und Leseleistung relativ gut ist, wenn die Anzahl der Datensätze in einer einzelnen Tabelle weniger als 10 Millionen beträgt. Auf diese Weise kann, wenn ein Puffer gelassen wird, die Anzahl der Datensätze in einer einzelnen Tabelle mit allen Datenzeichen unter 8 Millionen und die Anzahl der Datensätze in einer einzelnen Tabelle mit Zeichen unter 5 Millionen gehalten werden.

Wenn der Plan auf 100 Datenbanken und 100 Tabellen basiert, z. B. Benutzergeschäft:

5 Millionen*100*100 = 50000000 = 500 Milliarden Datensätze.

Wenn Sie erst einmal eine grobe Idee im Kopf haben, ist es relativ einfach, geschäftsorientierte Pläne zu machen.

Echte Fragen

Angenommen, die Zahl der Website-Benutzer liegt im zweistelligen Millionenbereich, die Zahl der aktiven Benutzer beträgt jedoch nur 1 %. Wie lässt sich die Zugriffsgeschwindigkeit aktiver Benutzer durch die Optimierung der Datenbank erhöhen?

Antwort:

Mithilfe der MySQL-Partitionierung können Sie aktive Benutzer in eine Zone und inaktive Benutzer in eine andere Zone aufteilen. Die aktive Benutzerzone selbst verfügt über eine relativ kleine Datenmenge, sodass die Zugriffsgeschwindigkeit aktiver Benutzer verbessert werden kann.

Sie können die Tabelle auch horizontal unterteilen, indem Sie aktive Benutzer in eine Tabelle und inaktive Benutzer in eine andere Tabelle einfügen. Dadurch kann die Zugriffsgeschwindigkeit aktiver Benutzer erhöht werden.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Wenn Sie mehr darüber erfahren möchten, schauen Sie sich bitte die folgenden Links an