Detaillierte Erklärung der GaussDB zur MySQL-Leistungsoptimierung

Hintergrund

Schauen wir uns zunächst den allgemeinen Prozess der Transaktionsübermittlung in MySQL 8.0 an

Der obige Prozess ist eine Implementierung des WAL-Prinzips in MySQL 8.0. Dieser Prozess bedeutet, dass bei der Übermittlung einer Transaktion der Schreibpuffer und die Leerung auf die Festplatte abgeschlossen werden müssen.

Bei diesem Prozess gibt es jedoch ein Problem: Die CPU jedes Servers ist begrenzt und auch die Anzahl der Threads, die der Server verarbeiten kann, ist begrenzt. Wenn also die Anzahl der gleichzeitigen Transaktionen in unserem Unternehmen viel größer ist als die Anzahl, die unser Server parallel verarbeiten kann, können die nachfolgenden Transaktionen erst verarbeitet werden, nachdem die vorherigen Transaktionen übermittelt wurden. Vorher konnten sie nichts tun. Daher ist in Szenarien mit hoher Parallelität die weitere Verbesserung der Thread-Auslastung der Schlüssel zum Schreiben von Transaktionen mit hoher Parallelität.

Inspiration kommt aus dem Leben

Eine Optimierung ist keine Erfindung der Welt, sondern entspringt oft der Realität. Schauen wir uns als Nächstes ein Beispiel aus unserem Umfeld an, das dem Transaktionsübermittlungsprozess sehr ähnlich ist: die Expresslieferung.

Bei der heutigen Expresszustellung ist im Allgemeinen ein Kurier für ein Gebiet zuständig. Als Expresszustellungen erstmals populär wurden, war die Menge gering, sodass ein Kurier die Zustellung im Grunde innerhalb der angegebenen Zeit erledigen konnte.

Da jedoch die Zahl der Expresslieferungen zunimmt, muss ein Kurier viel Zeit damit verbringen, in einer Gemeinde zuzustellen, bevor er die nächste Gemeinde erreicht, was häufig dazu führt, dass der Kurier seine Lieferung nicht rechtzeitig einhalten kann. Aufgrund dieses Problems begann eine neue Branche zu entstehen: Express-Lieferstationen.

Optimierungsprinzipien der Expresslieferung

Schauen wir uns als nächstes an, welche Probleme die Express-Lieferstation tatsächlich löst.

Der zeitaufwendigste Teil einer Expresslieferung ist nicht das Be- und Entladen, sondern das Telefonieren und Warten. Die Lieferzeit in eine Gemeinde hängt von der Zeit ab, zu der die letzte Person das Paket abholt. Nachdem die letzte Person das Geld abgeholt hat, kann der Kurier nichts weiter tun, als anzurufen (es gibt keine Möglichkeit, die Leute in der nächsten Gemeinde zu benachrichtigen, da die Zeit, zu der die letzte Person das Paket abholt, ungewiss ist). Dann ist diese Wartezeit für den Kurier eine Verschwendung.

Express-Lieferstationen können dieses Problem weitgehend lösen. Nachdem der Kurier angekommen ist, muss er nur noch den Express ausladen und zur nächsten Gemeinde fahren. Den Rest der Arbeit kann das Stationspersonal erledigen, was die Liefereffizienz des Kuriers erheblich verbessert.

analysieren

Zurück zur Datenbank: Wenn wir den Transaktionsthread als Kurier und die Datei im Speicher als die Person betrachten, die den Kurier abholt, werden wir feststellen, dass die beiden sehr ähnlich sind. Können wir also den Transaktionsverarbeitungsprozess so optimieren, wie wir die Expresslieferung optimieren? Die Antwort ist ja.

Gemäß dem Optimierungsprinzip von Express-Lieferstationen wissen wir, dass Express-Lieferstationen den Kurieren die Wartezeit ersparen, bis die Kunden die Waren abholen. Gibt es also im Transaktionsverarbeitungsprozess einen Warteprozess? Die Antwort ist ja. Bei der Speicher-E/A ist die Wartezeit länger. Entwickler mit umfassender Erfahrung in der Verwendung von Datenbanken wissen alle, dass die Schreibleistung der Datenbank weitgehend von der Festplatten-E/A-Leistung beim Warten auf das Schreiben von Redo-Protokollen in den Speicher abhängt. Bei modernen Datenbanken, insbesondere bei Datenbanken wie GaussDB (für MySQL), die Datenverarbeitung und Speicherung trennen, macht die Speicher-IO-Zeit einen großen Teil der gesamten Transaktionsverarbeitungszeit aus. Obwohl das Zusammenführen von Schreibvorgängen im Protokollpuffer den Gesamtdurchsatz in gleichzeitigen Situationen verbessern kann, wenn diese Threads während der Wartezeit für IO andere Dinge tun können (z. B. andere wartende Transaktionen verarbeiten). Dann wird es noch weitere Leistungsverbesserungen geben.

Optimierung von GaussDB (für MySQL)

Nachdem wir nun den Wartepunkt gefunden haben, können wir, genau wie bei der Optimierungsmethode für Expresslieferungen, eine „Expresslieferstation“ für die Datenbank erstellen und die „Expresslieferstation“ das Warten übernehmen lassen, während der Transaktionsthread andere wartende Transaktionen verarbeiten kann, sodass die CPU nicht „im Leerlauf“ ist.

Wie in Abbildung 5 dargestellt, kann GaussDB (für MySQL) eine Transaktion festschreiben, nachdem die Aktion „Auf Festplatte leeren“ des Redo-Logs abgeschlossen ist. Allerdings antwortet es zu diesem Zeitpunkt nicht auf den Client, sondern verarbeitet direkt die nächste Transaktion. Gleichzeitig wird eine kleine Anzahl von „Post-Commit-Worker-Threads“ verwendet, um auf den Abschluss des Protokollschreibens in Stapeln zu warten (der Wartevorgang belegt die CPU nicht wirklich) und dem Client zu antworten. Dadurch können das „Warten“ und die „Verarbeitung der nächsten Transaktion“ parallelisiert werden, wodurch die CPU „beschäftigt“ bleibt.

Tatsächlicher Test

Laut tatsächlichen Tests beträgt die maximale Leistung beim Standard-Sysbench-Schreibmodell ohne Verwendung von Post Commit etwa 350.000 QPS. Nach Verwendung von Post Commit können die QPS über 420.000 erreichen, was die Schreibleistung um 20 % verbessert.

Oben finden Sie eine ausführliche Erläuterung der Leistungsoptimierung von GaussDB für MySQL. Weitere Informationen zur Leistungsoptimierung von GaussDB für MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!