Cenários de uso do Repositório 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 Query Store 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:
- Identificação e ajuste das principais consultas caras.
- Teste A/B.
- Manter o desempenho estável durante as atualizações.
- Identificação e melhoria de cargas de trabalho improvisadas.
Identificar e ajustar consultas caras
Identificar as consultas de execução mais longas
Use o Repositório de Consultas exibições no banco de dados azure_sys do seu servidor para identificar rapidamente as consultas em execução mais longas. Essas consultas normalmente 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ê pode fazer uma solução de problemas direcionada de 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 dinâmico. 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.
Testes de 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 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:
- Migração entre as principais versões do PostgreSQL.
- Implantando uma nova versão de um aplicativo.
- Modificando a quantidade de recursos concedidos ao servidor.
- Alterar qualquer um dos parâmetros do servidor que afetam o comportamento do servidor.
- Criando índices ausentes em tabelas referenciadas por consultas caras.
- Migrando 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:
- Execute sua carga de trabalho com o Repositório de Consultas antes da alteração planejada, para gerar uma linha de base de desempenho.
- Aplique as mudanças desejadas em um momento controlado no tempo.
- Continue executando a carga de trabalho, tempo suficiente para gerar a imagem de desempenho do sistema após a alteração.
- Compare os resultados de antes e depois da mudança.
- 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ê 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 de tempo de execução não é crítico. Por outro lado, dado que o aplicativo está gerando novas consultas o tempo todo, uma parcela 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 no 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.