Scenari di utilizzo per Query Store - Database di Azure per PostgreSQL - Server flessibile
SI APPLICA A:
Database di Azure per PostgreSQL - Server flessibile
È possibile usare Query Store in svariati scenari, in cui è fondamentale garantire prestazioni dei carichi di lavoro prevedibili e tenerne traccia. Vedi gli esempi seguenti:
- Identificazione e ottimizzazione delle query più costose.
- Test A/B.
- Mantenere stabili le prestazioni durante gli aggiornamenti.
- Identificazione e miglioramento di carichi di lavoro improvvisati.
Identificare e ottimizzare le query con costo elevato
Identificare le query in esecuzione da più tempo
Usare le viste di Query Store nel database azure_sys del server per identificare rapidamente le query con esecuzione più lunga. Queste query tendono in genere a usare la maggior parte delle risorse. L'ottimizzazione delle query con esecuzione più lunga può migliorare le prestazioni liberando risorse usate da altre query in esecuzione nel sistema.
Identificare le query con valori differenziali nelle prestazioni
Query Store suddivide i dati sulle prestazioni in intervalli di tempo, in modo da poter tenere traccia delle prestazioni di una query nel tempo. In questo modo è possibile identificare esattamente quali query contribuiscono ad aumentare il tempo totale impiegato. Di conseguenza è possibile risolvere in modo mirato i problemi del carico di lavoro.
Ottimizzare query costose
Quando si identifica una query con prestazioni non ottimali, l'azione eseguita dipende dalla natura del problema. Alcune di queste azioni potrebbero essere:
- Assicurarsi che le statistiche siano aggiornate per le tabelle sottostanti usate dalla query.
- Considerare la possibilità di riscrivere le query con costo elevato. Ad esempio, sfruttare i vantaggi della parametrizzazione delle query e ridurre l'uso di SQL dinamico. Implementare la logica ottimale durante la lettura dei dati, ad esempio l'applicazione di filtri dei dati sul lato database, invece di eseguirla sul lato applicazione.
Test A/B
Usare Query Store per confrontare le prestazioni del carico di lavoro prima e dopo una modifica dell'applicazione che si prevede di introdurre o prima e dopo la migrazione. Scenari di esempio per l'uso di Query Store per valutare l'impatto delle modifiche apportate alle prestazioni del carico di lavoro:
- Migrazione tra le versioni principali di PostgreSQL.
- Implementazione di una nuova versione di un'applicazione.
- Modifica della quantità di risorse concesse al server.
- Modifica di uno dei parametri del server che influiscono sul comportamento del server.
- Creazione di indici mancanti nelle tabelle a cui fanno riferimento query con costo elevato.
- Migrazione da Database di Azure per PostgreSQL server singolo a server flessibile Database di Azure per PostgreSQL.
In tutti questi scenari applicare il flusso di lavoro seguente:
- Eseguire il carico di lavoro con Query Store prima della modifica pianificata per generare una baseline di prestazioni.
- Applicare le modifiche desiderate in un momento controllato.
- Continuare a eseguire il carico di lavoro, abbastanza a lungo per generare l'immagine delle prestazioni del sistema dopo la modifica.
- Confrontare i risultati di prima e dopo la modifica.
- Decidere se mantenere la modifica o eseguire il rollback.
Identificare e migliorare carichi di lavoro improvvisati
Alcuni carichi di lavoro non includono query dominanti che è possibile ottimizzare per migliorare le prestazioni complessive dell'applicazione. Questi carichi di lavoro sono in genere caratterizzati da un numero relativamente elevato di query univoche, ognuna delle quali consuma una parte delle risorse di sistema. Ogni query univoca viene eseguita raramente, quindi singolarmente il consumo di runtime non è critico. D'altra parte, dato che l'applicazione genera sempre nuove query, una parte significativa delle risorse di sistema viene impiegata per la compilazione delle query, che non è ottimale. In genere, questa situazione si verifica se l'applicazione genera query (invece di usare le stored procedure o le query con parametri) o se si basa su framework di mapping relazionale a oggetti che generano query per impostazione predefinita.
Se si ha il controllo del codice dell'applicazione, è possibile riscrivere il livello di accesso ai dati per usare stored procedure o query con parametri. Tuttavia, questa situazione può essere migliorata anche senza modifiche all'applicazione forzando la parametrizzazione delle query per l'intero database (tutte le query) o per i singoli modelli di query con lo stesso hash di query.