è un sistema di gestione di database a colonne per l'elaborazione analitica online (OLAP) con codice sorgente aperto, sviluppato da Yandex. Viene utilizzato da Yandex, CloudFlare, VK.com, Badoo e altri servizi in tutto il mondo per archiviare enormi quantità di dati (inserendo migliaia di righe al secondo o petabyte di dati memorizzati su disco).
In un tradizionale DBMS "a righe", con esempi come MySQL, Postgres, MS SQL Server, i dati sono memorizzati in questo ordine:
In questo modo, i valori che appartengono alla stessa riga sono fisicamente memorizzati vicini. Nei DBMS a colonne, i valori di colonne diverse sono memorizzati separatamente, mentre i dati di una colonna sono memorizzati insieme:
Esempi di DBMS a colonne includono Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
L'azienda - mail forwarder ha iniziato a utilizzare Clickhouse nel 2018 per la creazione di report ed è rimasta molto colpita dalla sua semplicità, scalabilità, supporto per SQL e velocità. La rapidità di questa DBMS sfiorava la magia.
Semplicità
Clickhouse si installa su Ubuntu con un semplice comando. Se conosci SQL, puoi immediatamente iniziare a utilizzare Clickhouse per le tue esigenze. Tuttavia, questo non significa che tu possa semplicemente eseguire «show create table» in MySQL e copiare il SQL in Clickhouse.
Rispetto a MySQL, ci sono importanti differenze nei tipi di dati nelle definizioni degli schemi delle tabelle in questo DBMS, quindi avrai comunque bisogno di un po' di tempo per modificare le definizioni degli schemi delle tabelle e imparare i motori delle tabelle.
Clickhouse funziona perfettamente senza alcun software aggiuntivo, ma se desideri utilizzare la replica, dovrai installare ZooKeeper. L'analisi delle prestazioni delle query mostra risultati eccellenti: le tabelle di sistema contengono tutte le informazioni e tutti i dati possono essere ottenuti tramite il vecchio e noioso SQL.
Prestazioni
- confronti tra Clickhouse, Vertica e MySQL su un server di configurazione: due socket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB di RAM; md RAID-5 su 8 HDD SATA da 6 TB, ext4.
- confronti tra Clickhouse e il data warehouse cloud Amazon RedShift.
- Estratti dal blog :
Il database ClickHouse presenta un design molto semplice: tutti i nodi nel cluster hanno la stessa funzionalità e utilizzano solo ZooKeeper per la coordinazione. Abbiamo costruito un piccolo cluster di alcuni nodi e abbiamo eseguito test, durante i quali abbiamo scoperto che il sistema offre prestazioni piuttosto impressionanti, in linea con i vantaggi dichiarati nei benchmark dei database analitici. Abbiamo deciso di esaminare più nel dettaglio il concetto alla base di ClickHouse. Il primo ostacolo alla ricerca è stato l'assenza di strumenti e la scarsità della comunità di ClickHouse, quindi ci siamo immersi nel design di questo DBMS per capire come funziona.
ClickHouse non supporta la ricezione di dati direttamente da Kafka, poiché è solo un database. Per questo motivo abbiamo creato un nostro servizio di adattatori in Go. Questo leggeva i messaggi codificati Cap’n Proto da Kafka, li trasformava in TSV e li inseriva in ClickHouse in pacchetti tramite l'interfaccia HTTP. In seguito, abbiamo riscritto questo servizio per utilizzare la libreria Go insieme alla nostra interfaccia ClickHouse per migliorare le prestazioni. Quando abbiamo valutato le prestazioni della ricezione dei pacchetti, abbiamo scoperto una cosa importante: si è rivelato che le prestazioni di ClickHouse dipendono fortemente dalla dimensione del pacchetto, ovvero dal numero di righe inserite contemporaneamente. Per comprendere perché ciò accade, abbiamo esaminato come ClickHouse memorizza i dati.
Il motore principale, o meglio, la famiglia di motori per le tabelle utilizzato da ClickHouse per l'archiviazione dei dati è MergeTree. Questo motore è concettualmente simile all'algoritmo LSM utilizzato in Google BigTable o Apache Cassandra, ma evita di costruire una tabella intermedia in memoria e scrive i dati direttamente sul disco. Questo gli conferisce un'ottima capacità di scrittura, poiché ogni pacchetto inserito viene ordinato solo in base alla "chiave primaria" primary key, compresso e scritto sul disco per formare un segmento.
L'assenza di una tabella della memoria o di un qualsiasi concetto di "freschezza" dei dati implica che questi possano essere soltanto aggiunti, mentre la modifica o la rimozione non sono supportate dal sistema. Ad oggi, l'unico modo per eliminare i dati è cancellarli per mese, poiché i segmenti non superano mai il confine del mese. Il team di ClickHouse sta lavorando attivamente per rendere questa funzione personalizzabile. D'altra parte, questo rende la registrazione e la fusione dei segmenti senza conflitti, quindi la capacità di assorbimento si scala linearmente con il numero di inserimenti paralleli fino a quando non si verifica un saturazione dell'I/O o delle CPU.
Tuttavia, questa circostanza implica anche che il sistema non sia adatto per piccoli pacchetti; pertanto, vengono utilizzati servizi Kafka e inserter per il buffering. Inoltre, ClickHouse continua a eseguire in background la fusione dei segmenti, così che molte piccole parti di informazione verranno unite e scritte più volte, aumentando così l'intensità della scrittura. Troppe parti non collegate, però, innescheranno un throttling aggressivo delle inserzioni fino a quando la fusione è in corso. Abbiamo scoperto che il miglior compromesso tra l'acquisizione di dati in tempo reale e le prestazioni di assorbimento è l'accettazione in tabella di un numero limitato di inserimenti al secondo.
La chiave per le prestazioni di lettura delle tabelle è l'indicizzazione e la disposizione dei dati su disco. Indipendentemente dalla velocità di elaborazione, quando il motore deve esaminare terabyte di dati dal disco e ne utilizza solo una parte, ci vorrà tempo. ClickHouse è un database colonnare, quindi ogni segmento contiene un file per ogni colonna con valori ordinati per ogni riga. Così, intere colonne assenti nella query possono essere saltate in anticipo e quindi diverse celle possono essere elaborate in parallelo con l'esecuzione vettoriale. Per evitare una scansione completa, ogni segmento ha un piccolo file di indice.
Dato che tutte le colonne sono ordinate per 'chiave primaria', il file di indice contiene solo i marcatori (righe catturate) di ogni N-esima riga, in modo da poterli memorizzare in memoria anche per tabelle molto grandi. Ad esempio, si possono impostare le impostazioni predefinite per 'segnare ogni 8192-esima riga', quindi l'indicizzazione 'scarsa' di una tabella con 1 trilione di righe, che si adatta facilmente in memoria, richiederà solo 122.070 caratteri.
Sviluppo del sistema
Lo sviluppo e il perfezionamento di Clickhouse possono essere seguiti su e puoi verificare che il processo di 'crescita' sta avvenendo a un ritmo impressionante.
Popolarità
Sembra che la popolarità di Clickhouse stia crescendo esponenzialmente, soprattutto nella comunità di lingua russa. La conferenza dello scorso anno High Load 2018 (Mosca, 8-9 novembre 2018) ha dimostrato che mostri come vk.com e Badoo utilizzano Clickhouse, con cui inseriscono dati (ad esempio, log) da decine di migliaia di server contemporaneamente. Nel video di 40 minuti . Presto pubblicheremo la trascrizione su Habr per facilitare il lavoro con il materiale.
Ambiti di applicazione
Dopo aver trascorso del tempo a ricercare, penso che esistano aree in cui ClickHouse può essere utile o può completamente sostituire altre soluzioni più tradizionali e popolari, come MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot e Druid. Di seguito sono forniti dettagli sull'uso di ClickHouse per modernizzare o sostituire completamente i suddetti DBMS.
Espansione delle possibilità di MySQL e PostgreSQL
Recentemente abbiamo parzialmente sostituito MySQL con ClickHouse per la piattaforma delle newsletter. . Il problema era che MySQL, a causa di un design poco ponderato, registrava ogni email inviata e ogni link all'interno di essa con un hash base64, creando così una tabella MySQL molto grande (email_stats). Dopo aver inviato ai sottoscrittori del servizio 10 milioni di email, questa tabella occupava 150 GB di spazio, e MySQL iniziava a rallentare nelle query semplici. Per risolvere il problema dello spazio, abbiamo utilizzato con successo la compressione della tabella InnoDB, riducendone le dimensioni di quattro volte. Tuttavia, non ha comunque senso conservare più di 20-30 milioni di email in MySQL solo per leggere la cronologia, poiché qualsiasi semplice query che per qualche motivo deve eseguire una scansione completa porta a swap e a un carico elevato su I/O, a riguardo del quale ricevevamo regolarmente avvisi da Zabbix.
ClickHouse utilizza due algoritmi di compressione che riducono il volume dei dati di circa , ma in questo caso specifico i dati erano particolarmente 'compressibili'.
Sostituzione ELK
In base alla mia esperienza, lo stack ELK (ElasticSearch, Logstash e Kibana, in questo caso specifico ElasticSearch) richiede molte più risorse per avviarsi di quanto sia necessario per memorizzare i log. ElasticSearch è un ottimo motore se hai bisogno di una buona ricerca testuale nei log (e non credo che sia davvero necessario), ma mi chiedo perché sia diventato de facto il motore standard per la registrazione. Le sue prestazioni di ricezione, insieme a Logstash, ci hanno creato problemi anche con carichi di lavoro relativamente leggeri e hanno richiesto l'aggiunta di sempre maggiore memoria RAM e spazio su disco. Come database, Clickhouse è superiore a ElasticSearch per i seguenti motivi:
- Supporto per il dialetto SQL;
- Miglior tasso di compressione dei dati memorizzati;
- Supporto per la ricerca con espressioni regolari Regex invece della ricerca testuale completa;
- Pianificazione delle query migliorata e prestazioni complessive più elevate.
Attualmente, la principale problematica nel confrontare ClickHouse con ELK è la mancanza di soluzioni per la spedizione dei log e la carenza di documentazione e tutorial su questo argomento. Ogni utente può configurare ELK seguendo la guida di Digital Ocean, il che è fondamentale per una rapida implementazione di tecnologie simili. C'è un motore di database, ma attualmente manca Filebeat per ClickHouse. Sì, è presente e un sistema per la gestione dei log , esiste uno strumento per l'immissione dei dati dei log in ClickHouse, ma tutto ciò richiede più tempo. Tuttavia, ClickHouse resta comunque il leader grazie alla sua semplicità, quindi anche i principianti riescono a installarlo facilmente e iniziare a utilizzarlo completamente in appena 10 minuti.
Preferendo soluzioni minimaliste, ho provato a utilizzare FluentBit, uno strumento per la spedizione dei log con un ingombro di memoria molto ridotto, insieme a ClickHouse, cercando di evitare l'uso di Kafka. Tuttavia, è necessario risolvere alcune piccole incompatibilità, come , prima che ciò possa avvenire senza un livello proxy che converte i dati da FluentBit a ClickHouse.
Come alternativa a Kibana, si può utilizzare ClickHouse come backend. A quanto ho capito, questo può causare problemi di prestazioni quando si rendono enormi quantità di dati, specialmente con versioni più vecchie di Grafana. In Qwintry non lo abbiamo provato finora, ma ci sono lamentele a riguardo che emergono di tanto in tanto nel canale di supporto di ClickHouse su Telegram.
Sostituto di Google Big Query e Amazon RedShift (soluzione per grandi aziende)
L'uso ideale di BigQuery è caricare 1 TB di dati JSON e eseguire query analitiche su di essi. BigQuery è un ottimo prodotto, la cui scalabilità è difficile da sovrastimare. È un software molto più complesso di ClickHouse, che opera su un cluster interno, ma dal punto di vista del cliente ha molto in comune con ClickHouse. BigQuery può diventare rapidamente "costoso" non appena si inizia a pagare per ogni SELECT, rendendolo una vera soluzione SaaS con tutti i suoi pro e contro.
ClickHouse è la scelta migliore quando esegui molte query costose in termini di calcolo. Più query SELECT esegui ogni giorno, più ha senso sostituire Big Query con ClickHouse, poiché questa sostituzione può farti risparmiare migliaia di dollari quando si tratta di molti terabyte di dati elaborati. Questo non si applica ai dati memorizzati, la cui elaborazione in Big Query è piuttosto economica.
Nell'articolo del co-fondatore di Altinity, Aleksandr Zaicev si parla dei vantaggi di tale migrazione del DBMS.
Sostituzione di TimescaleDB
TimescaleDB è un'estensione di PostgreSQL che ottimizza la gestione delle serie temporali in un normale database., ).
Sebbene ClickHouse non sia un serio concorrente nel campo dei dati temporali, la sua struttura colonnare e l'elaborazione vettoriale delle query lo rendono, nella maggior parte dei casi, molto più veloce di TimescaleDB per l'elaborazione delle query analitiche. Inoltre, le prestazioni nell'accettare dati in batch di ClickHouse sono circa tre volte superiori e utilizza anche venti volte meno spazio su disco, il che è davvero importante per la gestione di grandi quantità di dati storici..
A differenza di ClickHouse, l'unico modo per risparmiare un po' di spazio su disco in TimescaleDB è utilizzare ZFS o file system simili.
I futuri aggiornamenti di ClickHouse introdurranno probabilmente la compressione delta, rendendolo ancora più adatto per l'elaborazione e la conservazione dei dati temporali. TimescaleDB potrebbe diventare una scelta migliore rispetto al «semplice» ClickHouse nei seguenti casi:
- piccole installazioni con pochissima RAM (<3 GB);
- un gran numero di piccoli INSERT che non si vogliono bufferizzare in grandi frammenti;
- migliore coerenza, uniformità e requisiti ACID;
- supporto per PostGIS;
- integrazione con le tabelle PostgreSQL esistenti, poiché sostanzialmente Timescale DB è PostgreSQL.
Concorrenza con i sistemi Hadoop e MapReduce
Hadoop e altri prodotti MapReduce possono eseguire una serie di calcoli complessi, ma tendono a funzionare con enormi ritardi. ClickHouse risolve questo problema elaborando terabyte di dati e restituendo i risultati quasi istantaneamente. Di conseguenza, ClickHouse è molto più efficiente per eseguire ricerche analitiche rapide e interattive, il che dovrebbe interessare i professionisti del trattamento dei dati.
Concorrenza con Pinot e Druid
I principali concorrenti di ClickHouse sono i prodotti open source colonne linearmente scalabili Pinot e Druid. Un eccellente confronto tra questi sistemi è pubblicato nell'articolo del 1 febbraio 2018.
Questo articolo richiede un aggiornamento: afferma che ClickHouse non supporta le operazioni UPDATE e DELETE, il che non è del tutto corretto per le ultime versioni.
Non abbiamo abbastanza esperienza con questi DBMS, ma non mi piace affatto la complessità dell'infrastruttura necessaria per avviare Druid e Pinot: ci sono un sacco di "parti mobili" circondate da Java da tutte le parti.
Druid e Pinot sono progetti incubatori di Apache, il cui sviluppo viene dettagliatamente seguito da Apache sulle pagine dei propri progetti su GitHub. Pinot è nato nell'incubatore nell'ottobre 2018, mentre Druid è comparso 8 mesi prima, a febbraio.
La mancanza di informazioni su come funziona AFS mi solleva alcune, e forse sciocche, domande. È interessante sapere se gli autori di Pinot hanno notato che la Apache Foundation è più favorevole a Druid, e se questo atteggiamento verso un concorrente abbia suscitato sentimenti di invidia? Lo sviluppo di Druid rallenterà e quello di Pinot accelererà se i sostenitori del primo si interesseranno improvvisamente al secondo?
Svantaggi di ClickHouse
Immaturità: è evidente che si tratta ancora di una tecnologia in fase di sviluppo, ma ad ogni modo, non si osserva nulla di simile in altri DBMS a colonne.
Le piccole inserzioni funzionano male con elevate velocità: le inserzioni devono essere suddivise in pezzi più grandi, poiché le prestazioni delle piccole inserzioni diminuiscono proporzionalmente al numero di colonne in ogni riga. Questo è il modo in cui ClickHouse memorizza i dati su disco: ogni colonna equivale a 1 file o più, quindi per inserire 1 riga contenente 100 colonne è necessario aprire e scrivere almeno 100 file. Ecco perché è necessario un intermediario per il buffering delle inserzioni (a meno che non sia il cliente stesso a fornire il buffering): di solito si tratta di Kafka o di un sistema di gestione delle code. È anche possibile utilizzare il motore della tabella Buffer per copiare successivamente grandi blocchi di dati nelle tabelle MergeTree.
Le join tra tabelle sono limitate dalla memoria RAM del server, ma almeno ci sono! Ad esempio, Druid e Pinot non hanno affatto queste join, poiché sono difficili da implementare direttamente in sistemi distribuiti che non supportano lo spostamento di grandi blocchi di dati tra nodi.
Conclusioni
Nei prossimi anni, prevediamo di utilizzare ampiamente ClickHouse in Qwintry, poiché questo DBMS offre un ottimo equilibrio tra prestazioni, costi operativi ridotti, scalabilità e semplicità. Sono quasi sicuro che inizierà a diffondersi rapidamente non appena la comunità di ClickHouse troverà più modi per utilizzarlo in installazioni di piccole e medie dimensioni.
Un po' di pubblicità 🙂
Grazie per essere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci ai tuoi conoscenti, , un'alternativa unica ai server entry-level, che abbiamo creato per te: (disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Scopri di più su
Fonte: habr.com
