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à.

Suggerimenti di Amazon Redshift Advisor

Amazon Redshift Advisor fornisce raccomandazioni su come ottimizzare il cluster Amazon Redshift per migliorare le prestazioni e ridurre i costi operativi. Puoi trovare delle spiegazioni su ogni raccomandazione nella console, come descritto precedentemente. Ulteriori dettagli sulle raccomandazioni sono forniti nelle sezioni seguenti.

Comprimi oggetti di file Amazon S3 caricati da COPY

Il COPY comando sfrutta l'architettura massively parallel processing (MPP) di Amazon Redshift per leggere e caricare dati in parallelo. Può leggere file da Amazon S3, tabelle DynamoDB e un output di testo da uno o più host remoti.

Quando si caricano grandi quantità di dati, consigliamo vivamente di utilizzare il COPY comando per caricare file di dati compressi da S3. La compressione di set di dati di grandi dimensioni consente di risparmiare tempo durante il caricamento dei file in Amazon S3. COPYpuò anche velocizzare il processo di caricamento decomprimendo i file man mano che vengono letti.

Analisi

COPYI comandi a lunga esecuzione che caricano set di dati non compressi di grandi dimensioni spesso offrono l'opportunità di un notevole miglioramento delle prestazioni. L'analisi Advisor identifica i COPY comandi che caricano set di dati non compressi di grandi dimensioni. In tal caso, Advisor genera un suggerimento per implementare la compressione sui file di origine in Amazon S3.

Raccomandazione

Assicurati che ogni dispositivo COPY che carica una quantità significativa di dati o funzioni per un periodo di tempo significativo acquisisca oggetti di dati compressi da Amazon S3. Puoi identificare i COPY comandi che caricano set di dati non compressi di grandi dimensioni da Amazon S3 eseguendo il seguente SQL comando come superutente.

SELECT
    wq.userid, query, exec_start_time AS starttime, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY 1, 2, 3, 7
HAVING SUM(transfer_size) = SUM(data_size) 
AND SUM(transfer_size)/(1024*1024) >= 5
ORDER BY 6 DESC, 5 DESC;         
          

Se i dati in gestione temporanea rimangono in Amazon S3 dopo il caricamento, evento comune nelle architetture dei data lake, l'archiviazione di questi dati in un formato compresso può ridurre i costi di archiviazione.

Consigli di implementazione

Isolare molteplici database attivi

Come best practice, consigliamo di isolare i database in Amazon Redshift gli uni dagli altri. Le query sono eseguite in uno specifico database e non possono accedere ai dati da qualsiasi altro database sul cluster. Tuttavia, le query eseguite in tutti i database di un cluster condividono lo stesso spazio di storage di cluster sottostante e le stesse risorse di calcolo. Quando un singolo cluster contiene molteplici database attivi, i relativi carichi di lavoro sono spesso non correlati.

Analisi

L'analisi di Advisor esamina tutti i database sul cluster per verificare la presenza di carichi di lavoro attivi in esecuzione nello stesso momento. Se questi carichi sono presenti, Advisor genera un suggerimento per prendere in considerazione la migrazione dei database verso cluster Amazon Redshift distinti.

Raccomandazione

Prendi in considerazione lo spostamento di ogni database sottoposto a query a un cluster dedicato distinto. Utilizzando un cluster distinto è possibile ridurre i conflitti tra le risorse e migliorare le prestazioni delle query. Questo perché è possibile definire la dimensione di ogni cluster in funzione delle esigenze di archiviazione, costi e prestazioni di ogni carico di lavoro. Inoltre, i carichi di lavoro non correlati spesso utilizzano differenti configurazioni di gestione del carico di lavoro.

Per identificare quali database vengono utilizzati attivamente, puoi eseguire questo SQL comando come superutente.

SELECT database,
  COUNT(*) as num_queries,
  AVG(DATEDIFF(sec,starttime,endtime)) avg_duration,
  MIN(starttime) as oldest_ts,
  MAX(endtime) as latest_ts
FROM stl_query
WHERE userid > 1
GROUP BY database;            
         

Consigli di implementazione

Riallocare la memoria di gestione del carico di lavoro () WLM

Amazon Redshift instrada le query degli utenti a Manuale di implementazione WLM per l'elaborazione. La gestione del carico di lavoro (WLM) definisce il modo in cui tali interrogazioni vengono indirizzate alle code. Amazon Redshift assegna a ogni coda una parte della memoria disponibile del cluster. La memoria di una coda viene ripartita tra gli slot di query della coda.

Quando una coda è configurata con più slot di quelli richiesti dal carico di lavoro, la memoria allocata a questi slot inutilizzati è sottoutilizzata. La riduzione degli slot configurati in funzione delle esigenze del carico di lavoro massimo consente di ridistribuire la memoria sottoutilizzata agli slot attivi e può quindi migliorare le prestazioni delle query.

Analisi

L'analisi di Advisor esamina le esigenze in materia di simultaneità del carico di lavoro per identificare le code di query con slot non utilizzati. Advisor genera una raccomandazione per ridurre il numero di slot in una coda quando trova quanto segue:

Raccomandazione

La riduzione degli slot configurati in funzione delle esigenze del carico di lavoro massimo consente di ridistribuire la memoria sottoutilizzata agli slot attivi. Prendi in considerazione la riduzione del numero di slot configurati per le code i cui slot non sono mai stati completamente utilizzati. Per identificare queste code, è possibile confrontare i requisiti degli slot orari di punta per ciascuna coda eseguendo il comando seguente come superutente. SQL

WITH
 generate_dt_series AS (select sysdate - (n * interval '5 second') as dt from (select row_number() over () as n from stl_scan limit 17280)),
 apex AS (
     SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
     FROM
         (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
         FROM stl_wlm_query wq
         JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 5)
         JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
         WHERE wq.userid > 1 AND wq.service_class > 5) iq
     GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
     maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                     from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class - 5 AS queue, apex.service_class, apex.num_query_tasks AS max_wlm_concurrency, maxes.d AS day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;            
         

La max_service_class_slots colonna rappresenta il numero massimo di slot di WLM interrogazione nella coda di interrogazione per quell'ora. Se esistono delle code sottoutilizzate, implementare l'ottimizzazione della riduzione degli slot modificando un gruppo di parametri, come descritto nella Guida alla gestione di Amazon Redshift.

Consigli di implementazione

Salta l'analisi di compressione durante COPY

Quando carichi dati in una tabella vuota con la codifica di compressione dichiarata con il COPY comando, Amazon Redshift applica la compressione dello storage. Questa ottimizzazione assicura che i dati nel cluster siano archiviati in modo efficace anche quando caricati da utenti finali. L'analisi richiesta per applicare la compressione può durare un certo tempo.

Analisi

L'analisi Advisor verifica le COPY operazioni che sono state ritardate dall'analisi automatica della compressione. L'analisi determina le codifiche di compressione campionando i dati durante il caricamento degli stessi. Questo campionamento è simile a quello eseguito dal comando ANALYZE COMPRESSION.

Quando caricate i dati come parte di un processo strutturato, ad esempio in un batch overnight extract, transform, load (ETL), potete definire preventivamente la compressione. Puoi anche ottimizzare le definizioni di tabella per ignorare in modo permanente questa fase senza alcun impatto negativo.

Raccomandazione

Per migliorare la COPY reattività saltando la fase di analisi della compressione, implementate una delle due opzioni seguenti:

La migliore soluzione è generalmente di utilizzare la codifica di colonna durante la creazione di tabelle in quanto questo approccio consente di archiviare dati compressi sul disco. È possibile utilizzare il ANALYZE COMPRESSION comando per suggerire codifiche di compressione, ma è necessario ricreare la tabella per applicare tali codifiche. Per automatizzare questo processo, è possibile utilizzare AWSColumnEncodingUtility, trovato su. GitHub

Per identificare COPY le operazioni recenti che hanno attivato l'analisi di compressione automatica, esegui il SQL comando seguente.

  WITH xids AS (
    SELECT xid FROM stl_query WHERE userid>1 AND aborted=0 
    AND querytxt = 'analyze compression phase 1' GROUP BY xid
    INTERSECT SELECT xid FROM stl_commit_stats WHERE node=-1)
SELECT a.userid, a.query, a.xid, a.starttime, b.complyze_sec, 
    a.copy_sec, a.copy_sql
FROM (SELECT q.userid, q.query, q.xid, date_trunc('s',q.starttime) 
    starttime, substring(querytxt,1,100) as copy_sql, 
    ROUND(datediff(ms,starttime,endtime)::numeric / 1000.0, 2) copy_sec
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt ilike 'copy %from%' OR querytxt ilike '% copy %from%') 
    AND querytxt not like 'COPY ANALYZE %') a
LEFT JOIN (SELECT xid, 
    ROUND(sum(datediff(ms,starttime,endtime))::numeric / 1000.0,2) complyze_sec 
    FROM stl_query q JOIN xids USING (xid)
    WHERE (querytxt like 'COPY ANALYZE %' 
    OR querytxt like 'analyze compression phase %') 
    GROUP BY xid ) b ON a.xid = b.xid
WHERE b.complyze_sec IS NOT NULL ORDER BY a.copy_sql, a.starttime;
         

Consigli di implementazione

Suddividi gli oggetti Amazon S3 caricati da COPY

Il COPY comando sfrutta l'architettura massively parallel processing (MPP) di Amazon Redshift per leggere e caricare dati dai file su Amazon S3. Il COPY comando carica i dati in parallelo da più file, dividendo il carico di lavoro tra i nodi del cluster. Per ottenere un throughput ottimale, ti consigliamo vivamente di suddividere i dati in più file per beneficiare dall'elaborazione parallela.

Analisi

L'analisi Advisor identifica COPY i comandi che caricano set di dati di grandi dimensioni contenuti in un numero limitato di file archiviati in Amazon S3. COPYI comandi a lunga esecuzione che caricano set di dati di grandi dimensioni da pochi file spesso offrono l'opportunità di un notevole miglioramento delle prestazioni. Quando Advisor rileva che questi COPY comandi richiedono molto tempo, crea un consiglio per aumentare il parallelismo suddividendo i dati in file aggiuntivi in Amazon S3.

Raccomandazione

In questo caso, consigliamo le seguenti operazioni, elencate in ordine di priorità:

Alcuni COPY comandi caricano una quantità significativa di dati o vengono eseguiti per una durata significativa. Per questi comandi consigliamo di caricare un numero di oggetti dati da Amazon S3 equivalente a un multiplo del numero di sezioni nel cluster. Per identificare quanti oggetti S3 sono stati caricati da ogni COPY comando, esegui il SQL codice seguente come superutente.

SELECT
    query, COUNT(*) num_files,
    ROUND(MAX(wq.total_exec_time/1000000.0),2) execution_secs,
    ROUND(SUM(transfer_size)/(1024.0*1024.0),2) total_mb,
    SUBSTRING(querytxt,1,60) copy_sql
FROM stl_s3client s
JOIN stl_query q USING (query)
JOIN stl_wlm_query wq USING (query)
WHERE s.userid>1 AND http_method = 'GET'
    AND POSITION('COPY ANALYZE' IN querytxt) = 0
    AND aborted = 0 AND final_state='Completed'
GROUP BY query, querytxt
HAVING (SUM(transfer_size)/(1024*1024))/COUNT(*) >= 2
ORDER BY CASE
WHEN COUNT(*) < (SELECT max(node)+1 FROM stv_slices) THEN 1
WHEN COUNT(*) < (SELECT COUNT(*) FROM stv_slices WHERE node=0) THEN 2
ELSE 2+((COUNT(*) % (SELECT COUNT(*) FROM stv_slices))/(SELECT COUNT(*)::DECIMAL FROM stv_slices))
END, (SUM(transfer_size)/(1024.0*1024.0))/COUNT(*) DESC;   
            
         

Consigli di implementazione

Aggiornamento delle statistiche delle tabelle

Amazon Redshift utilizza un ottimizzatore di query basato sui costi per scegliere il piano di esecuzione ottimale per le query. Le stime dei costi si basano sulle statistiche delle tabelle raccolte utilizzando il ANALYZE comando. Quando le statistiche di una tabella risultano non aggiornate o mancanti, il database potrebbe scegliere un piano meno efficiente per l'esecuzione delle query, soprattutto per quelle complesse. Disporre di statistiche aggiornate consente di eseguire query complesse nel minor tempo possibile.

Analisi

L'analisi Advisor tiene traccia delle tabelle le cui statistiche sono out-of-date o mancanti. Esamina i metadati di accesso alle tabelle che sono associati a query complesse. Se nelle tabelle a cui si accede di frequente con schemi complessi mancano statistiche, Advisor crea un consiglio fondamentale da eseguireANALYZE. Se le tabelle a cui si accede di frequente con schemi complessi contengono out-of-date statistiche, Advisor crea una raccomandazione suggerita da eseguireANALYZE.

Raccomandazione

Ogni volta che il contenuto della tabella cambia in modo significativo, aggiorna le statistiche conANALYZE. Ti consigliamo di ANALYZE eseguirlo ogni volta che un numero significativo di nuove righe di dati viene caricato in una tabella esistente con INSERT i comandi COPY or. Si consiglia inoltre di ANALYZE eseguirlo ogni volta che un numero significativo di righe viene modificato utilizzando DELETE i comandi UPDATE or. Per identificare tabelle mancanti o out-of-date statistiche, esegui il seguente SQL comando come superutente. I risultati sono ordinati dalla tabella più grande a quella più piccola.

Per identificare le tabelle mancanti o out-of-date statistiche, esegui il SQL comando seguente come superutente. I risultati sono ordinati dalla tabella più grande a quella più piccola.

SELECT
   ti.schema||'.'||ti."table" tablename,
   ti.size table_size_mb,
   ti.stats_off statistics_accuracy
 FROM svv_table_info ti
 WHERE ti.stats_off > 5.00
 ORDER BY ti.size DESC;          
         

Consigli di implementazione

La ANALYZE soglia predefinita è del 10 percento. Questa impostazione predefinita indica che il ANALYZE comando salta una determinata tabella se meno del 10 percento delle righe della tabella sono state modificate rispetto all'ultimaANALYZE. Di conseguenza, è possibile scegliere di ANALYZE impartire comandi alla fine di ogni ETL processo. Adottare questo approccio significa che ANALYZE viene spesso ignorato, ma garantisce anche che venga ANALYZE eseguito quando necessario.

ANALYZEle statistiche hanno l'impatto maggiore per le colonne utilizzate nei join (ad esempio,JOIN tbl_a ON col_b) o come predicati (ad esempio,). WHERE col_b = 'xyz' Per impostazione predefinita, ANALYZE raccoglie le statistiche per tutte le colonne della tabella specificata. Se necessario, è possibile ridurre il tempo necessario per l'esecuzione ANALYZE eseguendo l'esecuzione ANALYZE solo per le colonne in cui ha il maggiore impatto. È possibile eseguire il SQL comando seguente per identificare le colonne utilizzate come predicati. È possibile anche lasciare a Amazon Redshift la scelta delle colonne da analizzare specificando ANALYZE PREDICATE COLUMNS.

WITH predicate_column_info as (
SELECT ns.nspname AS schema_name, c.relname AS table_name, a.attnum as col_num,  a.attname as col_name,
        CASE
            WHEN 10002 = s.stakind1 THEN array_to_string(stavalues1, '||') 
            WHEN 10002 = s.stakind2 THEN array_to_string(stavalues2, '||')
            WHEN 10002 = s.stakind3 THEN array_to_string(stavalues3, '||')
            WHEN 10002 = s.stakind4 THEN array_to_string(stavalues4, '||')
            ELSE NULL::varchar
        END AS pred_ts
   FROM pg_statistic s
   JOIN pg_class c ON c.oid = s.starelid
   JOIN pg_namespace ns ON c.relnamespace = ns.oid
   JOIN pg_attribute a ON c.oid = a.attrelid AND a.attnum = s.staattnum)
SELECT schema_name, table_name, col_num, col_name,
       pred_ts NOT LIKE '2000-01-01%' AS is_predicate,
       CASE WHEN pred_ts NOT LIKE '2000-01-01%' THEN (split_part(pred_ts, '||',1))::timestamp ELSE NULL::timestamp END as first_predicate_use,
       CASE WHEN pred_ts NOT LIKE '%||2000-01-01%' THEN (split_part(pred_ts, '||',2))::timestamp ELSE NULL::timestamp END as last_analyze
FROM predicate_column_info;

Per ulteriori informazioni, consultare Analisi delle tabelle.

Abilitazione dell'accelerazione di query brevi

Short query acceleration (SQA) dà la priorità alle query selezionate di breve durata rispetto alle query a esecuzione più lunga. SQAesegue query di breve durata in uno spazio dedicato, in modo che le query non siano costrette ad attendere in coda per le query più SQA lunghe. SQAdà priorità solo alle query di breve durata e che si trovano in una coda definita dall'utente. In questo modoSQA, le query di breve durata iniziano a essere eseguite più rapidamente e gli utenti vedono i risultati prima.

Se la attiviSQA, puoi ridurre o eliminare le code di gestione del carico di lavoro (WLM) dedicate all'esecuzione di query brevi. Inoltre, le query di lunga durata non devono necessariamente far fronte a query brevi relative agli slot in una coda, quindi è possibile configurare le code in modo da utilizzare un numero inferiore di slot di query. WLM Quando usi una simultaneità inferiore, il throughput delle query aumenta e le prestazioni generali del sistema risultano migliorate per la maggior parte dei carichi di lavoro. Per ulteriori informazioni, consultare Utilizzo dall'accelerazione di query brevi.

Analisi

Advisor verifica i modelli di carico di lavoro e riporta il numero di query recenti che SQA potrebbero ridurre la latenza e il tempo di coda giornaliero per le query idonee. SQA

Raccomandazione

Modifica la configurazione per attivarla. WLM SQA Amazon Redshift utilizza un algoritmo di machine learning per analizzare ciascuna query idonea. Le previsioni migliorano man mano che si SQA impara dai modelli di interrogazione. Per ulteriori informazioni, consultare Configurazione della gestione del carico di lavoro.

Quando si attivaSQA, WLM imposta il tempo di esecuzione massimo per le query brevi su dinamico per impostazione predefinita. Ti consigliamo di mantenere l'impostazione dinamica per la SQA massima autonomia.

Consigli di implementazione

Per verificare se SQA è attivata, esegui la seguente query. Se la query restituisce una riga, SQA viene attivata.

select * from stv_wlm_service_class_config 
where service_class = 14;

Per ulteriori informazioni, consulta Monitoraggio SQA.

Chiavi di distribuzione Alter nelle tabelle

Amazon Redshift distribuisce righe di tabelle nel cluster in base allo stile di distribuzione della tabella. Le tabelle con KEY distribuzione richiedono una colonna come chiave di distribuzione (DISTKEY). Una riga di tabella viene assegnata a una sezione di nodo di un cluster in base al valore DISTKEY della colonna.

Una riga appropriata DISTKEY posiziona un numero simile di righe su ciascuna sezione di nodo e viene spesso utilizzata come riferimento nelle condizioni di unione. Un join ottimizzato si verifica quando le tabelle vengono unite sulle relative DISTKEY colonne, accelerando le prestazioni delle query.

Analisi

Advisor analizza il carico di lavoro del cluster per identificare la chiave di distribuzione più appropriata per le tabelle che possono trarre vantaggi significativi da uno KEY stile di distribuzione.

Raccomandazione

Advisor fornisce ALTER TABLE dichiarazioni che alterano DISTSTYLE la fine DISTKEY di una tabella in base alla sua analisi. Per ottenere un vantaggio significativo in termini di prestazioni, assicurati di implementare tutte le SQL istruzioni all'interno di un gruppo di raccomandazioni.

La ridistribuzione di una tabella di grandi dimensioni ALTER TABLE consuma risorse del cluster e richiede blocchi temporanei delle tabelle in momenti diversi. Implementare ogni gruppo di raccomandazioni quando il carico di lavoro dell'altro cluster è leggero. Per maggiori dettagli sull'ottimizzazione delle proprietà di distribuzione delle tabelle, consultare Playbook di progettazione avanzata delle tabelle di engineering di Amazon Redshift: chiavi e stili di distribuzione.

Per ulteriori informazioni su ALTER DISTSYLE and, vedere. DISTKEY ALTER TABLE

Modifica delle chiavi di ordinamento sulle tabelle

Amazon Redshift ordina le righe della tabella in base alla chiave di ordinamento della tabella. L'ordinamento delle righe della tabella si basa sui valori delle colonne chiave di ordinamento.

L'ordinamento di una tabella su una chiave di ordinamento appropriata può accelerare le prestazioni delle query, in particolare quelle con predicati limitati dall'intervallo, richiedendo meno blocchi di tabella da leggere dal disco.

Analisi

Advisor analizza il carico di lavoro del cluster per diversi giorni per identificare una chiave di ordinamento utile per le tabelle.

Raccomandazione

Advisor fornisce due gruppi di ALTER TABLE istruzioni che modificano la chiave di ordinamento di una tabella in base alla relativa analisi:

Quando si ordina una tabella di grandi dimensioni con ALTERTABLE, le risorse del cluster vengono consumate e i blocchi delle tabelle sono necessari in momenti diversi. Implementare ogni raccomandazione quando il carico di lavoro di un cluster è moderato. Per maggiori dettagli sull'ottimizzazione delle configurazioni delle chiavi di ordinamento della tabella, consultare Playbook di progettazione avanzata delle tabelle di engineering di Amazon Redshift: chiavi di ordinamento composto e interlacciato.

Per ulteriori informazioni su ALTERSORTKEY, vedere. ALTER TABLE

Modifica delle codifiche di compressione sulle colonne

La compressione è un'operazione a livello di colonna che riduce la dimensione dei dati quando vengono archiviati. La compressione viene utilizzata in Amazon Redshift per risparmiare spazio di archiviazione e migliorare le prestazioni delle query riducendo la quantità di I/O del disco. Consigliamo una codifica di compressione ottimale per ogni colonna in base al tipo di dati e ai modelli di query. Grazie alla compressione ottimale, le query possono essere eseguite in modo più efficiente e il database può occupare uno spazio di archiviazione minimo.

Analisi

Advisor esegue continuamente l'analisi del carico di lavoro e dello schema del database del cluster per identificare la codifica di compressione ottimale per ogni colonna della tabella.

Raccomandazione

Advisor fornisce ALTER TABLE istruzioni che modificano la codifica di compressione di determinate colonne, in base alla relativa analisi.

La modifica delle codifiche di compressione delle colonne con ALTER TABLE utilizza risorse del cluster e richiede un blocco della tabella in momenti diversi. È consigliabile implementare suggerimenti quando il carico di lavoro del cluster è leggero.

Come riferimento, ALTERTABLEesempi mostra diverse istruzioni che modificano la codifica per una colonna.

Suggerimenti per i tipi di dati

Amazon Redshift dispone di una libreria di tipi di SQL dati per vari casi d'uso. Questi includono tipi di numeri interi come INT e tipi per memorizzare caratteri, come VARCHAR. Inoltre, Redshift memorizza i tipi in modo ottimizzato per fornire accesso rapido e buone prestazioni di query. Inoltre, Redshift fornisce funzioni per tipi specifici che possono essere utilizzate per formattare o eseguire calcoli sui risultati delle query.

Analisi

Advisor esegue continuamente l'analisi del carico di lavoro e dello schema del database del cluster per identificare le colonne che possono trarre vantaggio in modo significativo dalla modifica del tipo di dati.

Raccomandazione

Advisor fornisce un'istruzione ALTER TABLE che aggiunge una nuova colonna con il tipo di dati suggerito. Una istruzione UPDATE di accompagnamento copia i dati dalla colonna esistente nella nuova colonna. Dopo aver creato la nuova colonna e caricato i dati, modificare le query e gli script di importazione per accedere alla nuova colonna. Quindi sfruttare le funzionalità e le funzioni specializzate per il nuovo tipo di dati, disponibili in SQLriferimento alle funzioni.

La copia dei dati esistenti nella nuova colonna può richiedere del tempo. Si consiglia di implementare ogni suggerimento di Advisor quando il carico di lavoro del cluster è leggero. Fare riferimento all'elenco dei tipi di dati disponibili all'indirizzo Tipi di dati.

Advisor non fornisce suggerimenti quando non ci sono dati sufficienti o se il vantaggio previsto della modifica della codifica del tipo di dati è limitato.