Scénarios d’utilisation pour Magasin des requêtes - Azure Database pour PostgreSQL - Serveur flexible
S’APPLIQUE À :
Azure Database pour PostgreSQL – Serveur flexible
Vous pouvez utiliser le Magasin des requêtes dans de nombreux scénarios dans lesquels il est essentiel de suivre et de gérer les performances des charges de travail prévisibles. Penchez-vous sur les exemples suivants :
- Identification et réglage des requêtes les plus coûteuses.
- Tests A/B.
- Maintenir les performances stables pendant les mises à niveau.
- Identification et amélioration des charges de travail improvisées.
Identifier et ajuster les requêtes coûteuses
Identifier les requêtes les plus longues à s’exécuter
Utilisez des vues du Magasin des requêtes sur la base de données azure_sys de votre serveur pour identifier rapidement les requêtes les plus longues. En général, ces requêtes ont tendance à consommer le plus de ressources. L’optimisation de vos requêtes les plus longues à s’exécuter peut améliorer les performances en libérant des ressources utilisées par d’autres requêtes exécutées sur votre système.
Cibler les requêtes avec des différences de performances
Magasin des requêtes segmente les données de performances en fenêtres de temps afin de suivre les performances d’une requête au fil du temps. Vous pouvez ainsi identifier exactement quelles requêtes contribuent à une augmentation du temps total passé. Par conséquent, vous pouvez effectuer un dépannage ciblé de votre charge de travail.
Ajuster les requêtes coûteuses
Lorsque vous identifiez une requête avec des performances non optimales, l’action que vous effectuez dépend de la nature du problème. Certaines de ces actions peuvent être les suivantes :
- Vérifiez que les statistiques sont à jour pour les tables sous-jacentes utilisées par la requête.
- Envisagez de réécrire les requêtes coûteuses. Par exemple, tirez parti du paramétrage des requêtes et réduisez l’utilisation du code SQL dynamique. Implémentez une logique optimale lors de la lecture de données, comme l’application du filtrage des données côté base de données, au lieu de le faire côté application.
Test A/B
Utilisez Magasin des requêtes pour comparer les performances des charges de travail avant et après un changement d’application que vous envisagez d’introduire, ou avant et après la migration. Exemples de scénarios d’utilisation du Magasin des requêtes pour évaluer l’impact de changements sur les performances des charges de travail :
- Migration entre les versions principales de PostgreSQL.
- Déploiement d’une nouvelle version d’une application.
- Modification de la quantité de ressources accordées au serveur.
- Modification de l’un des paramètres de serveur qui affectent le comportement du serveur.
- Création d’index manquants sur des tables référencées par des requêtes coûteuses.
- Migration de Azure Database pour PostgreSQL serveur unique vers Azure Database pour PostgreSQL serveur flexible.
Dans n’importe lequel de ces scénarios, appliquez le workflow suivant :
- Exécutez votre charge de travail avec Magasin des requêtes avant la modification planifiée pour générer une base de référence de performances.
- Appliquez les modifications souhaitées à un moment contrôlé dans le temps.
- Continuez à exécuter la charge de travail, suffisamment longtemps pour générer l’image de performances du système après la modification.
- Comparez les résultats avant et après la modification.
- Déterminez s’il faut conserver la modification ou la restaurer.
Identifier et améliorer les charges de travail improvisées
Certaines charges de travail n’ont pas de requêtes dominantes que vous pouvez ajuster pour améliorer les performances globales de l’application. Ces charges de travail se caractérisent généralement par un nombre relativement important de requêtes uniques, chacune d’elles consommant une partie des ressources système. Chaque requête unique est exécutée rarement, de sorte que leur consommation d’exécution individuellement n’est pas critique. D’autre part, étant donné que l’application génère de nouvelles requêtes tout le temps, une partie importante des ressources système est consacrée à la compilation des requêtes, ce qui n’est pas optimal. En général, cette situation se produit si votre application génère des requêtes (au lieu d’utiliser des procédures stockées ou des requêtes paramétrables), ou si elle s’appuie sur des frameworks de mappage de relationnel objet qui génèrent des requêtes par défaut.
Si vous contrôlez le code de l’application, vous pouvez envisager de réécrire la couche d’accès aux données pour utiliser des procédures stockées ou des requêtes paramétrables. Toutefois, cette situation peut également être améliorée sans modification de l’application en forçant le paramétrage des requêtes pour l’ensemble de la base de données (toutes les requêtes) ou pour les modèles de requête individuels avec le même hachage de requête.