Isolatieniveaus (WriteSerializable en Serializable)

Delta Lake in Azure Databricks ondersteunt twee isolatieniveaus waarmee wordt bepaald hoe gelijktijdige bewerkingen in een bepaalde tabel werken:

Wanneer u het isolatieniveau wijzigt

Houd het standaard WriteSerializable isolatieniveau voor de meeste workloads.

Met WriteSerializable kan een DELETE, UPDATE, of MERGE die begint vóór een gelijktijdige insert nog steeds daarna committen. De rijen van de insert worden niet beïnvloed, zelfs als ze overeenkomen met de voorwaarde van de operatie. De tabelgeschiedenis vermeldt nog steeds de insert als eerste, dus de tabelinhoud komt niet overeen met het resultaat van het opnieuw afspelen van de commits in geschiedenisvolgorde. Zie voorbeeld: gelijktijdig verwijderen en invoegen.

Verander een tabel naar Serializable als je werklast dit resultaat niet aankan. Bijvoorbeeld, als een DELETE elke overeenkomende rij die bestaat op het moment dat deze commit wordt vastgelegd moet verwijderen, of als downstream-processen de tabelinhoud reconstrueren uit de commitvolgorde in de geschiedenis. Met Serializable mislukt de latere operatie door een conflict, en moet je het opnieuw proberen.

Serializable vermindert de doorvoer voor gelijktijdige schrijfopdrachten. Toevoegingen die de tabel niet lezen, conflicteren nooit onder WriteSerializable, maar kunnen wel conflicteren onder Serializable. Zie concurrentie op rijniveau.

Hoe isolatieniveaus van invloed zijn op leesbewerkingen

Leesbewerkingen maken altijd gebruik van isolatie van momentopnamen. Het isolatieniveau voor schrijven bepaalt of een lezer een momentopname van een tabel kan zien die volgens de geschiedenis nooit bestond.

• Serializeerbaar: Een lezer ziet altijd alleen tabellen die voldoen aan de geschiedenis
• WriteSerializable: een lezer kan een tabelstatus zien die niet bestaat in het Delta-logboek

Voorbeeld: Gelijktijdig verwijderen en invoegen

Overweeg een scenario waarin een langlopende verwijdertransactie en een invoegtransactie tegelijkertijd beginnen en de versie v0 lezen. De invoertransactie wordt eerst vastgelegd en creëert versie v1. Daarna probeert de verwijdertransactie het volgende door te voeren v2:

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

In dit scenario heeft deleteTxn de door insertTxn ingevoegde gegevens niet gezien en heeft hij ze niet verwijderd:

• Serializable: deleteTxn kan niet worden gecomiteerd en er ontstaat een conflict.
• WriteSerializable: deleteTxn mag commiteren omdat de transacties kunnen worden geordend. De resulterende tabelstatus is alsof insertTxn heeft plaatsgevonden na deleteTxn, zodat de ingevoegde rijen deel uitmaken van de tabel. In de Delta-geschiedenis wordt echter de fysieke doorvoervolgorde (insertTxn v1 vóór deleteTxn v2) weergegeven.

Het isolatieniveau instellen

Om het isolatieniveau in te stellen, gebruik je het ALTER TABLE commando:

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

Waar <level-name> is Serializable of WriteSerializable.

Voorbeeld:

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

Wanneer voert Delta Lake een commit uit zonder de tabel te lezen?

Delta Lake- INSERT of append-bewerkingen lezen de tabelstatus niet voordat de commit plaatsvindt, als aan deze voorwaarden is voldaan:

1. Logica wordt uitgedrukt met behulp van INSERT SQL-logica of toevoegmodus
2. Logica bevat geen subquery's of voorwaarden die verwijzen naar de tabel waarop de schrijfbewerking is gericht

Net als bij andere doorvoeringen gebruikt Delta Lake metagegevens van transactielogboeken om tabelversies bij doorvoer te valideren en op te lossen, maar er wordt geen versie van de tabel daadwerkelijk gelezen.

Aanvullende informatiebronnen

• Rijniveau-concurrentie
• Transacties
• Isolatieniveaus en schrijfconflicten