Delen via

Isolatieniveaus (WriteSerializable en Serializable)

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

Isolatieniveau Beschrijving
Serializerbaar Het sterkste isolatieniveau. Zorgt ervoor dat vastgelegde schrijfbewerkingen en alle leesbewerkingen serializeerbaar zijn. Bewerkingen zijn toegestaan zolang er een seriële reeks is die, wanneer één voor één wordt uitgevoerd, hetzelfde resultaat genereert als in de tabel. Voor schrijfbewerkingen is deze seriële reeks hetzelfde als de volgorde die wordt weergegeven in de geschiedenis van de tabel.
WriteSerializable (standaard) Een zwakker isolatieniveau dan Serializeerbaar. Zorgt ervoor dat alleen schrijfbewerkingen (geen leesbewerkingen) serialiseerbaar zijn. Dit is nog steeds sterker dan isolatie van momentopnamen . Biedt een goede balans tussen gegevensconsistentie en beschikbaarheid voor de meest voorkomende bewerkingen.

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

Stel het isolatieniveau in met behulp van de ALTER TABLE opdracht:

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 toevoegbewerkingen lezen de tabelstatus niet voordat ze worden doorgevoerd als aan de volgende voorwaarden wordt 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.

Opmerking

Veel veelvoorkomende patronen gebruiken MERGE bewerkingen om gegevens in te voegen op basis van tabelvoorwaarden. Hoewel het mogelijk is om deze logica opnieuw te schrijven met behulp van INSERT instructies, hebben deze instructies dezelfde gelijktijdigheidsbeperkingen als MERGEwanneer een voorwaardelijke expressie verwijst naar een kolom in de doeltabel.

Volgende stappen 

  • Last updated on