Zusammenfassung der Aufteilung der MySQL-Datenbankdaten in Datenbanken und Tabellen_MySQL

Idee eins zur Entwicklung der Datenspeicherung: einzelne Datenbank und einzelne Tabelle

Eine einzelne Datenbank und eine einzelne Tabelle sind die gebräuchlichsten Datenbankdesigns. Beispielsweise gibt es eine Benutzertabelle in der Datenbank-Datenbank, und alle Benutzer können in der Benutzertabelle in der Datenbank-Datenbank gefunden werden.

Idee zwei zur Entwicklung der Datenspeicherung: einzelne Datenbank mit mehreren Tabellen

Mit zunehmender Anzahl von Benutzern wird das Datenvolumen der Benutzertabelle immer größer. Wenn das Datenvolumen ein bestimmtes Niveau erreicht, wird die Abfrage der Benutzertabelle allmählich verlangsamt, was sich auf die Gesamtleistung auswirkt DB. Wenn Sie MySQL verwenden, besteht ein schwerwiegenderes Problem darin, dass MySQL die Tabelle sperrt, wenn Sie eine Spalte hinzufügen müssen, sodass alle Lese- und Schreibvorgänge nur warten können.

Benutzer können auf irgendeine Weise horizontal aufgeteilt werden, um zwei Tabellen mit genau derselben Struktur zu generieren: Benutzer_0000, Benutzer_0001 usw. Die Daten von Benutzer_0000, Benutzer_0001 ... sind nur ein vollständiger Datensatz.

Idee drei zur Entwicklung der Datenspeicherung: mehrere Datenbanken und mehrere Tabellen

Mit zunehmender Datenmenge reicht der Speicherplatz einer einzelnen Datenbank möglicherweise nicht mehr aus, und mit zunehmender Anzahl von Abfragen kann ein einzelner Datenbankserver dies nicht mehr unterstützen. Zu diesem Zeitpunkt kann die Datenbank horizontal differenziert werden.

Mysql-Datenbank-Sharding-Regeln

Beim Entwerfen einer Tabelle müssen Sie die Regeln festlegen, nach denen die Tabelle in Datenbanken und Tabellen unterteilt wird. Wenn es beispielsweise einen neuen Benutzer gibt, muss das Programm bestimmen, zu welcher Tabelle die Benutzerinformationen hinzugefügt werden sollen. Ebenso müssen wir beim Anmelden den entsprechenden Datensatz in der Datenbank über das Konto des Benutzers finden, wobei alle Schritte befolgt werden müssen Verhalten.
Route

Der Prozess des Auffindens der entsprechenden Tabellen und Bibliotheken mithilfe der Sharding-Regeln. Die Regel für das Sharding von Datenbanken und Tabellen lautet beispielsweise user_id mod 4. Wenn ein Benutzer ein neues Konto mit der Konto-ID 123 registriert, können wir id mod 4 verwenden, um zu bestimmen, dass dieses Konto in der Tabelle User_0003 gespeichert werden soll. Wenn sich Benutzer 123 anmeldet, stellen wir fest, dass er in Benutzer_0003 aufgezeichnet ist, nachdem 123 Mod 4 übergeben wurde.

Im Folgenden sind die Probleme aufgeführt, die durch Unterdatenbanken und Untertabellen verursacht werden, sowie Angelegenheiten, die Aufmerksamkeit erfordern

1. Probleme mit Unterdatenbank- und Untertabellendimensionen

Wenn ein Benutzer ein Produkt kauft, muss der Transaktionsdatensatz gespeichert und abgerufen werden. Wenn die Tabelle entsprechend dem Spielraum des Benutzers unterteilt ist, wird der Transaktionsdatensatz jedes Benutzers in derselben Tabelle gespeichert, sodass dies schnell und bequem ist Finden Sie den Kaufstatus eines Benutzers, aber der Kaufstatus eines bestimmten Produkts ist wahrscheinlich auf mehrere Tabellen verteilt, was die Suche schwieriger macht. Im Gegenteil, wenn Sie die Tabelle nach Produktdimensionen unterteilen, können Sie den Kaufstatus dieses Produkts leicht ermitteln, es ist jedoch schwieriger, die Transaktionsdatensätze des Käufers zu finden.

Übliche Lösungen sind also:

a. Lösen Sie das Problem durch Scannen des Messgeräts. Diese Methode ist grundsätzlich unmöglich und die Effizienz ist zu gering.
b. Zeichnen Sie zwei Daten auf, eine nach Benutzerdimensionen in Tabellen und eine nach Produktdimensionen in Tabellen.
c. Lösen Sie es über Suchmaschinen. Wenn die Echtzeitanforderungen jedoch sehr hoch sind, muss es mit der Echtzeitsuche in Zusammenhang stehen.

2. Probleme mit gemeinsamen Abfragen

Eine Unionsabfrage ist grundsätzlich unmöglich, da sich die zugehörigen Tabellen möglicherweise nicht in derselben Datenbank befinden.

3. Vermeiden Sie datenbankübergreifende Transaktionen

Vermeiden Sie es, die Tabelle in db1 zu ändern, während die Tabelle in db0 in einer Transaktion geändert wird. Einer davon ist, dass der Vorgang komplizierter ist und die Effizienz in gewissem Maße beeinträchtigt wird.

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

Wenn beispielsweise die Produkte und Transaktionsinformationen von Verkäufer A in DB0 abgelegt werden und DB1 ausfällt, können die zugehörigen Dinge von Verkäufer A normal verwendet werden. Dies bedeutet, dass verhindert wird, dass Daten in einer Datenbank auf Daten in einer anderen Datenbank angewiesen sind.

Ein Master, viele Backups

In tatsächlichen Anwendungen ist das Lesen in den meisten Fällen viel wichtiger als das Schreiben. MySQL bietet einen Lese-/Schreib-Trennmechanismus. Alle Schreibvorgänge können auf den Master- und Slave-Maschinen ausgeführt werden Sie können einen Slave anschließen, wodurch die QPS des DB-Clusters effektiv verbessert werden kann.

Alle Schreibvorgänge werden zuerst auf dem Master ausgeführt und dann mit dem Slave synchronisiert. Daher kommt es zu einer gewissen Verzögerung bei der Synchronisierung vom Master zum Slave-Computer, wenn das System sehr ausgelastet ist gravierend Die Anzahl der Slave-Maschinen Die Erhöhung wird auch dieses Problem noch gravierender machen.

Darüber hinaus ist ersichtlich, dass der Master der Flaschenhals des Clusters ist. Wenn zu viele Schreibvorgänge ausgeführt werden, wird die Stabilität des Masters erheblich beeinträchtigt richtig.

Also 1. Wenn der Lesedruck sehr hoch ist, können Sie erwägen, Slave-Maschinen für eine Teillösung hinzuzufügen. Wenn die Anzahl der Slave-Maschinen jedoch eine bestimmte Zahl erreicht, müssen Sie eine Unterbibliothek in Betracht ziehen. 2. Wenn der Schreibdruck sehr hoch ist, ist es notwendig, einen Unterbibliotheksbetrieb durchzuführen.

Warum muss MySQL in Datenbanken und Tabellen unterteilt werden?

Man kann sagen, dass bei Verwendung von MySQL, solange die Datenmenge groß ist, sofort ein Problem auftritt, das eine Aufteilung von Datenbanken und Tabellen erfordert.
Hier ist eine Frage: Warum müssen wir Datenbanken und Tabellen aufteilen? Kann MySQL keine großen Tabellen verarbeiten?
Tatsächlich kann es große Tabellen verarbeiten. In den Projekten, die ich erlebt habe, beträgt die physische Dateigröße einer einzelnen Tabelle mehr als 80 GB und die Anzahl der Datensätze in einer einzelnen Tabelle beträgt mehr als 500 Millionen, und diese Tabelle
Es ist eine sehr nützliche Tabelle: Freundschaftsbeziehungstabelle.

Man kann jedoch sagen, dass diese Methode nicht die beste ist, da Dateisysteme wie Ext3-Dateisysteme auch viele Probleme beim Umgang mit größeren Dateien haben.
Diese Ebene kann durch das xfs-Dateisystem ersetzt werden. Es gibt jedoch ein Problem, das schwer zu lösen ist, wenn die einzelne MySQL-Tabelle zu groß ist: die Operationsbasis im Zusammenhang mit der Anpassung der Tabellenstruktur
Dies ist nicht möglich. Bei Großprojekten wird die Anwendung von Unterdatenbanken und Untertabellen während der Nutzung überwacht.

Von Innodb selbst gibt es nur zwei Sperren für den Btree der Datendatei, die Blattknotensperre und die untergeordnete Knotensperre. Sie können sich das vorstellen, wenn eine Seitenteilung auftritt oder eine Seite hinzugefügt wird
Neue Blätter führen dazu, dass Daten nicht in die Tabelle geschrieben werden können.
Daher sind Unterdatenbank und Untertabelle die bessere Wahl.

Wie viele Unterdatenbanken und Tabellen sind also angemessen?
Nach dem Testen von 10 Millionen Datensätzen in einer einzelnen Tabelle ist die Schreib- und Leseleistung relativ gut. Auf diese Weise bleiben alle Datenschriftarten in der einzelnen Tabelle bei
, wenn etwas Puffer übrig bleibt Die Anzahl der Datensätze liegt unter 8 Millionen und die Anzahl der einzelnen Tabellen mit Zeichen wird unter 5 Millionen gehalten.

Wenn nach 100 Datenbanken und 100 Tabellen geplant, z. B. Benutzergeschäft:
5 Millionen*100*100 = 500.000.000 = 500 Milliarden Datensätze.

Da ich nun eine Zahl im Kopf habe, ist es relativ einfach, geschäftsorientiert zu planen.