Condividi tramite

Scenari di utilizzo per Query Store - Database di Azure per PostgreSQL - Server flessibile

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

È possibile usare l'archivio query in un'ampia gamma di scenari in cui il rilevamento e la gestione delle prestazioni prevedibili del carico di lavoro sono fondamentali. Vedi gli esempi seguenti:

  • Identificare e ottimizzare query costose.
  • eseguire test A/B
  • Identificare e migliorare carichi di lavoro improvvisati.

Identificare e ottimizzare le query con costo elevato

Identificare le query a esecuzione prolungata

Usare le viste dell'archivio query nel azure_sys database del server per identificare rapidamente le query con esecuzione più lunga. Queste query tendono a usare la maggior parte delle risorse. Ottimizzando le query in esecuzione da più tempo, è possibile migliorare le prestazioni liberando risorse che possono essere 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 eseguire la risoluzione dei problemi con ambito del carico di lavoro.

Otimizzare le query dispendiose

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 ad hoc. Implementare la logica ottimale durante la lettura dei dati, ad esempio applicando i filtri dei dati sul lato database, anziché farlo sul lato applicazione.

Eseguire 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 dal Database di Azure per PostgreSQL - Server singolo al Database di Azure per PostgreSQL - Server flessibile.

In tutti questi scenari applicare il flusso di lavoro seguente:

  1. Eseguire il carico di lavoro con Query Store prima della modifica pianificata per generare una baseline di prestazioni.
  2. Applicare le modifiche desiderate in un momento controllato.
  3. Continuare a eseguire il carico di lavoro in un periodo di tempo sufficiente, in modo da poter avere una visione chiara delle prestazioni del sistema dopo la modifica.
  4. Confrontare i risultati ottenuti prima e dopo la modifica.
  5. 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 il consumo individuale del runtime non è critico. D'altra parte, dato che l'applicazione genera continuamente nuove query, una parte significativa delle risorse di sistema viene impiegata per la compilazione delle query, ma ciò non è l'ideale. 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, considerare la possibilità di riscrivere il livello di accesso ai dati per usare le stored procedure o le query con parametri. Tuttavia, questa situazione può essere migliorata anche senza modifiche dell'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.

Contenuto correlato