Trasferirsi su ClickHouse: 3 anni dopo

Tre anni fa, Viktor Taranovski e Aleksey Milovidov di Yandex erano sul palco HighLoad++ parlato, parlando di quanto sia buono ClickHouse e di come non rallenti. E sul palco accanto c'era Alexander Zaytsev con relazione che parlava del passaggio a ClickHouse un altro sistema di gestione di database analitici e della conclusione che ClickHouse, certo, è buono, ma non molto comodo. Quando nel 2016 l'azienda LifeStreet, dove all'epoca lavorava Alexander, stava migrando un sistema analitico multiterabyte su ClickHouse, è stato un affascinante «viaggio nel paese delle meraviglie», pieno di pericoli sconosciuti — ClickHouse allora sembrava un campo minato.

Tre anni dopo ClickHouse è diventato molto meglio — in questo periodo Alexander ha fondato l'azienda Altinity, che non solo aiuta a migrare versoi ClickHouse decine di progetti, ma perfeziona il prodotto stesso insieme ai colleghi di Yandex. Oggi ClickHouse non è più una passeggiata spensierata, ma nemmeno un campo minato.

Alexander si occupa di sistemi distribuiti dal 2003, ha sviluppato grandi progetti su MySQL, Oracle e Vertica. Al recente HighLoad++ 2019 Alexander, uno dei pionieri nell'uso di ClickHouse, ha raccontato cosa rappresenta oggi questo sistema di gestione database. Scopriremo le principali caratteristiche ClickHouse: in che modo si differenzia dagli altri sistemi e in quali casi è più efficiente usarlo. Tramite esempi, esamineremo pratiche recenti e comprovate per la costruzione di sistemi su ClickHouse.

Riflessione: cosa è successo 3 anni fa

Tre anni fa stavamo migrando l'azienda LifeStreet in ClickHouse da un altro database analitico, e la migrazione dell'analisi della rete pubblicitaria sembrava così:

• Giugno 2016. In OpenSource è apparso ClickHouse è iniziato il nostro progetto;
• Agosto. Proof Of Concept: una grande rete pubblicitaria, infrastruttura e 200-300 terabyte di dati;
• Ottobre. I primi dati di produzione;
• Dicembre. Carico completo del prodotto — 10-50 miliardi di eventi al giorno.
• Giugno 2017. Trasferimento riuscito degli utenti su ClickHouse, 2,5 petabyte di dati su un cluster di 60 server.

Nel processo di migrazione è cresciuta la consapevolezza che ClickHouse è un buon sistema, con cui è piacevole lavorare, ma è un progetto interno di Yandex. Pertanto, ci sono delle sfumature: Yandex si occuperà prima dei propri clienti interni e solo dopo della comunità e delle esigenze degli utenti esterni, e ClickHouse non raggiungeva allora il livello enterprise in molte aree funzionali. Così, a marzo 2017, abbiamo fondato la società Altinity per rendere ClickHouse ancora più veloce e conveniente non solo per Yandex, ma anche per altri utenti. E ora noi:

• Formiamo e aiutiamo a costruire soluzioni su ClickHouse in modo che i clienti non commettano errori, e perché la soluzione funzioni alla fine;
• Offriamo supporto 24/7 ClickHouse-installazioni;
• Sviluppiamo progetti ecosistemici proprietari;
• Contribuiamo attivamente al ClickHouse, rispondendo alle richieste degli utenti che vogliono vedere determinate funzionalità.

E naturalmente, aiutiamo con il trasferimento su ClickHouse con MySQL, Vertica, Oracle, Greenplum, Redshift e altri sistemi. Abbiamo partecipato a diversi trasferimenti e tutti sono stati un successo.

Perché dovremmo trasferirci su ClickHouse

Non rallenta! Questa è la ragione principale. ClickHouse — un database molto veloce per diversi scenari:

Citazioni casuali da persone che lavorano a lungo con ClickHouse.

Scalabilità. Su un altro DB si può ottenere buone prestazioni su un singolo server, ma ClickHouse si può scalare non solo verticalmente, ma anche orizzontalmente, semplicemente aggiungendo server. Tutto funziona non così fluidamente come si vorrebbe, ma funziona. È possibile espandere il sistema insieme alla crescita dell'azienda. È importante che non siamo limitati dalla soluzione attuale e c'è sempre potenziale per lo sviluppo.

Portabilità. Non c'è legame a una singola cosa. Ad esempio, con Amazon Redshift è difficile trasferirsi altrove. Ma ClickHouse può essere installato sul proprio laptop, server, distribuito nel cloud, spostarsi in Kubernetes — non ci sono limiti sull'uso dell'infrastruttura. È comodo per tutti, e questo è un grande vantaggio che molte altre DB simili non possono vantare.

Flessibilità. ClickHouse non si ferma a una sola cosa, ad esempio, a Yandex.Metrica, ma si sviluppa e viene utilizzato in un numero sempre crescente di progetti e settori diversi. Può essere ampliato, aggiungendo nuove funzionalità per affrontare nuove sfide. Ad esempio, si ritiene che archiviare log in un DB sia un'anacronismo, quindi è stato inventato Elasticsearch. Ma, grazie alla flessibilità di ClickHouse, è possibile archiviare anche i log, e spesso è addirittura migliore che in Elasticsearch — in ClickHouse richiede dieci volte meno hardware.

Gratuito Open Source. Non c'è bisogno di pagare per nulla. Non è necessario contrattare per avere il permesso di installare il sistema sul proprio laptop o server. Non ci sono costi nascosti. Nel contempo, nessun'altra tecnologia di database open source può competere in velocità con ClickHouse. MySQL, MariaDB, Greenplum — sono tutte molto più lente.

Community, dinamismo e fun. Ha ClickHouse un'ottima comunità: meetups, chat e Alexey Milovidov, che ci energizza tutti con la sua energia e ottimismo.

Trasferirsi a ClickHouse

Per passare a ClickHouse qualcosa, servono solo tre cose:

• Capire le limitazioni ClickHouse e per cosa non è adatto.
• Sfruttare i vantaggi della tecnologia e i suoi punti di forza.
• Sperimentare. Anche comprendendo come funziona ClickHouse, non è sempre possibile prevedere quando sarà più veloce, quando più lento, quando migliore e quando peggiore. Quindi provate.

Il problema del trasferimento

C'è solo un «ma»: se ti trasferisci a ClickHouse da qualcos'altro, solitamente qualcosa va storto. Siamo abituati a certe pratiche e cose che funzionano nel nostro DB preferito. Ad esempio, chiunque lavori con SQL-database, considera obbligatorio un certo insieme di funzionalità:

• transazioni;
• vincoli;
• consistenza;
• indici;
• UPDATE/DELETE;
• NULLs;
• millisecondi;
• conversioni automatiche di tipo;
• join multipli;
• partizioni arbitrarie;
• strumenti di gestione del cluster.

Il set è obbligatorio, ma tre anni fa in ClickHouse non c'era nessuna di queste funzionalità! Ora degli non implementati ne sono rimasti meno della metà: transazioni, vincoli, Consistenza, millisecondi e conversione di tipo.

E la cosa principale è che in ClickHouse alcune pratiche e approcci standard non funzionano o non funzionano come siamo abituati. Tutto ciò che appare in ClickHouse, corrisponde al «modo ClickHouse», cioè le funzioni differiscono da altri DB. Ad esempio:

• Gli indici non selezionano, ma saltano.
• UPDATE/DELETE non sono sincroni, ma asincroni.
• Esistono join multipli, ma non c'è un pianificatore di query. Come vengono eseguiti allora, non è molto chiaro a chi proviene dal mondo dei database.

Scenari ClickHouse

Nel 1960 il matematico americano di origine ungherese Wigner E. P. scrisse un articolo «The unreasonable effectiveness of mathematics in the natural sciences» («L'irragionevole efficacia della matematica nelle scienze naturali») riguardo al perché il mondo che ci circonda sia descrivibile bene attraverso leggi matematiche. La matematica è una scienza astratta e le leggi fisiche espresse in forma matematica non sono triviali, e Wigner E. P. sottolineò che è molto strano.

Dal mio punto di vista, ClickHouse è una stranezza simile. Riformulando Wigner, si può dire così: è sorprendente l'irragionevole efficacia ClickHouse in una varietà di applicazioni analitiche!

Ad esempio, prendiamo Real-Time Data Warehouse, nel quale i dati vengono caricati praticamente in continuazione. Vogliamo ricevere da esso richieste con un ritardo di un secondo. Prego — utilizziamo ClickHouse, perché questo scenario è stato progettato proprio per questo. ClickHouse viene utilizzato non solo nel web, ma anche nell'analisi di marketing e finanziaria, AdTech, e anche in Fraud detection. In Real-time Data Warehouse viene utilizzato uno schema strutturato complesso di tipo «stella» o «fiocco di neve», con molte tabelle JOIN (a volte multiple), e i dati vengono di solito memorizzati e modificati in alcuni sistemi.

Prendiamo un altro scenario — Time Series: monitoraggio di dispositivi, reti, statistiche di utilizzo, Internet delle cose. Qui ci imbattiamo in eventi abbastanza semplici ordinati temporalmente. ClickHouse per questo non era stato originariamente progettato, ma ha funzionato bene, quindi grandi aziende lo utilizzano ClickHouse come archivio per informazioni di monitoraggio. Per studiare se ClickHouse è adatto ai time-series, abbiamo effettuato un benchmark basato sull'approccio e sui risultati InfluxDB e TimescaleDB — database time-series specializzati. È emerso, che ClickHouse, anche senza ottimizzazione per tali compiti, vince anche in campo avverso:

In time-series di solito viene utilizzata una tabella ristretta — con poche colonne piccole. Dal monitoraggio possono arrivare moltissimi dati — milioni di record al secondo — e di solito arrivano tramite piccole inserzioni (real-time streaming). Pertanto, è necessario un altro scenario di inserimento, e le stesse richieste hanno una certa specificità.

Log Management. La raccolta dei log nel DB è di solito sconsigliata, ma in ClickHouse questo è possibile farlo con alcuni commenti, come descritto sopra. Molte aziende usano ClickHouse proprio per questo. In questo caso viene utilizzata una tabella piatta e ampia, dove memorizziamo i log interamente (ad esempio, sotto forma di JSON), oppure li suddividiamo in parti. I dati vengono di solito caricati in grandi batch (file), e cerchiamo in base a qualche campo.

Per ciascuna di queste funzioni vengono normalmente utilizzati database specializzati. ClickHouse uno può fare tutto questo e così bene che supera le loro prestazioni. Esaminiamo ora dettagliatamente time-series lo scenario, e come «preparare» ClickHouse per questo scenario.

Time-Series

Attualmente questo è lo scenario principale per il quale ClickHouse è considerato una soluzione standard. Time-series è un insieme di eventi ordinati nel tempo, che rappresentano le variazioni di un certo processo nel tempo. Ad esempio, può essere la frequenza cardiaca durante il giorno o il numero di processi in un sistema. Tutto ciò che genera tic temporali con alcune misurazioni – è time-series:

La maggior parte di questi eventi proviene dal monitoraggio. Può trattarsi non solo di monitoraggio web, ma anche di dispositivi reali: automobili, sistemi industriali, IoT, impianti o taxi senza conducente, nel cui bagagliaio Yandex sta già inserendo ClickHouse-server.

Ad esempio, ci sono aziende che raccolgono dati da navi. Ogni pochi secondi, i sensori di una portacontainers inviano centinaia di rilevamenti diversi. Gli ingegneri li analizzano, costruiscono modelli e tentano di capire quanto efficacemente venga utilizzata la nave, perché la portacontainers non dovrebbe rimanere inattiva un secondo. Ogni inattività è una perdita di denaro, quindi è importante prevedere il percorso in modo che le soste siano minime.

Attualmente si osserva una crescita di database specializzati che misurano time-series. Sul sito DB-Engines in qualche modo classificano diversi database, e possono essere visualizzati per tipologie:

Il tipo a crescita più rapida è il time-series. Anche i database grafici stanno crescendo, ma time-seriescrescere più rapidamente negli ultimi anni. I rappresentanti tipici di questa famiglia di database sono InfluxDB, Prometheus, KDB, TimescaleDB (basato su PostgreSQL), soluzioni da Amazon. ClickHouse qui potrebbe essere utilizzato, e viene utilizzato. Ecco alcuni esempi pubblici.

Uno dei pionieri è l'azienda CloudFlare (CDN-provider). Monitorano il loro CDN tramite ClickHouse (DNS-richieste, HTTP-richieste) con un carico enorme — 6 milioni di eventi al secondo. Tutto passa attraverso Kafka, inviato a ClickHouse, che offre la possibilità di vedere in tempo reale i dashboard degli eventi nel sistema.

Comcast è uno dei leader delle telecomunicazioni negli Stati Uniti: internet, televisione digitale, telefonia. Hanno creato un sistema di gestione simile CDN nell'ambito di Open Source del progetto Apache Traffic Control per gestire i loro enormi dati. ClickHouse viene utilizzato come backend per l'analisi.

Percona hanno integrato ClickHouse all'interno del loro PMM, per memorizzare il monitoraggio di diversi MySQL.

I requisiti specifici

I database di tipo time-series hanno requisiti specifici.

• Inserimento rapido da molti agenti. Dobbiamo inserire molto rapidamente i dati da molti flussi. ClickHouse lo fa bene, perché tutte le sue inserzioni non sono bloccanti. Qualsiasi Inseriamo la nostra chiave pubblica (quella che abbiamo creato sopra) è un nuovo file sul disco, e le piccole inserzioni possono essere memorizzate in buffer in un modo o nell'altro. In ClickHouse è meglio inserire i dati in grandi pacchetti, piuttosto che riga per riga.
• Schema flessibile. In time-series Di solito non conosciamo la struttura dei dati fino in fondo. Possiamo costruire un sistema di monitoraggio per un'applicazione specifica, ma diventa difficile utilizzarlo per un'altra applicazione. Per questo serve uno schema più flessibile. ClickHouse, questo permette di farlo, anche se si tratta di un database strettamente tipizzato.
• Archiviazione efficace e "dimenticanza" dei dati. Di solito in time-series un volume enorme di dati, quindi devono essere archiviati in modo il più efficiente possibile. Ad esempio, una InfluxDB buona compressione è la sua caratteristica principale. Ma oltre all'archiviazione, è necessario anche saper "dimenticare" i dati obsoleti e fare qualche tipo di downsampling — conteggio automatico degli aggregati.
• Query rapide sui dati aggregati. A volte è interessante guardare gli ultimi 5 minuti con un'accuratezza al millisecondo, ma sui dati mensili, la granularità al minuto o al secondo potrebbe non essere necessaria — basta una statistica generale. Supportare questo tipo di richieste è fondamentale, altrimenti una richiesta di 3 mesi impiegherà molto tempo anche in ClickHouse.
• Richieste del tipo "ultimo punto, alla data di». Queste sono richieste tipiche per time-series : controlliamo l'ultima misurazione o lo stato del sistema in un dato momento t. Per i database, queste non sono richieste molto piacevoli, ma è necessario saperle eseguire.
• "Unione" delle serie temporali. Time-series — è una serie temporale. Se ci sono due serie temporali, spesso è necessario unirle e correlare. Non tutte le database lo permettono comodamente, specialmente con serie temporali non allineate: qui ci sono un certo tipo di intervalli temporali, là ce ne sono altri. Si possono calcolare le medie, ma potrebbero esserci comunque delle lacune, quindi non è chiaro.

Vediamo come questi requisiti vengono soddisfatti in ClickHouse.

Schema

In ClickHouse uno schema per time-series può essere realizzato in diversi modi, a seconda del grado di regolarità dei dati. Si può costruire un sistema su dati regolari, quando conosciamo tutte le metriche in anticipo. Ad esempio, così ha fatto CloudFlare con il monitoraggio CDN — è un sistema ben ottimizzato. Si può costruire un sistema più generale, che monitora tutta l'infrastruttura, diversi servizi. Nel caso di dati irregolari, non sappiamo in anticipo cosa stiamo monitorando — e probabilmente questo è il caso più generale.

Dati regolari. Colonne. Lo schema è semplice: colonne con i tipi necessari:

CREA TABELLA cpu (
  created_date Data DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  
  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Questa è una tabella comune che monitora un certo tipo di attività di carico del sistema (user, system, idle, nice). È semplice e comoda, ma non flessibile. Se vogliamo uno schema più flessibile, possiamo usare gli array.

Dati irregolari. Array:

CREA TABELLA cpu_alc (
  created_date Data,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELEZIONA max(metrics.value[indexOf(metrics.name,'usage_user')]) DA ...

Struttura Annidato — sono due array: metrics.name e metrics.value. Qui possiamo memorizzare dati di monitoraggio arbitrari, come un array di nomi e un array di valori per ogni evento. Per una ulteriore ottimizzazione, invece di una sola struttura, possiamo crearne diverse. Ad esempio, una per float-valore, un'altra per int-valore, perché int vogliamo memorizzare in modo più efficiente.

Ma con questa struttura è più complicato da gestire. Dovremo usare una costruzione speciale, estraendo prima i valori dall'indice e poi dall'array:

SELEZIONA max(metrics.value[indexOf(metrics.name,'usage_user')]) DA ...

Ma funziona comunque abbastanza rapidamente. Un altro modo di conservare dati irregolari è per righe.

Dati irregolari. Righe. In questo approccio tradizionale, senza array, vengono memorizzati direttamente i nomi e i valori. Se da un dispositivo arrivano 5.000 misurazioni in una volta, vengono generate 5.000 righe nel database:

CREA TABELLA cpu_rlc (
  created_date Data,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELEZIONA 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
DA cpu_r
DOVE metric_name IN ('usage_user', ...)

ClickHouse con questo riesco — ha estensioni speciali ClickHouse SQL. Ad esempio, maxIf — è una funzione speciale che calcola il massimo per una metrica sotto una certa condizione. Puoi scrivere diverse di queste espressioni in un'unica query e calcolare immediatamente i valori per diverse metriche.

Confrontiamo tre approcci:

Dettagli

Qui ho aggiunto "Dimensione dei dati su disco" per un certo set di dati di test. Nel caso delle colonne, abbiamo la dimensione dei dati più piccola: massima compressione, massima velocità delle query, ma paghiamo il prezzo di dover fissare tutto in un colpo solo.

Nel caso degli array, le cose sono un po' più complicate. I dati si comprimono comunque bene e possiamo memorizzare uno schema irregolare. Ma ClickHouse — un database colonnare, e quando iniziamo a memorizzare tutto in un array, diventa un database di tipo stringa, e paghiamo per la flessibilità con efficienza. Per ogni operazione, sarà necessario leggere l'intero array in memoria, dopodiché cercare l'elemento necessario: e se l'array cresce, la velocità degrada.

In una delle aziende che usa questo approccio (ad esempio, Uber), gli array vengono suddivisi in pezzi da 128 elementi. Dati di diverse migliaia di metriche, per un totale di 200 TB di dati/giorno, non vengono memorizzati in un unico array, ma in 10 o 30 array con logiche di memorizzazione speciali.

L'approccio più semplice è con le stringhe. Ma i dati si comprimono male, la dimensione della tabella risulta grande, e quando le query riguardano più metriche, ClickHouse non funziona in modo ottimale.

Schema ibrido

Supponiamo di aver scelto uno schema con un array. Ma se sappiamo che la maggior parte dei nostri cruscotti mostra solo le metriche user e system, possiamo materializzare ulteriormente queste metriche a livello di tabella in colonne in questo modo:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Durante l'inserimento ClickHouse li calcolerà automaticamente. In questo modo è possibile combinare l'utile con il dilettevole: lo schema è flessibile e generale, ma le colonne più frequentemente utilizzate sono state estratte. Vorrei sottolineare che ciò non ha richiesto la modifica dell'inserimento e ETL, che continua a inserire array nella tabella. Abbiamo semplicemente fatto ALTER TABLE, aggiunto un paio di colonne ed è emerso uno schema ibrido e più veloce, con il quale è possibile iniziare a lavorare immediatamente.

Codec e compressione

Per time-series è importante quanto bene imballate i dati, perché un array di informazioni può essere molto grande. In ClickHouse c'è un insieme di strumenti per ottenere un effetto di compressione 1:10, 1:20 e a volte anche di più. Questo significa che i dati non confezionati di 1 TB su disco occupano 50-100 GB. Una dimensione minore è un vantaggio, poiché i dati possono essere letti e elaborati più rapidamente.

Per raggiungere un alto livello di compressione, ClickHouse supporta i seguenti codec:

Esempio di tabella:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Qui definiamo il codec DoubleDelta in un caso, nell'altro — Gorilla, e aggiungiamo necessariamente anche LZ4 compressione. Di conseguenza, la dimensione dei dati su disco si riduce notevolmente:

Qui è mostrato quanto spazio occupano gli stessi dati, ma utilizzando codec e compressioni diversi:

• in un file GZIP su disco;
• in ClickHouse senza codec, ma con compressione ZSTD;
• in ClickHouse con codec e compressione LZ4 e ZSTD.

Si può notare che le tabelle con codec occupano molto meno spazio.

La dimensione conta

È altrettanto importante scegliere il tipo di dato corretto:

In tutti gli esempi sopra ho utilizzato Float64. Ma se avessimo scelto Float32, sarebbe stato persino meglio. Questo è stato ben dimostrato dai ragazzi di Percona nell'articolo al link sopra. È importante utilizzare il tipo più compatto possibile, adatto all'uso: anche in misura minore per la dimensione su disco, piuttosto che per la velocità delle queries. ClickHouse è molto sensibile a questo.

Se puoi utilizzare int32 anziché int64, allora aspettati quasi il raddoppio delle prestazioni. I dati consumano meno memoria e tutta l'"aritmetica" funziona molto più velocemente. ClickHouse internamente — è un sistema altamente tipizzato, utilizza al massimo tutte le possibilità offerte dai moderni sistemi.

Aggregazione e Materialized Views

L'aggregazione e le viste materializzate consentono di creare aggregati per diverse necessità:

Ad esempio, potresti avere dati sorgente non aggregati, e su di essi puoi applicare diverse viste materializzate con sommarizzazioni automatiche tramite un motore speciale. SummingMergeTree (SMT). SMT — è una struttura dei dati aggregata speciale che calcola automaticamente gli aggregati. I dati grezzi vengono inseriti nel database, vengono aggregati automaticamente e possono essere utilizzati immediatamente nei dashboard.

TTL — "dimentichiamo" i vecchi dati

Come "dimenticare" i dati che non sono più necessari? ClickHouse questo è possibile. Durante la creazione delle tabelle si possono indicare TTL espressioni: ad esempio, che i dati al minuto vengono conservati per un giorno, i dati giornalieri per 30 giorni, e quelli settimanali o mensili non vengono toccati mai:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multi-tier — separiamo i dati su dischi diversi

Sviluppando questa idea, i dati possono essere conservati ClickHouse in luoghi diversi. Supponiamo di voler conservare i dati caldi dell'ultima settimana su un dispositivo SSDmolto veloce e locale, mentre i dati più storici li accumuliamo in un altro posto. In ClickHouse questo momento è possibile:

È possibile configurare una politica di archiviazione (storage policy) in modo che ClickHouse sposti automaticamente i dati al verificarsi di determinate condizioni in un altro archivio.

Ma non è tutto. A livello di singola tabella è possibile definire regole su quando i dati passano effettivamente a un'archiviazione fredda. Ad esempio, i dati rimangono su un disco molto veloce per 7 giorni, mentre tutto ciò che è più vecchio viene trasferito su uno lento. Questo è utile perché permette al sistema di mantenere prestazioni massime, controllando al contempo i costi e senza spendere risorse su dati freddi:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Opportunità uniche ClickHouse

Quasi in tutto in ClickHouse ci sono queste "chicche", ma sono livellate dall'esclusiva — ciò che non si trova in altri DB. Ad esempio, alcune delle funzioni uniche ClickHouse:

• Array. In ClickHouse offrono un supporto ottimo per gli array, oltre alla possibilità di effettuare su di essi calcoli complessi.
• Strutture di dati aggregati. Questa è una delle “killer feature” ClickHouse. Nonostante i ragazzi di Yandex dicano che non vogliono aggregare i dati, tutti aggregano in ClickHouse, perché è veloce e comodo.
• Visualizzazioni materializzate. Insieme alle strutture di dati aggregati, le visualizzazioni materializzate consentono di fare un'aggregazione comoda. real-time ClickHouse SQL
• . Questa è un'estensione del linguaggiocon alcune funzioni aggiuntive ed esclusive che esistono solo in SQL con alcune funzionalità aggiuntive ed esclusive che sono disponibili solo in ClickHouse. Prima questo era in un certo senso un ampliamento, ma dall'altro lato una mancanza. Ora quasi tutte le mancanze rispetto a SQL 92 le abbiamo rimosse, ora è solo un ampliamento.
• Lambda-espressioni. Esistono ancora in qualche database?
• ML-supporto. Questo è presente in diversi DB, in alcuni meglio, in altri peggio.
• Codice aperto. Possiamo espandere ClickHouse insieme. Ora ci sono ClickHouse circa 500 collaboratori, e questo numero cresce costantemente.

Query complesse

In ClickHouse ci sono molti modi diversi per fare la stessa cosa. Ad esempio, è possibile restituire l'ultimo valore da una tabella in tre modi diversi per CPU (ce n'è anche un quarto, ma è persino più esotico).

Il primo mostra quanto sia comodo farlo in ClickHouse query, quando vuoi verificare che la tupla sia contenuta in una sottoquery. Questo è ciò che personalmente mi è sempre mancato in altri DB. Se voglio confrontare qualcosa con una sottoquery, in altri DB posso confrontare solo uno scalar, e per più colonne devo scrivere JOIN. In ClickHouse posso usare la tupla:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Il secondo modo fa la stessa cosa, ma utilizza la funzione aggregata argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

In ClickHouse ci sono diverse decine di funzioni aggregatrici, e se utilizzi i combinatori, secondo le leggi della combinatoria ce ne sarebbero circa mille. ArgMax è una delle funzioni che calcola il valore massimo: la query restituisce il valore usage_user, al quale corrisponde il valore massimo created_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF JOIN è la «fusione» di righe con tempi diversi. Questa è una funzione unica per i database, presente solo in kdb+. Se ci sono due serie temporali con tempi diversi, ASOF JOIN consente di sovrapporle e unire i risultati in una sola query. Per ogni valore in una serie temporale viene trovato il valore più vicino nell'altra, e questi vengono restituiti su una sola riga:

Funzioni analitiche

Nello standard SQL-2003 si può scrivere così:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

In ClickHouse così non si può — non supporta lo standard SQL-2003 e probabilmente non lo farà mai. Al contrario, in ClickHouse è consuetudine scrivere così:

Ho promesso le lambda – eccole!

Questo è l'equivalente di una query analitica nello standard SQL-2003: calcola la differenza tra due timestamp, durata, numero d'ordine — tutto ciò che solitamente consideriamo funzioni analitiche. In ClickHouse le consideriamo attraverso gli array: prima riduciamo i dati in un array, poi su quell'array facciamo tutto ciò che vogliamo, infine lo espandiamo di nuovo. Non è molto comodo, richiede una certa propensione alla programmazione funzionale, almeno, ma è molto flessibile.

Funzioni speciali

Inoltre, in ClickHouse ci sono molte funzioni specializzate. Ad esempio, come determinare quante sessioni si svolgono contemporaneamente? Un compito tipico per il monitoraggio è determinare il massimo carico con una singola query. In ClickHouse c'è una funzione speciale per questo scopo:

In generale, per molti scopi ClickHouse ha funzioni speciali:

• runningDifference, runningAccumulate, neighbor;
• sumMap(key, value);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

Questa non è una lista completa di funzioni, ce ne sono circa 500-600. Suggerimento: tutte le funzioni in ClickHouse sono presenti nella tabella di sistema (non tutte documentate, ma tutte interessanti):

select * from system.functions order by name

ClickHouse stesso contiene molte informazioni su di sé, inclusi log tables, query_log, log di tracing, log delle operazioni con blocchi di dati (part_log), log delle metriche e log di sistema, che solitamente scrive su disco. Il log delle metriche è time-series in ClickHouse in effetti ClickHouse: il DB può svolgere un ruolo per se stesso time-series database, in questo modo “digerendo” se stesso.

È anche una cosa unica — dato che facciamo bene il lavoro per time-series, perché non possiamo conservare in noi stessi tutto ciò che è necessario? Non abbiamo bisogno di Prometheus, conserviamo tutto dentro di noi. Abbiamo attivato Grafana e ci monitoriamo da soli. Tuttavia, se ClickHouse cadesse, non lo vedremmo — il perché — per cui solitamente non si fa così.

Un grande cluster o molti piccoli ClickHouse

Cosa è meglio — un grande cluster o molti piccoli ClickHouse? L'approccio tradizionale al DWH è un grande cluster, in cui vengono dedicate schemi per ogni applicazione. Ci siamo presentati all'amministratore del DB — datci uno schema, e ci è stato fornito:

In ClickHouse può essere fatto in un altro modo. Possiamo dare a ogni applicazione il proprio ClickHouse:

Non abbiamo più bisogno di grandi mostri DWH e amministratori intransigenti. Possiamo fornire a ogni applicazione il proprio ClickHouse, e lo sviluppatore può farlo da solo, poiché ClickHouse si installa molto facilmente e non richiede un'amministrazione complessa:

Ma se abbiamo molti ClickHouse, e dobbiamo installarlo spesso, vogliamo automatizzare questo processo. Per questo possiamo, ad esempio, usare Kubernetes e clickhouse-operatore. In Kubernetes ClickHouse può essere installato «con un clic»: posso premere un pulsante, avviare il manifesto e il database è pronto. Posso subito creare uno schema, iniziare a caricare le metriche e dopo 5 minuti ho già un dashboard pronto Grafana. Tutto è così semplice!

Qual è il risultato finale?

Quindi, ClickHouse è:

• Veloce. È noto a tutti.
• Semplice. È un po' discutibile, ma credo che sia difficile nell'apprendimento, facile nella battaglia. Se capisci come ClickHouse funziona, tutto diventa molto semplice.
• Universale. È adatto a diversi scenari: DWH, Time Series, Log Storage. Ma non è un database OLTP, quindi non provare a fare inserimenti e letture brevi. Interessante
• . Probabilmente, chi lavora con, ha vissuto molti momenti interessanti sia in senso buono che in senso cattivo. Ad esempio, è uscita una nuova versione e tutto ha smesso di funzionare. O quando hai lavorato su un problema per due giorni, ma dopo una domanda nella chat su Telegram la questione è stata risolta in due minuti. O come alla conferenza, nella presentazione di Alexei Milovidov, uno screenshot di ClickHouseha interrotto la trasmissione ClickHouse . Questo tipo di cose succede costantemente e rende la nostra vita con HighLoad++vibrante e interessante! ClickHouse La presentazione può essere vista

Il tanto atteso incontro dei sviluppatori di sistemi ad alta carico si terrà qui.

il 9 e 10 novembre a Skolkovo. Finalmente sarà una conferenza offline (anche se con tutte le misure di sicurezza), poiché l'energia di HighLoad++ non può essere imballata online. HighLoad++ Per la conferenza, cerchiamo e mostriamo casi sulle massime potenzialità delle tecnologie: HighLoad++ è stato, è e sarà l'unico posto dove in due giorni puoi scoprire come funzionano Facebook, Yandex, VKontakte, Google e Amazon.

Tenendo le nostre riunioni senza interruzioni dal 2007, quest'anno ci incontreremo per la 14ª volta. In questo periodo la conferenza è cresciuta 10 volte, l'evento chiave dello scorso anno ha riunito 3339 partecipanti, 165 relatori tra interventi e meetup, e contemporaneamente si sono svolti 16 track.

Lo scorso anno abbiamo avuto a disposizione 20 autobus, 5280 litri di tè e caffè, 1650 litri di succhi e 10200 bottigliette d'acqua. Inoltre, 2640 chilogrammi di cibo, 16000 piatti e 25000 bicchieri. A proposito, con i soldi ricavati dalla carta riciclata abbiamo piantato 100 giovani querce 🙂
I biglietti possono essere acquistati

, ricevere notizie sulla conferenza — qui, ricevi aggiornamenti sulla conferenza — qui, e per parlare — su tutti i social: Telegram, Facebook, Vkontakte e Twitter.

Fonte: habr.com