er opinn uppspretta dálkalaga gagnagrunnsstjórnunarkerfi fyrir netgreiningarfyrirspurnavinnslu (OLAP) búið til af Yandex. Það er notað af Yandex, CloudFlare, VK.com, Badoo og öðrum þjónustum um allan heim til að geyma mjög mikið magn af gögnum (innsetning þúsunda raða á sekúndu eða petabæta af gögnum sem eru geymd á diski).
Í venjulegu „streng“ DBMS, dæmi um það eru MySQL, Postgres, MS SQL Server, eru gögn geymd í þessari röð:
Í þessu tilviki eru gildin sem tengjast einni röð líkamlega geymd hlið við hlið. Í dálkalaga DBMS eru gildi frá mismunandi dálkum geymd sérstaklega og gögn eins dálks eru geymd saman:
Dæmi um dálkalaga DBMS eru Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Fyrirtækið er póstsending Ég byrjaði að nota Clickhouse árið 2018 til skýrslugerðar og var mjög hrifinn af einfaldleika þess, sveigjanleika, SQL stuðningi og hraða. Hraði þessa DBMS jaðraði við töfra.
vellíðan
Clickhouse setur upp á Ubuntu með einni skipun. Ef þú þekkir SQL geturðu strax byrjað að nota Clickhouse fyrir þínar þarfir. Hins vegar þýðir þetta ekki að þú getir "sýnt búa til töflu" í MySQL og copy-paste SQL í Clickhouse.
Í samanburði við MySQL er mikilvægur munur á gagnategundum í skilgreiningum á töfluskemu í þessu DBMS, svo þú þarft enn smá tíma til að breyta töfluskemaskilgreiningunum og læra töfluvélarnar til að verða þægilegar.
Clickhouse virkar frábærlega án viðbótarhugbúnaðar, en ef þú vilt nota afritun þarftu að setja ZooKeeper upp. Frammistöðugreining fyrirspurna sýnir framúrskarandi árangur - kerfistöflurnar innihalda allar upplýsingar og hægt er að nálgast öll gögn með gömlum og leiðinlegum SQL.
Framleiðni
- Clickhouse á móti Vertica og MySQL samanburði á stillingarþjóni: tvær innstungur Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB vinnsluminni; md RAID-5 á 8 6TB SATA HDD, ext4.
- samanburður á Clickhouse við Amazon RedShift skýgeymslu.
- Bloggbrot :
ClickHouse gagnagrunnurinn hefur mjög einfalda hönnun - allir hnútar í þyrpingunni hafa sömu virkni og nota aðeins ZooKeeper til samhæfingar. Við byggðum lítinn þyrpingu af nokkrum hnútum og framkvæmdum prófun, þar sem við komumst að því að kerfið hefur nokkuð glæsilega frammistöðu, sem samsvarar þeim kostum sem haldið er fram í greinandi DBMS viðmiðum. Við ákváðum að skoða nánar hugmyndina á bakvið ClickHouse. Fyrsta hindrunin fyrir rannsóknum var skortur á verkfærum og lítið samfélag ClickHouse, svo við kafuðum ofan í hönnun þessa DBMS til að skilja hvernig það virkar.
ClickHouse styður ekki móttöku gagna beint frá Kafka, þar sem þetta er bara gagnagrunnur, svo við skrifuðum okkar eigin millistykkisþjónustu í Go. Það las Cap'n Proto kóðuð skilaboð frá Kafka, breytti þeim í TSV og setti þau inn í ClickHouse í lotum í gegnum HTTP viðmótið. Við endurskrifuðum þessa þjónustu síðar til að nota Go bókasafnið í tengslum við okkar eigin ClickHouse viðmót til að bæta árangur. Við mat á frammistöðu móttöku pakka uppgötvuðum við mikilvægan hlut - það kom í ljós að fyrir ClickHouse fer þessi frammistaða mjög eftir stærð pakkans, það er fjölda raða sem settar eru inn á sama tíma. Til að skilja hvers vegna þetta gerist, rannsökuðum við hvernig ClickHouse geymir gögn.
Aðalvélin, eða öllu heldur, fjölskylda borðvéla sem ClickHouse notar til að geyma gögn, er MergeTree. Þessi vél er hugmyndalega svipuð LSM reikniritinu sem notað er í Google BigTable eða Apache Cassandra, en forðast að byggja upp millistigs minnistöflu og skrifar gögn beint á diskinn. Þetta gefur honum framúrskarandi skrifafköst, þar sem hver pakki sem settur er inn er aðeins flokkaður eftir „aðallykil“ aðallyklinum, þjappaður og skrifaður á disk til að mynda hluta.
Skortur á minnistöflu eða einhver hugtak um „ferskleika“ gagna þýðir líka að aðeins er hægt að bæta þeim við, kerfið styður ekki breytingar eða eyðingu. Frá og með deginum í dag er eina leiðin til að eyða gögnum að eyða þeim eftir almanaksmánuði, þar sem hlutir fara aldrei yfir mánaðarmörk. ClickHouse teymið vinnur virkan að því að gera þennan eiginleika sérhannaðan. Á hinn bóginn gerir það skrif og sameiningu hluta deilulausa, þannig að fá afköst kvarða línulega með fjölda samhliða innskots þar til I/O eða kjarna mettast.
Hins vegar þýðir þetta líka að kerfið hentar ekki fyrir litla pakka, þannig að Kafka þjónustur og innsetningartæki eru notuð fyrir biðminni. Ennfremur, ClickHouse í bakgrunni heldur áfram að sameina hluti stöðugt, þannig að margar litlar upplýsingar verða sameinaðar og skráðar oftar og eykur þannig styrkleika upptökunnar. Hins vegar munu of margir óskyldir hlutar valda árásargjarnri inngjöf á innleggjum svo lengi sem sameiningin heldur áfram. Við höfum komist að því að besta málamiðlunin milli inntöku gagna í rauntíma og inntökuárangurs er að samþykkja takmarkaðan fjölda innskots á sekúndu í töfluna.
Lykillinn að afköstum lestrar töflu er flokkun og staðsetning gagna á diski. Sama hversu hröð vinnslan er, þegar vélin þarf að skanna terabæt af gögnum af diski og nota aðeins brot af þeim mun það taka tíma. ClickHouse er dálkaverslun, þannig að hver hluti inniheldur skrá fyrir hvern dálk (dálk) með flokkuðum gildum fyrir hverja röð. Þannig er fyrst hægt að sleppa heilum dálkum sem ekki eru til staðar í fyrirspurninni og síðan er hægt að vinna úr mörgum hólfum samhliða vektoraðri framkvæmd. Til að forðast fulla skönnun hefur hver hluti litla vísitöluskrá.
Í ljósi þess að allir dálkar eru flokkaðir eftir "aðallyklinum", inniheldur vísitöluskráin aðeins merki (fangaðar línur) hverrar N. röð, til að geta haldið þeim í minni jafnvel fyrir mjög stórar töflur. Til dæmis geturðu stillt sjálfgefnar stillingar á að „merkja hverja 8192. röð“, síðan „lítil“ flokkun á töflu með 1 trilljón. línur sem passa auðveldlega inn í minnið myndu aðeins taka 122 stafi.
Kerfisþróun
Rekja má þróun og endurbætur á Clickhouse og vertu viss um að ferlið „að alast upp“ sé að gerast á glæsilegum hraða.
Vinsældir
Svo virðist sem vinsældir Clickhouse fari vaxandi, sérstaklega í rússneskumælandi samfélagi. Háálagsráðstefnan 2018 á síðasta ári (Moskva, 8.-9. nóvember 2018) sýndi að skrímsli eins og vk.com og Badoo nota Clickhouse, sem setur inn gögn (til dæmis annála) frá tugþúsundum netþjóna samtímis. Í 40 mínútna myndbandi . Bráðum munum við birta afritið á Habr til að auðvelda vinnu með efnið.
Umsóknir
Eftir að hafa eytt tíma í að rannsaka held ég að það séu svæði þar sem ClickHouse getur verið gagnlegt eða geta komið algjörlega í stað annarra hefðbundnari og vinsælari lausna eins og MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot og Druid. Eftirfarandi eru upplýsingar um notkun ClickHouse til að uppfæra eða skipta algjörlega um ofangreinda DBMS.
Framlenging MySQL og PostgreSQL
Nú síðast skiptum við MySQL að hluta út fyrir ClickHouse fyrir fréttabréfavettvanginn . Vandamálið var að MySQL vegna vanhugsaðrar hönnunar skráði hvern póst sem var sendur og hvern hlekk í þeim tölvupósti með base64 kjötkássa og bjó til risastóra MySQL töflu (email_stats). Eftir að hafa sent aðeins 10 milljónir tölvupósta til áskrifenda þjónustunnar tók þetta borð 150 GB af skráaplássi og MySQL byrjaði að „heimska“ í einföldum fyrirspurnum. Til að laga vandamálið með skráarrýminu notuðum við InnoDB töfluþjöppun með góðum árangri, sem minnkaði það um 4. Hins vegar er samt ekki skynsamlegt að geyma meira en 20-30 milljónir tölvupósta í MySQL bara til að lesa sögu, þar sem allar einföld fyrirspurn sem af einhverjum ástæðum þarf að gera fulla skönnun leiðir til skiptis og þungs I/O yfir höfuð, sem við fengum reglulega Zabbix viðvaranir um.
Clickhouse notar tvö þjöppunaralgrím sem minnka gagnamagnið um u.þ.b , en í þessu tiltekna tilviki voru gögnin sérstaklega „þjappanleg“.
ELK skipti
Byggt á eigin reynslu, ELK staflan (ElasticSearch, Logstash og Kibana, í þessu tiltekna tilfelli ElasticSearch) þarf miklu meira fjármagn til að keyra en þarf til að geyma logs. ElasticSearch er frábær vél ef þú vilt góða leit í fullum textaskrá (sem ég held að þú þurfir ekki), en ég er að velta því fyrir mér hvers vegna það er orðið að raunverulega staðlaða skráningarvélinni. Inntökuafköst þess, ásamt Logstash, olli okkur vandamálum jafnvel við frekar létt vinnuálag og krafðist þess að bæta við meira og meira vinnsluminni og diskpláss. Sem gagnagrunnur er Clickhouse betri en ElasticSearch af eftirfarandi ástæðum:
- SQL mállýskur stuðningur;
- Besta samþjöppun geymdra gagna;
- Stuðningur við Regex leit í stað fulltextaleitar;
- Bætt fyrirspurnaáætlun og betri heildarafköst.
Eins og er, er stærsta vandamálið sem kemur upp þegar borið er saman ClickHouse við ELK skortur á lausnum til að hlaða upp annálum, sem og skortur á skjölum og kennsluefni um þetta efni. Á sama tíma getur hver notandi sett upp ELK með Digital Ocean handbókinni, sem er mjög mikilvægt fyrir hraða innleiðingu slíkrar tækni. Það er gagnagrunnsvél hér, en það er ekkert Filebeat fyrir ClickHouse ennþá. Já það er og kerfi til að vinna með logs , það er tól til að slá inn gagnaskrárgögn í ClickHouse, en allt þetta tekur lengri tíma. Hins vegar er ClickHouse enn í fararbroddi vegna einfaldleika þess, svo jafnvel byrjendur geta auðveldlega sett það upp og byrjað að nota fullkomlega virka á aðeins 10 mínútum.
Ég valdi naumhyggjulausnir og reyndi að nota FluentBit, mjög lítið minnisupphleðslutæki, með ClickHouse á meðan ég reyndi að forðast að nota Kafka. Hins vegar þarf að bregðast við smávægilegum ósamræmi, ss áður en hægt er að gera það án umboðslagsins sem breytir gögnum frá FluentBit í ClickHouse.
Sem valkostur við Kibana geturðu notað ClickHouse sem stuðning . Eftir því sem ég skil, getur þetta valdið frammistöðuvandamálum þegar gríðarlegur fjöldi gagnapunkta er birtur, sérstaklega með eldri útgáfum af Grafana. Í Qwintry höfum við ekki prófað þetta ennþá, en kvartanir um þetta birtast af og til á ClickHouse stuðningsrásinni í Telegram.
Skipti um Google Big Query og Amazon RedShift (lausn fyrir stór fyrirtæki)
Tilvalið notkunartilvik fyrir BigQuery er að hlaða 1TB af JSON gögnum og keyra greiningarfyrirspurnir á þeim. Big Query er frábær vara þar sem erfitt er að ofmeta sveigjanleika hennar. Þetta er mun flóknari hugbúnaður en ClickHouse sem keyrir á innri klasa, en frá sjónarhóli viðskiptavinarins á hann margt sameiginlegt með ClickHouse. BigQuery getur fljótt „verðlagt“ þegar þú byrjar að borga fyrir hverja SELECT, svo þetta er alvöru SaaS lausn með öllum sínum kostum og göllum.
ClickHouse er besti kosturinn þegar þú keyrir mikið af reikningslega dýrum fyrirspurnum. Því fleiri SELECT-fyrirspurnir sem þú keyrir á hverjum degi, því meiri tilgangur er að skipta út Big Query fyrir ClickHouse, því slík skipti mun spara þér þúsundir dollara þegar kemur að vinnslu margra terabæta af gögnum. Þetta á ekki við um geymd gögn, sem er frekar ódýrt í vinnslu í Big Query.
Í grein eftir Alexander Zaitsev, meðstofnanda Altinity lýsir ávinningi slíkrar DBMS-flutnings.
Skipti um tímaskalaDB
TimescaleDB er PostgreSQL viðbót sem fínstillir vinnu með tímaröð í venjulegum gagnagrunni (, ).
Þrátt fyrir að ClickHouse sé ekki alvarlegur keppinautur í tímaraðir sess, en hvað varðar dálka uppbyggingu og framkvæmd vektorfyrirspurna, er það mun hraðari en TimescaleDB í flestum tilfellum við vinnslu greiningarfyrirspurna. Á sama tíma er árangur móttöku ClickHouse pakkagagna um það bil 3 sinnum meiri, auk þess notar það 20 sinnum minna pláss, sem er mjög mikilvægt til að vinna mikið magn af sögulegum gögnum: .
Ólíkt ClickHouse er eina leiðin til að spara pláss í TimescaleDB að nota ZFS eða svipuð skráarkerfi.
Komandi uppfærslur á ClickHouse munu líklega kynna delta þjöppun, sem mun gera það enn hentugra til að vinna úr og geyma tímaraðargögn. TimescaleDB gæti verið betri kostur en ber ClickHouse í eftirfarandi tilvikum:
- litlar uppsetningar með mjög lítið vinnsluminni (<3 GB);
- mikill fjöldi lítilla INSERTs sem þú vilt ekki buffa í stór brot;
- betri samkvæmni, einsleitni og sýrukröfur;
- PostGIS stuðningur;
- sameinast núverandi PostgreSQL töflum, þar sem Timescale DB er í raun PostgreSQL.
Samkeppni við Hadoop og MapReduce kerfi
Hadoop og aðrar MapReduce vörur geta framkvæmt marga flókna útreikninga, en þeir hafa tilhneigingu til að keyra á mikilli leynd. ClickHouse lagar þetta vandamál með því að vinna terabæta af gögnum og framleiða niðurstöður nánast samstundis. Þannig er ClickHouse mun skilvirkara til að framkvæma hraðvirkar, gagnvirkar greiningarrannsóknir, sem ættu að vekja áhuga gagnafræðinga.
Keppni við Pinot og Druid
Næstu keppinautar ClickHouse eru súlulaga, línulega stigstærðar opinn uppspretta vörur Pinot og Druid. Frábært starf við að bera saman þessi kerfi er birt í greininni 1. febrúar 2018
Þessa grein þarf að uppfæra - hún segir að ClickHouse styðji ekki UPDATE og DELETE aðgerðir, sem er ekki alveg satt í tengslum við nýjustu útgáfurnar.
Við höfum ekki mikla reynslu af þessum DBMS, en mér líkar ekki hversu flókinn undirliggjandi innviði er sem þarf til að keyra Druid og Pinot - þetta er heill hópur af "hreyfanlegum hlutum" umkringdur Java frá öllum hliðum.
Druid og Pinot eru Apache útungunarvélarverkefni, sem Apache fjallar ítarlega um á GitHub verkefnasíðum þeirra. Pinot kom fram í hitakassa í október 2018 og Druid fæddist 8 mánuðum fyrr - í febrúar.
Skortur á upplýsingum um hvernig AFS virkar vekur upp nokkrar og kannski heimskulegar spurningar hjá mér. Ég velti því fyrir mér hvort höfundar Pinot hafi tekið eftir því að Apache stofnunin er hneigðara til Druid, og hafi slík afstaða til keppanda valdið öfundartilfinningu? Mun þróun Druid hægja á og þróun Pinot hraðast ef styrktaraðilar sem styðja þann fyrrnefnda fá skyndilega áhuga á þeim síðarnefnda?
Ókostir ClickHouse
Vanþroski: Vitanlega er þetta enn leiðinleg tækni, en í öllu falli sést ekkert eins og þetta í öðrum dálkum DBMS.
Lítil innlegg skila sér ekki vel á miklum hraða: innskotum verður að skipta í stóra bita vegna þess að frammistaða lítilla innleggs minnkar í hlutfalli við fjölda dálka í hverri röð. Svona geymir ClickHouse gögn á diski - hver dálkur þýðir 1 skrá eða fleiri, þannig að til að setja inn 1 röð sem inniheldur 100 dálka þarftu að opna og skrifa að minnsta kosti 100 skrár. Þetta er ástæðan fyrir því að insert buffering krefst milliliðs (nema biðlarinn sjálfur útvegi buffering) - venjulega Kafka eða einhvers konar biðröðkerfi. Þú getur líka notað Buffer töfluvélina til að afrita síðar stóra klumpa af gögnum í MergeTree töflur.
Table joins eru takmörkuð af vinnsluminni miðlara, en þeir eru að minnsta kosti til staðar! Til dæmis hafa Druid og Pinot alls ekki slíkar tengingar, þar sem erfitt er að útfæra þær beint í dreifðum kerfum sem styðja ekki flutning á stórum gagnaklumpum á milli hnúta.
Niðurstöður
Á næstu árum ætlum við að nýta ClickHouse í Qwintry í miklu mæli, þar sem þetta DBMS veitir frábært jafnvægi á afköstum, lágum kostnaði, sveigjanleika og einfaldleika. Ég er nokkuð viss um að það dreifist hratt þegar ClickHouse samfélagið kemur með fleiri leiðir til að nota það í litlum og meðalstórum uppsetningum.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com