Boas práticas para criar um aplicativo com o servidor único do Banco de Dados do Azure para PostgreSQL

APLICA-SE A: Banco de Dados do Azure para PostgreSQL – Servidor Único

Importante

O Banco de Dados do Azure para PostgreSQL – Servidor Único está prestes a ser desativado. É altamente recomendável que você atualize para o Banco de Dados do Azure para PostgreSQL - Servidor Flexível. Para obter mais informações sobre como migrar para o Banco de Dados do Azure para PostgreSQL: Servidor Flexível, consulte O que está acontecendo com o Banco de Dados do Azure para PostgreSQ:L Servidor Único?

Aqui estão algumas melhores práticas para ajudá-lo a criar um aplicativo pronto para a nuvem usando o Banco de Dados do Azure para PostgreSQL. Essas melhores práticas podem reduzir o tempo de desenvolvimento para seu aplicativo.

Configuração de recursos de aplicativo e banco de dados

Mantenha o aplicativo e o banco de dados na mesma região

Verifique se todas as suas dependências estão na mesma região ao implantar seu aplicativo no Azure. A difusão de instâncias entre regiões ou zonas de disponibilidade cria a latência de rede, o que pode afetar o desempenho geral do seu aplicativo.

Mantenha seu servidor PostgreSQL seguro

Configure seu servidor PostgreSQL para ser seguro e não acessível publicamente. Use uma destas opções para proteger seu servidor:

Para segurança, você deve sempre se conectar ao servidor PostgreSQL por SSL e configurar seu servidor PostgreSQL e seu aplicativo para usar o TLS 1.2. Confira Como configurar o SSL/TLS.

Usar variáveis de ambiente para informações de conexão

Não salve suas credenciais de banco de dados no código do aplicativo. Dependendo do aplicativo de front-end, siga as diretrizes para configurar variáveis de ambiente. Para usar o Serviço de Aplicativo, consulte como definir configurações de aplicativo e para o serviço de Kubernetes do Azure, confira como usar segredos do Kubernetes.

Desempenho e resiliência

Aqui estão algumas ferramentas e práticas que você pode usar para ajudar a depurar problemas de desempenho com seu aplicativo.

Usar o pool de conexões

Com o pool de conexões, um conjunto fixo de conexões é estabelecido no momento da inicialização e mantido. Isso também ajuda a reduzir a fragmentação de memória no servidor que é causado pelas conexões dinâmicas novas estabelecidas no servidor de banco de dados. O pooling de conexão poderá ser configurado do lado do aplicativo se a estrutura do aplicativo ou o driver de banco de dados oferecer suporte a ele. Se ele não for suportado, a outra opção recomendada é aproveitar um serviço de pooler de conexão de proxy como PgBouncer ou Pgpool em execução fora do aplicativo e conectar-se ao servidor de banco de dados. O PgBouncer e o Pgpool são ferramentas baseadas na comunidade que funcionam com o Banco de Dados do Azure para PostgreSQL.

Lógica de repetição para manipular erros transitórios

Seu aplicativo pode apresentar erros transitórios nos quais as conexões com o banco de dados são descartadas ou perdidas de forma intermitente. Nessas situações, o servidor está em execução após uma ou duas repetições em 5 a 10 segundos. Uma boa prática é aguardar 5 segundos antes de sua primeira tentativa. Em seguida, siga cada nova tentativa aumentando a espera gradualmente, até 60 segundos. Limite o número máximo de repetições em que o seu aplicativo considera que a operação falhou, para que você possa investigar ainda mais. Confira Como solucionar problemas de erros de conexão para saber mais.

Habilitar a replicação de leitura para reduzir failovers

Use a Replicação de Dados para cenários de failover. Quando você estiver usando réplicas de leitura, não ocorre nenhum failover automatizado entre os servidores de origem e de réplica. Você perceberá um atraso entre a origem e a réplica porque a replicação é assíncrona. O atraso da rede pode ser influenciado por muitos fatores, como o tamanho da carga de trabalho em execução no servidor de origem e a latência entre os datacenters. Na maioria dos casos, o atraso da réplica varia de alguns segundos para alguns minutos.

Implantação de banco de dados

Configurar o pipeline de implantação de CI/CD

Ocasionalmente, você precisa implantar alterações em seu banco de dados. Nesses casos, você pode usar a CI (integração contínua) por meio do GitHub Actions para que o servidor PostgreSQL atualize o banco de dados executando um script personalizado nele.

Definir processo de implantação manual de banco de dados

Durante a implantação manual do banco de dados, siga estas etapas para minimizar o tempo de inatividade ou reduzir o risco de falha na implantação:

  • Crie uma cópia de um banco de dados de produção em um novo banco de dados usando pg_dump.
  • Atualize o novo banco de dados com suas novas alterações de esquema ou atualizações necessárias para seu banco de dados.
  • Coloque o banco de dados de produção em um estado somente leitura. Você não deve ter operações de gravação no banco de dados de produção até que a implantação seja concluída.
  • Teste seu aplicativo com o banco de dados recentemente atualizado da etapa 1.
  • Implante as alterações do aplicativo e verifique se o aplicativo agora está usando o novo banco de dados que tem as atualizações mais recentes.
  • Mantenha o banco de dados de produção antigo para que você possa reverter as alterações. Em seguida, você pode avaliar excluir o banco de dados de produção antigo ou exportá-lo no Armazenamento do Azure, se necessário.

Observação

Se o aplicativo for como um aplicativo de comércio eletrônico e você não puder colocá-lo no estado somente leitura, implante as alterações diretamente no banco de dados de produção depois de fazer um backup. Essas alterações devem ocorrer fora do horário de pico, com baixo tráfego no aplicativo para minimizar o impacto, pois alguns usuários podem ter solicitações com falha. Verifique se o código do aplicativo também trata das solicitações com falha.

Esquema e consultas do banco de dados

Aqui estão algumas dicas para não esquecer quando você criar seu esquema de banco de dados e consultas.

Usar BIGINT ou UUID para Chaves Primárias

Ao criar aplicativos personalizados ou algumas estruturas eles podem usar INT em vez de BIGINT para chaves primárias. Ao usar INT, você corre o risco do valor em seu banco de dados exceder a capacidade de armazenamento do tipo de dado INT. Fazer essa alteração em um aplicativo de produção existente pode ser demorado custando mais tempo de desenvolvimento. Outra opção é usar o UUID para chaves primárias. Esse identificador usa uma cadeia de caracteres de 128 bits gerada automaticamente, por exemplo a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11. Saiba mais sobre os Tipos de dados PostgreSQL.

Usar índices

Há muitos tipos de índices no Postgres que podem ser usados de formas diferentes. O uso de um índice ajuda o servidor a localizar e recuperar linhas específicas muito mais rápido do que poderia sem um índice. Mas os índices também adicionam sobrecarga ao servidor de banco de dados, portanto, evite ter muitos índices.

Usar vácuo automático

Você pode otimizar seu servidor com o vácuo automático em um servidor de Banco de Dados PostgreSQL do Azure. O PostgreSQL permite maior simultaneidade de banco de dados, mas cada atualização resulta em inserção e exclusão. Para excluir, os registros marcados temporariamente serão limpos mais tarde. Para executar essas tarefas, o PostgreSQL executa um trabalho de vácuo. Se você não executar o vácuo periodicamente, as tuplas inativas acumuladas poderão levar a:

  • Sobrecarga de dados, como bancos de dados e tabelas maiores.
  • Maiores índices de qualidade inferior.
  • Aumento de E/S.

Saiba mais sobre Como otimizar com o vácuo automático.

Usar pg_stats_statements

Pg_stat_statements é uma extensão do PostgreSQL habilitada por padrão no Banco de Dados do Azure para PostgreSQL. A extensão fornece um modo para rastrear as estatísticas de execução de todas as instruções SQL executadas por um servidor. Confira Como usar o pg_statement.

Usar o Repositório de Consultas

O recurso Repositório de Consultas no Banco de Dados do Azure para PostgreSQL fornece um método mais eficaz para rastrear as estatísticas da consulta. Recomendamos esse recurso como uma alternativa ao uso de pg_stats_statements.

Otimizar inserções em massa e usas dados transitórios

Se você tem operações de carga de trabalho que envolvem dados temporários ou inserem grandes conjuntos de dados em massa, considere o uso de tabelas não registradas. Por padrão, ele fornece atomicidade e durabilidade. Atomicidade, consistência, isolamento e durabilidade são as propriedades ACID. Confira Como otimizar inserções em massa.