Clickhouse'i kasutamine ELK, Big Query ja TimescaleDB asendajana

Clickhouse — see on avatud lähtekoodiga veergudepõhine andmebaaside haldussüsteem (OLAP) Internetis analüütiliste päringute töötlemiseks, mille lõi Yandex. Seda kasutavad Yandex, CloudFlare, VK.com, Badoo ja paljud teised teenused kõikjal maailmas tõeliselt suurte andmehulkade salvestamiseks (tuhandete ridade sisestamine sekundis või petabaidide kaupa andmete salvestamine kettale).

Tavalisel, «reapõhisel» andmebaasi haldussüsteemil, milleks on näiteks MySQL, Postgres, MS SQL Server, säilitatakse andmed sellises järjestuses:

Samas on väärtused, mis kuuluvad ühte ritta, füüsiliselt lähedal. Veergudepõhistes andmebaasides salvestatakse erinevate veergude väärtused eraldi, ja ühe veeru andmed on koos:

Veergudepõhiste andmebaaside näideteks on Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.

Ettevõte – meilifoward Qwintry hakks kasutama Clickhouse'i 2018. aastal aruannete koostamiseks ja oli väga muljet avaldanud selle lihtsuse, skaleeritavuse, SQL toe ja kiirusest. Selle andmebaasi töö kiirus oli peaaegu nagu nõidus.

Lihtsus

Clickhouse on Ubuntu installitakse üheainsa käsuga. Kui oskate SQL-i, saate kohe hakata Clickhouse'i kasutama. See ei tähenda aga, et saaksite MySQL-is "show create table" teha ja SQL-i lihtsalt kopeerida ja kleepida Clickhouse'i.

Võrreldes MySQL-iga on selle andmebaasi puhul tabeliskeemide määratlemisel olulisi andmetüüpide erinevusi. Seetõttu on mugavaks töötamiseks vajalik veidi aega tabeliskeemide määratlemiste muutmiseks ja tabelimootorite tundmaõppimiseks.

Clickhouse töötab suurepäraselt ilma igasuguse lisatarkvarata, kuid kui soovite kasutada replikatsiooni, peate installima ZooKeeperi. Päringute jõudluse analüüs näitab suurepäraseid tulemusi — süsteemitabelid sisaldavad kogu teavet ning kõik andmed on kättesaadavad vanade ja igavate SQL-i abil.

Tootlikkus

• Benchmark Clickhouse'i võrreldes Vertica ja MySQL-ga konfigureeritud serveris: kaks Intel® Xeon® CPU E5-2650 v2 @ 2,60 GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD-l, ext4.
• Benchmark Clickhouse'i võrreldes Amazon RedShifti pilveandmehoidla.
• Blogi väljavõtted Cloudflare'i artikkel Clickhouse'i jõudlusest:

ClickHouse'i andmebaas omab väga lihtsat disaini — kõik klastris olevad sõlmed täidavad samu funktsioone ja koordineerimise jaoks kasutatakse ainult ZooKeeperit. Oleme ehitanud väikese klastrite gruppi ja viinud läbi teste, mille käigus leidsime, et süsteemil on üllatavalt hea jõudlus, mis vastab analüütiliste andmebaaside benchmark’ides lubatud eelistele. Otsustasime põhjalikumalt uurida ClickHouse'i aluseks olevat kontseptsiooni. Esimese teadusuuringute takistusena oli tööriistade puudus ja ClickHouse'i kogukonna vähenenud suurus, mistõttu süvenesime selle andmebaasi disaini, et mõista, kuidas see toimib.

ClickHouse ei toeta andmete vastuvõttu otse Kafka'lt, kuna see on lihtsalt andmebaas. Seetõttu kirjutasime me oma adaptermooduli Go keeles. See luges Kafka'st kodeeritud Cap’n Proto sõnumeid, konverteeris need TSV formaati ja sisestas ClickHouse'i pakettide kaupa läbi HTTP-liidese. Hiljem kirjutasime selle teenuse ümber, et kasutada Go raamatukogu koos ClickHouse'i oma liidese kasutamisega, et parandada jõudlust. Paketivastuvõtu jõudluse hindamisel avastasime olulise asja – selgus, et ClickHouse'i jõudlus sõltub suurel määral paketist, st samaaegselt sisestatud ridade arvust. Selle mõistmiseks uurisime, kuidas ClickHouse andmeid salvestab.

ClickHouse'i andmete salvestamiseks kasutatav peamine, pigem mootori perekond on MergeTree. See mootor on kontseptuaalselt sarnane LSM-algoritmiga, mis on rakendatud Google BigTable'is või Apache Cassandra's, kuid väldib vahepealse mälutabeli loomist ning kirjutab andmed otse kettale. See annab sellele suurepärase kirjutamise läbilaskevõime, kuna iga sisestatud partii sorteeritakse ainult "esimese võtme" (primary key) järgi, tihendatakse ja kirjutatakse kettale, et luua segment.

Mälu tabeli või andmete "värskuse" puudumine tähendab, et andmeid saab ainult lisada, nende muutmist või kustutamist süsteem ei toeta. Praegu on ainus viis andmete kustutamine kuude kaupa, kuna segmentide vahel ei teki kunagi kuupiire. ClickHouse meeskond töötab aktiivselt selle funktsiooni kohandatavamaks muutmise nimel. Teisest küljest muudab see konfliktivabaks segmentide kirjutamise ja ühendamise, seega vastuvõtu läbilaskevõime skaleerub joonearselt paralleelsete insertide arvuga, kuni ei tekita I/O või tuumade küllastumist.
Kuid see olukord tähendab ka, et süsteem ei sobi väikeste pakettide jaoks, mistõttu külastatakse puhverdamiseks Kafka teenuseid ja insertereid. Edasi, ClickHouse jätkab taustal pidevat segmentide sulandamist, nii et paljud väikesed andmepalad ühendatakse ja salvestatakse rohkem kordi, suurendades sellega kirjutamise intensiivsust. Sellega seoses võib liiga palju seotud osi põhjustada sisendite agressiivset piiramist, kuni sulandamine kestab. Oleme leidnud, et parim kompromiss reaalajas andmete vastuvõtu ja vastuvõtu efektiivsuse vahel on piiratud arvu sisendite vastuvõtt sekundis.

Lugemise tabelite jõudluse võtmekomponent on indekseerimine ja andmete paigutus kõvakettale. Ükskõik kui kiire on töötlemine, kui mootor peab skaneerima terabayte andmeid kettalt ja kasutama neist vaid osa, võtab see aega. ClickHouse on veergude andmete hoidla, seega iga segment sisaldab faili iga veeru jaoks, kus on iga rea jaoks järjestatud väärtused. Seega saavad kogu veerud, mida päringus ei ole, esialgu vahele jäetud ning seejärel võivad mitmed lahtrid olla töödeldud paralleelselt vektoriseeritud täitmisega. Täieliku skaneerimise vältimiseks on igal segmendil väike indeksifail.

Arvestades, et kõik veerud on järjekorras „peamise võtme” järgi, sisaldab indeksifail ainult märke (tabatud read) igast N-ndast reast, et neid oleks võimalik hoida mälus isegi väga suurte tabelite jaoks. Näiteks saab seada vaikeseaded „märgistada iga 8192. rea”, siis „karm” tabeli indekseerimine, mis sisaldab 1 triljonit rida, mis mahub kergesti mällu, võtab vaid 122 070 tähemärki.

Süsteemi areng

Clickhouse'i arengut ja täiustamist saab jälgida Githubi repo ja veenduda, et 'küpsemise' protsess toimub muljetavaldava kiirusel.

Populaarsus

Tundub, et Clickhouse'i populaarsus kasvab eksponentsiaalselt, eriti venekeelses kogukonnas. Eelmise aasta High Load 2018 konverents näitas, et sellised hiiglased nagu vk.com ja Badoo kasutavad Clickhouse'i, mille abil sisestavad nad andmeid (nt logisid) kümnetelt tuhandelt serverilt üheaegselt. 40-minutilises videos Yuri Nasretdinov VKontakte meeskonnast räägib sellest, kuidas see toimub. Peagi avaldame mugavuse huvides stenogrammi Habr's.

Rakendusvaldkonnad

Pärast teatud aja veetmist uurimisel usun, et on valdkondi, kus ClickHouse võib olla kasulik või suudab täielikult asendada teisi, traditsioonilisemaid ja populaarsemaid lahendusi nagu MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ja Druid. Järgnevalt on toodud üksikasjad ClickHouse'i kasutamise kohta ülaltoodud andmebaaside moderniseerimiseks või täielikuks asendamiseks.

MySQL ja PostgreSQL võimaluste laiendamine

Hiljuti asendasime osaliselt MySQL-i ClickHouse'iga uudiskirjade platvormil. Mautic uudiskiri. Probleem oli selles, et MySQL registreeris igasuguse saatmise ja iga kirjas oleva lingi base64-koodiga, luues hiiglasliku MySQL tabeli (email_stats). Pärast 10 miljoni kirja saatmist teenuse tellijatele oli see tabel 150 GB suurune, mille tõttu MySQL hakkas lihtsate päringute puhul "tükki tundma". Probleemi lahendamiseks kasutame tõhusalt InnoDB tabeli tihendamist, mis vähendas selle mahtu neljakordselt. Siiski pole mõtet hoida MySQL-is enam kui 20-30 miljonit e-kirja vaid ajaloo lugemise nimel, kuna iga lihtne päring, mis mingil põhjusel peab teostama täisskaneerimise, põhjustab vahetusmälu ja suurt I/O koormust, millest saime regulaarselt Zabbix'i hoiatusi.

Clickhouse kasutab kahte tihendamisalgoritmi, mis vähendavad andmete mahtu umbes 3-4 korda, kuid antud konkreetses juhul olid andmed eriti "tihendatavad".

ELK asendamine

Oma kogemusele tuginedes nõuab ELK (ElasticSearch, Logstash ja Kibana, antud juhul ElasticSearch) logide käitamiseks palju rohkem ressursse kui logide salvestamiseks vajalik. ElasticSearch on suurepärane mootor, kui vajate logides head täisteksti otsingu võimalust (kuigi ma ei arva, et see teile tõeliselt vajalik oleks), kuid mind huvitab, miks on sellest de-facto saanud standardne ajakirjanduse mootor. Selle vastuvõtutootlikkus koos Logstashiga on meile tekitanud probleeme isegi suhteliselt väikeste koormuste korral ja on nõudnud järjest rohkem RAM-i ja kettaruumi. Andmebaasina on Clickhouse ElasticSearchist parem järgmistel põhjustel:

• SQL dialekti tugi;
• Parema andmete kokkusurumise aste;
• Regex regulaaravaldiste otsingu tugi täisteksti otsingu asemel;
• Parandatud päringute kavandamine ja kõrgem üldine tootlikkus.

Praegu on ClickHouse'i ja ELK võrreldes suurim probleem logide väljastamise lahenduste puudumine ning samuti dokumentatsiooni ja õppematerjalide nappus selle teema kohta. Samas saab iga kasutaja ELKi seadistada Digital Ocean'i juhendi abil, mis on väga oluline selliste tehnoloogiate kiireks kasutuselevõtuks. Andmebaasi mootor on olemas, kuid Filebeat'i tugi ClickHouse'ile puudub. Jah, seal on olemas fluentd ja logide töötlemise süsteem loghouse, on olemas tööriist clicktail logifailide andmete sisestamiseks ClickHouse'i, kuid see kõik nõuab rohkem aega. Siiski on ClickHouse endiselt liider oma lihtsuse tõttu, mistõttu isegi algajad saavad selle paigaldada ja hakata täisfunktsionaalset kasutama vaid 10 minuti pärast.

Minimaalseid lahendusi eelistades proovisin kasutada FluentBit'i, väga väikese mälu kasutusega logide väljastamise tööriista, koos ClickHouse'iga, vältides samas Kafka kasutamist. Kuid mõned väiksed ühilduvusprobleemid, nagu kuupäeva formaadi probleemid, enne kui seda saab teha ilma proksivaateta, mis muudab andmed FluentBitist ClickHouse'i.

Alternatiivina Kibana'le saab ClickHouse'i kasutada tagaplaanina Grafana. Nagu aru sain, võivad sellega kaasneda jõudlusprobleemid suurte andmepunktide renderdamisel, eriti vanemate Grafana versioonidega. Qwintry's me pole seda veel proovinud, kuid kaebusi selle üle on aeg-ajalt tulnud ClickHouse'i tugikanalist Telegramis.

Google Big Query ja Amazon RedShift'i asendamine (lahendus suurtele ettevõtetele)

BigQuery ideaalne kasutusviis on laadida 1 TB JSON andmeid ja teha nende põhjal analüütilisi päringuid. BigQuery on suurepärane toode, mille skaleeritavust on raske üle hinnata. See on palju keerulisem tarkvara kui ClickHouse, mis töötab sisevõrgus, kuid kliendi seisukohalt on tal ClickHouse'iga palju ühist. BigQuery võib kiiresti „kalliks” minna, kui hakkate maksma iga SELECT'i eest, seega on see tõeline SaaS-lahendus koos kõigi oma plusside ja miinustega.

ClickHouse on parim valik, kui teete palju arvutuslikult kulukaid päringuid. Mida rohkem SELECT päringuid te iga päev teete, seda rohkem tasub Big Query asendada ClickHouse'iga, sest see vahetus aitab säästa tuhandeid dollareid, kui tegemist on suurte terabaitide töötlemisega. See ei kehti salvestatud andmete puhul, mille töötlemine Big Query's on üsna odav.

Artiklis, mille on koostanud Altinity kaasasutaja Aleksandr Zaitsev „Üleminek ClickHouse'ile“ käsitletakse sellise andmebaasi migreerimise eeliseid.

TimescaleDB asendamine

TimescaleDB on PostgreSQL laiendus, mis optimeerib ajaseeriate töötlemist tavalises andmebaasis.https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

Kuigi ClickHouse ei ole tõsine konkurent ajareadade nišis, on selle veergude struktuur ja vektorküsimuste täitmine enamikus analüüsipäringute töötlemisel TimescaleDB-st märgatavalt kiirem. Samuti on ClickHouse-i pakettide andmete vastuvõtu jõudlus umbes 3 korda parem, ning ta kasutab 20 korda vähem diskiruumi, mis on tõeliselt oluline suurte ajalooliste andmemahtude töötlemisel: 
https://www.altinity.com/blog/ClickHouse-for-time-series.

Erinevalt ClickHouse'ist on TimescaleDB-s ainus viis veidi diskiruumi kokku hoida ZFS-i või sarnaste failisüsteemide kasutamine.

Eelseisvad ClickHouse uuendused toovad tõenäoliselt sisse delta-kompressiooni, mis muudab selle veelgi sobivamaks ajareadade andmete töötlemiseks ja salvestamiseks. TimescaleDB võib olla parem valik kui 'puhtal' ClickHouse'il järgmistes olukordades:

• väiksed installatsioonid, kus on väga vähe RAM-i (<3 GB);
• suure hulga väikeste INSERT-käskude puhul, mida te ei soovi suurtesse fragmentidesse puhverdada;
• parem järjepidevus, ühtsus ja ACID-nõuded;
• PostGIS-i tugi;
• ühendamine olemasolevate PostgreSQL tabelitega, kuna Timescale DB on põhimõtteliselt PostgreSQL.

Konkurents Hadoopi ja MapReduce süsteemidega

Hadoop ja muud MapReduce tooted võivad teostada mitmeid keerulisi arvutusi, kuid need töötavad tavaliselt väga suurtel viivitustega. ClickHouse lahendab selle probleemi, töötledes terabaiti andmeid ja andes tulemusi peaaegu kohe. Seega on ClickHouse palju tõhusam kiiret, interaktiivset analüütilist uurimistööd tehes, mis peaks andmetöötluse spetsialiste kindlasti huvitama.

Konkurents Pinot ja Druidiga

ClickHouse'i lähimad konkurendid on veergude põhised lineaarse skaleeritavuse avatud lähtekoodiga tooted Pinot ja Druid. Nende süsteemide võrdlev hea töö on avaldatud artiklis Roman Leventov 1. veebruar 2018

See artikkel vajab värskendamist – see väidab, et ClickHouse ei toeta UPDATE ja DELETE toiminguid, mis ei ole viimaste versioonide osas täielikult tõsi.

Meil ei ole piisavalt kogemusi nende andmebaaside haldamisel, kuid mulle ei meeldi üldse Druid'i ja Pinot'i käitamiseks vajaliku infrastruktuuri keerukus — seal on palju „liikuvaid osi”, mis on Java ümber ehitatud.

Druid ja Pinot on Apache'i inkubaatoriprojektid, mille arengut kajastatakse põhjalikult Apache'i GitHub'i projektilehtedel. Pinot ilmus inkubaatorisse 2018. aasta oktoobris, samas kui Druid sündis kaheksa kuud varem — veebruaris.

Teave AFS-i toimimise kohta on vähene ning see tekitab minus mõned, võib-olla rumalad küsimused. Huvi pakub, kas Pinot'i autorid on märganud, et Apache Foundation on Druid'ile soodsamalt meelestatud, ning kas see on tekitanud konkurendi suhtes kadedust? Kas Druid'i areng pidurdub ja Pinot'i areng kiireneb, kui esimese toetajad äkki teisega enamasti huvi tunnevad?

ClickHouse'i puudused

Vähenenud võrreldes: ilmselgelt on see endiselt arenev tehnoloogia, kuid sarnaseid probleeme ei ole teiste veergude andmebaasides täheldatud.

Väikesed sisendiüksused ei tööta kõrge kiirusel hästi: sisendid peaksid olema jagatud suurte tükkideks, kuna väikeste sisendiüksuste jõudlus väheneb proportsionaalselt iga rea veergude arvule. Just nii salvestatakse andmeid ClickHouse'is kettale — iga veerg tähendab üht või enamat faili, seega 1 rea sisestamiseks, mis sisaldab 100 veergu, tuleb avada ja kirjutada vähemalt 100 faili. Seetõttu on sisendite puhvherdamiseks vajalik vahendaja (kui klient ise puhvreerimist ei taga) — tavaliselt on selleks Kafka või mõni järjekorrasüsteem. Samuti saab kasutada Buffer tabeli mootorit, et hiljem kopeerida suuri andmefragmente MergeTree tabelitesse.

Tabelite ühendused on piiratud serveri RAM-iga, kuid vähemalt need on olemas! Näiteks Druidil ja Pinotil ei ole üldse selliseid ühendusi, kuna nende rakendamine on keeruline jaotatud süsteemides, mis ei toeta suurte andmekoguste liikumist sõlmede vahel.

Järeldused

Järgmiste aastate jooksul plaanime Qwintrys laialdaselt kasutada ClickHouse'i, kuna see andmebaasihaldussüsteem pakub suurepärast tasakaalu jõudluse, madalate kulude, skaleeritavuse ja lihtsuse vahel. Olen peaaegu kindel, et see hakkab kiiresti laienema, kui ClickHouse'i kogukond välja mõtleb rohkem võimalusi selle kasutamiseks väikestes ja keskmistes installatsioonides.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com