on Yandexi loodud avatud lähtekoodiga veergude andmebaasihaldussüsteem veebipõhise analüütilise päringu töötlemiseks (OLAP). Seda kasutavad Yandex, CloudFlare, VK.com, Badoo ja teised teenused üle maailma tõeliselt suurte andmemahtude salvestamiseks (sisestades tuhandeid ridu sekundis või petabaite kettale salvestatud andmeid).
Tavalises "stringi" DBMS-is, mille näideteks on MySQL, Postgres, MS SQL Server, salvestatakse andmed järgmises järjekorras:
Sel juhul salvestatakse ühe reaga seotud väärtused füüsiliselt läheduses. Veergude DBMS-ides salvestatakse erinevate veergude väärtused eraldi ja ühest veerust pärinevad andmed salvestatakse koos:
Veerupõhised DBMS-id on näiteks Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Postiedastaja ettevõte alustas Clickhouse’i kasutamist aruandluseks 2018. aastal ning avaldas suurt muljet selle lihtsus, mastaapsus, SQL-i tugi ja kiirus. Selle DBMS-i kiirus piirnes maagiaga.
Lihtsus
Clickhouse installitakse Ubuntule ühe käsuga. Kui tunnete SQL-i, saate Clickhouse'i oma vajaduste jaoks kohe kasutama hakata. Kuid see ei tähenda, et saate MySQL-is kuvada „tabeli loomise” ja SQL-i kopeerida-kleepida Clickhouse'is.
Võrreldes MySQL-iga on tabeliskeemi definitsioonides olulisi andmetüüpide erinevusi, seega kulub teil siiski veidi aega, et tabeliskeemi määratlusi muuta ja tabelimootoreid tundma õppida.
Clickhouse töötab suurepäraselt ilma täiendava tarkvarata, kuid kui soovite kasutada replikatsiooni, peate installima ZooKeeperi. Päringu jõudluse analüüs näitab suurepäraseid tulemusi - süsteemitabelid sisaldavad kogu teavet ja kõiki andmeid saab vana ja igava SQL-i abil hankida.
Производительность
- Clickhouse'i võrdlus Vertica ja MySQL-iga serveri konfiguratsioonis: kaks pesa Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD-l, ext4.
- Clickhouse'i võrdlus Amazon RedShifti pilvesalvestusega.
- Blogi väljavõtted :
ClickHouse'i andmebaas on väga lihtsa ülesehitusega – kõik klastri sõlmed on sama funktsionaalsusega ja kasutavad koordineerimiseks ainult ZooKeeperit. Ehitasime mitmest sõlmest väikese klastri ja teostasime testimise, mille käigus leidsime, et süsteemil on üsna muljetavaldav jõudlus, mis vastab analüütilistes DBMS-i võrdlusalustes välja toodud eelistele. Otsustasime ClickHouse'i kontseptsiooni lähemalt uurida. Esimene takistus uurimistööle oli tööriistade puudumine ja väike ClickHouse'i kogukond, mistõttu süvenesime selle DBMS-i disaini, et mõista selle toimimist.
ClickHouse ei toeta andmete otse vastuvõtmist Kafkalt, kuna see on lihtsalt andmebaas, nii et kirjutasime Go's oma adapteriteenuse. See luges Kafka Cap'n Proto kodeeritud sõnumeid, teisendas need TSV-vormingusse ja sisestas HTTP-liidese kaudu partiidena ClickHouse'i. Hiljem kirjutasime selle teenuse ümber, et kasutada toimivuse parandamiseks Go teeki koos ClickHouse'i enda liidesega. Pakettide vastuvõtmise jõudlust hinnates avastasime olulise asja - selgus, et ClickHouse’i puhul sõltub see jõudlus tugevalt paketi suurusest ehk samaaegselt sisestatud ridade arvust. Et mõista, miks see juhtub, uurisime, kuidas ClickHouse andmeid salvestab.
Peamine mootor või õigemini tabelimootorite perekond, mida ClickHouse andmete salvestamiseks kasutab, on MergeTree. See mootor sarnaneb põhimõtteliselt Google BigTable'is või Apache Cassandras kasutatava LSM-i algoritmiga, kuid väldib vahepealse mälutabeli koostamist ja kirjutab andmed otse kettale. See annab suurepärase kirjutamisvõimsuse, kuna iga sisestatud pakett sorteeritakse ainult primaarvõtme järgi, tihendatakse ja kirjutatakse segmendi moodustamiseks kettale.
Mälutabeli või andmete “värskuse” kontseptsiooni puudumine tähendab ka seda, et neid saab ainult lisada, süsteem ei toeta muutmist ega kustutamist. Praegu on ainus viis andmete kustutamiseks kustutada need kalendrikuu järgi, kuna segmendid ei ületa kunagi kuu piiri. ClickHouse'i meeskond töötab aktiivselt selle funktsiooni kohandamiseks. Teisest küljest muudab see segmentide kirjutamise ja ühendamise tülivabaks, nii et saate läbilaskevõime skaalasid lineaarselt samaaegsete lisade arvuga, kuni toimub I/O või tuuma küllastumine.
See aga tähendab ka seda, et süsteem ei sobi väikeste pakettide jaoks, mistõttu kasutatakse puhverdamiseks Kafka teenuseid ja sisestajaid. Järgmiseks jätkab ClickHouse taustal pidevalt segmentide liitmist, nii et palju väikeseid teabekilde kombineeritakse ja salvestatakse rohkem kordi, suurendades nii salvestuse intensiivsust. Liiga palju ühendamata osi põhjustab aga sisestuste agressiivset tõrjumist seni, kuni ühendamine jätkub. Oleme leidnud, et parim kompromiss reaalajas allaneelamise ja allaneelamise jõudluse vahel on tabelisse piiratud arv sisestusi sekundis.
Tabeli lugemise jõudluse võti on indekseerimine ja andmete asukoht kettal. Olenemata sellest, kui kiire on töötlemine, võtab see aega, kui mootor peab kettalt skannima terabaite andmeid ja kasutama ainult osa sellest. ClickHouse on veeruline pood, nii et iga segment sisaldab iga veeru (veeru) jaoks faili, kus on iga rea jaoks sorteeritud väärtused. Nii saab esmalt vahele jätta terved päringust puuduvad veerud ja seejärel töödelda mitut lahtrit paralleelselt vektoriseeritud täitmisega. Täieliku skannimise vältimiseks on igal segmendil väike registrifail.
Arvestades, et kõik veerud on sorteeritud “esmavõtme” järgi, sisaldab registrifail ainult iga N rea silte (hõive ridu), et saaks neid mällu hoida isegi väga suurte tabelite puhul. Näiteks saate määrata vaikesäteteks "märgi iga 8192. rida", seejärel "kasina" indekseerida tabelit 1 triljoniga. kergesti mällu mahtuvad read võtavad vaid 122 070 tähemärki.
Süsteemi arendamine
Clickhouse'i arengut ja täiustamist saab jälgida aadressil ja veenduge, et "kasvamise" protsess toimuks muljetavaldava tempoga.
Populaarsus
Clickhouse’i populaarsus näib hüppeliselt kasvavat, eriti venekeelses kogukonnas. Eelmise aasta High load 2018 konverents (Moskva, 8.-9) näitas, et sellised koletised nagu vk.com ja Badoo kasutavad Clickhouse’i, millega nad sisestavad andmeid (näiteks logisid) samaaegselt kümnetelt tuhandetelt serveritelt. 2018-minutilises videos . Peagi postitame materjaliga töötamise hõlbustamiseks ärakirja Habrile.
Taotlused
Pärast uurimistööle kulutamist arvan, et on valdkondi, kus ClickHouse võiks olla kasulik või võiks täielikult asendada teisi traditsioonilisemaid ja populaarsemaid lahendusi, nagu MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ja Druiid. Järgnevalt kirjeldatakse ülaltoodud DBMS-i ajakohastamiseks või täielikuks asendamiseks ClickHouse'i kasutamise üksikasju.
MySQL-i ja PostgreSQL-i võimaluste laiendamine
Just hiljuti asendasime MySQL-i osaliselt oma uudiskirjaplatvormi ClickHouse'iga . Probleem seisnes selles, et kehva kujunduse tõttu logis MySQL iga saadetud meili ja selle lingi base64 räsi abil, luues tohutu MySQL-i tabeli (email_stats). Pärast teenuse tellijatele vaid 10 miljoni meili saatmist võttis see tabel enda alla 150 GB failiruumi ja MySQL hakkas lihtsate päringute puhul „loll”. Failiruumi probleemi lahendamiseks kasutasime edukalt InnoDB tabeli tihendamist, mis vähendas seda 4 korda. Siiski pole siiski mõtet salvestada MySQL-i rohkem kui 20-30 miljonit meili ainult lugemisajaloo huvides, kuna iga lihtne päring, mis mingil põhjusel vajab täielikku skannimist, põhjustab vahetust ja palju /O koormus, mille kohta saime regulaarselt Zabbixilt hoiatusi.
Clickhouse kasutab kahte tihendusalgoritmi, mis vähendavad andmemahtu ligikaudu , kuid sel konkreetsel juhul olid andmed eriti "kokkusurutavad".
ELK asendamine
Minu enda kogemuse põhjal nõuab ELK pinu (ElasticSearch, Logstash ja Kibana, antud juhul ElasticSearch) töötamiseks palju rohkem ressursse kui logide salvestamiseks. ElasticSearch on suurepärane mootor, kui vajate head täisteksti logiotsingut (mida ma arvan, et te tegelikult ei vaja), kuid ma mõtlen, miks see on muutunud de facto standardseks logimootoriks. Selle neelamisjõudlus koos Logstashiga tekitas meile probleeme isegi üsna väikese koormuse korral ja nõudis üha rohkem RAM-i ja kettaruumi lisamist. Andmebaasina on Clickhouse parem kui ElasticSearch järgmistel põhjustel:
- SQL dialekti tugi;
- Salvestatud andmete parim tihendusaste;
- Regexi regulaaravaldise otsingute tugi täistekstiotsingu asemel;
- Täiustatud päringu ajastamine ja suurem üldine jõudlus.
Hetkel on suurim probleem, mis ClickHouse’i ELK-ga võrreldes üles kerkib, logide üleslaadimise lahenduste puudumine, samuti teemakohase dokumentatsiooni ja õpetuste puudumine. Lisaks saab iga kasutaja konfigureerida ELK-i Digital Oceani käsiraamatu abil, mis on selliste tehnoloogiate kiireks rakendamiseks väga oluline. Andmebaasimootor on olemas, kuid ClickHouse'i jaoks pole veel Filebeati. Jah, see on olemas ja süsteem palkidega töötamiseks , on olemas tööriist logifaili andmete sisestamiseks ClickHouse'i, kuid see kõik võtab rohkem aega. ClickHouse on aga oma lihtsuse tõttu endiselt liider, nii et isegi algajad saavad selle hõlpsasti installida ja juba 10 minutiga täielikult funktsionaalselt kasutama hakata.
Eelistades minimalistlikke lahendusi, proovisin koos ClickHouse'iga kasutada väga vähese mäluga logide saatmise tööriista FluentBit, püüdes samas vältida Kafka kasutamist. Küll aga tuleb tegeleda väiksemate sobimatustega, nt Enne seda saab teha ilma puhverserveri kihita, mis teisendab andmed FluentBitist ClickHouse'iks.
Alternatiivina saab Kibanat kasutada ClickHouse'i taustaprogrammina . Minu arusaamist mööda võib see põhjustada jõudlusprobleeme suure hulga andmepunktide renderdamisel, eriti Grafana vanemate versioonide puhul. Me pole seda Qwintrys veel proovinud, kuid Telegrami ClickHouse'i tugikanalis ilmuvad aeg-ajalt selle kohta kaebused.
Google Big Query ja Amazon RedShifti asendamine (lahendus suurettevõtetele)
Ideaalne BigQuery kasutusjuht on laadida 1 TB JSON-andmeid ja käitada sellel analüütilisi päringuid. Big Query on suurepärane toode, mille skaleeritavust ei saa üle hinnata. See on siseklastris töötavast ClickHouse'ist palju keerulisem tarkvara, kuid kliendi seisukohast on sellel palju ühist ClickHouse'iga. BigQuery võib kiiresti kalliks minna, kui hakkate SELECTi eest maksma, seega on see tõeline SaaS-i lahendus koos oma plusside ja miinustega.
ClickHouse on parim valik, kui käitate palju arvutuslikult kulukaid päringuid. Mida rohkem SELECT päringuid iga päev käivitate, seda mõttekam on Big Query asendada ClickHouse'iga, sest selline asendus võib säästa tuhandeid dollareid, kui tegemist on paljude terabaitide töödeldavate andmetega. See ei kehti salvestatud andmete kohta, mida on Big Querys üsna odav töödelda.
Altinity kaasasutaja Aleksander Zaitsevi artiklis räägib sellise DBMS-i migratsiooni eelistest.
TimescaleDB asendamine
TimescaleDB on PostgreSQL-i laiendus, mis optimeerib tööd aegridade aegridadega tavalises andmebaasis (, ).
Kuigi ClickHouse ei ole tõsine konkurent aegridade nišis, vaid veerukujulise struktuuri ja vektorpäringu täitmisega, on see enamikel juhtudel analüütilise päringu töötlemisel palju kiirem kui TimescaleDB. Samal ajal on ClickHouse'ist pakiandmete vastuvõtmise jõudlus ligikaudu 3 korda suurem ja see kasutab ka 20 korda vähem kettaruumi, mis on väga oluline suurte ajalooliste andmete töötlemiseks: .
Erinevalt ClickHouse'ist on ainus viis TimescaleDB kettaruumi säästmiseks kasutada ZFS-i või sarnaseid failisüsteeme.
ClickHouse'i eelseisvad uuendused võtavad tõenäoliselt kasutusele delta tihendamise, mis muudab selle aegridade andmete töötlemiseks ja salvestamiseks veelgi sobivamaks. TimescaleDB võib olla parem valik kui paljas ClickHouse järgmistel juhtudel:
- väikesed installid väga vähese RAM-iga (<3 GB);
- suur hulk väikeseid INSERTe, mida te ei soovi puhverdada suurteks fragmentideks;
- parem järjepidevus, ühtlus ja ACID nõuded;
- PostGIS-i tugi;
- liitumine olemasolevate PostgreSQL-i tabelitega, kuna ajaskaala DB on sisuliselt PostgreSQL.
Võistlus Hadoopi ja MapReduce süsteemidega
Hadoop ja teised MapReduce'i tooted suudavad teha palju keerulisi arvutusi, kuid neil on tavaliselt suur latentsusaeg. ClickHouse lahendab selle probleemi, töötledes terabaiti andmeid ja andes tulemusi peaaegu kohe. Seega on ClickHouse palju tõhusam kiirete interaktiivsete analüütiliste uuringute läbiviimisel, mis peaks andmeteadlastele huvi pakkuma.
Võistlus Pinot ja Druidiga
ClickHouse'i lähimad konkurendid on sammaskujulised, lineaarselt skaleeritavad avatud lähtekoodiga tooted Pinot ja Druid. Artiklis on avaldatud suurepärane töö nende süsteemide võrdlemiseks kuupäevaga 1. veebruar 2018
See artikkel vajab värskendamist – seal öeldakse, et ClickHouse ei toeta UPDATE ja DELETE toiminguid, mis ei kehti viimaste versioonide puhul täielikult.
Meil pole nende andmebaasidega palju kogemusi, kuid mulle ei meeldi Druidi ja Pinoti käitamiseks vajaliku infrastruktuuri keerukus – see on terve hulk liikuvaid osi, mida igast küljest ümbritseb Java.
Druid ja Pinot on Apache inkubaatoriprojektid, mille edenemist Apache oma GitHubi projektilehtedel üksikasjalikult kajastab. Pinot ilmus inkubaatorisse 2018. aasta oktoobris ja Druid sündis 8 kuud varem – veebruaris.
Teabe puudumine AFS-i toimimise kohta tekitab minus mõningaid ja võib-olla rumalaid küsimusi. Huvitav, kas Pinot autorid märkasid, et Apache Foundation on Druidi suhtes soosivam ja kas selline suhtumine konkurendisse tekitas kadedust? Kas Druidi areng aeglustub ja Pinot’ areng kiireneb, kui esimese toetajad hakkavad ootamatult teise vastu huvi tundma?
ClickHouse'i puudused
Ebaküpsus: Ilmselgelt pole see ikka veel igav tehnoloogia, kuid igal juhul ei täheldata teistes veergude DBMS-ides midagi sellist.
Väikesed lisad ei tööta suurel kiirusel hästi: lisad tuleb jagada suuremateks tükkideks, kuna väikeste sisestuste jõudlus halveneb proportsionaalselt veergude arvuga igas reas. Nii salvestab ClickHouse andmed kettale – iga veerg tähistab 1 faili või enamat, nii et 1 veergu sisaldava rea sisestamiseks tuleb avada ja kirjutada vähemalt 100 faili. Seetõttu on lisade puhverdamiseks vaja vahendajat (kui klient ise puhverdamist ei paku) - tavaliselt Kafka või mõni järjekorrahaldussüsteem. Puhvertabeli mootorit saate kasutada ka suurte andmete kopeerimiseks hiljem MergeTree tabelitesse.
Tabelite liitumisi piirab serveri RAM, kuid vähemalt on need olemas! Näiteks Druidil ja Pinotil pole selliseid ühendusi üldse, kuna neid on keeruline otse juurutada hajutatud süsteemides, mis ei toeta suurte andmetükkide liigutamist sõlmede vahel.
Järeldused
Plaanime ClickHouse'i lähiaastatel Qwintrys laialdaselt kasutada, kuna see DBMS tagab suurepärase jõudluse, madala üldkulu, mastaapsuse ja lihtsuse tasakaalu. Olen üsna kindel, et see hakkab kiiresti levima, kui ClickHouse'i kogukond pakub rohkem võimalusi selle kasutamiseks väikestes ja keskmise suurusega installides.
Mõned reklaamid 🙂
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com