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à.
# Ottimizzazione automatica delle tabelle
L'ottimizzazione automatica delle tabelle è una funzionalità di auto-tuning che ottimizza automaticamente la progettazione delle tabelle applicando le chiavi di ordinamento e distribuzione senza la necessità di un intervento dell'amministratore. Utilizzando l'automazione per ottimizzare la progettazione delle tabelle, è possibile iniziare e ottenere subito le prestazioni più veloci senza investire tempo per ottimizzare e implementare manualmente le ottimizzazioni delle tabelle.
L'ottimizzazione automatica delle tabelle osserva continuamente il modo in cui le query interagiscono con le tabelle. Utilizza metodi avanzati di intelligenza artificiale per scegliere le chiavi di ordinamento e distribuzione per ottimizzare le prestazioni per il carico di lavoro del cluster. Se Amazon Redshift determina che l'applicazione di una chiave migliora le prestazioni del cluster, le tabelle vengono modificate automaticamente entro poche ore dal momento in cui il cluster è stato creato, con un impatto minimo sulle query.
Per sfruttare questa automazione, un amministratore Amazon Redshift crea una nuova tabella o modifica una tabella esistente per consentirgli di utilizzare l'ottimizzazione automatica. Le tabelle esistenti con uno stile di distribuzione o una chiave di ordinamento `AUTO` sono già abilitati per l'automazione. Quando si eseguono query su tali tabelle, Amazon Redshift determina se una chiave di ordinamento o una chiave di distribuzione migliorerà le prestazioni. In tal caso, Amazon Redshift modifica automaticamente la tabella senza richiedere l'intervento dell'amministratore. Se viene eseguito un numero minimo di query, le ottimizzazioni vengono applicate entro poche ore dall'avvio del cluster.
Se Amazon Redshift determina che una chiave di distribuzione migliora le prestazioni delle query, lo stile di distribuzione `AUTO` delle tabelle può cambiare in `KEY`.
**Topics**
+ [Abilitazione, disabilitazione e monitoraggio dell’ottimizzazione automatica delle tabelle](c_ato-enabling-disabling-monitoring.md)
+ [Gestione delle esclusioni dei carichi di lavoro da Autonomics](t_Manage_workload_exclusion.md)
+ [Compressione delle colonne per ridurre la dimensione dei dati archiviati](t_Compressing_data_on_disk.md)
+ [Distribuzione dei dati per l’ottimizzazione delle query](t_Distributing_data.md)
+ [Chiavi di ordinamento](t_Sorting_data.md)
+ [Limitazioni della tabella](t_Defining_constraints.md)
# Abilitazione, disabilitazione e monitoraggio dell’ottimizzazione automatica delle tabelle
Per impostazione predefinita, le tabelle create senza definire esplicitamente le chiavi di ordinamento o le chiavi di distribuzione sono impostate su `AUTO`. Al momento della creazione della tabella, è anche possibile impostare manualmente una chiave di distribuzione o di ordinamento in modo esplicito. Se si imposta la chiave di ordinamento o di distribuzione, la tabella non viene gestita automaticamente.
## Abilitazione dell'ottimizzazione automatica delle tabelle
Per consentire l'ottimizzazione automatica di una tabella esistente, utilizzare le opzioni dell'istruzione ALTER per modificare la tabella in `AUTO`. È possibile scegliere di definire l'automazione per le chiavi di ordinamento, ma non per le chiavi di distribuzione (e viceversa). Se si esegue un'istruzione ALTER per convertire una tabella in una tabella automatica, le chiavi di ordinamento e gli stili di distribuzione esistenti vengono mantenuti.
```
ALTER TABLE table_name ALTER SORTKEY AUTO;
```
```
ALTER TABLE table_name ALTER DISTSTYLE AUTO;
```
Per ulteriori informazioni, consultare [ALTER TABLE](r_ALTER_TABLE.md).
Inizialmente, una tabella non dispone di una chiave di distribuzione o di una chiave di ordinamento. Lo stile di distribuzione è impostato su `EVEN` o `ALL` a seconda delle dimensioni della tabella. Man mano che la tabella cresce di dimensioni, Amazon Redshift applica le chiavi di distribuzione e le chiavi di ordinamento ottimali. Le ottimizzazioni vengono applicate entro poche ore dall'esecuzione di un numero minimo di query. Quando si determinano le ottimizzazioni delle chiavi di ordinamento, Amazon Redshift prova ad ottimizzare i blocchi di dati letti dal disco durante una scansione della tabella. Quando si determinano le ottimizzazioni dello stile di distribuzione, Amazon Redshift prova a ottimizzare il numero di byte trasferiti tra i nodi del cluster.
## Rimozione dell'ottimizzazione automatica della tabella da una tabella
È possibile rimuovere la funzione di ottimizzazione automatica da una tabella. La rimozione di una tabella dall'automazione comporta la selezione di una chiave di ordinamento o di uno stile di distribuzione. Per modificare lo stile di distribuzione, specificare uno stile di distribuzione specifico.
```
ALTER TABLE table_name ALTER DISTSTYLE EVEN;
```
```
ALTER TABLE table_name ALTER DISTSTYLE ALL;
```
```
ALTER TABLE table_name ALTER DISTSTYLE KEY DISTKEY c1;
```
Per modificare una chiave di ordinamento, è possibile definire una chiave di ordinamento o sceglierne nessuna.
```
ALTER TABLE table_name ALTER SORTKEY(c1, c2);
```
```
ALTER TABLE table_name ALTER SORTKEY NONE;
```
## Monitoraggio dell’ottimizzazione automatica delle tabelle
La vista di sistema `SVV_ALTER_TABLE_RECOMMENDATIONS` registra i suggerimenti correnti di Amazon Redshift Advisor per le tabelle. Questa visualizzazione mostra i suggerimenti per tutte le tabelle, indipendentemente dal fatto che siano definite o meno per l'ottimizzazione automatica.
Per verificare se una tabella è definita per l'ottimizzazione automatica, eseguire una query sulla vista di sistema `SVV_TABLE_INFO`. Le voci sono visualizzate solo per le tabelle visibili nel database della sessione corrente. I suggerimenti vengono inseriti nella vista due volte al giorno a partire già dopo poche ore dal momento della creazione del cluster. Una volta che è disponibile un suggerimento, viene avviata entro un'ora. Dopo che è stato applicato un suggerimento (da Amazon Redshift o dall'utente), non viene più visualizzato nella visualizzazione.
La vista di sistema `SVL_AUTO_WORKER_ACTION` mostra un log di audit di tutte le operazioni eseguite da Amazon Redshift e lo stato precedente della tabella.
La vista di sistema `SVV_TABLE_INFO` elenca tutte le tabelle del sistema insieme a una colonna per indicare se la chiave di ordinamento e lo stile di distribuzione della tabella sono impostati su `AUTO`.
Per ulteriori informazioni sull'utilizzo di queste viste di sistema, consultare [Monitoraggio del sistema (solo con provisioning)](c_intro_system_views.md).
# Gestione delle esclusioni dei carichi di lavoro da Autonomics
È possibile escludere endpoint o gruppi di lavoro serverless con provisioning specifico dall'influenza sulle decisioni relative all'autonomia, come la chiave di distribuzione e la chiave di ordinamento, tramite una funzionalità di denylist. In questo modo puoi controllare quali carichi di lavoro considera Amazon Redshift quando prendi decisioni di ottimizzazione per i tuoi dati Redshift Managed Storage (RMS).
**Utilizzo della denylist**
Puoi gestire la denylist tramite la sezione Autonomics nella console Amazon Redshift:
1. **Aggiungere o rimuovere articoli**
Aggiungi endpoint o gruppi di lavoro serverless specifici con provisioning alla denylist e rimuovili quando necessario.
1. **Visualizza e cerca**
Visualizza tutti gli elementi negati e cerca endpoint o gruppi di lavoro specifici nella denylist.
La denylist è particolarmente utile quando gestisci marketplace di dati, condividi dati con utenti esterni o disponi di più unità aziendali, in cui desideri evitare che determinati modelli di utilizzo influenzino le decisioni di ottimizzazione adatte al tuo carico di lavoro. Ad esempio, se il gruppo di lavoro A esegue il carico di lavoro A e il gruppo di lavoro B esegue il carico di lavoro B su una tabella condivisa T, la chiave di ordinamento di T sarà determinata da entrambi i carichi di lavoro A e B. Se desideri che solo il carico di lavoro A influenzi la decisione sulla chiave di ordinamento, aggiungi il gruppo di lavoro B all'elenco di rifiuto dell'endpoint o del gruppo di lavoro proprietario della tabella T. Per impostazione predefinita, Amazon Redshift Autonomics considera i modelli di interrogazione del produttore e tutti i consumatori a meno che non siano espressamente esclusi dalla denylist. clusters/workgroups
**Nota**
Puoi negare l'accesso alle risorse in diverse AWS regioni all'interno dello stesso account. La denylisting tra più account non è ancora supportata.
## Gestione delle risorse della denylist nella console Amazon Redshift
Sulla console di Amazon Redshift Serverless, completare questa procedura:
1. Scegli cluster o gruppi di lavoro serverless.
1. Passa alla pagina dei dettagli di un cluster o di un gruppo di lavoro specifico.
1. Scegli Autonomics nella sezione delle schede.
1. Nella scheda Autonomics, puoi visualizzare e gestire la tua denylist.
1. Per gestire la denylist tra regioni, scegli la regione corrispondente. AWS
## Aggiungere risorse denylist
1. Passa alla scheda Autonomics del cluster o del gruppo di lavoro selezionato, seleziona la AWS regione e scegli Aggiungi risorse.
1. Seleziona uno o più cluster Provisioned o gruppi di lavoro Serverless da aggiungere alla denylist e scegli Aggiungi.
1. La tabella mostra l'elenco delle risorse denylist.
## Rimuovi le risorse denylist
1. Vai alla scheda Autonomics del cluster o gruppo di lavoro selezionato, seleziona la regione. AWS
1. Scegli il cluster o il gruppo di lavoro che desideri eliminare dall'elenco e seleziona Rimuovi.
1. Viene visualizzata una finestra di dialogo di conferma. Seleziona Rimuovi per confermare.
# Compressione delle colonne per ridurre la dimensione dei dati archiviati
La *compressione* è un'operazione a livello di colonna che riduce la dimensione dei dati quando vengono archiviati. La compressione preserva lo spazio di storage e riduce le dimensioni dei dati letti dallo storage, diminuendo quindi la quantità di I/O su disco e migliorando le prestazioni delle query.
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).
Tuttavia, se si specifica la codifica di compressione per qualsiasi colonna della tabella, la tabella non è più impostata su ENCODE AUTO. Amazon Redshift non gestisce più automaticamente la codifica di compressione per tutte le colonne della tabella.
È possibile applicare un tipo di compressione oppure*encoding*, alle colonne in una tabella manualmente quando si crea la tabella. In alternativa, è possibile utilizzare il comando COPY per analizzare e applicare automaticamente la compressione. Per ulteriori informazioni, consultare [Scelta automatica delle codifiche di compressione con COPY](c_best-practices-use-auto-compression.md). Per ulteriori informazioni sull'applicazione della compressione automatica, consultare [Caricamento di tabelle con compressione automatica](c_Loading_tables_auto_compress.md).
**Nota**
Consigliamo fortemente l'uso del comando COPY per applicare compressione automatica.
È possibile scegliere di applicare manualmente le codificazioni di compressione nel caso in cui la nuova tabella condivida le stesse caratteristiche di dati di un'altra tabella. In alternativa, è possibile farlo se in fase di verifica si dovesse rilevare che le codifiche di compressione applicate durante la compressione automatica non sono adatte ai propri dati. Se scegli di applicare manualmente le codifiche di compressione, puoi eseguire il comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) su una tabella già popolata e utilizzare i risultati per scegliere codifiche di compressione.
Per applicare manualmente la compressione, specifica le codifiche di compressione per colonne singole come parte della dichiarazione CREATE TABLE. La sintassi è esposta di seguito.
```
CREATE TABLE table_name (column_name
data_type ENCODE encoding-type)[, ...]
```
*encoding-type* è preso dalla tabella delle parole chiave nella sezione seguente.
Ad esempio, la dichiarazione PRODUCT crea una tabella a due colonne. Quando i dati vengono caricati nella tabella, la colonna PRODUCT\$1ID non viene compressa; la colonna PRODUCT\$1NAME viene invece compressa mediante l'uso della codifica del dizionario del byte (BYTEDICT).
```
create table product(
product_id int encode raw,
product_name char(20) encode bytedict);
```
Puoi specificare la codifica di una colonna dopo che viene aggiunta a una tabella mediante l'uso del comando ALTER TABLE.
```
ALTER TABLE table-name ADD [ COLUMN ] column_name column_type ENCODE encoding-type
```
**Topics**
+ [Codifiche di compressione](c_Compression_encodings.md)
+ [Test delle codifiche di compressione](t_Verifying_data_compression.md)
# Codifiche di compressione
Una *codifica di compressione* specifica il tipo di compressione applicata a una colonna di valori dei dati nel momento in cui le righe vengono aggiunte a una tabella.
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).
Tuttavia, se si specifica la codifica di compressione per qualsiasi colonna della tabella, la tabella non è più impostata su ENCODE AUTO. Amazon Redshift non gestisce più automaticamente la codifica di compressione per tutte le colonne della tabella.
Quando utilizzi CREATE TABLE, ENCODE AUTO è disabilitato quando si specifica la codifica di compressione per qualsiasi colonna della tabella. Amazon Redshift assegna automaticamente una codifica di compressione alle colonne per le quali non si specifica un tipo ENCODE come segue:
+ Le colonne definite come chiavi di ordinamento vengono assegnate alla compressione RAW.
+ Le colonne definite come tipi di dati BOOLEAN, REAL o DOUBLE PRECISION vengono assegnate alla compressione RAW.
+ Alle colonne definite come tipi di dati SMALLINT, INTEGER, BIGINT, DECIMAL, DATE, TIMESTAMP o TIMESTAMPTZ viene assegnata la compressione. AZ64
+ Le colonne definite come tipi di dati CHAR o VARCHAR sono assegnate alla compressione LZO.
Puoi modificare la codifica di una tabella dopo averla creata utilizzando ALTER TABLE. Se disabiliti ENCODE AUTO utilizzando ALTER TABLE, Amazon Redshift non gestisce più automaticamente le codifiche di compressione per le colonne. Tutte le colonne manterranno i tipi di codifica di compressione che avevano quando è stato disabilitato ENCODE AUTO finché non si modificano o non si abilita nuovamente ENCODE AUTO.
Amazon Redshift supporta le codifiche di compressione seguenti:
------
#### [ Raw ]
La codifica raw è la codifica predefinita per le colonne designate come chiavi di ordinamento, oltre che per le colonne definite come tipi di dati BOOLEAN, REAL o DOUBLE PRECISION. Grazie alla codifica raw, i dati vengono archiviati in una forma non compressa e non elaborata.
------
#### [ AZ64 ]
AZ64 è un algoritmo di codifica di compressione proprietario progettato da Amazon per ottenere un rapporto di compressione elevato e una migliore elaborazione delle query. Fondamentalmente, l' AZ64 algoritmo comprime gruppi più piccoli di valori di dati e utilizza istruzioni SIMD (Single Instruction, Multiple Data) per l'elaborazione parallela. Utilizzato AZ64 per ottenere risparmi di archiviazione significativi e prestazioni elevate per tipi di dati numerici, di data e ora.
È possibile utilizzare AZ64 come codifica di compressione quando si definiscono le colonne utilizzando le istruzioni CREATE TABLE e ALTER TABLE con i seguenti tipi di dati:
+ SMALLINT
+ INTEGER
+ BIGINT
+ DECIMAL
+ DATE
+ TIMESTAMP
+ TIMESTAMPTZ
------
#### [ Byte-dictionary ]
Nella codifica del dizionario byte, viene creato un dizionario separato da valori univoci per ogni blocco di valori della colonna sul disco. (Un blocco del disco Amazon Redshift occupa 1 MB.) Il dizionario contiene fino a 256 valori da un byte, i quali vengono archiviati come indici dei valori di dati originali. Se in un singolo blocco vengono archiviati più di 256 valori, i valori in eccesso vengono scritti nel blocco in forma non compressa e non elaborata. Lo stesso processo si ripete per ogni blocco del disco.
Questa codifica è molto efficace su colonne di stringhe a bassa cardinalità. Questa codifica è ottimale quando il dominio di dati di una colonna è inferiore a 256 valori univoci.
Per le colonne con il tipo di dati stringa (CHAR e VARCHAR) codificato con BYTEDICT, Amazon Redshift esegue scansioni vettorializzate e valutazioni dei predicati che operano direttamente sui dati compressi. Queste scansioni utilizzano istruzioni singole specifiche dell'hardware e istruzioni con dati multipli (SIMD) per l'elaborazione parallela. Ciò velocizza notevolmente la scansione delle colonne di stringhe. La codifica Byte-dictionary è particolarmente efficiente in termini di spazio se una colonna contiene stringhe di caratteri lunghe. CHAR/VARCHAR
Si supponga che una tabella disponga di una colonna COUNTRY con un tipo di dati CHAR(30). Quando i dati vengono caricati, Amazon Redshift crea il dizionario e popola la colonna COUNTRY con il valore indice. Il dizionario contiene i valori univoci indicizzati; inoltre la relativa tabella contiene solo i subscript da un byte dei valori corrispondenti.
**Nota**
Gli spazi iniziali vengono archiviati in colonne di caratteri a lunghezza fissa. Pertanto, in una colonna CHAR(30), ogni valore compresso risparmia 29 byte di storage quando utilizzi la codifica del dizionario byte.
La seguente tabella rappresenta il dizionario per la colonna COUNTRY:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
La seguente tabella rappresenta i valori nella colonna COUNTRY:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
La dimensione totale compressa in questo esempio viene calcolata come di seguito: 6 voci diverse vengono archiviate nel dizionario (6 \$1 30 = 180), e la tabella contiene 10 valori compressi da un byte, per un totale di 190 byte.
------
#### [ Delta ]
Le codifiche delta sono molto utili per le colonne date time.
La codifica delta comprime i dati mediante la registrazione della differenza tra i valori che si susseguono nella colonna. Questa differenza viene registrata in un dizionario separato per ogni blocco di valori della colonna sul disco. (Un blocco del disco Amazon Redshift occupa 1 MB.) Ad esempio, si supponga che la colonna contenga 10 interi in una sequenza da 1 a 10. I primi sono memorizzati come un intero da 4 byte (più un flag da 1 byte). I nove successivi vengono memorizzati come byte con il valore 1, indicando che è uno maggiore del valore precedente.
La codifica delta è disponibile in due variazioni:
+ DELTA registra le differenze come valori di 1 byte (interi di 8 bit)
+ DELTA32K registra le differenze come valori a 2 byte (numeri interi a 16 bit)
Se la maggior parte dei valori nella colonna si potessero comprimere mediante l'uso di un singolo byte, la variazione di 1 byte sarebbe molto efficace. Tuttavia, se i delta sono più grandi, questa codifica, nel peggiore dei casi, è in qualche modo meno efficace rispetto all'archiviazione dei dati non compressi. Una logica simile si applica alla versione 16 bit.
Se la differenza tra due valori supera l'intervallo a 1 byte (DELTA) o l'intervallo a 2 byte (DELTA32K), viene memorizzato il valore originale completo, con un flag a 1 byte iniziale. L'intervallo di 1 byte va da -127 a 127, mentre quello di 2 byte da-32K a 32K.
La tabella seguente mostra come funziona una codifica delta per una colonna numerica:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
------
#### [ LZO ]
La codifica LZO fornisce un rapporto di compressione molto alto e con buone prestazioni. La codifica LZO funziona particolarmente bene per le colonne CHAR e VARCHAR che archiviano stringhe di caratteri molto lunghe. Sono particolarmente adatti per testo in formato libero, ad esempio le descrizioni del prodotto, i commenti dell'utente o le stringhe JSON.
------
#### [ Mostly ]
Le codifiche mostly sono utili quando il tipo di dati di una colonna è maggiore rispetto alla maggior parte dei valori archiviati richiesti. Specificando una codifica mostly per questo tipo di colonna, puoi comprimere la maggior parte dei valori nella colonna in una dimensione di storage standard più piccola. I valori restanti, che non possono essere compressi, vengono archiviati nel loro formato raw. Ad esempio, è possibile comprimere una colonna a 16 bit, ad esempio una colonna, in uno spazio di archiviazione a 8 bit. INT2
Generalmente, la codifica mostly funziona con i seguenti tipi di dati:
+ SMALLINT/ INT2 (16 bit)
+ INTEGER/INT (32 bit)
+ BIGINT/ INT8 (64 bit)
+ DECIMAL/NUMERIC (64 bit)
Scegli la variazione appropriata della codifica mostly, in funzione della dimensione del tipo di dati per la colonna. Ad esempio, si applica MOSTLY8 a una colonna definita come colonna intera a 16 bit. L'applicazione MOSTLY16 a una colonna con un tipo di dati a 16 bit o MOSTLY32 a una colonna con un tipo di dati a 32 bit non è consentita.
Rispetto all'assenza di compressione, la maggior parte delle codifiche potrebbero essere meno efficaci quando un numero relativamente alto dei valori nella colonna non può essere compresso. Prima di applicare una di queste codificazioni a una colonna, eseguire un controllo. La *maggior parte* dei valori che stanno per essere caricati (e che saranno caricati in seguito) dovrebbe adattarsi agli intervalli riportati nella seguente tabella.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
**Nota**
Per i valori decimali, ignora la posizione del punto per determinare se il valore è appropriato all'intervallo. Ad esempio, 1.234,56 viene considerato come 123.456 e può essere compresso in una colonna. MOSTLY32
Ad esempio, la colonna VENUEID sulla tabella VENUE viene definita come una colonna intera in formato raw, ciò significa che il suo valore consuma 4 byte dello storage. Ad ogni modo, l'intervallo attuale dei valori nella colonna va da **0** a **309**. Pertanto, ricreare e ricaricare questa tabella con la MOSTLY16 codifica per VENUEID ridurrebbe la memorizzazione di ogni valore in quella colonna a 2 byte.
Se i valori VENUEID a cui si fa riferimento in un'altra tabella fossero per lo più compresi tra 0 e 127, potrebbe essere opportuno codificare quella colonna a chiave esterna come. MOSTLY8 Prima di scegliere, sarà necessario eseguire varie query sui dati della tabella di riferimento, per scoprire se la maggior parte dei valori rientra nell'intervallo a 8 bit, 16 bit o 32 bit.
La tabella seguente mostra le dimensioni compresse per valori numerici specifici quando si utilizzano le codifiche, e: MOSTLY8 MOSTLY16 MOSTLY32
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
------
#### [ Run length ]
La codifica della lunghezza di esecuzione sostituisce un valore che viene ripetuto consecutivamente con un token, il quale è composto dal valore e dal conteggio del numero delle ricorrenze consecutive (la lunghezza dell'esecuzione). Viene creato un dizionario separato da valori univoci per ogni blocco di valori della colonna sul disco. (Un blocco del disco Amazon Redshift occupa 1 MB.) Questa codifica è la più appropriata per una tabella in cui i valori dei dati vengono spesso ripetuti consecutivamente, per esempio quando la tabella è ordinata in base a quei valori.
Ad esempio, si supponga che una colonna in una tabella di grandi dimensioni disponga di un dominio abbastanza piccolo, ad esempio una colonna COLOR con meno di 10 valori possibili. È probabile che questi valori cadano in sequenze lunghe in tutta la tabella, anche se i dati non sono ordinati.
Consigliamo di non applicare la codifica della lunghezza di esecuzione su nessuna colonna indicata come chiave di ordinamento. Le scansione a intervallo limitato hanno una migliore prestazione quando i blocchi contengono numeri di righe simili. Se le colonne della chiave di ordinamento vengono compresse più delle altre colonne nella stessa query, le prestazioni delle scansioni a intervallo limitato potrebbero essere scarse.
La tabella seguente usa l'esempio della colonna COLOR per mostrare come funziona la codifica di lunghezza dell'esecuzione:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
------
#### [ Text255 and Text32k ]
Le codifiche Text255 e Text32k sono utili per la compressione delle colonne VARCHAR in cui ricorrono spesso le stesse parole. Viene creato un dizionario separato da parole univoche per ogni blocco di valori della colonna sul disco. (Un blocco del disco Amazon Redshift occupa 1 MB.) Il dizionario contiene le prime 245 parole univoche nella colonna. Queste parole vengono sostituite sul disco da un valore dell'indice 1 byte, che rappresenta uno dei 245 valori; inoltre tutte le parole che non sono nel dizionario vengono archiviate senza essere compresse. Lo stesso processo si ripete per ogni blocco del disco da 1 MB. Se le parole indicizzate si verificano frequentemente nella colonna, questa produrrà un alto rapporto di compressione.
Per quando riguarda la codifica text32k, il principio è lo stesso ma il dizionario di ogni blocco non acquisisce uno specifico numero di parole. Al contrario, il dizionario indicizza ogni parola univoca che rileva finché le voci combinate raggiungono una lunghezza di 32k, meno qualche spesa di gestione. I valori dell'indice vengono archiviati in due byte.
Considera, ad esempio, la colonna VENUENAME nella tabella VENUE. Parole come **Arena**, **Center** e **Theatre** sono ricorrenti in questa colonna e, probabilmente, sarebbero tra le prime 245 parole trovate in ogni blocco se fosse applicata la compressione text255. In tal caso, questa colonna beneficia della compressione. Questo perché ogni volta che appariranno queste parole, occuperanno solo 1 byte dello storage (anziché 5, 6 o 7 rispettivamente).
------
#### [ ZSTD ]
La codifica Zstandard (ZSTD) fornisce un elevato rapporto di compressione con buone prestazioni tra i diversi set di dati. La codifica ZSTD funziona particolarmente bene con le colonne CHAR e VARCHAR che archiviano un'ampia gamma di stringhe lunghe e corte, ad esempio le descrizioni del prodotto, i commenti dell'utente, i log e le stringhe JSON. Mentre alcuni algoritmi, ad esempio la codifica Delta o la codifica Mostly, potenzialmente possono utilizzare più spazio di archiviazione rispetto all’assenza di compressione, è molto improbabile che la codifica ZSTD incrementi l’uso del disco.
ZSTD supporta i tipi di dati SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP e TIMESTAMPTZ.
------
La seguente tabella identifica le codifiche di compressione supportate, oltre che i tipi di dati che supportano la codifica.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/redshift/latest/dg/c_Compression_encodings.html)
# Test delle codifiche di compressione
Nel caso in cui decidessi di specificare manualmente le codifiche della colonna, probabilmente vorresti eseguire i test delle diverse codifiche dei tuoi dati.
**Nota**
Se possibile, ti consigliamo l'utilizzo del comando COPY per caricare i dati e per permettergli di scegliere le codifiche ottimali a seconda dei tuoi dati. In alternativa, è possibile utilizzare il comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) per visualizzare le codifiche consigliate per i dati esistenti. Per ulteriori informazioni sull'applicazione della compressione automatica, consultare [Caricamento di tabelle con compressione automatica](c_Loading_tables_auto_compress.md).
Per eseguire un test della compressione di dati significativo, sarà necessario un gran numero di righe. In questo esempio, verrà creata una tabella e saranno inserite delle righe mediante l'uso di una dichiarazione che seleziona dati da due tabelle, VENUE e LISTING. Lasciamo fuori la clausola WHERE che normalmente unirebbe le due tabelle. Il risultato è che *ogni* riga nella tabella VENUE viene unita a *tutte* le righe nella tabella LISTING, per un totale di più di 32 milioni di righe. Questa operazione, conosciuta come join cartesiano, solitamente non è consigliata. Tuttavia, a questo scopo, è un metodo conveniente per la creazione di molte righe. Se disponi di una tabella esistente con dei dati su cui desideri eseguire dei test, puoi ignorare questa fase.
Una volta ottenuta una tabella con dati di esempio, viene creata una tabella con sette colonne. Ognuna di esse ha una diversa codifica di compressione: raw, bytedict, lzo, lunghezza di esecuzione, text255, text32k e zstd. Ogni colonna viene completata con esattamente gli stessi dati eseguendo un comando INSERT che seleziona i dati dalla prima tabella.
Per testare le codifiche di compressione, procedere come indicato di seguito:
1. (Facoltativo) Per prima cosa, utilizzare un join cartesiano al fine di creare una tabella con un gran numero di righe. Salta questa fase se desideri eseguire il test di una tabella esistente.
```
create table cartesian_venue(
venueid smallint not null distkey sortkey,
venuename varchar(100),
venuecity varchar(30),
venuestate char(2),
venueseats integer);
insert into cartesian_venue
select venueid, venuename, venuecity, venuestate, venueseats
from venue, listing;
```
1. Successivamente, creare una tabella con le codifiche che si desidera confrontare.
```
create table encodingvenue (
venueraw varchar(100) encode raw,
venuebytedict varchar(100) encode bytedict,
venuelzo varchar(100) encode lzo,
venuerunlength varchar(100) encode runlength,
venuetext255 varchar(100) encode text255,
venuetext32k varchar(100) encode text32k,
venuezstd varchar(100) encode zstd);
```
1. Inserire gli stessi dati in tutte le colonne utilizzando la dichiarazione INSERT con una clausola SELECT.
```
insert into encodingvenue
select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as venuetext32k, venuename as venuetext255, venuename as venuezstd
from cartesian_venue;
```
1. Verificare il numero di righe nella nuova tabella.
```
select count(*) from encodingvenue
count
----------
38884394
(1 row)
```
1. Eseguire una query della tabella del sistema [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) per confrontare il numero di blocchi del disco da 1 MB utilizzati da ogni colonna.
La funzione di aggregazione MAX restituisce il numero massimo di blocchi per ogni colonna. La tabella STV\$1BLOCKLIST include i dettagli delle tre colonne generate dal sistema. Questo esempio utilizza `col < 6` nella clausola WHERE per escludere le colonne generate dal sistema.
```
select col, max(blocknum)
from stv_blocklist b, stv_tbl_perm p
where (b.tbl=p.id) and name ='encodingvenue'
and col < 7
group by name, col
order by col;
```
La query restituisce i seguenti risultati. Le colonne sono numerate a partire da zero. A seconda della configurazione del tuo cluster, i risultati potrebbero avere numeri diversi, ma le dimensioni relative dovrebbero essere simili. È possibile osservare che la codifica BYTEDICT sulla seconda colonna ha prodotto i migliori risultati per questo set di dati. Questo approccio ha un rapporto di compressione migliore di 20:1. Anche le codifiche LZO e ZSTD hanno prodotto risultati eccellenti. Set di dati diversi produrranno naturalmente risultati diversi. Se una colonna contiene stringhe di testo più lunghe, la codifica LZO spesso produce i migliori risultati di compressione.
```
col | max
-----+-----
0 | 203
1 | 10
2 | 22
3 | 204
4 | 56
5 | 72
6 | 20
(7 rows)
```
Se disponi di dati in una tabella esistente, puoi utilizzare il comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) per visualizzare le codifiche consigliate per la tabella. Ad esempio, l'esempio seguente mostra la codifica consigliata per una copia della tabella VENUE, ovvero CARTESIAN\$1VENUE, che contiene 38 milioni di righe. Nota che ANALYZE COMPRESSION consiglia la codifica LZO per la colonna VENUENAME. ANALYZE COMPRESSION sceglie la compressione ottimale secondo diversi fattori, tra cui una percentuale di riduzione. In questo caso specifico, BYTEDICT fornisce una migliore compressione, ma anche LZO produce una compressione maggiore del 90 percento.
```
analyze compression cartesian_venue;
Table | Column | Encoding | Est_reduction_pct
---------------+------------+----------+------------------
reallybigvenue | venueid | lzo | 97.54
reallybigvenue | venuename | lzo | 91.71
reallybigvenue | venuecity | lzo | 96.01
reallybigvenue | venuestate | lzo | 97.68
reallybigvenue | venueseats | lzo | 98.21
```
## Esempio
L’esempio seguente crea una tabella CUSTOMER che dispone di colonne con diversi tipi di dati. Questa dichiarazione CREATE TABLE mostra una delle possibili combinazioni delle codifiche di compressione per queste colonne.
```
create table customer(
custkey int encode delta,
custname varchar(30) encode raw,
gender varchar(7) encode text255,
address varchar(200) encode text255,
city varchar(30) encode text255,
state char(2) encode raw,
zipcode char(5) encode bytedict,
start_date date encode delta32k);
```
La tabella seguente mostra le codifiche della colonna che sono state scelte per la tabella CUSTOMER e fornisce una spiegazione della scelta:
| Colonna | Tipo di dati | Encoding | Spiegazione |
| --- | --- | --- | --- |
| CUSTKEY | int | delta | CUSTKEY è composta da valori interi consecutivi e univoci. Dato che le differenze saranno di 1 byte, la codifica DELTA è una buona scelta. |
| CUSTNAME | varchar(30) | raw | CUSTNAME dispone di un grande dominio con pochi valori ripetuti. Qualunque codifica di compressione probabilmente non sarebbe efficace. |
| GENDER | varchar(7) | text255 | GENDER è un dominio molto piccolo con molti valori ripetuti. Text255 funziona bene con le colonne VARCHAR in cui ricorrono le stesse parole. |
| ADDRESS | varchar(200) | text255 | ADDRESS è un dominio grande, ma contiene molte parole ripetute come Street, Avenue, North, South e così via. Le codifiche Text255 e text32k sono utili per la compressione delle colonne VARCHAR in cui ricorrono le stesse parole. La lunghezza della colonna è corta, pertanto text255 è una buona scelta. |
| CITY | varchar(30) | text255 | CITY è un dominio grande, con alcuni valori ripetuti. Alcuni nomi di città sono utilizzati di più rispetto ad altri. Text255 è una buona scelta per lo stesso motivo di ADDRESS. |
| STATE | char(2) | raw | Negli Stati Uniti, STATE è un dominio preciso di 50 valori da due caratteri. La codifica bytedict restituirebbe delle compressioni, ma siccome la dimensione della colonna è di soli due caratteri, la compressione potrebbe non essere conveniente per i costi di gestione relativi alla decompressione dei dati. |
| ZIPCODE | char(5) | bytedict | ZIPCODE è un dominio noto di poco più di 50.000 valori univoci. Alcuni codici zip ricorrono più di altri. La codifica bytedict è molto efficace quando una colonna contiene un numero limitato di valori univoci. |
| START\$1DATE | data | delta32k | Le codifiche delta sono molto utili per le colonne date time, in particolare quando le righe vengono caricate nell'ordine di data. |
# Distribuzione dei dati per l’ottimizzazione delle query
Quando si caricano i dati in una tabella, Amazon Redshift distribuisce le righe della tabella su tutti i nodi di calcolo a seconda dello stile di distribuzione della tabella. 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 ridurre al minimo l'impatto della fase di ridistribuzione posizionando i dati dove necessario prima dell'esecuzione della query.
**Nota**
In questa sezione verranno presentati i principi della distribuzione dei dati in un database Amazon Redshift. È consigliabile creare le tabelle con `DISTSTYLE AUTO`. In tal caso, Amazon Redshift utilizza l'ottimizzazione automatica della tabella per scegliere lo stile di distribuzione dei dati. Per ulteriori informazioni, consultare [Ottimizzazione automatica delle tabelle](t_Creating_tables.md). Il resto di questa sezione fornisce dettagli sugli stili di distribuzione.
**Topics**
+ [Concetti della distribuzione dei dati](#t_data_distribution_concepts)
+ [Stili di distribuzione](c_choosing_dist_sort.md)
+ [Visualizzazione degli stili di distribuzione](viewing-distribution-styles.md)
+ [Valutazione dei modelli di query](t_evaluating_query_patterns.md)
+ [Indicazione degli stili di distribuzione](t_designating_distribution_styles.md)
+ [Valutazione del piano di query](c_data_redistribution.md)
+ [Esempio del piano di query](t_explain_plan_example.md)
+ [Esempi di distribuzione](c_Distribution_examples.md)
## Concetti della distribuzione dei dati
Di seguito sono riportati alcuni concetti di distribuzione dei dati per Amazon Redshift.
**Nodi e sezioni**
Un cluster Amazon Redshift è un set di nodi. Ogni nodo nel cluster ha il proprio sistema operativo, una memoria dedicata e uno storage del disco dedicato. Uno dei nodi è il *nodo principale*, il quale gestisce la distribuzione dei dati ed esegue query delle attività di elaborazione ai nodi di calcolo. I *nodi di calcolo* forniscono risorse per eseguire tali attività.
Lo storage del disco di un nodo di calcolo è diviso in un numero di *sezioni*. Il numero di sezioni per nodo dipende dalla dimensione dei nodi del cluster. Tutti i nodi partecipano all'esecuzione di query parallele, lavorando sui dati di calcolo distribuiti più uniformemente possibile all'interno delle sezioni. Per ulteriori informazioni sul numero di sezioni per ogni dimensione di nodo, consulta [Informazioni su cluster e nodi](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html#rs-about-clusters-and-nodes) nella *Guida alla gestione di Amazon Redshift*.
**Ridistribuzione dei dati**
Quando si caricano i dati in una tabella, Amazon Redshift distribuisce le righe della tabella su ognuna delle sezioni dei nodi a seconda dello stile di distribuzione della tabella. Come parte di un piano di query, l'ottimizzatore determina dove è necessario posizionare i blocchi dei dati per la migliore esecuzione della query. I dati quindi vengono spostati fisicamente, o ridistribuiti, durante l'esecuzione della query. La redistribuzione potrebbe comportare l'invio di specifiche righe ai nodi per il join o la diffusione di un'intera tabella a tutti i nodi.
La ridistribuzione dei dati può contare su una porzione sostanziale dei costi del piano di query; inoltre, il traffico di rete generato dalla ridistribuzione dei dati, può influire sulle altre operazioni del database e può rallentare le prestazioni generali del sistema. Qualora prevedessi dove converrebbe posizionare inizialmente i dati, potrai minimizzare l'impatto della ridistribuzione dei dati.
**Obiettivi della distribuzione dei dati**
Quando si caricano i dati in una tabella, Amazon Redshift distribuisce le righe della tabella su tutti i nodi di calcolo e alle sezioni, a seconda dello stile di distribuzione scelto al momento della creazione della tabella. La distribuzione dei dati ha due obiettivi principali:
+ Distribuire il carico di lavoro uniformemente su tutti i nodi del cluster. La distribuzione di dati non uniforme, o la differenza di distribuzione dei dati, forza alcuni nodi a lavorare maggiormente rispetto ad altri e compromette le prestazioni della query.
+ Minimizzare lo spostamento dei dati durante l'esecuzione di una query. Se le righe che partecipano a join o alle aggregazioni si trovano già sui nodi con le loro righe di join in altre tabelle, l'ottimizzatore non dovrà ridistribuire molti dati durante l'esecuzione della query.
La strategia di distribuzione che hai scelto per il tuo database avrà importanti ripercussioni sulle prestazioni della query, sui requisiti dello storage, sul caricamento dei dati e sulla manutenzione. Scegliendo lo stile di distribuzione migliore per ogni tabella, puoi bilanciare la distribuzione dei dati e migliorare in modo significativo le prestazioni generali del sistema.
# Stili di distribuzione
Quando crei una tabella, puoi indicare uno dei seguenti stili di distribuzione: AUTO, EVEN, KEY o ALL.
Se non si specifica uno stile di distribuzione, Amazon Redshift utilizza la distribuzione AUTO.
**Distribuzione AUTO**
Con la distribuzione AUTO, Amazon Redshift assegna uno stile di distribuzione ottimale basato sulla dimensione dei dati della tabella. Ad esempio, se viene specificato lo stile di distribuzione AUTO, Amazon Redshift assegna inizialmente la distribuzione ALL a una tabella di piccole dimensioni. Quando le dimensioni della tabella aumentano, Amazon Redshift potrebbe modificare lo stile di distribuzione in KEY, scegliendo la chiave primaria (o una colonna della chiave primaria composita) come chiave di distribuzione. Se le dimensioni della tabella aumentano e nessuna delle colonne è adatta per essere utilizzata come chiave di distribuzione, Amazon Redshift modifica lo stile di distribuzione in EVEN. La modifica dello stile di distribuzione avviene in background con un impatto minimo sulle query degli utenti.
Per visualizzare le operazioni eseguite automaticamente da Amazon Redshift per modificare una chiave di distribuzione della tabella, consultare [SVL\$1AUTO\$1WORKER\$1ACTION](r_SVL_AUTO_WORKER_ACTION.md). Per visualizzare i suggerimenti correnti relativi alla modifica di una chiave di distribuzione della tabella, consultare [SVV\$1ALTER\$1TABLE\$1RECOMMENDATIONS](r_SVV_ALTER_TABLE_RECOMMENDATIONS.md).
Per visualizzare lo stile di distribuzione applicato a una tabella, eseguire una query sulla visualizzazione del catalogo di sistema PG\$1CLASS\$1INFO. Per ulteriori informazioni, consultare [Visualizzazione degli stili di distribuzione](viewing-distribution-styles.md). Se non si specifica uno stile di distribuzione con l'istruzione CREATE TABLE, Amazon Redshift applica la distribuzione AUTO.
**Distribuzione EVEN**
Il nodo principale distribuisce le righe tra le sezioni con un metodo round robin, indipendentemente dai valori in una determinata colonna. La distribuzione EVEN è appropriata quando una tabella non partecipa ai join. È appropriata anche quando non c'è una scelta chiara tra la distribuzione KEY e la distribuzione ALL.
**Distribuzione KEY**
Le righe sono distribuite in funzione dei valori in una colonna. Il nodo principale posiziona valori corrispondenti sulla stessa sezione di nodo. Se si distribuisce una coppia di tabelle sulle chiavi di join, il nodo principale colloca le righe sulle sezioni in funzione dei valori nelle colonne di join affinché i valori corrispondenti delle colonne comuni siano archiviati fisicamente insieme. In questo modo, i valori corrispondenti delle colonne comuni vengono fisicamente memorizzati insieme.
**Distribuzione ALL**
Un copia dell'intera tabella viene distribuita a ogni nodo. Dove la distribuzione EVEN o KEY posiziona solo una parte delle righe di una tabella su ogni nodo, la distribuzione ALL assicura la collocazione di ogni riga per ogni join a cui la tabella partecipa.
La distribuzione ALL moltiplica lo storage richiesto dal numero di nodi nel cluster, quindi impiega più tempo per caricare, aggiornare o inserire i dati in più tabelle. La distribuzione ALL è idonea solo per spostamenti relativamente lenti delle tabelle, ovvero per le tabelle che non vengono aggiornate intensamente o frequentemente. Poiché il costo della ridistribuzione di piccole tabelle durante una query è basso, non vi è un vantaggio significativo per definire le tabelle di dimensioni ridotte come DISTSTYLE ALL.
**Nota**
Dopo aver specificato uno stile di distribuzione per una colonna, Amazon Redshift gestisce la distribuzione dei dati a livello di cluster. Amazon Redshift non richiede né supporta il concetto di partizionamento dei dati all'interno degli oggetti del database. Non è necessario creare spazi di tabelle o definire schemi di partizionamento per le tabelle.
In alcuni scenari, puoi modificare lo stile di distribuzione di una tabella dopo che è stata creata. Per ulteriori informazioni, consultare [ALTER TABLE](r_ALTER_TABLE.md). Per gli scenari in cui non puoi modificare lo stile di distribuzione di una tabella dopo che è stata creata, puoi ricreare la tabella e popolarla con una copia completa. Per ulteriori informazioni, consultare [Esecuzione di una copia completa](performing-a-deep-copy.md)
# Visualizzazione degli stili di distribuzione
Per visualizzare lo stile di distribuzione di una tabella, eseguire una query sulla visualizzazione PG\$1CLASS\$1INFO o SVV\$1TABLE\$1INFO.
La colonna RELEFFECTIVEDISTSTYLE in PG\$1CLASS\$1INFO indica lo stile di distribuzione attuale per la tabella. Se la tabella utilizza la distribuzione automatica, RELEFFECTIVEDISTSTYLE è 10, 11 o 12 che indica se lo stile di distribuzione effettivo è AUTO (ALL), AUTO (EVEN) o AUTO (KEY). Se la tabella utilizza la distribuzione automatica, lo stile di distribuzione potrebbe inizialmente mostrare AUTO (ALL), quindi passare ad AUTO (EVEN) o AUTO (KEY) quando le dimensioni della tabella aumentano.
La seguente tabella fornisce lo stile di distribuzione per ogni valore su RELEFFECTIVEDISTSTYLE:
| RELEFFECTIVEDISTSTYLE | Stile di distribuzione attuale |
| --- | --- |
| 0 | EVEN |
| 1 | KEY |
| 8 | ALL |
| 10 | AUTO (ALL) |
| 11 | AUTO (EVEN) |
| 12 | AUTO (KEY) |
La colonna DISTSTYLE in SVV\$1TABLE\$1INFO indica lo stile di distribuzione attuale per la tabella. Se la tabella utilizza la distribuzione automatica, DISTSTYLE è AUTO (ALL), AUTO (EVEN) o AUTO (KEY).
L'esempio seguente crea quattro tabelle mediante l'uso di tre stili di distribuzione e distribuzione automatica, quindi esegue una query SVV\$1TABLE\$1INFO per visualizzare gli stili di distribuzione.
```
create table public.dist_key (col1 int)
diststyle key distkey (col1);
insert into public.dist_key values (1);
create table public.dist_even (col1 int)
diststyle even;
insert into public.dist_even values (1);
create table public.dist_all (col1 int)
diststyle all;
insert into public.dist_all values (1);
create table public.dist_auto (col1 int);
insert into public.dist_auto values (1);
select "schema", "table", diststyle from SVV_TABLE_INFO
where "table" like 'dist%';
schema | table | diststyle
------------+-----------------+------------
public | dist_key | KEY(col1)
public | dist_even | EVEN
public | dist_all | ALL
public | dist_auto | AUTO(ALL)
```
# Valutazione dei modelli di query
La scelta di stili di distribuzione è solo uno degli aspetti della progettazione del database. Si dovrebbero prendere in considerazione gli stili di distribuzione solo all'interno del contesto dell'intero sistema, bilanciando la distribuzione con altri importanti fattori, come la dimensione dei cluster, i metodi di codifica della compressione, le chiavi di ordinamento e i limiti della tabella.
Esegui dei test sul tuo sistema con dei dati che siano più reali possibili.
Per scegliere lo stile di distribuzione migliore, sarà necessario capire i modelli di query per l'applicazione Amazon Redshift. Identifica le query più costose nel tuo sistema e basa il progetto iniziale del database sulle richieste di queste query. I fattori che determinano il costo totale di una query sono i tempi di esecuzione della query e i relativi consumi di risorse di calcolo. Altri fattori che determinano il costo della query sono i tempi di esecuzione e quanto le altre query e le operazioni del database vengono rivoluzionate.
Identificare le tabelle utilizzate dalle query più costose e valutare il loro ruolo nel runtime delle query. Considera il modo in cui le tabelle vengono combinate e aggregate.
Utilizza le linee guida di questa sezione per scegliere uno stile di distribuzione per ogni tabella. Dopo averlo fatto, creare le tabelle e caricarle con dei dati che siano più reali possibile. Quindi testare le tabelle per i tipi di query che si prevede di utilizzare. Puoi valutare i piani di illustrazione di query per identificare le opportunità di ottimizzazione. Confrontare i tempi di caricamento, lo spazio di archiviazione e i tempi di esecuzione della query per bilanciare i requisiti generali del sistema.
# Indicazione degli stili di distribuzione
In questa sezione, le considerazioni e le raccomandazioni per l'indicazione degli stili di distribuzione utilizzano uno schema a stella come esempio. Il progetto del database potrebbe essere basato su uno star schema, su alcune sue varianti o su uno schema completamente diverso. Amazon Redshift è progettato per funzionare in modo efficace con qualsiasi schema di progettazione scelto. I principi di questa sezione possono essere applicati a qualsiasi schema di progetto.
1. **Specificare la chiave primaria e le chiavi esterne per tutte le tabelle.**
Amazon Redshift non applica limitazioni di chiavi primarie o esterne, ma l'ottimizzatore di query le utilizza quando genera i piani di query. Se imposti le chiavi primarie e quelle esterne, la tua applicazione dovrà mantenere la validità delle chiavi.
1. **Distribuire le tabelle dei fatti e le sue tabelle di dimensioni più grandi sulle loro colonne comuni.**
Scegli quella di dimensioni più grandi a seconda della dimensione del set di dati coinvolto nel join più comune, non solo per la dimensione della tabella. Se una tabella di solito viene filtrata mediante l'utilizzo della clausola WHERE, solo una parte delle sue righe parteciperà alla combinazione. Tabelle del genere hanno un impatto minore sulla ridistribuzione rispetto a tabelle più piccole che forniscono più dati. Indica sia la dimensione della chiave primaria della tabella che la chiave esterna corrispondente della tabella dei fatti come DISTKEY. Se più tabelle utilizzano la stessa chiave di distribuzione, verranno posizionate con la tabella dei fatti. La tabella dei fatti può avere una sola chiave di distribuzione. Le tabelle che eseguono l'operazione join su un'altra chiave non sono collocate con la tabella dei fatti.
1. **Indicare le chiavi di distribuzione per le altre tabelle dimensionali.**
Distribuisci le tabelle sulle loro chiavi primarie o esterne, a seconda di come combinano più frequentemente con le altre tabelle.
1. **Valutare se sia il caso di modificare alcune tabelle dimensionali per utilizzare la dimensione 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. La seguente sezione illustra come identificare i candidati per la distribuzione ALL, mediante la valutazione del piano EXPLAIN.
1. **Utilizzare la distribuzione AUTO per le tabelle restanti.**
Se una tabella è ampiamente denormalizzata e non partecipa ai join, oppure se non hai ben chiara la scelta di un altro stile di distribuzione, utilizza la distribuzione AUTO.
Per permettere ad Amazon Redshift di scegliere lo stile di distribuzione appropriato, non specificare esplicitamente una distribuzione automatica.
# Valutazione del piano di query
Puoi utilizzare i piani di query per identificare i candidati per l'ottimizzazione dello stile di distribuzione.
Dopo avere fatto la scelta iniziale, crea le tue tabelle, caricale con i dati e verificale. Utilizza un set di dati per il test che sia più reale possibile. Misura i tempi di caricamento per utilizzarli come riferimento per il confronto.
Valutare le query che sono rappresentative di quelle più costose che verranno eseguite; nello specifico, le query che utilizzano combinazioni e aggregazioni. Confrontare i runtime per le varie opzioni di progettazione. Quando si confrontano i runtime di una query, non tenere in conto il primo runtime della query perché include il tempo di compilazione.
**DS\$1DIST\$1NONE**
Non è necessaria alcuna ridistribuzione, perché le sezioni corrispondenti vengono posizionate sui nodi di calcolo. Solitamente si avrà una sola fase DS\$1DIST\$1NONE, la combinazione tra la tabella dei fatti e una tabella dimensionale.
**DS\$1DIST\$1ALL\$1NONE**
Non è necessaria alcuna ridistribuzione, perché la tabella di combinazione interna utilizza DISTSTYLE ALL. L'intera tabella si trova su ogni nodo.
**DS\$1DIST\$1INNER**
La tabella interna viene ridistribuita.
**DS\$1DIST\$1OUTER**
La tabella esterna viene ridistribuita.
**DS\$1BCAST\$1INNER**
Una copia di tutta la tabella interna viene trasmessa a tutti i nodi di calcolo.
**DS\$1DIST\$1ALL\$1INNER**
Tutta la tabella interna viene ridistribuita in una singola sezione, perché la tabella esterna utilizza DISTSTYLE ALL.
**DS\$1DIST\$1BOTH**
Entrambe le tabelle vengono ridistribuite.
**DS\$1DIST\$1ERR**
Quando nella tabella non è selezionato uno stile di distribuzione.
DS\$1DIST\$1NONE e DS\$1DIST\$1ALL\$1NONE vanno bene. Indicano che non è stata necessaria alcuna ridistribuzione per quella fase, perché tutte le combinazioni erano posizionate.
DS\$1DIST\$1INNER significa che la fase probabilmente avrà un costo relativamente alto, perché la tabella interna è stata ridistribuita sui nodi. DS\$1DIST\$1INNER indica che la tabella esterna è già stata propriamente distribuita sulla chiave di combinazione. Imposta la chiave di distribuzione della tabella interna sulla chiave di combinazione per convertirla in DS\$1DIST\$1NONE. In alcuni casi, la distribuzione della tabella interna sulla chiave di combinazione non è possibile, perché la tabella esterna non è distribuita sulla chiave di combinazione. In questo caso, valutare se utilizzare la distribuzione ALL per la tabella interna. Se la tabella non viene aggiornata frequentemente o ampiamente, oltre a essere troppo grande per portare alti costi di ridistribuzione, modificare lo stile di distribuzione su ALL e riprovare. Le clausole di distribuzione ALL incrementano i tempi di caricamento, quindi se esegui nuovi test, includi il tempo di caricamento nei fattori di valutazione.
DS\$1DIST\$1ALL\$1INNER non va bene. Ciò significa che tutta la tabella interna viene ridistribuita in una singola sezione, perché la tabella esterna utilizza DISTSTYLE ALL, in modo che una copia di tutta la tabella esterna venga posizionata su ogni nodo. Questo comporta un'esecuzione seriale inefficiente della combinazione su un singolo nodo, anziché trarre vantaggio dal runtime parallelo che utilizza tutti i nodi. DISTSTYLE ALL dovrebbe essere utilizzata solo per la tabella di combinazione interna. Per la tabella esterna invece, specifica una chiave di distribuzione o utilizza la distribuzione EVEN.
DS\$1BCAST\$1INNER e DS\$1DIST\$1BOTH non vanno bene. Solitamente queste ridistribuzioni si verificano perché le tabelle non vengono combinate sulle loro chiavi di ridistribuzione. Se la tabella dei fatti non dispone ancora di una chiave di distribuzione, specifica la colonna di combinazione come la chiave di distribuzione per entrambe le tabelle. Se la tabella dei fatti ha già una chiave di distribuzione su un'altra colonna, valutare se la modifica della chiave di distribuzione per collocare questo join migliora le prestazioni complessive. Se la modifica della chiave di distribuzione della tabella esterna non dovesse essere una scelta ottimale, è possibile ottenere la collocazione specificando DISTSTYLE ALL per tutte le tabelle interne.
L'esempio seguente mostra una parte del piano di query con le etichette DS\$1BCAST\$1INNER e DS\$1DIST\$1NONE.
```
-> XN Hash Join DS_BCAST_INNER (cost=112.50..3272334142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_BCAST_INNER (cost=109.98..3167290276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
```
Dopo aver modificato la tabella dimensionale per utilizzare DISTSTYLE ALL, il piano di query per la stessa query mostra DS\$1DIST\$1ALL\$1NONE al posto di DS\$1BCAST\$1INNER. Inoltre, si verifica un significativo cambiamento in termini di costi per le fasi di combinazione. Il costo totale è `14142.59` confrontato con `3272334142.59` della query precedente.
```
-> XN Hash Join DS_DIST_ALL_NONE (cost=112.50..14142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=109.98..10276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
```
# Esempio del piano di query
Questo esempio mostra come valutare un piano di query per scoprire le opportunità di ottimizzazione della distribuzione.
Esegui la seguente query con un comando EXPLAIN per produrre un piano di query.
```
explain
select lastname, catname, venuename, venuecity, venuestate, eventname,
month, sum(pricepaid) as buyercost, max(totalprice) as maxtotalprice
from category join event on category.catid = event.catid
join venue on venue.venueid = event.venueid
join sales on sales.eventid = event.eventid
join listing on sales.listid = listing.listid
join date on sales.dateid = date.dateid
join users on users.userid = sales.buyerid
group by lastname, catname, venuename, venuecity, venuestate, eventname, month
having sum(pricepaid)>9999
order by catname, buyercost desc;
```
Nel database TICKIT, SALES è una tabella dei fatti e LISTING è la sua dimensione più grande. Per collocare le tabelle, SALES viene distribuito su LISTID, che rappresenta la chiave esterna di LISTING, il quale viene distribuito sulla chiave primaria, LISTID. L'esempio seguente mostra il comando CREATE TABLE per SALES e LISTING.
```
create table sales(
salesid integer not null,
listid integer not null distkey,
sellerid integer not null,
buyerid integer not null,
eventid integer not null encode mostly16,
dateid smallint not null,
qtysold smallint not null encode mostly8,
pricepaid decimal(8,2) encode delta32k,
commission decimal(8,2) encode delta32k,
saletime timestamp,
primary key(salesid),
foreign key(listid) references listing(listid),
foreign key(sellerid) references users(userid),
foreign key(buyerid) references users(userid),
foreign key(dateid) references date(dateid))
sortkey(listid,sellerid);
create table listing(
listid integer not null distkey sortkey,
sellerid integer not null,
eventid integer not null encode mostly16,
dateid smallint not null,
numtickets smallint not null encode mostly8,
priceperticket decimal(8,2) encode bytedict,
totalprice decimal(8,2) encode mostly32,
listtime timestamp,
primary key(listid),
foreign key(sellerid) references users(userid),
foreign key(eventid) references event(eventid),
foreign key(dateid) references date(dateid));
```
Nel seguente piano di query, la fase Merge Join per la combinazione su SALES e LISTING mostra DS\$1DIST\$1NONE, che indica che non è necessaria alcuna ridistribuzione per la fase. Ad ogni modo, scorrendo il piano di query, le altre combinazioni interne mostrano DS\$1BCAST\$1INNER, il quale indica che la tabella interna viene trasmessa come parte dell'esecuzione della query. Dato che solo una coppia di tabelle può essere collocata mediante la distribuzione della chiave, cinque tabelle devono essere ritrasmesse.
```
QUERY PLAN
XN Merge (cost=1015345167117.54..1015345167544.46 rows=1000 width=103)
Merge Key: category.catname, sum(sales.pricepaid)
-> XN Network (cost=1015345167117.54..1015345167544.46 rows=170771 width=103)
Send to leader
-> XN Sort (cost=1015345167117.54..1015345167544.46 rows=170771 width=103)
Sort Key: category.catname, sum(sales.pricepaid)
-> XN HashAggregate (cost=15345150568.37..15345152276.08 rows=170771 width=103)
Filter: (sum(pricepaid) > 9999.00)
-> XN Hash Join DS_BCAST_INNER (cost=742.08..15345146299.10 rows=170771 width=103)
Hash Cond: ("outer".catid = "inner".catid)
-> XN Hash Join DS_BCAST_INNER (cost=741.94..15342942456.61 rows=170771 width=97)
Hash Cond: ("outer".dateid = "inner".dateid)
-> XN Hash Join DS_BCAST_INNER (cost=737.38..15269938609.81 rows=170766 width=90)
Hash Cond: ("outer".buyerid = "inner".userid)
-> XN Hash Join DS_BCAST_INNER (cost=112.50..3272334142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_BCAST_INNER (cost=109.98..3167290276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
-> XN Hash (cost=87.98..87.98 rows=8798 width=25)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=25)
-> XN Hash (cost=2.02..2.02 rows=202 width=41)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=41)
-> XN Hash (cost=499.90..499.90 rows=49990 width=14)
-> XN Seq Scan on users (cost=0.00..499.90 rows=49990 width=14)
-> XN Hash (cost=3.65..3.65 rows=365 width=11)
-> XN Seq Scan on date (cost=0.00..3.65 rows=365 width=11)
-> XN Hash (cost=0.11..0.11 rows=11 width=10)
-> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=10)
```
Una soluzione è modificare le tabelle per avere DISTSTYLE ALL.
```
ALTER TABLE users ALTER DISTSTYLE ALL;
ALTER TABLE venue ALTER DISTSTYLE ALL;
ALTER TABLE category ALTER DISTSTYLE ALL;
ALTER TABLE date ALTER DISTSTYLE ALL;
ALTER TABLE event ALTER DISTSTYLE ALL;
```
Esegui la stessa query ancora con il comando EXPLAIN ed esamina il nuovo piano di query. Le combinazioni ora mostrano DS\$1DIST\$1ALL\$1NONE, il quale indica che non è necessaria alcuna ridistribuzione, dato che i dati sono stati distribuiti su tutti i nodi tramite DISTSTYLE ALL.
```
QUERY PLAN
XN Merge (cost=1000000047117.54..1000000047544.46 rows=1000 width=103)
Merge Key: category.catname, sum(sales.pricepaid)
-> XN Network (cost=1000000047117.54..1000000047544.46 rows=170771 width=103)
Send to leader
-> XN Sort (cost=1000000047117.54..1000000047544.46 rows=170771 width=103)
Sort Key: category.catname, sum(sales.pricepaid)
-> XN HashAggregate (cost=30568.37..32276.08 rows=170771 width=103)
Filter: (sum(pricepaid) > 9999.00)
-> XN Hash Join DS_DIST_ALL_NONE (cost=742.08..26299.10 rows=170771 width=103)
Hash Cond: ("outer".buyerid = "inner".userid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=117.20..21831.99 rows=170766 width=97)
Hash Cond: ("outer".dateid = "inner".dateid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=112.64..17985.08 rows=170771 width=90)
Hash Cond: ("outer".catid = "inner".catid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=112.50..14142.59 rows=170771 width=84)
Hash Cond: ("outer".venueid = "inner".venueid)
-> XN Hash Join DS_DIST_ALL_NONE (cost=109.98..10276.71 rows=172456 width=47)
Hash Cond: ("outer".eventid = "inner".eventid)
-> XN Merge Join DS_DIST_NONE (cost=0.00..6286.47 rows=172456 width=30)
Merge Cond: ("outer".listid = "inner".listid)
-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=14)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=24)
-> XN Hash (cost=87.98..87.98 rows=8798 width=25)
-> XN Seq Scan on event (cost=0.00..87.98 rows=8798 width=25)
-> XN Hash (cost=2.02..2.02 rows=202 width=41)
-> XN Seq Scan on venue (cost=0.00..2.02 rows=202 width=41)
-> XN Hash (cost=0.11..0.11 rows=11 width=10)
-> XN Seq Scan on category (cost=0.00..0.11 rows=11 width=10)
-> XN Hash (cost=3.65..3.65 rows=365 width=11)
-> XN Seq Scan on date (cost=0.00..3.65 rows=365 width=11)
-> XN Hash (cost=499.90..499.90 rows=49990 width=14)
-> XN Seq Scan on users (cost=0.00..499.90 rows=49990 width=14)
```
# Esempi di distribuzione
I seguenti esempi mostrano come i dati vengono distribuiti secondo le opzioni che hai definito nella dichiarazione CREATE TABLE.
## Esempi DISTKEY
Guarda lo schema della tabella USERS nel database TICKIT. USERID è definito come la colonna SORTKEY e la colonna DISTKEY:
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'users';
column | type | encoding | distkey | sortkey
---------------+------------------------+----------+---------+---------
userid | integer | none | t | 1
username | character(8) | none | f | 0
firstname | character varying(30) | text32k | f | 0
...
```
USERID è una buona scelta per la colonna di distribuzione su questa tabella. Se si esegue la query della vista di sistema SVV\$1DISKUSAGE, è possibile appurare che la tabella è stata distribuita in modo molto uniforme. I segmenti sono in base zero, quindi USERID è la colonna 0.
```
select slice, col, num_values as rows, minvalue, maxvalue
from svv_diskusage
where name='users' and col=0 and rows>0
order by slice, col;
slice| col | rows | minvalue | maxvalue
-----+-----+-------+----------+----------
0 | 0 | 12496 | 4 | 49987
1 | 0 | 12498 | 1 | 49988
2 | 0 | 12497 | 2 | 49989
3 | 0 | 12499 | 3 | 49990
(4 rows)
```
La tabella contiene 49.990 righe. Le colonne delle righe (num\$1values) mostrano che ogni sezione contiene approssimativamente lo stesso numero di righe. Le colonne minvalue e maxvalue mostrano l'intervallo di valori su ogni sezione. Ogni sezione include quasi l'intero intervallo di valori, quindi ci sono buone probabilità che ogni sezione partecipi all'esecuzione di una query che filtra per un intervallo di utenti. IDs
Questo esempio dimostra la distribuzione su un piccolo sistema di test. Il numero totale delle sezioni è solitamente più alto.
Se di solito esegui combinazioni o raggruppamenti mediante la colonna STATE, potresti scegliere di distribuire sulla colonna STATE. I seguenti esempi mostrano che se viene creata una nuova tabella con gli stessi dati della tabella USERS ma si imposta DISTKEY sulla colonna STATE, la distribuzione non sarà così ordinata. In questo caso, la distribuzione non è altrettanto uniforme. La sezione 0 (13.587 righe) contiene approssimativamente il 30% di righe in più rispetto alla sezione 3 (10.150 righe). In una tabella più grande, il totale della differenza di distribuzione potrebbe avere un impatto avverso sull'elaborazione di query.
```
create table userskey distkey(state) as select * from users;
select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage
where name = 'userskey' and col=0 and rows>0
order by slice, col;
slice | col | rows | minvalue | maxvalue
------+-----+-------+----------+----------
0 | 0 | 13587 | 5 | 49989
1 | 0 | 11245 | 2 | 49990
2 | 0 | 15008 | 1 | 49976
3 | 0 | 10150 | 4 | 49986
(4 rows)
```
## Esempio DISTSTYLE EVEN
Se crei una nuova tabella con gli stessi dati della tabella USERS ma imposti DISTSTYLE su EVEN, le righe saranno comunque distribuite in modo ordinato per le sezioni.
```
create table userseven diststyle even as
select * from users;
select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage
where name = 'userseven' and col=0 and rows>0
order by slice, col;
slice | col | rows | minvalue | maxvalue
------+-----+-------+----------+----------
0 | 0 | 12497 | 4 | 49990
1 | 0 | 12498 | 8 | 49984
2 | 0 | 12498 | 2 | 49988
3 | 0 | 12497 | 1 | 49989
(4 rows)
```
Ad ogni modo, dato che la distribuzione non è basata su una colonna specifica, l'elaborazione di query può essere degradata, soprattutto se la tabella viene combinata su un'altra tabella. La mancanza di distribuzione su una colonna di combinazione, spesso influenza il tipo di operazione di combinazione che può essere eseguita in modo efficiente. Le operazioni di combinazione, aggregazione e raggruppamento sono ottimizzate quando entrambe le tabelle vengono distribuite e ordinate sulle loro rispettive colonne di combinazione.
## Esempio DISTSTYLE ALL
Se crei una nuova tabella con gli stessi dati della tabella USERS ma imposti DISTSTYLE su ALL, tutte le righe saranno distribuite alla prima sezione di ogni nodo.
```
select slice, col, num_values as rows, minvalue, maxvalue from svv_diskusage
where name = 'usersall' and col=0 and rows > 0
order by slice, col;
slice | col | rows | minvalue | maxvalue
------+-----+-------+----------+----------
0 | 0 | 49990 | 4 | 49990
2 | 0 | 49990 | 2 | 49990
(4 rows)
```
# Chiavi di ordinamento
**Nota**
È consigliabile creare le tabelle con `SORTKEY AUTO`. In tal caso, Amazon Redshift utilizza l'ottimizzazione automatica della tabella per scegliere la chiave di ordinamento. Per ulteriori informazioni, consultare [Ottimizzazione automatica delle tabelle](t_Creating_tables.md). I dettagli sull'ordinamento sono descritti in dettaglio nella parte restante di questa sezione.
Quando si crea una tabella, è possibile definire una o più delle sue colonne come *chiavi di ordinamento*. Quando i dati vengono caricati inizialmente nella tabella vuota, le righe vengono archiviate sul disco in modo ordinato. Le informazioni sulle colonne della chiave di ordinamento vengono passate al pianificatore di query, che utilizza questa informazioni per costruire piani che tengano in considerazione il modo in cui sono ordinati i dati. Per ulteriori informazioni, consulta [CREATE TABLE](r_CREATE_TABLE_NEW.md). Per informazioni sulle best practice per la creazione di una chiave di ordinamento, consulta [Scelta della migliore chiave di ordinamento](c_best-practices-sort-key.md).
L'ordinamento consente una gestione efficiente dei predicati a intervallo limitato. Amazon Redshift archivia i dati colonnari nei blocchi del disco da 1 MB. I valori minimo e massimo di ogni blocco vengono archiviati come parte dei metadati. Se una query utilizza un predicato a intervallo limitato, il processore di query può utilizzare i valori minimo e massimo per saltare rapidamente grandi numeri di blocchi durante la scansione della tabella. Ad esempio, si supponga che una tabella memorizzi cinque anni di dati ordinati per data e che una query specifichi un intervallo di un mese. In questo caso, puoi eliminare fino al 98% dei blocchi del disco dalla scansione. Se i dati non sono ordinati, dovranno essere scansionati più blocchi del disco (probabilmente tutti).
È possibile specificare la chiave di ordinamento composto o interlacciato. Una chiave di ordinamento composta è più efficiente quando i predicati di query utilizzano un *prefisso*, ovvero un sottoinsieme delle colonne della chiave di ordinamento in ordine. Una chiave di ordinamento interlacciato dà lo stesso peso a ogni colonna nella chiave di ordinamento, quindi i predicato di query possono utilizzare qualsiasi sottoinsieme di colonne che costituiscono la chiave di ordinamento, in qualsiasi ordine.
Per comprendere l'impatto sulle prestazioni della query della chiave di ordinamento scelta, utilizza il comando [EXPLAIN](r_EXPLAIN.md). Per ulteriori informazioni, consultare [Pianificazione di query e flusso di lavoro di esecuzione](c-query-planning.md).
Per definire un tipo di ordinamento, utilizza la parola chiave INTERLEAVED o COMPOUND con le tue dichiarazioni CREATE TABLE o CREATE TABLE AS. L'impostazione predefinita è COMPOUND. COMPOUND è consigliata quando aggiorni regolarmente le tabelle con le operazioni INSERT, UPDATE o DELETE. Una chiave di ordinamento INTERLEAVED può utilizzare un massimo di otto colonne. A seconda delle dimensioni di dati e cluster, VACUUM REINDEX può impiegare molto più tempo rispetto a VACUUM FULL perché esegue un ulteriore passaggio per analizzare le chiavi di ordinamento interlacciate. L'operazione di ordinamento e unione può richiedere più tempo per le tabelle interlacciate perché l'ordinamento interlacciato potrebbe dover riordinare più righe rispetto a un ordinamento composto.
Per visualizzare le chiavi di ordinamento per una tabella, eseguire la query della vista di sistema [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) .
**Topics**
+ [Ordinamento del layout dati multidimensionale](t_Sorting_mutidimensional-sort-key.md)
+ [Chiave di ordinamento composta](t_Sorting_data-compound.md)
+ [Chiave di ordinamento interlacciato](t_Sorting_data-interleaved.md)
# Ordinamento del layout dati multidimensionale
Una chiave di ordinamento del layout di dati multidimensionali è una chiave di ordinamento di tipo AUTO basato su predicati ripetitivi presenti in un carico di lavoro. Se il carico di lavoro contiene predicati ripetitivi, Amazon Redshift può migliorare le prestazioni di scansione delle tabelle eseguendo la co-locazione delle righe di dati che soddisfano i predicati ripetitivi. Anziché archiviare i dati di una tabella in un rigoroso ordine di colonne, una chiave di ordinamento del layout dei dati multidimensionale memorizza i dati analizzando i predicati ripetitivi presenti in un carico di lavoro. In un carico di lavoro è possibile trovare più di un predicato ripetitivo. A seconda del carico di lavoro, questo tipo di chiave di ordinamento può migliorare le prestazioni di molti predicati. Amazon Redshift determina automaticamente se questo metodo della chiave di ordinamento deve essere utilizzato per le tabelle definite con una chiave di ordinamento `AUTO`.
Ad esempio, supponi di disporre di una tabella con i dati ordinati in base alle colonne. Potrebbe essere necessario esaminare molti blocchi di dati per determinare se soddisfano i predicati del carico di lavoro. Tuttavia, se i dati sono archiviati su disco nell'ordine dei predicati, è necessario scansionare un numero inferiore di blocchi per soddisfare la query. In questo caso è utile utilizzare una chiave di ordinamento del layout dei dati multidimensionali.
Per vedere se una query utilizza una chiave del layout dei dati multidimensionali, consulta la colonna `step_attribute` della vista [SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md). Quando il valore è `multi-dimensional`, per la query è stato utilizzato un layout di dati multidimensionali.
Per evitare che Amazon Redshift utilizzi una chiave di ordinamento per il layout dei dati multidimensionali, scegli un'opzione di ordinamento della tabella diversa da `SORTKEY AUTO`. Per ulteriori informazioni sulle opzioni SORTKEY, consulta [CREATE TABLE](r_CREATE_TABLE_NEW.md).
# Chiave di ordinamento composta
Una chiave composta è costituita da tutte le colonne elencate nella definizione della chiave di ordinamento, nell'ordine in cui sono elencate. Una chiave di ordinamento composta è più utile quando un filtro di query applica delle condizioni, come filtri e combinazioni, che utilizzano un prefisso delle chiavi di ordinamento. I vantaggi in termini di prestazioni dell'ordinamento composto diminuiscono quando le query si basano solo su colonne di ordinamento secondarie, senza fare riferimento alle colonne primarie. COMPOUND è il tipo di ordinamento predefinito.
Le chiavi di ordinamento composte potrebbero velocizzare le combinazioni, le operazioni GROUP BY e ORDER BY e le funzioni di finestra che utilizzano PARTITION BY e ORDER BY. Ad esempio, un merge join, che è sempre più veloce di un hash join, è conveniente quando i dati vengono distribuiti e preordinati sulle colonne di combinazione. Le chiavi di ordinamento composte aiutano anche a migliorare la compressione.
Quando aggiungi righe a una tabella ordinata che già contiene dati, la regione non ordinata cresce; questo ha degli effetti importanti sulle prestazioni. L'effetto è maggiore quando la tabella utilizza ordinamento interlacciato, soprattutto quando le colonne di ordinamento includono dati che aumentano in maniera monotona, come le colonne di dati o timestamp. Esegui regolarmente un'operazione VACUUM, soprattutto dopo aver caricato grandi quantità di dati, per ordinare e analizzare nuovamente i dati. Per ulteriori informazioni, consulta [Ridurre le dimensioni della Regione non ordinata](vacuum-managing-vacuum-times.md#r_vacuum_diskspacereqs). Dopo il vacuum per riordinare i dati, è buona norma eseguire un comando ANALYZE per aggiornare i metadati statistici per il pianificatore di query. Per ulteriori informazioni, consultare [Analisi delle tabelle](t_Analyzing_tables.md).
# Chiave di ordinamento interlacciato
Un ordinamento interlacciato dà lo stesso peso a ogni colonna, o sottoinsieme di colonne, nella chiave di ordinamento. Se più query utilizzano colonne diverse per i filtri, puoi spesso migliorare le prestazioni di quelle query tramite uno stile di ordinamento interlacciato. Quando una query utilizza predicati restrittivi sulle colonne di ordinamento secondarie, l'ordinamento interlacciato migliora in modo significativo le prestazioni delle query rispetto all'ordinamento composto.
**Importante**
Non utilizzare una chiave di ordinamento "interlacciato" su colonne con attributi che crescono in maniera monotona, come colonne di identità, date o timestamp.
I miglioramenti delle prestazioni che hai ottenuto implementando una chiave di ordinamento interlacciato, dovrebbero essere confrontati con i tempi di caricamento e di vacuum.
Gli ordinamenti interlacciati sono più efficaci con query molto selettive, che filtrano su una o più colonne di ordinamento nella clausola WHERE, ad esempio `select c_name from customer where c_region = 'ASIA'`. I benefici dell'ordinamento interlacciato aumenta con il numero delle colonne ordinate che vengono limitate.
Un ordinamento interlacciato è più efficace con le tabelle grandi. L'ordinamento viene applicato su ogni sezione. Di conseguenza, un ordinamento interlacciato è più efficace quando una tabella è abbastanza grande da richiedere più blocchi da 1 MB per sezione. Qui, il processore di query può saltare una percentuale significativa dei blocchi utilizzando predicati restrittivi. Per visualizzare il numero di blocchi che utilizza una tabella, eseguire la query della vista di sistema [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md).
Quando si esegue un ordinamento su una singola colonna, un ordinamento interlacciato fornisce prestazioni migliori rispetto a un ordinamento composto, nel caso in cui i valori della colonna abbiano un prefisso lungo in comune. Ad esempio, in URLs genere iniziano con "http://www». Le chiavi di ordinamento composto utilizzano un numero limitati di caratteri dal prefisso, che comporta molte duplicazioni delle chiavi. Gli ordinamenti interlacciati utilizzano uno schema di compressione interno per i valori della mappa di zona, i quali gli consentono di discriminare meglio i valori delle colonne che dispongono di un prefisso lungo in comune.
Quando migri cluster con provisioning Amazon Redshift ad Amazon Redshift serverless, Redshift converte le tabelle con chiavi di ordinamento interlacciate e DISTSTYLE KEY in chiavi di ordinamento composte. Tuttavia le tabelle con solo chiavi di ordinamento interlacciate rimangono invariate. Per ulteriori informazioni sugli stili di distribuzione, consulta [Utilizzo degli stili di distribuzione dati](https://docs.aws.amazon.com//redshift/latest/dg/t_Distributing_data.html).
**VACUUM REINDEX**
Quando aggiungi righe a una tabella ordinata che già contiene dati, le prestazioni possono diminuire nel tempo. Questa diminuzione riguarda sia gli ordinamenti composti che quelli interlacciati, ma ha degli effetti più significativi sulle tabelle interlacciate. Un VACUUM ripristina l'ordine, ma l'operazione può impiegare più tempo per le tabelle interlacciate, perché l'unione di nuovi dati interlacciati può causare modifiche ad ogni blocco di dati.
Quando le tabelle vengono caricate inizialmente, Amazon Redshift analizza la distribuzione dei valori nelle colonne della chiave di ordinamento e utilizza queste informazioni per un ordinamento interlacciato ottimale delle colonne della chiave di ordinamento. Quando una tabella cresce, la distribuzione dei valori nelle colonne della chiave di ordinamento può cambiare o differenziarsi, in particolar modo con le colonne timestamp o di dati. Se la differenza diventa troppo ampia, le prestazioni potrebbero risentirne. Per analizzare nuovamente le chiavi di ordinamento e per ripristinare le prestazioni, esegui il comando VACUUM con la parola chiave REINDEX. Dato che è necessaria un'ulteriore analisi da passare sui dati, VACUUM REINDEX può impiegare più tempo rispetto al VACUUM standard per le tabelle interlacciate. Per visualizzare le informazioni sulla differenza della distribuzione della chiave e sull'ultimo tempo di reindicizzazione, eseguire una query della vista di sistema [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md).
Per ulteriori informazioni su come determinare la frequenza dell'esecuzione di VACUUM e quando eseguire VACUUM REINDEX, consultare [Decidere sulla reindicizzazione](vacuum-managing-vacuum-times.md#r_vacuum-decide-whether-to-reindex).
# Limitazioni della tabella
In modo univoco, le limitazioni della chiave esterna e della chiave primaria sono solo a livello informativo e *non vengono applicate da Amazon Redshift* quando si popola una tabella. Ad esempio, se si inseriscono dati in una tabella con dipendenze, l'inserimento può avere esito positivo anche se viola il vincolo. Tuttavia, la chiave esterna e quella primaria vengono utilizzate come suggerimenti di pianificazione. Queste dovrebbero essere dichiarate se il processo ETL o altri processi nell'applicazione applicano la loro integrità.
Ad esempio, il pianificatore di query utilizza chiavi primarie ed esterne in determinati calcoli statistici. Lo fa per dedurre l'unicità e le relazioni referenziali che influiscono sulle tecniche di decorrelazione delle query secondarie. In questo modo, può ordinare un gran numero di join ed eliminare i join ridondanti.
Il pianificatore utilizza queste relazioni della chiave, ma presuppone che tutte le chiavi nelle tabelle Amazon Redshift vengano validate appena caricate. Se la tua applicazione permette chiavi primarie o esterne non valide, alcune query potrebbero restituire risultati sbagliati. Ad esempio, una query SELECT DISTINCT potrebbe restituire righe doppie se la chiave primaria non è univoca. Non definire i limiti della chiave per le tue tabelle se hai dei dubbi sulla loro validità. D'altra parte, si dovrebbe sempre dichiarare la chiave primaria e quella esterna, oltre che i limiti di univocità se si sa che sono validi.
Amazon Redshift *applica* i limiti della colonna NOT NULL.
Per ulteriori informazioni sui vincoli di tabella, consultare [CREATE TABLE](r_CREATE_TABLE_NEW.md). Per informazioni su come eliminare una tabella con dipendenze, consultare [DROP TABLE](r_DROP_TABLE.md).