Amazon Redshift non supporterà più l'uso delle UDF Python dopo il 30 giugno 2026. Inizieremo ad applicarlo gradualmente. Per ulteriori informazioni sui dettagli della fine del ciclo di vita e sulle opzioni di migrazione di Python, consulta la post sul blog
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à.
Miglioramento delle prestazioni della query
Di seguito vengono riportati problemi comuni che riguardano le prestazioni delle query di Amazon Redshift, con istruzioni su come diagnosticarli e risolverli.
Statistiche della tabella mancanti o scadute
Se le statistiche della tabella sono mancanti o scadute, potresti visualizzare quanto segue:
-
Un messaggio di avviso nei risultati del comando EXPLAIN.
-
Un evento di avviso statistiche mancanti su STL_ALERT_EVENT_LOG. Per ulteriori informazioni, consultare Revisione degli avvisi di query.
Per risolvere questo problema, esegui il comando ANALYZE.
Loop nidificato
Se è presente un loop nidificato, potresti visualizzare un evento di avviso loop nidificato su STL_ALERT_EVENT_LOG. Per identificare questo tipo di evento, puoi anche eseguire la query su Identificazione di query con loop nidificati. Per ulteriori informazioni, consulta Revisione degli avvisi di query.
Per risolvere questo problema, esamina la presenza di cross-join nella query e rimuovili, se possibile. Cross-joins sono join senza una condizione di join che danno come risultato il prodotto cartesiano di due tabelle. Generalmente vengono eseguite come combinazioni di loop nidificati, che sono le più lente tra i tipi di combinazione possibili.
Hash join
Se è presente un hash join, potresti visualizzare quanto segue:
-
Le operazioni hash e hash join nel piano di query. Per ulteriori informazioni, consultare Analisi del piano di query.
-
Una fase HJOIN nel segmento con il valore maxtime più alto su SVL_QUERY_SUMMARY. Per ulteriori informazioni, consultare Utilizzo della visualizzazione SVL_QUERY_SUMMARY.
Il problema può essere risolto in diversi modi:
-
Se possibile, riscrivi la query per utilizzare un merge join. Puoi farlo mediante la specificazione di quelle colonne di combinazione che sono sia chiavi di distribuzione che chiavi di ordinamento.
-
Se la fase HJOIN su SVL_QUERY_SUMMARY ha un valore molto alto nel campo relativo alle righe rispetto al valore delle righe nella fase finale RETURN nella query, verifica se puoi riscrivere la query per combinarla su un'unica colonna. Se una query non viene combinata su un'unica colonna, ad esempio una chiave primaria, aumenta il numero di righe coinvolte nella combinazione.
Righe fantasma o righe di cui non è stato eseguito il commit
Se sono presenti righe fantasma o non eseguite, potresti visualizzare un evento di avviso su STL_ALERT_EVENT_LOG che indica l'eccessiva presenza di righe fantasma. Per ulteriori informazioni, consultare Revisione degli avvisi di query.
Il problema può essere risolto in diversi modi:
-
Cercare nella scheda Carichi della console Amazon Redshift le operazioni di carico attive su tutte le tabelle della query. Se visualizzi operazioni di carico attive, attendi il loro completamento prima di intraprendere altre operazioni.
-
Se non ci sono operazioni di carico attive, esegui il comando VACUUM sulle tabelle della query al fine di rimuovere le righe eliminate.
Righe non ordinate o ordinate in modo errato
Se sono presenti delle righe non ordinate o ordinate male, potresti visualizzare un evento di avviso del filtro molto selettivo su STL_ALERT_EVENT_LOG. Per ulteriori informazioni, consultare Revisione degli avvisi di query.
Inoltre, puoi verificare la presenza di grandi aree non ordinate nelle tabelle della tua query, eseguendo la stessa su Identificazione delle tabelle con differenza di dati o con righe non ordinate.
Il problema può essere risolto in diversi modi:
-
Esegui il comando VACUUM sulle tabelle della query per riordinare le righe.
-
Per verificare se è possibile apportare dei miglioramenti, rivedi la chiave di ordinamento sulle tabelle della query. Ricordati di comparare le prestazioni di questa query a quelle di altre query importanti e al sistema globale prima di apportare delle modifiche. Per ulteriori informazioni, consultare Chiavi di ordinamento.
Distribuzione dei dati non ottimale
Se la distribuzione dei dati non è ottimale, potresti visualizzare quanto segue:
-
Su STL_ALERT_EVENT_LOG apparirà un evento di avviso di una grande trasmissione, distribuzione o un'esecuzione seriale. Per ulteriori informazioni, consultare Revisione degli avvisi di query.
-
Le sezioni non stanno processando approssimativamente lo stesso numero di righe per una fase specifica. Per ulteriori informazioni, consultare Utilizzo della vista SVL_QUERY_REPORT.
-
Le sezioni non stanno impiegando approssimativamente lo stesso tempo per una fase specifica. Per ulteriori informazioni, consultare Utilizzo della vista SVL_QUERY_REPORT.
Se nessuna delle opzioni precedenti è vera, puoi anche verificare se qualche tabella nella tua query presenta una differenza di dati, eseguendo la stessa su Identificazione delle tabelle con differenza di dati o con righe non ordinate.
Per risolvere questo problema, esamina gli stili di distribuzione delle tabelle nella query e determina se è possibile apportare dei miglioramenti. Ricordati di comparare le prestazioni di questa query a quelle di altre query importanti e al sistema globale prima di apportare delle modifiche. Per ulteriori informazioni, consultare Distribuzione dei dati per l’ottimizzazione delle query.
Memoria insufficiente allocata alla query
Quando una query richiede più memoria di quella allocata, Amazon Redshift scrive i risultati intermedi in eccesso su disco. Questa operazione si chiama spilling to disk. Amazon Redshift scrive prima i dati fuoriusciti sul disco locale e, se supera la capacità del disco locale, i dati vengono trasferiti in Amazon S3. Le fasi di query che hanno maggiori probabilità di verificarsi sono gli hash join, le aggregazioni (come GROUP BY e DISTINCT), le funzioni delle finestre e gli ordinamenti (ORDER BY) su set di dati di grandi dimensioni.
La propagazione su disco rallenta la fuoriuscita della query, poiché l'accesso al disco è molto più lento della memoria. Poiché il disco locale e la I/O larghezza di banda sono condivisi in tutto il cluster, una forte perdita di dati può anche rallentare l'esecuzione contemporanea di altre query. La riduzione delle perdite migliora sia la latenza delle singole query che il throughput complessivo del cluster.
Identifica le query che generano perdite. Interroga SYS_QUERY_DETAIL e rivedi le colonne spilled_block_local_disk andspilled_block_remote_disk. Le query con un spilled_block_remote_disk valore elevato si diffondono oltre il disco locale e traggono i maggiori vantaggi dal tuning. In un cluster predisposto, puoi anche esaminare la metrica in. query_temp_blocks_to_disk SVL_QUERY_METRICS_SUMMARY
Come ridurre la fuoriuscita del disco
-
Ridurre il volume dei dati intermedi. Filtra prima, seleziona solo le colonne di cui hai bisogno e, se possibile, esegui la preaggregazione in modo che meno righe confluiscano in join, aggregazioni e ordinamenti.
-
Suddividi le query di grandi dimensioni in passaggi. Materializza i risultati intermedi in tabelle temporanee (CREATE TEMP TABLE AS) in modo che ogni passaggio venga eseguito con un minore ingombro in memoria e abbia meno probabilità di fuoriuscire. Assegna alla tabella temporanea una chiave di distribuzione e ordinamento appropriata ed esegui ANALYZE in modo che i passaggi a valle vengano eseguiti in modo efficiente.
-
Assegnate più memoria alla query aumentando temporaneamente il numero di slot se utilizzate il WLM manuale (vedete). wlm_query_slot_count
-
Aggiungete nodi o passate a un tipo di nodo più grande quando la perdita è inevitabile a causa del volume di dati.
Monitora le fuoriuscite in modo proattivo. Crea una regola di monitoraggio delle interrogazioni (QMR) sulla metrica. query_temp_blocks_to_disk Questa metrica misura lo spazio temporaneo su disco utilizzato per risultati intermedi, in blocchi da 1 MB. Quindi scegli un'azione:
- log
-
Registra la richiesta per la revisione.
- abort
-
Interrompe l'interrogazione prima che la sua fuoriuscita danneggi gli altri carichi di lavoro.
Ad esempio, query_temp_blocks_to_disk > 100000 (circa 100 GB) registra o interrompe le query che generano quantità insolitamente elevate. Adatta la soglia al tuo cluster o gruppo di lavoro. Su un cluster predisposto, configura QMR tramite le code WLM. Su Redshift Serverless, configuralo tramite i limiti delle query dei gruppi di lavoro. Per ulteriori informazioni, consulta Regole di monitoraggio delle query WLM.
Clausola WHERE non ottimale
Se la tua clausola WHERE causa un'eccessiva scansione della tabella, potresti visualizzare una fase SCAN nel segmento con il valore maxtime più alto su SVL_QUERY_SUMMARY. Per ulteriori informazioni, consultare Utilizzo della visualizzazione SVL_QUERY_SUMMARY.
Per risolvere questo problema, aggiungi una clausola WHERE alla query basata sulla colonna di ordinamento principale della tabella più grande. Grazie a questo approccio, è possibile ridurre al minimo i tempi di scansione. Per ulteriori informazioni, consultare Best practice di Amazon Redshift per la progettazione di tabelle.
Predicato poco restrittivo
Se la tua query dispone di un predicato poco restrittivo, potresti visualizzare una fase SCAN nel segmento con il valore maxtime più alto su SVL_QUERY_SUMMARY, il quale ha un valore rows molto alto rispetto al valore rows nella fase finale RETURN nella query. Per ulteriori informazioni, consultare Utilizzo della visualizzazione SVL_QUERY_SUMMARY.
Per risolvere questo problema. prova ad aggiungere un predicato alla query, oppure rendi il predicato esistente più restrittivo per restringere l'output.
Insieme di risultati molto grande
Se la query restituisce un set di risultati molto ampio, considerare la riscrittura della query per utilizzare UNLOAD e scrivere i risultati in Amazon S3. Questo approccio migliorerà le prestazioni della fase RETURN, traendo vantaggio dall'elaborazione parallela. Per ulteriori informazioni sulla verifica di un insieme di risultati molto grande, consultare Utilizzo della visualizzazione SVL_QUERY_SUMMARY.
Elenco SELECT grande
Se la tua query dispone di un elenco SELECT insolitamente grande, potresti visualizzare un valore bytes più alto rispetto al valore rows di tutte le fasi (in relazione alle altre fasi) su SVL_QUERY_SUMMARY. Questo valore bytes alto può indicare che stai selezionando molte colonne. Per ulteriori informazioni, consultare Utilizzo della visualizzazione SVL_QUERY_SUMMARY.
Per risolvere questo problema, rivedi le colonne che stai selezionando e verifica se puoi rimuoverne qualcuna.
