Compartilhar via

Cenários de uso do repositório de consultas no Servidor Flexível do Banco de Dados do Azure para PostgreSQL

  • Artigo

APLICA-SE A: Banco de dados do Azure para PostgreSQL – Servidor Flexível

É possível usar o repositório de consultas em uma ampla variedade de cenários, nos quais o acompanhamento e a manutenção do desempenho previsível da carga de trabalho são essenciais. Considere os seguintes exemplos:

  • Identificar e ajustar consultas caras.
  • Execute testes A/B.
  • Identificar e melhorar cargas de trabalho improvisadas.

Identificar e ajustar consultas caras

Identificar consultas de execução prolongada

Use o repositório de consultas exibições no banco de dados azure_sys do servidor para identificar rapidamente as consultas em execução mais longas. Essas consultas tendem a consumir muitos recursos. A otimização de suas consultas mais longas pode melhorar o desempenho, liberando recursos para uso por outras consultas em execução no seu sistema.

Consultas de destino com deltas de desempenho

O repositório de consultas divide os dados de desempenho em janelas de tempo, para que você possa acompanhar o desempenho de uma consulta ao longo do tempo. Isso ajuda a identificar exatamente quais consultas estão contribuindo para um aumento no tempo total gasto. Como resultado, você poderá fazer uma solução de problemas com escopo na sua carga de trabalho.

Ajustar consultas caras

Quando você identifica uma consulta com desempenho abaixo do ideal, a ação executada depende da natureza do problema. Algumas dessas ações podem ser:

  • Certifique-se de que as estatísticas estejam atualizadas para as tabelas subjacentes usadas pela consulta.
  • Pense em reescrever as consultas caras. Por exemplo, aproveite a parametrização de consulta e reduza o uso de SQL ad-hoc. Implemente a lógica ideal ao ler dados, como aplicar a filtragem de dados no lado do banco de dados, não no lado do aplicativo.

Execute os testes A/B

Use o repositório de consultas para comparar o desempenho da carga de trabalho antes e depois de uma alteração de aplicativo que você planeja introduzir ou antes e depois de uma migração. Exemplos de cenários de uso do repositório de consultas para avaliar o impacto do ambiente ou a alteração do aplicativo no desempenho da carga de trabalho:

  • Migrando entre as principais versões do PostgreSQL.
  • Implantando uma nova versão de um aplicativo.
  • Modificando a quantidade de recursos concedidos ao servidor.
  • Alterando qualquer um dos parâmetros do servidor que afetam o comportamento do servidor.
  • Criando índices ausentes em tabelas referenciadas por consultas caras.
  • Migrar do Banco de Dados do Azure para Servidor único do PostgreSQL para o Servidor flexível do Banco de Dados do Azure para PostgreSQL.

Em qualquer um desses cenários, aplique o seguinte fluxo de trabalho:

  1. Execute sua carga de trabalho com o repositório de consultas antes da mudança planejada, para gerar uma linha de base de desempenho.
  2. Aplique as alterações desejadas em um momento controlado no tempo.
  3. Continue executando a carga de trabalho durante tempo suficiente, para que você possa ter uma visão clara do desempenho do sistema após a alteração.
  4. Compare os resultados de antes e depois da alteração.
  5. Decida se deseja manter a alteração ou reversão.

Identificar e melhorar cargas de trabalho improvisadas

Algumas cargas de trabalho não têm consultas dominantes que você pode ajustar para aprimorar o desempenho geral do aplicativo. Essas cargas de trabalho normalmente são caracterizadas com um número relativamente grande de consultas exclusivas, cada uma consumindo uma parte dos recursos do sistema. Cada consulta exclusiva é executada com pouca frequência, portanto, individualmente, seu consumo em runtime não é crítico. Por outro lado, como o aplicativo está gerando novas consultas o tempo todo, uma parte significativa dos recursos do sistema é gasta na compilação de consultas, o que não é o ideal. Normalmente, essa situação acontece se o aplicativo gerar consultas (em vez de usar procedimentos armazenados ou consultas parametrizadas) ou se depender de estruturas de mapeamento objeto-relacional que geram consultas por padrão.

Se você estiver no controle do código do aplicativo, considere reescrever a camada de acesso a dados para usar procedimentos armazenados ou consultas parametrizadas. No entanto, essa situação também pode ser melhorada sem alterações de aplicativo, forçando a parametrização de consulta para todo o banco de dados (todas as consultas) ou para os modelos de consulta individuais com o mesmo hash de consulta.

Conteúdo relacionado