Detaillierte Erläuterung der Multiversion-Parallelitätskontrolle großer Objekte in MySQL

MySQL 8.0: MVCC für große Objekte in InnoDB

In diesem Artikel erkläre ich das Multi-Version Concurrency Control (MVCC)-Design für große Objekte (LOBs) in der MySQL InnoDB-Speicher-Engine. MySQL 8.0 verfügt über eine neue Funktion, die es Benutzern ermöglicht, große Objekte, einschließlich JSON-Dokumente, teilweise zu aktualisieren. Mit dieser Funktion zur teilweisen Aktualisierung hat sich die Funktionsweise von MVCC für LOBs geändert, wenn ein LOB teilweise aktualisiert wird. Bei normalen Updates (vollständigen Updates) funktioniert MVCC genauso wie frühere Versionen. Sehen wir uns an, wie MVCC funktioniert, wenn keine Teilaktualisierungen erforderlich sind, und betrachten wir dann den Anwendungsfall von Teilaktualisierungen für LOBs.

MVCC – Allgemeine Updates

Mit dem Begriff „regelmäßige Updates“ bezeichne ich Updates, bei denen es sich nicht um Teilupdates handelt. Ich werde anhand eines Beispiels erklären, wie MVCC zum routinemäßigen Aktualisieren großer Objekte verwendet werden kann. Ich werde zu diesem Zweck den folgenden mtr(1)-Testfall verwenden:

 Erstellen Sie Tabelle t1 (f1 int Primärschlüssel, f2 Longblob) Engine = innodb; 
 in t1-Werte einfügen (1, Wiederholung (‚a‘, 65536)); 
 
 Transaktion starten; 
 Aktualisiere t1, setze f2 = wiederhole (‚b‘, 65536), wobei f1 = 1; 
 
 -- echo # Verbindung con1: 
 -- Benutzer, die den MySQL-Client verwenden, müssen möglicherweise eine neue Verknüpfung herstellen, indem sie ein weiteres Terminalfenster öffnen (siehe unten).
 verbinden (con1, localhost, root, , ); 
 -- echo # Muss den alten Wert 'aaaaaaaaaaa' sehen 
 Wähle f1, rechts (f2, 10) von t1, sortiere nach f1; 
 
 -- echo # Verbindungsstandard: 
 Verbindungsstandard; 
 con1 trennen; 
 begehen ; 
 
 Tabelle t1 löschen;

Um die folgende Erklärung zu verstehen, ist es sehr wichtig, den obigen Testfall sorgfältig zu verstehen.

Das Testszenario sieht wie folgt aus:

Anfangs enthält Tabelle t1 einen einzelnen Datensatz (R1).
Die Transaktion trx1 aktualisiert den Datensatz auf den neuen Wert.
Während trx1 noch aktiv ist, liest eine andere Transaktion, trx2, die Datensätze. Es wird der alte Wert gelesen.

Tabelle t1 enthält nur einen Datensatz (R1). Aber trx1 und trx2 sehen zwei unterschiedliche Werte. Die Tabelle enthält tatsächlich nur die neuesten Werte (die von trx1 gesehenen Werte), während die von trx2 gesehenen Werte oder Datensätze aus den Undo-Log-Datensätzen abgerufen werden. Schauen wir uns das Bild unten an, um es besser zu verstehen.

Ausgangszustand: vor dem Updatevorgang

Die folgende Abbildung zeigt die Situation vor dem Update-Vorgang. Das Undo-Protokoll ist leer. Der gruppierte Index einer Tabelle enthält eine Zeile. In der Tabelle befindet sich ein LOB. Der gruppierte Indexdatensatz enthält einen Verweis auf das LOB.

Endzustand: Nach dem Updatevorgang

Sehen wir uns nun an, was nach dem Aktualisierungsvorgang passiert.

Hier sind einige wichtige Beobachtungen:

Es gibt zwei LOBs im Benutzertabellenbereich – altes LOB und neues LOB. Auf alte LOBs kann nur über Undo-Protokolle zugegriffen werden. Der gruppierte Indexdatensatz verweist auf das neue LOB.
Der Aktualisierungsvorgang hat einen Undo-Log-Datensatz erstellt, der den Aktualisierungsvektor enthält. Dieser Undo-Log-Datensatz verweist auf das alte LOB.
Clustered-Index-Datensätze verweisen über die Systemspalte DB_ROLL_PTR auf Undo-Log-Datensätze. Dieser Rollzeiger verweist auf einen Undo-Log-Datensatz, der zum Erstellen einer vorherigen Version des gruppierten Indexdatensatzes verwendet werden kann.
Undo-Datensätze enthalten nicht das LOB selbst. Stattdessen enthält es nur Verweise auf LOBs, die im Benutzertabellenbereich gespeichert sind.
Die in Undo-Log-Datensätzen gespeicherten LOB-Referenzen unterscheiden sich von den in Clustered-Index-Datensätzen gespeicherten LOB-Referenzen.

Die von der Transaktion in Verbindung 1 ausgeführten Schritte sind wie folgt:

Die Transaktion prüft R1 und stellt fest, dass keine Transaktion festgeschrieben wurde, die den gruppierten Indexdatensatz geändert hat. Dies bedeutet, dass der Datensatz nicht gelesen werden kann (da die Standardisolationsebene „REPEATABLE READ“ ist).
Es untersucht den DB_ROLL_PTR in R1 und findet den Undo-Log-Datensatz. Erstellen Sie die vorherige Version von R1 mithilfe der Undo-Protokollierung.
Es liest das ältere R1 für diesen Build. Beachten Sie, dass diese Version in gruppierten Indexdatensätzen nicht verfügbar ist. Es wird jedoch spontan unter Verwendung von Undo-Datensätzen erstellt.
Während R1 auf das neue LOB verweist, verweist die alte Version von R1 auf das alte LOB. Das Ergebnis enthält also das alte LOB.

So funktioniert MVCC für LOBs, wenn keine teilweisen Aktualisierungen erforderlich sind.

MVCC Teilaktualisierung

Sehen wir uns ein weiteres Beispiel an, um zu verstehen, wie MVCC bei teilweisen Aktualisierungen funktioniert. Wir benötigen ein weiteres Beispiel, da die teilweise Aktualisierung von JSON-Dokumenten derzeit nur durch die Funktionen json_set() und json_replace() unterstützt wird.

 Tabelle t2 erstellen (f1 int Primärschlüssel, j json) Engine = InnoDB; 
 setze @elem_a = concat('"', wiederhole('a', 200), '"'); 
 setze @elem_a_with_coma = concat ( @ elem_a , ',' ) ; 
 setze @json_doc = concat ( "[", wiederhole ( @elem_a_with_coma , 300 ), @elem_a , "]" ); 
 
 in t2(f1, j) Werte (1, @json_doc) einfügen; 
 
 Transaktion starten; 
 Aktualisiere t2, setze j = json_set (j, „$[200]“, wiederhole („b“, 200)), wobei f1 = 1; 
 
 -- echo # Verbindung con1: 
 verbinden (con1, localhost, root, , ); 
 -- echo # Muss den alten Wert „aaaaaaaaaaa…“ sehen 
 wähle json_extract (j, '$[200]') aus t2; 
 
 -- echo # Verbindungsstandard: 
 Verbindungsstandard; 
 con1 trennen; 
 begehen ;

Das Szenario ist das gleiche wie im vorherigen Beispiel. Nur das Longblob-Feld wurde in ein JSON-Dokument geändert. Die geladenen Daten unterscheiden sich ebenfalls geringfügig, um dem JSON-Format zu entsprechen.

Tipp: Sie können den obigen MTR-Testfällen (in beiden) die Anweisung „set debug = '+d, innodb_lob_print'“ hinzufügen, um die LOB-Indizes in der Server-Protokolldatei auszudrucken. Der LOB-Index wird sofort nach dem Einfügen ausgedruckt. Der LOB-Index gibt Ihnen die Struktur des gespeicherten LOB-Objekts.
Vor einem teilweisen Aktualisierungsvorgang

Die Anfangsbedingungen vor der vollständigen oder teilweisen Aktualisierung sind dieselben und wurden oben angegeben. In der folgenden Abbildung werden jedoch einige zusätzliche Informationen bereitgestellt.

Schauen wir uns einige weitere in der Grafik dargestellte Informationen an:

Die im gruppierten Indexdatensatz gespeicherte LOB-Referenz enthält jetzt die LOB-Versionsnummer v1. Während des ersten Einfügevorgangs wird der Wert auf 1 gesetzt und bei jeder Teilaktualisierung erhöht.
Jede LOB-Datenseite hat einen Eintrag im LOB-Index. Jeder Eintrag enthält LOB-Versionsinformationen. Wenn eine LOB-Datenseite geändert wird, wird sie mit den neuen Daten auf eine neue LOB-Datenseite kopiert und ein neuer LOB-Indexeintrag mit einer erhöhten LOB-Versionsnummer erstellt.

Weitere Informationen sind die LOB-Versionsnummer. Dies ist in der LOB-Referenz im Clustered-Index-Datensatz und in jedem Eintrag des LOB-Index verfügbar.

Nach einem teilweisen Updatevorgang

Das folgende Diagramm veranschaulicht die Situation nach einem teilweisen Aktualisierungsvorgang.

Die wichtigste Optimierung besteht hierbei darin, dass sich im Benutzertabellenbereich weiterhin nur ein LOB befindet. Aktualisieren Sie nur die LOB-Datenseiten, die geändert werden müssen. Dieses einzelne LOB enthält nach dem teilweisen Aktualisierungsvorgang sowohl die alte als auch die neue Version des LOB. Dies wird durch die Beschriftungen v1 und v2 auf der LOB-Datenseite in der Abbildung veranschaulicht.

Eine weitere wichtige Beobachtung besteht darin, dass die LOB-Referenzen im Undo-Protokoll und in den Clustered-Index-Datensätzen auf dasselbe LOB verweisen. Die LOB-Referenz enthält jedoch eine andere Versionsnummer. Die LOB-Referenz im Undo-Log-Datensatz enthält v1 (die alte Versionsnummer) und die LOB-Referenz im Clustered-Index-Datensatz enthält die neue Versionsnummer v2.

Zweck der LOB-Versionsnummern

Wie oben gezeigt, verweisen verschiedene LOB-Referenzen mit unterschiedlichen Versionsnummern auf dasselbe LOB. Ein einzelnes LOB enthält Teile aus verschiedenen Versionen. Die LOB-Versionsnummer wird verwendet, um die richtige Version zu erhalten, auf die die verschiedenen LOB-Referenzen verweisen. In diesem Abschnitt sehen wir, wie das geht.

Ein LOB-Index enthält eine Liste von LOB-Seiten, aus denen ein LOB besteht. Es enthält die Seitennummer der LOB-Datenseite, die Datenmenge, die auf jeder LOB-Datenseite enthalten ist, und eine Versionsnummer. Jeder Knoten dieser Liste wird als LOB-Indexeintrag bezeichnet. Jeder LOB-Indexeintrag enthält eine Liste alter Versionen. Sehen wir uns ein Diagramm an, das die Struktur des obigen Testfalls für die teilweise Aktualisierung veranschaulicht.

Zunächst, also vor der teilweisen Aktualisierung, enthält der LOB-Index insgesamt 4 Einträge. Die Seitennummern der vier Einträge sind 5, 6, 7 und 8. Kein LOB-Indexeintrag hat eine alte Version. Alle vier Einträge haben die Versionsnummer 1.

Nachdem einige der Aktualisierungen abgeschlossen waren, stellten wir fest, dass Seite 9 Seite 7 ersetzt hatte und Seite 7 nun als ältere Version von Seite 9 galt. Seite 9 hat die Versionsnummer 2 und Seite 7 hat die Versionsnummer 1.

Wenn nach Abschluss der teilweisen Aktualisierung auf das LOB über eine LOB-Referenz mit der Versionsnummer 1 zugegriffen wird, wird der erste Indexeintrag auf Seite 5 betrachtet. Es hat die Versionsnummer 1. Wenn die Versionsnummer im Indexeintrag kleiner oder gleich der Versionsnummer in der LOB-Referenz ist, wird dieser Eintrag gelesen. Daher wird Seite 5 gelesen. Anschließend wird der Indexeintrag für Seite 6 angezeigt. Es hat die Versionsnummer 1 und wird daher gelesen. Anschließend wird der Indexeintrag für die Seitenzahl 9 angezeigt. Es hat die Versionsnummer 2. Aber die LOB-Referenz hat die Versionsnummer 1. Wenn die Versionsnummer im Indexeintrag größer ist als die Versionsnummer in der LOB-Referenz, wird der Eintrag nicht gelesen. Da der Eintrag auf Seite 9 die Version 2 hat, wird seine ältere Version angezeigt. Geprüft wird der Indexeintrag mit der Seitenzahl 7. Es hat die Versionsnummer 1 und wird daher gelesen. Anschließend wird der Indexeintrag mit der Seitennummer 8 geprüft. Es hat die Versionsnummer 1 und wird daher auch gelesen. So greifen Sie auf ältere LOBs zu.

Wenn nach Abschluss der teilweisen Aktualisierung auf das LOB über die LOB-Referenz mit der Versionsnummer 2 zugegriffen wird, wird der erste Indexeintrag auf Seite 5 betrachtet. Es hat die Versionsnummer 1. Wenn die Versionsnummer im Indexeintrag kleiner oder gleich der Versionsnummer in der LOB-Referenz ist, wird dieser Eintrag gelesen. Daher werden die Seitenzahlen 5, 6, 9 und 8 der Reihe nach gelesen. Da die Versionsnummer immer <= 2 ist, ist es nicht erforderlich, für den Zugriff auf die Seite mit der Nummer 7 eine ältere Version zu verwenden.

Denken Sie daran, dass LOBs in InnoDB nicht unabhängig voneinander existieren. Es wird als Erweiterung des gruppierten Indexdatensatzes betrachtet. Ob ein LOB für eine Transaktion sichtbar ist, wird nicht vom LOB-Modul geregelt. Das LOB-Modul verarbeitet nur gruppierte Indexdatensätze. Wenn eine Transaktion auf ein LOB zugreift, bedeutet dies, dass sie mit Hilfe der DB_TRX_ID im Clustered-Index-Datensatz ermittelt hat, dass sie sich das LOB (und nicht eine bestimmte Version des LOB) ansehen kann. Daher machen wir uns im LOB-Modul keine Gedanken über diesen Aspekt. Wir konzentrieren uns nur darauf, den richtigen Inhalt für eine bestimmte LOB-Versionsnummer bereitzustellen.

abschließend

In diesem Artikel haben wir gesehen, wie MVCC in InnoDB für große Objekte durchgeführt wird. Wenn ein LOB teilweise aktualisiert wird, können mehrere LOB-Referenzen auf dasselbe LOB verweisen. Sie werden jedoch unterschiedliche Versionsnummern haben. Mithilfe dieser LOB-Versionsnummern kann auf die richtigen LOB-Inhalte zugegriffen werden.

Ich hoffe, Sie fanden diese Informationen nützlich.

Vielen Dank für die Verwendung von MySQL!

Hinweise:

(1) Mtr ist die Abkürzung für Mini-Transaktion, was wörtlich „kleine Sache“ bedeutet. Verglichen mit logischen Dingen bezeichnen wir sie als physische Dinge. Gehört zum zugrunde liegenden Modul der Innodb-Speicher-Engine. Wird hauptsächlich zum Sperren und Protokollieren von Informationen verwendet.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.