- Raw
-
La codifica raw è la codifica predefinita per le colonne designate come chiavi di ordinamento e le colonne definite come BOOLEANREAL, o tipi di dati. 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'AZ64algoritmo comprime gruppi più piccoli di valori di dati e utilizza istruzioni singole e multiple data (SIMD) per l'elaborazione parallela. Utilizzalo 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 per definire le colonne utilizzando ALTER TABLE istruzioni CREATE TABLE e 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 (CHAReVARCHAR) codificato conBYTEDICT, Amazon Redshift esegue scansioni vettoriali e valutazioni dei predicati che operano direttamente su dati compressi. Queste scansioni utilizzano istruzioni singole e multiple data () specifiche dell'hardware per SIMD l'elaborazione parallela. Ciò velocizza notevolmente la scansione delle colonne di stringhe. La codifica del dizionario dei byte è particolarmente efficiente in termini di spazio se una colonna/contiene stringhe di caratteri lunghe. CHAR VARCHAR
Supponiamo che una tabella abbia una COUNTRY colonna con un tipo di dati (30). CHAR Man mano che i dati vengono caricati, Amazon Redshift crea il dizionario e compila la COUNTRY colonna con il valore dell'indice. Il dizionario contiene i valori univoci indicizzati; inoltre la relativa tabella contiene solo i subscript da un byte dei valori corrispondenti.
Gli spazi iniziali vengono archiviati in colonne di caratteri a lunghezza fissa. Pertanto, in una colonna CHAR (30), ogni valore compresso consente di risparmiare 29 byte di spazio di archiviazione quando si utilizza la codifica byte-dictionary.
La tabella seguente rappresenta il dizionario per la colonna. COUNTRY
Valori dei dati univoci |
Indice del dizionario |
Dimensione (lunghezza fissata a 30 byte per valore) |
England |
0 |
30 |
United States of America |
1 |
30 |
Venezuela |
2 |
30 |
Sri Lanka |
3 |
30 |
Argentina |
4 |
30 |
Japan |
5 |
30 |
Totale |
|
180 |
La tabella seguente rappresenta i valori nella COUNTRY colonna.
Valore dati originale |
Dimensione originale (lunghezza fissata a 30 byte per valore) |
Valore compresso (indice) |
Nuova dimensione (byte) |
England |
30 |
0 |
1 |
England |
30 |
0 |
1 |
United States of America |
30 |
1 |
1 |
United States of America |
30 |
1 |
1 |
Venezuela |
30 |
2 |
1 |
Sri Lanka |
30 |
3 |
1 |
Argentina |
30 |
4 |
1 |
Japan |
30 |
5 |
1 |
Sri Lanka |
30 |
3 |
1 |
Argentina |
30 |
4 |
1 |
Totale |
300 |
|
10 |
La dimensione totale compressa in questo esempio viene calcolata come di seguito: 6 voci diverse vengono archiviate nel dizionario (6 * 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:
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 (), viene memorizzato il valore originale completo, con un flag a 1 byte iniziale. DELTA32K 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:
Valore dati originale |
Dimensione originale (byte) |
Differenza (delta) |
Valore compresso |
Dimensione compressa (byte) |
1 |
4 |
|
1 |
1+4 (contrassegno + valore attuale) |
5 |
4 |
4 |
4 |
1 |
50 |
4 |
45 |
45 |
1 |
200 |
4 |
150 |
150 |
1+4 (contrassegno + valore attuale) |
185 |
4 |
-15 |
-15 |
1 |
220 |
4 |
35 |
35 |
1 |
221 |
4 |
1 |
1 |
1 |
Totali |
28 |
|
|
15 |
- LZO
-
LZOla codifica offre un rapporto di compressione molto elevato con buone prestazioni. LZOla codifica funziona particolarmente bene per CHAR le VARCHAR colonne che memorizzano stringhe di caratteri molto lunghe. Sono particolarmente utili per testi in formato libero, come descrizioni dei prodotti, commenti degli utenti o 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 INT2 spazio di archiviazione a 8 bit.
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.
Encoding |
Dimensione storage compressa |
L'intervallo dei valori che può essere compresso (i valori fuori dall'intervallo vengono archiviati in formato raw) |
MOSTLY8 |
1 byte (8 bit) |
Da -128 a 127 |
MOSTLY16 |
2 byte (16 bit) |
Da -32768 a 32767 |
MOSTLY32 |
4 byte (32 bit) |
Da -2147483648 a +2147483647 |
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 VENUEID colonna della VENUE tabella è definita come una colonna intera non elaborata, il che significa che i suoi valori occupano 4 byte di spazio di archiviazione. Ad ogni modo, l'intervallo attuale dei valori nella colonna va da 0
a 309
. Pertanto, ricreare e ricaricare questa tabella con MOSTLY16 encoding for VENUEID ridurrebbe la memorizzazione di ogni valore in quella colonna a 2 byte.
Se i VENUEID valori 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 vengono utilizzate le codificheMOSTLY8, MOSTLY16 e: MOSTLY32
Valore originale |
BIGINTDimensione originale INT o (byte) |
MOSTLY8dimensione compressa (byte) |
MOSTLY16dimensione compressa (byte) |
MOSTLY32dimensione compressa (byte) |
1 |
4 |
1 |
2 |
4 |
10 |
4 |
1 |
2 |
4 |
100 |
4 |
1 |
2 |
4 |
1000 |
4 |
La stessa dimensione dei dati raw |
2 |
4 |
10000 |
4 |
2 |
4 |
20000 |
4 |
2 |
4 |
40000 |
8 |
La stessa dimensione dei dati raw |
4 |
100000 |
8 |
4 |
2000000000 |
8 |
4 |
- 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, supponiamo che una colonna in una tabella di grandi dimensioni abbia un dominio prevedibilmente piccolo, ad esempio una COLOR colonna 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 utilizza l'esempio di COLOR colonna per mostrare come funziona la codifica della lunghezza di esecuzione.
Valore dati originale |
Dimensione originale (byte) |
Valore compresso (token) |
Dimensione compressa (byte) |
Blue |
4 |
{2,Blue} |
5 |
Blue |
4 |
0 |
Green |
5 |
{3,Green} |
6 |
Green |
5 |
0 |
Green |
5 |
0 |
Blue |
4 |
{1,Blue} |
5 |
Yellow |
6 |
{4,Yellow} |
7 |
Yellow |
6 |
0 |
Yellow |
6 |
0 |
Yellow |
6 |
0 |
Totale |
51 |
|
23 |
- Text255 and Text32k
-
Le codifiche text255 e text32k sono utili per comprimere le VARCHAR colonne 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.
Ad esempio, considerate la colonna nella tabella. VENUENAME 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) offre un rapporto di compressione elevato con ottime prestazioni su diversi set di dati. ZSTDfunziona particolarmente bene con CHAR VARCHAR colonne che memorizzano un'ampia gamma di stringhe lunghe e corte, come descrizioni dei prodotti, commenti degli utenti, registri e stringhe. JSON Laddove alcuni algoritmi, come la codifica Delta o la codifica Mostly, possano potenzialmente utilizzare più spazio di archiviazione rispetto alla mancata compressione, ZSTD è improbabile che aumentino l'utilizzo del disco.
ZSTDsupportaSMALLINT,INTEGER,BIGINT,DECIMAL,REAL,, DOUBLEPRECISION, BOOLEAN CHAR VARCHAR DATETIMESTAMP, e TIMESTAMPTZ tipi di dati.