Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Piano di query

Per ottenere informazioni sulle operazioni individuali necessarie per eseguire una query, puoi utilizzare il piano di query. Prima di lavorare con il piano di query, consigliamo di capire in che modo Amazon Redshift gestisce l'elaborazione delle query e crea piani di query. Per ulteriori informazioni, consultare Pianificazione di query e flusso di lavoro di esecuzione.

Per creare un piano di query, esegui il comando EXPLAIN seguito dal testo di query corrente. Il piano di query rende le seguenti informazioni:

Il comando EXPLAIN non esegue effettivamente la query. Mostra solamente il piano che verrà eseguito da Amazon Redshift se la query viene eseguita nelle condizioni operative attuali. Se modifichi lo schema o i dati di una tabella ed esegui nuovamente il comando ANALYZE per aggiornare i metadati statistici, il piano di query potrebbe essere differente.

L'output del piano di query che genera il comando EXPLAIN, è una visualizzazione semplificata e di alto livello dell'esecuzione della query. Non illustra i dettagli dell'elaborazione di query parallela. Per visualizzare le informazioni dettagliate, devi eseguire la stessa query, quindi ottenere le informazioni di riepilogo della query dalle visualizzazioni SVL_QUERY_SUMMARY o SVL_QUERY_REPORT. Per ulteriori informazioni sull'utilizzo di queste visualizzazioni, consultare Analisi del riepilogo della query.

Il seguente esempio illustra l'output EXPLAIN per una semplice query GROUP BY sulla tabella EVENT:

explain select eventname, count(*) from event group by eventname;

                            QUERY PLAN
-------------------------------------------------------------------
XN HashAggregate  (cost=131.97..133.41 rows=576 width=17)
  ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=17)

EXPLAIN restituisce i seguenti parametri per ogni operazione:

Operatori EXPLAIN

Questa sezione descrive brevemente gli operatori che visualizzi più spesso nell'output EXPLAIN. Per un elenco completo degli operatori, consultare EXPLAIN nella sezione relativa ai comandi SQL.

Operatore scansione sequenziale

L'operatore scansione sequenziale (Seq Scan) indica una scansione della tabella. Seq Scan scansiona ogni colonna della tabella in maniera sequenziale dall'inizio alla fine, valutando le limitazioni della query (nella clausola WHERE) per ogni riga.

Operatori di combinazione

Amazon Redshift seleziona gli operatori join basati sul progetto fisico delle tabelle combinate, la posizione dei dati necessari per il join e i requisiti specifici della stessa query.

Operatori di aggregazione

Il piano di query utilizza i seguenti operatori nelle query che implicano le funzioni aggregate e le operazioni GROUP BY.

Operatori di ordinamento

Il piano di query utilizza i seguenti operatori quando le query devono ordinare o unire gli insiemi dei risultati.

Operatori UNION, INTERSECT ed EXCEPT

Il piano di query utilizza i seguenti operatori per le query che implicano le funzioni aggregate e le operazioni dell'insieme con UNION, INTERSECT e EXCEPT.

Altri operatori

I seguenti operatori appaiono frequentemente anche nell'output EXPLAIN per le query di routine.

Combinazioni su EXPLAIN

L'ottimizzatore di query utilizza diversi tipi di combinazioni per recuperare i dati della tabella, a seconda della struttura della query e delle tabelle sottostanti. L'output EXPLAIN fa riferimento al tipo di combinazione, alla tabella utilizzata e al modo in cui i dati della tabella vengono distribuiti all'interno del cluster, al fine di descrivere in che modo viene elaborata la query.

Esempi di tipo di join

I seguenti esempi mostrano i diversi tipi di combinazione che può utilizzare l'ottimizzatore di query. Il tipo di combinazione utilizzato nel piano della query dipende dal progetto fisico delle tabelle coinvolte.

Esempio: eseguire un hash join di due tabelle

La seguente query combina EVENT e CATEGORY sulla colonna CATID. CATID è la chiave di distribuzione e di ordinamento per CATEGORY, ma non per EVENT. Un hash join viene eseguito con EVENT come tabella esterna e CATEGORY come tabella interna. Dato che CATEGORY è la tabella più piccola, il pianificatore trasmette una copia della stessa ai nodi di calcolo durante l'elaborazione della query, mediante l'uso di DS_BCAST_INNER. Il costo di combinazione in questo esempio rappresenta la maggior parte del costo cumulativo del piano.

explain select * from category, event where category.catid=event.catid;

                               QUERY PLAN
-------------------------------------------------------------------------
 XN Hash Join DS_BCAST_INNER  (cost=0.14..6600286.07 rows=8798 width=84)
   Hash Cond: ("outer".catid = "inner".catid)
   ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=35)
   ->  XN Hash  (cost=0.11..0.11 rows=11 width=49)
         ->  XN Seq Scan on category  (cost=0.00..0.11 rows=11 width=49)

Esempio: eseguire un merge join di due tabelle

La seguente query utilizza anche SELECT *, ma combina SALES e LISTING sulla colonna LISTID, dove LISTID è stato impostato come chiave di distribuzione e come chiave di ordinamento per entrambe le tabelle. Viene scelto un merge join e per la combinazione non è necessaria alcuna ridistribuzione dei dati (DS_DIST_NONE).

explain select * from sales, listing where sales.listid = listing.listid;
QUERY PLAN
-----------------------------------------------------------------------------
XN Merge Join DS_DIST_NONE  (cost=0.00..6285.93 rows=172456 width=97)
  Merge Cond: ("outer".listid = "inner".listid)
  ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=44)
  ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=53)

L'esempio seguente dimostra i diversi tipi di combinazione all'interno della stessa query. Come nell'esempio precedente, SALES e LISTING vengono combinati mediante l'operatore merge join, ma la terza tabella EVENT deve essere combinata con i risultati dell'operatore merge join. Ancora una volta, l'operatore merge join incorre in un costo di trasmissione.

explain select * from sales, listing, event
where sales.listid = listing.listid and sales.eventid = event.eventid;
                                  QUERY PLAN
----------------------------------------------------------------------------
XN Hash Join DS_BCAST_INNER  (cost=109.98..3871130276.17 rows=172456 width=132)
  Hash Cond: ("outer".eventid = "inner".eventid)
  ->  XN Merge Join DS_DIST_NONE  (cost=0.00..6285.93 rows=172456 width=97)
        Merge Cond: ("outer".listid = "inner".listid)
        ->  XN Seq Scan on listing  (cost=0.00..1924.97 rows=192497 width=44)
        ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=53)
  ->  XN Hash  (cost=87.98..87.98 rows=8798 width=35)
        ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=35)

Esempi: Join, Aggregate e Sort

La seguente query esegue un hash join delle tabelle SALES e EVENT, seguito da operazioni di distribuzione e aggregazione per verificare la funzione SUM raggruppata e la clausola ORDER BY. L'operatore Sort iniziale viene eseguito in parallelo sui nodi di calcolo. Quindi l'operatore Network invia i risultati al nodo principale, dove l'operatore Merge produce i risultati finali ordinati.

explain select eventname, sum(pricepaid) from sales, event 
where sales.eventid=event.eventid group by eventname
order by 2 desc;
                                           QUERY PLAN
---------------------------------------------------------------------------------
 XN Merge  (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
  Merge Key: sum(sales.pricepaid)
  ->  XN Network  (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
        Send to leader
        ->  XN Sort  (cost=1002815366604.92..1002815366606.36 rows=576 width=27)
              Sort Key: sum(sales.pricepaid)
              ->  XN HashAggregate  (cost=2815366577.07..2815366578.51 rows=576 width=27)
                    ->  XN Hash Join DS_BCAST_INNER  (cost=109.98..2815365714.80 rows=172456 width=27)
                          Hash Cond: ("outer".eventid = "inner".eventid)
                          ->  XN Seq Scan on sales  (cost=0.00..1724.56 rows=172456 width=14)
                          ->  XN Hash  (cost=87.98..87.98 rows=8798 width=21)
                                ->  XN Seq Scan on event  (cost=0.00..87.98 rows=8798 width=21)

Ridistribuzione dei dati

L'output EXPLAIN per le combinazioni, inoltre, specifica un metodo per come verranno spostati i dati all'interno di un cluster, così che la combinazione sia più semplice. Questo movimento di dati può essere sia una trasmissione che una ridistribuzione. In una trasmissione, i valori dei dati da un lato della combinazione vengono copiati da ogni nodo di calcolo su ogni altro nodo di calcolo, così che ognuno di essi finisca con una copia completa dei dati. In una ridistribuzione, la partecipazione dei valori dei dati viene inviata dalla loro sezione attuale alla nuova sezione (possibilmente su un nodo differente). Solitamente i dati vengono ridistribuiti per far corrispondere la chiave di distribuzione dell'altra tabella che ha partecipato alla combinazione, nel caso in cui la chiave di distribuzione sia una delle colonne di combinazione. Se nessuna delle tabelle dispone di chiavi di distribuzione su una delle colonne di combinazione, entrambe le tabelle vengono distribuite o la tabella interna viene trasmessa a ogni nodo.

L'output EXPLAIN fa riferimento anche alle tabelle esterne e interne. La tabella interna viene scansionata per prima e appare più vicina al fondo del piano di query. La tabella interna è la tabella in cui si trovano le corrispondenza. Questa si trova solitamente in memoria, di solito è la tabella di origine per l'hashing e, probabilmente, è la tabella più piccola delle due combinate. La tabella esterna è la sorgente delle righe da combinare con la tabella interna. Viene letta solitamente dal disco. L'ottimizzatore di query sceglie la tabella interne e quella esterna a seconda delle statistiche del database, che provengono dall'esecuzione più recente del comando ANALYZE. L'ordine delle tabelle nella clausola FROM di una query non determina quale sia la tabella esterne né quella interna.

Utilizza i seguenti attributi nei piani di query, per identificare come verranno spostati i dati per facilitare una query: