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.

O Aurora DSQL não comporta comandos ALTER SYSTEM porque o sistema é totalmente gerenciado. A configuração é feita automaticamente com base nos padrões de workload.

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

Use UUIDs ou chaves compostas em vez de sequências de incremento automático. As sequências de incremento automático geram uma grande quantidade de conflitos em um sistema distribuído, pois vários gravadores estão tentando atualizar os mesmos dados. Os UUIDs fornecem a mesma função, mas não exigem coordenação.

Exemplo da: id UUID PRIMARY KEY DEFAULT gen_random_uuid()

O Aurora DSQL comporta relações e operações JOIN de tabelas, mas ainda não impõe restrições de chave externa. Essa opção de projeto se alinha aos padrões modernos de banco de dados distribuídos, nos quais a validação da camada de aplicação fornece maior flexibilidade e evita gargalos de performance 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.

Tabelas temporárias ainda não são aceitas no Aurora DSQL. Expressões de tabela comuns (CTEs) e subconsultas podem ser usadas como uma alternativa 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.

O Aurora DSQL não comporta gatilhos.

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 relacionamentos de chave externa entre tabelas, incluindo operações JOIN , mas as restrições de chave externa ainda não são aceitas. 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 não exige comandos VACUUM, TRUNCATE e ALTER SYSTEM. O sistema gerencia automaticamente a otimização do armazenamento, a coleta de estatísticas e o ajuste da performance.

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. O particionamento e as sequências manuais não são necessários.

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 em vez de sequências.