Partitionstabelle der MySQL-Sharding-Partitionsdatenbank

Nachdem die Datenmenge in der Datenbank ein bestimmtes Niveau erreicht hat, um Engpässe bei der Systemleistung zu vermeiden. Daten müssen mithilfe von Partitionierung, Sharding, Datenbanken und Tabellen verarbeitet werden.

Empfohlener Kurs: MySQL-Tutorial.

Sharding (ähnlich wie Sharding)

Sharding ist die Skalierung der Datenbank auf mehrere physische Knoten. Es ist eine effektive Möglichkeit, Sein Hauptzweck besteht darin, die E/A-Kapazitätsbeschränkungen eines Einzelknoten-Datenbankservers zu durchbrechen und das Problem der Datenbankskalierbarkeit zu lösen. Das Wort Shard bedeutet „Fragment“. Wenn eine Datenbank als großes Stück Glas behandelt wird und das Glas zerbricht, dann wird jedes kleine Stück als Fragment der Datenbank (Datenbank-Shard) bezeichnet. Der Vorgang, bei dem die gesamte Datenbank in Teile zerlegt wird, wird als Sharding bezeichnet und kann mit „Sharding“ übersetzt werden.

Formal lässt sich Sharding einfach als Partitionierungsschema definieren, das eine große Datenbank auf mehrere physische Knoten verteilt. Jede Partition enthält einen bestimmten Teil der Datenbank, der als Slice bezeichnet wird. Die Partitionierungsmethode kann beliebig sein und ist nicht auf die herkömmliche horizontale und vertikale Partitionierung beschränkt. Ein Shard kann den Inhalt mehrerer Tabellen oder sogar mehrerer Datenbankinstanzen enthalten. Jeder Shard wird auf einem Datenbankserver platziert. Ein Datenbankserver kann einen oder mehrere Daten-Shards verarbeiten. Für die Abfrageweiterleitung und -weiterleitung ist im System ein Server erforderlich, der für die Weiterleitung der Abfrage an den Shard oder Shard-Sammelknoten verantwortlich ist, der die Daten enthält, auf die die Abfrage zur Ausführung zugreift.

Scale Out/Scale Up und vertikale Aufteilung/horizontale Aufteilung

Zu den Erweiterungslösungen von MySQL gehören Scale Out und Scale Up.

Scale Out (horizontale Erweiterung) bedeutet, dass die Anwendung in horizontaler Richtung erweitert werden kann. Im Allgemeinen bedeutet Scale-out für Rechenzentrumsanwendungen, dass die Anwendung die Ressourcen dieser Maschinen immer noch sinnvoll nutzen kann, wenn weitere Maschinen hinzugefügt werden, um ihre eigene Effizienz zu verbessern und eine gute Skalierbarkeit zu erreichen.

Scale Up (vertikale Erweiterung) bedeutet, dass die Anwendung in vertikaler Richtung erweitert werden kann. Im Allgemeinen lohnt sich die Skalierung für eine einzelne Maschine, wenn ein Rechenknoten (eine Maschine) mehr CPU-Kerne und Speichergeräte hinzufügt und größeren Speicher verwendet. Dadurch kann die Anwendung diese Ressourcen vollständig nutzen gute Skalierbarkeit.

Die Sharding-Strategie von MySQL umfasst vertikales Sharding und horizontales Sharding.

Vertikale (vertikale) Aufteilung: Bezieht sich auf die Aufteilung nach Funktionsmodulen, um den IO-Wettbewerb zwischen Tabellen zu lösen. Es ist beispielsweise in Bestelldatenbank, Produktdatenbank, Benutzerdatenbank usw. unterteilt. Auf diese Weise sind die Tabellenstrukturen mehrerer Datenbanken unterschiedlich.

Horizontale (horizontale) Aufteilung: Speichern Sie die Daten derselben Tabelle in Blöcken und speichern Sie sie in verschiedenen Datenbanken, um den Druck des zunehmenden Datenvolumens in einer einzelnen Tabelle zu lösen. Die Tabellenstrukturen in diesen Datenbanken sind genau gleich.

Die Tischstruktur ist so konzipiert, dass sie vertikal geteilt werden kann. Einige häufige Szenarien umfassen

a). Vertikale Segmentierung großer Felder. Bauen Sie große Felder separat in einer anderen Tabelle auf, um die Zugriffsleistung der Basistabelle zu verbessern. Grundsätzlich sollten große Felder in der Datenbank in leistungskritischen Anwendungen vermieden werden

b). Beispielsweise können Unternehmensmaterialattribute vertikal nach Basisattributen, Verkaufsattributen, Einkaufsattributen, Fertigungsattributen, Finanzbuchhaltungsattributen usw. segmentiert werden.

c) Vertikal segmentiert nach Zugriffshäufigkeit. Wenn beispielsweise in E-Commerce- und Web 2.0-Systemen viele Benutzerattributeinstellungen vorhanden sind, können grundlegende, häufig verwendete Attribute und selten verwendete Attribute vertikal unterteilt werden

und das Tabellenstrukturdesign kann horizontal unterteilt werden . Einige häufige Szenarien umfassen

a). Auf einer Online-E-Commerce-Website ist beispielsweise die Menge der Bestelltabellendaten zu groß und wird in jährliche und monatliche Ebenen unterteilt.

b) . Registrierte Web 2.0-Website-Benutzer, online Es gibt zu viele aktive Benutzer, segmentieren Sie horizontal die relevanten Benutzer und die Tabellen, die eng mit dem Benutzer verbunden sind

c). Der oberste Beitrag des Forums, da es sich um Seitenprobleme handelt, ist es notwendig, den angehefteten Beitrag anzuzeigen. In diesem Fall kann der angeheftete Beitrag horizontal geteilt werden, um beim Abrufen des angehefteten Beitrags das Lesen aus der Tabelle aller Beiträge zu vermeiden. 🎜>Oberflächlich betrachtet bedeutet Tabellenaufteilung die Aufteilung einer Tabelle in mehrere kleine Tabellen, während Partitionierung die Aufteilung der Daten einer Tabelle in N Blöcke bedeutet. Diese Blöcke können sich auf derselben Festplatte oder auf verschiedenen Festplatten befinden.

Der Unterschied zwischen geteilten Tabellen und Partitionen

1. In Bezug auf die Implementierung

Mysqls geteilte Tabellen sind echte geteilte Tabellen Jede kleine Tabelle ist eine vollständige Tabelle und entspricht drei Dateien (MyISAM-Engine: eine .MYD-Datendatei, eine .MYI-Indexdatei und eine .frm-Tabellenstrukturdatei).

2. In Bezug auf die Datenverarbeitung

Nachdem die Tabelle geteilt wurde, werden die Daten in der Tabelle gespeichert, und der Datenzugriff erfolgt in jeder Tabelle. Bei der Partitionierung gibt es kein Konzept der Tabellenpartitionierung. Die Partitionstabelle ist immer noch eine Tabelle und die Datenverarbeitung wird immer noch von selbst abgeschlossen.

3. Verbesserung der Leistung

Nach der Aufteilung der Tabellen wurde die Parallelitätsfähigkeit einer einzelnen Tabelle verbessert und auch die Festplatten-E/A-Leistung wurde verbessert. Die Partition durchbricht den E/A-Engpass der Festplatte und ich möchte die Lese- und Schreibfähigkeiten der Festplatte verbessern, um die MySQL-Leistung zu erhöhen.

Zu diesem Zeitpunkt liegt der Testschwerpunkt von Partitionen und Untertabellen darin, wie die MySQL-Parallelität beim Zugriff auf Daten und Partitionen verbessert werden kann und wie die Lese- und Schreibfunktionen der Festplatte durchbrochen werden können Dadurch wird die Leistung von MySQL verbessert.

4. Was den Schwierigkeitsgrad der Implementierung betrifft,

Es gibt viele Möglichkeiten, Tabellen zu teilen. Die Verwendung von Merge zum Teilen von Tabellen ist die einfachste. Diese Methode ist ungefähr so ​​einfach wie das Partitionieren und kann für den Programmcode transparent sein. Wenn Sie andere Tabellenpartitionierungsmethoden verwenden, ist dies problematischer als die Partitionierung. Die Implementierung der Partitionierung ist relativ einfach. Das Erstellen einer partitionierten Tabelle unterscheidet sich nicht vom Erstellen einer gewöhnlichen Tabelle und ist für die Codeseite transparent.

Anwendbare Szenarien für die Partitionierung

1. Die Abfragegeschwindigkeit einer Tabelle ist so langsam geworden, dass sie ihre Verwendung beeinträchtigt.

2. Die Daten in der Tabelle sind segmentiert

3. Datenoperationen betreffen oft nur einen Teil der Daten, nicht alle Daten

CREATE TABLE sales (

    id INT AUTO_INCREMENT,

    amount DOUBLE NOT NULL,

    order_day DATETIME NOT NULL,

    PRIMARY KEY(id, order_day)

) ENGINE=Innodb

PARTITION BY RANGE(YEAR(order_day)) (

    PARTITION p_2010 VALUES LESS THAN (2010),

    PARTITION p_2011 VALUES LESS THAN (2011),

    PARTITION p_2012 VALUES LESS THAN (2012),

PARTITION p_catchall VALUES LESS THAN MAXVALUE);

Anwendbarkeit von Untertabellenszenarien

1. Die Abfragegeschwindigkeit einer Tabelle ist so langsam geworden, dass sie ihre Verwendung beeinträchtigt.

2. Bei häufigem Einfügen oder gemeinsamem Abfragen verlangsamt sich die Geschwindigkeit.

Die Implementierung von Untertabellen erfordert eine Kombination aus Geschäftsimplementierung und Migration, was relativ komplex ist.

Untertabelle und Unterdatenbank

Untertabellen können das Problem der verringerten Abfrageeffizienz, die durch übermäßiges Datenvolumen in einer einzelnen Tabelle verursacht wird, lösen, aber nicht verbessern Die Parallelität der Datenbankverarbeitungsfunktionen bringt eine qualitative Verbesserung. Angesichts des stark gleichzeitigen Lese- und Schreibzugriffs ist es sinnlos, den Slave-Server zu erweitern, wenn der Datenbank-Masterserver dem Druck von Schreibvorgängen nicht standhalten kann. Daher müssen wir unsere Denkweise ändern und die Datenbank aufteilen, um die Schreibfähigkeit der Datenbank zu verbessern. Dies ist die sogenannte Unterdatenbank.

Ähnlich wie bei der Table-Sharding-Strategie kann beim Sharding ein Schlüsselwort-Modulo verwendet werden, um den Datenzugriff weiterzuleiten.

Das obige ist der detaillierte Inhalt vonPartitionstabelle der MySQL-Sharding-Partitionsdatenbank. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!