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

Si consiglia di utilizzare il COPY comando per caricare i dati ogni volta che è possibile e di consentire al COPY comando di scegliere le codifiche ottimali in base ai dati. In alternativa, è possibile utilizzare il comando ANALYZE COMPRESSION per visualizzare le codifiche consigliate per i dati esistenti. Per ulteriori informazioni sull'applicazione della compressione automatica, consultare Caricamento di tabelle con compressione automatica.

Per eseguire un test della compressione di dati significativo, sarà necessario un gran numero di righe. Per questo esempio, creiamo una tabella e inseriamo righe utilizzando un'istruzione che seleziona tra due tabelle; VENUE e. LISTING Tralasciamo la WHERE clausola che normalmente unisce le due tabelle. Il risultato è che ogni riga della VENUE tabella viene unita a tutte le righe della LISTING tabella, per un totale di oltre 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. Compiliamo ogni colonna con esattamente gli stessi dati eseguendo un INSERT comando che seleziona i dati dalla prima tabella.

Per testare le codifiche di compressione, procedere come indicato di seguito:

(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;

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);

Inseriamo gli stessi dati in tutte le colonne utilizzando un'INSERTistruzione con una SELECT clausola.


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;

Verificare il numero di righe nella nuova tabella.


select count(*) from encodingvenue

  count
----------
 38884394
(1 row)

Eseguire una query della tabella del sistema STV_BLOCKLIST per confrontare il numero di blocchi del disco da 1 MB utilizzati da ogni colonna.

La funzione di MAX aggregazione restituisce il numero di blocco più alto per ogni colonna. La BLOCKLIST tabella STV _ include i dettagli per tre colonne generate dal sistema. Questo esempio utilizza col < 6 nella WHERE clausola l'esclusione delle 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. Come potete vedere, la BYTEDICT codifica nella seconda colonna ha prodotto i migliori risultati per questo set di dati. Questo approccio ha un rapporto di compressione migliore di 20:1. LZOe anche la ZSTD codifica ha prodotto risultati eccellenti. Set di dati diversi produrranno naturalmente risultati diversi. Quando una colonna contiene stringhe di testo più lunghe, 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 per visualizzare le codifiche consigliate per la tabella. Ad esempio, l'esempio seguente mostra la codifica consigliata per una copia della VENUE tabella, CARTESIAN _VENUE, che contiene 38 milioni di righe. Nota che ANALYZE COMPRESSION consiglia la LZO codifica per la VENUENAME colonna. ANALYZECOMPRESSIONsceglie la compressione ottimale in base a diversi fattori, tra cui la percentuale di riduzione. In questo caso specifico, BYTEDICT fornisce una compressione migliore, ma produce LZO anche una compressione superiore al 90%.


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 CUSTOMER tabella con colonne con diversi tipi di dati. Questa CREATE TABLE istruzione mostra una delle molte possibili combinazioni di 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 di colonna scelte per la CUSTOMER tabella e fornisce una spiegazione delle scelte:

Colonna	Tipo di dati	Encoding	Spiegazione
CUSTKEY	int	delta	CUSTKEYè costituito da valori interi unici e consecutivi. Poiché le differenze sono di un byte, DELTA è una buona scelta.
CUSTNAME	varchar(30)	raw	CUSTNAMEha un dominio di grandi dimensioni 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 VARCHAR colonne in cui ricorrono le stesse parole.
ADDRESS	varchar(200)	text255	ADDRESSè un dominio di grandi dimensioni, ma contiene molte parole ripetute, come Street, Avenue, North, South e così via. Text 255 e text 32k sono utili per comprimere VARCHAR le colonne in cui ricorrono le stesse parole. La lunghezza della colonna è corta, pertanto text255 è una buona scelta.
CITY	varchar(30)	text255	CITYè un dominio di grandi dimensioni, con alcuni valori ripetuti. Alcuni nomi di città sono utilizzati di più rispetto ad altri. Text255 è una buona scelta per gli stessi motivi diADDRESS.
STATE	char(2)	raw	Negli Stati Uniti, STATE è un dominio preciso di 50 valori a 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 con meno 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_DATE	data	delta32k	Le codifiche delta sono molto utili per le colonne date time, in particolare quando le righe vengono caricate nell'ordine di data.

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Codifiche di compressione

Distribuzione dei dati