Modelo de simultaneidade do Amazon QLDB

O Amazon QLDB é destinado a atender às necessidades de workloads de processamento de transações online (OLTP). O QLDB suporta capacidade de consultas semelhantes ao SQL e entrega transações ACID completas. Além disso, os itens de dados do QLDB são documentos, entregando flexibilidade de esquema e modelagem de dados intuitiva. Com um diário no núcleo, você pode usar o QLDB para acessar o histórico completo e verificável de todas as alterações em seus dados e transmitir transações coerentes para outros serviços de dados conforme necessário.

Controle de simultaneidade otimista

No QLDB, o controle de simultaneidade é implementado usando o controle de simultaneidade otimista (OCC). O OCC opera com base no princípio de que várias transações podem ser concluídas com frequência sem interferir umas nas outras.

Usando o OCC, as transações no QLDB não adquirem bloqueios nos recursos do banco de dados e operam com isolamento serializável total. O QLDB executa transações concomitantes em série, de forma a produzir o mesmo efeito como se essas transações tivessem sido iniciadas em série.

Antes da confirmação, cada transação executa uma verificação de validação para garantir que nenhuma outra transação confirmada tenha modificado os dados que está acessando. Se essa verificação revelar modificações conflitantes ou se o estado dos dados mudar, a transação confirmada será rejeitada. No entanto, a transação pode ser reiniciada.

Quando uma transação grava no QLDB, as verificações de validação do modelo OCC são implementadas pelo próprio QLDB. Se uma transação não puder ser gravada no diário devido a uma falha na fase de verificação do OCC, o QLDB retornará OccConflictException uma para a camada do aplicativo. O software do aplicativo é responsável por garantir que a transação seja reiniciada. O aplicativo deve interromper a transação rejeitada e, em seguida, repetir toda a transação desde o início.

Para saber como o driver QLDB trata e repete conflitos de OCC e outras exceções temporárias, consulte Entendendo a política de repetição com o driver no Amazon QLDB.

Usando índices para evitar varreduras completas da tabela

No QLDB, cada instrução PartiQL (incluindo cada consulta SELECT) é processada em uma transação e está sujeita a um limite de tempo de espera de transações.

Como prática recomendada, você deve executar instruções com uma cláusula de predicado WHERE que filtre em um campo indexado ou em uma ID de documento. O QLDB requer um operador de igualdade em um campo indexado para pesquisar um documento com eficiência, por exemplo, WHERE indexedField = 123 ou WHERE indexedField IN (456, 789).

Sem essa pesquisa indexada, o QLDB precisa fazer uma verificação da tabela completa ao ler documentos. Isso pode causar latência da consulta e tempos limite de transação, além de aumentar as chances de um conflito de OCC com transações concorrentes.

Por exemplo, considere uma tabela chamada Vehicle que tenha um índice somente no campo VIN. Contém os seguintes documentos.

VIN	Make	Modelo	Cor
"1N4AL11D75C109151"	"Audi"	"A5"	"Silver"
"KM8SRDHF6EU074761"	"Tesla"	"Model S"	"Blue"
"3HGGK5G53FM761765"	"Ducati"	"Monster 1200"	"Yellow"
"1HVBBAANXWH544237"	"Ford"	"F 150"	"Black"
"1C4RJFAG0FC625797"	"Mercedes"	"CLK 350"	"White"

Dois usuários concomitantes chamados Alice e Bob estão trabalhando com a mesma tabela em um ledger. Eles querem atualizar dois documentos diferentes, da seguinte forma.

Alice:

UPDATE Vehicle AS v
SET v.Color = 'Blue'
WHERE v.VIN = '1N4AL11D75C109151'

Bob

UPDATE Vehicle AS v
SET v.Color = 'Red'
WHERE v.Make = 'Tesla' AND v.Model = 'Model S'

Suponha que Alice e Bob iniciem suas transações ao mesmo tempo. A instrução UPDATE de Alice faz uma pesquisa indexada no campo VIN, então ela só precisa ler aquele documento. Alice termina e confirma sua transação com êxito primeiro.

A instrução de Bob filtra em campos não indexados, então ela faz uma varredura da tabela e encontra um OccConflictException. Isso ocorre porque a transação confirmada de Alice modificou os dados que a instrução de Bob está acessando, o que inclui todos os documentos da tabela, não apenas o documento que Bob está atualizando.

Conflitos de inserção no OCC

Os conflitos de OCC podem incluir documentos recém-inseridos — não apenas documentos que existiam anteriormente. Considere o diagrama a seguir, no qual dois usuários concomitantes (Alice e Bob) estão trabalhando com a mesma tabela em um ledger. Ambos desejam inserir um novo documento somente sob a condição de que ainda não exista um valor de predicado.

Neste exemplo, tanto Alice quanto Bob executam as instruções SELECT e INSERT a seguir, em uma única transação. Seu aplicativo executa a instrução INSERT somente se a instrução SELECT não retornar resultados.

SELECT * FROM Vehicle v WHERE v.VIN = 'ABCDE12345EXAMPLE'

INSERT INTO Vehicle VALUE
{
    'VIN' : 'ABCDE12345EXAMPLE',
    'Type' : 'Wagon',
    'Year' : 2019,
    'Make' : 'Subaru',
    'Model' : 'Outback',
    'Color' : 'Gray'
}

Suponha que Alice e Bob iniciem suas transações ao mesmo tempo. Ambas as consultas SELECT não retornam nenhum documento existente com um VIN deABCDE12345EXAMPLE. Então, seus aplicativos prosseguem com a instrução INSERT.

Alice termina e confirma sua transação com êxito primeiro. Em seguida, Bob tenta confirmar sua transação, mas o QLDB a rejeita e lança um OccConflictException. Isso ocorre porque a transação confirmada de Alice modificou o conjunto de resultados da consulta SELECT de Bob, e a OCC detecta esse conflito antes de confirmar a transação de Bob.

A consulta SELECT é necessária para que esse exemplo de transação seja idempotente. Bob pode então repetir toda a transação desde o início. Mas sua próxima consulta SELECT retornará o documento que Alice inseriu, então o aplicativo de Bob não executará o INSERT.

Tornando as transações idempotentes

A transação de inserção na seção anterior também é um exemplo de transação idempotente. Em outras palavras, executar a mesma transação várias vezes produz resultados idênticos. Se Bob executar o INSERT sem primeiro verificar se um determinado VIN já existe, a tabela pode acabar com documentos com valores VIN duplicados.

Considere outros cenários de repetição, além dos conflitos de OCC. Por exemplo, é possível que o QLDB confirme com sucesso a transação no lado do servidor, mas o tempo do cliente expire enquanto espera por uma resposta. Recomendamos que você torne as transações de gravação idempotentes para evitar efeitos colaterais inesperados no caso de simultaneidade ou tentativas repetidas.

Conflitos de edição do OCC

O QLDB evita edições simultâneas de revisões no mesmo bloco de diário. Considere um exemplo em que dois usuários concomitantes (Alice e Bob) desejam redigir duas revisões de documentos diferentes que são confirmadas no mesmo bloco em um ledger. Primeiro, Alice solicita a redação de uma revisão executando o procedimento armazenado REDACT_REVISION, da seguinte forma.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '5PLf9SXwndd63lPaSIa0O6', 'ADR2Ll1fGsU4Jr4EqTdnQF'

Então, enquanto a solicitação de Alice ainda está sendo processada, Bob solicita a redação de outra revisão, da seguinte forma.

EXEC REDACT_REVISION `{strandId:"JdxjkR9bSYB5jMHWcI464T", sequenceNo:17}`, '8F0TPCmdNQ6JTRpiLj2TmW', '05K8zpGYWynDlEOK5afDRc'

O QLDB rejeita a solicitação de Bob com um OccConflictException, apesar de estar tentando redigir duas revisões de documentos diferentes . Isso ocorre porque a revisão de Bob está localizada no mesmo bloco da revisão que Alice está editando. Depois que a solicitação de Alice terminar o processamento, Bob poderá repetir sua solicitação de redação.

Da mesma forma, se duas transações simultâneas tentarem redigir a mesma revisão, somente uma solicitação poderá ser processada. A outra solicitação falha com uma exceção de conflito de OCC até que a redação seja concluída. Posteriormente, qualquer solicitação para redigir a mesma revisão resultará em um erro que indica que a revisão já foi editada.

Gerenciar sessões simultâneas

Se você tem experiência no uso de um sistema de gerenciamento de banco de dados relacional (RDBMS), talvez esteja familiarizado com limites de conexões simultâneas. O QLDB não tem o mesmo conceito de uma conexão RDBMS tradicional porque as transações são executadas com mensagens de solicitação e resposta HTTP.

No QLDB, o conceito análogo é uma sessão ativa. Uma sessão é conceitualmente semelhante a um login de usuário — ela gerencia as informações sobre suas solicitações de transação de dados em um ledger. Uma sessão ativa é aquela que está executando ativamente uma transação. Também pode ser uma sessão que concluiu recentemente uma transação em que o serviço prevê que iniciará outra transação imediatamente. O QLDB suporta uma transação em execução ativa por sessão.

O limite de sessões ativas simultâneas por ledger é definido em Cotas e limites no Amazon QLDB. Depois que esse limite for atingido, qualquer sessão que tente iniciar uma transação resultará em um erro (LimitExceededException).

Para obter informações sobre o ciclo de vida de uma sessão e como o driver QLDB lida com as sessões ao executar transações de dados, consulte Gerenciamento da sessão com o driver. Para obter as práticas recomendadas para configurar um pool de sessões em seu aplicativo usando o driver QLDB, consulte Configurando o objeto QldbDriver nas recomendações do driver QLDB da Amazon.