je open source systém správy stĺpcových databáz pre online analytické spracovanie dotazov (OLAP) vytvorený spoločnosťou Yandex. Používajú ho Yandex, CloudFlare, VK.com, Badoo a ďalšie služby po celom svete na ukladanie skutočne veľkého množstva dát (vkladanie tisícov riadkov za sekundu alebo petabajtov dát uložených na disku).
V normálnej „reťazcovej“ DBMS, ktorej príkladmi sú MySQL, Postgres, MS SQL Server, sa údaje ukladajú v tomto poradí:
V tomto prípade sú hodnoty súvisiace s jedným riadkom fyzicky uložené vedľa seba. V stĺpcovom DBMS sú hodnoty z rôznych stĺpcov uložené oddelene a údaje jedného stĺpca sú uložené spoločne:
Príklady stĺpcových DBMS 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+.
Spoločnosť je doručovateľom pošty Clickhouse som začal používať na vytváranie prehľadov v roku 2018 a veľmi ma zaujala jeho jednoduchosť, škálovateľnosť, podpora SQL a rýchlosť. Rýchlosť tohto DBMS hraničila s mágiou.
jednoduchosť
Clickhouse sa inštaluje na Ubuntu jediným príkazom. Ak poznáte SQL, môžete okamžite začať používať Clickhouse pre svoje potreby. To však neznamená, že v MySQL môžete „ukázať vytvoriť tabuľku“ a v Clickhouse skopírovať a vložiť SQL.
V porovnaní s MySQL existujú dôležité rozdiely v typoch údajov v definíciách schém tabuľky v tomto DBMS, takže stále potrebujete nejaký čas na zmenu definícií schémy tabuliek a na naučenie sa nástrojov tabuliek, aby ste sa dostali do pohodlia.
Clickhouse funguje skvele bez akéhokoľvek dodatočného softvéru, ale ak chcete používať replikáciu, budete si musieť nainštalovať ZooKeeper. Analýza výkonu dotazov ukazuje vynikajúce výsledky - systémové tabuľky obsahujú všetky informácie a všetky údaje je možné získať pomocou starého a nudného SQL.
produktivita
- Porovnania Clickhouse verzus Vertica a MySQL na konfiguračnom serveri: dve zásuvky Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 na 8 6TB SATA HDD, ext4.
- porovnanie Clickhouse s cloudovým úložiskom Amazon RedShift.
- Úryvky z blogu :
Databáza ClickHouse má veľmi jednoduchý dizajn – všetky uzly v klastri majú rovnakú funkcionalitu a na koordináciu používajú iba ZooKeeper. Postavili sme malý klaster niekoľkých uzlov a vykonali testovanie, počas ktorého sme zistili, že systém má celkom pôsobivý výkon, ktorý zodpovedá nárokovaným výhodám v analytických benchmarkoch DBMS. Rozhodli sme sa bližšie pozrieť na koncept ClickHouse. Prvou prekážkou výskumu bol nedostatok nástrojov a malá komunita ClickHouse, takže sme sa ponorili do návrhu tohto DBMS, aby sme pochopili, ako funguje.
ClickHouse nepodporuje príjem dát priamo z Kafky, keďže ide len o databázu, preto sme v Go napísali vlastnú službu adaptéra. Čítal Cap'n Proto zakódované správy od Kafku, konvertoval ich do TSV a vložil do ClickHouse v dávkach cez HTTP rozhranie. Neskôr sme túto službu prepísali tak, aby používala knižnicu Go v spojení s naším vlastným rozhraním ClickHouse na zlepšenie výkonu. Pri vyhodnocovaní výkonu prijímania paketov sme zistili dôležitú vec – ukázalo sa, že pre ClickHouse tento výkon silne závisí od veľkosti paketu, teda od počtu súčasne vložených riadkov. Aby sme pochopili, prečo sa to deje, študovali sme, ako ClickHouse ukladá údaje.
Hlavným motorom, alebo skôr rodinou tabuľkových motorov, ktoré ClickHouse používa na ukladanie údajov, je MergeTree. Tento engine je koncepčne podobný algoritmu LSM používanému v Google BigTable alebo Apache Cassandra, ale vyhýba sa vytváraniu medzipamäťovej tabuľky a zapisuje dáta priamo na disk. To mu dáva vynikajúcu priepustnosť zápisu, pretože každý vložený paket je triedený iba podľa primárneho kľúča „primárneho kľúča“, komprimovaný a zapísaný na disk, aby vytvoril segment.
Absencia pamäťovej tabuľky alebo akéhokoľvek konceptu „čerstvosti“ údajov tiež znamená, že ich možno iba pridávať, systém nepodporuje zmenu ani vymazanie. V súčasnosti je jediným spôsobom, ako odstrániť údaje, odstrániť ich podľa kalendárneho mesiaca, pretože segmenty nikdy neprekročia hranicu mesiaca. Tím ClickHouse aktívne pracuje na tom, aby bola táto funkcia prispôsobiteľná. Na druhej strane to robí zápis a zlučovanie segmentov bez sporov, takže dostávajte škály priepustnosti lineárne s počtom paralelných vložiek, kým sa nenasýtia I/O alebo jadrá.
Táto okolnosť však zároveň znamená, že systém nie je vhodný pre malé pakety, preto sa na ukladanie do vyrovnávacej pamäte používajú služby Kafka a vkladače. Okrem toho ClickHouse na pozadí pokračuje v nepretržitom zlučovaní segmentov, takže veľa malých informácií bude kombinovaných a zaznamenaných viackrát, čím sa zvýši intenzita záznamu. Príliš veľa nesúvisiacich častí však spôsobí agresívne škrtenie vložiek, pokiaľ bude spojenie pokračovať. Zistili sme, že najlepším kompromisom medzi prijímaním údajov v reálnom čase a výkonom prijímania je prijať do tabuľky obmedzený počet vložení za sekundu.
Kľúčom k výkonu čítania tabuľky je indexovanie a umiestnenie údajov na disku. Bez ohľadu na to, aké rýchle je spracovanie, keď engine potrebuje skenovať terabajty dát z disku a použiť len zlomok z nich, bude to chvíľu trvať. ClickHouse je úložisko stĺpcov, takže každý segment obsahuje súbor pre každý stĺpec (stĺpec) so zoradenými hodnotami pre každý riadok. Celé stĺpce, ktoré nie sú prítomné v dotaze, je teda možné najskôr preskočiť a následne spracovať viacero buniek paralelne s vektorizovaným vykonávaním. Aby sa predišlo úplnému skenovaniu, každý segment má malý indexový súbor.
Vzhľadom na to, že všetky stĺpce sú zoradené podľa "primárneho kľúča", indexový súbor obsahuje iba označenia (zachytené riadky) každého N-tého riadku, aby bolo možné ich uchovávať v pamäti aj pre veľmi veľké tabuľky. Môžete napríklad nastaviť predvolené nastavenia na „označiť každý 8192. riadok“ a potom na „slabé“ indexovanie tabuľky s 1 biliónom. riadky, ktoré sa ľahko zmestia do pamäte, by zabrali iba 122 070 znakov.
Vývoj systému
Vývoj a zlepšovanie Clickhouse je možné sledovať a uistite sa, že proces „dospievania“ prebieha pôsobivým tempom.
Popularita
Zdá sa, že popularita Clickhouse rastie exponenciálne, najmä v rusky hovoriacej komunite. Minuloročná konferencia High load 2018 (Moskva, 8. – 9. novembra 2018) ukázala, že príšery ako vk.com a Badoo používajú Clickhouse, ktorý vkladá dáta (napríklad logy) z desiatok tisíc serverov súčasne. V 40 minútovom videu . Čoskoro zverejníme prepis na Habr pre pohodlie práce s materiálom.
aplikácie
Po nejakom čase strávenom výskumom si myslím, že existujú oblasti, v ktorých môže byť ClickHouse užitočný alebo schopný úplne nahradiť iné tradičnejšie a populárnejšie riešenia, ako sú MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot a Druid. Nasledujú podrobnosti o používaní ClickHouse na inováciu alebo úplné nahradenie vyššie uvedeného DBMS.
Rozšírenie MySQL a PostgreSQL
Nedávno sme čiastočne nahradili MySQL za ClickHouse pre platformu newsletterov . Problém bol v tom, že MySQL kvôli nedomyslenému dizajnu zaprotokolovalo každý odoslaný e-mail a každý odkaz v tomto e-maile pomocou hash base64, čím sa vytvorila obrovská tabuľka MySQL (email_stats). Po odoslaní iba 10 miliónov e-mailov predplatiteľom služby táto tabuľka zaberala 150 GB súborového priestoru a MySQL začalo „blbnúť“ na jednoduché dotazy. Na vyriešenie problému s priestorom v súbore sme úspešne použili kompresiu tabuľky InnoDB, ktorá ju znížila o faktor 4. Stále však nemá zmysel ukladať viac ako 20-30 miliónov e-mailov v MySQL len kvôli histórii čítania, pretože každý jednoduchý dotaz, ktorý z nejakého dôvodu musí vykonať úplné skenovanie, má za následok swap a ťažké I/O réžiu, na čo sme pravidelne dostávali upozornenia Zabbixu.
Clickhouse používa dva kompresné algoritmy, ktoré redukujú množstvo dát približne o , no v tomto konkrétnom prípade boli dáta obzvlášť „stlačiteľné“.
Náhrada ELK
Na základe mojich vlastných skúseností si zásobník ELK (ElasticSearch, Logstash a Kibana, v tomto konkrétnom prípade ElasticSearch) vyžaduje oveľa viac zdrojov na spustenie, ako je potrebné na ukladanie protokolov. ElasticSearch je skvelý nástroj, ak chcete dobré fulltextové vyhľadávanie v protokoloch (čo si myslím, že naozaj nepotrebujete), no zaujímalo by ma, prečo sa stal de facto štandardným protokolom. Jeho výkon príjmu v kombinácii s Logstash nám spôsobil problémy aj pri pomerne nízkej záťaži a vyžadoval pridávanie stále väčšej pamäte RAM a miesta na disku. Ako databáza je Clickhouse lepší ako ElasticSearch z nasledujúcich dôvodov:
- podpora dialektu SQL;
- Najlepší stupeň kompresie uložených údajov;
- Podpora pre vyhľadávanie Regex namiesto fulltextového vyhľadávania;
- Vylepšené plánovanie dopytov a lepší celkový výkon.
V súčasnosti je najväčším problémom, ktorý vzniká pri porovnávaní ClickHouse s ELK nedostatok riešení pre nahrávanie logov, ako aj chýbajúca dokumentácia a návody na túto tému. Zároveň si každý používateľ môže nastaviť ELK pomocou manuálu Digital Ocean, ktorý je veľmi dôležitý pre rýchlu implementáciu takýchto technológií. Existuje tu databázový nástroj, ale zatiaľ neexistuje žiadny Filebeat pre ClickHouse. Áno, existuje a systém na prácu s logami , existuje nástroj na zadanie údajov súboru denníka do ClickHouse, ale to všetko si vyžaduje viac času. ClickHouse však stále vedie svojou jednoduchosťou, takže si ho jednoducho nainštalujú aj začiatočníci a začnú plne funkčné používanie už za 10 minút.
Preferoval som minimalistické riešenia a pokúsil som sa použiť FluentBit, nástroj na nahrávanie protokolov s veľmi nízkou pamäťou, s ClickHouse, pričom som sa snažil vyhnúť používaniu Kafka. Treba však riešiť menšie nekompatibility, ako napr skôr, než to bude možné urobiť bez proxy vrstvy, ktorá konvertuje údaje z FluentBit do ClickHouse.
Ako alternatívu k Kibana môžete použiť ClickHouse ako backend . Pokiaľ som pochopil, môže to spôsobiť problémy s výkonom pri vykresľovaní veľkého počtu údajových bodov, najmä pri starších verziách Grafany. V Qwintry sme to ešte neskúšali, ale z času na čas sa na kanáli podpory ClickHouse v Telegrame objavia sťažnosti.
Nahradenie Google Big Query a Amazon RedShift (riešenie pre veľké spoločnosti)
Ideálnym prípadom použitia pre BigQuery je načítanie 1 TB údajov JSON a spúšťanie analytických dopytov. Big Query je skvelý produkt, ktorého škálovateľnosť je ťažké preceňovať. Ide o oveľa komplexnejší softvér ako ClickHouse bežiaci na internom klastri, no z pohľadu klienta má s ClickHouse veľa spoločného. BigQuery sa môže rýchlo „predražiť“, keď začnete platiť za každý SELECT, takže ide o skutočné riešenie SaaS so všetkými jeho kladmi a zápormi.
ClickHouse je najlepšou voľbou, keď spúšťate veľa výpočtovo drahých dopytov. Čím viac SELECT dotazov spustíte každý deň, tým väčší zmysel má nahradiť Big Query ClickHouse, pretože takáto výmena vám ušetrí tisíce dolárov, pokiaľ ide o množstvo terabajtov spracovávaných dát. Neplatí to pre uložené dáta, ktorých spracovanie v Big Query je pomerne lacné.
V článku Alexandra Zaitseva, spoluzakladateľa Altinity popisuje výhody takejto migrácie DBMS.
Časová mierka Výmena DB
TimescaleDB je rozšírenie PostgreSQL, ktoré optimalizuje prácu s časovými radmi v bežnej databáze (, ).
ClickHouse síce nie je vážnym konkurentom v oblasti časových radov, ale pokiaľ ide o stĺpcovú štruktúru a vykonávanie vektorových dotazov, je vo väčšine prípadov spracovania analytických dotazov oveľa rýchlejší ako TimescaleDB. Výkon prijímania paketových dát ClickHouse je zároveň asi 3-krát vyšší, navyše využíva 20-krát menej miesta na disku, čo je naozaj dôležité pre spracovanie veľkých objemov historických dát: .
Na rozdiel od ClickHouse je jediným spôsobom, ako ušetriť miesto na disku v TimescaleDB, použitie ZFS alebo podobných súborových systémov.
Nadchádzajúce aktualizácie ClickHouse pravdepodobne zavedú delta kompresiu, vďaka čomu bude ešte vhodnejší na spracovanie a ukladanie údajov časových radov. TimescaleDB môže byť lepšou voľbou ako holý ClickHouse v nasledujúcich prípadoch:
- malé inštalácie s veľmi malou pamäťou RAM (<3 GB);
- veľký počet malých INSERT, ktoré nechcete ukladať do veľkých fragmentov;
- lepšia konzistencia, jednotnosť a požiadavky na ACID;
- podpora PostGIS;
- zlúčiť s existujúcimi tabuľkami PostgreSQL, pretože Timescale DB je v podstate PostgreSQL.
Konkurencia so systémami Hadoop a MapReduce
Hadoop a ďalšie produkty MapReduce môžu vykonávať množstvo zložitých výpočtov, ale majú tendenciu bežať s obrovskou latenciou. ClickHouse rieši tento problém spracovaním terabajtov údajov a takmer okamžitým výsledkom. ClickHouse je teda oveľa efektívnejší na vykonávanie rýchleho, interaktívneho analytického výskumu, ktorý by mal byť zaujímavý pre vedcov údajov.
Súťaž s Pinotom a Druidom
Najbližšími konkurentmi ClickHouse sú stĺpcové, lineárne škálovateľné open source produkty Pinot a Druid. Výborná práca porovnávajúca tieto systémy je uverejnená v článku 1. februára 2018
Tento článok je potrebné aktualizovať – píše sa v ňom, že ClickHouse nepodporuje operácie UPDATE a DELETE, čo vo vzťahu k najnovším verziám nie je úplne pravda.
Nemáme veľa skúseností s týmito DBMS, ale nepáči sa mi zložitosť základnej infraštruktúry, ktorá je potrebná na spustenie Druid a Pinot - je to celá kopa "pohyblivých častí" obklopených Java zo všetkých strán.
Druid a Pinot sú projekty inkubátorov Apache, ktorým sa Apache podrobne venuje na svojich projektových stránkach GitHub. Pinot sa objavil v inkubátore v októbri 2018 a Druid sa narodil o 8 mesiacov skôr - vo februári.
Nedostatok informácií o tom, ako AFS funguje, vo mne vyvoláva niektoré a možno hlúpe otázky. Zaujímalo by ma, či si autori Pinotu všimli, že nadácia Apache je viac naklonená Druidovi a vyvolal takýto postoj voči konkurentovi pocit závisti? Spomalí sa vývoj Druida a zrýchli vývoj Pinotu, ak sa sponzori podporujúci prvého zrazu začnú zaujímať o druhého?
Nevýhody ClickHouse
Nezrelosť: Je zrejmé, že je to stále nudná technológia, ale v každom prípade sa nič také nevidí v iných stĺpcových DBMS.
Malé vložky nefungujú dobre pri vysokej rýchlosti: vložky sa musia rozdeliť na veľké kusy, pretože výkon malých vložiek klesá úmerne s počtom stĺpcov v každom riadku. Takto ClickHouse ukladá dáta na disk – každý stĺpec znamená 1 súbor alebo viac, takže na vloženie 1 riadku obsahujúceho 100 stĺpcov je potrebné otvoriť a zapísať aspoň 100 súborov. To je dôvod, prečo vkladanie do vyrovnávacej pamäte vyžaduje sprostredkovateľa (pokiaľ samotný klient neposkytuje vyrovnávaciu pamäť) - zvyčajne Kafka alebo nejaký druh systému radenia. Na neskoršie kopírovanie veľkých častí údajov do tabuliek MergeTree môžete použiť aj nástroj vyrovnávacej pamäte.
Spojenia tabuliek sú obmedzené RAM servera, ale aspoň sú tam! Napríklad Druid a Pinot takéto spojenia vôbec nemajú, pretože je ťažké ich implementovať priamo do distribuovaných systémov, ktoré nepodporujú presúvanie veľkých kusov dát medzi uzlami.
Závery
V nadchádzajúcich rokoch plánujeme rozsiahle využitie ClickHouse v Qwintry, pretože tento DBMS poskytuje vynikajúcu rovnováhu medzi výkonom, nízkou réžiou, škálovateľnosťou a jednoduchosťou. Som si celkom istý, že sa to rýchlo rozšíri, keď komunita ClickHouse príde s ďalšími spôsobmi, ako ho použiť v malých a stredných inštaláciách.
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com