ProHoster > Blog > Pangangasiwa > ClickHouse para sa mga advanced na user sa mga tanong at sagot

ClickHouse para sa mga advanced na user sa mga tanong at sagot

Noong Abril, nagtipon ang mga inhinyero ng Avito para sa mga online na pagpupulong kasama ang pangunahing developer ng ClickHouse na sina Alexey Milovidov at Kirill Shvakov, isang developer ng Golang mula sa Integros. Tinalakay namin kung paano namin ginagamit ang isang database management system at kung anong mga paghihirap ang aming nararanasan.

Batay sa pulong, nag-compile kami ng isang artikulo na may mga sagot ng mga eksperto sa aming mga tanong at ng madla tungkol sa mga pag-backup, pag-reshard ng data, mga panlabas na diksyunaryo, driver ng Golang at pag-update ng mga bersyon ng ClickHouse. Maaaring kapaki-pakinabang ito sa mga developer na aktibong nagtatrabaho sa Yandex DBMS at interesado sa kasalukuyan at hinaharap nito. Bilang default, ang mga sagot ay ni Alexey Milovidov, maliban kung nakasulat.

Mag-ingat, mayroong maraming teksto sa ilalim ng hiwa. Umaasa kami na ang nilalamang may mga tanong ay makakatulong sa iyo na mag-navigate.

ClickHouse para sa mga advanced na user sa mga tanong at sagot

nilalaman

Kung ayaw mong basahin ang teksto, maaari mong panoorin ang pag-record ng mga pagtitipon sa aming YouTube channel. Ang mga timecode ay nasa unang komento sa ilalim ng video.

Ang ClickHouse ay patuloy na ina-update, ngunit ang aming data ay hindi. Ano ang gagawin tungkol dito?

Ang ClickHouse ay patuloy na ina-update, at ang aming data, na na-optimize na panghuling naproseso, ay hindi na-update at nasa isang backup na kopya.

Sabihin nating nagkaroon kami ng ilang problema at nawala ang data. Napagpasyahan naming ibalik, at lumabas na ang mga lumang partisyon, na nakaimbak sa mga backup na server, ay ibang-iba sa kasalukuyang ginagamit na bersyon ng ClickHouse. Ano ang gagawin sa ganoong sitwasyon, at posible ba?

Ang isang sitwasyon kung saan naibalik mo ang data mula sa isang backup sa isang lumang format, ngunit hindi ito kumonekta sa bagong bersyon, ay imposible. Tinitiyak namin na ang format ng data sa ClickHouse ay palaging nananatiling pabalik na tugma. Ito ay mas mahalaga kaysa sa paatras na compatibility sa functionality kung ang gawi ng ilang bihirang ginagamit na function ay nagbago. Dapat palaging mabasa ng bagong bersyon ng ClickHouse ang data na nakaimbak sa disk. Ito ang batas.

Ano ang kasalukuyang pinakamahuhusay na kagawian para sa pag-back up ng data mula sa ClickHouse?

Paano gumawa ng mga pag-backup, isinasaalang-alang na mayroon kaming na-optimize na panghuling mga operasyon, isang malaking database ng mga terabytes, at data na na-update, halimbawa, sa huling tatlong araw, at pagkatapos ay walang mga pamamaraan na nangyari dito?

Maaari tayong gumawa ng sarili nating solusyon at magsulat sa bash: kolektahin ang mga backup na kopya na ito sa ganoon at ganoong paraan. Siguro hindi na kailangang magsaklay ng anuman, at ang bisikleta ay naimbento na noon pa?

Magsimula tayo sa pinakamahuhusay na kagawian. Palaging nagpapayo ang aking mga kasamahan, bilang tugon sa mga tanong tungkol sa mga backup, na paalalahanan sila tungkol sa serbisyo ng Yandex.Cloud, kung saan nalutas na ang problemang ito. Kaya gamitin ito kung maaari.

Walang kumpletong solusyon para sa mga backup, isang daang porsyento na binuo sa ClickHouse. Mayroong ilang mga blangko na maaaring magamit. Upang makakuha ng kumpletong solusyon, kakailanganin mong mag-tinker nang kaunti nang manu-mano, o lumikha ng mga wrapper sa anyo ng mga script.

Magsisimula ako sa mga pinakasimpleng solusyon at magtatapos sa mga pinaka sopistikadong solusyon, depende sa dami ng data at laki ng cluster. Kung mas malaki ang kumpol, nagiging mas kumplikado ang solusyon.

Kung ang talahanayan na may data ay sumasakop lamang ng ilang gigabytes, maaaring gawin ang pag-backup tulad nito:

  1. I-save ang kahulugan ng talahanayan i.e. metadata − ipakita ang paglikha ng talahanayan.
  2. Gumawa ng dump gamit ang ClickHouse client - piliin * mula sa mesa mag-file. Bilang default, makakatanggap ka ng file sa TabSeparated na format. Kung gusto mong maging mas mahusay, magagawa mo ito sa Native na format.

Kung ang dami ng data ay mas malaki, ang pag-backup ay tatagal ng mas maraming oras at maraming espasyo. Tinatawag itong lohikal na backup; hindi ito nakatali sa format ng data ng ClickHouse. Kung ito ay, pagkatapos bilang isang huling paraan maaari kang kumuha ng backup at i-upload ito sa MySQL para sa pagbawi.

Para sa mas advanced na mga kaso, ang ClickHouse ay may built-in na kakayahan upang lumikha ng snapshot ng mga partisyon sa lokal na file system. Ang tampok na ito ay magagamit bilang isang kahilingan baguhin ang table freeze partition. O kaya lang baguhin ang table freeze - ito ay isang snapshot ng buong talahanayan.

Ang snapshot ay gagawin nang tuluy-tuloy para sa isang table sa isang shard, ibig sabihin, imposibleng gumawa ng pare-parehong snapshot ng buong cluster sa ganitong paraan. Ngunit para sa karamihan ng mga gawain ay walang ganoong pangangailangan, at sapat na upang magsagawa ng isang kahilingan sa bawat shard at makakuha ng pare-parehong snapshot. Ito ay nilikha sa anyo ng mga hardlink at samakatuwid ay hindi tumatagal ng karagdagang espasyo. Susunod, kopyahin mo ang snapshot na ito sa backup server o sa storage na ginagamit mo para sa mga backup.

Ang pagpapanumbalik ng naturang backup ay medyo madali. Una, gumawa ng mga talahanayan gamit ang mga kasalukuyang kahulugan ng talahanayan. Susunod, kopyahin ang mga naka-save na snapshot ng mga partisyon sa Directory-Detached para sa mga talahanayang ito at patakbuhin ang query ikabit ang partisyon. Ang solusyon na ito ay lubos na angkop para sa pinakaseryosong dami ng data.

Minsan kailangan mo ng isang bagay na mas cool - sa mga kaso kung saan mayroon kang sampu o kahit na daan-daang terabytes sa bawat server at daan-daang mga server. Mayroong solusyon dito na kinuha ko mula sa aking mga kasamahan mula sa Yandex.Metrica. Hindi ko ito irerekomenda sa lahat - basahin ito at magpasya para sa iyong sarili kung ito ay angkop o hindi.

Una kailangan mong lumikha ng ilang mga server na may malalaking istante ng disk. Susunod, sa mga server na ito, itaas ang ilang mga server ng ClickHouse at i-configure ang mga ito upang gumana ang mga ito bilang isa pang replika para sa parehong mga shards. At pagkatapos ay gumamit ng isang file system o ilang tool sa mga server na ito na nagpapahintulot sa iyo na lumikha ng mga snapshot. Mayroong dalawang mga pagpipilian dito. Ang unang opsyon ay LVM snapshots, ang pangalawang opsyon ay ZFS sa Linux.

Pagkatapos nito, araw-araw kailangan mong lumikha ng isang snapshot, ito ay magsisinungaling at kukuha ng ilang espasyo. Naturally, kung magbabago ang data, tataas ang dami ng espasyo sa paglipas ng panahon. Maaaring alisin ang snapshot na ito anumang oras at maibalik ang data, isang kakaibang solusyon. Dagdag pa, kailangan din nating limitahan ang mga replica na ito sa config para hindi nila subukang maging lider.

Posible bang ayusin ang isang kinokontrol na lag ng mga replika sa mga shaft?

Sa taong ito ay nagpaplano kang gumawa ng mga shaft sa ClickHouse. Posible bang ayusin ang isang kinokontrol na lag ng mga replika sa kanila? Gusto naming gamitin ito para protektahan ang aming sarili mula sa mga negatibong sitwasyon na may mga pagbabago at iba pang pagbabago.

Posible bang gumawa ng ilang uri ng roll back para sa mga pagbabago? Halimbawa, sa isang umiiral na baras, kunin at sabihin na hanggang sa sandaling ito ay ilalapat mo ang mga pagbabago, at mula sa sandaling ito ay huminto ka sa paglalapat ng mga pagbabago?

Kung may dumating na command sa aming cluster at sinira ito, pagkatapos ay mayroon kaming conditional replica na may isang oras na lag, kung saan maaari naming sabihin na gamitin natin ito sa sandaling ito, ngunit hindi namin ilalapat ang mga pagbabago dito sa huling sampung minuto?

Una, tungkol sa kinokontrol na lag ng mga replika. Nagkaroon ng ganoong kahilingan mula sa mga user, at gumawa kami ng isyu sa Github na may kahilingan: "Kung may nangangailangan nito, tulad nito, maglagay ng puso." Walang naghatid, at sarado na ang isyu. Gayunpaman, maaari mo nang makuha ang pagkakataong ito sa pamamagitan ng pag-set up ng ClickHouse. Totoo, nagsisimula lamang sa bersyon 20.3.

Ang ClickHouse ay patuloy na nagsasagawa ng data merging sa background. Kapag nakumpleto ang isang pagsasanib, ang isang tiyak na hanay ng mga piraso ng data ay papalitan ng isang mas malaking piraso. Kasabay nito, ang mga piraso ng data na naroon noon ay patuloy na nananatili sa disk nang ilang panahon.

Una, ang mga ito ay patuloy na iniimbak hangga't may mga piling query na gumagamit ng mga ito, upang makapagbigay ng non-blocking operation. Ang mga piling query ay madaling basahin mula sa mga lumang chunks.

Pangalawa, mayroon ding time threshold - ang mga lumang piraso ng data ay nasa disk sa loob ng walong minuto. Ang walong minutong ito ay maaaring i-customize at maging isang araw. Magkakahalaga ito ng puwang sa disk: depende sa daloy ng data, lumalabas na sa huling araw ang data ay hindi lamang doble, maaari itong maging limang beses pa. Ngunit kung may malubhang problema, maaari mong ihinto ang ClickHouse server at ayusin ang lahat.

Ngayon ang tanong ay lumitaw kung paano ito nagpoprotekta laban sa mga pagbabago. Ito ay nagkakahalaga ng pagkuha ng mas malalim na pagtingin dito, dahil sa mas lumang mga bersyon ng ClickHouse, ang pagbabago ay nagtrabaho sa paraang ito ay direktang nagbago ng mga piraso. Mayroong isang piraso ng data na may ilang mga file, at ginagawa namin, halimbawa, baguhin ang drop column. Pagkatapos ay pisikal na inalis ang column na ito sa lahat ng chunks.

Ngunit simula sa bersyon 20.3, ang mekanismo ng pagbabago ay ganap na nabago, at ngayon ang mga piraso ng data ay palaging hindi nababago. Hindi sila nagbabago - gumagana na ngayon ang mga pagbabago sa parehong paraan tulad ng mga pagsasanib. Sa halip na palitan ang isang piraso sa lugar, gumawa kami ng bago. Sa bagong chunk, ang mga file na hindi nagbago ay naging mga hardlink, at kung magde-delete tayo ng column, mawawala lang ito sa bagong chunk. Ang lumang piraso ay tatanggalin bilang default pagkatapos ng walong minuto, at dito maaari mong i-tweak ang mga setting na binanggit sa itaas.

Ang parehong naaangkop sa mga pagbabago tulad ng mutations. Kapag ginawa mo baguhin ang tanggalin o baguhin ang update, hindi nito binabago ang piraso, ngunit lumilikha ng bago. At pagkatapos ay tanggalin ang luma.

Paano kung ang istraktura ng talahanayan ay nagbago?

Paano ibalik ang isang backup na ginawa gamit ang lumang scheme? At ang pangalawang tanong ay tungkol sa kaso na may mga snapshot at mga tool sa file system. Maganda ba ang Btrfs dito sa halip na ZFS sa Linux LVM?

Kung gagawin mo ikabit ang partisyon mga partisyon na may ibang istraktura, pagkatapos ay sasabihin sa iyo ng ClickHouse na hindi ito posible. Ito ang solusyon. Ang una ay gumawa ng pansamantalang talahanayan ng uri ng MergeTree na may lumang istraktura, mag-attach ng data doon gamit ang attach, at gumawa ng alter query. Pagkatapos ay maaari mong kopyahin o ilipat ang data na ito at i-attach muli, o gumamit ng kahilingan baguhin ang table move partition.

Ngayon ang pangalawang tanong ay kung magagamit ang Btrfs. Upang magsimula, kung mayroon kang LVM, kung gayon ang mga snapshot ng LVM ay sapat, at ang file system ay maaaring ext4, hindi mahalaga. Sa Btrts, ang lahat ay nakasalalay sa iyong karanasan sa paggamit nito. Ito ay isang mature na file system, ngunit mayroon pa ring ilang mga hinala tungkol sa kung paano gagana ang lahat sa pagsasanay sa isang partikular na senaryo. Hindi ko irerekomenda ang paggamit nito maliban kung mayroon kang mga Btrf sa produksyon.

Ano ang kasalukuyang pinakamahuhusay na kagawian sa resharding ng data?

Ang isyu ng resharding ay kumplikado at multifaceted. Mayroong ilang mga posibleng sagot dito. Maaari kang pumunta mula sa isang tabi at sabihin ito - ClickHouse ay walang built-in na resharding tampok. Ngunit natatakot ako na ang sagot na ito ay hindi angkop sa sinuman. Samakatuwid, maaari kang pumunta mula sa kabilang panig at sabihin na ang ClickHouse ay may maraming mga paraan upang reshard ang data.

Kung maubusan ng espasyo ang cluster o hindi nito mahawakan ang pag-load, magdagdag ka ng mga bagong server. Ngunit ang mga server na ito ay walang laman bilang default, walang data sa kanila, walang load. Kailangan mong muling ayusin ang data upang maging pantay-pantay itong kumalat sa bago, mas malaking cluster.

Ang unang paraan na magagawa nito ay ang kopyahin ang bahagi ng mga partisyon sa mga bagong server gamit ang isang kahilingan baguhin ang table fetch partition. Halimbawa, mayroon kang mga partisyon ayon sa buwan, at kukunin mo ang unang buwan ng 2017 at kopyahin ito sa isang bagong server, pagkatapos ay kopyahin ang ikatlong buwan sa ibang bagong server. At gagawin mo ito hanggang sa maging mas o mas mababa ito.

Ang paglipat ay maaaring isagawa lamang para sa mga partisyon na hindi nagbabago habang nagre-record. Para sa mga sariwang partisyon, kailangang i-disable ang pagre-record, dahil hindi atomic ang kanilang paglilipat. Kung hindi, magkakaroon ka ng mga duplicate o gaps sa data. Gayunpaman, ang pamamaraang ito ay praktikal at gumagana nang lubos. Ang mga handa na naka-compress na partisyon ay ipinadala sa network, iyon ay, ang data ay hindi na-compress o muling na-encode.

Ang pamamaraang ito ay may isang disbentaha, at depende ito sa sharding scheme, kung nangako ka sa sharding scheme na ito, kung anong sharding key ang mayroon ka. Sa iyong halimbawa para sa kaso na may mga sukatan, ang sharding key ay ang hash ng path. Kapag pumili ka ng Ibinahagi na talahanayan, mapupunta ito sa lahat ng shards sa cluster nang sabay-sabay at kumukuha ng data mula doon.

Nangangahulugan ito na talagang hindi mahalaga sa iyo kung anong data ang napunta sa kung aling shard. Ang pangunahing bagay ay ang data sa isang landas ay nagtatapos sa isang shard, ngunit kung alin ang hindi mahalaga. Sa kasong ito, ang paglilipat ng mga handa na partisyon ay perpekto, dahil sa mga piling query makakatanggap ka rin ng kumpletong data - bago mag-resharding o pagkatapos, ang scheme ay hindi talaga mahalaga.

Ngunit may mga kaso na mas kumplikado. Kung sa antas ng lohika ng aplikasyon ay umaasa ka sa isang espesyal na scheme ng sharding, na ang kliyenteng ito ay matatagpuan sa ganito at ganoong shard, at ang kahilingan ay maaaring ipadala nang direkta doon, at hindi sa Naipamahagi na talahanayan. O ikaw ay gumagamit ng isang medyo kamakailang bersyon ng ClickHouse at pinagana ang setting i-optimize ang laktawan ang mga hindi nagamit na shards. Sa kasong ito, sa panahon ng piling query, susuriin ang expression sa seksyong kung saan at kakalkulahin kung aling mga shards ang kailangang gamitin ayon sa sharding scheme. Ito ay gumagana sa kondisyon na ang data ay nahahati nang eksakto ayon sa sharding scheme na ito. Kung manu-mano mong inayos ang mga ito, maaaring magbago ang sulat.

Kaya ito ang paraan numero uno. At hinihintay ko ang iyong sagot, kung ang pamamaraan ay angkop, o magpatuloy tayo.

Vladimir Kolobaev, nangunguna sa tagapangasiwa ng sistema sa Avito: Alexey, ang paraan na iyong binanggit ay hindi gumagana nang maayos kapag kailangan mong ikalat ang pagkarga, kasama ang pagbabasa. Maaari kaming kumuha ng partition na buwanan at maaaring dalhin ang nakaraang buwan sa isa pang node, ngunit kapag dumating ang isang kahilingan para sa data na ito, ilo-load lang namin ito. Ngunit nais naming i-load ang buong kumpol, dahil kung hindi, sa loob ng ilang oras ang buong pag-load ng pagbabasa ay mapoproseso ng dalawang shards.

Alexey Milovidov: Ang sagot dito ay kakaiba - oo, masama ito, ngunit maaaring gumana ito. Ipapaliwanag ko nang eksakto kung paano. Ito ay nagkakahalaga ng pagtingin sa senaryo ng pagkarga na nasa likod ng iyong data. Kung ito ay data ng pagsubaybay, halos tiyak na masasabi natin na ang karamihan sa mga kahilingan ay para sa bagong data.

Nag-install ka ng mga bagong server, nag-migrate ng mga lumang partition, ngunit binago mo rin kung paano naitala ang bagong data. At ang bagong data ay ikakalat sa buong cluster. Kaya, pagkatapos lamang ng limang minuto, ang mga kahilingan para sa huling limang minuto ay pantay na maglo-load sa cluster; pagkatapos ng isang araw, ang mga kahilingan para sa XNUMX na oras ay pantay na maglo-load sa cluster. At ang mga kahilingan para sa nakaraang buwan, sa kasamaang-palad, ay mapupunta lamang sa bahagi ng mga cluster server.

Ngunit kadalasan ay wala kang mga kahilingang partikular para sa Pebrero 2019. Malamang, kung ang mga kahilingan ay mapupunta sa 2019, ang mga ito ay para sa buong 2019 - para sa isang malaking yugto ng panahon, at hindi para sa ilang maliit na saklaw. At ang mga naturang kahilingan ay makakapag-load din sa cluster nang pantay-pantay. Ngunit sa pangkalahatan, ang iyong sinabi ay ganap na tama na ito ay isang ad hoc na solusyon na hindi ganap na nagkakalat ng data nang pantay-pantay.

Mayroon pa akong ilang puntos upang sagutin ang tanong. Ang isa sa mga ito ay tungkol sa kung paano unang magdisenyo ng sharding scheme upang ang muling pagbaha ay magdulot ng mas kaunting sakit. Ito ay hindi laging posible.

Halimbawa, mayroon kang data sa pagsubaybay. Ang data ng pagsubaybay ay lumalaki para sa tatlong dahilan. Ang una ay ang akumulasyon ng makasaysayang datos. Ang pangalawa ay ang paglaki ng trapiko. At ang pangatlo ay ang pagtaas ng bilang ng mga bagay na napapailalim sa monitoring. May mga bagong microservice at sukatan na kailangang i-save.

Posible na sa mga ito, ang pinakamalaking pagtaas ay nauugnay sa ikatlong dahilan - ang pagtaas sa paggamit ng pagsubaybay. At sa kasong ito, ito ay nagkakahalaga ng pagtingin sa likas na katangian ng pag-load, ano ang mga pangunahing piling query. Ang mga pangunahing piling query ay malamang na ibabatay sa ilang subset ng mga sukatan.

Halimbawa, ang paggamit ng CPU sa ilang server ng ilang serbisyo. Lumalabas na mayroong partikular na subset ng mga key kung saan mo makukuha ang data na ito. At ang kahilingan mismo para sa data na ito ay malamang na medyo simple at nakumpleto sa sampu-sampung millisecond. Ginagamit para sa pagsubaybay sa mga serbisyo at dashboard. Sana naiintindihan ko ito ng tama.

Vladimir Kolobaev: Ang katotohanan ay madalas kaming umaapela sa makasaysayang data, dahil inihahambing namin ang kasalukuyang sitwasyon sa makasaysayang sitwasyon sa real time. At mahalaga para sa amin na magkaroon ng mabilis na pag-access sa isang malaking halaga ng data, at ang ClickHouse ay gumagawa ng isang mahusay na trabaho dito.

Talagang tama ka, nararanasan namin ang karamihan sa mga kahilingan sa pagbabasa sa huling araw, tulad ng anumang sistema ng pagsubaybay. Ngunit sa parehong oras, ang pag-load sa makasaysayang data ay medyo malaki din. Ito ay karaniwang mula sa isang sistema ng pag-aalerto na umiikot bawat tatlumpung segundo at nagsasabi sa ClickHouse: “Bigyan mo ako ng data para sa huling anim na linggo. Ngayon, bumuo ako ng ilang uri ng moving average mula sa kanila, at ikumpara natin ang kasalukuyang halaga sa makasaysayang halaga."

Gusto kong sabihin na para sa mga napakakamakailang kahilingan ay mayroon kaming isa pang maliit na talahanayan kung saan kami ay nag-iimbak lamang ng dalawang araw ng data, at ang mga pangunahing kahilingan ay lilipad dito. Nagpapadala lang kami ng malalaking makasaysayang query sa malaking sharded table.

Alexey Milovidov: Sa kasamaang palad, ito ay lumalabas na hindi gaanong naaangkop para sa iyong senaryo, ngunit sasabihin ko sa iyo ang isang paglalarawan ng dalawang masama at kumplikadong mga sharding scheme na hindi kailangang gamitin, ngunit ginagamit sa serbisyo ng aking mga kaibigan.

Mayroong pangunahing kumpol na may mga kaganapan sa Yandex.Metrica. Ang mga kaganapan ay mga page view, pag-click, at conversion. Karamihan sa mga kahilingan ay napupunta sa isang partikular na website. Binuksan mo ang serbisyo ng Yandex.Metrica, mayroon kang website - avito.ru, pumunta sa ulat, at isang kahilingan ang ginawa para sa iyong website.

Ngunit may iba pang mga kahilingan - analytical at global - na ginawa ng mga panloob na analyst. Kung sakali, tandaan ko na ang mga panloob na analyst ay gumagawa lamang ng mga kahilingan para sa mga serbisyo ng Yandex. Ngunit gayunpaman, kahit na ang mga serbisyo ng Yandex ay sumasakop ng isang makabuluhang bahagi ng lahat ng data. Ito ay mga kahilingan hindi para sa mga partikular na counter, ngunit para sa mas malawak na pag-filter.

Paano ayusin ang data sa paraang mahusay na gumagana ang lahat para sa isang counter, at mga pandaigdigang query din? Ang isa pang kahirapan ay ang bilang ng mga kahilingan sa ClickHouse para sa cluster ng Metrics ay ilang libo bawat segundo. Kasabay nito, hindi kayang pangasiwaan ng isang server ng ClickHouse ang mga di-maliit na kahilingan, halimbawa, ilang libo bawat segundo.

Ang laki ng cluster ay anim na raan-something server. Kung kukuha ka lang ng isang Naipamahagi na talahanayan sa kumpol na ito at magpadala ng ilang libong kahilingan doon, mas malala pa ito kaysa sa pagpapadala sa kanila sa isang server. Sa kabilang banda, ang opsyon na ang data ay ikalat nang pantay-pantay, at pumunta kami at humiling mula sa lahat ng mga server, ay agad na na-dismiss.

Mayroong isang opsyon na diametrically opposite. Isipin kung pinaghati-hatian namin ang data sa mga site, at ang isang kahilingan para sa isang site ay mapupunta sa isang shard. Ngayon ang cluster ay makakayanan ng sampung libong mga kahilingan sa bawat segundo, ngunit sa isang shard anumang isang kahilingan ay gagana masyadong mabagal. Hindi na ito susukat sa mga tuntunin ng throughput. Lalo na kung ito ang site na avito.ru. Hindi ko isisiwalat ang sikreto kung sasabihin kong isa ang Avito sa pinaka binibisitang site sa RuNet. At ang pagproseso nito sa isang shard ay magiging kabaliwan.

Samakatuwid, ang sharding scheme ay idinisenyo sa isang mas tusong paraan. Ang buong cluster ay nahahati sa isang bilang ng mga cluster, na tinatawag naming mga layer. Ang bawat kumpol ay naglalaman ng mula sa isang dosenang hanggang ilang dosenang shards. Mayroong tatlumpu't siyam na mga kumpol sa kabuuan.

Paano ito nasusukat sa lahat? Ang bilang ng mga kumpol ay hindi nagbabago - dahil ito ay tatlumpu't siyam ilang taon na ang nakalilipas, ito ay nananatiling gayon. Ngunit sa loob ng bawat isa sa kanila, unti-unti naming dinadagdagan ang bilang ng mga shards habang nag-iipon kami ng data. At ang scheme ng sharding sa kabuuan ay ganito: ang mga kumpol na ito ay nahahati sa mga website, at upang maunawaan kung aling website ang nasa kung aling cluster, isang hiwalay na metabase sa MySQL ang ginagamit. Isang site - sa isang kumpol. At sa loob nito, nangyayari ang sharding ayon sa mga ID ng bisita.

Kapag nagre-record, hinahati namin ang mga ito sa natitirang bahagi ng visitor ID. Ngunit kapag nagdagdag ng bagong shard, nagbabago ang sharding scheme; patuloy kaming naghahati, ngunit may natitira sa dibisyon ng isa pang numero. Nangangahulugan ito na ang isang bisita ay matatagpuan na sa ilang mga server, at hindi ka makakaasa dito. Ginagawa lamang ito upang matiyak na mas mahusay na na-compress ang data. At kapag gumagawa ng mga kahilingan, pumupunta kami sa Ibinahagi na talahanayan, na tumitingin sa kumpol at nag-a-access ng dose-dosenang mga server. Ito ay isang hangal na pamamaraan.

Ngunit hindi kumpleto ang aking kwento kung hindi ko sasabihin na tinalikuran natin ang pamamaraang ito. Sa bagong scheme, binago namin ang lahat at kinopya ang lahat ng data gamit ang clickhouse-copier.

Sa bagong pamamaraan, ang lahat ng mga site ay nahahati sa dalawang kategorya - malaki at maliit. Hindi ko alam kung paano napili ang threshold, ngunit ang resulta ay ang malalaking site ay naitala sa isang kumpol, kung saan mayroong 120 shards na may tatlong replika bawat isa - iyon ay, 360 server. At ang sharding scheme ay tulad na ang anumang kahilingan ay mapupunta sa lahat ng shards nang sabay-sabay. Kung magbubukas ka na ngayon ng anumang pahina ng ulat para sa avito.ru sa Yandex.Metrica, mapupunta ang kahilingan sa 120 server. Mayroong ilang mga malalaking site sa RuNet. At ang mga kahilingan ay hindi isang libo bawat segundo, ngunit kahit na mas mababa sa isang daan. Ang lahat ng ito ay tahimik na ngumunguya ng Ibinahagi na talahanayan, na ang bawat isa sa kanila ay pinoproseso na may 120 server.

At ang pangalawang kumpol ay para sa maliliit na site. Narito ang isang sharding scheme batay sa site ID, at ang bawat kahilingan ay napupunta sa eksaktong isang shard.

Ang ClickHouse ay may isang clickhouse-copier utility. Maaari mo bang sabihin sa akin ang tungkol sa kanya?

Sasabihin ko kaagad na ang solusyon na ito ay mas mahirap at medyo hindi gaanong produktibo. Ang kalamangan ay na ito ay bumagsak sa data ayon sa pattern na iyong tinukoy. Ngunit ang disbentaha ng utility ay hindi ito nagre-reshard sa lahat. Kinokopya nito ang data mula sa isang cluster schema patungo sa isa pang cluster schema.

Nangangahulugan ito na para gumana dapat mayroon kang dalawang kumpol. Matatagpuan ang mga ito sa parehong mga server, ngunit, gayunpaman, ang data ay hindi ililipat nang paunti-unti, ngunit makokopya.

Halimbawa, mayroong apat na server, ngayon mayroon nang walo. Lumilikha ka ng bagong Ibinahagi na talahanayan sa lahat ng mga server, bagong lokal na mga talahanayan at ilunsad ang clickhouse-copier, na nagpapahiwatig dito ng scheme ng trabaho na dapat nitong basahin mula doon, tanggapin ang bagong sharding scheme at ilipat ang data doon. At sa mga lumang server kakailanganin mo ng isa at kalahating beses na mas maraming espasyo kaysa sa mayroon ngayon, dahil ang lumang data ay dapat manatili sa kanila, at kalahati ng parehong lumang data ay darating sa ibabaw ng mga ito. Kung naisip mo nang maaga na ang data ay kailangang i-reshard at mayroong espasyo, kung gayon ang pamamaraang ito ay angkop.

Paano gumagana ang clickhouse-copier sa loob? Pinaghihiwa nito ang lahat ng gawain sa isang hanay ng mga gawain para sa pagproseso ng isang partition ng isang table sa isang shard. Ang lahat ng mga gawaing ito ay maaaring isagawa nang magkatulad, at ang clickhouse-copier ay maaaring patakbuhin sa iba't ibang mga makina sa maraming pagkakataon, ngunit kung ano ang ginagawa nito para sa isang partition ay walang iba kundi isang insert na pinili. Ang data ay binabasa, na-decompress, nirepartition, pagkatapos ay muling i-compress, isinulat sa isang lugar, at muling inayos. Ito ay isang mas mahigpit na desisyon.

Nagkaroon ka ng pilot na bagay na tinatawag na resharding. Ano sa kanya?

Noong 2017, nagkaroon ka ng pilot na bagay na tinatawag na resharding. Mayroong kahit isang pagpipilian sa ClickHouse. Sa pagkakaintindi ko, hindi ito nag-take off. Maaari mo bang sabihin sa akin kung bakit ito nangyari? Mukhang napaka-kaugnay nito.

Ang buong problema ay kung ito ay kinakailangan upang reshard data sa lugar, napaka-komplikadong synchronization ay kinakailangan upang gawin ito atomically. Noong sinimulan naming tingnan kung paano gumagana ang pag-synchronize na ito, naging malinaw na may mga pangunahing problema. At ang mga pangunahing problemang ito ay hindi lamang teoretikal, ngunit agad na nagsimulang ipakita ang kanilang sarili sa pagsasanay sa anyo ng isang bagay na maaaring ipaliwanag nang simple - walang gumagana.

Posible bang pagsamahin ang lahat ng mga piraso ng data nang magkasama bago ilipat ito sa mga mabagal na disk?

Tanong tungkol sa TTL sa paglipat sa mabagal na opsyon sa disk sa konteksto ng mga pagsasanib. Mayroon bang paraan, maliban sa pamamagitan ng cron, upang pagsamahin ang lahat ng mga bahagi sa isa bago ilipat ang mga ito sa mga slow disk?

Ang sagot sa tanong ay posible na kahit papaano ay awtomatikong idikit ang lahat ng mga piraso sa isa bago ilipat ang mga ito - hindi. Sa tingin ko ay hindi ito kailangan. Hindi mo kailangang pagsamahin ang lahat ng mga bahagi sa isa, ngunit umasa lamang sa katotohanan na ang mga ito ay awtomatikong ililipat sa mga mabagal na disk.

Mayroon kaming dalawang pamantayan para sa mga panuntunan sa paglipat. Ang una ay habang ito ay napuno. Kung ang kasalukuyang tier ng storage ay may mas mababa sa isang tiyak na porsyento ng libreng espasyo, pipili kami ng isang chunk at ililipat ito sa mas mabagal na storage. O sa halip, hindi mas mabagal, ngunit ang susunod - habang nag-configure ka.

Ang pangalawang criterion ay laki. Ito ay tungkol sa paglipat ng malalaking piraso. Maaari mong ayusin ang threshold ayon sa libreng espasyo sa mabilis na disk, at ang data ay awtomatikong ililipat.

Paano lumipat sa mga bagong bersyon ng ClickHouse kung walang paraan upang suriin ang pagiging tugma nang maaga?

Ang paksang ito ay regular na tinatalakay sa ClickHouse telegram chat isinasaalang-alang ang iba't ibang mga bersyon, at gayon pa man. Gaano kaligtas ang mag-upgrade mula sa bersyon 19.11 hanggang 19.16 at, halimbawa, mula 19.16 hanggang 20.3. Ano ang pinakamahusay na paraan upang lumipat sa mga bagong bersyon nang hindi masuri ang pagiging tugma sa sandbox nang maaga?

Mayroong ilang mga "ginintuang" panuntunan dito. Una - basahin ang changelog. Malaki ito, ngunit may mga hiwalay na talata tungkol sa mga pabalik na hindi tugmang pagbabago. Huwag ituring ang mga puntong ito bilang isang pulang bandila. Ang mga ito ay kadalasang maliliit na hindi pagkakatugma na may kasamang ilang paggana sa gilid na malamang na hindi mo ginagamit.

Pangalawa, kung walang paraan upang suriin ang pagiging tugma sa sandbox, at gusto mong mag-update kaagad sa produksyon, ang rekomendasyon ay hindi mo kailangang gawin ito. Gumawa muna ng sandbox at subukan. Kung walang pagsubok na kapaligiran, malamang na wala kang isang napakalaking kumpanya, na nangangahulugang maaari mong kopyahin ang ilan sa data sa iyong laptop at tiyaking gumagana nang tama ang lahat dito. Maaari ka ring magtaas ng ilang mga replika nang lokal sa iyong makina. O maaari kang pumili ng bagong bersyon sa isang lugar sa malapit at mag-upload ng ilan sa data doon - iyon ay, lumikha ng isang improvised na kapaligiran sa pagsubok.

Ang isa pang panuntunan ay hindi mag-update sa loob ng isang linggo pagkatapos ng paglabas ng bersyon dahil sa pagkakaroon ng mga bug sa produksyon at mga kasunod na mabilisang pag-aayos. Alamin natin ang pagnunumero ng mga bersyon ng ClickHouse upang hindi malito.

Mayroong bersyon 20.3.4. Ang numero 20 ay nagpapahiwatig ng taon ng paggawa - 2020. Mula sa punto ng view ng kung ano ang nasa loob, hindi ito mahalaga, kaya hindi namin ito bibigyan ng pansin. Susunod - 20.3. Pinapataas namin ang pangalawang numero - sa kasong ito 3 - sa tuwing maglalabas kami ng release na may ilang bagong functionality. Kung gusto naming magdagdag ng ilang feature sa ClickHouse, dapat naming dagdagan ang bilang na ito. Iyon ay, sa bersyon 20.4 ClickHouse ay gagana kahit na mas mahusay. Ang ikatlong digit ay 20.3.4. Narito ang 4 ang bilang ng mga release ng patch kung saan hindi kami nagdagdag ng mga bagong feature, ngunit naayos ang ilang mga bug. At 4 ay nangangahulugan na ginawa namin ito ng apat na beses.

Huwag isipin na ito ay isang bagay na kakila-kilabot. Kadalasan ay maaaring i-install ng user ang pinakabagong bersyon at gagana ito nang walang anumang problema sa uptime bawat taon. Ngunit isipin na sa ilang function para sa pagproseso ng mga bitmap, na idinagdag ng aming mga kasamang Tsino, nag-crash ang server kapag nagpapasa ng mga maling argumento. Responsibilidad nating ayusin ito. Maglalabas kami ng bagong bersyon ng patch at ang ClickHouse ay magiging mas matatag.

Kung mayroon kang ClickHouse na tumatakbo sa produksyon, at ang isang bagong bersyon ng ClickHouse ay lumabas na may mga karagdagang tampok - halimbawa, ang 20.4.1 ang pinakaunang isa, huwag magmadali upang ilagay ito sa produksyon sa pinakaunang araw. Bakit kailangan pa? Kung hindi mo pa ginagamit ang ClickHouse, maaari mo itong i-install, at malamang na magiging maayos ang lahat. Ngunit kung gumagana nang matatag ang ClickHouse, pagkatapos ay bantayan ang mga patch at update upang makita kung anong mga problema ang inaayos namin.

Kirill Shvakov: Gusto kong magdagdag ng kaunti tungkol sa mga kapaligiran ng pagsubok. Ang lahat ay labis na natatakot sa mga kapaligiran ng pagsubok at sa ilang kadahilanan ay naniniwala sila na kung mayroon kang isang napakalaking cluster ng ClickHouse, kung gayon ang kapaligiran ng pagsubok ay dapat na hindi bababa o hindi bababa sa sampung beses na mas maliit. Hindi naman ganoon.

Masasabi ko sa iyo mula sa aking sariling halimbawa. Mayroon akong isang proyekto, at mayroong ClickHouse. Ang aming kapaligiran sa pagsubok ay para lamang sa kanya - ito ay isang maliit na virtual machine sa Hetzner sa halagang dalawampung euro, kung saan ganap na lahat ay naka-deploy. Upang gawin ito, mayroon kaming ganap na automation sa Ansible, at samakatuwid, sa prinsipyo, walang pagkakaiba kung saan pupunta - sa mga server ng hardware o i-deploy lamang sa mga virtual machine.

Ano ang maaaring gawin? Mainam na magbigay ng halimbawa sa dokumentasyon ng ClickHouse kung paano mag-deploy ng maliit na kumpol sa iyong sariling tahanan - sa Docker, sa LXC, marahil ay lumikha ng Ansible playbook, dahil ang iba't ibang tao ay may iba't ibang deployment. Ito ay magpapasimple ng marami. Kapag kumuha ka at nag-deploy ng cluster sa loob ng limang minuto, mas madaling subukang mag-isip ng isang bagay. Ito ay mas maginhawa, dahil ang paglipat sa isang bersyon ng produksyon na hindi mo pa nasusuri ay isang daan patungo sa wala. Minsan gumagana at minsan hindi. At samakatuwid, ang pag-asa para sa tagumpay ay masama.

Maxim Kotyakov, senior backend engineer Avito: Magdaragdag ako ng kaunti tungkol sa mga kapaligiran ng pagsubok mula sa isang serye ng mga problemang kinakaharap ng malalaking kumpanya. Mayroon kaming ganap na cluster ng pagtanggap ng ClickHouse; sa mga tuntunin ng mga scheme at setting ng data, ito ay isang eksaktong kopya ng kung ano ang nasa produksyon. Ang cluster na ito ay naka-deploy sa medyo rundown na mga container na may minimum na mapagkukunan. Nagsusulat kami ng isang tiyak na porsyento ng data ng produksyon doon, sa kabutihang palad posible na kopyahin ang stream sa Kafka. Lahat ng bagay doon ay naka-synchronize at naka-scale - parehong sa mga tuntunin ng kapasidad at daloy, at, sa teorya, lahat ng iba pang bagay ay pantay, dapat itong kumilos tulad ng produksyon sa mga tuntunin ng mga sukatan. Ang lahat ng posibleng sumasabog ay unang inilalagay sa stand na ito at iniiwan doon ng ilang araw hanggang handa. Ngunit natural, ang solusyon na ito ay mahal, mahirap at may mga non-zero na gastos sa suporta.

Alexey Milovidov: Sasabihin ko sa iyo kung ano ang kapaligiran ng pagsubok ng aming mga kaibigan mula sa Yandex.Metrica. Ang isang kumpol ay may 600-kakaibang mga server, ang isa pa ay may 360, at mayroong pangatlo at ilang mga kumpol. Ang kapaligiran ng pagsubok para sa isa sa mga ito ay dalawang shards lamang na may dalawang replika sa bawat isa. Bakit dalawang shards? Para hindi ka nag-iisa. At dapat may mga replika din. Isang tiyak na minimum na halaga lamang na maaari mong bayaran.

Binibigyang-daan ka ng kapaligiran ng pagsubok na ito na suriin kung gumagana ang iyong mga query at kung may nasira. Ngunit kadalasan ang mga problema ay lumitaw sa isang ganap na naiibang kalikasan, kapag ang lahat ay gumagana, ngunit may ilang maliliit na pagbabago sa pagkarga.

Bigyan kita ng isang halimbawa. Nagpasya kaming mag-install ng bagong bersyon ng ClickHouse. Ito ay nai-post sa isang pagsubok na kapaligiran, ang mga awtomatikong pagsubok ay nakumpleto sa Yandex.Metrica mismo, na naghahambing ng data sa lumang bersyon at sa bago, na nagpapatakbo sa buong pipeline. At siyempre, mga green test ng ating CI. Kung hindi, hindi namin iminumungkahi ang bersyon na ito.

Maayos ang lahat. Nagsisimula na kaming lumipat sa produksyon. Nakatanggap ako ng mensahe na ang pag-load sa mga graph ay tumaas ng ilang beses. Ibinabalik namin ang bersyon. Tinitingnan ko ang graph at nakita ko: ang pag-load ay aktwal na tumaas nang ilang beses sa panahon ng paglulunsad, at bumaba muli noong inilunsad ang mga ito. Pagkatapos ay sinimulan naming ibalik ang bersyon. At ang pagkarga ay tumaas sa parehong paraan at nahulog pabalik sa parehong paraan. Kaya ang konklusyon ay ito: ang pag-load ay tumaas dahil sa layout, walang nakakagulat.

Pagkatapos ay mahirap kumbinsihin ang mga kasamahan na i-install ang bagong bersyon. Sabi ko: “Okay lang, roll out. Panatilihin ang iyong mga daliri crossed, lahat ay gagana. Ngayon ang pagkarga sa mga graph ay tumaas, ngunit ang lahat ay maayos. Mag anatay ka lang dyan." Sa pangkalahatan, ginawa namin ito, at iyon na - ang bersyon ay inilabas para sa produksyon. Ngunit halos sa bawat layout ay lumitaw ang mga katulad na problema.

Ang Kill query ay dapat na pumatay ng mga query, ngunit hindi. Bakit?

Isang user, isang uri ng analyst, ang lumapit sa akin at gumawa ng kahilingan na naglagay ng aking ClickHouse cluster. Ilang node o buong cluster, depende sa kung aling replica o shard napunta ang kahilingan. Nakikita ko na ang lahat ng mga mapagkukunan ng CPU sa server na ito ay nasa isang istante, lahat ay pula. Kasabay nito, ang ClickHouse mismo ay tumutugon sa mga kahilingan. At sumulat ako: "Pakipakita sa akin, listahan ng proseso, kung anong kahilingan ang nakabuo ng kabaliwan na ito."

Nahanap ko ang kahilingang ito at sumulat ng patayin dito. At nakikita kong walang nangyayari. Ang aking server ay nasa isang istante, pagkatapos ay binibigyan ako ng ClickHouse ng ilang mga utos, nagpapakita na ang server ay buhay, at lahat ay mahusay. Ngunit mayroon akong pagkasira sa lahat ng kahilingan ng gumagamit, ang pagkasira ay nagsisimula sa mga tala sa ClickHouse, at ang aking query sa pagpatay ay hindi gumagana. Bakit? Akala ko ang kill query ay dapat na pumatay ng mga query, ngunit hindi.

Ngayon ay magkakaroon ng isang medyo kakaibang sagot. Ang punto ay hindi pinapatay ng kill query ang mga query.

Sinusuri ng Kill query ang isang maliit na kahon na tinatawag na "Gusto kong patayin ang query na ito." At ang kahilingan mismo ay tumitingin sa flag na ito kapag pinoproseso ang bawat bloke. Kung nakatakda ito, hihinto sa paggana ang kahilingan. Ito ay lumiliko na walang pumapatay sa kahilingan, siya mismo ay dapat suriin ang lahat at huminto. At ito ay dapat gumana sa lahat ng mga kaso kung saan ang kahilingan ay nasa estado ng pagproseso ng mga bloke ng data. Ipoproseso nito ang susunod na bloke ng data, suriin ang bandila, at hihinto.

Hindi ito gumagana sa mga kaso kung saan na-block ang kahilingan sa ilang operasyon. Totoo, malamang na hindi ito ang iyong kaso, dahil, ayon sa iyo, gumagamit ito ng isang toneladang mapagkukunan ng server. Posible na hindi ito gumana sa kaso ng panlabas na pag-uuri at sa ilang iba pang mga detalye. Ngunit sa pangkalahatan ay hindi ito dapat mangyari, ito ay isang bug. At ang tanging bagay na maaari kong irekomenda ay i-update ang ClickHouse.

Paano makalkula ang oras ng pagtugon sa ilalim ng pag-load ng pagbabasa?

Mayroong isang talahanayan na nag-iimbak ng mga pinagsama-samang item - iba't ibang mga counter. Ang bilang ng mga linya ay humigit-kumulang isang daang milyon. Posible bang umasa sa isang predictable response time kung magbubuhos ka ng 1K RPS para sa 1K na item?

Sa paghusga sa konteksto, pinag-uusapan natin ang pag-load ng pagbabasa, dahil walang mga problema sa pagsulat - kahit isang libo, kahit isang daang libo, at kung minsan ilang milyong mga hilera ang maaaring maipasok.

Ang mga kahilingan sa pagbabasa ay ibang-iba. Sa piling 1, ang ClickHouse ay maaaring magsagawa ng halos sampu-sampung libong mga kahilingan sa bawat segundo, kaya kahit na ang mga kahilingan para sa isang susi ay mangangailangan na ng ilang mga mapagkukunan. At ang mga naturang puntong query ay magiging mas mahirap kaysa sa ilang mga database ng key-value, dahil para sa bawat pagbabasa kinakailangan na basahin ang isang bloke ng data ayon sa index. Ang aming index ay hindi tumutugon sa bawat tala, ngunit sa bawat hanay. Ibig sabihin, kakailanganin mong basahin ang buong hanay - ito ay 8192 na linya bilang default. At kakailanganin mong i-decompress ang naka-compress na bloke ng data mula 64 KB hanggang 1 MB. Karaniwan, ang mga naturang naka-target na query ay tumatagal ng ilang millisecond upang makumpleto. Ngunit ito ang pinakasimpleng opsyon.

Subukan natin ang ilang simpleng aritmetika. Kung magpaparami ka ng ilang millisecond sa isang libo, makakakuha ka ng ilang segundo. Para bang imposibleng makasabay sa isang libong kahilingan sa bawat segundo, ngunit sa katunayan posible, dahil mayroon kaming ilang mga core ng processor. Kaya, sa prinsipyo, minsan ang ClickHouse ay maaaring humawak ng 1000 RPS, ngunit para sa mga maikling kahilingan, partikular na naka-target.

Kung kailangan mong sukatin ang isang ClickHouse cluster sa pamamagitan ng bilang ng mga simpleng kahilingan, pagkatapos ay inirerekomenda ko ang pinakasimpleng bagay - dagdagan ang bilang ng mga replika at magpadala ng mga kahilingan sa isang random na replika. Kung ang isang replika ay mayroong limang daang kahilingan sa bawat segundo, na ganap na makatotohanan, pagkatapos ay tatlong replika ang hahawak ng isa at kalahating libo.

Minsan, siyempre, maaari mong i-configure ang ClickHouse para sa maximum na bilang ng mga point reading. Ano ang kailangan para dito? Ang una ay upang bawasan ang granularity ng index. Sa kasong ito, hindi ito dapat bawasan sa isa, ngunit sa batayan na ang bilang ng mga entry sa index ay magiging ilang milyon o sampu-sampung milyon bawat server. Kung ang talahanayan ay may isang daang milyong row, ang granularity ay maaaring itakda sa 64.

Maaari mong bawasan ang laki ng naka-compress na bloke. May mga setting para dito min compress block size, max na sukat ng bloke ng compress. Maaaring bawasan ang mga ito, mapunan muli ng data, at pagkatapos ay magiging mas mabilis ang mga naka-target na query. Ngunit gayon pa man, ang ClickHouse ay hindi isang database ng key-value. Ang isang malaking bilang ng mga maliliit na kahilingan ay isang load antipattern.

Kirill Shvakov: Magbibigay ako ng payo kung sakaling may mga ordinaryong account doon. Ito ay isang medyo karaniwang sitwasyon kapag ang ClickHouse ay nag-iimbak ng ilang uri ng counter. Mayroon akong isang gumagamit, siya ay mula sa ganito at ganoong bansa, at ilang ikatlong larangan, at kailangan kong dagdagan ang isang bagay nang paunti-unti. Kunin ang MySQL, gumawa ng isang natatanging key - sa MySQL ito ay isang duplicate na key, at sa PostgreSQL ito ay isang salungatan - at magdagdag ng isang plus sign. Ito ay gagana nang mas mahusay.

Kapag wala kang gaanong data, walang gaanong punto sa paggamit ng ClickHouse. Mayroong mga regular na database at ginagawa nila ito nang maayos.

Ano ang maaari kong i-tweak sa ClickHouse para mas maraming data ang nasa cache?

Isipin natin ang isang sitwasyon - ang mga server ay may 256 GB ng RAM, sa pang-araw-araw na gawain ng ClickHouse ay tumatagal ng mga 60-80 GB, sa peak - hanggang sa 130. Ano ang maaaring paganahin at i-tweake upang mas maraming data ang nasa cache at, nang naaayon, may mas kaunting mga biyahe sa disk?

Karaniwan, ang cache ng pahina ng operating system ay gumagawa ng magandang trabaho nito. Kung bubuksan mo lang ang tuktok, tumingin doon na naka-cache o libre - sinasabi rin nito kung magkano ang naka-cache - pagkatapos ay makikita mo na ang lahat ng libreng memorya ay ginagamit para sa cache. At kapag binabasa ang data na ito, mababasa ito hindi mula sa disk, ngunit mula sa RAM. Kasabay nito, masasabi kong epektibong ginagamit ang cache dahil ito ang naka-compress na data na naka-cache.

Gayunpaman, kung gusto mong pabilisin pa ang ilang simpleng query, posibleng paganahin ang cache sa na-decompress na data sa loob ng ClickHouse. Ito ay tinatawag na hindi naka-compress na cache. Sa config.xml configuration file, itakda ang hindi naka-compress na laki ng cache sa halaga na kailangan mo - Inirerekomenda ko ang hindi hihigit sa kalahati ng libreng RAM, dahil ang iba ay mapupunta sa ilalim ng cache ng pahina.

Bilang karagdagan, mayroong dalawang mga setting ng antas ng kahilingan. Unang setting - gumamit ng hindi naka-compress na cache - kasama ang paggamit nito. Inirerekomenda na paganahin ito para sa lahat ng mga kahilingan, maliban sa mga mabibigat, na maaaring basahin ang lahat ng data at i-flush ang cache. At ang pangalawang setting ay katulad ng maximum na bilang ng mga linya upang magamit ang cache. Awtomatiko nitong nililimitahan ang malalaking query upang ma-bypass nila ang cache.

Paano ko mai-configure ang storage_configuration para sa storage sa RAM?

Sa bagong dokumentasyon ng ClickHouse nabasa ko ang kaugnay na seksyon na may imbakan ng data. Ang paglalarawan ay naglalaman ng isang halimbawa na may mabilis na SSD.

Nagtataka ako kung paano mai-configure ang parehong bagay sa dami ng mainit na memorya. At isa pang tanong. Paano gumagana ang pagpili sa organisasyong ito ng data, babasahin ba nito ang buong set o ang isa lang na nasa disk, at naka-compress ba ang data na ito sa memorya? At paano gumagana ang prewhere na seksyon sa naturang organisasyon ng data?

Ang setting na ito ay nakakaapekto sa pag-iimbak ng mga data chunks, at ang kanilang format ay hindi nagbabago sa anumang paraan.
Tingnan natin nang maigi.

Maaari mong i-configure ang imbakan ng data sa RAM. Ang lahat ng na-configure para sa disk ay ang landas nito. Gumawa ka ng tmpfs partition na naka-mount sa ilang path sa file system. Tinukoy mo ang landas na ito bilang landas para sa pag-iimbak ng data para sa pinakamainit na partisyon, ang mga piraso ng data ay nagsisimulang dumating at nakasulat doon, lahat ay maayos.

Ngunit hindi ko inirerekomenda na gawin ito dahil sa mababang pagiging maaasahan, kahit na kung mayroon kang hindi bababa sa tatlong mga replika sa iba't ibang mga sentro ng data, posible ito. Kung may mangyari, maibabalik ang data. Isipin natin na ang server ay biglang na-off at na-on muli. Na-mount muli ang partition, ngunit wala doon. Kapag nagsimula ang ClickHouse server, nakikita nito na wala itong mga pirasong ito, bagaman, ayon sa metadata ng ZooKeeper, dapat nandoon sila. Tinitingnan niya kung aling mga replika ang mayroon nito, hinihiling ang mga ito at dina-download ang mga ito. Sa ganitong paraan maibabalik ang data.

Sa ganitong kahulugan, ang pag-iimbak ng data sa RAM ay hindi pangunahing naiiba sa pag-iimbak nito sa disk, dahil kapag ang data ay isinulat sa disk, ito rin ay unang nagtatapos sa cache ng pahina at pisikal na nakasulat sa ibang pagkakataon. Depende ito sa opsyon sa pag-mount ng file system. Ngunit kung sakali, sasabihin ko na ang ClickHouse ay hindi nag-fsync kapag nagpasok.

Sa kasong ito, ang data sa RAM ay naka-imbak sa eksaktong parehong format tulad ng sa disk. Ang piling query sa parehong paraan ay pinipili ang mga piraso na kailangang basahin, pinipili ang mga kinakailangang hanay ng data sa mga piraso, at binabasa ang mga ito. At ang prewhere ay gumagana nang eksakto pareho, hindi alintana kung ang data ay nasa RAM o sa disk.

Hanggang sa anong bilang ng mga natatanging halaga ang epektibong Low Cardinality?

Ang Low Cardinality ay matalinong idinisenyo. Nag-compile ito ng mga diksyunaryo ng data, ngunit lokal ang mga ito. Una, mayroong iba't ibang mga diksyunaryo para sa bawat piraso, at pangalawa, kahit na sa loob ng isang piraso maaari silang maging iba para sa bawat hanay. Kapag ang bilang ng mga natatanging halaga ay umabot sa isang threshold na numero—isang milyon, sa palagay ko—ang diksyonaryo ay ini-shelve lang at gumawa ng bago.

Ang sagot ay sa pangkalahatan: para sa bawat lokal na hanay - sabihin, para sa bawat araw - sa isang lugar hanggang sa isang milyong natatanging halaga ay epektibo ang Low Cardinality. Pagkatapos ay magkakaroon lamang ng isang fallback, kung saan maraming iba't ibang mga diksyunaryo ang gagamitin, at hindi lamang isa. Ito ay gagana nang humigit-kumulang kapareho ng isang regular na hanay ng string, marahil ay medyo hindi gaanong mahusay, ngunit hindi magkakaroon ng malubhang pagkasira ng pagganap.

Ano ang mga pinakamahusay na kagawian para sa full-text na paghahanap sa isang talahanayan na may limang bilyong row?

Mayroong iba't ibang mga sagot. Ang una ay ang sabihin na ang ClickHouse ay hindi isang full-text na search engine. Mayroong mga espesyal na sistema para dito, halimbawa, Elasticsearch и Sphinx. Gayunpaman, lalo kong nakikita ang mga tao na nagsasabing sila ay lumilipat mula sa Elasticsearch patungo sa ClickHouse.

Bakit ito nangyayari? Ipinaliwanag nila ito sa pamamagitan ng katotohanan na ang Elasticsearch ay huminto sa pag-load sa ilang mga volume, simula sa pagtatayo ng mga index. Masyadong mahirap ang mga index, at kung ililipat mo lang ang data sa ClickHouse, lumalabas na naiimbak ang mga ito nang maraming beses nang mas mahusay sa mga tuntunin ng dami. Kasabay nito, ang mga query sa paghahanap ay madalas na hindi tulad na kinakailangan upang makahanap ng ilang parirala sa buong dami ng data, na isinasaalang-alang ang morpolohiya, ngunit ganap na naiiba. Halimbawa, maghanap ng ilang kasunod na byte sa mga log sa nakalipas na ilang oras.

Sa kasong ito, lumikha ka ng isang index sa ClickHouse, ang unang field kung saan ay ang petsa at oras. At ang pinakamalaking data cut-off ay ibabatay sa hanay ng petsa. Sa loob ng napiling hanay ng petsa, bilang panuntunan, posible nang magsagawa ng buong-text na paghahanap, kahit na gamit ang brute force na paraan gamit ang like. Ang katulad na operator sa ClickHouse ay ang pinaka mahusay na tulad ng operator na mahahanap mo. Kung nakakita ka ng mas mahusay, sabihin sa akin.

Ngunit gayon pa man, tulad ng isang buong pag-scan. At ang buong pag-scan ay maaaring mabagal hindi lamang sa CPU, kundi pati na rin sa disk. Kung biglang mayroon kang isang terabyte ng data bawat araw, at maghanap ka ng isang salita sa araw, kakailanganin mong i-scan ang terabyte. At malamang na nasa mga regular na hard drive ito, at sa huli ay mai-load ang mga ito sa paraang hindi mo maa-access ang server na ito sa pamamagitan ng SSH.

Sa kasong ito, handa akong mag-alok ng isa pang maliit na trick. Ito ay pang-eksperimento - maaaring gumana, maaaring hindi. Ang ClickHouse ay may mga full-text index sa anyo ng mga trigram na mga filter ng Bloom. Sinubukan na ng aming mga kasamahan sa Arenadata ang mga index na ito, at madalas na gumagana ang mga ito nang eksakto tulad ng nilalayon.

Upang magamit nang tama ang mga ito, dapat kang magkaroon ng isang mahusay na pag-unawa sa eksakto kung paano gumagana ang mga ito: kung ano ang isang trigram na Bloom filter at kung paano piliin ang laki nito. Masasabi kong makakatulong sila para sa mga query sa ilang bihirang parirala, mga substring na bihirang makita sa data. Sa kasong ito, ang mga subrange ay pipiliin ng mga index at mas kaunting data ang mababasa.

Kamakailan, ang ClickHouse ay nagdagdag ng higit pang mga advanced na function para sa paghahanap ng buong teksto. Ito ay, una, isang paghahanap para sa isang grupo ng mga substring nang sabay-sabay sa isang pass, kabilang ang mga opsyon na case-sensitive, case-insensitive, na may suporta para sa UTF-8 o para lamang sa ASCII. Piliin ang pinaka-epektibong kailangan mo.

Ang paghahanap para sa maramihang mga regular na expression sa isang pass ay lumitaw din. Hindi mo kailangang isulat ang X tulad ng isang substring o X tulad ng isa pang substring. Sumulat ka kaagad, at lahat ay ginagawa nang mahusay hangga't maaari.

Pangatlo, mayroon na ngayong tinatayang paghahanap para sa mga regexp at tinatayang paghahanap para sa mga substring. Kung may maling spelling ng salita, hahanapin ito para sa maximum na tugma.

Ano ang pinakamahusay na paraan upang ayusin ang pag-access sa ClickHouse para sa isang malaking bilang ng mga gumagamit?

Sabihin sa amin kung paano pinakamahusay na ayusin ang access para sa isang malaking bilang ng mga consumer at analyst. Paano bumuo ng queue, unahin ang max concurrent query, at gamit ang anong mga tool?

Kung ang kumpol ay sapat na malaki, kung gayon ang isang magandang solusyon ay ang pagtaas ng dalawa pang server, na magiging entry point para sa mga analyst. Iyon ay, huwag payagan ang mga analyst na ma-access ang mga partikular na shards sa cluster, ngunit lumikha lamang ng dalawang walang laman na server, nang walang data, at i-configure ang mga karapatan sa pag-access sa mga ito. Sa kasong ito, ang mga setting ng user para sa mga ipinamamahaging kahilingan ay inililipat sa mga malalayong server. Ibig sabihin, iko-configure mo ang lahat sa dalawang server na ito, at may epekto ang mga setting sa buong cluster.

Sa prinsipyo, ang mga server na ito ay walang data, ngunit ang halaga ng RAM sa kanila ay napakahalaga para sa pagpapatupad ng mga kahilingan. Ang disk ay maaari ding gamitin para sa pansamantalang data kung ang panlabas na pagsasama-sama o panlabas na pag-uuri ay pinagana.

Mahalagang tingnan ang mga setting na nauugnay sa lahat ng posibleng limitasyon. Kung pupunta ako ngayon sa cluster ng Yandex.Metrica bilang isang analyst at humingi ng kahilingan piliin ang bilang mula sa mga hit, pagkatapos ay bibigyan ako kaagad ng isang pagbubukod na hindi ko maisagawa ang kahilingan. Ang maximum na bilang ng mga row na pinapayagan akong i-scan ay isang daang bilyon, at sa kabuuan mayroong limampung trilyon sa mga ito sa isang talahanayan sa cluster. Ito ang unang limitasyon.

Sabihin nating inalis ko ang limitasyon ng row at muling patakbuhin ang query. Pagkatapos ay makikita ko ang sumusunod na pagbubukod - pinagana ang setting force index ayon sa petsa. Hindi ko makumpleto ang query kung hindi ako tumukoy ng hanay ng petsa. Hindi mo kailangang umasa sa mga analyst upang manu-manong tukuyin ito. Ang isang karaniwang kaso ay kapag ang isang hanay ng petsa ay nakasulat kung saan ang petsa ng kaganapan sa pagitan ng linggo. At pagkatapos ay tinukoy lang nila ang isang bracket sa maling lugar, at sa halip na at ito ay naging o - o tugma ng URL. Kung walang limitasyon, iko-crawl nito ang column ng URL at mag-aaksaya lamang ng isang toneladang mapagkukunan.

Bilang karagdagan, ang ClickHouse ay may dalawang priyoridad na setting. Sa kasamaang palad, sila ay napaka-primitive. Simple lang ang tawag sa isa karapatang mauna. Kung ang priyoridad ≠ 0, at ang mga kahilingan na may ilang priyoridad ay isinasagawa, ngunit ang isang kahilingan na may priyoridad na halaga na mas mababa sa, na nangangahulugang mas mataas ang priyoridad, ay isinasagawa, pagkatapos ay isang kahilingan na may priyoridad na halaga na mas malaki, na nangangahulugang mas mababang priyoridad , ay sinuspinde lang at hindi gagana sa panahong ito.

Ito ay isang napaka-krudong setting at hindi angkop para sa mga kaso kung saan ang cluster ay may pare-parehong pagkarga. Ngunit kung mayroon kang maikli, mapusok na mga kahilingan na mahalaga, at halos walang ginagawa ang cluster, angkop ang setup na ito.

Ang susunod na setting ng priyoridad ay tinatawag Priyoridad ng OS thread. Itinatakda lamang nito ang magandang halaga para sa lahat ng mga thread ng pagpapatupad ng kahilingan para sa Linux scheduler. Gumagana ito, ngunit gumagana pa rin. Kung itinakda mo ang pinakamababang magandang halaga - ito ang pinakamalaki sa halaga, at samakatuwid ang pinakamababang priyoridad - at itinakda -19 para sa mga kahilingang may mataas na priyoridad, ang CPU ay kukuha ng mga kahilingang mababa ang priyoridad nang halos apat na beses na mas mababa kaysa sa mga may mataas na priyoridad.

Kailangan mo ring i-configure ang maximum na oras ng pagpapatupad ng kahilingan - sabihin, limang minuto. Ang pinakamababang bilis ng pagsasagawa ng query ay ang pinaka-cool na bagay. Ang setting na ito ay nasa loob ng mahabang panahon, at ito ay kinakailangan hindi lamang upang igiit na ang ClickHouse ay hindi nagpapabagal, ngunit upang pilitin ito.

Isipin, nag-set up ka: kung ang ilang query ay nagpoproseso ng wala pang isang milyong row bawat segundo, hindi mo magagawa iyon. Sinisiraan nito ang ating magandang pangalan, ang ating magandang database. Ipagbawal na lang natin ito. May dalawang setting talaga. Tinatawag ang isa min bilis ng execution - sa mga linya bawat segundo, at ang pangalawa ay tinatawag na timeout bago suriin ang min na bilis ng pagpapatupad - labinlimang segundo bilang default. Iyon ay, labinlimang segundo ay posible, at pagkatapos, kung ito ay mabagal, pagkatapos ay magtapon lamang ng isang pagbubukod at i-abort ang kahilingan.

Kailangan mo ring mag-set up ng mga quota. Ang ClickHouse ay may built-in na tampok na quota na binibilang ang pagkonsumo ng mapagkukunan. Ngunit, sa kasamaang-palad, hindi mga mapagkukunan ng hardware tulad ng CPU, mga disk, ngunit mga lohikal - ang bilang ng mga naprosesong kahilingan, mga linya at byte na nabasa. At maaari mong i-configure, halimbawa, ang maximum na isang daang kahilingan sa loob ng limang minuto at isang libong kahilingan kada oras.

Bakit ito mahalaga? Dahil ang ilang mga query sa analytics ay manu-manong isasagawa nang direkta mula sa kliyente ng ClickHouse. At magiging maayos din ang lahat. Ngunit kung mayroon kang mga advanced na analyst sa iyong kumpanya, susulat sila ng isang script, at maaaring may error sa script. At ang error na ito ay magiging sanhi ng kahilingan na maisakatuparan sa isang walang katapusang loop. Ito ang kailangan nating protektahan ang ating sarili.

Posible bang ibigay ang mga resulta ng isang query sa sampung kliyente?

Mayroon kaming ilang user na gustong pumasok na may napakalaking kahilingan sa parehong oras. Ang kahilingan ay malaki at, sa prinsipyo, ay naisakatuparan nang mabilis, ngunit dahil sa ang katunayan na mayroong maraming mga naturang kahilingan sa parehong oras, ito ay nagiging napakasakit. Posible bang isagawa ang parehong kahilingan, na dumating nang sampung beses sa isang hilera, isang beses, at ibigay ang resulta sa sampung kliyente?

Ang problema ay wala kaming mga resulta ng cache o cache ng intermediate data. Mayroong isang cache ng pahina ng operating system, na pumipigil sa iyo na basahin muli ang data mula sa disk, ngunit, sa kasamaang-palad, ang data ay made-decompress, deserialized at muling iproseso.

Gusto kong iwasan ito kahit papaano, alinman sa pamamagitan ng pag-cache ng intermediate na data, o sa pamamagitan ng pag-linya ng mga katulad na query sa ilang uri ng pila at pagdaragdag ng cache ng mga resulta. Kasalukuyan kaming may isang pull request sa pag-develop na nagdaragdag ng cache ng kahilingan, ngunit para lamang sa mga subquery sa in at sumali na mga seksyon - iyon ay, ang solusyon ay hindi kumpleto.

Gayunpaman, nahaharap din tayo sa ganitong sitwasyon. Ang isang partikular na kanonikal na halimbawa ay paginated query. Mayroong isang ulat, mayroon itong ilang mga pahina, at mayroong isang kahilingan para sa limitasyon 10. Pagkatapos ay ang parehong bagay, ngunit limitahan ang 10,10. Pagkatapos ay isa pang susunod na pahina. At ang tanong, bakit natin binibilang ang lahat ng ito sa bawat oras? Ngunit ngayon ay walang solusyon, at walang paraan upang maiwasan ito.

Mayroong alternatibong solusyon na inilalagay bilang sidecar sa tabi ng ClickHouse - ClickHouse Proxy.

Kirill Shvakov: Ang ClickHouse Proxy ay may built-in na rate limiter at isang built-in na cache ng mga resulta. Maraming mga setting ang ginawa doon dahil ang isang katulad na problema ay nalulutas. Binibigyang-daan ka ng proxy na limitahan ang mga kahilingan sa pamamagitan ng pagpila sa kanila at i-configure kung gaano katagal nabubuhay ang cache ng kahilingan. Kung talagang pareho ang mga kahilingan, ipapadala sila ng Proxy nang maraming beses, ngunit isang beses lang mapupunta sa ClickHouse.

Ang Nginx ay mayroon ding cache sa libreng bersyon, at gagana rin ito. Ang Nginx ay mayroon ding mga setting na kung ang mga kahilingan ay dumating sa parehong oras, ito ay magpapabagal sa iba hanggang sa makumpleto ang isa. Ngunit nasa ClickHouse Proxy na ang pag-setup ay ginagawa nang mas mahusay. Partikular itong ginawa para sa ClickHouse, partikular para sa mga kahilingang ito, kaya mas angkop ito. Well, madali itong i-install.

Paano ang tungkol sa mga asynchronous na operasyon at materialized na view?

Mayroong problema na ang mga operasyon sa replay engine ay asynchronous - una ang data ay nakasulat, pagkatapos ay nag-collapse. Kung ang isang materyalized na tablet na may ilang mga pinagsama-sama ay nakatira sa ilalim ng karatula, ang mga duplicate ay isusulat dito. At kung walang kumplikadong lohika, ang data ay madodoble. Ano ang maaari mong gawin tungkol dito?

Mayroong isang malinaw na solusyon - upang ipatupad ang isang trigger sa isang tiyak na klase ng mga matview sa panahon ng isang asynchronous na operasyon ng pagbagsak. Mayroon bang anumang mga pilak na bala o mga plano upang ipatupad ang katulad na pag-andar?

Ito ay nagkakahalaga ng pag-unawa kung paano gumagana ang deduplication. Ang sasabihin ko sa iyo ngayon ay hindi nauugnay sa tanong, ngunit kung sakaling ito ay nagkakahalaga ng pag-alala.

Kapag nagpapasok sa isang kinokopyang talahanayan, mayroong deduplikasyon ng buong ipinasok na mga bloke. Kung muling ilalagay mo ang parehong bloke na naglalaman ng parehong bilang ng parehong mga hilera sa parehong pagkakasunud-sunod, ang data ay aalisin ng duplicate. Makakatanggap ka ng "Ok" bilang tugon sa pagpasok, ngunit sa katunayan isang packet ng data ang isusulat, at hindi ito madodoble.

Ito ay kinakailangan para sa katiyakan. Kung nakatanggap ka ng "Ok" sa panahon ng pagpapasok, kung gayon ang iyong data ay naipasok na. Kung nakatanggap ka ng error mula sa ClickHouse, nangangahulugan ito na hindi sila naipasok at kailangan mong ulitin ang pagpasok. Ngunit kung ang koneksyon ay nasira sa panahon ng pagpapasok, hindi mo alam kung ang data ay ipinasok o hindi. Ang tanging pagpipilian ay ulitin muli ang pagpapasok. Kung ang data ay talagang ipinasok at muli mo itong ipinasok, mayroong block deduplication. Ito ay kinakailangan upang maiwasan ang mga duplicate.

At mahalaga din kung paano ito gumagana para sa mga materyal na pananaw. Kung ang data ay na-deduplicate kapag ipinasok sa pangunahing talahanayan, hindi rin ito mapupunta sa materialized na view.

Ngayon tungkol sa tanong. Ang iyong sitwasyon ay mas kumplikado dahil nagre-record ka ng mga duplicate ng mga indibidwal na linya. Ibig sabihin, hindi ang buong pack ang nadoble, ngunit mga partikular na linya, at bumagsak ang mga ito sa background. Sa katunayan, ang data ay babagsak sa pangunahing talahanayan, ngunit ang hindi na-collapse na data ay mapupunta sa materialized na view, at sa panahon ng mga pagsasanib ay walang mangyayari sa mga materialized na view. Dahil ang isang materialized na view ay walang iba kundi isang insert trigger. Sa ibang mga operasyon, walang karagdagang mangyayari dito.

At hindi kita mapasaya dito. Kailangan mo lang maghanap ng partikular na solusyon para sa kasong ito. Halimbawa, posible bang i-replay ito sa isang materialized na view, at ang paraan ng deduplication ay maaaring gumana sa parehong paraan. Ngunit sa kasamaang palad, hindi palaging. Kung ito ay pinagsama-sama, hindi ito gagana.

Kirill Shvakov: Nagkaroon din kami ng crutch construction noong araw. Nagkaroon ng problema na mayroong mga impression sa advertising, at mayroong ilang data na maaari naming ipakita sa real time - ito ay mga impression lamang. Bihirang madoble ang mga ito, ngunit kung mangyari ito, ibabagsak natin ang mga ito sa ibang pagkakataon. At may mga bagay na hindi ma-duplicate - mga pag-click at ang buong kwentong ito. Ngunit gusto ko ring ipakita sa kanila halos kaagad.

Paano ginawa ang mga materyal na pananaw? May mga view kung saan ito ay direktang isinulat - ito ay isinulat sa raw data, at isinulat sa mga view. Doon, sa ilang mga punto ang data ay hindi masyadong tama, ito ay nadoble, at iba pa. At mayroong pangalawang bahagi ng talahanayan, kung saan ang hitsura nila ay eksaktong kapareho ng mga materyal na pananaw, iyon ay, sila ay ganap na magkapareho sa istraktura. Paminsan-minsan ay muling kinakalkula namin ang data, binibilang ang data nang walang mga duplicate, sumulat sa mga talahanayang iyon.

Dumaan kami sa API - hindi ito gagana sa ClickHouse nang manu-mano. At ang hitsura ng API: kapag mayroon akong petsa ng huling pagdaragdag sa talahanayan, kung saan ginagarantiyahan na ang tamang data ay nakalkula na, at humiling ito sa isang talahanayan at sa isa pang talahanayan. Mula sa isa ang kahilingan ay pipili ng hanggang sa isang tiyak na tagal ng oras, at mula sa isa pa ay nakukuha nito ang hindi pa nakalkula. At ito ay gumagana, ngunit hindi sa pamamagitan ng ClickHouse lamang.

Kung mayroon kang ilang uri ng API - para sa mga analyst, para sa mga user - kung gayon, sa prinsipyo, ito ay isang opsyon. Lagi kang nagbibilang, laging nagbibilang. Ito ay maaaring gawin isang beses sa isang araw o sa ibang pagkakataon. Pumili ka para sa iyong sarili ng isang hanay na hindi mo kailangan at hindi kritikal.

Ang ClickHouse ay may maraming log. Paano ko makikita ang lahat ng nangyayari sa server sa isang sulyap?

Ang ClickHouse ay may napakalaking bilang ng iba't ibang mga log, at ang bilang na ito ay tumataas. Sa mga bagong bersyon, ang ilan sa mga ito ay pinagana pa nga bilang default; sa mga mas lumang bersyon ay dapat na pinagana ang mga ito kapag nag-a-update. Gayunpaman, mayroong higit at higit pa sa kanila. Sa huli, gusto kong makita kung ano ang nangyayari sa aking server ngayon, marahil sa ilang uri ng dashboard ng buod.

Mayroon ka bang ClickHouse team, o mga team ng iyong mga kaibigan, na sumusuporta sa ilang functionality ng mga yari na dashboard na magpapakita sa mga log na ito bilang isang tapos na produkto? Sa huli, ang pagtingin lamang sa mga log sa ClickHouse ay mahusay. Ngunit ito ay magiging napaka-cool kung ito ay handa na sa anyo ng isang dashboard. Mapapatalsik sana ako dito.

May mga dashboard, bagama't hindi sila standardized. Sa aming kumpanya, humigit-kumulang 60 team ang gumagamit ng ClickHouse, at ang kakaiba ay marami sa kanila ang may mga dashboard na ginawa nila para sa kanilang sarili, at medyo naiiba. Gumagamit ang ilang team ng panloob na pag-install ng Yandex.Cloud. Mayroong ilang mga nakahanda nang ulat, bagaman hindi lahat ng kailangan. Ang iba ay may kanya-kanyang sarili.

Ang aking mga kasamahan mula sa Metrica ay may sariling dashboard sa Grafana, at mayroon akong sarili para sa kanilang cluster. Tinitingnan ko ang mga bagay tulad ng cache hit para sa serif cache. At ang mas mahirap ay gumamit tayo ng iba't ibang mga tool. Ginawa ko ang aking dashboard gamit ang isang napakalumang tool na tinatawag na Graphite-web. Ang pangit niya talaga. At ginagamit ko pa rin ito sa ganitong paraan, kahit na ang Grafana ay malamang na mas maginhawa at maganda.

Ang pangunahing bagay sa mga dashboard ay pareho. Ito ang mga sukatan ng system para sa cluster: CPU, memorya, disk, network. Iba pa - bilang ng mga sabay-sabay na kahilingan, bilang ng sabay-sabay na pagsasama, bilang ng mga kahilingan sa bawat segundo, maximum na bilang ng mga chunks para sa mga partisyon ng talahanayan ng MergeTree, lag ng pagtitiklop, laki ng pila ng pagtitiklop, bilang ng mga ipinasok na row sa bawat segundo, bilang ng mga ipinasok na bloke bawat segundo. Ito lang ang nakuha hindi mula sa mga log, ngunit mula sa mga sukatan.

Vladimir Kolobaev: Alexey, nais kong itama ito ng kaunti. Mayroong Grafana. Ang Grafana ay may datasource, na ClickHouse. Iyon ay, maaari akong gumawa ng mga kahilingan mula sa Grafana nang direkta sa ClickHouse. Ang ClickHouse ay may isang talahanayan na may mga log, ito ay pareho para sa lahat. Bilang resulta, gusto kong i-access ang log table na ito sa Grafana at makita ang mga kahilingan na ginagawa ng aking server. Magiging mahusay na magkaroon ng isang dashboard na tulad nito.

Ako mismo ang nagbike. Ngunit mayroon akong tanong - kung ang lahat ay na-standardize, at ang Grafana ay ginagamit ng lahat, bakit walang opisyal na dashboard ang Yandex?

Kirill Shvakov: Sa katunayan, ang datasource na napupunta sa ClickHouse ay sumusuporta na ngayon sa Altinity. At gusto ko lang magbigay ng vector kung saan maghukay at kung sino ang itutulak. Maaari mong tanungin sila, dahil ang Yandex ay gumagawa pa rin ng ClickHouse, at hindi ang kuwento sa paligid nito. Ang Altinity ay ang pangunahing kumpanya na kasalukuyang nagpo-promote ng ClickHouse. Hindi nila siya pababayaan, ngunit susuportahan siya. Dahil, sa prinsipyo, upang mag-upload ng isang dashboard sa website ng Grafana, kailangan mo lamang magrehistro at mag-upload nito - walang mga espesyal na problema.

Alexey Milovidov: Sa nakalipas na taon, nagdagdag ang ClickHouse ng maraming kakayahan sa pag-profile ng query. May mga sukatan para sa bawat kahilingan sa paggamit ng mapagkukunan. At kamakailan lang, nagdagdag kami ng mas mababang antas ng query profiler upang makita kung saan gumagastos ang isang query bawat millisecond. Ngunit upang magamit ang pagpapaandar na ito, kailangan kong buksan ang console client at mag-type ng isang kahilingan, na lagi kong nakakalimutan. Nai-save ko ito sa isang lugar at patuloy na nakakalimutan kung saan eksakto.

Nais kong mayroong isang tool na nagsabi lang, narito ang iyong mga mabibigat na query, na naka-grupo ayon sa klase ng query. Pinindot ko ang isa, at sasabihin nila sa akin na iyon ang dahilan kung bakit ito mabigat. Wala nang ganyang solusyon ngayon. At talagang kakaiba na kapag tinanong ako ng mga tao: "Sabihin mo sa akin, mayroon bang anumang mga handa na dashboard para sa Grafana?", Sabi ko: "Pumunta sa website ng Grafana, mayroong isang "Dashboard" na komunidad, at mayroong isang dashboard mula sa Dimka, mayroong isang dashboard mula sa Kostyan. Hindi ko alam kung ano ito, hindi ko ito ginamit sa aking sarili."

Paano maimpluwensyahan ang mga pagsasanib upang ang server ay hindi bumagsak sa OOM?

Mayroon akong isang talahanayan, mayroon lamang isang partition sa talahanayan, ito ay ang ReplacingMergeTree. Apat na taon na akong nagsusulat ng data dito. Kailangan kong gumawa ng pagbabago dito at magtanggal ng ilang data.

Ginawa ko ito, at sa panahon ng pagproseso ng kahilingang ito, naubos ang lahat ng memorya sa lahat ng server sa cluster, at lahat ng server sa cluster ay napunta sa OOM. Pagkatapos ay bumangon silang lahat, nagsimulang pagsamahin ang parehong operasyon, ang data block na ito, at muling nahulog sa OOM. Tapos bumangon ulit sila at bumagsak ulit. At ang bagay na ito ay hindi tumigil.

Pagkatapos ay lumabas na ito ay talagang isang bug na naayos ng mga lalaki. Ito ay napaka-cool, maraming salamat. Ngunit nanatili ang isang nalalabi. At ngayon, kapag iniisip kong gumawa ng ilang uri ng pagsasanib sa talahanayan, mayroon akong tanong - bakit hindi ko maimpluwensyahan ang mga pagsasanib na ito? Halimbawa, limitahan ang mga ito sa dami ng kinakailangang RAM, o, sa prinsipyo, sa halagang magpoproseso sa partikular na talahanayang ito.

Mayroon akong talahanayan na tinatawag na "Mga Sukatan", mangyaring iproseso ito para sa akin sa dalawang thread. Hindi na kailangang lumikha ng sampu o limang pagsasanib nang magkatulad, gawin ito sa dalawa. Sa tingin ko ay mayroon akong sapat na memorya para sa dalawa, ngunit maaaring hindi ito sapat upang iproseso ang sampu. Bakit nananatili ang takot? Dahil lumalaki ang talahanayan, at balang araw ay haharap ako sa isang sitwasyon na, sa prinsipyo, ay hindi na dahil sa isang bug, ngunit dahil ang data ay magbabago sa napakalaking halaga na ako ay hindi magkakaroon ng sapat na memorya sa server. At pagkatapos ay mag-crash ang server sa OOM kapag pinagsama. Bukod dito, maaari kong kanselahin ang mutation, ngunit wala na si Merji.

Alam mo, kapag pinagsama, ang server ay hindi mahuhulog sa OOM, dahil kapag pinagsama, ang halaga ng RAM ay ginagamit lamang para sa isang maliit na hanay ng data. Kaya magiging maayos ang lahat anuman ang dami ng data.

Vladimir Kolobaev: ayos lang. Narito ang sandali ay tulad na pagkatapos na maayos ang bug, nag-download ako ng isang bagong bersyon para sa aking sarili, at sa isa pang talahanayan, isang mas maliit, kung saan maraming mga partisyon, nagsagawa ako ng katulad na operasyon. At sa panahon ng pagsasama, halos 100 GB ng RAM ang nasunog sa server. Mayroon akong 150 okupado, 100 ang kumain, at isang 50 GB na window ang natitira, kaya hindi ako nahulog sa OOM.

Ano ang kasalukuyang nagpoprotekta sa akin mula sa pagkahulog sa OOM kung talagang kumonsumo ito ng 100 GB ng RAM? Ano ang gagawin kung biglang naubos ang RAM sa mga merge?

Alexey Milovidov: Mayroong ganoong problema na ang pagkonsumo ng RAM partikular para sa pagsasama ay hindi limitado. At ang pangalawang problema ay kung ang ilang uri ng pagsasanib ay naitalaga, dapat itong maisakatuparan dahil ito ay naitala sa log ng pagtitiklop. Ang replication log ay ang mga aksyon na kailangan para dalhin ang replica sa isang pare-parehong estado. Kung hindi ka gagawa ng mga manu-manong manipulasyon na magpapabalik sa replication log na ito, ang pagsasanib ay kailangang isagawa sa isang paraan o iba pa.

Siyempre, hindi kalabisan na magkaroon ng limitasyon ng RAM na "kung sakali" ay nagpoprotekta laban sa OOM. Hindi ito makakatulong upang makumpleto ang pagsasama, magsisimula itong muli, maabot ang ilang threshold, magtapon ng isang pagbubukod, at pagkatapos ay magsimulang muli - walang magandang mangyayari dito. Ngunit sa prinsipyo, magiging kapaki-pakinabang na ipakilala ang paghihigpit na ito.

Paano mabubuo ang driver ng Golang para sa ClickHouse?

Ang driver ng Golang, na isinulat ni Kirill Shvakov, ay opisyal na ngayong sinusuportahan ng pangkat ng ClickHouse. Siya sa ClickHouse repository, malaki na siya at totoo na.

Isang maliit na tala. Mayroong isang kahanga-hanga at minamahal na imbakan ng mga normal na anyo ng walang katapusang pagkakasunud-sunod - ito ay Vertica. Mayroon din silang sariling opisyal na driver ng python, na sinusuportahan ng mga developer ng Vertica. At ilang beses nangyari na ang mga bersyon ng imbakan at ang mga bersyon ng driver ay nag-iba nang malaki, at ang driver sa ilang mga punto ay tumigil sa pagtatrabaho. At ang pangalawang punto. Ang suporta para sa opisyal na driver na ito, tila sa akin, ay isinasagawa ng "utong" na sistema - isinulat mo sila ng isang isyu, at ito ay nakabitin magpakailanman.

Mayroon akong dalawang tanong. Ngayon ang driver ng Golang ni Kirill ay halos ang default na paraan upang makipag-usap mula sa Golang sa ClickHouse. Maliban kung may nakikipag-usap pa rin sa pamamagitan ng interface ng http dahil gusto niya ito sa ganoong paraan. Paano magpapatuloy ang pag-unlad ng driver na ito? Ito ba ay mai-synchronize sa anumang paglabag sa mga pagbabago sa repositoryo mismo? At ano ang pamamaraan para sa pagsasaalang-alang ng isang isyu?

Kirill Shvakov: Ang una ay kung paano inorganisa ang lahat ng bureaucratically. Ang puntong ito ay hindi napag-usapan, kaya wala akong masagot.

Upang masagot ang tanong tungkol sa isyu, kailangan namin ng kaunting kasaysayan ng driver. Nagtrabaho ako sa isang kumpanya na maraming data. Isa itong advertising spinner na may malaking bilang ng mga kaganapan na kailangang itago sa isang lugar. At sa ilang sandali ay lumitaw ang ClickHouse. Pinuno namin ito ng data, at sa una ay maayos ang lahat, ngunit pagkatapos ay nag-crash ang ClickHouse. Sa sandaling iyon napagpasyahan namin na hindi namin ito kailangan.

Makalipas ang isang taon, bumalik kami sa ideya ng paggamit ng ClickHouse, at kailangan naming magsulat ng data doon kahit papaano. Ang pambungad na mensahe ay ito: ang hardware ay napakahina, mayroong ilang mga mapagkukunan. Ngunit palagi kaming gumagawa sa ganitong paraan, at samakatuwid ay tumingin kami sa katutubong protocol.

Dahil nagtatrabaho kami sa Go, malinaw na kailangan namin ng driver ng Go. Ginawa ko ito halos buong oras - ito ang aking gawain sa trabaho. Dinala namin ito sa isang tiyak na punto, at sa prinsipyo walang sinuman ang nag-aakala na sinuman maliban sa amin ang gagamit nito. Pagkatapos ay dumating ang CloudFlare na may eksaktong kaparehong problema, at sa loob ng ilang panahon ay nagtrabaho kami sa kanila nang maayos, dahil mayroon silang parehong mga gawain. Bukod dito, ginawa namin ito pareho sa ClickHouse sa aming sarili at sa driver.

Sa ilang mga punto, tumigil lang ako sa paggawa nito, dahil ang aking aktibidad sa mga tuntunin ng ClickHouse at trabaho ay nagbago ng kaunti. Samakatuwid ang mga isyu ay hindi sarado. Paminsan-minsan, ang mga taong nangangailangan ng isang bagay mismo ay nangangako sa repositoryo. Pagkatapos ay tinitingnan ko ang kahilingan sa paghila at kung minsan ay nag-e-edit ako ng isang bagay sa aking sarili, ngunit bihira itong mangyari.

Gusto kong bumalik sa driver. Ilang taon na ang nakalilipas, nang magsimula ang buong bagay na ito, iba rin ang ClickHouse at may iba't ibang kakayahan. Ngayon ay mayroon na tayong pag-unawa kung paano muling gawin ang driver upang ito ay gumana nang maayos. Kung nangyari ito, ang bersyon 2 ay hindi tugma sa anumang kaso dahil sa mga naipon na saklay.

Hindi ko alam kung paano ayusin ang bagay na ito. Wala akong masyadong oras sa sarili ko. Kung ang ilang tao ay nakatapos ng driver, maaari ko silang tulungan at sabihin sa kanila kung ano ang gagawin. Ngunit ang aktibong pakikilahok ng Yandex sa pagbuo ng proyekto ay hindi pa napag-uusapan.

Alexey Milovidov: Sa katunayan, wala pang bureaucracy tungkol sa mga driver na ito. Ang tanging bagay ay ang mga ito ay isinumite sa isang opisyal na organisasyon, iyon ay, ang driver na ito ay kinikilala bilang ang opisyal na default na solusyon para sa Go. Mayroong ilang iba pang mga driver, ngunit sila ay dumating nang hiwalay.

Wala kaming anumang panloob na pag-unlad para sa mga driver na ito. Ang tanong ay kung maaari tayong kumuha ng isang indibidwal na tao, hindi para sa partikular na driver na ito, ngunit para sa pagpapaunlad ng lahat ng mga driver ng komunidad, o maaari ba tayong makahanap ng isang tao mula sa labas.

Hindi naglo-load ang panlabas na diksyunaryo pagkatapos ng pag-reboot na pinagana ang setting ng lazy_load. Anong gagawin?

Pinagana namin ang setting ng lazy_load, at pagkatapos ma-reboot ang server, hindi naglo-load ang diksyunaryo nang mag-isa. Itinataas lamang ito pagkatapos ma-access ng user ang diksyunaryong ito. At sa unang pagkakataon na ma-access ko ito, nagbibigay ito ng isang error. Posible bang kahit papaano ay awtomatikong mag-load ng mga diksyunaryo gamit ang ClickHouse, o kailangan mong palaging kontrolin ang kanilang kahandaan sa iyong sarili upang ang mga user ay hindi makatanggap ng mga error?

Marahil mayroon kaming lumang bersyon ng ClickHouse, kaya hindi awtomatikong naglo-load ang diksyunaryo. Ito kaya ang kaso?

Una, ang mga diksyunaryo ay maaaring piliting i-load gamit ang isang query system reload diksyunaryo. Pangalawa, tungkol sa error - kung na-load na ang diksyunaryo, gagana ang mga query batay sa data na na-load. Kung ang diksyunaryo ay hindi pa na-load, ito ay mai-load nang direkta sa panahon ng kahilingan.

Ito ay hindi masyadong maginhawa para sa mabibigat na mga diksyunaryo. Halimbawa, kailangan mong hilahin ang isang milyong mga hilera mula sa MySQL. May isang taong gumagawa ng isang simpleng pagpili, ngunit ang piling ito ay maghihintay para sa parehong milyong mga hilera. Mayroong dalawang solusyon dito. Ang una ay i-off ang lazy_load. Pangalawa, kapag ang server ay up, bago ilagay ang load dito, gawin diksyunaryo ng reload ng system o gumawa lang ng query na gumagamit ng diksyunaryo. Pagkatapos ay ilo-load ang diksyunaryo. Kailangan mong kontrolin ang pagkakaroon ng mga diksyunaryo na pinagana ang setting ng lazy_load, dahil hindi awtomatikong nilo-load ng ClickHouse ang mga ito.

Ang sagot sa huling tanong ay maaaring luma na ang bersyon o kailangan itong i-debug.

Ano ang gagawin sa katotohanan na ang system reload na mga diksyunaryo ay hindi naglo-load ng anuman sa maraming mga diksyunaryo kung kahit isa sa mga ito ay nag-crash nang may error?

May isa pang tanong tungkol sa mga diksyunaryo ng system reload. Mayroon kaming dalawang diksyunaryo - ang isa ay hindi na-load, ang pangalawa ay na-load. Sa kasong ito, hindi naglo-load ang mga diksyunaryo ng System reload ng anumang diksyunaryo, at kailangan mong mag-point-by-point na mag-load ng isang partikular na pangalan gamit ang system reload dictionary. May kaugnayan din ba ito sa bersyon ng ClickHouse?

Gusto kitang pasayahin. Nagbabago ang ugali na ito. Nangangahulugan ito na kung i-update mo ang ClickHouse, magbabago din ito. Kung hindi ka masaya sa ugali mo ngayon system reload diksyunaryo, i-update, at sana ay magbago ito para sa mas mahusay.

Mayroon bang paraan upang i-configure ang mga detalye sa ClickHouse config, ngunit hindi ipakita ang mga ito kung sakaling magkaroon ng mga error?

Ang susunod na tanong ay tungkol sa mga error na nauugnay sa diksyunaryo, lalo na ang mga detalye. Tinukoy namin ang mga detalye ng koneksyon sa ClickHouse config para sa diksyunaryo, at kung may error, natatanggap namin ang mga detalyeng ito at password bilang tugon.

Nalutas namin ang error na ito sa pamamagitan ng pagdaragdag ng mga detalye sa config ng driver ng ODBC. Mayroon bang anumang paraan upang i-configure ang mga detalye sa ClickHouse config, ngunit hindi ipakita ang mga detalyeng ito kung sakaling magkaroon ng mga error?

Ang tunay na solusyon dito ay tukuyin ang mga kredensyal na ito sa odbc.ini, at sa ClickHouse mismo ay tukuyin lamang ang Pangalan ng Pinagmulan ng Data ng ODBC. Hindi ito mangyayari para sa iba pang mga mapagkukunan ng diksyunaryo - para sa diksyunaryo na may MySQL, o para sa iba pa, hindi mo dapat makita ang password kapag nakatanggap ka ng mensahe ng error. Para sa ODBC, titingnan ko rin - kung mayroon man, kailangan mo lang itong alisin.

Bonus: mga background para sa Zoom mula sa mga pagtitipon

Sa pamamagitan ng pag-click sa larawan, ang mga bonus na background mula sa mga pagtitipon ay magbubukas para sa mga pinakamatiyagang mambabasa. Pinapatay namin ang apoy kasama ang mga maskot ng teknolohiya ng Avito, nakikipag-usap kami sa mga kasamahan mula sa silid ng administrator ng system o sa old-school na computer club, at nagsasagawa kami ng mga pang-araw-araw na pagpupulong sa ilalim ng tulay sa background ng graffiti.

ClickHouse para sa mga advanced na user sa mga tanong at sagot

Pinagmulan: www.habr.com

Magdagdag ng komento