Gebruiksscenario's voor querystore - Azure Database for PostgreSQL - Flexibele server
VAN TOEPASSING OP: 
Azure Database for PostgreSQL - Flexibele server
U kunt querystore gebruiken in een groot aantal scenario's waarin het bijhouden en onderhouden van voorspelbare workloadprestaties essentieel is. Bekijk de volgende voorbeelden:
- Dure query's identificeren en afstemmen.
- Voer A/B-tests uit.
- Geïmproviseerde workloads identificeren en verbeteren.
Dure query's identificeren en afstemmen
Langlopende query's identificeren
Gebruik querystoreweergaven in de azure_sys database van uw server om snel de langst lopende query's te identificeren. Deze query's verbruiken meestal de meeste resources. Door uw langst lopende query's te optimaliseren, kunt u de prestaties verbeteren door resources vrij te maken die worden gebruikt door andere query's die op uw systeem worden uitgevoerd.
Doelquery's met prestatie-delta's
Query store segmenteert de prestatiegegevens in tijdvensters, zodat u de prestaties van een query in de loop van de tijd kunt bijhouden. Dit helpt u precies te bepalen welke query's bijdragen aan een toename van de totale tijd die wordt besteed. Als gevolg hiervan kunt u problemen met een bereik van uw workload oplossen.
Dure query's afstemmen
Wanneer u een query identificeert met suboptimale prestaties, is de actie die u uitvoert afhankelijk van de aard van het probleem. Een aantal van deze acties kan het volgende zijn:
- Zorg ervoor dat de statistieken up-to-date zijn voor de onderliggende tabellen die door de query worden gebruikt.
- Overweeg dure query's te herschrijven. Maak bijvoorbeeld gebruik van queryparameterisatie en verminder het gebruik van ad-hoc SQL. Implementeer optimale logica bij het lezen van gegevens, zoals het toepassen van gegevensfilters aan de databasezijde, in plaats van dit te doen aan de toepassingszijde.
A/B-tests uitvoeren
Gebruik query store om de prestaties van workloads te vergelijken voor en na een wijziging in een toepassing die u wilt introduceren, of vóór en na de migratie. Voorbeeldscenario's voor het gebruik van querystore om de impact van wijzigingen in de workloadprestaties te beoordelen:
- Migreren tussen primaire versies van PostgreSQL.
- Een nieuwe versie van een toepassing implementeren.
- Het wijzigen van de hoeveelheid resources die aan de server zijn verleend.
- Het wijzigen van een van de serverparameters die van invloed zijn op het gedrag van de server.
- Ontbrekende indexen maken voor tabellen waarnaar wordt verwezen door dure query's.
- Migreren van Azure Database for PostgreSQL enkele server naar Azure Database for PostgreSQL flexibele server.
Pas in een van deze scenario's de volgende werkstroom toe:
- Voer uw workload uit met querystore vóór de geplande wijziging om een prestatiebasislijn te genereren.
- Pas de gewenste wijzigingen op een bepaald moment in de tijd toe.
- Ga door met het uitvoeren van de workload gedurende voldoende tijd, zodat u na de wijziging een duidelijk beeld kunt krijgen van de prestaties van het systeem.
- Vergelijk de resultaten van vóór en na de wijziging.
- Bepaal of u de wijziging wilt behouden of terugdraaien.
Geïmproviseerde workloads identificeren en verbeteren
Sommige workloads hebben geen dominante query's die u kunt afstemmen om de algehele prestaties van toepassingen te verbeteren. Deze workloads worden doorgaans gekenmerkt door een relatief groot aantal unieke query's, die elk een deel van systeembronnen verbruiken. Elke unieke query wordt onregelmatig uitgevoerd, dus individueel is het runtimeverbruik niet kritiek. Aan de andere kant, gezien het feit dat de toepassing steeds nieuwe query's genereert, wordt er een aanzienlijk deel van de systeembronnen besteed aan het compileren van query's, wat niet optimaal is. Deze situatie treedt meestal op als uw toepassing query's genereert (in plaats van opgeslagen procedures of geparameteriseerde query's te gebruiken) of als deze afhankelijk is van frameworks voor object-relationele toewijzing die standaard query's genereren.
Als u de toepassingscode beheert, kunt u overwegen de gegevenstoegangslaag opnieuw te schrijven voor het gebruik van opgeslagen procedures of geparameteriseerde query's. Deze situatie kan echter ook worden verbeterd zonder toepassingswijzigingen, door queryparameterisatie af te dwingen voor de hele database (alle query's) of voor de afzonderlijke querysjablonen met dezelfde query-hash.