Livelli di isolamento (WriteSerializable e Serializable)

Delta Lake in Azure Databricks supporta due livelli di isolamento che controllano il modo in cui interagiscono le operazioni simultanee in una determinata tabella:

Livello di isolamento Descrizione
Serializzabile Livello di isolamento più forte. Assicura che le operazioni di scrittura di cui è stato eseguito il commit e che tutte le letture siano serializzabili. Le operazioni sono consentite finché è presente una sequenza seriale che, quando viene eseguita una alla volta, genera lo stesso risultato visualizzato nella tabella. Per le operazioni di scrittura, questa sequenza seriale corrisponde all'ordine visualizzato nella cronologia della tabella.
WriteSerializable (impostazione predefinita) Livello di isolamento più debole rispetto a Serializzabile. Assicura che solo le operazioni di scrittura (non le letture) siano serializzabili. Questo è ancora più forte rispetto all'isolamento dello snapshot . Offre un buon equilibrio tra coerenza e disponibilità dei dati per le operazioni più comuni.

Quando cambiare il livello di isolamento

Mantieni il livello di isolamento predefinito di WriteSerializable per la maggior parte dei carichi di lavoro.

Con WriteSerializable, un DELETE, UPDATE o MERGE che inizia prima di un inserimento concorrente può comunque eseguire il commit dopo di esso. Le righe inserite non sono interessate, anche se corrispondono alla condizione dell'operazione. La cronologia della tabella elenca ancora l'inserimento per primo, quindi il contenuto della tabella non corrisponde al risultato della riproduzione dei commit in ordine storico. Vedi esempio: cancellazione e inserimento simultaneo.

Cambia una tabella in Serializzabile se il tuo carico di lavoro non può accettare questo risultato. Ad esempio, se DELETE deve rimuovere ogni riga corrispondente esistente al momento del commit, o se i processi a valle ricostruiscono il contenuto della tabella dall'ordine di commit nella cronologia. Con Serializable, l'operazione successiva fallisce con un conflitto e devi riprovarla.

Serializable riduce il throughput per le scritture concorrenti. Gli append che non leggono la tabella non entrano mai in conflitto con WriteSerializable ma possono entrare in conflitto con Serializable. Consulta Concorrenza a livello di riga.

Impatto dei livelli di isolamento sulle letture

Le operazioni di lettura usano sempre l'isolamento dello snapshot. Il livello di isolamento della scrittura determina se un lettore può visualizzare uno snapshot di una tabella che, in base alla cronologia, "non sia mai esistito".

  • Serializzabile: un lettore vede sempre solo le tabelle conformi alla cronologia
  • WriteSerializable: un lettore può visualizzare uno stato di tabella che non esiste nel log Delta

Esempio: eliminazione e inserimento simultanei

Si consideri uno scenario in cui una lunga transazione di eliminazione e una transazione di inserimento iniziano contemporaneamente e leggono la versione v0 di lettura. La transazione di inserimento esegue prima il commit e crea la versione v1. Successivamente, la transazione di eliminazione tenta di eseguire il commit di v2.

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

In questo scenario, deleteTxn non ha visto i dati inseriti da insertTxn e non li ha eliminati:

  • Serializzabile: deleteTxn non è consentito eseguire il commit e si verifica un conflitto
  • WriteSerializable: deleteTxn è possibile eseguire il commit perché le transazioni possono essere ordinate. Lo stato della tabella risultante è come se insertTxn si verificasse dopo deleteTxn, quindi le righe inserite fanno parte della tabella. Tuttavia, la storia del Delta mostra l'ordine fisico del commit (insertTxn nella versione 1 prima di deleteTxn nella versione 2).

Impostare il livello di isolamento

Per impostare il livello di isolamento, usa il ALTER TABLE comando:

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

Dove <level-name> è Serializable o WriteSerializable.

Esempio:

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

Quando viene eseguito il commit di Delta Lake senza leggere la tabella?

Le operazioni Delta Lake INSERT o append non leggono lo stato della tabella prima di effettuare il commit se queste condizioni sono soddisfatte:

  1. La logica viene espressa usando la INSERT logica SQL o la modalità di appendice
  2. La logica non contiene sottoquery o condizionali che fanno riferimento alla tabella di destinazione dell'operazione di scrittura

Come per altri commit, Delta Lake usa i metadati del log delle transazioni per convalidare e risolvere le versioni delle tabelle al commit, ma non viene effettivamente letta alcuna versione della tabella.

Annotazioni

Molti modelli comuni usano operazioni MERGE per inserire dati in base alle condizioni della tabella. Sebbene sia possibile riscrivere questa logica usando istruzioni INSERT, se un'espressione condizionale fa riferimento a una colonna nella tabella di destinazione, queste istruzioni presentano le stesse limitazioni di concorrenza di MERGE.

Risorse aggiuntive

  • Ultimo aggiornamento: