Migrar do PostgreSQL para o Aurora DSQL

Use CREATE INDEX ASYNC em vez de CREATE INDEX para criação de índices sem bloqueio.

Benefício: criação de índice de tempo de inatividade zero em tabelas grandes.

Use DELETE FROM table_name em vez de TRUNCATE.

Alternativa: para a recriação completa da tabela, use DROP TABLE seguido de CREATE TABLE.

Como o Aurora DSQL é totalmente gerenciado, a configuração é feita automaticamente com base nos padrões de workload. Use a API ou o Console de Gerenciamento da AWS para gerenciar configurações de cluster.

Benefício: não há necessidade de ajuste do banco de dados nem gerenciamento de parâmetros.

O Aurora DSQL comporta relações e operações JOIN de tabelas. Para obter integridade referencial, implemente a validação na camada da aplicação. Esse design se alinha aos padrões dos bancos de dados distribuídos modernos, nos quais a validação da camada da aplicação oferece maior flexibilidade e evita gargalos de desempenho das operações em cascata.

Padrão: implemente verificações de integridade referencial em sua camada de aplicação usando convenções de nomenclatura consistentes, lógica de validação e limites de transação. Muitas aplicações de alta escala preferem essa abordagem para melhor controle sobre o tratamento de erros e a performance.

Use CTEs, subconsultas ou tabelas regulares com lógica de limpeza em vez de tabelas temporárias.

Alternativa: crie tabelas com nomes específicos da sessão e limpe-as em sua aplicação.

O Aurora DSQL fornece um banco de dados incorporado denominado postgres por cluster.

Dica de migração: se sua aplicação usa vários bancos de dados, crie clusters do Aurora DSQL separados para separação lógica ou use esquemas em um único cluster.

Para o tratamento temporário de dados, é NECESSÁRIO usar expressões de tabela comuns (CTEs) e subconsultas, que oferecem alternativas flexíveis para consultas complexas.

Alternativa: use CTEs com cláusulas WITH para conjuntos de resultados temporários ou tabelas regulares com nomenclatura exclusiva para dados específicos da sessão.

O Aurora DSQL elimina os espaços de tabela e o gerenciamento manual do armazenamento. O armazenamento escala e otimizado automaticamente com base em seus padrões de dados.

Benefício: não é necessário monitorar o espaço em disco, planejar a alocação de armazenamento nem gerenciar configurações de espaço de tabela.

Para ter uma funcionalidade semelhante a um acionador, implemente a lógica orientada a eventos na camada da aplicação.

Estratégia de migração: mova a lógica de gatilho para o código da aplicação, use arquiteturas orientadas por eventos com serviços da AWS, como o EventBridge, ou implemente trilhas de auditoria usando o registro em log de aplicações.

O Aurora DSQL comporta funções baseadas em SQL, mas não a linguagens processuais, como PL/pgSQL.

Alternativa: use funções SQL para transformações de dados ou mova uma lógica complexa para sua camada de aplicação ou funções do AWS Lambda.

O Aurora DSQL usa o controle otimista (OCC), uma abordagem sem bloqueio que difere de sistemas tradicionais baseados em bloqueios. Em vez de adquirir bloqueios que impedem outras transações, o Aurora DSQL permite que as transações prossigam sem bloqueio e detecta conflitos no momento da confirmação. Isso elimina deadlocks e impede que transações lentas bloqueiem outras operações.

Diferença fundamental: quando ocorrem conflitos, o Aurora DSQL exibe um erro de serialização em vez de fazer as transações aguardarem bloqueios. Isso exige que as aplicações implementem uma lógica de repetição, semelhante à manipulação de tempos limite de bloqueio em bancos de dados tradicionais, mas os conflitos são resolvidos imediatamente, em vez de causar esperas de bloqueio.

Padrão de projeto: implemente uma lógica de transação idempotente com mecanismos de repetição. Crie esquemas para minimizar a contenção usando chaves primárias aleatórias e distribuindo atualizações por todo o intervalo de chaves. Para obter detalhes, consulte Controle de simultaneidade no Aurora DSQL.

O Aurora DSQL aceita relações de chave externa entre tabelas, como operações JOIN . Para obter integridade referencial, implemente a validação na camada da aplicação. Embora impor a integridade referencial possa ser valioso, operações em cascata (como exclusões em cascata) podem criar problemas de performance inesperados, por exemplo, excluir um pedido com mil itens de linha se torna uma transação de 1.001 linhas. Muitos clientes evitam restrições de chave externa por esse motivo.

Padrão de projeto: implemente verificações de integridade referencial em sua camada de aplicação, use padrões de consistência eventual ou utilize serviços da AWS para validação de dados.

O Aurora DSQL gerencia automaticamente a otimização do armazenamento, a coleta de estatísticas e o ajuste de desempenho. Os comandos de manutenção tradicionais, como VACUUM, são gerenciados pelo sistema.

Benefício: elimina a necessidade de janelas de manutenção do banco de dados, agendamento de vácuo e ajuste dos parâmetros do sistema.

O Aurora DSQL particiona e distribui automaticamente seus dados com base nos padrões de acesso. Use UUIDs ou IDs gerados pela aplicação para ter uma distribuição ideal.

Dica de migração: remova a lógica de particionamento manual e deixe o Aurora DSQL lidar com a distribuição de dados. Use UUIDs ou IDs gerados pela aplicação para ter uma distribuição ideal. Se a aplicação exigir identificadores sequenciais, consulte Sequências e colunas de identidade.