Dela via

Isoleringsnivåer (WriteSerializable och Serializable)

Delta Lake på Azure Databricks stöder två isoleringsnivåer som styr hur samtidiga åtgärder i en viss tabell interagerar:

Isoleringsnivå Beskrivning
Serialiserbar Den starkaste isoleringsnivån. Säkerställer att de incheckade skrivåtgärderna och alla läsningar är Serializable. Åtgärder tillåts så länge det finns en seriesekvens som, när den körs en i taget, genererar samma resultat som i tabellen. För skrivåtgärder är den här seriesekvensen samma som den ordning som visas i tabellens historik.
WriteSerializable (standard) En svagare isoleringsnivå än Serializable. Säkerställer att endast skrivåtgärder (inte läsningar) är serialiserbara. Detta är fortfarande starkare än ögonblicksbildisolering . Ger en bra balans mellan datakonsekvens och tillgänglighet för de vanligaste åtgärderna.

Hur isoleringsnivåer påverkar läsoperationer

Läsåtgärder använder alltid ögonblicksbildisolering. Skrivisoleringsnivån avgör om en läsare kan se en ögonblicksbild av en tabell som enligt historiken "aldrig existerade".

  • Serialiserbar: En läsare ser alltid endast tabeller som överensstämmer med historiken
  • WriteSerializable: En läsare kan se ett tabelltillstånd som inte finns i Delta-loggen

Exempel: Samtidig borttagning och infoga

Tänk dig ett scenario där en tidskrävande borttagningstransaktion och en infogad transaktion startar samtidigt och läser version v0. Infogningstransaktionen begås först och skapar version v1. Därefter försöker borttagningstransaktionen att slutföra v2:

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

I det här scenariot deleteTxn såg du inte de data som infogades av insertTxn och tog inte bort dem:

  • Serialiserbar: deleteTxn tillåts inte att göra en commit och en konflikt uppstår
  • WriteSerializable: deleteTxn tillåts att begå eftersom transaktionerna kan ordnas. Det resulterande tabelltillståndet är som om insertTxn inträffade efter deleteTxn, så de infogade raderna är en del av tabellen. Deltahistoriken visar dock den fysiska kommitteringsordningen (insertTxn vid v1 före deleteTxn vid v2).

Ange isoleringsnivå

Ange isoleringsnivån med kommandot ALTER TABLE :

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

Var <level-name> är Serializable eller WriteSerializable.

Ett exempel:

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

När committerar Delta Lake utan att läsa tabellen?

Delta Lake INSERT eller tilläggsåtgärder läser inte tabelltillståndet innan de genomförs om följande villkor är uppfyllda:

  1. Logik uttrycks med SQL-logik INSERT eller tilläggsläge
  2. Logik innehåller inga underfrågor eller villkor som refererar till tabellen som skrivåtgärden riktar sig till

Precis som med andra incheckningar använder Delta Lake transaktionsloggmetadata för att verifiera och lösa tabellversioner vid incheckning, men ingen version av tabellen läses faktiskt.

Anmärkning

Många vanliga mönster använder MERGE åtgärder för att infoga data baserat på tabellvillkor. Även om det kan vara möjligt att skriva om den här logiken med hjälp av INSERT instruktioner, har dessa uttryck samma samtidighetsbegränsningar som MERGEom några villkorsuttryck refererar till en kolumn i måltabellen.

Nästa steg

  • Last updated on