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