— è un sistema di gestione di database colonnare per l'elaborazione online di query analitiche (OLAP) open source, creato da Yandex. È utilizzato da Yandex, CloudFlare, VK.com, Badoo e altri servizi in tutto il mondo per archiviare veramente grandi volumi di dati (inserimento di migliaia di righe al secondo o petabyte di dati archiviati su disco).
In un normale DBMS "a righe", esempi dei quali sono MySQL, Postgres, MS SQL Server, i dati sono memorizzati in questo ordine:
In questo caso, i valori relativi a una riga sono fisicamente memorizzati vicini. Nei DBMS colonnari, i valori di diverse colonne sono memorizzati separatamente, e i dati di una colonna sono insieme:
Esempi di DBMS colonnari 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+.
Azienda – forwarder di posta ha iniziato a utilizzare Clickhouse nel 2018 per la generazione di report ed è rimasta molto impressionata dalla sua semplicità, scalabilità, supporto per SQL e velocità. La rapidità di questa DBMS sembrava magica.
Semplicità
Clickhouse si installa su Ubuntu con un unico comando. Se conosci SQL, puoi iniziare subito a utilizzare Clickhouse per le tue esigenze. Tuttavia, ciò non significa che puoi eseguire "show create table" in MySQL e fare un copia e incolla di SQL in Clickhouse.
Rispetto a MySQL, in questo DBMS ci sono differenze importanti nei tipi di dati nelle definizioni degli schemi delle tabelle, quindi per lavorare comodamente ti servirà comunque del tempo per modificare le definizioni degli schemi delle tabelle e studiare i motori delle tabelle.
Clickhouse funziona bene 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
- del confronto tra Clickhouse e Vertica e MySQL su un server con la seguente configurazione: due socket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 su 8 HDD SATA da 6TB, ext4.
- del confronto tra Clickhouse e il data warehouse cloud Amazon RedShift.
- Estratti dal blog :
Il database ClickHouse ha 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 composto da diversi nodi e abbiamo eseguito dei test, durante i quali abbiamo scoperto che il sistema ha prestazioni piuttosto impressionanti, che corrispondono ai 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 è stata la mancanza di strumenti e la scarsità della comunità 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, quindi abbiamo scritto un nostro servizio di adattatori in linguaggio Go. Questo leggeva i messaggi codificati Cap’n Proto da Kafka, li convertiva in TSV e li inseriva in ClickHouse in pacchetti tramite l'interfaccia HTTP. Successivamente, abbiamo riscritto questo servizio per utilizzare la libreria Go insieme al nostro interfaccia ClickHouse per migliorare le prestazioni. Durante la valutazione delle prestazioni della ricezione dei pacchetti, abbiamo scoperto una cosa importante: le prestazioni di ClickHouse dipendono fortemente dalla dimensione del pacchetto, cioè dal numero di righe inserite contemporaneamente. Per capire perché ciò accade, abbiamo studiato come ClickHouse memorizza i dati.
Il motore principale, o meglio, la famiglia di motori per tabelle utilizzata da ClickHouse per l'archiviazione dei dati, è MergeTree. Questo motore è concettualmente simile all'algoritmo LSM utilizzato in Google BigTable o Apache Cassandra, ma evita la creazione di una tabella intermedia in memoria e scrive i dati direttamente su disco. Questo gli conferisce un'ottima larghezza di banda in scrittura, poiché ogni pacchetto inserito viene ordinato solo in base alla 'chiave primaria' primary key, compresso e scritto su disco per formare un segmento.
L'assenza di una tabella di memoria o di qualsiasi concetto di "freschezza" dei dati significa anche che possono essere solo aggiunti, la modifica o la rimozione non sono supportate dal sistema. Oggi l'unico modo per eliminare i dati è rimuoverli mensilmente, poiché i segmenti non attraversano mai il confine del mese. Il team di ClickHouse sta lavorando attivamente per rendere questa funzione configurabile. D'altra parte, ciò rende la registrazione e la fusione dei segmenti prive di conflitti, quindi la larghezza di banda in entrata scala linearmente con il numero di inserimenti paralleli fino a quando non si verifica un saturamento di I/O o di CPU.
Tuttavia, questa circostanza significa anche che il sistema non è adatto per piccoli pacchetti, quindi si utilizzano servizi Kafka e inseritori per il buffering. Successivamente, ClickHouse continua a eseguire costantemente la fusione dei segmenti in background, in modo che molte piccole parti delle informazioni vengano unite e scritte più volte, aumentando così l'intensità della scrittura. Troppe parti non correlate causeranno un throttling aggressivo delle inserzioni fino a quando la fusione è in corso. Abbiamo scoperto che il miglior compromesso tra l'accettazione dei dati in tempo reale e le prestazioni di ricezione è 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 posizione dei dati su disco. Indipendentemente da quanto sia veloce l'elaborazione, quando il motore deve scansionare terabyte di dati dal disco e utilizzare solo una parte di essi, ci vorrà del tempo. ClickHouse è un archivio a colonne, quindi ogni segmento contiene un file per ciascuna colonna con valori ordinati per ogni riga. In questo modo, intere colonne non presenti nella query possono essere tralasciate all'inizio, e poi è possibile elaborare diverse celle in parallelo con l'esecuzione vettorializzata. Per evitare la scansione completa, ogni segmento ha un piccolo file indice.
Considerando che tutte le colonne sono ordinate per "chiave primaria", il file indice contiene solo i segnaposto (righe catturate) di ogni N-esima riga, consentendo di memorizzarli in memoria anche per tabelle di dimensioni molto grandi. Ad esempio, si possono impostare le opzioni predefinite per "contrassegnare ogni 8192ª riga", quindi la "scarsa" indicizzazione di una tabella con 1 trilione di righe, che può facilmente essere memorizzata in memoria, occuperà solo 122.070 caratteri.
Sviluppo del sistema
Lo sviluppo e il miglioramento di Clickhouse possono essere seguiti su e si può verificare che il processo di "crescita" avvenga a un ritmo impressionante.
Popolarità
Sembra che la popolarità di Clickhouse stia crescendo esponenzialmente, soprattutto nella comunità di lingua russa. La conferenza High load 2018 dell'anno scorso (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. In un 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 in ricerche, penso che ci siano aree in cui ClickHouse può essere utile o in grado di sostituire completamente altre soluzioni più tradizionali e popolari, come MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot e Druid. Di seguito sono riportati i dettagli sull'uso di ClickHouse per modernizzare o sostituire completamente i database menzionati.
Espansione delle capacità di MySQL e PostgreSQL
Recentemente abbiamo sostituito parzialmente MySQL con ClickHouse per la piattaforma delle newsletter . Il problema era che MySQL, a causa di un design poco studiato, registrava ogni email inviata e ciascun link in essa con un hash base64, creando un'immensa tabella MySQL (email_stats). Dopo aver inviato solo 10 milioni di email agli abbonati, questa tabella occupava 150 GB di spazio su disco, e MySQL iniziava a «rallentare» con le semplici query. Per risolvere il problema dello spazio su disco, abbiamo utilizzato con successo la compressione della tabella InnoDB, che l'ha ridotta di 4 volte. Tuttavia, non ha comunque senso conservare oltre 20-30 milioni di email in MySQL solo per la lettura della cronologia, poiché qualsiasi semplice query, che per qualche motivo dovrebbe eseguire una scansione completa, porta a uno swap e a un carico elevato sull'I/O, per il 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 dell'ELK
Dalla mia esperienza, lo stack ELK (ElasticSearch, Logstash e Kibana, in questo caso ElasticSearch) richiede molte più risorse per funzionare rispetto a quelle necessarie per memorizzare i log. ElasticSearch è un ottimo motore se hai bisogno di una buona ricerca full-text nei log (e non penso tu ne abbia realmente bisogno), ma mi chiedo perché sia diventato de facto il motore standard per la registrazione. La sua capacità di assorbimento, combinata con Logstash, ci ha creato problemi anche con carichi abbastanza piccoli e ha richiesto un'allocazione sempre maggiore di memoria e spazio su disco. Come DB, Clickhouse è migliore di ElasticSearch per i seguenti motivi:
- Supporto per il dialetto SQL;
- Migliore grado di compressione dei dati memorizzati;
- Supporto per la ricerca di espressioni regolari Regex anziché per la ricerca full-text;
- Pianificazione delle query migliorata e prestazioni complessive più elevate.
Attualmente, il problema più grande che si presenta nel confrontare ClickHouse con ELK è la mancanza di soluzioni per l'acquisizione dei log, così come la scarsità di documentazione e tutorial a riguardo. Tuttavia, ogni utente può configurare ELK utilizzando la guida di Digital Ocean, il che è molto importante per una rapida implementazione di tali tecnologie. Qui c'è un motore DB, ma per ora non c'è Filebeat per ClickHouse. Sì, è presente e sistema per lavorare con i log , esiste uno strumento per inserire in ClickHouse i dati dei log, ma tutto ciò richiede più tempo. Tuttavia, ClickHouse è comunque in testa per la sua semplicità, quindi anche i principianti lo installano facilmente e iniziano a utilizzarlo in modo completamente funzionale in appena 10 minuti.
Preferendo soluzioni minimalist, ho provato a utilizzare FluentBit, uno strumento per il caricamento dei log con un consumo 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 essere fatto senza uno strato di proxy che converte i dati da FluentBit a ClickHouse.
In alternativa a Kibana, si può utilizzare ClickHouse come backend . Da quanto ho capito, ci possono essere problemi di prestazioni nel renderizzare un numero enorme di punti dati, specialmente con le versioni più vecchie di Grafana. In Qwintry non abbiamo ancora provato, ma ci sono lamentele su questo che di tanto in tanto emergono nel canale di supporto di ClickHouse su Telegram.
Sostituzione di Google Big Query e Amazon RedShift (soluzione per grandi aziende)
L'uso ideale di BigQuery è caricare 1 TB di dati JSON ed eseguire su di essi query analitiche. Big Query è un ottimo prodotto, la scalabilità del quale è difficile da sovrastimare. È un software molto più complesso rispetto a ClickHouse, che opera su un cluster interno, ma dal punto di vista del cliente ha molto in comune con ClickHouse. BigQuery può rapidamente 'aumentare di prezzo', non appena inizi a pagare per ogni SELECT, quindi è 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, perché tale sostituzione ti aiuterà a risparmiare migliaia di dollari, se si tratta di molti terabyte di dati elaborati. Questo non si applica ai dati memorizzati, il cui trattamento in Big Query è piuttosto economico.
Nell'articolo del cofondatore di Altinity, Alexander Zaytsev si parla dei vantaggi di tale migrazione del DBMS.
Sostituzione di TimescaleDB
TimescaleDB è un'estensione di PostgreSQL che ottimizza il lavoro con le serie temporali in un database tradizionale., ).
Sebbene ClickHouse non rappresenti un concorrente significativo nel settore delle serie temporali, nella maggior parte dei casi di elaborazione delle query analitiche, la sua struttura a colonne e l'esecuzione vettoriale delle query lo rendono molto più veloce di TimescaleDB. Inoltre, le prestazioni nella ricezione di dati in batch di ClickHouse sono circa 3 volte superiori, e utilizza 20 volte meno spazio su disco, il che è davvero importante per elaborare grandi volumi 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 prossimi aggiornamenti di ClickHouse probabilmente introdurranno la compressione delta, che lo renderà ancora più adatto per l'elaborazione e la memorizzazione di dati di serie temporali. TimescaleDB può risultare una scelta migliore rispetto a ClickHouse "nudo" nei seguenti casi:
- piccole installazioni con pochissima memoria operativa (<3 GB);
- un elevato numero di SMALL INSERT che non si desidera bufferizzare in grandi frammenti;
- migliore coerenza, uniformità e requisiti ACID;
- supporto per PostGIS;
- integrazione con tabelle PostgreSQL esistenti, poiché fondamentalmente TimescaleDB è PostgreSQL.
Concorrenza con i sistemi Hadoop e MapReduce
Hadoop e altri prodotti di MapReduce possono eseguire numerosi calcoli complessi, ma generalmente funzionano con enormi latenza. ClickHouse risolve questo problema elaborando terabyte di dati e restituendo risultati quasi immediati. Pertanto, ClickHouse è molto più efficiente per condurre indagini analitiche interattive rapide, il che dovrebbe interessare i professionisti del trattamento dei dati.
Concorrenza con Pinot e Druid
I concorrenti più vicini a ClickHouse sono i prodotti open source a colonne scalabili come Pinot e Druid. Un eccellente confronto tra questi sistemi è stato pubblicato nell'articolo del 1 febbraio 2018.
Questo articolo ha bisogno di un aggiornamento - afferma che ClickHouse non supporta le operazioni UPDATE e DELETE, il che non è del tutto corretto per le versioni più recenti.
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 su tutti i lati.
Druid e Pinot sono progetti incubatori di Apache, il cui sviluppo è ampiamente trattato da Apache sulle pagine dei loro progetti GitHub. Pinot è apparso nell'incubatore nell'ottobre 2018, mentre Druid è nato 8 mesi prima, a febbraio.
La mancanza di informazioni su come funziona AFS suscita in me alcune, forse stupide, domande. È interessante notare che gli autori di Pinot hanno notato che la Apache Foundation è più favorevole a Druid, e se tale atteggiamento nei confronti del concorrente ha suscitato sentimenti di invidia? Lo sviluppo di Druid rallenterà e quello di Pinot accelererà se i finanziatori che supportano il primo si interesseranno improvvisamente al secondo?
Svantaggi di ClickHouse
Immaturità: è chiaro che è ancora una tecnologia in fase di sviluppo, ma in ogni caso, nulla di simile si osserva in altri DBMS a colonne.
Le piccole inserzioni funzionano male con velocità elevate: le inserzioni devono essere suddivise in grandi blocchi, poiché le prestazioni delle piccole inserzioni diminuiscono in proporzione al numero di colonne in ogni riga. È proprio così che i dati vengono memorizzati su disco in ClickHouse: ogni colonna rappresenta 1 file o più, quindi per inserire 1 riga contenente 100 colonne è necessario aprire e scrivere non meno di 100 file. Ecco perché è necessario un intermediario per il buffering delle inserzioni (a meno che il client stesso non garantisca il buffering): di solito è Kafka o qualche sistema di gestione delle code. È possibile utilizzare anche il motore Buffer table, per copiarne in seguito grandi frammenti in tabelle MergeTree.
Le connessioni tra tabelle sono limitate dalla memoria del server, ma almeno ci sono! Ad esempio, Druid e Pinot non hanno affatto tali connessioni, poiché è difficile implementarle direttamente in sistemi distribuiti che non supportano il trasferimento di grandi blocchi di dati tra nodi.
Conclusioni
Nei prossimi anni prevediamo di utilizzare ampiamente ClickHouse in Qwintry, poiché questo DBMS offre un eccellente equilibrio tra prestazioni, bassi costi generali, scalabilità e semplicità. Sono quasi certo che inizierà a diffondersi rapidamente, non appena la comunità di ClickHouse inventerà più modi per utilizzarlo in installazioni piccole e medie.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono 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! Leggi di
Fonte: habr.com
