hè un sistema di gestione di basa di dati colonnari open-source per l'elaborazione di e dumande analitiche in linea (OLAP) creatu da Yandex. Hè utilizatu da Yandex, CloudFlare, VK.com, Badoo è altri servizii in u mondu per almacenà quantità veramente grande di dati (inserzione di millaie di fila per seconda o petabytes di dati almacenati in discu).
In un DBMS normale "stringa", esempi di quale sò MySQL, Postgres, MS SQL Server, i dati sò guardati in questu ordine:
In questu casu, i valori ligati à a listessa linea sò fisicamente guardati fiancu à fiancu. In DBMS colonnare, i valori di e diverse colonne sò almacenati separatamente, è i dati di una colonna sò almacenati inseme:
Esempi di DBMS colonnari sò Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
A cumpagnia hè un mail forwarder Aghju cuminciatu à aduprà Clickhouse in 2018 per i rapporti è era assai impressiunatu cù a so simplicità, scalabilità, supportu SQL è rapidità. A vitezza di stu DBMS cunfina cù a magia.
Semplicità
Clickhouse installate nantu à Ubuntu cun un solu cumandamentu. Se sapete SQL, pudete immediatamente principià cù Clickhouse per i vostri bisogni. Tuttavia, questu ùn significa micca chì pudete "mostra a tavola di creazione" in MySQL è copia-incolla SQL in Clickhouse.
Comparatu à MySQL, ci sò differenze di tippu di dati impurtanti in e definizioni di schema di tabella in questu DBMS, cusì avete bisognu di qualchì tempu per cambià e definizioni di schema di tabella è amparà i mutori di tabella per esse còmode.
Clickhouse funziona bè senza software supplementu, ma se vulete utilizà a replicazione, avete bisognu di installà ZooKeeper. L'analisi di u rendiment di a dumanda mostra risultati eccellenti - i tavule di u sistema cuntenenu tutte l'infurmazioni, è tutte e dati ponu esse ottenuti cù SQL anticu è noioso.
Produttività
- Comparazioni Clickhouse versus Vertica è MySQL nantu à u servitore di cunfigurazione: dui sockets Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 su 8 HDD SATA da 6 TB, ext4.
- paragone di Clickhouse cù Amazon RedShift cloud storage.
- Estratti di blog :
A basa di dati ClickHouse hà un disignu assai simplice - tutti i nodi in u cluster anu a listessa funziunalità è utilizate solu ZooKeeper per a coordinazione. Avemu custruitu un picculu cluster di parechji nodi è eseguite teste, durante quale avemu trovu chì u sistema hà un rendimentu abbastanza impressiunanti, chì currisponde à i vantaghji rivendicati in benchmarks analitici DBMS. Avemu decisu di piglià un ochju più vicinu à u cuncettu daretu à ClickHouse. U primu ostaculu per a ricerca era a mancanza di strumenti è a piccula cumunità di ClickHouse, cusì avemu intruduciutu in u disignu di stu DBMS per capisce cumu si travaglia.
ClickHouse ùn sustene micca riceve dati direttamente da Kafka, postu chì hè solu una basa di dati, cusì avemu scrittu u nostru propiu serviziu di adattatore in Go. Leghje i missaghji codificati Cap'n Proto da Kafka, li cunvertisce in TSV, è li inserisce in ClickHouse in batch via l'interfaccia HTTP. Dopu avemu riscritto stu serviziu per utilizà a biblioteca Go in cungiunzione cù a nostra propria interfaccia ClickHouse per migliurà u rendiment. Quandu evaluà u rendiment di riceve pacchetti, avemu scupertu una cosa impurtante - hè risultatu chì per ClickHouse sta prestazione dipende assai da a dimensione di u pacchettu, vale à dì u numeru di fila inseriti à u stessu tempu. Per capisce perchè questu succede, avemu studiatu cumu ClickHouse guarda i dati.
U mutore principale, o megliu, una famiglia di mutori di tavulinu utilizati da ClickHouse per almacenà dati, hè MergeTree. Stu mutore hè conceptualmente simili à l'algoritmu LSM utilizatu in Google BigTable o Apache Cassandra, ma evita di custruisce una tavola di memoria intermedia è scrive dati direttamente à u discu. Questu li dà un rendimentu di scrittura eccellente, postu chì ogni pacchettu inseritu hè solu ordinatu da a chjave primaria "chjave primaria", cumpressa è scritta à u discu per furmà un segmentu.
L'absenza di una tavola di memoria o qualsiasi cuncettu di "freschezza" di dati significa ancu chì ponu esse aghjuntu solu, u sistema ùn sustene micca cambià o sguassà. A data d'oghje, l'unicu modu per sguassà e dati hè di sguassà per u mese di u calendariu, postu chì i segmenti ùn attraversanu mai u cunfini di un mese. A squadra di ClickHouse travaglia attivamente per fà sta funzione persunalizabile. Per d 'altra banda, rende l'scrittura è a fusione di i segmenti senza cuntenzione, cusì riceve scale di throughput linearmente cù u nùmeru d'inserzioni parallele finu à chì l'I / O o i nuclei saturanu.
Tuttavia, sta circustanza significa ancu chì u sistema ùn hè micca adattatu per i picculi pacchetti, cusì i servizii Kafka è inseritori sò usati per buffering. In più, ClickHouse in u sfondate cuntinueghja à unisce continuamente i segmenti, cusì chì parechji picculi pezzi d'infurmazioni seranu cumminati è arregistrati più volte, cusì aumentendu l'intensità di a registrazione. In ogni casu, troppu parte senza relazione pruvucarà un throttling aggressivu di inserti sempre chì a fusione cuntinueghja. Avemu trovu chì u megliu cumprumissu trà l'ingerimentu di dati in tempu reale è u rendiment di l'ingerimentu hè di accettà un numeru limitatu di inserimenti per seconda in a tavula.
A chjave per u rendiment di lettura di a tavula hè l'indexazione è u locu di e dati nantu à u discu. Ùn importa micca a velocità di u processu, quandu u mutore hà bisognu di scansà terabytes di dati da u discu è solu aduprà una frazzioni di questu, duverà tempu. ClickHouse hè un magazinu di colonna, cusì ogni segmentu cuntene un schedariu per ogni colonna (colonna) cù valori ordinati per ogni fila. Cusì, e culonne intere chì ùn sò micca prisenti in a dumanda ponu esse saltate prima, è dopu parechje cellule ponu esse processate in parallelu cù l'esekzione vectorizzata. Per evitari una scansione cumpleta, ogni segmentu hà un picculu file index.
Dapoi chì tutte e culonne sò ordinate da a "chjave primaria", u schedariu indexu cuntene solu l'etichette (fila catturata) di ogni fila Nth, per pudè mantene in memoria ancu per tavule assai grande. Per esempiu, pudete stabilisce i paràmetri predeterminati per "marcà ogni fila 8192", dopu l'indexazione "magra" di una tavola cù 1 trilione. e linee chì si mette facilmente in memoria piglianu solu 122 070 caratteri.
Sviluppu di u sistema
U sviluppu è a migliione di Clickhouse ponu esse tracciati è assicuratevi chì u prucessu di "crescente" si faci à un ritmu impressiunanti.
Popularity
Sembra chì a popularità di Clickhouse cresce in modu esponenziale, soprattuttu in a cumunità di lingua russa. A cunferenza High load 2018 di l'annu passatu (Mosca, 8-9 Novembre 2018) hà dimustratu chì i mostri cum'è vk.com è Badoo utilizanu Clickhouse, chì inserisce dati (per esempiu, logs) da decine di millaie di servitori simultaneamente. In un video di 40 minuti . Prestu pubblicheremu a trascrizione in Habr per a cunvenzione di travaglià cù u materiale.
Applicazioni
Dopu avè passatu qualchì tempu in ricerca, pensu chì ci sò spazii induve ClickHouse pò esse utile o capace di rimpiazzà cumplettamente altre soluzioni più tradiziunali è populari cum'è MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot è Druida. I seguenti sò i dettagli di l'usu di ClickHouse per aghjurnà o rimpiazzà cumplettamente u DBMS sopra.
Estende MySQL è PostgreSQL
Più recentemente, avemu sustituitu parzialmente MySQL cù ClickHouse per a piattaforma di newsletter . U prublema era chì MySQL per via di un disignu malu cuncepitu hà registratu ogni email mandatu è ogni ligame in quellu email cù un hash base64, creendu una tavola MySQL enormosa (email_stats). Dopu avè mandatu solu 10 milioni di email à l'abbonati di u serviziu, sta tavula occupava 150 GB di spaziu di fugliale, è MySQL hà cuminciatu à "stupidu" nantu à e dumande simplici. Per risolve u prublema di u spaziu di l'archiviu, avemu utilizatu cun successu a compressione di a tavola InnoDB, chì l'hà ridutta da un fattore di 4. Tuttavia, ùn hà ancu sensu per almacenà più di 20-30 milioni di e-mail in MySQL solu per a fine di a storia di lettura, cum'è qualsiasi dumanda simplice chì per qualchì mutivu hà da fà una scansione completa risultati in swap è I / O pesante. overhead, circa chì avemu ricevutu regularmente avvisi Zabbix.
Clickhouse usa dui algoritmi di cumpressione chì riduce a quantità di dati da circa , ma in questu casu particulari, a dati era soprattuttu "compressible".
ELK sustituzione
Basatu nantu à a mo propria sperienza, a pila ELK (ElasticSearch, Logstash è Kibana, in questu casu particulari ElasticSearch) necessita assai più risorse per eseguisce di ciò chì hè necessariu per almacenà logs. ElasticSearch hè un grande mutore se vulete una bona ricerca di log in testu sanu (chì ùn pensu micca veramente bisognu), ma mi dumandu perchè hè diventatu u mutore di logu standard di facto. A so prestazione di ingestione, cumminata cù Logstash, ci hà datu prublemi ancu à carichi di travagliu abbastanza ligeri è necessitava l'aghjunzione di più è più RAM è spaziu di discu. Cum'è una basa di dati, Clickhouse hè megliu cà ElasticSearch per i seguenti motivi:
- supportu di dialettu SQL;
- U megliu gradu di cumpressione di dati almacenati;
- Supportu per a ricerca Regex invece di a ricerca di testu sanu;
- Programmazione di query mejorata è megliu rendimentu generale.
Attualmente, u prublema più grande chì sorge quandu si compara ClickHouse cù ELK hè a mancanza di suluzioni per a carica di logs, è ancu a mancanza di documentazione è tutoriali nantu à questu tema. À u listessu tempu, ogni utilizatore pò stallà ELK utilizendu u manuale di l'Oceanu Digitale, chì hè assai impurtante per l'implementazione rapida di tali tecnulugia. Ci hè un mutore di basa di dati quì, ma ùn ci hè ancu Filebeat per ClickHouse. Iè, ci hè è un sistema per travaglià cù logs , ci hè un strumentu per inserisce i dati di u schedariu di log in ClickHouse, ma tuttu questu piglia più tempu. Tuttavia, ClickHouse guida sempre a strada per via di a so simplicità, cusì ancu i principianti ponu facilmente installallu è principià l'usu cumplettamente funziunale in solu 10 minuti.
Preferendu suluzioni minimalisti, aghju pruvatu à utilizà FluentBit, un strumentu di caricamentu di log di memoria assai bassu, cù ClickHouse mentre cercava di evità di utilizà Kafka. Tuttavia, incompatibilità minori deve esse trattatu, cum'è prima di pudè esse fattu senza a capa proxy chì cunverte dati da FluentBit à ClickHouse.
Comu alternativa à Kibana, pudete aduprà ClickHouse cum'è backend . Per quantu capiscu, questu pò causà prublemi di rendiment quandu rende un gran numaru di punti di dati, soprattuttu cù versioni più vechje di Grafana. In Qwintry, ùn avemu micca pruvatu ancu questu, ma lagnanze nantu à questu appariscenu di tantu in tantu in u canali di supportu ClickHouse in Telegram.
Sustituzione di Google Big Query è Amazon RedShift (soluzione per grandi cumpagnie)
U casu d'utilizazione ideale per BigQuery hè di carricà 1TB di dati JSON è eseguite dumande analitiche nantu à questu. Big Query hè un grande pruduttu chì a scalabilità hè difficiule di sopravvalutà. Questu hè un software assai più cumplessu di ClickHouse chì funziona in un cluster internu, ma da u puntu di vista di u cliente, hà assai in cumunu cù ClickHouse. BigQuery pò "aumentà u prezzu" rapidamente una volta chì avete principiatu à pagà per ogni SELECT, cusì hè una vera suluzione SaaS cù tutti i so pro è i contra.
ClickHouse hè a megliu scelta quandu eseguite assai dumande di calculu caru. Quantu più SELECT chì eseguite ogni ghjornu, u più puntu hè di rimpiazzà Big Query cù ClickHouse, perchè un tali rimpiazzamentu vi risparmià millaie di dollari quandu si tratta di parechji terabyte di dati chì sò processati. Questu ùn hè micca applicatu à i dati almacenati, chì hè abbastanza economicu per processà in Big Query.
In un articulu di Alexander Zaitsev, cofundatore di Altinity descrive i benefici di una tale migrazione DBMS.
Sostituzione di TimescaleDB
TimescaleDB hè una estensione PostgreSQL chì ottimizza u travagliu cù serie temporali in una basa di dati regulare (, ).
Ancu se ClickHouse ùn hè micca un competitore seriu in u niche di a serie di u tempu, ma in quantu à a struttura di colonna è l'esekzione di query vector, hè assai più veloce di TimescaleDB in a maiò parte di i casi di trasfurmazioni di e dumande analitiche. À u listessu tempu, u rendiment di riceve dati di u pacchettu ClickHouse hè di circa 3 volte più altu, in più, usa 20 volte menu spaziu di discu, chì hè veramente impurtante per processà grandi volumi di dati storichi: .
A cuntrariu di ClickHouse, l'unicu modu per salvà un pocu spaziu di discu in TimescaleDB hè di utilizà ZFS o sistemi di schedari simili.
L'aghjurnamenti futuri di ClickHouse prubabilmente introduceranu a compressione delta, chì a rende ancu più adatta per u processu è l'almacenamiento di dati di serie temporale. TimescaleDB pò esse una scelta megliu cà Bare ClickHouse in i seguenti casi:
- picculi installazioni cù pocu RAM (<3 GB);
- un gran numaru di picculi INSERT chì ùn vulete micca buffer in frammenti grossi;
- megliu coerenza, uniformità è esigenze ACID;
- supportu PostGIS;
- unisce cù e tavule PostgreSQL esistenti, postu chì Timescale DB hè essenzialmente PostgreSQL.
Cumpetizione cù i sistemi Hadoop è MapReduce
Hadoop è altri prudutti MapReduce ponu fà assai calculi cumplessi, ma tendenu à curriri à una latenza enormi. ClickHouse risolve stu prublema tratendu terabyte di dati è pruduce risultati quasi istantaneamente. Cusì, ClickHouse hè assai più efficiente per fà una ricerca analitica rapida è interattiva, chì deve esse di interessu à i scientifichi di dati.
Cumpetizione cù Pinot è Druid
I cuncurrenti più vicini di ClickHouse sò i prudutti open source, linearmente scalabili, Pinot è Druid. Un travagliu eccellente paragunendu sti sistemi hè publicatu in l'articulu 1 di ferraghju 2018
Questu articulu deve esse aghjurnatu - dice chì ClickHouse ùn sustene micca l'operazione UPDATE è DELETE, chì ùn hè micca veramente vera in relazione à l'ultime versioni.
Ùn avemu micca assai spirienza cù questi DBMS, ma ùn mi piace micca a cumplessità di l'infrastruttura sottostante chì hè necessariu per eseguisce Druid è Pinot - hè una mansa di "parti in muvimentu" circundatu da Java da tutti i lati.
Druid è Pinot sò prughjetti d'incubatori Apache, chì sò cuparti in dettagliu da Apache nantu à e so pagine di prughjettu GitHub. Pinot apparsu in l'incubatore in uttrovi 2018, è Druid hè natu 8 mesi prima - in February.
A mancanza d'infurmazioni nantu à u funziunamentu di l'AFS suscite parechje dumande, è forsi stupidu, per mè. Mi dumandu s'ellu l'autori di Pinot anu nutatu chì a Fundazione Apache hè più disposta versu Druid, è una tale attitudine versu un cuncurrente hà causatu un sensu d'invidia? U sviluppu di Druid rallentarà è u sviluppu di Pinot accelerà se i patrocinatori chì sustenenu l'anzianu s'interessanu di colpu à l'ultime ?
Svantaghji di ClickHouse
Immaturità: Ovviamente, questu hè sempre una tecnulugia noiosa, ma in ogni casu, nunda cum'è questu hè vistu in altri DBMS columnar.
L'inserti chjuchi ùn funzionanu micca bè à alta velocità: l'inserzioni deve esse divisu in grossi pezzi perchè u rendiment di inserzioni chjuchi si degrada in proporzione à u numeru di colonne in ogni fila. Questu hè cumu ClickHouse guarda dati nantu à u discu - ogni colonna significa 1 file o più, cusì per inserisce 1 fila chì cuntene 100 colonne, avete bisognu di apre è scrive almenu 100 schedari. Hè per quessa chì l'inserimentu di buffering richiede un intermediariu (salvo chì u cliente stessu furnisce un buffering) - di solitu Kafka o un tipu di sistema di fila. Pudete ancu aduprà u mutore di tavulinu Buffer per copià più tardi pezzi grossi di dati in tavule MergeTree.
L'unioni di a tavola sò limitati da a RAM di u servitore, ma almenu ci sò! Per esempiu, Druid è Pinot ùn anu micca tali cunnessione in tuttu, postu chì sò difficiuli di implementà direttamente in sistemi distribuiti chì ùn sustene micca u muvimentu di grande quantità di dati trà i nodi.
scuperti
In l'anni à vene, pensamu di fà un usu estensivu di ClickHouse in Qwintry, postu chì questu DBMS furnisce un eccellente equilibriu di prestazione, bassa overhead, scalabilità è simplicità. Sò abbastanza sicuru chì si sparghjerà rapidamente una volta chì a cumunità ClickHouse vene cun più modi per aduprà in installazioni chjuche è mediu.
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com