Partilhar via

Níveis de isolamento (WriteSerializable e Serializable)

O Delta Lake no Azure Databricks suporta dois níveis de isolamento que controlam como as operações concorrentes numa dada tabela interagem:

Nível de isolamento Descrição
Serializável O nível de isolamento mais forte. Assegura que as operações de escrita confirmadas e todas as leituras serão serializáveis. As operações são permitidas desde que exista uma sequência serial que, quando executada uma de cada vez, gere o mesmo resultado visto na tabela. Para operações de escrita, esta sequência serial é a mesma que a ordem vista no histórico da tabela.
WriteSerializable (Padrão) Um nível de isolamento mais fraco do que o Serializable. Assegura que apenas as operações de escrita (não leituras) são serializáveis. Isto ainda é mais forte do que o isolamento Snapshot. Proporciona um bom equilíbrio entre consistência e disponibilidade de dados para a maioria das operações comuns.

Como os níveis de isolamento afetam as leituras

As operações de leitura sempre usam isolamento instantâneo. O nível de isolamento de escrita determina se um leitor pode ver um instantâneo de uma tabela que, segundo o histórico, "nunca existiu."

  • Serializável: Um leitor vê sempre apenas tabelas que estão de acordo com o histórico
  • WriteSerializable: Um leitor pode ver um estado de tabela que não existe no registo Delta

Exemplo: Exclusão e inserção simultâneas

Considere um cenário em que uma transação de eliminação de longa duração e uma transação de inserção começam ao mesmo tempo e lê a versão v0. A transação de inserção é confirmada primeiro e cria a versão v1. Depois disso, a transação de exclusão tenta confirmar v2:

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

Neste cenário, deleteTxn não viu os dados inseridos por insertTxn nem os apagou:

  • Serializável: deleteTxn não tem permissão para efetuar o commit, e ocorre um conflito
  • WriteSerializable: é permitido fazer commit deleteTxn porque as transações podem ser ordenadas. O estado resultante da tabela é como se insertTxn tivesse ocorrido após deleteTxn, portanto, as linhas inseridas fazem parte da tabela. No entanto, o histórico Delta mostra a ordem física de commit (insertTxn no v1 antes deleteTxn no v2).

Definir o nível de isolamento

Defina o nível de isolamento usando o ALTER TABLE comando:

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

Onde <level-name> é Serializable ou WriteSerializable.

Exemplo:

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

Quando é que a Delta Lake se compromete sem ler a tabela?

As operações Delta Lake INSERT ou append não leem o estado da tabela antes de se comprometerem se as seguintes condições forem satisfeitas:

  1. A lógica é expressa usando INSERT lógica SQL ou modo append
  2. A lógica não contém subconsultas ou condicionais que se refiram à tabela alvo da operação de escrita

Tal como noutros commits, o Delta Lake utiliza metadados do registo de transações para validar e resolver versões das tabelas no commit, mas nenhuma versão da tabela é realmente lida.

Observação

Muitos padrões comuns usam operações de MERGE para inserir dados com base nas condições da tabela. Embora seja possível reescrever essa lógica usando instruções INSERT, se qualquer expressão condicional fizer referência a uma coluna na tabela de destino, essas instruções terão as mesmas limitações de simultaneidade que MERGE.

Passos seguintes

  • Last updated on