Compartilhar via

Níveis de isolamento (WriteSerializable e Serializable)

O Delta Lake no Azure Databricks dá suporte a dois níveis de isolamento que controlam como as operações simultâneas em uma determinada tabela interagem:

Nível de isolamento Descrição
Serializável O nível de isolamento mais forte. Garante que as operações de gravação confirmadas e todas as leituras sejam serializáveis. As operações são permitidas desde que haja uma sequência serial que, quando executada uma de cada vez, gera o mesmo resultado visto na tabela. Para operações de gravação, essa sequência serial é a mesma que a ordem vista no histórico da tabela.
WriteSerializable (Padrão) Um nível de isolamento mais fraco que Serializável. Garante que somente as operações de gravação (não leituras) sejam serializáveis. Isso ainda é mais forte do que isolamento instantâneo. Fornece um bom equilíbrio de 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 por 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 sempre vê apenas tabelas em conformidade com o histórico
  • WriteSerializable: um leitor pode ver um estado de tabela que não existe no log Delta

Exemplo: exclusão simultânea e inserção

Considere um cenário em que uma transação de exclusão de execução longa e uma transação de inserção começam ao mesmo tempo e leem a versão v0. A transação de inserção confirma 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)

Nesse cenário, deleteTxn não viu os dados inseridos e insertTxn não os excluiu:

  • Serializável: deleteTxn não pode submeter, e ocorre um conflito
  • WriteSerializable: deleteTxn tem permissão para confirmação porque as transações podem ser ordenadas. O estado da tabela resultante é como se insertTxn tivesse ocorrido depois deleteTxn, portanto, as linhas inseridas fazem parte da tabela. No entanto, o histórico Delta mostra a ordem de confirmação física (insertTxn em v1 antes de deleteTxn na 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> está Serializable ou WriteSerializable.

Exemplo:

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

Quando o Delta Lake confirma sem ler a tabela?

As operações INSERT ou de acréscimo do Delta Lake não leem o estado da tabela antes de confirmar se as seguintes condições foram atendidas:

  1. A lógica é expressa usando INSERT lógica SQL ou modo de adição
  2. A lógica não contém subconsultas ou condicionais que referenciam a tabela referida pela operação de escrita

Assim como acontece com outras confirmações, o Delta Lake usa metadados de log de transações para validar e resolver versões de tabela na confirmação, mas nenhuma versão da tabela é realmente lida.

Observação

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

Próximas Etapas 

  • Last updated on