Partilhar via


Cenários de uso para armazenamento de consultas - Banco de Dados do Azure para PostgreSQL - Servidor Flexível

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

Você pode usar o armazenamento de consultas em uma ampla variedade de cenários nos quais o controle e a manutenção do desempenho previsível da carga de trabalho são essenciais. Considere os seguintes exemplos:

  • Identifique e ajuste consultas caras.
  • Realize testes A/B.
  • Identificar e melhorar cargas de trabalho improvisadas.

Identifique e ajuste consultas caras

Identificar consultas de longa duração

Use exibições azure_sys de armazenamento de consultas no banco de dados do seu servidor para identificar rapidamente as consultas de execução mais longa. Essas consultas tendem a consumir mais recursos. Otimizar suas consultas de execução mais longa pode melhorar o desempenho, liberando recursos usados 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 você a identificar exatamente quais consultas estão contribuindo para um aumento no tempo total gasto. Como resultado, você pode fazer a solução de problemas de escopo de sua carga de trabalho.

Ajuste consultas caras

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

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

Realizar 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 da migração. Exemplos de cenários para usar o repositório de consultas para avaliar o impacto das alterações no desempenho da carga de trabalho:

  • Migração entre as principais versões do PostgreSQL.
  • Lançamento de uma nova versão de um aplicativo.
  • Modificar a quantidade de recursos concedidos ao servidor.
  • Alterar qualquer um dos parâmetros do servidor que afetam o comportamento do servidor.
  • Criação de índices ausentes em tabelas referenciadas por consultas caras.
  • Migração do Banco de Dados do Azure para servidor único PostgreSQL para o Banco de Dados do Azure para servidor flexível 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 alteração 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 revertê-la.

Identificar e melhorar cargas de trabalho improvisadas

Algumas cargas de trabalho não têm consultas dominantes que você possa ajustar para melhorar o desempenho geral do aplicativo. Essas cargas de trabalho são normalmente caracterizadas com um número relativamente grande de consultas exclusivas, cada uma delas consumindo uma parte dos recursos do sistema. Cada consulta exclusiva é executada com pouca frequência, portanto, individualmente, seu consumo de tempo de execução não é crítico. Por outro lado, dado que 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 seu 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, poderá considerar 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 no aplicativo, forçando a parametrização da consulta para todo o banco de dados (todas as consultas) ou para os modelos de consulta individuais com o mesmo hash de consulta.