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 concorrência
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. 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.
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.
