Clickhouse'i kasutamine ELK, Big Query ja TimescaleDB asendajana.

Clickhouse — see on veergupõhine andmebaaside haldussüsteem, mis on loodud Yandexi poolt ja mõeldud veebipõhiste analüütiliste päringute (OLAP) töötlemiseks avatud lähtekoodiga. Seda kasutavad Yandex, CloudFlare, VK.com, Badoo ja teised teenused üle kogu maailma, et salvestada tõeliselt suuri andmemahtusid (tuhandete ridade sisestamine sekundis või petabaidid andmeid, mis on salvestatud kettale).

Tavaliselt, "rea" andmebaasi haldussüsteemides, nagu MySQL, Postgres, MS SQL Server, on andmed salvestatud sellises järjekorras:

Samas salvestatakse ühe rea väärtused füüsiliselt koos. Veergupõhistes andmebaasi haldussüsteemides hoitakse erinevate veergude väärtusi eraldi, samas kui ühe veeru andmed hoitakse koos:

Veergupõ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 – meilifoorvarder Qwintry hakkas kasutama Clickhouse'i 2018. aastal aruannete koostamiseks ja oli selle lihtsuse, skaleeritavuse, SQL-i toe ja kiirusest väga positiivselt üllatunud. Selle andmebaasi töökiirus ulatus peaaegu maagiliseks.

Lihtsus

Clickhouse installimine Ubuntu-s toimub üheainsa käsuga. Kui oskate SQL-i, siis saate kohe alustada Clickhouse'i kasutamist oma vajaduste jaoks. Kuid see ei tähenda, et saaksite lihtsalt MySQL-is "show create table" käsku käitada ja teha SQL-i kopeerimist Clickhouse'i.

Võrreldes MySQL-iga on selle andmebaasi puhul olulised erinevused andmetüüpide määratlemises tabelite skeemides, seetõttu kulub teil siiski aega, et muuta tabelite skeemide määratlusi ja õppida tabelite mootoreid.

Clickhouse töötab suurepäraselt ilma igasuguste täiendavate tarkvarade installimiseta, kuid kui soovite kasutada replikatsiooni, vajate ZooKeeper'i installimist. Päringute jõudluse analüüs näitab suurepäraseid tulemusi — süsteemi tabelid sisaldavad kogu teavet ja kõik andmed on saadaval vana ja igava SQL-i abil.

Tõhusus

• Bensi Clickhouse'i võrdlemine Vertica ja MySQL-ga serverikonfiguratsioonil: kaks soket Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD-l, ext4.
• Bensi Clickhouse'i võrdlemine Amazon RedShift'i pilveteenusega.
• Kneeed blogist Cloudflare'i postitus Clickhouse'i jõudluse kohta:

ClickHouse andmebaas omab väga lihtsat disaini - kõik klastris olevad sõlmed omavad sama funktsionaalsust ja kasutavad koordineerimiseks ainult ZooKeeperit. Me tõstsime üles väikese klastrite, kus oli mitu sõlme ja tegime testimise, mille käigus leidsime, et süsteem omab üsna muljetavaldavat jõudlust, mis vastab väidetud eelistele analüütiliste andmebaaside bänšmarkides. Otsustasime põhjalikumalt uurida ClickHouse'i aluseks olevat kontseptsiooni. Esimese probleemina teadusuuringute teel oli tööriistade puudumine ja ClickHouse'i kogukonna vähesus, seetõttu süvenesime selle andmebaasi disaini, et mõista, kuidas see töötab.

ClickHouse ei toeta andmete vastuvõttu otse Kafka'st, kuna see on lihtsalt andmebaas, seetõttu kirjutasime omaenda adapterite teenuse Go keeles. See luges Kafka'st kodeeritud sõnumeid Cap’n Proto, muundas need TSV-ks ja sisestas need pakettidena ClickHouse'i HTTP-liidese kaudu. Hiljem kirjutasime selle teenuse ümber, et kasutada Go raamatukogu koos ClickHouse'i enda liidesega jõudluse tõstmiseks. Pakettide vastuvõtu jõudlust hinnates leidsime ühe olulise asja - ClickHouse'i jõudlus sõltub tugevalt paketi suurusest, see tähendab, samaaegselt sisestatud ridade arvust. Et mõista, miks see nii on, uurisime, kuidas ClickHouse andmeid salvestab.

ClickHouse'i peamine mootor, täpsemalt laudadeks kasutatavate mootorite perekond, on MergeTree. See mootor on kontseptuaalselt sarnane LSM algoritmiga, mida kasutatakse Google BigTable'is või Apache Cassandra's, kuid see väldib vahepealse mälutabeli loomist ja kirjutab andmed otse kettale. See tagab suurepärase kirjutamise läbilaskevõime, kuna iga sisestatud paket sorteeritakse ainult "peamise võtme" primary key järgi, pressitakse kokku ja kirjutatakse kettale, et luua segment.

Mälu tabeli või mingisuguse „värskuse” andmete mõiste puudumine tähendab, et andmeid saab vaid lisada; süsteem ei toeta muutmist ega kustutamist. Praegu on ainus viis andmete kustutamiseks nende kustutamine kalenderkuude kaupa, kuna segmendid ei ületa kunagi kuu piire. ClickHouse meeskond töötab aktiivselt selle funktsiooni kohandamise nimel. Teiselt poolt muudab see konfliktivabaks segmentide salvestamise ja liitmise, mistõttu vastuvõtu läbilaskevõime suureneb lineaarselt paralleelsete sisestuste arvuga, kuni toimub I/O või tuumade küllastus.
Kuid see asjaolu tähendab ka, et süsteem ei sobi väikeste partiide jaoks, seega kasutatakse puhverdamiseks Kafka teenuseid ja sisestajaid. Tõenäoliselt teeb ClickHouse taustal pidevalt segmente liitmist, nii et palju väikeseid andmeosi ühendatakse ja salvestatakse rohkem kordi, seeläbi suurendades kirjutamisintensiivsust. Samal ajal põhjustab liiga palju omavahel mitteseotud osi agressiivset sisestuste tootmise vähendamist, kuni liitmine jätkub. Oleme avastanud, et parim kompromiss reaalajas andmete vastuvõtu ja vastuvõtutootlikkuse vahel on vastuvõtt tabelisse piiratud arvu sisestuste puhul sekundis.

Lugemise sooritusvõime võti tabelites on indekseerimine ja andmete paiknemine kettal. Ükskõik kui kiire on töötlemine, kui mootori tuleb skaneerida terabaitide kaupa andmeid kettalt ja kasutada neist vaid osa, võtab see aega. ClickHouse on veergude kaupa salvestav süsteem, seega iga segment sisaldab iga veeru jaoks faili, kus on sorteeritud väärtused iga rea kohta. Seega võivad päringus puuduvad terved veerud esmalt jääda vahelt kõrvale ning seejärel võivad mõned rakud töötlemiseks toimuda paralleelselt vektoriseeritud täitmisega. Täieliku skaneerimise vältimiseks on igal segmendil väike indeksifail.

Arvestades, et kõik veerud on järjestatud „peamise võtme“ järgi, sisaldab indeksifail ainult märgid (kinni püütud read) iga N-nda rea kohta, et neid isegi väga suurte tabelite jaoks mälus hoida. Näiteks võib vaikeseaded seadistada nii, et „märkida iga 8192. rea“, siis „nõrk“ indekseerimine tabelisse, kus on 1 triljon rida, mis mahub kergesti mällu, võtab vaid 122 070 baiti.

Süsteemi areng

Clickhouse'i arengu ja täiustamise jälgimine on võimalik Githubi repole ja näha, et „kasvamisprotsess“ toimub muljetavaldava tempoga.

Populaarsus

Paistab, et Clickhouse'i populaarsus kasvab eksponentsiaalselt, eriti venekeelses kogukonnas. Eelmisel aastal toimunud konverents High load 2018 (Moskva, 8-9. november 2018) näitas, et sellised hiiglased nagu vk.com ja Badoo kasutavad Clickhouse'i, et sisestada andmeid (nt logisid) kümnetelt tuhandelt serverilt samal ajal. 40-minutilises videos Jurij Nasretdinov Vkontakte meeskonnast räägib, kuidas seda tehakse. Peagi avaldame materjali mugavuse huvides Habrile.

Rakendusvaldkonnad

Pärast seda, kui olen veidi aega uurimisele pühendanud, arvan, 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. Edasi on toodud üksikasjad ClickHouse'i kasutamise kohta nende andmebaaside moderniseerimiseks või täielikuks asendamiseks.

MySQL ja PostgreSQL võimekuse laiendamine

Hiljuti asendasime osaliselt MySQL-i ClickHouse'iga teadetetahvlite platvormil Mautic teadetetalblil. Probleem oli see, et MySQL salvestas halva kujunduse tõttu iga saadetud kirja ja iga selle kirja linki base64-hashiga, luues tohutu MySQL tabeli (email_stats). Pärast 10 miljoni kirja saatmist teenuse tellijatele kasvas selle tabeli suurus 150 GB peale ja MySQL hakkas aeglustuma lihtsate päringute ajal. Probleemi lahendamiseks failiruumi osas kasutasime edukalt InnoDB tabeli kokkusurumist, mis vähendas selle mahtu 4 korda. Kuid pole mõtet hoida MySQL-is üle 20-30 miljoni e-kirja vaid ajaloosse vaatamiseks, kuna iga lihtne päring, mis mingil põhjusel peab teostama täieliku skaneerimise, viib vahetusse ja suurenenud I/O koormuseni, millest saime regulaarselt Zabbixi hoiatusi.

Clickhouse kasutab kahte kokkusurumise algoritmi, mis vähendavad andmemahtu umbes 3-4 korda, kuid antud juhul olid andmed eriti "kokkusurutavad".

ELK asendamine

Oma kogemustest lähtuvalt nõuab ELK (ElasticSearch, Logstash ja Kibana, antud juhul ElasticSearch) kasutamine palju rohkem ressursse, kui on vajalik logide salvestamiseks. ElasticSearch on suurepärane mootor, kui vajate head täisteksti otsingut logides (aga ma ei usu, et see tõeliselt vajalik on), kuid mind huvitab, miks sellest on de-facto saanud standardne logide haldamise mootor. Selle vastuvõtu tulemuslikkus koos Logstashiga tekitas meile probleeme isegi üsna väikeste koormuste korral ja nõudis pidevat suurema RAM-i ja kettaruumi lisamist. Andmebaasina on Clickhouse parem kui ElasticSearch järgmiste põhjuste tõttu:

• SQL-dialekti tugi;
• Parim andmete salvestamise kokkusurumise määr;
• Regex regulaaravaldiste otsimise tugi, mitte täisteksti otsimise tugi;
• Parandatud päringute planeerimine ja üldine kõrgem jõudlus.

Praegu on suurim probleem ClickHouse'i võrdlemisel ELK-ga logide transportimise lahenduste puudumine ning selle teema dokumentatsiooni ja juhendite nappus. Sellegipoolest saab iga kasutaja ELK-d seadistada Digital Ocean'i juhendi abil, mis on väga oluline selliste tehnoloogiate kiireks rakendamiseks. Siin on andmebaasimootor, kuid Filebeat'i tugi ClickHouse'i jaoks puudub. Jah, seal on olemas fluentd ja logide töötlemiseks mõeldud süsteem loghouse, on olemas tööriist clicktail , et edastada logifailide andmeid ClickHouse'i, kuid see nõuab rohkem aega. Siiski jääb ClickHouse oma lihtsuse tõttu liidriks, mistõttu ka algajad suudavad selle paigaldada ja kasutada täielikult vaid kümne minutiga.

Eelistades minimalistlikke lahendusi, proovisin kasutada FluentBit'i, tööriista, mis edastab logisid väga väikese mälukasutusega, koos ClickHouse'iga, samal ajal püüdes vältida Kafka kasutamist. Siiski tuleb lahendada mõned väiksed ühilduvusprobleemid, näiteks kuupäeva formaadi probleemid, enne kui seda saab teha ilma vahetegemise kihita, mis konverteerib andmed FluentBit'ist ClickHouse'i.

Alternatiivselt saab ClickHouse'i kasutada ka Kibana tagaplaanina Grafana. Nii palju kui ma aru sain, võivad sellega kaasneda jõudlusprobleemid, kui renderdatakse tohutul hulgal andmepunkte, eriti vanemate Grafana versioonide puhul. Me Qwintry's pole seda veel proovinud, kuid kaebusi selle üle ilmneb aeg-ajalt ClickHouse'i tugikanalis Telegramis.

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

BigQuery ideaalne kasutusjuht on 1 TB JSON-andmete üleslaadimine ja nende peal analüüsiküsimuste tegemine. Big Query on suurepärane toode, mille skaleeritavust on raske üle hinnata. See on palju keerukam tarkvara kui ClickHouse, mis töötab sisemises klastris, kuid kliendi seisukohalt on sellel palju ühist ClickHouse'iga. BigQuery võib kiiresti "kulukaks" muutuda, kui hakkate maksma iga SELECT'i eest, seega on see tõeline SaaS-lahendus oma kõigi plusside ja miinustega.

ClickHouse on parim valik juhul, kui täidate palju arvutuslikult kallis küsimusi. Mida rohkem SELECT-i küsimusi te iga päev esitate, seda rohkem mõtet on asendada Big Query ClickHouse'iga, sest see vahetamine aitab teil säästa tuhandeid dollareid, kui tegemist on paljude terabaitide töödeldud andmetega. See ei kehti salvestatud andmete kohta, mille töötlemine Big Query's on suhteliselt odav.

Altinity kaasasutaja Aleksandr Zaitsevi artiklis "Üleminek ClickHouse'ile" räägitakse sellise andmebaasi migreerimise eelistest.

TimescaleDB asendamine

TimescaleDB on PostgreSQLi laiendamine, mis optimeerib ajajärkude 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 ajajoone nurgas, on see veergude struktuuri ja vektorküsimuste täitmise tõttu analüütiliste päringute töötlemisel enamasti TimescaleDB-st kolm korda kiirem. Lisaks on ClickHouse'i partiide andmete vastuvõtu jõudlus umbes kolm korda parem ning see kasutab 20 korda vähem kettaruumi, mis on tõeliselt oluline suurte ajalooliste andmete töötlemiseks.https://www.altinity.com/blog/ClickHouse-for-time-series.

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

Tulevased ClickHouse'i täiustused toovad tõenäoliselt sissetulekud, mille kaudu see on veelgi sobivam ajajärkude andmete töötlemiseks ja salvestamiseks. TimescaleDB võib olla parem valik kui "puhas" ClickHouse järgmistes olukordades:

• väiksed installatsioonid väga väikese mälumahtuga (<3 GB);
• suur hulk väikeseid INSERT-e, mida te ei soovi suurtesse fragmentidesse puhuda;
• parem järjepidevus, ühtsus ja ACID-nõuded;
• PostGIS-i tugi;
• integreerimine olemasolevate PostgreSQL-tabelitega, kuna TimescaleDB on põhimõtteliselt PostgreSQL.

konkurents Hadoopi ja MapReduce süsteemide vahel.

Hadoop ja teised MapReduce tooted suudavad täita mitmeid keerukaid arvutusi, kuid tavaliselt töötavad nad tohutu viivitusega. ClickHouse lahendab selle probleemi, töötlemata terabaitide andmeid ja andes tulemuse peaaegu koheselt. Seetõttu on ClickHouse oluliselt tõhusam kiire, interaktiivse analüütilise uuringu teostamiseks, mis peaks andmeanalüütikute huvi äratama.

konkurents Pinot ja Druidiga.

ClickHouse'i lähimad konkurendid on veergude lineaarsete avatud allikate tooted Pinot ja Druid. Hea töö nende süsteemide võrdluses on avaldatud artiklis Roman Leventov 1. veebruar 2018.

See artikkel vajab värskendamist – see ütleb, et ClickHouse ei toeta UPDATE ja DELETE operatsioone, mis ei ole viimaste versioonide kohta päris õiged.

Meil puudub piisav kogemus nende andmebaasidega, kuid mulle ei meeldi üldse keerulisus, mida infrastruktuur nõuab Druid ja Pinot käivitamiseks — seal on terve rida „liikumãisi osi“, ümbritsetud Java'ga igast küljest.

Druid ja Pinot on Apache'i inkubaatoriprojektid, mille arengut kajastatakse üksikasjalikult Apache'i projektide GitHubi lehtedel. Pinot ilmus inkubaatorisse oktoobris 2018, samas kui Druid sündis kaheksa kuud varem – veebruaris.

Teave AFSi toimimise kohta puudub ja see tekitab minus mitmeid, ja võib-olla ka tobedaid, küsimusi. Kas Pinot'i autorid on märganud, et Apache Foundation on Druidile palju vastuolulisem kui Pinot'ile, ning kas see on tekitanud nende seas kadedust? Kas Druid'i areng aeglustub ja Pinot'i areng kiireneb, kui esimese toetajad äkki teise vastu huvi tunnevad?

ClickHouse'i puudused

Küpsus: on ilmne, et see on endiselt lõbus tehnoloogia, kuid igal juhul ei täheldata midagi sarnast teistes veergandmebaasides.

Väikesed lisandid töötavad kõrge kiirusel halvasti: lisandid tuleks jagada suurteks tükkideks, kuna väikeste lisandite efektiivsus väheneb proportsionaalselt iga rea veergude arvule. Just nii ClickHouse salvestab andmeid kettale — iga veerg tähendab 1 faili või rohkem, seetõttu tuleb 1 rea lisamiseks, mis sisaldab 100 veergu, avada ja kirjutada vähemalt 100 faili. Sellepärast on lisandite vahemälu jaoks vajalik vahendaja (kui klient iseenesest vahemälu ei paku) — tavaliselt on see Kafka või mõni järjekorratehnoloogia. Samuti võib kasutada Buffer table'i mootorit, et hiljem kopeerida suured andmefraktsioonid MergeTree tabelitesse.

Tabelite ühendused on piiratud serveri mäluga, kuid vähemalt on need seal! Näiteks Druid ja Pinot ei oma selliseid ühendusi, kuna neid on raske rakendada jaotatud süsteemides, mis ei toeta suurte andmete tükikeste liikumist sõlmede vahel.

Järeldused

Järgnevatel aastatel kavatseme Qwintrys laialdaselt kasutada ClickHouse'i, kuna see andmebaasisüsteem pakub suurepärast tasakaalu jõudluse, madalate kulude, skaleeritavuse ja lihtsuse vahel. Olen peaaegu kindel, et see hakkab kiiresti levinema, kui ClickHouse'i kogukond leiab rohkem viise selle kasutamiseks väikestes ja keskmistes installatsioonides.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level 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 jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com