Wann werden Tabellen in MySQL geteilt?

Situationen, die für die Tabellenaufteilung in MySQL geeignet sind: 1. Wenn die Datenmenge zu groß ist und der normale Betrieb und die Wartung den Geschäftszugriff beeinträchtigen, erfordert das Sichern der Datenbank beispielsweise eine große Menge an Festplatten-E/A und Netzwerk-E/A sowie DDL-Änderungen Eine Tabelle sperrt die gesamte Tabelle. Beim Zugriff auf und bei der Aktualisierung großer Tabellen kommt es zu Sperrwartezeiten. 2. Mit zunehmender Geschäftsentwicklung müssen einige Felder vertikal aufgeteilt werden Der Engpass und die horizontale Aufteilung müssen als Punkt betrachtet werden.

Die Betriebsumgebung dieses Tutorials: Windows7-System, MySQL8-Version, Dell G3-Computer.

Nicht alle Tabellen müssen geteilt werden, dies hängt hauptsächlich von der Wachstumsrate der Daten ab. Die Segmentierung wird die Komplexität des Unternehmens bis zu einem gewissen Grad erhöhen. Neben der Datenspeicherung und -abfrage ist die Datenbank auch eine ihrer wichtigen Aufgaben, um das Unternehmen bei der besseren Umsetzung seiner Anforderungen zu unterstützen.

Verwenden Sie den Trick der Unterdatenbank und Untertabelle nicht, es sei denn, dies ist unbedingt erforderlich, um „Überdesign“ und „vorzeitige Optimierung“ zu vermeiden. Bevor Sie Datenbanken und Tabellen aufteilen, sollten Sie die Aufteilung nicht nur um der Aufteilung willen durchführen. Versuchen Sie zunächst, alles zu tun, was Sie können, z. B. die Hardware zu aktualisieren, das Netzwerk zu aktualisieren, Lese- und Schreibvorgänge zu trennen, den Index zu optimieren usw. Wenn die Datenmenge den Engpass einer einzelnen Tabelle erreicht, sollten Sie das Sharding von Datenbanken und Tabellen in Betracht ziehen.

Wann sollten Untertabellen in MySQL in Betracht gezogen werden

1. Die Datenmenge ist zu groß und der normale Betrieb und die Wartung beeinträchtigen den Geschäftszugriff

Der hier erwähnte Betrieb und die Wartung beziehen sich auf:

• Sichern Sie die Datenbank, wenn eine einzelne Tabelle zu groß ist und während der Sicherung eine große Menge an Festplatten-IO und Netzwerk-IO erforderlich sind. Wenn beispielsweise 1T Daten über das Netzwerk übertragen werden und 50 MB belegen, dauert der Abschluss 20.000 Sekunden. Das Risiko des gesamten Prozesses ist relativ hoch

• Wenn DDL-Änderungen an einer großen Tabelle vorgenommen werden, wird MySQL gesperrt Die gesamte Tabelle wird sehr lange dauern, bis das Unternehmen auf diese Tabelle zugreifen kann. Wenn Sie pt-online-schema-change verwenden, werden während der Nutzung Trigger und Schattentabellen erstellt, was ebenfalls viel Zeit in Anspruch nimmt. Während dieser Operation wird sie als Risikozeit gezählt. Durch Aufteilen der Datentabelle und Reduzieren des Gesamtbetrags kann dieses Risiko verringert werden.

• Auf große Tabellen wird häufig zugegriffen und diese werden häufig aktualisiert, daher ist es wahrscheinlicher, dass es zu Sperrwartezeiten kommt. Teilen Sie die Daten auf, tauschen Sie Platz gegen Zeit und reduzieren Sie den Zugriffsdruck im Verborgenen.

2 Während sich das Unternehmen entwickelt, müssen einige Felder vertikal aufgeteilt werden Das Projekt sieht wie folgt aus:

In der Anfangsphase des Projekts erfüllt dieses Design einfache Geschäftsanforderungen und erleichtert außerdem eine schnelle iterative Entwicklung. Wenn sich das Unternehmen schnell entwickelt, steigt die Anzahl der Benutzer von 100.000 auf 1 Milliarde und die Benutzer sind sehr aktiv. Das Feld last_login_name wird bei jeder Anmeldung aktualisiert, was dazu führt, dass die Benutzertabelle ständig aktualisiert wird, was sehr stressig ist. Andere Felder: id, name, personal_info bleiben unverändert oder werden selten aktualisiert. Aus geschäftlicher Sicht ist es notwendig, last_login_time aufzuteilen und eine neue user_time-Tabelle zu erstellen. Das Attribut

personal_info wird seltener aktualisiert und abgefragt und das Textfeld nimmt zu viel Platz ein. Zu diesem Zeitpunkt ist es erforderlich, die Tabelle user_ext vertikal aufzuteilen.

3. Die Datenmenge wächst rasant

Mit der rasanten Geschäftsentwicklung wird die Datenmenge in einer einzelnen Tabelle weiter wachsen. Wenn sich die Leistung dem Engpass nähert, ist es notwendig, horizontales Sharding in Betracht zu ziehen separate Datenbanken und Tabellen. Zu diesem Zeitpunkt müssen Sie die entsprechenden Segmentierungsregeln auswählen und die Datenkapazität im Voraus abschätzen

Geschäftsfallanalyse

1. User Center ist ein sehr verbreitetes Unternehmen, das hauptsächlich Benutzer bereitstellt Mit Für Funktionen wie Registrierung, Anmeldung, Abfrage/Änderung usw. lautet die Kerntabelle:

Jedes architektonische Design, das vom Geschäft getrennt ist, ist ein Schurke Die Anforderungen des Geschäftsszenarios müssen geklärt werden:

Benutzerseite: Der Front-End-Zugriff mit einer großen Anzahl von Besuchen muss eine hohe Verfügbarkeit und hohe Konsistenz gewährleisten. Es gibt zwei Haupttypen von Anforderungen:

Benutzeranmeldung: Benutzerinformationen über Anmeldename/Telefon/E-Mail abfragen, 1 % der Anfragen gehören zu diesem Typ

• Benutzerinformationsabfrage: Nach dem Anmelden abfragen der Benutzer über UID-Informationen, 99 % der Anfragen sind von diesem Typ
  Betriebsseite: Hintergrundzugriff, unterstützt betriebliche Anforderungen und führt Paging-Abfragen nach Alter, Geschlecht, Anmeldezeit, Registrierungszeit usw. durch. Es handelt sich um ein internes System mit geringem Zugriffsvolumen und geringen Anforderungen an Verfügbarkeit und Konsistenz.

• 2. Horizontale Segmentierungsmethode

Wenn die Datenmenge immer größer wird, muss die Datenbank horizontal segmentiert werden. Zu den oben beschriebenen Segmentierungsmethoden gehören „basierend auf dem numerischen Bereich“ und „basierend auf dem numerischen Modul“. ".

"Basierend auf dem numerischen Bereich": Basierend auf der Primärschlüssel-UID werden die Daten entsprechend dem UID-Bereich horizontal in mehrere Datenbanken unterteilt. Beispiel: Benutzer-db1 speichert Daten mit UID-Bereichen von 0 bis 1000w und Benutzer-db2 speichert Daten mit UID-Bereichen von 1000w bis 2000wuid.

• Der Vorteil ist: Die Erweiterung ist einfach. Wenn die Kapazität nicht ausreicht, fügen Sie einfach eine neue Datenbank hinzu.

• Der Nachteil ist: Das Anforderungsvolumen ist ungleichmäßig. Neu registrierte Benutzer sind im Allgemeinen aktiver, sodass der neue Benutzer-db2 eine höhere Auslastung aufweist als Benutzer-db1, was zu einer unausgewogenen Serverauslastung führt „Nach numerischem Modulo“

  : Die Primärschlüssel-UID wird auch als Basis für die Aufteilung verwendet und die Daten werden basierend auf dem Modulo-Wert von UID horizontal in mehrere Datenbanken aufgeteilt. Beispiel: Benutzer-DB1 speichert UID-Daten Modulo 1, Benutzer-DB2 speichert UID-Daten Modulo 0.

Der Vorteil ist: Das Datenvolumen und das Anforderungsvolumen sind gleichmäßig verteilt.

• Der Nachteil ist: Die Erweiterung ist mühsam. Wenn die Kapazität nicht ausreicht, ist ein erneutes Aufwärmen erforderlich. Eine reibungslose Migration der Daten muss berücksichtigt werden.

• Nicht-UID-Abfragemethode

Nach der horizontalen Segmentierung kann die Nachfrage nach UID-Abfragen gut befriedigt und direkt an eine bestimmte Datenbank weitergeleitet werden. Bei Abfragen, die nicht auf der UID basieren, wie z. B. login_name, ist nicht bekannt, auf welche Bibliothek zugegriffen werden soll. In diesem Fall müssen alle Bibliotheken durchlaufen werden, was die Leistung erheblich verringert. Für die Benutzerseite kann die Lösung „Einrichten einer Zuordnungsbeziehung von Nicht-UID-Attributen zu UID“ übernommen werden, für die Betriebsseite kann die Lösung „Trennung von Front-End und Back-End“ übernommen werden.

1. Stellen Sie eine Zuordnungsbeziehung von Nicht-UID-Attributen zu UID her. und verwenden Sie eine Indextabelle oder einen Cache, um es zu speichern. Wenn Sie auf login_name zugreifen, fragen Sie zuerst die UID, die login_name entspricht, über die Zuordnungstabelle ab und suchen Sie dann die spezifische Bibliothek über die UID.

Die Zuordnungstabelle hat nur zwei Spalten und kann viele Daten enthalten. Wenn die Datenmenge zu groß ist, kann die Zuordnungstabelle auch horizontal geteilt werden. Diese Art der Indexstruktur im KV-Format kann den Cache verwenden, um die Abfrageleistung zu optimieren. Die Zuordnungsbeziehung ändert sich nicht häufig und die Cache-Trefferquote ist sehr hoch.

Gen-Methode

• Breaking-Gen: Wenn die Bibliothek über UID in 8 Bibliotheken unterteilt ist, wird das Routing mit UID % 8 durchgeführt. Zu diesem Zeitpunkt bestimmen die letzten 3 Bits der UID die spezifischen Benutzerdaten dieser Zeile . Auf welche Bibliothek es fällt, dann können diese 3 Bits als Unterbibliotheksgene betrachtet werden.

2. Trennung von Front-End und Back-End

Für die Benutzerseite besteht die Hauptanforderung darin, sich auf einzeilige Abfragen zu konzentrieren. Es ist notwendig, eine Zuordnungsbeziehung von Login-Name/Telefon/E-Mail-Adresse herzustellen , wodurch das Abfrageproblem dieser Felder gelöst werden kann.

Auf der Betriebsseite gibt es viele Abfragen mit Batch-Paging und verschiedenen Bedingungen. Solche Abfragen erfordern einen großen Rechenaufwand, geben eine große Datenmenge zurück und verbrauchen eine hohe Leistung der Datenbank. Wenn zu diesem Zeitpunkt derselbe Stapel von Diensten oder Datenbanken mit der Benutzerseite geteilt wird, kann eine kleine Anzahl von Hintergrundanforderungen eine große Menge an Datenbankressourcen belegen, was zu einer Verschlechterung der Zugriffsleistung oder einer Zeitüberschreitung auf der Benutzerseite führt.

• Für diese Art von Geschäft ist es am besten, die Lösung „Trennung von Front-End und Back-End“ zu übernehmen. Das Back-End-Geschäft auf der Betriebsseite extrahiert unabhängige Dienste und DBs, um die Kopplung mit dem Front-End-Geschäft zu lösen System. Da die Betriebsseite keine hohen Anforderungen an Verfügbarkeit und Konsistenz stellt, ist es möglich, nicht auf die Echtzeitbibliothek zuzugreifen, sondern die Daten für den Zugriff über Binlog asynchron mit der Betriebsbibliothek zu synchronisieren. Wenn die Datenmenge groß ist, können Sie auch die ES-Suchmaschine oder Hive verwenden, um die komplexen Abfragemethoden im Hintergrund zu erfüllen.

【Verwandte Empfehlung:

MySQL-Video-Tutorial

】

Das obige ist der detaillierte Inhalt vonWann werden Tabellen in MySQL geteilt?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!