So teilen Sie Daten in MySQL-Tabellen und -Datenbanken auf

Die relationale Datenbank selbst kann leicht zu einem Systemengpass werden, da die Speicherkapazität, die Anzahl der Verbindungen und die Verarbeitungsleistung einer einzelnen Maschine begrenzt sind. Wenn das Datenvolumen einer einzelnen Tabelle 10 Millionen oder 100 GB erreicht, verschlechtert sich die Leistung aufgrund der großen Anzahl von Abfragedimensionen bei der Ausführung vieler Vorgänge immer noch erheblich, selbst wenn Slave-Bibliotheken hinzugefügt und Indizes optimiert werden. Zu diesem Zeitpunkt sollten wir eine Aufteilung in Betracht ziehen. Der Zweck der Aufteilung besteht darin, die Belastung der Datenbank zu verringern und die Abfragezeit zu verkürzen.

Der Kerninhalt der Datenbankverteilung ist nichts anderes als die Datensegmentierung (Sharding) und die Positionierung und Integration von Daten nach der Segmentierung. Bei der Datensegmentierung werden Daten verteilt in mehreren Datenbanken gespeichert, sodass die Datenmenge in einer einzelnen Datenbank kleiner wird und das Leistungsproblem einer einzelnen Datenbank durch die Erweiterung der Anzahl der Hosts gemildert wird, wodurch das Ziel einer Verbesserung der Datenbankbetriebsleistung erreicht wird.

Die Datensegmentierung kann je nach Segmentierungstyp in zwei Typen unterteilt werden: vertikale (längs verlaufende) Segmentierung und horizontale (quer verlaufende) Segmentierung.

1. Vertikales (längsseitiges) Schneiden

Es gibt zwei gängige Arten der vertikalen Segmentierung: vertikale Datenbanksegmentierung und vertikale Tabellensegmentierung.

1.1 Vertikale Datenbank

Das heißt, dass aufgrund der Geschäftskopplung unterschiedliche Tabellen mit geringer Korrelation in unterschiedlichen Datenbanken gespeichert werden. Der Ansatz ähnelt der Aufteilung eines großen Systems in mehrere kleine Systeme, basierend auf Geschäfts

Die Kategorien sind unabhängig voneinander unterteilt. Ähnlich dem Ansatz der „Microservice Governance“ verwendet jeder Microservice eine separate Datenbank. Wie in der Abbildung gezeigt:

Die Datentabellen verschiedener Module werden in separaten Bibliotheken gespeichert. Die Module stehen in keinem Zusammenhang miteinander.

Wenn ja, muss das Problem durch Datenredundanz oder sekundäre Verarbeitung gelöst werden. Diese Geschäftsmethode und Datenstruktur ist am klarsten. Wenn wir jedoch datenbankübergreifende Abfragen nicht verhindern können, deklarieren wir diesen Pfad anders.

1.2 Vertikale Tabellenaufteilung

Es basiert auf den „Spalten“ in der Datenbank. Wenn eine Tabelle viele Felder hat, können Sie eine neue erweiterte Tabelle erstellen und die Felder, die nicht häufig verwendet werden oder eine große Feldlänge haben, in die erweiterte Tabelle aufteilen. Wenn viele Felder vorhanden sind (eine große Tabelle hat beispielsweise mehr als 100 Felder), erleichtert das „Aufteilen der großen Tabelle in kleine Tabellen“ die Entwicklung und Wartung und vermeidet seitenübergreifende Probleme. MySQL speichert Daten über Datenseiten auf der untersten Ebene. Wenn ein Datensatz zu viel Platz einnimmt, wird er seitenübergreifend ausgeführt, was zu zusätzlichem Leistungsaufwand führt. Darüber hinaus lädt die Datenbank Daten zeilenweise in den Speicher, sodass die Felder in der Tabelle kürzer sind und häufiger aufgerufen werden. Der Speicher kann mehr Daten mit einer höheren Trefferquote laden, was die Festplatten-E/A reduziert und somit die Datenbankleistung verbessert.

Vorteile der vertikalen Segmentierung:

• Lösen Sie die Kopplung auf der Ebene des Geschäftssystems und machen Sie das Geschäft klar
• Ähnlich der Governance von Microservices können damit auch Daten verschiedener Unternehmen hierarchisch verwaltet, gepflegt, überwacht und erweitert werden.
• In Szenarien mit hoher Parallelität kann die vertikale Segmentierung die Engpässe bei IO, Anzahl der Datenbankverbindungen und Hardwareressourcen einzelner Maschinen bis zu einem gewissen Grad beheben.

Mangel:

• Einige Tabellen können nicht verknüpft werden und können nur durch Schnittstellenaggregation gelöst werden, was die Komplexität der Entwicklung erhöht
• Verteilte Transaktionsverarbeitung ist komplex
• Es besteht immer noch das Problem, dass sich zu viele Daten in einer einzelnen Tabelle befinden (horizontale Segmentierung ist erforderlich).

2. Horizontale (Querschnitts-)Segmentierung

Wenn sich eine Anwendung nur schwer vertikal mit höherer Granularität aufteilen lässt oder die Menge der Datenzeilen nach dem Aufteilen sehr groß ist und es Engpässe bei der Lese-, Schreib- und Speicherleistung einer einzelnen Datenbank gibt, ist eine horizontale Aufteilung erforderlich.

Horizontales Sharding wird in Intra-Datenbank-Sharding und Sub-Datenbank-Sharding unterteilt. Dabei wird dieselbe Tabelle auf mehrere Datenbanken oder mehrere Tabellen verteilt, je nach den inhärenten logischen Beziehungen der Daten in der Tabelle. Jede Tabelle enthält nur einen Teil der Daten, wodurch die Datenmenge in einer einzelnen Tabelle reduziert und ein verteilter Effekt erzielt wird. Wie in der Abbildung gezeigt:

Im Vergleich zur vertikalen Segmentierung, bei der Tabellen klassifiziert werden, werden bei dieser Methode die Daten gemäß einer bestimmten Regel für jedes Feld in der Tabelle in verschiedenen Datenbanken (oder verschiedenen Tabellen) gespeichert, d. h. die Daten werden nach der Anzahl der Zeilen segmentiert.

Das Aufteilen von Tabellen innerhalb einer Datenbank löst nur das Problem zu vieler Daten in einer einzelnen Tabelle, verteilt die Tabelle jedoch nicht auf Datenbanken auf verschiedenen Computern. Daher ist es nicht sehr hilfreich, den Druck auf die MySQL-Datenbank zu verringern. Alle konkurrieren weiterhin um die CPU, den Speicher und die Netzwerk-E/A derselben physischen Maschine. Dieses Problem lässt sich am besten durch Aufteilen der Datenbank und der Tabellen lösen.

Vorteile der horizontalen Sharding:

• Es gibt keinen Leistungsengpass durch übermäßiges Datenvolumen einzelner Datenbanken und hohe Parallelität, was die Systemstabilität und die Ladekapazität verbessert
• Die anwendungsseitige Transformation ist relativ gering und es besteht keine Notwendigkeit, die Geschäftsmodule aufzuteilen

Mangel:

• Die Konsistenz der Transaktionen über Shards hinweg ist schwer zu gewährleisten
• Die Leistung von datenbankübergreifenden Join-Abfragen ist schlecht
• Der Aufwand und die Wartung mehrerer Datenerweiterungen sind extrem groß

Nach dem horizontalen Sharding wird dieselbe Tabelle in mehreren Datenbanken/Tabellen angezeigt und der Inhalt jeder Datenbank/Tabelle ist unterschiedlich. Einige typische Regeln für die Datenteilung sind:

2.1 Nach dem Zahlenbereich

Durch Zeitintervall oder ID-Intervall teilen. Beispiel: Verteilen Sie Daten aus verschiedenen Monaten oder sogar Tagen nach Datum auf unterschiedliche Datenbanken. Verteilen Sie Datensätze mit Benutzer-IDs von 1 bis 9999 an die erste Datenbank, Datensätze mit Benutzer-IDs von 10000 bis 20000 an die zweite Datenbank und so weiter. In gewissem Sinne handelt es sich auch bei der in einigen Systemen angewandten „Trennung von kalten und heißen Daten“, bei der einige weniger genutzte historische Daten in andere Datenbanken migriert werden und in Geschäftsfunktionen nur Abfragen für heiße Daten möglich sind, um eine ähnliche Vorgehensweise.

Die Vorteile hiervon sind:

• Die Größe einzelner Tabellen ist steuerbar
• Die horizontale Erweiterung ist natürlich problemlos möglich. Wenn Sie später den gesamten Shard-Cluster erweitern möchten, müssen Sie nur Knoten hinzufügen, ohne Daten aus anderen Shards zu migrieren.
• Wenn Sie Shard-Felder für Bereichssuchen verwenden, können kontinuierliche Shards Shards für schnelle Abfragen rasch lokalisieren und so Probleme bei Shard-übergreifenden Abfragen effektiv vermeiden.

Mangel:

• Heiße Daten werden zum Leistungsengpass. Beim kontinuierlichen Sharding kann es Daten-Hotspots geben. Beim Sharding nach Zeitfeldern speichern einige Shards beispielsweise Daten aus dem jüngsten Zeitraum, die häufig gelesen und geschrieben werden können, während andere Shards historische Daten speichern, die selten abgefragt werden.

2.2 Modulo nach Wert

Im Allgemeinen wird die Hash-Modul-Segmentierungsmethode verwendet. Beispielsweise wird die Tabelle „Customer“ gemäß dem Feld „cusno“ in 4 Datenbanken segmentiert. Die Daten mit einem Rest von 0 werden in die erste Datenbank gestellt, die Daten mit einem Rest von 1 in die zweite Datenbank und so weiter. Auf diese Weise werden die Daten desselben Benutzers in derselben Datenbank verstreut. Wenn die Abfragebedingung das Feld cusno enthält, kann die entsprechende Datenbank für die Abfrage eindeutig lokalisiert werden.

Vorteil:

• Die Datenverteilung ist relativ gleichmäßig, und es treten kaum Hotspots und Engpässe bei gleichzeitigem Zugriff auf.

Mangel:

• Wenn der Sharded-Cluster später erweitert wird, müssen die alten Daten migriert werden (dieses Problem lässt sich durch die Verwendung eines konsistenten Hash-Algorithmus besser vermeiden).
• Es ist leicht, mit dem komplexen Problem von Cross-Shard-Abfragen konfrontiert zu werden. Wenn beispielsweise im obigen Beispiel die häufig verwendeten Abfragebedingungen nicht cusno enthalten, kann die Datenbank nicht gefunden werden. Daher müssen Abfragen an vier Datenbanken gleichzeitig initiiert, die Daten im Speicher zusammengeführt und der Mindestsatz an die Anwendung zurückgegeben werden. Das Datenbank-Sharding wird zur Belastung.

Oben finden Sie Einzelheiten zur Datensegmentierung durch Sharding von MySQL-Tabellen und -Datenbanken. Weitere Informationen zur Datensegmentierung durch Sharding von MySQL-Tabellen und -Datenbanken finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!