este un sistem open-source de gestionare a bazelor de date în coloană pentru procesarea online a interogărilor analitice (OLAP) creat de Yandex. Este folosit de Yandex, CloudFlare, VK.com, Badoo și alte servicii din întreaga lume pentru a stoca cantități foarte mari de date (inserarea a mii de rânduri pe secundă sau petaocteți de date stocate pe disc).
Într-un SGBD normal, „șir”, exemple dintre care sunt MySQL, Postgres, MS SQL Server, datele sunt stocate în această ordine:
În acest caz, valorile aferente unui rând sunt stocate fizic una lângă alta. În DBMS coloane, valorile din diferite coloane sunt stocate separat, iar datele unei coloane sunt stocate împreună:
Exemple de SGBD-uri coloane sunt Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Compania este un expeditor de corespondență Am început să folosesc Clickhouse în 2018 pentru raportare și am fost foarte impresionat de simplitatea, scalabilitatea, suportul SQL și viteza. Viteza acestui DBMS s-a marginit de magie.
Ușura
Clickhouse se instalează pe Ubuntu cu o singură comandă. Dacă cunoașteți SQL, puteți începe imediat să utilizați Clickhouse pentru nevoile dvs. Cu toate acestea, acest lucru nu înseamnă că puteți „afișa tabelul creat” în MySQL și puteți copia și lipi SQL în Clickhouse.
În comparație cu MySQL, există diferențe importante de tip de date în definițiile schemei de tabel din acest SGBD, așa că mai aveți nevoie de ceva timp pentru a schimba definițiile schemei de tabel și pentru a învăța motoarele de tabel pentru a vă simți confortabil.
Clickhouse funcționează excelent fără niciun software suplimentar, dar dacă doriți să utilizați replicarea, va trebui să instalați ZooKeeper. Analiza performanței interogărilor arată rezultate excelente - tabelele de sistem conțin toate informațiile, iar toate datele pot fi obținute folosind SQL vechi și plictisitor.
productivitate
- Comparații Clickhouse versus Vertica și MySQL pe serverul de configurare: CPU Intel® Xeon® E5-2650 v2 cu două socluri la 2.60 GHz; 128 GiB RAM; md RAID-5 pe 8 HDD SATA de 6TB, ext4.
- comparație dintre Clickhouse și stocarea în cloud Amazon RedShift.
- Extrase de blog :
Baza de date ClickHouse are un design foarte simplu - toate nodurile din cluster au aceeași funcționalitate și folosesc doar ZooKeeper pentru coordonare. Am construit un mic cluster de mai multe noduri și am efectuat teste, în timpul cărora am constatat că sistemul are performanțe destul de impresionante, ceea ce corespunde avantajelor pretinse în benchmark-urile analitice DBMS. Am decis să aruncăm o privire mai atentă asupra conceptului din spatele ClickHouse. Primul obstacol în calea cercetării a fost lipsa instrumentelor și a comunității mici ClickHouse, așa că ne-am adâncit în designul acestui DBMS pentru a înțelege cum funcționează.
ClickHouse nu acceptă primirea de date direct de la Kafka, deoarece este doar o bază de date, așa că am scris propriul nostru serviciu de adaptor în Go. Citea mesajele codificate Cap'n Proto de la Kafka, le-a convertit în TSV și le-a inserat în ClickHouse în loturi prin interfața HTTP. Ulterior, am rescris acest serviciu pentru a folosi biblioteca Go împreună cu propria noastră interfață ClickHouse pentru a îmbunătăți performanța. La evaluarea performanței de primire a pachetelor, am descoperit un lucru important - s-a dovedit că pentru ClickHouse această performanță depinde foarte mult de dimensiunea pachetului, adică de numărul de rânduri introduse în același timp. Pentru a înțelege de ce se întâmplă acest lucru, am studiat modul în care ClickHouse stochează datele.
Motorul principal, sau mai degrabă, o familie de motoare de tabele utilizate de ClickHouse pentru stocarea datelor, este MergeTree. Acest motor este similar conceptual cu algoritmul LSM utilizat în Google BigTable sau Apache Cassandra, dar evită construirea unui tabel de memorie intermediar și scrie datele direct pe disc. Acest lucru îi oferă un debit excelent de scriere, deoarece fiecare pachet inserat este sortat doar după cheia primară „cheie primară”, comprimat și scris pe disc pentru a forma un segment.
Absența unui tabel de memorie sau a oricărui concept de „prospețime” a datelor înseamnă, de asemenea, că acestea pot fi doar adăugate, sistemul nu acceptă modificarea sau ștergerea. Începând de astăzi, singura modalitate de a șterge datele este să le ștergeți în funcție de lună calendaristică, deoarece segmentele nu depășesc niciodată limita unei luni. Echipa ClickHouse lucrează activ pentru a face această caracteristică personalizabilă. Pe de altă parte, face scrierea și îmbinarea segmentelor fără conflicte, astfel încât să primiți scale de debit liniar cu numărul de inserții paralele până când I/O sau nucleele se saturează.
Cu toate acestea, această împrejurare înseamnă și că sistemul nu este potrivit pentru pachete mici, astfel încât serviciile Kafka și dispozitivele de inserție sunt folosite pentru stocare în tampon. Mai mult, ClickHouse din fundal continuă să îmbine în mod continuu segmente, astfel încât multe informații mici vor fi combinate și înregistrate de mai multe ori, crescând astfel intensitatea înregistrării. Cu toate acestea, prea multe părți neînrudite vor provoca o accelerare agresivă a inserțiilor atâta timp cât îmbinarea continuă. Am descoperit că cel mai bun compromis între asimilarea datelor în timp real și performanța de asimilare este acceptarea unui număr limitat de inserări pe secundă în tabel.
Cheia pentru performanța citirii tabelelor este indexarea și locația datelor de pe disc. Indiferent cât de rapidă este procesarea, atunci când motorul trebuie să scaneze terabytes de date de pe disc și să folosească doar o fracțiune din acestea, va dura timp. ClickHouse este un magazin de coloane, astfel încât fiecare segment conține un fișier pentru fiecare coloană (coloană) cu valori sortate pentru fiecare rând. Astfel, coloanele întregi care nu sunt prezente în interogare pot fi mai întâi sărite, iar apoi mai multe celule pot fi procesate în paralel cu execuția vectorizată. Pentru a evita o scanare completă, fiecare segment are un fișier index mic.
Având în vedere că toate coloanele sunt sortate după „cheia primară”, fișierul index conține doar etichetele (rândurile capturate) ale fiecărui N-lea rând, pentru a le putea păstra în memorie chiar și pentru tabele foarte mari. De exemplu, puteți seta setările implicite pentru a „marca fiecare rând al 8192”, apoi indexarea „slabă” a unui tabel cu 1 trilion. liniile care se potrivesc cu ușurință în memorie ar lua doar 122 de caractere.
Dezvoltarea sistemului
Dezvoltarea și îmbunătățirea Clickhouse poate fi urmărită și asigurați-vă că procesul de „creștere” are loc într-un ritm impresionant.
Popularitate
Se pare că popularitatea Clickhouse crește exponențial, mai ales în comunitatea de limbă rusă. Conferința High load 2018 de anul trecut (Moscova, 8-9 noiembrie 2018) a arătat că monștri precum vk.com și Badoo folosesc Clickhouse, care inserează date (de exemplu, jurnalele) de pe zeci de mii de servere simultan. Într-un videoclip de 40 de minute . În curând vom posta transcrierea pe Habr pentru confortul de a lucra cu materialul.
aplicații
După ce am petrecut ceva timp cercetării, cred că există domenii în care ClickHouse poate fi util sau poate înlocui complet alte soluții mai tradiționale și populare, cum ar fi MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot și Druid. Următoarele sunt detalii despre utilizarea ClickHouse pentru a face upgrade sau a înlocui complet SGBD-ul de mai sus.
Extinderea MySQL și PostgreSQL
Cel mai recent, am înlocuit parțial MySQL cu ClickHouse pentru platforma de buletine informative . Problema a fost că MySQL, din cauza designului prost conceput, a înregistrat fiecare e-mail trimis și fiecare link din acel e-mail cu un hash base64, creând un tabel MySQL uriaș (email_stats). După ce a trimis doar 10 milioane de e-mailuri către abonații serviciului, acest tabel a ocupat 150 GB spațiu de fișiere, iar MySQL a început să „prostească” la interogări simple. Pentru a remedia problema spațiului de fișiere, am folosit cu succes compresia tabelului InnoDB, care a redus-o cu un factor de 4. Cu toate acestea, încă nu are sens să stocați mai mult de 20-30 de milioane de e-mailuri în MySQL doar de dragul citirii istoricului, deoarece orice interogare simplă care, dintr-un anumit motiv, trebuie să facă o scanare completă are ca rezultat swap și I/O grele. deasupra capului, despre care primim regulat avertismente Zabbix.
Clickhouse folosește doi algoritmi de compresie care reduc cantitatea de date cu aproximativ , dar în acest caz particular, datele erau în special „compresibile”.
Înlocuire ELK
Pe baza propriei mele experiențe, stiva ELK (ElasticSearch, Logstash și Kibana, în acest caz particular ElasticSearch) necesită mult mai multe resurse pentru a rula decât este necesar pentru a stoca jurnalele. ElasticSearch este un motor grozav dacă doriți o căutare bună în jurnal de text integral (și nu cred că aveți nevoie de el), dar mă întreb de ce a devenit motorul de logare standard de facto. Performanța sa de asimilare, combinată cu Logstash, ne-a creat probleme chiar și la sarcini de lucru destul de ușoare și a necesitat adăugarea din ce în ce mai multă RAM și spațiu pe disc. Ca bază de date, Clickhouse este mai bun decât ElasticSearch din următoarele motive:
- Suport dialect SQL;
- Cel mai bun grad de compresie a datelor stocate;
- Suport pentru căutarea Regex în loc de căutarea text integral;
- Programare îmbunătățită a interogărilor și performanță generală mai bună.
În prezent, cea mai mare problemă care apare la compararea ClickHouse cu ELK este lipsa soluțiilor pentru încărcarea jurnalelor, precum și lipsa documentației și tutorialelor pe această temă. În același timp, fiecare utilizator poate configura ELK folosind manualul Digital Ocean, care este foarte important pentru implementarea rapidă a unor astfel de tehnologii. Există un motor de bază de date aici, dar încă nu există Filebeat pentru ClickHouse. Da este și un sistem de lucru cu jurnalele , există un instrument pentru a introduce datele fișierului jurnal în ClickHouse, dar toate acestea necesită mai mult timp. Cu toate acestea, ClickHouse este în continuare lider datorită simplității sale, astfel încât chiar și începătorii îl pot instala cu ușurință și pot începe utilizarea complet funcțională în doar 10 minute.
Preferind soluții minimaliste, am încercat să folosesc FluentBit, un instrument de încărcare a jurnalelor cu memorie foarte scăzută, cu ClickHouse, încercând în același timp să evit să folosesc Kafka. Cu toate acestea, incompatibilitățile minore trebuie abordate, cum ar fi înainte de a se putea face fără stratul proxy care convertește datele din FluentBit în ClickHouse.
Ca alternativă la Kibana, puteți utiliza ClickHouse ca backend . Din câte am înțeles, acest lucru poate cauza probleme de performanță la redarea unui număr mare de puncte de date, în special cu versiunile mai vechi ale Grafana. În Qwintry, nu am încercat încă acest lucru, dar plângeri în acest sens apar din când în când pe canalul de asistență ClickHouse din Telegram.
Înlocuirea Google Big Query și Amazon RedShift (soluție pentru companii mari)
Cazul de utilizare ideal pentru BigQuery este să încărcați 1 TB de date JSON și să rulați interogări analitice pe el. Big Query este un produs grozav a cărui scalabilitate este greu de supraestimat. Acesta este un software mult mai complex decât ClickHouse care rulează pe un cluster intern, dar din punctul de vedere al clientului, are multe în comun cu ClickHouse. BigQuery poate „crește prețul” rapid odată ce începeți să plătiți pentru fiecare SELECT, deci este o adevărată soluție SaaS, cu toate avantajele și dezavantajele sale.
ClickHouse este cea mai bună alegere atunci când executați o mulțime de interogări costisitoare din punct de vedere computațional. Cu cât rulați mai multe interogări SELECT în fiecare zi, cu atât este mai important să înlocuiți Big Query cu ClickHouse, deoarece o astfel de înlocuire vă va economisi mii de dolari atunci când este vorba de mulți teraocteți de date procesați. Acest lucru nu se aplică datelor stocate, care este destul de ieftin de procesat în Big Query.
Într-un articol al lui Alexander Zaitsev, co-fondatorul Altinity descrie beneficiile unei astfel de migrări DBMS.
Înlocuire TimecaleDB
TimescaleDB este o extensie PostgreSQL care optimizează lucrul cu serii temporale într-o bază de date obișnuită (, ).
Deși ClickHouse nu este un concurent serios în nișa seriilor de timp, dar în ceea ce privește structura coloanelor și execuția interogărilor vectoriale, este mult mai rapid decât TimescaleDB în majoritatea cazurilor de procesare a interogărilor analitice. În același timp, performanța de primire a pachetelor de date ClickHouse este de aproximativ 3 ori mai mare, în plus, utilizează de 20 de ori mai puțin spațiu pe disc, ceea ce este cu adevărat important pentru procesarea unor volume mari de date istorice: .
Spre deosebire de ClickHouse, singura modalitate de a economisi spațiu pe disc în TimescaleDB este să utilizați ZFS sau sisteme de fișiere similare.
Actualizările viitoare ale ClickHouse vor introduce probabil compresia delta, ceea ce o va face și mai potrivită pentru procesarea și stocarea datelor din seria temporală. TimescaleDB poate fi o alegere mai bună decât ClickHouse gol în următoarele cazuri:
- instalatii mici cu foarte putina RAM (<3 GB);
- un număr mare de INSERT-uri mici pe care nu doriți să le salvați în fragmente mari;
- cerințe mai bune de consistență, uniformitate și ACID;
- suport PostGIS;
- fuzionați cu tabelele PostgreSQL existente, deoarece Timescale DB este în esență PostgreSQL.
Concurență cu sistemele Hadoop și MapReduce
Hadoop și alte produse MapReduce pot efectua o mulțime de calcule complexe, dar tind să ruleze la o latență uriașă. ClickHouse rezolvă această problemă prin procesarea terabytes de date și producând rezultate aproape instantaneu. Astfel, ClickHouse este mult mai eficient pentru efectuarea de cercetări analitice rapide, interactive, care ar trebui să fie de interes pentru oamenii de știință de date.
Concurență cu Pinot și Druid
Cei mai apropiați concurenți ai ClickHouse sunt produsele open source, liniar scalabile, Pinot și Druid. O lucrare excelentă care compară aceste sisteme este publicată în articol 1 februarie 2018
Acest articol trebuie actualizat - spune că ClickHouse nu acceptă operațiunile UPDATE și DELETE, ceea ce nu este în întregime adevărat în raport cu cele mai recente versiuni.
Nu avem prea multă experiență cu aceste SGBD-uri, dar nu-mi place complexitatea infrastructurii de bază care este necesară pentru a rula Druid și Pinot - este o grămadă de „părți în mișcare” înconjurate de Java din toate părțile.
Druid și Pinot sunt proiecte de incubatoare Apache, care sunt acoperite în detaliu de Apache pe paginile lor de proiecte GitHub. Pinot a apărut în incubator în octombrie 2018, iar Druid sa născut cu 8 luni mai devreme - în februarie.
Lipsa de informații despre modul în care funcționează AFS îmi ridică câteva întrebări, și poate stupide. Mă întreb dacă autorii lui Pinot au observat că Fundația Apache este mai dispusă față de Druid și o astfel de atitudine față de un concurent a provocat un sentiment de invidie? Va încetini dezvoltarea lui Druid și dezvoltarea lui Pinot se va accelera dacă sponsorii care îl susțin pe primul devin brusc interesați de cel din urmă?
Dezavantajele ClickHouse
Imaturitatea: Evident, aceasta este încă o tehnologie plictisitoare, dar, în orice caz, nimic de genul acesta nu se vede în alte DBMS-uri coloane.
Inserțiile mici nu funcționează bine la viteză mare: inserturile trebuie împărțite în bucăți mari, deoarece performanța inserturilor mici se degradează proporțional cu numărul de coloane din fiecare rând. Acesta este modul în care ClickHouse stochează datele pe disc - fiecare coloană înseamnă 1 fișier sau mai multe, așa că pentru a insera 1 rând care conține 100 de coloane, trebuie să deschideți și să scrieți cel puțin 100 de fișiere. Acesta este motivul pentru care inserarea buffering necesită un intermediar (cu excepția cazului în care clientul însuși oferă buffering) - de obicei Kafka sau un fel de sistem de așteptare. De asemenea, puteți utiliza motorul de tabel Buffer pentru a copia ulterior bucăți mari de date în tabelele MergeTree.
Joinările la mese sunt limitate de RAM-ul serverului, dar cel puțin sunt acolo! De exemplu, Druid și Pinot nu au deloc astfel de conexiuni, deoarece sunt dificil de implementat direct în sistemele distribuite care nu acceptă mutarea unor cantități mari de date între noduri.
Constatări
În următorii ani, intenționăm să folosim pe scară largă ClickHouse în Qwintry, deoarece acest DBMS oferă un echilibru excelent de performanță, costuri generale reduse, scalabilitate și simplitate. Sunt destul de sigur că se va răspândi rapid odată ce comunitatea ClickHouse va veni cu mai multe modalități de a-l folosi în instalații mici și mijlocii.
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com