Controle de simultaneidade no Aurora DSQL
A simultaneidade permite que várias sessões acessem e modifiquem dados simultaneamente sem comprometer a integridade e a consistência dos dados. O Aurora DSQL oferece compatibilidade com o PostgreSQL e implementa um mecanismo moderno de controle de simultaneidade sem bloqueio. Ele mantém a conformidade total com ACID por meio do isolamento de snapshots, garantindo a consistência e a confiabilidade dos dados.
Uma das principais vantagens do Aurora DSQL é sua arquitetura sem bloqueios, que elimina gargalos comuns de desempenho do banco de dados. O Aurora DSQL impede que transações lentas bloqueiem outras operações e elimina o risco de deadlocks. Essa abordagem torna o Aurora DSQL particularmente valioso para aplicações de alto throughput em que o desempenho e a escalabilidade são essenciais.
Respostas de controle de simultaneidade
O Aurora DSQL usa o controle de simultaneidade otimista (OCC), que funciona de forma diferente dos sistemas tradicionais baseados em bloqueios. Em vez de usar bloqueios, o OCC avalia os conflitos no horário da confirmação. Esse processo de avaliação de conflitos no momento da confirmação também é chamado de adjudicação. Quando o Aurora DSQL detecta um conflito, ele retorna uma falha de serialização do PostgreSQL com código SQLSTATE 40001. A mensagem de resposta inclui um código OCC que identifica o tipo de conflito:
- OC000: conflito de dados
-
Duas transações tentaram modificar a mesma linha. A transação com o tempo de commit mais cedo é bem-sucedida, e a transação em conflito recebe a resposta OC000:
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) - OC001: conflito de esquema
-
O catálogo de esquema em cache na sessão está desatualizado. Quando o Aurora DSQL detecta que a versão do catálogo mudou desde que a sessão carregou o cache, e a transação não pode fazer o rebase com segurança para a versão atual, a transação recebe a resposta OC001:
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)Qualquer operação que modifique o catálogo de esquema pode causar uma resposta OC001, incluindo instruções DDL como
CREATE TABLEeALTER TABLE, bem como instruçõesGRANTeREVOKE. Para obter mais informações, consulte DDL e transações distribuídas no Aurora DSQL.
Projete as aplicações para implementar lógica de repetição para lidar com essas respostas. O padrão de design ideal é idempotente, permitindo a repetição da transação como primeiro recurso sempre que possível. A lógica recomendada é semelhante à lógica de cancelar e repetir em uma situação padrão de tempo limite de bloqueio ou deadlock do PostgreSQL. No entanto, o OCC exige que as aplicações exerçam essa lógica com maior frequência.
Tipos de conflito de dados
Devido ao mecanismo de controle de simultaneidade do Aurora DSQL, as cláusulas SELECT ... FOR
UPDATE e SELECT ... FOR KEY SHARE produzem resultados por meio da detecção otimista de conflitos no momento da confirmação, em vez de usar bloqueios. No Aurora DSQL, quando uma transação grava uma linha e outra a lê usando uma das cláusulas anteriores, pode surgir um conflito no momento da confirmação, dependendo das colunas usadas pelas transações. As cláusulas a seguir determinam como o Aurora DSQL detecta esses conflitos.
Definição de coluna de chave
As colunas de chave são colunas que são membros de um índice exclusivo, não parcial e sem expressão. Todas as outras colunas são colunas que não são de chave.
SELECT ... FOR UPDATE-
Declara que o Aurora DSQL faz a adjudicação das linhas selecionadas como se a transação gravasse nelas. Se outra transação executar
UPDATE,DELETE,SELECT ... FOR UPDATEouSELECT ... FOR KEY SHAREna mesma linha e for confirmada primeiro, a transação que executouSELECT ... FOR UPDATEfalhará com uma respostaOC000. Essa cláusula entra em conflito com qualquer gravação simultânea na linha e com leituras simultâneas deFOR UPDATEouFOR KEY SHARE. SELECT ... FOR KEY SHARE-
Declara que a transação depende das colunas de chave das linhas selecionadas. Se outra transação excluir a linha, alterar suas colunas de chave ou executar
SELECT ... FOR UPDATEe for confirmada primeiro, a transação que executouSELECT ... FOR KEY SHAREfalhará com uma respostaOC000. Uma operaçãoUPDATEsimultânea em colunas que não são de chave não entra em conflito.
O Aurora DSQL não é compatível com as cláusulas NO KEY UPDATE nem FOR SHARE. No entanto, a DML usa implicitamente o mecanismo NO KEY UPDATE. A matriz a seguir resume quando duas transações simultâneas que acessam a mesma linha entram em conflito. Um X indica que as duas operações entram em conflito: a transação que for confirmada por último falhará com uma resposta OC000. Uma célula em branco indica que as duas transações podem ser confirmadas.
| Operation | INSERT, DELETE, UPDATE (colunas de chave) ou SELECT ... FOR UPDATE |
UPDATE (somente colunas que não são de chave) |
SELECT ... FOR KEY SHARE |
|---|---|---|---|
INSERT, DELETE, UPDATE (colunas de chave) ou SELECT ... FOR UPDATE |
X | X | X |
UPDATE (somente colunas que não são de chave) |
X | X | |
SELECT ... FOR KEY SHARE |
X |
Diretrizes para otimizar o desempenho da transação
Para otimizar o desempenho, minimize a alta contenção em chaves únicas ou em pequenos intervalos de chaves. Para atingir esse objetivo, projete seu esquema para distribuir atualizações pelo intervalo de chaves do cluster usando as seguintes diretrizes:
-
Escolha uma chave primária aleatória para suas tabelas.
-
Evite padrões que aumentem a contenção em chaves únicas. Essa abordagem garante um desempenho ideal mesmo com o aumento do volume de transações.
