Isolationsstufen (WriteSerializable und Serializable)

Delta Lake auf Azure Databricks unterstützt zwei Isolationsstufen, die steuern, wie gleichzeitige Vorgänge in einer bestimmten Tabelle interagieren:

Wann sollte die Isolationsstufe geändert werden

Behalten Sie für die meisten Workloads das Standard-Isolierungslevel WriteSerializable.

Mit WriteSerializable kann ein DELETE, UPDATE, oder MERGE das vor einem gleichzeitigen Insert beginnt, noch danach committen. Die Reihen aus dem Insert sind nicht betroffen, selbst wenn sie mit der Bedingung der Operation übereinstimmen. Die Tabellengeschichte listet immer noch zuerst den Insert auf, daher stimmen die Tabelleninhalte nicht mit dem Ergebnis überein, wenn man die Commits in der Reihenfolge erneut abspielt. Siehe Beispiel: Gleichzeitiges Löschen und Einfügen.

Ändere eine Tabelle auf Serializable, wenn der Workload dieses Resultat nicht akzeptieren kann. Zum Beispiel dann, wenn ein DELETE jede passende Zeile entfernen muss, die beim Commit existiert, oder wenn nachgelagerte Prozesse den Tabelleninhalt aus der Commit-Reihenfolge in der Historie rekonstruieren. Bei Serializable scheitert die spätere Operation stattdessen mit einem Konflikt, und du musst den Vorgang wiederholen.

Serialisierbar reduziert den Durchsatz für gleichzeitige Schreibvorgänge. Append-Operationen, die die Tabelle nicht lesen, stehen unter WriteSerializable niemals in Konflikt, können aber unter Serializable in Konflikt geraten. Siehe Zeilenebene-Konkurrenz.

Auswirkungen der Isolationsebenen auf Lesevorgänge

Für Lesevorgänge gilt stets die Momentaufnahmenisolation. Die Isolationsstufe für Schreibvorgänge legt fest, ob es einem Leser möglich ist, eine Momentaufnahme einer Tabelle zu sehen, die laut Verlauf „nie vorhanden war“.

• Serialisierbar: Ein Leser sieht immer nur Tabellen, die dem Verlauf entsprechen
• WriteSerializable: Ein Leser kann einen Tabellenstatus sehen, der im Delta-Protokoll nicht vorhanden ist.

Beispiel: Gleichzeitiges Löschen und Einfügen

Betrachten Sie ein Szenario, in dem eine lange Löschtransaktion und eine Insert-Transaktion gleichzeitig beginnen, und die Version v0 lesen. Die Einfügetransaktion wird zuerst abgeschlossen und erstellt die Version v1. Danach versucht die Löschtransaktion, einen Commit durchzuführen v2:

t0: deleteTxn_START
t1: insertTxn_START
t2: insertTxn_COMMIT(v1)
t3: deleteTxn_COMMIT(v2)

In diesem Szenario deleteTxn hat die von insertTxn eingefügten Daten nicht gesehen und nicht gelöscht:

• Serialisierbar: deleteTxn Es ist nicht zulässig, einen Commit auszuführen, ein Konflikt tritt auf
• WriteSerializable: deleteTxn ist für Commit zulässig, da die Transaktionen sortiert werden können. Der resultierende Tabellenstatus ist so, als sei insertTxn nach deleteTxn aufgetreten, sodass die eingefügten Zeilen Teil der Tabelle sind. Der Delta-Verlauf zeigt jedoch die physische Commitreihenfolge (insertTxn bei v1 vor deleteTxn bei v2).

Festlegen der Isolationsstufe

Um die Isolationsstufe einzustellen, verwenden Sie den Befehl ALTER TABLE :

ALTER TABLE <table-name> SET TBLPROPERTIES ('delta.isolationLevel' = <level-name>)

Wo <level-name> ist Serializable oder WriteSerializable.

Example:

-- Change from default WriteSerializable to Serializable
ALTER TABLE my_table SET TBLPROPERTIES ('delta.isolationLevel' = 'Serializable')

Wann führt Delta Lake ein Commit aus, ohne die Tabelle zu lesen?

Delta Lake INSERT oder Anfügevorgänge lesen den Tabellenzustand nicht vor dem Commit, wenn diese Bedingungen erfüllt sind:

1. Logik wird mithilfe der INSERT SQL-Logik oder des Anfügemodus ausgedrückt.
2. Logik enthält keine Unterabfragen oder Bedingungen, die auf die Tabelle verweisen, auf die der Schreibvorgang abzielt.

Wie bei anderen Commits verwendet Delta Lake Transaktionsprotokollmetadaten, um Tabellenversionen beim Commit zu überprüfen und aufzulösen, aber keine Version der Tabelle wird tatsächlich gelesen.

Weitere Ressourcen

• Zeilenebene-Row-level Nebenläufigkeit
• Transaktionen
• Isolationsstufen und Schreibkonflikte