Condividi tramite

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.

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

Impostare il livello di isolamento usando 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 di Delta Lake o di accodamento non leggono lo stato della tabella prima di eseguire il commit se vengono soddisfatte le condizioni seguenti:

  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.

Passaggi successivi

  • Last updated on