ClickHouse

Compressione dati

ClickHouse e' un Columnar Database SQL Open Source con ottime prestazioni sulle attivita' OLAP (On-Line Analytical Processing).

In questa paginetta ne vediamo, dal punto di vista pratico, le funzionalita' di compressione dei dati.
Gia' con la configurazione di default ClickHouse comprime tutti i dati con buoni risparmi ma e' anche possibile utilizzare algoritmi specifici per ottenere risultati ottimali.

Gli argomenti contenuti in questa pagina sono: Introduzione, Compressione, Test compressione, Test prestazioni, Conclusioni, ...
Il documento si riferisce alla versione 19.11 o successive di ClickHouse [NdA perche' da tale versione stable dal 2019-07 sono stati introdotti nuovi Codec particolarmente efficaci].

Introduzione

ClickHouse e' il recente database colonnare sviluppato da Yandex adatto alle attivita' OLAP. Con il termine OLAP (On-Line Analytical Processing) si indicano tecniche ed architetture adatte ad analizzare grandi basi dati in tempi molto brevi.
ClickHouse utilizza un approccio differente rispetto alla rappresentazione ISAM e con indici B-Tree tipica dei DB relazionali memorizzando i dati per colonna. Questo consente di utilizzare algoritmi per l'accesso ai dati che possono essere eseguiti in parallelo. Con ClickHouse si utilizzano tutte le CPU sul nodo ospite, ma e' possibile farlo anche in rete con piu' nodi. Le query di ClickHouse in cluster scalano in modo pressoche' lineare come prestazioni.

I datatype disponibili in ClickHouse sono stati scelti per ottenere le massime prestazioni. Piu' i dati sono compatti e migliori sono le prestazioni: per un corretto disegno della base dati va scelto il tipo di dato piu' adatto e di minori dimensioni.

Per i valori numerici i datatype disponibili in ClickHouse sono: UInt8, UInt16, UInt32, UInt64, Int8, Int16, Int32, Int64, Float32, Float64, Decimal e Boolean.
Per le stringhe si usa praticamente un solo datatype: String. ClickHouse non gestisce l'encoding quindi le stringhe sono semplicemente una serie di byte [NdA ma puo' essere specificato il COLLATE nell'ORDER BY]. In qualche caso limitato puo' essere utile anche il FixedString(N).
Per le date: Date, DateTime, DateTime64 [NdA quest'ultimo dalla versione 20.1]. ClickHouse non gestisce la timezone e tutti i tempi fanno riferimento ad Epoch in UTC.
Molto efficiente e' il datatype Enum che pero' richiede definire nella DDL tutti i valori possibili.
I NULL sono gestiti come un datatype aggiuntivo: Nullable(TypeName); tuttavia e' consigliabile evitarli nel disegno. Sono disponibili anche strutture complesse come Array(T) che invece sono molto efficienti.

Poiche' i dati sono raggruppati per colonna e quindi molto omogenei, ClickHouse e' in grado di comprimere efficacemente anche i dati numerici.
La compressione dati e' molto utile anche per minimizzare lo spazio occupato: una base dati ClickHouse e' tipicamente molto piu' piccola rispetto alla quantita' di dati memorizzati. Sugli altri database relazionali lo spazio occupato e' invece molto piu' ampio sia per la memorizzazione degli indici che per la preallocazione degli spazi.

L'organizzazione dei dati per colonna consente di effettuare un'elevata compressione ed ottenere significativi miglioramenti prestazionali: e' l'argomento di questa paginetta.

Compressione dati

La compressione di default automatica (LZ4) ottiene gia' ottimi risultati nella maggioranza delle situazioni. Sono normali compressioni oltre il 50% per i valori numerici ed oltre l'80% per le stringhe. Ma si puo' fare spesso anche molto di piu' [NdA vedremo degli esempi con compressioni superiori al 99%]

ClickHouse mantiene sul data dictionary system tutte le informazioni sulla compressione. La verifica della quantita' di spazio utilizzato/risparmiato si effettua con la seguente query:

SELECT database, table, column, type,
       column_data_compressed_bytes compressed,
       column_data_uncompressed_bytes,
       (column_data_uncompressed_bytes-column_data_compressed_bytes)*100/column_data_uncompressed_bytes ratio
  FROM system.parts_columns
 WHERE active
   AND database<>'system'
   AND column_data_uncompressed_bytes>0
 ORDER BY database, table, column;

Sulla famiglia di Engine MergeTree e' possibile migliorare ulteriormente la compressione utilizzando Codec ed algoritmi specifici scegliendoli tra quelli descritti nella documentazione ufficiale. Un Codec e' una rappresentazione dei dati: per esempio e' possibile rappresentare un dato come differenza rispetto al dato precedente oppure utilizzando un dizionario. In altri casi si utilizza un algoritmo di compressione che utilizza tecniche statistiche per rappresentare con meno bit le sequenze di dati piu' frequenti e puo' essere loseless (con perdita di dati) o meno.

E' possibile applicare in cascata in pipeline piu' Codecs, ovvero piu' codifiche dei dati e quindi un algoritmo di compressione.

La scelta si effettua per singola colonna con la sintassi:

CREATE TABLE codec_example
(
    dt Date CODEC(ZSTD),
    ts DateTime Codec(DoubleDelta, LZ4),
    float_value Float32 CODEC(NONE),
    double_value Float64 CODEC(LZ4HC(9))
    value Float32 CODEC(Delta, ZSTD)
)
...

I codecs specializzati, ovvero che sono adatti a particolari serie di valori sono:

• Delta[(bytes)]: dopo il primo valore i successivi sono calcolati per differenza. Il parametro puo' essere 1, 2, 4, 8 ed e' il numero di byte utilizzati per rappresentare la differenza.
• DoubleDelta: rispetto al codec precedente la differenza e' rappresentata in binario per ridurne la dimensione.
• Gorilla: effettua uno XOR tra i valori e ne rappresenta la differenza in forma compatta. E' l'algoritmo introdotto da Facebook Gorilla TSDB (esteso per i valori a 64 bit).
• T64: utilizza una matrice di 64x64 bit per rappresentare i valori, da cui il nome. Molto efficace se i valori presentano serie simili.

Ai primi codecs generalmente si fa seguire una successiva compressione scegliendo tra:

• NONE: nessuna compressione.
• LZ4: utilizza l'algoritmo LZ4 Fast.
• LZ4HC[(level)]: utilizza l'algoritmo LZ4 High Compression. Il livello varia da 1 a 12, default 9.
• ZSTD[(level)]: utilizza l'algoritmo ZSTD. Il livello varia da 1 a 22, default 1.

Qual'e' il migliore? Dipende... proviamo!

Test compressione

In realta' la compressione reale dipende dai dati presenti. Ogni caso e' diverso, la compressione puo' dipendere a seconda della provenienza dei dati dalle frequenze di campionamento, dalla qualita' dei sensori, dalla provenienza dei dati, dai datatype scelti, da eventuali errori, ...
Il modo migliore e' quello di provare con i dati effettivi e cosi' abbiamo fatto. Abbiamo raccolto i dati di interesse (il traffico di rete), abbiamo selezionato un campione significativo (abbiamo scelto 10.000.000 di record, non molti ma sufficienti per il nostro scopo) e li abbiamo inseriti su una tabella di test con differenti combinazioni di codec/compressione. Lo stesso procedimento l'abbiamo eseguito su una tabella di dimensioni inferiori che presentava tipologie di dati diversi (Float). Le tabelle sono state create con piu' colonne con questa DDL:

 machine_id_l String Codec(LZ4),
 machine_id_l1 String Codec(LZ4HC(1)),
 machine_id_l9 String Codec(LZ4HC(9)),
 machine_id_l12 String Codec(LZ4HC(12)),
 machine_id_z1 String Codec(ZSTD(1)),
 machine_id_z22 String Codec(ZSTD(22)),
 machine_id_lcl1 LowCardinality(String) Codec(LZ4HC(1)),
 machine_id_lcz LowCardinality(String) Codec(ZSTD(1)),

Vediamo i primi dati:

Il primo datatype che analizziamo sono le String.
Innanzi tutto si deve notare che il risparmio in termine di spazio e' notevolissimo, tutti gli algoritmi ottengono oltre il 95% di compressione.
Considerando solo la percentuale % Gain e' l'algoritmo ZSTD ad ottenere la maggiore compressione con poca differenza tra i livelli passati come parametro. Anche per LZ4 il livello di compressione non produce una variazione significativa di % Gain.
In realta' la specifica LowCardinality() consente un risparmio notevole gia' a monte ed in coppia le due indicazione forniscono il maggior risparmio di spazio.

Anche sulla seconda stringa, piu' lunga, il LowCardinality() fornisce il miglior guadagno finale.

Ora diamo in numeri!
Utilizzando questa DDL specifichiamo diverse modalita' di compressione per gli interi:

 bytes_out_n UInt64 Codec(NONE),
 bytes_out_dn UInt64 Codec(Delta),
 bytes_out_2n UInt64 Codec(DoubleDelta),
 bytes_out_gn UInt64 Codec(Gorilla),
 bytes_out_tn UInt64 Codec(T64),
 bytes_out_dl UInt64 Codec(Delta, LZ4),
 bytes_out_2l UInt64 Codec(DoubleDelta, LZ4),
 bytes_out_gl UInt64 Codec(Gorilla, LZ4),
 bytes_out_tl UInt64 Codec(T64, LZ4),
 bytes_out_dz UInt64 Codec(Delta, ZSTD),
 bytes_out_2z UInt64 Codec(DoubleDelta, ZSTD),
 bytes_out_gz UInt64 Codec(Gorilla, ZSTD),
 bytes_out_tz UInt64 Codec(T64, ZSTD),

Ora analizziamo tipi di dati interi che nel nostro caso sono UInt64.
Qui i risparmi ottenuti sono meno significativi perche' i i numeri sono piu' corti delle stringhe.
Anche in questo caso la compressione maggiore si ottiene con ZSTD in coppia al Codec T64, molto vicino e' anche la coppia Codec(T64, LZ4).

Vediamo altri esempi:

Le date sono un importantissime in tutti i DB e sui TSDB in particolare.
I DateTime sono rappresentati come UInt32 in ClickHouse e corrispondono i secondi a partire da Epoch in UTC. Nonostante la dimensione ridotta si ottengono significativi risparmi con il codec Delta e poi comprimendo. La differenza rispetto ad altri metodi e' significativa quindi e' opportuno scegliere tra queste due alternative.

Non abbiamo finito:

Gli ultimi esempi da analizzare sono relativi a Float32.
Con i Float non e' possibile utilizzare la codifica T64 e quindi non e' stato provato tale Codec. I risultati migliori sono ottenuti con una prima codifica con Gorilla o Delta e quindi la compressione ZSTD o LZ4.
Sicuramente ha inciso la scarsa distribuzione dei valori di input. Infatti ottenere oltre il 90% di compressione su un dato che utilizza 4 byte e' un risultato notevole.

Test Prestazioni

Lo spazio non e' tutto. C'e' anche il tempo! E come e' ben noto lo spazio ed il tempo sono strettamente legati :)

Ma prima e' importante capire come ClickHouse tratta i dati e quando effettua le codifiche.
In memoria i dati sono rappresentati senza codifiche, solo in fase di scrittura su disco vengono compressi. Con l'Engine MergeTree, che e' quello fondamentale, i nuovi dati vengono inseriti i Parts ordinate e solo successivamente viene eseguito il merge con i dati gia' presenti.

Piu' importante e' la fase di lettura perche' su un OLAP la scrittura avviene una sola volta ma le letture sono molte. Da questo punto di vista una tabella o, per essere piu' precisi, la Part della colonna di interesse puo' essere in stato Cold, Warm o Hot.
Quando il dato risiede solo su disco i tempi per accedere sono maggiori e dipendono dalle meccaniche usate (in senso lato: un SSD non ha parti meccaniche): questo e' lo stato Cold. Minore e' la dimensione dei dato minore sara' il tempo per leggerlo da disco.
Nello stato Warm i dati sono gia' in memoria nella buffer cache del sistema, sono ancora compressi ma non e' piu' necessario accedere al disco.
Una part acceduta di recente si trova in stato Hot: e' stata letta da disco, ha attraversato la buffer cache ed e' stata decompressa in memoria. E' nel passaggio da Warm a Hot che avviene la decodifica e si ottengono i dati in chiaro. Quando i dati sono in memoria in chiaro le SELECT per l'analisi utilizzano piu' thread in parallelo con algoritmi vettorizzati.

Dopo questa ampia premessa dovrebbe essere chiaro che non e' semplice misurare le reali differenze prestazionali tra gli algoritmi... ma lo facciamo lo stesso!
Per misurare la differenza di prestazioni abbiamo utilizzato la stessa INSERT su tabelle con Codecs differenti:

insert into test_compr.traffic_4compress
select byte_in, byte_out
  from sensor_data.traffic
 limit 10000000;

I risultati ottenuti sono riassunti in questa tabella:

Rispetto alla compressione LZ4 di default, non fare nulla e' piu' veloce! E' normale, ma e' ugualmente veloce il Codec Delta e solo un poco piu' pesante il T64.
Tutti le combinazioni che utilizzando l'algoritmo ZSTD sono piu' pesanti in modo significativo, fino al doppio piu' lenti.

Molte combinazioni di codec risultano avere un peso simile tra loro ed in generale la differenza di tempi non e' drammatica. In pratica la cosa piu' veloce e' non comprimere affatto ma la compressione piu' complessa e' piu' lenta solo di 4 volte.

Conclusioni

Quanto riportato ovviamente e' solo un riassunto e va raccolto con intelligenza poiche' le combinazioni possibili di tutti i codec, provando i diversi livelli di compressione, sono veramente moltissime.
La compressione dipende fortemente dai dati effettivamente presenti. Quindi le indicazioni sull'algoritmo migliore non solo assolute ma da valutare caso per caso.
Un altro punto da sottolineare e' che le modalita' di default sono sicuramente le piu' testate. Nella scelta dell'algoritmo da utilizzare il solo risparmio di spazio non e' l'unico fattore da tenere in considerazione.
Tenendo conto di queste premesse ci sono comunque una serie di indicazioni che e' possibile fornire.

Se la quantita' di dati non e' elevata la compressione di default e' sufficiente. ClickHouse per default utilizza l'algoritmo LZ4 per tutti i dati con buoni risultati sia in lettura che in scrittura.
Per le stringhe con un numero limitato di valori e' assolutamente conveniente utilizzare LowCardinality(String). In pratica questa sola impostazione, associata alla compressione di default, e' sufficiente su basi dati di piccole dimensioni [NdA per piccole dimensioni con ClickHouse si puo' intendere fino ad un Terabyte].

Per colonne che sono utilizzate solo raramente e contengono dati storicizzati vanno utilizzate le combinazioni di algoritmi che consentono il maggior risparmio di spazio. Da questo punto di vista, anche se piu' pesante come algoritmo, generalmente ZSTD e' quello che ottiene la maggiore compressione. Ad esempio Codec(Delta, ZSTD) per le date, ZSTD per gli interi e ZSTD per i Float.

Per colonne di dimensioni significative come dimensioni totali e' consigliabile sperimentare il reale vantaggio della compressione con i dati effettivi: a seconda dei casi possono essere adatte combinazioni differenti di Codec. Quindi utilizzare algoritmi che presentano un buon compromesso tra prestazioni ed efficienza. Ad esempio Codec(T64, LZ4) e Codec(Gorilla, LZ4).
Nel caso di colonne che variano di poco i valori per i timestamp e' molto efficiente il Codec(DoubleDelta) mentre per i float e' efficiente Codec(Gorilla).

Varie ed eventuali

L'articolo New ClickHouse Encodings contiene una trattazione molto completa e precisa dei Codecs e dei test effettuabili.

Il documento Introduzione a ClickHouse contiene una presentazione sulle funzioni di base, il documento Architettura di ClickHouse contiene una presentazione dell'architettura, DBA scripts contiene alcuni dei comandi piu' utili per il DBA.

In ClickHouse Cloud l'algoritmo di compressione di default e' ZSTD anziche' LZ4.

Titolo: Compressione in ClickHouse
Livello: Medio (2/5)
Data: 31 Ottobre 2019 🎃 Halloween
Versione: 1.0.3 - 14 Febbraio 2021 ❤️ San Valentino
© Autore: mail [AT] meo.bogliolo.name