Amazon Redshift non supporterà più la creazione di nuovi Python UDFs a partire dalla Patch 198. Python esistente UDFs continuerà a funzionare fino al 30 giugno 2026. Per ulteriori informazioni, consulta il [post del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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à.
# Best practice di Amazon Redshift per la progettazione di tabelle
Durante la pianificazione di un database, alcune decisioni chiave in materia di progettazione di tabelle influenzano considerevolmente le prestazioni globali delle query. Queste scelte hanno inoltre un notevole effetto sui requisiti di storage, i quali alterano le prestazioni delle query diminuendo il numero di operazioni di I/O e riducendo al minimo la memoria necessaria per elaborare le query.
In questa sezione, è possibile trovare un riepilogo delle decisioni di progettazione più importanti e le best practice per l'ottimizzazione delle prestazioni delle query. [Ottimizzazione automatica delle tabelle](t_Creating_tables.md) fornisce descrizioni ed esempi più dettagliati delle opzioni di progettazione delle tabelle.
**Topics**
+ [Scelta della migliore chiave di ordinamento](c_best-practices-sort-key.md)
+ [Scelta del migliore stile di distribuzione](c_best-practices-best-dist-key.md)
+ [Scelta automatica delle codifiche di compressione con COPY](c_best-practices-use-auto-compression.md)
+ [Definizione dei vincoli di chiave primaria e chiave esterna](c_best-practices-defining-constraints.md)
+ [Utilizzo della dimensione di colonna più piccola possibile](c_best-practices-smallest-column-size.md)
+ [Usa date/time i tipi di dati per le colonne di date](c_best-practices-timestamp-date-columns.md)
# Scelta della migliore chiave di ordinamento
Amazon Redshift archivia i dati sul disco nell'ordine stabilito dalla chiave di ordinamento. L'ottimizzatore di query Amazon Redshift utilizza tale ordinamento per determinare i piani di query ottimali.
**Nota**
Quando si utilizza l'ottimizzazione automatica della tabella, non è necessario scegliere la chiave di ordinamento della tabella. Per ulteriori informazioni, consultare [Ottimizzazione automatica delle tabelle](t_Creating_tables.md).
Seguono alcuni suggerimenti per l'approccio migliore:
+ Per fare in modo che Amazon Redshift scelga l'ordinamento appropriato, specificare `AUTO` per la chiave di ordinamento.
+ Se i dati recenti vengono sottoposti a query più di frequente, specifica la colonna timestamp come colonna principale per la chiave di ordinamento.
Le query sono più efficaci in quanto possono ignorare interi blocchi che non rientrano nell'intervallo di tempo.
+ Se applichi spesso filtri di intervallo o di uguaglianza su una colonna, specifica tale colonna come chiave di ordinamento.
Amazon Redshift può ignorare la lettura di interi blocchi di dati per quella colonna Può farlo perché tiene traccia dei valori di colonna minimi e massimi archiviati su ogni blocco e può ignorare i blocchi non applicabili all'intervallo di predicati.
+ Se si esegue spesso il join di una tabella, specificare la colonna join come chiave di ordinamento e chiave di distribuzione.
In questo modo, si consente all'ottimizzatore di query di scegliere un sort merge join anziché un hash join più lento. Poiché i dati sono già ordinati nella chiave di join, l'ottimizzatore di query può bypassare la fase di ordinamento del sort merge join.
# Scelta del migliore stile di distribuzione
Quando si esegue una query, l'ottimizzatore di query ridistribuisce le righe sui nodi di calcolo per eseguire qualsiasi operazione di join e aggregazione, in base alle necessità. La selezione di uno stile di distribuzione di tabella ha l'obiettivo di minimizzare l'impatto dalle fase di ridistribuzione posizionando i dati dove necessario prima dell'esecuzione della query.
**Nota**
Quando si utilizza l'ottimizzazione automatica della tabella, non è necessario scegliere lo stile di distribuzione della tabella. Per ulteriori informazioni, consultare [Ottimizzazione automatica delle tabelle](t_Creating_tables.md).
Seguono alcuni suggerimenti per l'approccio migliore:
1. Distribuire la tabella dei fatti e una tabella di dimensioni sulle relative colonne comuni.
La tabella dei fatti può avere una sola chiave di distribuzione. Le tabelle che eseguono l'operazione di join su un'altra chiave non sono collocate con la tabella dei fatti. Scegliere una dimensione da collocare in base alla frequenza alla quale viene unita in join e alla dimensione delle righe di join. Indicare la chiave primaria della tabella di dimensioni e la chiave esterna corrispondente della tabella dei fatti come DISTKEY.
1. Scegliere la dimensione più grande in base alla dimensione del set di dati filtrato.
Poiché devono essere distribuite solo le righe utilizzate nel join, considera le dimensioni del set di dati dopo il filtraggio e non le dimensioni della tabella.
1. Scegliere una colonna con un'elevata cardinalità nel set di risultati filtrati.
Se si distribuisce una tabella delle vendite su una colonna di dati, ad esempio, si otterrebbe probabilmente una distribuzione dei dati abbastanza uniforme, a meno che la maggior parte delle vendite non sia stagionale. Tuttavia, se in genere si utilizza un predicato a intervallo limitato per filtrare su un breve periodo di date, la maggior parte delle righe filtrate si trova su un set di sezioni limitato e il carico di lavoro delle query è asimmetrico.
1. Modificare alcune tabelle di dimensioni per utilizzare la distribuzione ALL.
Se una tabella di dimensioni non può essere collocata con la tabella dei fatti o altre importanti tabelle di join, è spesso possibile migliorare le prestazioni delle query in modo significativo distribuendo l'intera tabella su tutti i nodi. L'utilizzo della distribuzione ALL moltiplica i requisiti di spazio di storage e aumenta i tempi di caricamento oltre che le operazioni di manutenzione; è quindi necessario valutare tutti i fattori prima di scegliere la distribuzione ALL.
Per permettere ad Amazon Redshift di scegliere lo stile di distribuzione appropriato, specificare `AUTO` per lo stile di distribuzione.
Per ulteriori informazioni sulla scelta degli stili di distribuzione, consultare [Distribuzione dei dati per l’ottimizzazione delle query](t_Distributing_data.md).
# Scelta automatica delle codifiche di compressione con COPY
Puoi specificare le codifiche di compressione al momento della creazione di una tabella, ma nella maggior parte dei casi la compressione automatica produce i migliori risultati.
ENCODE AUTO è l'impostazione di default per le tabelle. Quando la tabella è impostata su ENCODE AUTO, Amazon Redshift gestisce automaticamente la codifica di compressione per tutte le colonne della tabella. Per ulteriori informazioni, consultare [CREATE TABLE](r_CREATE_TABLE_NEW.md) e [ALTER TABLE](r_ALTER_TABLE.md).
Il comando COPY analizza i dati e applica automaticamente le codifiche di compressione a una tabella vuota nel quadro dell'operazione di caricamento.
La compressione automatica equilibra le prestazioni globali quando si scelgono le codifiche di compressione. Le prestazioni delle scansioni a intervallo limitato potrebbero risultare scadenti se le colonne di chiave di ordinamento vengono compresse più delle altre colonne nella stessa query. Di conseguenza, la compressione automatica sceglie una codifica di compressione meno efficiente per mantenere l'equilibrio tra le colonne di chiave di ordinamento e le altre.
Supponiamo che la chiave di ordinamento della tabelle sia una data o un timestamp e che la tabella utilizzi molte colonne varchar di grandi dimensioni. In questo caso, potresti ottenere delle migliori prestazioni non comprimendo affatto la colonna di chiave di ordinamento. Esegui il comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) sulla tabella, quindi utilizza le codifiche per creare una nuova tabella, ad eccezione della codifica di compressione per la chiave di ordinamento.
La codifica di compressione automatica comporta un costo in termini di prestazioni, ma solo se la tabella è vuota e non ha ancora una codifica di compressione. Per le tabelle di breve durata e per quelle che crei di frequente, come le tabelle di gestione temporanea, carica la tabella una sola volta con la compressione automatica o esegui il comando ANALYZE COMPRESSION e quindi utilizza queste codifiche per creare nuove tabelle. Puoi aggiungere le codifiche all'istruzione CREATE TABLE o utilizzare CREATE TABLE LIKE per creare una nuova tabella con la stessa codifica.
Per ulteriori informazioni, consultare [Caricamento di tabelle con compressione automatica](c_Loading_tables_auto_compress.md).
# Definizione dei vincoli di chiave primaria e chiave esterna
Definisci i vincoli di chiave primaria e chiave esterna tra le tabelle quando necessario. Anche se hanno soltanto un valore informativo, l'ottimizzatore di query utilizza tali vincoli per generare piani di query più efficienti.
Non definire vincoli di chiave primaria e di chiave esterna a meno che l'applicazione non applichi i vincoli. Amazon Redshift non applica vincoli di chiave primaria e di chiave esterna univoci.
Per ulteriori informazioni sul modo in cui Amazon Redshift utilizza i vincoli, consultare [Limitazioni della tabella](t_Defining_constraints.md).
# Utilizzo della dimensione di colonna più piccola possibile
Non utilizzare sistematicamente la dimensione di colonna massima per comodità.
Considera invece i valori più grandi che probabilmente archivierai nelle colonne e dimensionale di conseguenza. Ad esempio, una colonna CHAR per archiviare le abbreviazioni degli stati e dei territori degli Stati Uniti utilizzati dall’ufficio postale deve essere solo CHAR(2).
# Usa date/time i tipi di dati per le colonne di date
Amazon Redshift archivia i dati di tipo DATE e TIMESTAMP più efficacemente rispetto a CHAR o VARCHAR, con conseguente miglioramento delle prestazioni delle query. Utilizza il tipo di dati DATE o TIMESTAMP, in funzione della risoluzione necessaria, anziché un tipo CHAR quando archivi informazioni di tipo date/time. Per ulteriori informazioni, consultare [Tipi datetime](r_Datetime_types.md).