As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Modelo de QLDB concorrência da Amazon

QLDBO objetivo da Amazon é atender às necessidades de cargas de trabalho de processamento de transações on-line (OLTP) de alto desempenho. QLDBoferece suporte a recursos SQL de consulta semelhantes aos de consultas e fornece ACID transações completas. Além disso, QLDB os itens de dados são documentos, oferecendo flexibilidade de esquema e modelagem de dados intuitiva. Com um diário no centro, você pode usá-lo 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

EmQLDB, o controle de concorrência é implementado usando o controle de concorrência otimista (). OCC OCCopera com base no princípio de que várias transações podem ser concluídas frequentemente sem interferir umas nas outras.

UsandoOCC, as transações QLDB não adquirem bloqueios nos recursos do banco de dados e operam com isolamento serializável total. QLDBexecuta transações simultâneas em série, de forma que produza 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 emQLDB, as verificações de validação do OCC modelo são implementadas por QLDB si mesmas. Se uma transação não puder ser gravada no diário devido a uma falha na fase de verificação doOCC, QLDB retorna uma OccConflictException para a camada de aplicação. 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 QLDB driver lida e repete OCC conflitos e outras exceções transitórias, consulte. Entendendo a política de repetição com o motorista na Amazon QLDB

Usar índices para evitar varreduras completas da tabela

EmQLDB, cada instrução partiQL (incluindo cada SELECT consulta) é processada em uma transação e está sujeita a um limite de tempo limite de transação.

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

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

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

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 OCC

OCCos conflitos podem incluir documentos que foram inseridos recentemente, 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 de ABCDE12345EXAMPLE. Então, seus aplicativos prosseguem com a instrução INSERT.

Alice termina e confirma sua transação com êxito primeiro. Então, Bob tenta confirmar sua transação, mas a QLDB rejeita e lança uma. OccConflictException Isso ocorre porque a transação confirmada de Alice modificou o conjunto de resultados da SELECT consulta de Bob e 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.

Tornar 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 OCC conflitos. Por exemplo, é possível que uma transação seja confirmada QLDB com sucesso no lado do servidor, mas o 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 redação OCC

QLDBevita redaçõ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'

QLDBrejeita a solicitação de Bob OccConflictException mesmo que eles estejam 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 OCC conflito 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ê tiver experiência no uso de um sistema de gerenciamento de banco de dados relacional (RDBMS), talvez esteja familiarizado com os limites de conexão simultânea. QLDBnão tem o mesmo conceito de RDBMS conexão tradicional porque as transações são executadas com mensagens de HTTP solicitação e resposta.

EmQLDB, 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. QLDBsuporta 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 na 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 QLDB driver lida com as sessões ao executar transações de dados, consulte. Gerenciamento da sessão com o driver Para obter as melhores práticas para configurar um pool de sessões em seu aplicativo usando o QLDB driver, consulte as recomendações Configurando o objeto QldbDriver de QLDB drivers da Amazon.