Mnamo Aprili, wahandisi wa Avito walikusanyika kwa mikutano ya mtandaoni na msanidi mkuu wa ClickHouse Alexey Milovidov na Kirill Shvakov, msanidi wa Golang kutoka Integros. Tulijadili jinsi tunavyotumia mfumo wa usimamizi wa hifadhidata na matatizo gani tunayokumbana nayo.
Kulingana na mkutano huo, tumekusanya makala yenye majibu ya wataalamu kwa maswali yetu na ya hadhira kuhusu hifadhi rudufu, kushiriki upya data, kamusi za nje, kiendesha Golang na kusasisha matoleo ya ClickHouse. Inaweza kuwa na manufaa kwa watengenezaji ambao tayari wanafanya kazi kikamilifu na Yandex DBMS na wanavutiwa na sasa na ya baadaye. Kwa msingi, majibu ni ya Alexey Milovidov, isipokuwa imeandikwa vinginevyo.
Kuwa makini, kuna maandishi mengi chini ya kukata. Tunatumai kuwa maudhui yaliyo na maswali yatakusaidia kusogeza.
yaliyomo
Ikiwa hutaki kusoma maandishi, unaweza kutazama rekodi ya mikusanyiko . Misimbo ya saa iko kwenye maoni ya kwanza chini ya video.
ClickHouse inasasishwa kila mara, lakini data yetu sio. Nini cha kufanya kuhusu hilo?
ClickHouse inasasishwa kila mara, na data yetu, ambayo iliboreshwa ilichakatwa, haijasasishwa na iko kwenye nakala rudufu.
Wacha tuseme tulikuwa na shida na data ikapotea. Tuliamua kurejesha, na ikawa kwamba sehemu za zamani, ambazo zimehifadhiwa kwenye seva za chelezo, ni tofauti sana na toleo la sasa la ClickHouse. Nini cha kufanya katika hali kama hiyo, na inawezekana?
Hali ambayo umerejesha data kutoka kwa chelezo katika muundo wa zamani, lakini hauunganishi na toleo jipya, haiwezekani. Tunahakikisha kwamba umbizo la data katika ClickHouse daima linasalia likiendana nyuma. Hii ni muhimu zaidi kuliko utangamano wa nyuma katika utendakazi ikiwa tabia ya chaguo za kukokotoa ambazo hazitumiki sana imebadilika. Toleo jipya la ClickHouse linapaswa kuwa na uwezo wa kusoma data ambayo imehifadhiwa kwenye diski. Hii ndiyo sheria.
Je, ni mbinu gani bora za sasa za kuhifadhi nakala za data kutoka kwa ClickHouse?
Jinsi ya kufanya nakala rudufu, kwa kuzingatia kwamba tumeongeza shughuli za mwisho, hifadhidata kubwa ya terabytes, na data ambayo imesasishwa, tuseme, kwa siku tatu zilizopita, na kisha hakuna taratibu zinazofanyika kwake?
Tunaweza kutengeneza suluhisho letu wenyewe na kuandika kwenye bash: kukusanya nakala hizi za chelezo kwa njia kama hii. Labda hakuna haja ya kugonga kitu chochote, na baiskeli ilizuliwa zamani?
Wacha tuanze na mazoea bora. Wenzangu daima wanashauri, kwa kujibu maswali kuhusu backups, kuwakumbusha kuhusu huduma ya Yandex.Cloud, ambapo tatizo hili tayari limetatuliwa. Kwa hivyo itumie ikiwezekana.
Hakuna suluhisho kamili kwa chelezo, asilimia mia moja iliyojengwa kwenye ClickHouse. Kuna nafasi zilizo wazi ambazo zinaweza kutumika. Ili kupata suluhu kamili, itabidi ucheze kidogo kwa mikono, au uunde vifungashio kwa namna ya hati.
Nitaanza na ufumbuzi rahisi zaidi na kuishia na wale wa kisasa zaidi, kulingana na kiasi cha data na ukubwa wa nguzo. Kadiri nguzo inavyokuwa kubwa, ndivyo suluhisho inakuwa ngumu zaidi.
Ikiwa meza iliyo na data inachukua gigabytes chache tu, nakala rudufu inaweza kufanywa kama hii:
- Hifadhi ufafanuzi wa jedwali yaani metadata - onyesha jedwali la kuunda.
- Tengeneza dampo kwa kutumia mteja wa ClickHouse - teua * kutoka kwa meza faili. Kwa chaguo-msingi utapokea faili katika umbizo la TabSeparated. Ikiwa unataka kuwa bora zaidi, unaweza kuifanya katika umbizo la Asili.
Ikiwa kiasi cha data ni kikubwa, basi chelezo itachukua muda zaidi na nafasi nyingi. Hii inaitwa nakala rudufu ya kimantiki; haijaunganishwa na umbizo la data la ClickHouse. Ikiwa ni hivyo, basi kama suluhu la mwisho unaweza kuchukua nakala rudufu na kuipakia kwenye MySQL kwa urejeshaji.
Kwa kesi za hali ya juu zaidi, ClickHouse ina uwezo wa ndani wa kuunda taswira ya sehemu katika mfumo wa faili wa ndani. Kipengele hiki kinapatikana kama ombi badilisha kizigeu cha kufungia jedwali. Au kwa urahisi badilisha kufungia kwa meza - hii ni snapshot ya meza nzima.
Picha itaundwa mara kwa mara kwa meza moja kwenye shard moja, yaani, haiwezekani kuunda snapshot thabiti ya nguzo nzima kwa njia hii. Lakini kwa kazi nyingi hakuna haja hiyo, na inatosha kutekeleza ombi kwenye kila shard na kupata snapshot thabiti. Imeundwa kwa namna ya hardlinks na kwa hiyo haina kuchukua nafasi ya ziada. Kisha, unakili muhtasari huu kwenye seva ya chelezo au kwenye hifadhi unayotumia kuhifadhi nakala.
Kurejesha nakala kama hiyo ni rahisi sana. Kwanza, tengeneza jedwali ukitumia ufafanuzi wa jedwali uliopo. Ifuatayo, nakili vijipicha vilivyohifadhiwa vya kizigeu kwenye Saraka-Iliyotenganishwa kwa majedwali haya na uendeshe hoja. ambatisha kizigeu. Suluhisho hili linafaa kabisa kwa idadi kubwa zaidi ya data.
Wakati mwingine unahitaji kitu baridi zaidi - katika hali ambapo una makumi au hata mamia ya terabytes kwenye kila seva na mamia ya seva. Kuna suluhisho hapa ambalo nilichukua kutoka kwa wenzangu kutoka Yandex.Metrica. Nisingeipendekeza kwa kila mtu - isome na ujiamulie ikiwa inafaa au la.
Kwanza unahitaji kuunda seva kadhaa na rafu kubwa za diski. Ifuatayo, kwenye seva hizi, inua seva kadhaa za ClickHouse na uzisanidi ili zifanye kazi kama nakala nyingine ya shards sawa. Na kisha utumie mfumo wa faili au chombo fulani kwenye seva hizi ambacho kinakuwezesha kuunda snapshots. Kuna chaguzi mbili hapa. Chaguo la kwanza ni snapshots za LVM, chaguo la pili ni ZFS kwenye Linux.
Baada ya hayo, kila siku unahitaji kuunda snapshot, itakuwa uongo na kuchukua nafasi fulani. Kwa kawaida, ikiwa data itabadilika, kiasi cha nafasi kitaongezeka kwa muda. Picha hii inaweza kuchukuliwa wakati wowote na data kurejeshwa, suluhisho la kushangaza kama hilo. Zaidi ya hayo, tunahitaji pia kupunguza nakala hizi kwenye usanidi ili wasijaribu kuwa viongozi.
Itawezekana kuandaa lagi iliyodhibitiwa ya nakala kwenye shimoni?
Mwaka huu unapanga kutengeneza shafts katika ClickHouse. Itawezekana kupanga safu iliyodhibitiwa ya nakala ndani yao? Tungependa kuitumia kujilinda dhidi ya hali mbaya zenye mabadiliko na mabadiliko mengine.
Inawezekana kufanya aina fulani ya kurudi nyuma kwa mabadilisho? Kwa mfano, katika shimoni iliyopo, chukua na kusema kwamba mpaka wakati huu unatumia mabadiliko, na kutoka wakati huu unaacha kutumia mabadiliko?
Ikiwa amri ilikuja kwenye kikundi chetu na kuivunja, basi tuna replica ya masharti na lag ya saa, ambapo tunaweza kusema kwamba hebu tuitumie kwa sasa, lakini hatutatumia mabadiliko kwa dakika kumi zilizopita?
Kwanza, kuhusu lagi iliyodhibitiwa ya nakala. Kulikuwa na ombi kama hilo kutoka kwa watumiaji, na tukaunda suala kwenye Github na ombi: "Ikiwa mtu anahitaji hii, kama hiyo, weka moyo." Hakuna mtu aliyeletwa, na suala lilifungwa. Hata hivyo, unaweza tayari kupata fursa hii kwa kuanzisha ClickHouse. Kweli, kuanzia toleo la 20.3.
ClickHouse mara kwa mara hufanya kuunganisha data chinichini. Wakati kuunganisha kukamilika, seti fulani ya vipande vya data inabadilishwa na kipande kikubwa. Wakati huo huo, vipande vya data vilivyokuwepo hapo awali vinaendelea kubaki kwenye diski kwa muda fulani.
Kwanza, zinaendelea kuhifadhiwa kwa muda mrefu kama kuna maswali yaliyochaguliwa ambayo yanazitumia, ili kutoa operesheni isiyo ya kuzuia. Maswali yaliyochaguliwa yanasomwa kwa urahisi kutoka kwa vipande vya zamani.
Pili, pia kuna kizingiti cha wakati - vipande vya zamani vya data viko kwenye diski kwa dakika nane. Dakika hizi nane zinaweza kubinafsishwa na hata kugeuzwa kuwa siku moja. Hii itagharimu nafasi ya diski: kulingana na mtiririko wa data, zinageuka kuwa katika siku ya mwisho data sio mara mbili tu, inaweza kuwa mara tano zaidi. Lakini ikiwa kuna shida kubwa, unaweza kusimamisha seva ya ClickHouse na kutatua kila kitu.
Sasa swali linatokea jinsi hii inalinda dhidi ya mabadiliko. Inafaa kuangalia kwa undani hapa, kwa sababu katika matoleo ya zamani ya ClickHouse, kibadilishaji kilifanya kazi kwa njia ambayo ilibadilisha vipande moja kwa moja. Kuna kipande cha data kilicho na faili kadhaa, na tunafanya, kwa mfano, badilisha safu wima ya kushuka. Kisha safu hii hutolewa kimwili kutoka kwa vipande vyote.
Lakini kuanzia na toleo la 20.3, utaratibu wa kubadilisha umebadilishwa kabisa, na sasa vipande vya data daima havibadiliki. Hazibadiliki hata kidogo - mabadiliko sasa yanafanya kazi kwa njia sawa na uunganishaji. Badala ya kuchukua nafasi ya kipande papo hapo, tunaunda mpya. Katika chunk mpya, faili ambazo hazijabadilika huwa ngumu, na ikiwa tutafuta safu, itakosekana tu kwenye chunk mpya. Kipande cha zamani kitafutwa kwa default baada ya dakika nane, na hapa unaweza kurekebisha mipangilio iliyotajwa hapo juu.
Hali hiyo hiyo inatumika kwa mabadiliko kama vile mabadiliko. Unapofanya badilisha kufuta au badilisha sasisho, haibadiliki kipande, lakini huunda mpya. Na kisha kufuta ya zamani.
Je, ikiwa muundo wa meza umebadilika?
Jinsi ya kurejesha nakala rudufu ambayo ilifanywa na mpango wa zamani? Na swali la pili ni kuhusu kesi na snapshots na zana za mfumo wa faili. Btrfs ni nzuri hapa badala ya ZFS kwenye Linux LVM?
Ukifanya hivyo ambatisha kizigeu partitions na muundo tofauti, basi ClickHouse itakuambia kuwa hii haiwezekani. Hili ndilo suluhisho. Ya kwanza ni kuunda jedwali la muda la aina ya MergeTree na muundo wa zamani, ambatisha data hapo kwa kutumia ambatisha, na ufanye hoja ya kubadilisha. Kisha unaweza kunakili au kuhamisha data hii na kuambatisha tena, au kutumia ombi badilisha kizigeu cha kusonga jedwali.
Sasa swali la pili ni ikiwa Btrfs inaweza kutumika. Kuanza, ikiwa una LVM, basi snapshots za LVM zinatosha, na mfumo wa faili unaweza kuwa ext4, haijalishi. Ukiwa na Btrts, kila kitu kinategemea uzoefu wako wa kuitumia. Huu ni mfumo wa faili uliokomaa, lakini bado kuna mashaka juu ya jinsi kila kitu kitafanya kazi kwa vitendo katika hali fulani. Nisingependekeza kutumia hii isipokuwa unayo Btrfs katika uzalishaji.
Je, ni mbinu gani bora za sasa za kushiriki upya data?
Suala la kugawana upya ni gumu na lina mambo mengi. Kuna majibu kadhaa yanayowezekana hapa. Unaweza kwenda kutoka upande mmoja na kusema hivi - ClickHouse haina kipengee cha kushiriki upya. Lakini ninaogopa jibu hili halitafaa mtu yeyote. Kwa hiyo, unaweza kwenda kutoka upande mwingine na kusema kwamba ClickHouse ina njia nyingi za kushiriki tena data.
Ikiwa nguzo itaishiwa na nafasi au haiwezi kushughulikia mzigo, unaongeza seva mpya. Lakini seva hizi ni tupu kwa chaguo-msingi, hakuna data juu yao, hakuna mzigo. Unahitaji kupanga upya data ili isambae sawasawa kwenye nguzo mpya, kubwa zaidi.
Njia ya kwanza hii inaweza kufanywa ni kunakili sehemu ya partitions kwa seva mpya kwa kutumia ombi badilisha kizigeu cha kuchukua meza. Kwa mfano, ulikuwa na sehemu kwa mwezi, na unachukua mwezi wa kwanza wa 2017 na unakili kwa seva mpya, kisha unakili mwezi wa tatu kwa seva nyingine mpya. Na unafanya hivi hadi inakuwa zaidi au chini hata.
Uhamisho unaweza kufanywa tu kwa sehemu hizo ambazo hazibadilika wakati wa kurekodi. Kwa partitions mpya, kurekodi itabidi kuzimwa, kwa sababu uhamishaji wao sio wa atomiki. Vinginevyo, utaishia na nakala au mapungufu kwenye data. Hata hivyo, njia hii ni ya vitendo na inafanya kazi kwa ufanisi kabisa. Sehemu zilizoshinikizwa zilizotengenezwa tayari hupitishwa kwenye mtandao, ambayo ni kwamba, data haijabanwa au kusimbwa tena.
Njia hii ina kikwazo kimoja, na inategemea mpango wa kugawanyika, ikiwa uliahidi mpango huu wa kugawanyika, ulikuwa na ufunguo gani wa sharding. Katika mfano wako kwa kesi na metriki, ufunguo wa kugawanya ni heshi ya njia. Unapochagua Jedwali la Kusambazwa, huenda kwa shards zote kwenye nguzo mara moja na kuchukua data kutoka hapo.
Hii inamaanisha kuwa haijalishi ni data gani iliishia kwenye shard gani. Jambo kuu ni kwamba data kwenye njia moja huisha kwenye shard moja, lakini ambayo sio muhimu. Katika kesi hii, kuhamisha sehemu zilizotengenezwa tayari ni sawa, kwa sababu kwa maswali yaliyochaguliwa pia utapokea data kamili - iwe kabla ya kushiriki tena au baada, mpango haujalishi.
Lakini kuna kesi ambazo ni ngumu zaidi. Ikiwa katika ngazi ya mantiki ya maombi unategemea mpango maalum wa sharding, kwamba mteja huyu iko kwenye vile na vile shard, na ombi linaweza kutumwa moja kwa moja huko, na si kwa meza ya Kusambazwa. Au unatumia toleo la hivi majuzi la ClickHouse na umewezesha mpangilio boresha ruka shards ambazo hazijatumika. Katika kesi hii, wakati wa swala la kuchagua, kujieleza katika sehemu ambapo sehemu itachambuliwa na itahesabiwa ambayo shards inahitaji kutumika kulingana na mpango wa sharding. Hii inafanya kazi ili mradi data imegawanywa haswa kulingana na mpango huu wa kugawa. Ikiwa umezipanga upya kwa mikono, mawasiliano yanaweza kubadilika.
Kwa hivyo hii ni njia namba moja. Na ninangojea jibu lako, ikiwa njia hiyo inafaa, au wacha tuendelee.
Vladimir Kolobaev, msimamizi wa mfumo wa Avito: Alexey, njia ambayo umetaja haifanyi kazi vizuri wakati unahitaji kueneza mzigo, ikiwa ni pamoja na kusoma. Tunaweza kuchukua kizigeu ambacho ni cha kila mwezi na tunaweza kuchukua mwezi uliopita kwenye nodi nyingine, lakini ombi linapokuja la data hii, tutaipakia pekee. Lakini tungependa kupakia nguzo nzima, kwa sababu vinginevyo, kwa muda fulani mzigo wote wa kusoma utashughulikiwa na shards mbili.
Alexey Milovidov: Jibu hapa ni la kushangaza - ndio, ni mbaya, lakini inaweza kufanya kazi. Nitaeleza jinsi gani hasa. Inafaa kuangalia hali ya mzigo ambayo inakuja nyuma ya data yako. Ikiwa hii ni data ya ufuatiliaji, basi tunaweza kusema kwa hakika kwamba idadi kubwa ya maombi ni ya data mpya.
Ulisakinisha seva mpya, ukahamisha sehemu za zamani, lakini pia ulibadilisha jinsi data mpya inavyorekodiwa. Na data mpya itasambazwa katika nguzo nzima. Kwa hivyo, baada ya dakika tano tu, maombi ya dakika tano za mwisho yatapakia nguzo sawasawa; baada ya siku, maombi ya masaa XNUMX yatapakia nguzo sawasawa. Na maombi ya mwezi uliopita, kwa bahati mbaya, yataenda tu kwa sehemu ya seva za nguzo.
Lakini mara nyingi hutakuwa na maombi mahususi kwa ajili ya Februari 2019. Uwezekano mkubwa zaidi, ikiwa maombi yataingia 2019, basi yatakuwa ya 2019 nzima - kwa muda mrefu, na sio kwa anuwai ndogo. Na maombi kama haya pia yataweza kupakia nguzo sawasawa. Lakini kwa ujumla, maoni yako ni sahihi kabisa kwamba hili ni suluhisho la dharula ambalo halienezi data kwa usawa kabisa.
Nina pointi chache zaidi za kujibu swali. Mojawapo ni kuhusu jinsi ya kuunda mpango wa kugawanyika ili kugawanya tena kunaweza kusababisha maumivu kidogo. Hii haiwezekani kila wakati.
Kwa mfano, una data ya ufuatiliaji. Data ya ufuatiliaji inakua kwa sababu tatu. Ya kwanza ni mkusanyiko wa data za kihistoria. Ya pili ni ukuaji wa trafiki. Na ya tatu ni kuongezeka kwa idadi ya mambo ambayo ni chini ya ufuatiliaji. Kuna huduma ndogo ndogo na vipimo ambavyo vinahitaji kuhifadhiwa.
Inawezekana kwamba kati ya hizi, ongezeko kubwa zaidi linahusishwa na sababu ya tatu - ongezeko la matumizi ya ufuatiliaji. Na katika kesi hii, inafaa kuangalia asili ya mzigo, ni maswali gani kuu ya kuchagua. Hoja za kimsingi zilizochaguliwa kuna uwezekano mkubwa kuwa zitatokana na baadhi ya vipimo vidogo.
Kwa mfano, matumizi ya CPU kwenye seva zingine na huduma fulani. Inabadilika kuwa kuna sehemu ndogo ya funguo ambazo unapata data hii. Na ombi lenyewe la data hii ni rahisi sana na linakamilika kwa makumi ya milisekunde. Inatumika kwa huduma za ufuatiliaji na dashibodi. Natumai ninaelewa hii kwa usahihi.
Vladimir Kolobaev: Ukweli ni kwamba mara nyingi tunakata rufaa kwa data ya kihistoria, kwani tunalinganisha hali ya sasa na ile ya kihistoria kwa wakati halisi. Na ni muhimu kwetu kuwa na upatikanaji wa haraka kwa kiasi kikubwa cha data, na ClickHouse hufanya kazi nzuri na hii.
Uko sahihi kabisa, tunapokea maombi mengi ya kusoma katika siku iliyopita, kama vile mfumo wowote wa ufuatiliaji. Lakini wakati huo huo, mzigo kwenye data ya kihistoria pia ni kubwa kabisa. Kimsingi ni kutoka kwa mfumo wa tahadhari ambao huenda karibu kila sekunde thelathini na kumwambia ClickHouse: "Nipe data ya wiki sita zilizopita. Sasa nijengee aina fulani ya wastani kutoka kwao, na wacha tulinganishe thamani ya sasa na ile ya kihistoria.
Ningependa kusema kwamba kwa maombi ya hivi karibuni sana tuna meza nyingine ndogo ambayo tunahifadhi siku mbili tu za data, na maombi kuu yanaingia ndani yake. Tunatuma tu maswali makubwa ya kihistoria kwenye jedwali kubwa lililogawanywa.
Alexey Milovidov: Kwa bahati mbaya, inageuka kuwa haitumiki vizuri kwa hali yako, lakini nitakuambia maelezo ya miradi miwili mbaya na ngumu ya kugawanyika ambayo haihitaji kutumiwa, lakini ambayo hutumiwa katika huduma ya marafiki zangu.
Kuna nguzo kuu na matukio ya Yandex.Metrica. Matukio ni mwonekano wa kurasa, mibofyo na ubadilishaji. Maombi mengi huenda kwa tovuti maalum. Unafungua huduma ya Yandex.Metrica, una tovuti - avito.ru, nenda kwenye ripoti, na ombi linafanywa kwa tovuti yako.
Lakini kuna maombi mengine - ya uchambuzi na ya kimataifa - ambayo yanatolewa na wachambuzi wa ndani. Ikiwezekana, naona kwamba wachambuzi wa ndani hufanya maombi tu kwa huduma za Yandex. Lakini hata hivyo, hata huduma za Yandex zinachukua sehemu kubwa ya data zote. Haya si maombi ya vihesabio maalum, lakini kwa uchujaji mpana.
Jinsi ya kupanga data kwa njia ambayo kila kitu hufanya kazi kwa ufanisi kwa kaunta moja, na maswali ya kimataifa pia? Ugumu mwingine ni kwamba idadi ya maombi katika ClickHouse kwa nguzo ya Metrics ni elfu kadhaa kwa sekunde. Wakati huo huo, seva moja ya ClickHouse haiwezi kushughulikia maombi yasiyo ya kawaida, kwa mfano, elfu kadhaa kwa pili.
Ukubwa wa nguzo ni seva mia sita za kitu. Ukivuta tu Jedwali la Kusambazwa juu ya nguzo hii na kutuma maombi elfu kadhaa huko, itakuwa mbaya zaidi kuliko kuyatuma kwa seva moja. Kwa upande mwingine, chaguo kwamba data imeenea sawasawa, na tunakwenda na kuomba kutoka kwa seva zote, mara moja hufukuzwa.
Kuna chaguo ambalo ni kinyume cha diametrically. Hebu fikiria ikiwa tutagawanya data kwenye tovuti zote, na ombi la tovuti moja kwenda kwa shard moja. Sasa nguzo itaweza kushughulikia maombi elfu kumi kwa sekunde, lakini kwa shard moja ombi lolote litafanya kazi polepole sana. Haitakua tena katika suala la upitishaji. Hasa ikiwa hii ni tovuti ya avito.ru. Sitafunua siri ikiwa nasema kwamba Avito ni mojawapo ya maeneo yaliyotembelewa zaidi katika RuNet. Na kusindika kwenye shard moja itakuwa wazimu.
Kwa hiyo, mpango wa sharding umeundwa kwa njia ya ujanja zaidi. Nguzo nzima imegawanywa katika idadi ya makundi, ambayo tunaita tabaka. Kila nguzo ina vipande kutoka dazeni hadi kadhaa. Kuna makundi thelathini na tisa kama haya kwa jumla.
Je, hii yote inakuaje? Idadi ya makundi haibadiliki - kama ilivyokuwa miaka thelathini na tisa iliyopita, inabakia hivyo. Lakini ndani ya kila moja yao, hatua kwa hatua tunaongeza idadi ya shards tunapokusanya data. Na mpango wa kugawanyika kwa ujumla ni kama hii: nguzo hizi zimegawanywa katika tovuti, na ili kuelewa ni tovuti gani ambayo ni nguzo, metabase tofauti katika MySQL inatumiwa. Tovuti moja - kwenye nguzo moja. Na ndani yake, sharding hutokea kulingana na vitambulisho vya wageni.
Wakati wa kurekodi, tunazigawanya kwa sehemu iliyobaki ya kitambulisho cha mgeni. Lakini wakati wa kuongeza shard mpya, mpango wa kugawanya hubadilika; tunaendelea kugawanyika, lakini kwa salio la mgawanyiko kwa nambari nyingine. Hii ina maana kwamba mgeni mmoja tayari iko kwenye seva kadhaa, na huwezi kutegemea hili. Hii inafanywa tu ili kuhakikisha kuwa data imebanwa vyema. Na wakati wa kufanya maombi, tunaenda kwenye Jedwali la Kusambazwa, ambalo linaangalia nguzo na kufikia seva kadhaa. Huu ni mpango wa kijinga sana.
Lakini hadithi yangu itakuwa haijakamilika ikiwa sitasema kwamba tuliacha mpango huu. Katika mpango mpya, tulibadilisha kila kitu na kunakili data yote kwa kutumia clickhouse-copier.
Katika mpango mpya, tovuti zote zimegawanywa katika makundi mawili - kubwa na ndogo. Sijui jinsi kizingiti kilichaguliwa, lakini matokeo yake ni kwamba tovuti kubwa zimerekodiwa kwenye nguzo moja, ambapo kuna shards 120 zilizo na nakala tatu kila moja - yaani, seva 360. Na mpango wa kugawanyika ni kwamba ombi lolote huenda kwa shards zote mara moja. Ikiwa sasa utafungua ukurasa wowote wa ripoti kwa avito.ru katika Yandex.Metrica, ombi litaenda kwa seva 120. Kuna tovuti chache kubwa katika RuNet. Na maombi sio elfu kwa sekunde, lakini hata chini ya mia moja. Yote hii hutafunwa kimya kimya na Jedwali la Kusambazwa, ambalo kila mmoja wao huchakata na seva 120.
Na nguzo ya pili ni ya tovuti ndogo. Hapa kuna mpango wa kugawanya kulingana na kitambulisho cha tovuti, na kila ombi huenda kwa shard moja haswa.
ClickHouse ina matumizi ya clickhouse-copier. Unaweza kutuambia kumhusu?
Nitasema mara moja kuwa suluhisho hili ni gumu zaidi na kwa kiasi fulani halitoi tija. Faida ni kwamba hupaka data kabisa kulingana na muundo uliotaja. Lakini drawback ya matumizi ni kwamba haina reshard wakati wote. Hunakili data kutoka kwa schema ya nguzo moja hadi schema nyingine ya nguzo.
Hii ina maana kwamba ili ifanye kazi lazima uwe na makundi mawili. Wanaweza kuwa kwenye seva sawa, lakini, hata hivyo, data haitahamishwa kwa kuongezeka, lakini itakiliwa.
Kwa mfano, kulikuwa na seva nne, sasa kuna nane. Unaunda jedwali jipya la Kusambazwa kwenye seva zote, jedwali mpya za ndani na kuzindua kikopi cha kubofya, ukionyesha ndani yake mpango wa kazi ambao unapaswa kusoma kutoka hapo, ukubali mpango mpya wa kugawanya na kuhamisha data hapo. Na kwenye seva za zamani utahitaji nafasi moja na nusu zaidi kuliko ilivyo sasa, kwa sababu data ya zamani inapaswa kubaki juu yao, na nusu ya data ya zamani itafika juu yao. Ikiwa ulifikiri mapema kwamba data inahitaji kugawanywa tena na kuna nafasi, basi njia hii inafaa.
Kinakili cha kubofya kinafanyaje kazi ndani? Inavunja kazi yote katika seti ya kazi za usindikaji sehemu moja ya meza moja kwenye shard moja. Majukumu haya yote yanaweza kutekelezwa kwa sambamba, na clickhouse-copier inaweza kuendeshwa kwa mashine tofauti katika matukio mengi, lakini inachofanya kwa kizigeu kimoja si chochote zaidi ya chaguo la kuingiza. Data husomwa, kupunguzwa, kugawanywa tena, kisha kubanwa tena, kuandikwa mahali fulani, na kupangwa upya. Huu ni uamuzi mgumu zaidi.
Ulikuwa na kitu cha majaribio kinachoitwa resharding. Vipi naye?
Huko nyuma mnamo 2017, ulikuwa na kitu cha majaribio kinachoitwa resharding. Kuna hata chaguo katika ClickHouse. Kama ninavyoelewa, haikuondoka. Unaweza kuniambia kwa nini hii ilitokea? Inaonekana inafaa sana.
Shida nzima ni kwamba ikiwa inahitajika kushiriki tena data mahali, maingiliano ngumu sana inahitajika ili kufanya hivi kwa atomiki. Tulipoanza kuangalia jinsi maingiliano haya yanavyofanya kazi, ikawa wazi kwamba kulikuwa na matatizo ya kimsingi. Na matatizo haya ya msingi sio tu ya kinadharia, lakini mara moja walianza kujionyesha katika mazoezi kwa namna ya kitu ambacho kinaweza kuelezewa kwa urahisi sana - hakuna kitu kinachofanya kazi.
Inawezekana kuunganisha vipande vyote vya data pamoja kabla ya kuihamisha kwa diski polepole?
Swali kuhusu TTL na hoja ya kupunguza chaguo la diski katika muktadha wa miunganisho. Kuna njia, isipokuwa kupitia cron, ya kuunganisha sehemu zote kuwa moja kabla ya kuzihamishia kwa diski polepole?
Jibu la swali ni inawezekana kwa namna fulani gundi moja kwa moja vipande vyote katika moja kabla ya kuhamisha - hapana. Sidhani kama hii ni muhimu. Si lazima kuunganisha sehemu zote kwa moja, lakini tu kuhesabu ukweli kwamba watahamishiwa kwenye disks za polepole moja kwa moja.
Tuna vigezo viwili vya sheria za uhamisho. Ya kwanza ni kama imejaa. Ikiwa kiwango cha sasa cha hifadhi kina chini ya asilimia fulani ya nafasi ya bure, tunachagua kipande kimoja na kukipeleka kwenye hifadhi ya polepole. Au tuseme, sio polepole, lakini inayofuata - unaposanidi.
Kigezo cha pili ni ukubwa. Ni juu ya kusonga vipande vikubwa. Unaweza kurekebisha kizingiti kulingana na nafasi ya bure kwenye diski ya haraka, na data itahamishwa moja kwa moja.
Jinsi ya kuhamia matoleo mapya ya ClickHouse ikiwa hakuna njia ya kuangalia utangamano mapema?
Mada hii inajadiliwa mara kwa mara kwa kuzingatia matoleo tofauti, na bado. Je, ni salama jinsi gani kuboresha kutoka toleo la 19.11 hadi 19.16 na, kwa mfano, kutoka 19.16 hadi 20.3. Ni ipi njia bora ya kuhamia matoleo mapya bila kuwa na uwezo wa kuangalia uoanifu katika sandbox mapema?
Kuna sheria kadhaa za "dhahabu" hapa. Kwanza - . Ni kubwa, lakini kuna aya tofauti kuhusu mabadiliko ya nyuma yasiyoendana. Usichukulie pointi hizi kama bendera nyekundu. Kwa kawaida hizi ni kutopatana kidogo ambako kunahusisha utendakazi fulani wa makali ambao huenda hutumii.
Pili, ikiwa hakuna njia ya kuangalia utangamano kwenye sanduku la mchanga, na unataka kusasisha mara moja katika uzalishaji, pendekezo ni kwamba hauitaji kufanya hivyo. Kwanza tengeneza sanduku la mchanga na ujaribu. Ikiwa hakuna mazingira ya mtihani, basi uwezekano mkubwa huna kampuni kubwa sana, ambayo ina maana unaweza kunakili baadhi ya data kwenye kompyuta yako ya mkononi na uhakikishe kuwa kila kitu kinafanya kazi kwa usahihi juu yake. Unaweza hata kuongeza nakala kadhaa kwenye mashine yako. Au unaweza kuchukua toleo jipya mahali karibu na kupakia baadhi ya data hapo - yaani, kuunda mazingira ya majaribio yaliyoboreshwa.
Sheria nyingine sio kusasisha kwa wiki moja baada ya kutolewa kwa toleo kwa sababu ya kupata hitilafu katika toleo la umma na marekebisho ya haraka yanayofuata. Wacha tuchunguze hesabu za matoleo ya ClickHouse ili usichanganyike.
Kuna toleo la 20.3.4. Nambari ya 20 inaonyesha mwaka wa utengenezaji - 2020. Kutoka kwa mtazamo wa kile kilicho ndani, hii haijalishi, kwa hiyo hatutazingatia. Inayofuata - 20.3. Tunaongeza nambari ya pili - katika kesi hii 3 - kila wakati tunapotoa toleo na utendakazi mpya. Ikiwa tunataka kuongeza kipengele fulani kwa ClickHouse, lazima tuongeze nambari hii. Hiyo ni, katika toleo la 20.4 ClickHouse itafanya kazi vizuri zaidi. Nambari ya tatu ni 20.3.4. Hapa 4 ni idadi ya matoleo ya kiraka ambayo hatukuongeza vipengele vipya, lakini tulirekebisha mende fulani. Na 4 inamaanisha tulifanya hivyo mara nne.
Usifikiri kwamba hii ni kitu cha kutisha. Kawaida mtumiaji anaweza kusakinisha toleo la hivi karibuni na itafanya kazi bila matatizo yoyote na uptime kwa mwaka. Lakini fikiria kwamba katika baadhi ya utendaji wa kuchakata bitmaps, ambazo ziliongezwa na wenzetu wa Kichina, seva huacha kufanya kazi wakati wa kupitisha hoja zisizo sahihi. Tuna wajibu wa kurekebisha hili. Tutatoa toleo jipya la kiraka na ClickHouse itakuwa thabiti zaidi.
Ikiwa una ClickHouse inayoendeshwa katika uzalishaji, na toleo jipya la ClickHouse linatoka na vipengele vya ziada - kwa mfano, 20.4.1 ndiyo ya kwanza kabisa, usikimbilie kuiweka katika uzalishaji siku ya kwanza kabisa. Kwa nini hata inahitajika? Ikiwa tayari hutumii ClickHouse, basi unaweza kuiweka, na uwezekano mkubwa kila kitu kitakuwa sawa. Lakini ikiwa ClickHouse tayari inafanya kazi kwa utulivu, basi endelea kutazama viraka na visasisho ili kuona ni shida gani tunarekebisha.
Kirill Shvakov: Ningependa kuongeza kidogo kuhusu mazingira ya majaribio. Kila mtu anaogopa sana mazingira ya mtihani na kwa sababu fulani anaamini kwamba ikiwa una kikundi kikubwa cha ClickHouse, basi mazingira ya mtihani haipaswi kuwa chini au angalau mara kumi ndogo. Sio hivyo hata kidogo.
Ninaweza kukuambia kutoka kwa mfano wangu mwenyewe. Nina mradi, na kuna ClickHouse. Mazingira yetu ya mtihani ni kwa ajili yake tu - hii ni mashine ndogo ya kawaida huko Hetzner kwa euro ishirini, ambapo kila kitu kinatumika. Ili kufanya hivyo, tuna automatisering kamili katika Ansible, na kwa hiyo, kwa kanuni, haifanyi tofauti wapi kwenda - kwa seva za vifaa au tu kupeleka kwenye mashine za kawaida.
Je, nini kifanyike? Itakuwa nzuri kutoa mfano katika nyaraka za ClickHouse juu ya jinsi ya kupeleka kikundi kidogo nyumbani kwako - huko Docker, katika LXC, labda kuunda Ansible playbook, kwa sababu watu tofauti wana matumizi tofauti. Hii itarahisisha sana. Unapochukua na kupeleka kundi katika dakika tano, ni rahisi zaidi kujaribu kufikiri kitu. Hii ni rahisi zaidi, kwa sababu kuingia katika toleo la uzalishaji ambalo hujalijaribu ni njia ya kwenda popote. Wakati mwingine inafanya kazi na wakati mwingine haifanyi kazi. Na kwa hiyo, matumaini ya mafanikio ni mbaya.
Maxim Kotyakov, mhandisi mkuu wa nyuma Avito: Nitaongeza kidogo kuhusu mazingira ya majaribio kutoka kwa mfululizo wa matatizo yanayokabili makampuni makubwa. Tuna kikundi kamili cha kukubalika cha ClickHouse; kwa suala la mipango na mipangilio ya data, ni nakala halisi ya kile kilicho katika uzalishaji. Kundi hili limewekwa katika vyombo vilivyo na kiwango cha chini cha rasilimali. Tunaandika asilimia fulani ya data ya uzalishaji huko, kwa bahati nzuri inawezekana kuiga mkondo huko Kafka. Kila kitu hapo kimesawazishwa na kupunguzwa - kulingana na uwezo na mtiririko, na, kwa nadharia, vitu vingine vyote vikiwa sawa, vinapaswa kuwa kama uzalishaji kulingana na vipimo. Kila kitu kinachoweza kulipuka kwanza hubingirwa kwenye stendi hii na kuachwa hapo kwa siku kadhaa hadi tayari. Lakini kwa kawaida, suluhisho hili ni ghali, ngumu na lina gharama zisizo za sifuri za usaidizi.
Alexey Milovidov: Nitakuambia nini mazingira ya mtihani wa marafiki zetu kutoka Yandex.Metrica ni kama. Kundi moja lilikuwa na seva zisizo za kawaida 600, lingine lilikuwa na 360, na kuna nguzo ya tatu na kadhaa. Mazingira ya majaribio kwa mmoja wao ni shards mbili zilizo na nakala mbili kwa kila moja. Kwa nini vipande viwili? Ili hauko peke yako. Na kunapaswa kuwa na nakala pia. Kiasi fulani cha chini tu ambacho unaweza kumudu.
Mazingira haya ya majaribio hukuruhusu kuangalia ikiwa hoja zako zinafanya kazi na ikiwa kuna jambo lolote kuu limeharibika. Lakini mara nyingi matatizo hutokea kwa asili tofauti kabisa, wakati kila kitu kinafanya kazi, lakini kuna mabadiliko madogo katika mzigo.
Ngoja nikupe mfano. Tuliamua kusakinisha toleo jipya la ClickHouse. Imechapishwa kwenye mazingira ya majaribio, majaribio ya kiotomatiki yamekamilika katika Yandex.Metrica yenyewe, ambayo inalinganisha data kwenye toleo la zamani na jipya, linaloendesha bomba zima. Na kwa kweli, vipimo vya kijani vya CI yetu. Vinginevyo tusingalipendekeza toleo hili.
Kila kitu kiko sawa. Tunaanza kuhamia kwenye uzalishaji. Ninapokea ujumbe kwamba mzigo kwenye grafu umeongezeka mara kadhaa. Tunarudisha toleo nyuma. Ninaangalia grafu na kuona: mzigo kweli uliongezeka mara kadhaa wakati wa uchapishaji, na ulipungua nyuma wakati ulipotoka. Kisha tukaanza kurudisha toleo. Na mzigo ukaongezeka vivyo hivyo na ukaanguka nyuma kwa njia ile ile. Kwa hiyo hitimisho ni hili: mzigo umeongezeka kutokana na mpangilio, hakuna kitu cha kushangaza.
Kisha ilikuwa vigumu kuwashawishi wenzake kusanikisha toleo jipya. Ninasema: "Ni sawa, fungua. Weka vidole vyako, kila kitu kitafanya kazi. Sasa mzigo kwenye grafu umeongezeka, lakini kila kitu ni sawa. Subiri hapo." Kwa ujumla, tulifanya hivi, na ndivyo hivyo - toleo lilitolewa kwa uzalishaji. Lakini karibu na kila mpangilio matatizo sawa hutokea.
Kill query inapaswa kuua maswali, lakini haifanyi hivyo. Kwa nini?
Mtumiaji, aina fulani ya mchambuzi, alikuja kwangu na kuunda ombi ambalo liliweka nguzo yangu ya ClickHouse. Baadhi ya nodi au nguzo nzima, kulingana na ni nakala gani au sehemu ambayo ombi lilienda. Ninaona kuwa rasilimali zote za CPU kwenye seva hii ziko kwenye rafu, kila kitu ni nyekundu. Wakati huo huo, ClickHouse yenyewe hujibu maombi. Nami ninaandika: "Tafadhali nionyeshe, orodha ya mchakato, ni ombi gani lilileta wazimu huu."
Ninapata ombi hili na kuandika kuua kwake. Na naona hakuna kinachoendelea. Seva yangu iko kwenye rafu, ClickHouse kisha hunipa amri, inaonyesha kuwa seva iko hai, na kila kitu ni nzuri. Lakini nina uharibifu katika maombi yote ya mtumiaji, uharibifu huanza na rekodi katika ClickHouse, na swala langu la kuua haifanyi kazi. Kwa nini? Nilidhani swala la kuua lilipaswa kuua maswali, lakini haifanyi hivyo.
Sasa kutakuwa na jibu la kushangaza. Jambo ni kwamba swala ya kuua haiui maswali.
Kill query hukagua kisanduku kidogo kiitwacho "Nataka hoja hii iuawe." Na ombi lenyewe huangalia bendera hii wakati wa kuchakata kila kizuizi. Ikiwa imewekwa, ombi huacha kufanya kazi. Inatokea kwamba hakuna mtu anayeua ombi, yeye mwenyewe lazima aangalie kila kitu na kuacha. Na hii inapaswa kufanya kazi katika hali zote ambapo ombi iko katika hali ya usindikaji wa vitalu vya data. Itachakata kizuizi kifuatacho cha data, angalia bendera, na usimamishe.
Hii haifanyi kazi katika hali ambapo ombi limezuiwa kwenye operesheni fulani. Kweli, uwezekano mkubwa hii sio kesi yako, kwa sababu, kulingana na wewe, hutumia tani ya rasilimali za seva. Inawezekana kwamba hii haifanyi kazi katika kesi ya upangaji wa nje na kwa maelezo mengine. Lakini kwa ujumla hii haipaswi kutokea, ni mdudu. Na jambo pekee ninaloweza kupendekeza ni kusasisha ClickHouse.
Jinsi ya kuhesabu wakati wa majibu chini ya mzigo wa kusoma?
Kuna meza ambayo huhifadhi jumla ya vitu - kaunta mbalimbali. Idadi ya mistari ni takriban milioni mia moja. Je, inawezekana kutegemea wakati wa kujibu unaotabirika ikiwa utamwaga 1K RPS kwa vitu 1K?
Kwa kuzingatia muktadha, tunazungumza juu ya mzigo wa kusoma, kwa sababu hakuna shida na uandishi - hata elfu, hata mia elfu, na wakati mwingine safu milioni kadhaa zinaweza kuingizwa.
Maombi ya kusoma ni tofauti sana. Katika kuchagua 1, ClickHouse inaweza kutekeleza takriban makumi ya maelfu ya maombi kwa sekunde, kwa hivyo hata maombi ya ufunguo mmoja tayari yatahitaji rasilimali kadhaa. Na maswali kama haya yatakuwa magumu zaidi kuliko katika hifadhidata zingine za ufunguo, kwa sababu kwa kila usomaji ni muhimu kusoma kizuizi cha data kwa faharisi. Faharasa yetu inashughulikia sio kila rekodi, lakini kila safu. Hiyo ni, itabidi usome safu nzima - hii ni mistari 8192 kwa msingi. Na itabidi upunguze kizuizi cha data kilichobanwa kutoka 64 KB hadi 1 MB. Kwa kawaida, hoja kama hizo zinazolengwa huchukua milisekunde chache kukamilika. Lakini hii ndiyo chaguo rahisi zaidi.
Hebu tujaribu hesabu rahisi. Ukizidisha milisekunde chache kwa elfu, utapata sekunde chache. Ni kana kwamba haiwezekani kuendelea na maombi elfu moja kwa sekunde, lakini kwa kweli inawezekana, kwa sababu tuna cores kadhaa za processor. Kwa hivyo, kimsingi, ClickHouse wakati mwingine inaweza kushikilia RPS 1000, lakini kwa maombi mafupi, yaliyolengwa haswa.
Ikiwa unahitaji kuongeza nguzo ya ClickHouse kwa idadi ya maombi rahisi, basi ninapendekeza jambo rahisi - ongeza idadi ya nakala na utume maombi kwa nakala ya nasibu. Ikiwa replica moja inashikilia maombi mia tano kwa sekunde, ambayo ni ya kweli kabisa, basi nakala tatu zitashughulikia elfu moja na nusu.
Wakati mwingine, bila shaka, unaweza kusanidi ClickHouse kwa idadi ya juu ya usomaji wa uhakika. Ni nini kinachohitajika kwa hili? Ya kwanza ni kupunguza granularity ya index. Katika kesi hii, haipaswi kupunguzwa kwa moja, lakini kwa msingi kwamba idadi ya maingizo katika index itakuwa milioni kadhaa au makumi ya mamilioni kwa seva. Ikiwa meza ina safu milioni mia moja, basi granularity inaweza kuweka 64.
Unaweza kupunguza saizi ya block iliyoshinikwa. Kuna mipangilio ya hii min compress block ukubwa, saizi kubwa ya kuzuia compression. Wanaweza kupunguzwa, kujazwa tena na data, na kisha hoja zinazolengwa zitakuwa za haraka zaidi. Lakini bado, ClickHouse sio hifadhidata ya thamani kuu. Idadi kubwa ya maombi madogo ni antipattern ya mzigo.
Kirill Shvakov: Nitatoa ushauri ikiwa kuna akaunti za kawaida huko. Hii ni hali ya kawaida wakati ClickHouse huhifadhi aina fulani ya kaunta. Nina mtumiaji, anatoka nchi kama na vile, na uwanja wa tatu, na ninahitaji kuongeza kitu zaidi. Chukua MySQL, tengeneza ufunguo wa kipekee - katika MySQL ni ufunguo unaorudiwa, na katika PostgreSQL ni mzozo - na ongeza ishara ya kuongeza. Hii itafanya kazi vizuri zaidi.
Wakati huna data nyingi, hakuna uhakika sana katika kutumia ClickHouse. Kuna hifadhidata za kawaida na hufanya hivi vizuri.
Ninaweza kurekebisha nini kwenye ClickHouse ili data zaidi iko kwenye kashe?
Hebu fikiria hali - seva zina 256 GB ya RAM, katika utaratibu wa kila siku ClickHouse inachukua kuhusu 60-80 GB, kwa kilele - hadi 130. Ni nini kinachoweza kuwezeshwa na kuunganishwa ili data zaidi iko kwenye cache na, ipasavyo, kuna safari chache kwa diski?
Kwa kawaida, kashe ya ukurasa wa mfumo wa uendeshaji hufanya kazi nzuri ya hii. Ikiwa unafungua tu juu, angalia pale iliyohifadhiwa au bure - pia inasema ni kiasi gani kilichohifadhiwa - basi utaona kwamba kumbukumbu yote ya bure hutumiwa kwa cache. Na wakati wa kusoma data hii, itasomwa sio kutoka kwa diski, lakini kutoka kwa RAM. Wakati huo huo, naweza kusema kwamba cache hutumiwa kwa ufanisi kwa sababu ni data iliyoshinikizwa ambayo imehifadhiwa.
Walakini, ikiwa unataka kuharakisha maswali rahisi hata zaidi, inawezekana kuwezesha kache katika data iliyopunguzwa ndani ya ClickHouse. Inaitwa akiba isiyobanwa. Katika faili ya usanidi wa config.xml, weka ukubwa wa cache usio na shinikizo kwa thamani unayohitaji - ninapendekeza si zaidi ya nusu ya RAM ya bure, kwa sababu wengine wataenda chini ya cache ya ukurasa.
Kwa kuongeza, kuna mipangilio miwili ya kiwango cha ombi. Mpangilio wa kwanza - tumia akiba isiyobanwa - inajumuisha matumizi yake. Inashauriwa kuiwezesha kwa maombi yote, isipokuwa nzito, ambayo inaweza kusoma data zote na kufuta cache. Na mpangilio wa pili ni kitu kama idadi ya juu ya mistari ya kutumia kache. Inaweka kikomo maswali makubwa kiotomatiki ili yaweze kupita kache.
Ninawezaje kusanidi storage_configuration kwa hifadhi kwenye RAM?
Kwenye hati mpya ya ClickHouse nilisoma sehemu inayohusiana . Maelezo yana mfano na SSD ya haraka.
Ninashangaa jinsi kitu kimoja kinaweza kusanidiwa na kumbukumbu ya moto ya kiasi. Na swali moja zaidi. Teua inafanyaje kazi na shirika hili la data, itasoma seti nzima au ile tu iliyo kwenye diski, na je, data hii imebanwa kwenye kumbukumbu? Na ni jinsi gani sehemu ya prewhere inafanya kazi na shirika kama hilo la data?
Mpangilio huu unaathiri uhifadhi wa vipande vya data, na muundo wao haubadilika kwa njia yoyote.
Hebu tuangalie kwa karibu.
Unaweza kusanidi hifadhi ya data katika RAM. Yote ambayo imeundwa kwa diski ni njia yake. Unaunda kizigeu cha tmpfs ambacho kimewekwa kwa njia fulani kwenye mfumo wa faili. Unabainisha njia hii kama njia ya kuhifadhi data kwa kizigeu cha moto zaidi, vipande vya data huanza kufika na kuandikwa hapo, kila kitu kiko sawa.
Lakini siipendekeza kufanya hivyo kwa sababu ya kuegemea chini, ingawa ikiwa una angalau nakala tatu katika vituo tofauti vya data, basi inawezekana. Ikiwa chochote kitatokea, data itarejeshwa. Wacha tufikirie kuwa seva ilizimwa ghafla na kuwashwa tena. Sehemu hiyo iliwekwa tena, lakini hakukuwa na kitu hapo. Wakati seva ya ClickHouse inapoanza, inaona kuwa haina vipande hivi, ingawa, kulingana na metadata ya ZooKeeper, wanapaswa kuwa huko. Anaangalia ni nakala zipi zinazo, anaziomba na kuzipakua. Kwa njia hii data itarejeshwa.
Kwa maana hii, kuhifadhi data katika RAM sio tofauti kabisa na kuihifadhi kwenye diski, kwa sababu wakati data imeandikwa kwenye diski, pia huishia kwenye kashe ya ukurasa na imeandikwa kimwili baadaye. Hii inategemea chaguo la kuweka mfumo wa faili. Lakini ikiwa tu, nitasema kwamba ClickHouse hailingani wakati wa kuingiza.
Katika kesi hii, data katika RAM imehifadhiwa katika muundo sawa na kwenye diski. Swali la kuchagua kwa njia sawa huchagua vipande vinavyotakiwa kusoma, huchagua safu za data muhimu katika vipande, na kuzisoma. Na mahali pengine hufanya kazi sawa, bila kujali ikiwa data ilikuwa kwenye RAM au kwenye diski.
Ni hadi nambari gani ya maadili ya kipekee ambayo Ukadilifu wa Chini unafaa?
Ukadinali wa Chini umeundwa kwa ustadi. Inakusanya kamusi za data, lakini ni za kawaida. Kwanza, kuna kamusi tofauti kwa kila kipande, na pili, hata ndani ya kipande kimoja zinaweza kuwa tofauti kwa kila safu. Idadi ya thamani za kipekee inapofikia nambari ya kiwango cha juu—milioni moja, nadhani—kamusi hiyo huwekwa kando na kuunda mpya.
Jibu ni kwa ujumla: kwa kila safu ya ndani - sema, kwa kila siku - mahali pengine hadi maadili milioni ya kipekee ya Ukadinali wa Chini ni mzuri. Baadaye kutakuwa na kurudi nyuma, ambapo kamusi nyingi tofauti zitatumika, na sio moja tu. Itafanya kazi takriban sawa na safu ya kamba ya kawaida, labda yenye ufanisi kidogo, lakini hakutakuwa na uharibifu mkubwa wa utendaji.
Je, ni mbinu gani bora zaidi za kutafuta maandishi kamili kwenye jedwali lenye safu mlalo bilioni tano?
Kuna majibu tofauti. Ya kwanza ni kusema kwamba ClickHouse sio injini ya utaftaji ya maandishi kamili. Kuna mifumo maalum ya hii, kwa mfano, и . Walakini, ninazidi kuona watu wakisema wanabadilisha kutoka Elasticsearch hadi ClickHouse.
Kwa nini hili linatokea? Wanaelezea hili kwa ukweli kwamba Elasticsearch huacha kukabiliana na mzigo kwa kiasi fulani, kuanzia na ujenzi wa faharisi. Fahirisi huwa ngumu sana, na ikiwa utahamisha data tu kwa ClickHouse, zinageuka kuwa zimehifadhiwa mara kadhaa kwa ufanisi zaidi kwa suala la kiasi. Wakati huo huo, maswali ya utafutaji mara nyingi hayakuwa hivyo kwamba ilikuwa ni lazima kupata baadhi ya maneno katika kiasi kizima cha data, kwa kuzingatia morphology, lakini tofauti kabisa. Kwa mfano, pata baadhi ya mfuatano wa baiti kwenye kumbukumbu katika saa chache zilizopita.
Katika kesi hii, unaunda index katika ClickHouse, shamba la kwanza ambalo litakuwa tarehe na wakati. Na kipunguzi kikubwa zaidi cha data kitalingana na kipindi. Ndani ya safu ya tarehe iliyochaguliwa, kama sheria, tayari inawezekana kufanya utaftaji wa maandishi kamili, hata kwa kutumia njia ya nguvu ya kinyama kwa kutumia kama. Opereta kama katika ClickHouse ndiye mwendeshaji mzuri zaidi kama unaweza kupata. Ukipata kitu bora zaidi, niambie.
Lakini bado, kama ni skanning kamili. Na scan kamili inaweza kuwa polepole si tu kwenye CPU, lakini pia kwenye diski. Ikiwa ghafla una terabyte moja ya data kwa siku, na unatafuta neno wakati wa mchana, basi utakuwa na scan terabyte. Na labda iko kwenye anatoa ngumu za kawaida, na mwisho zitapakiwa kwa namna ambayo hutaweza kufikia seva hii kupitia SSH.
Katika kesi hii, niko tayari kutoa hila moja zaidi. Ni majaribio - inaweza kufanya kazi, labda isifanyike. ClickHouse ina faharasa za maandishi kamili katika mfumo wa vichungi vya trigram Bloom. Wenzetu katika Arenadata tayari wamejaribu faharisi hizi, na mara nyingi hufanya kazi kama ilivyokusudiwa.
Ili kuzitumia kwa usahihi, unapaswa kuwa na ufahamu mzuri wa jinsi wanavyofanya kazi: ni nini kichujio cha Bloom cha trigram na jinsi ya kuchagua ukubwa wake. Ninaweza kusema kwamba zitasaidia kwa maswali juu ya misemo adimu, mifuatano ambayo haipatikani sana kwenye data. Katika kesi hii, safu ndogo zitachaguliwa kwa faharasa na data ndogo itasomwa.
Hivi majuzi, ClickHouse imeongeza vitendaji vya juu zaidi vya utafutaji wa maandishi kamili. Hii, kwanza, ni utafutaji wa rundo la mistari midogo kwa wakati mmoja katika pasi moja, ikijumuisha chaguo ambazo ni nyeti kwa kadhia, hazijali kadhia, zenye usaidizi wa UTF-8 au ASCII pekee. Chagua yenye ufanisi zaidi unayohitaji.
Utafutaji wa maneno mengi ya kawaida katika pasi moja pia umeonekana. Huna haja ya kuandika X kama kamba ndogo moja au X kama kamba nyingine ndogo. Unaandika mara moja, na kila kitu kinafanyika kwa ufanisi iwezekanavyo.
Tatu, sasa kuna takriban utaftaji wa regexps na utaftaji wa takriban wa mifuatano. Ikiwa mtu ameandika neno vibaya, hutafutwa ili kupata idadi ya juu inayolingana.
Ni ipi njia bora ya kupanga ufikiaji wa ClickHouse kwa idadi kubwa ya watumiaji?
Tuambie jinsi bora ya kupanga ufikiaji kwa idadi kubwa ya watumiaji na wachambuzi. Jinsi ya kuunda foleni, kutanguliza maswali mengi yanayofanana, na kwa zana gani?
Ikiwa nguzo ni kubwa ya kutosha, basi suluhisho nzuri itakuwa kuongeza seva mbili zaidi, ambazo zitakuwa mahali pa kuingilia kwa wachambuzi. Hiyo ni, usiruhusu wachambuzi kufikia shards maalum katika nguzo, lakini tu kuunda seva mbili tupu, bila data, na usanidi haki za upatikanaji juu yao. Katika kesi hii, mipangilio ya mtumiaji kwa maombi yaliyosambazwa huhamishiwa kwenye seva za mbali. Hiyo ni, unasanidi kila kitu kwenye seva hizi mbili, na mipangilio ina athari kwenye nguzo nzima.
Kimsingi, seva hizi hazina data, lakini kiasi cha RAM juu yao ni muhimu sana kwa kutekeleza maombi. Diski pia inaweza kutumika kwa data ya muda ikiwa mkusanyiko wa nje au upangaji wa nje umewezeshwa.
Ni muhimu kutazama mipangilio ambayo inahusishwa na mipaka yote inayowezekana. Ikiwa sasa nitaenda kwenye nguzo ya Yandex.Metrica kama mchambuzi na kuuliza ombi chagua hesabu kutoka kwa vibao, basi mara moja nitapewa ubaguzi kwamba siwezi kutekeleza ombi. Idadi ya juu ya safu ambazo ninaruhusiwa kuchanganua ni bilioni mia moja, na kwa jumla kuna trilioni hamsini kati yao kwenye jedwali moja kwenye nguzo. Hiki ni kikomo cha kwanza.
Wacha tuseme ninaondoa kikomo cha safu mlalo na niendeshe hoja tena. Kisha nitaona ubaguzi ufuatao - mpangilio umewezeshwa lazimisha index kwa tarehe. Siwezi kukamilisha hoja ikiwa sijabainisha masafa ya tarehe. Huna haja ya kutegemea wachanganuzi ili kubainisha wewe mwenyewe. Kisa cha kawaida ni wakati kipindi kimeandikwa ambapo tarehe ya tukio kati ya wiki. Na kisha walitaja tu mabano mahali pasipofaa, na badala yake na ikawa au - au URL inayolingana. Ikiwa hakuna kikomo, itatambaa kwenye safu wima ya URL na kupoteza tu tani ya rasilimali.
Kwa kuongeza, ClickHouse ina mipangilio miwili ya kipaumbele. Kwa bahati mbaya, wao ni primitive sana. Moja inaitwa tu kipaumbele. Ikiwa kipaumbele ≠ 0, na maombi yenye kipaumbele fulani yanatekelezwa, lakini ombi lenye thamani ya kipaumbele ya chini ya, ambayo ina maana ya kipaumbele cha juu, inatekelezwa, basi ombi lenye thamani ya kipaumbele ya kubwa zaidi, ambayo ina maana ya kipaumbele cha chini. , imesimamishwa tu na haitafanya kazi kabisa wakati huu.
Huu ni mpangilio mbaya sana na haufai kwa kesi ambapo nguzo ina mzigo wa mara kwa mara. Lakini ikiwa una maombi mafupi, yenye kupasuka ambayo ni muhimu, na nguzo nyingi hazifanyi kazi, usanidi huu unafaa.
Mpangilio unaofuata wa kipaumbele unaitwa Kipaumbele cha thread ya OS. Inaweka tu thamani nzuri kwa nyuzi zote za utekelezaji wa ombi kwa mpangilio wa Linux. Inafanya kazi hivyo-hivyo, lakini bado inafanya kazi. Ukiweka kima cha chini cha thamani nzuri - ni kubwa zaidi kwa thamani, na kwa hivyo kipaumbele cha chini - na kuweka -19 kwa maombi yenye kipaumbele cha juu, basi CPU itatumia maombi ya kipaumbele cha chini kuhusu mara nne chini ya yale ya kipaumbele cha juu.
Pia unahitaji kusanidi muda wa juu wa utekelezaji wa ombi - sema, dakika tano. Kasi ya chini ya utekelezaji wa hoja ndio jambo baridi zaidi. Mpangilio huu umekuwepo kwa muda mrefu, na inahitajika sio tu kudai kwamba ClickHouse haipunguzi, lakini kuilazimisha.
Fikiria, unasanidi: ikiwa hoja fulani itachakata chini ya safu mlalo milioni moja kwa sekunde, huwezi kufanya hivyo. Hii inadhalilisha jina letu zuri, hifadhidata yetu nzuri. Hebu tupige marufuku hili. Kwa kweli kuna mipangilio miwili. Mmoja anaitwa min kasi ya utekelezaji - kwa mistari kwa sekunde, na ya pili inaitwa kuisha kabla ya kuangalia kasi ya utekelezaji - sekunde kumi na tano kwa chaguo-msingi. Hiyo ni, sekunde kumi na tano inawezekana, na kisha, ikiwa ni polepole, basi tu kutupa ubaguzi na uondoe ombi.
Pia unahitaji kuweka upendeleo. ClickHouse ina kipengele cha mgao uliojengewa ndani ambacho huhesabu matumizi ya rasilimali. Lakini, kwa bahati mbaya, sio rasilimali za vifaa kama vile CPU, diski, lakini zile za kimantiki - idadi ya maombi yaliyochakatwa, mistari na kaiti zilizosomwa. Na unaweza kusanidi, kwa mfano, upeo wa maombi mia moja ndani ya dakika tano na maombi elfu kwa saa.
Kwa nini ni muhimu? Kwa sababu baadhi ya maswali ya uchanganuzi yatatekelezwa moja kwa moja kutoka kwa mteja wa ClickHouse. Na yote yatakuwa sawa. Lakini ikiwa una wachambuzi wa hali ya juu katika kampuni yako, wataandika hati, na kunaweza kuwa na hitilafu katika hati. Na hitilafu hii itasababisha ombi kutekelezwa kwa kitanzi kisicho na mwisho. Hili ndilo tunalohitaji kujilinda nalo.
Je, inawezekana kutoa matokeo ya swala moja kwa wateja kumi?
Tuna watumiaji kadhaa ambao wanapenda kuja na maombi makubwa sana kwa wakati mmoja. Ombi hilo ni kubwa na, kwa kanuni, linatekelezwa haraka, lakini kutokana na ukweli kwamba kuna maombi mengi hayo kwa wakati mmoja, inakuwa chungu sana. Je, inawezekana kutekeleza ombi lile lile, ambalo lilifika mara kumi mfululizo, mara moja, na kutoa matokeo kwa wateja kumi?
Shida ni kwamba hatuna matokeo ya kache au kache ya data ya kati. Kuna cache ya ukurasa wa mfumo wa uendeshaji, ambayo itakuzuia kusoma data kutoka kwa diski tena, lakini, kwa bahati mbaya, data bado itapunguzwa, kufutwa na kusindika tena.
Ningependa kwa njia fulani kuepusha hili, ama kwa kuweka akiba data ya kati, au kwa kupanga maswali sawa katika aina fulani ya foleni na kuongeza kashe ya matokeo. Kwa sasa tuna ombi moja la usanidi ambalo linaongeza akiba ya ombi, lakini kwa maswali madogo tu katika sehemu za ndani na za kujiunga - yaani, suluhisho halijakamilika.
Hata hivyo, sisi pia tunakabiliwa na hali kama hiyo. Mfano wa kisheria hasa ni maswali ya paginated. Kuna ripoti, ina kurasa kadhaa, na kuna ombi la kikomo 10. Kisha kitu kimoja, lakini kikomo 10,10. Kisha ukurasa mwingine unaofuata. Na swali ni, kwa nini tunahesabu haya yote kila wakati? Lakini sasa hakuna suluhisho, na hakuna njia ya kuizuia.
Kuna suluhisho mbadala ambalo limewekwa kama kando karibu na ClickHouse - .
Kirill Shvakov: Wakala wa ClickHouse ana kikomo cha viwango kilichojumuishwa na akiba ya matokeo iliyojumuishwa. Mipangilio mingi ilifanywa hapo kwa sababu tatizo kama hilo lilikuwa likitatuliwa. Wakala hukuruhusu kuweka kikomo maombi kwa kuyaweka kwenye foleni na kusanidi ni muda gani akiba ya ombi huishi. Ikiwa maombi yalikuwa sawa, Proksi itayatuma mara nyingi, lakini itaenda kwa ClickHouse mara moja tu.
Nginx pia ina cache katika toleo la bure, na hii pia itafanya kazi. Nginx hata ina mipangilio ambayo ikiwa maombi yanafika kwa wakati mmoja, itapunguza wengine hadi moja ikamilike. Lakini ni katika Wakala wa ClickHouse ambapo usanidi unafanywa bora zaidi. Ilifanywa mahsusi kwa ClickHouse, haswa kwa maombi haya, kwa hivyo inafaa zaidi. Naam, ni rahisi kufunga.
Vipi kuhusu utendakazi usiolingana na mitazamo inayoonekana?
Kuna tatizo kwamba uendeshaji na injini ya replay ni asynchronous - kwanza data imeandikwa, kisha inaanguka. Iwapo kompyuta kibao iliyo na umbile iliyo na mijumuisho fulani inaishi chini ya ishara, basi nakala zitaandikwa kwake. Na ikiwa hakuna mantiki ngumu, basi data itarudiwa. Unaweza kufanya nini kuhusu hilo?
Kuna suluhisho dhahiri - kutekeleza kichochezi kwenye darasa fulani la matviews wakati wa operesheni ya kuanguka kwa asynchronous. Je, kuna risasi zozote za fedha au mipango ya kutekeleza utendakazi sawa?
Inafaa kuelewa jinsi uondoaji unavyofanya kazi. Nini nitakuambia sasa haifai kwa swali, lakini tu ikiwa inafaa kukumbuka.
Wakati wa kuingiza kwenye meza iliyoigwa, kuna upunguzaji wa vitalu vyote vilivyoingizwa. Ukiingiza tena kizuizi kile kile kilicho na nambari sawa ya safu mlalo kwa mpangilio sawa, basi data itatolewa. Utapokea "Ok" kwa kukabiliana na kuingiza, lakini kwa kweli pakiti moja ya data itaandikwa, na haitarudiwa.
Hii ni muhimu kwa uhakika. Ukipokea "Sawa" wakati wa kuingiza, basi data yako imeingizwa. Ukipokea hitilafu kutoka kwa ClickHouse, inamaanisha kuwa hazikuingizwa na unahitaji kurudia uingizaji. Lakini ikiwa uunganisho umevunjwa wakati wa kuingizwa, basi hujui ikiwa data iliingizwa au la. Chaguo pekee ni kurudia uingizaji tena. Ikiwa data iliingizwa na ukaiingiza tena, kuna upunguzaji wa kizuizi. Hii inahitajika ili kuzuia nakala.
Na pia ni muhimu jinsi inavyofanya kazi kwa maoni yaliyofanywa. Ikiwa data ilitolewa wakati imeingizwa kwenye jedwali kuu, basi haitaingia kwenye mwonekano wa nyenzo pia.
Sasa kuhusu swali. Hali yako ni ngumu zaidi kwa sababu unarekodi nakala za mistari mahususi. Hiyo ni, sio pakiti nzima ambayo inarudiwa, lakini mistari maalum, na huanguka nyuma. Hakika, data itaanguka kwenye jedwali kuu, lakini data ambayo haijakunjwa itaenda kwa mwonekano wa nyenzo, na wakati wa kuunganishwa hakuna kitakachotokea kwa maoni yaliyofanywa. Kwa sababu mtazamo unaoonekana sio kitu zaidi ya kichochezi cha kuingiza. Wakati wa operesheni zingine, hakuna cha ziada kinachotokea kwake.
Na siwezi kukufanya uwe na furaha hapa. Unahitaji tu kutafuta suluhisho maalum kwa kesi hii. Kwa mfano, je, inawezekana kuigiza tena katika mwonekano wa kimaumbile, na mbinu ya utenganisho inaweza kufanya kazi kwa njia hiyo hiyo. Lakini, kwa bahati mbaya, sio kila wakati. Ikiwa ni kujumlisha, haitafanya kazi.
Kirill Shvakov: Pia tulikuwa na ujenzi wa crutch huko nyuma. Kulikuwa na tatizo kwamba kuna maonyesho ya utangazaji, na kuna baadhi ya data ambayo tunaweza kuonyesha kwa wakati halisi - haya ni maonyesho tu. Hunakiliwa mara chache, lakini hili likitokea, tutazikunja baadaye. Na kulikuwa na mambo ambayo hayangeweza kurudiwa - kubofya na hadithi hii yote. Lakini pia nilitaka kuwaonyesha karibu mara moja.
Maoni yaliyofanywa yalifanywaje? Kulikuwa na maoni ambapo iliandikwa moja kwa moja - iliandikwa kwa data ghafi, na imeandikwa kwa maoni. Huko, wakati fulani data si sahihi sana, inarudiwa, na kadhalika. Na kuna sehemu ya pili ya jedwali, ambapo zinaonekana sawa na maoni yaliyotengenezwa, ambayo ni, yanafanana kabisa katika muundo. Mara kwa mara tunahesabu tena data, kuhesabu data bila marudio, kuandika kwa meza hizo.
Tulipitia API - hii haitafanya kazi kwa ClickHouse kwa mikono. Na API inaonekana: wakati nina tarehe ya nyongeza ya mwisho kwenye meza, ambapo imehakikishiwa kuwa data sahihi tayari imehesabiwa, na inafanya ombi kwa meza moja na kwa meza nyingine. Kutoka kwa ombi moja huchagua hadi muda fulani, na kutoka kwa mwingine hupata kile ambacho bado hakijahesabiwa. Na inafanya kazi, lakini sio kupitia ClickHouse pekee.
Ikiwa una aina fulani ya API - kwa wachambuzi, kwa watumiaji - basi, kwa kanuni, hii ni chaguo. Unahesabu kila wakati, unahesabu kila wakati. Hii inaweza kufanywa mara moja kwa siku au wakati mwingine. Unajichagulia anuwai ambayo hauitaji na sio muhimu.
ClickHouse ina kumbukumbu nyingi. Ninawezaje kuona kila kitu kinachotokea kwa seva kwa mtazamo?
ClickHouse ina idadi kubwa sana ya kumbukumbu tofauti, na nambari hii inaongezeka. Katika matoleo mapya, baadhi yao hata huwashwa kwa chaguo-msingi; katika matoleo ya zamani lazima yawashwe wakati wa kusasisha. Hata hivyo, kuna zaidi na zaidi yao. Hatimaye, ningependa kuona kinachoendelea na seva yangu sasa, labda kwenye aina fulani ya dashibodi ya muhtasari.
Je, una timu ya ClickHouse, au timu za marafiki zako, zinazotumia baadhi ya utendaji wa dashibodi zilizotengenezwa tayari ambazo zinaweza kuonyesha kumbukumbu hizi kama bidhaa iliyokamilika? Hatimaye, kuangalia tu magogo katika ClickHouse ni nzuri. Lakini itakuwa baridi sana ikiwa tayari imeandaliwa kwa namna ya dashibodi. Napenda kupata kick nje yake.
Kuna dashibodi, ingawa sio sanifu. Katika kampuni yetu, takriban timu 60 hutumia ClickHouse, na jambo la kushangaza zaidi ni kwamba wengi wao wana dashibodi ambazo walijitengenezea, na tofauti kidogo. Baadhi ya timu hutumia usakinishaji wa ndani wa Yandex.Cloud. Kuna ripoti zilizotengenezwa tayari, ingawa sio zote muhimu. Wengine wana yao wenyewe.
Wenzangu kutoka Metrica wana dashibodi yao wenyewe huko Grafana, na mimi nina yangu ya kundi lao. Ninaangalia vitu kama kache iliyopigwa kwa kashe ya serif. Na ngumu zaidi ni kwamba tunatumia zana tofauti. Niliunda dashibodi yangu kwa kutumia zana ya zamani sana inayoitwa Graphite-web. Yeye ni mbaya kabisa. Na bado ninaitumia kwa njia hii, ingawa Grafana labda ingekuwa rahisi zaidi na nzuri.
Jambo la msingi katika dashibodi ni sawa. Hizi ni metriki za mfumo kwa nguzo: CPU, kumbukumbu, diski, mtandao. Nyingine - idadi ya maombi ya wakati mmoja, idadi ya kuunganishwa kwa wakati mmoja, idadi ya maombi kwa pili, idadi ya juu ya chunks kwa partitions meza ya MergeTree, replication lag, replication foleni ukubwa, idadi ya safu kuingizwa kwa pili, idadi ya vitalu kuingizwa kwa pili. Hii ndiyo yote ambayo haipatikani kutoka kwa kumbukumbu, lakini kutoka kwa metriki.
Vladimir Kolobaev: Alexey, ningependa kusahihisha kidogo. Kuna Grafana. Grafana ina hifadhidata, ambayo ni ClickHouse. Hiyo ni, naweza kufanya maombi kutoka Grafana moja kwa moja hadi ClickHouse. ClickHouse ina meza iliyo na magogo, ni sawa kwa kila mtu. Kama matokeo, ninataka kufikia jedwali hili la kumbukumbu huko Grafana na kuona maombi ambayo seva yangu hufanya. Itakuwa nzuri kuwa na dashibodi kama hii.
Niliendesha baiskeli mwenyewe. Lakini nina swali - ikiwa yote ni sanifu, na Grafana inatumiwa na kila mtu, kwa nini Yandex haina dashibodi rasmi kama hiyo?
Kirill Shvakov: Kwa kweli, hifadhidata inayoenda kwa ClickHouse sasa inasaidia Altinity. Na ninataka tu kutoa vekta ya wapi kuchimba na nani wa kusukuma. Unaweza kuwauliza, kwa sababu Yandex bado hufanya ClickHouse, na sio hadithi karibu nayo. Altinity ndio kampuni kuu inayokuza ClickHouse kwa sasa. Hawatamtelekeza, bali watamsaidia. Kwa sababu, kwa kanuni, kupakia dashibodi kwenye tovuti ya Grafana, unahitaji tu kujiandikisha na kuipakia - hakuna matatizo maalum.
Alexey Milovidov: Katika mwaka uliopita, ClickHouse imeongeza uwezo mwingi wa kuorodhesha hoja. Kuna vipimo kwa kila ombi la matumizi ya rasilimali. Na hivi majuzi, tuliongeza profaili ya hoja ya kiwango cha chini zaidi ili kuona ni wapi swala linatumia kila milisekunde. Lakini kutumia utendaji huu, lazima nifungue mteja wa koni na kuandika ombi, ambalo mimi husahau kila wakati. Niliihifadhi mahali fulani na kuendelea kusahau wapi hasa.
Laiti kungekuwa na kifaa ambacho kilisema hivi punde, haya ni maswali yako mazito, yaliyopangwa kulingana na darasa la hoja. Nilibonyeza moja, na wangeniambia kuwa ndiyo sababu ni nzito. Hakuna suluhisho kama hilo sasa. Na inashangaza sana kwamba watu wanaponiuliza: "Niambie, kuna dashibodi zilizotengenezwa tayari kwa Grafana?", Ninasema: "Nenda kwenye tovuti ya Grafana, kuna jumuiya ya "Dashibodi", na kuna dashibodi. kutoka Dimka, kuna dashibodi kutoka Kostyan. Sijui ni nini, sijaitumia mimi mwenyewe."
Jinsi ya kushawishi unganisho ili seva isiingie kwenye OOM?
Nina meza, kuna kizigeu kimoja tu kwenye jedwali, ni ReplaceMergeTree. Nimekuwa nikiandika data ndani yake kwa miaka minne. Nilihitaji kufanya mabadiliko ndani yake na kufuta data fulani.
Nilifanya hivi, na wakati wa usindikaji wa ombi hili, kumbukumbu zote kwenye seva zote kwenye nguzo zilitumiwa, na seva zote kwenye nguzo ziliingia kwenye OOM. Kisha wote wakainuka pamoja, wakaanza kuunganisha operesheni hii, kizuizi hiki cha data, na kuangukia kwenye OOM tena. Kisha wakainuka tena na kuanguka tena. Na jambo hili halikuacha.
Kisha ikawa kwamba hii ilikuwa kweli mdudu kwamba guys fasta. Hii ni poa sana, asante sana. Lakini mabaki yalibaki. Na sasa, ninapofikiria juu ya kutengeneza aina fulani ya unganisho kwenye jedwali, nina swali - kwa nini siwezi kushawishi muunganisho huu? Kwa mfano, ziweke kikomo kwa kiasi cha RAM kinachohitajika, au, kwa kanuni, kwa kiasi ambacho kitashughulikia meza hii.
Nina jedwali linaloitwa "Metrics", tafadhali nichatilie kwa nyuzi mbili. Hakuna haja ya kuunda miunganisho kumi au tano kwa sambamba, fanya kwa mbili. Nadhani nina kumbukumbu ya kutosha kwa mbili, lakini inaweza kuwa haitoshi kusindika kumi. Kwa nini hofu inabaki? Kwa sababu meza inakua, na siku moja nitakabiliwa na hali ambayo, kimsingi, sio kwa sababu ya mdudu tena, lakini kwa sababu data itabadilika kwa kiasi kikubwa kwamba sitakuwa na kumbukumbu ya kutosha kwenye seva. Na kisha seva itaanguka kwenye OOM wakati wa kuunganisha. Zaidi ya hayo, ninaweza kughairi mabadiliko, lakini Merji hayupo tena.
Unajua, wakati wa kuunganisha, seva haitaanguka kwenye OOM, kwa sababu wakati wa kuunganisha, kiasi cha RAM kinatumiwa tu kwa aina moja ndogo ya data. Kwa hiyo kila kitu kitakuwa sawa bila kujali kiasi cha data.
Vladimir Kolobaev: Sawa. Hapa wakati ni kwamba baada ya mdudu kusasishwa, nilipakua toleo jipya kwangu, na kwenye meza nyingine, ndogo, ambapo kuna sehemu nyingi, nilifanya operesheni kama hiyo. Na wakati wa kuunganisha, karibu 100 GB ya RAM ilichomwa kwenye seva. Nilikuwa na 150, 100 zilizoliwa, na dirisha la GB 50 lililosalia, kwa hivyo sikuanguka kwenye OOM.
Ni nini kinachonilinda kwa sasa nisianguke kwenye OOM ikiwa kweli hutumia GB 100 za RAM? Nini cha kufanya ikiwa ghafla RAM kwenye viunganisho itaisha?
Alexey Milovidov: Kuna tatizo kwamba matumizi ya RAM hasa kwa kuunganisha sio mdogo. Na shida ya pili ni kwamba ikiwa aina fulani ya unganisho imepewa, basi lazima itekelezwe kwa sababu imeandikwa kwenye logi ya replication. Rekodi ya urudufishaji ni vitendo vinavyohitajika ili kuleta nakala katika hali thabiti. Usipofanya ghiliba za mikono ambazo zitarudisha nyuma kumbukumbu hii ya kunakili, uunganishaji utalazimika kufanywa kwa njia moja au nyingine.
Kwa kweli, haitakuwa mbaya sana kuwa na kizuizi cha RAM ambacho "ikiwa tu" kinalinda dhidi ya OOM. Haitasaidia kuunganisha kukamilisha, itaanza tena, kufikia kizingiti fulani, kutupa ubaguzi, na kisha kuanza tena - hakuna kitu kizuri kitakachokuja kutoka kwa hili. Lakini kwa kanuni, itakuwa muhimu kuanzisha kizuizi hiki.
Je, kiendeshi cha Golang cha ClickHouse kitatengenezwa?
Dereva wa Golang, ambayo iliandikwa na Kirill Shvakov, sasa inaungwa mkono rasmi na timu ya ClickHouse. Yeye , sasa yeye ni mkubwa na halisi.
noti ndogo. Kuna hifadhi ya ajabu na ya kupendwa ya aina za kawaida za utaratibu usio na mwisho - hii ni Vertica. Pia wana dereva wao rasmi wa python, ambayo inaungwa mkono na watengenezaji wa Vertica. Na mara kadhaa ilitokea kwamba matoleo ya uhifadhi na matoleo ya dereva yalipungua kwa kasi, na dereva wakati fulani aliacha kufanya kazi. Na hatua ya pili. Msaada kwa dereva huyu rasmi, inaonekana kwangu, unafanywa na mfumo wa "chuchu" - unawaandikia suala, na hutegemea milele.
Nina maswali mawili. Sasa dereva wa Golang wa Kirill ni karibu njia chaguo-msingi ya kuwasiliana kutoka Golang na ClickHouse. Isipokuwa mtu bado anawasiliana kupitia kiolesura cha http kwa sababu anaipenda hivyo. Je, maendeleo ya dereva huyu yataendeleaje? Itasawazishwa na mabadiliko yoyote ya kuvunja kwenye hazina yenyewe? Na ni utaratibu gani wa kuzingatia suala?
Kirill Shvakov: Ya kwanza ni jinsi kila kitu kinavyopangwa kwa urasimu. Jambo hili halikujadiliwa, kwa hivyo sina cha kujibu.
Ili kujibu swali kuhusu suala hilo, tunahitaji historia kidogo ya dereva. Nilifanya kazi kwa kampuni ambayo ilikuwa na data nyingi. Ilikuwa spinner ya matangazo na idadi kubwa ya matukio ambayo yanahitajika kuhifadhiwa mahali fulani. Na wakati fulani ClickHouse ilionekana. Tuliijaza na data, na mwanzoni kila kitu kilikuwa sawa, lakini kisha ClickHouse ilianguka. Wakati huo tuliamua kwamba hatuhitaji.
Mwaka mmoja baadaye, tulirudi kwenye wazo la kutumia ClickHouse, na tulihitaji kuandika data huko kwa njia fulani. Ujumbe wa utangulizi ulikuwa huu: vifaa ni dhaifu sana, kuna rasilimali chache. Lakini tumefanya kazi kwa njia hii kila wakati, na kwa hivyo tuliangalia itifaki ya asili.
Kwa kuwa tulikuwa tukifanya kazi katika Go, ilikuwa wazi kwamba tulihitaji dereva wa Go. Nilifanya karibu muda wote - ilikuwa kazi yangu ya kazi. Tuliifikisha kwenye hatua fulani, na kwa kanuni hakuna mtu aliyedhani kwamba mtu mwingine yeyote isipokuwa sisi angeitumia. Kisha CloudFlare wakaja na tatizo lile lile, na kwa muda fulani tulifanya nao kazi vizuri sana, kwa sababu walikuwa na kazi zinazofanana. Kwa kuongezea, tulifanya hivi katika ClickHouse wenyewe na kwa dereva.
Wakati fulani, niliacha kuifanya, kwa sababu shughuli yangu katika suala la ClickHouse na kazi ilibadilika kidogo. Kwa hivyo masuala hayajafungwa. Mara kwa mara, watu wanaohitaji kitu wenyewe hujitolea kwenye hazina. Kisha mimi hutazama ombi la kuvuta na wakati mwingine mimi huhariri kitu mwenyewe, lakini hii hutokea mara chache.
Nataka kurudi kwa dereva. Miaka kadhaa iliyopita, wakati jambo hili lote lilianza, ClickHouse pia ilikuwa tofauti na yenye uwezo tofauti. Sasa tuna ufahamu wa jinsi ya kutengeneza tena dereva ili ifanye kazi vizuri. Ikiwa hii itatokea, basi toleo la 2 halitaendana kwa hali yoyote kwa sababu ya magongo yaliyokusanywa.
Sijui jinsi ya kupanga jambo hili. Mimi mwenyewe sina muda mwingi. Ikiwa watu wengine watamaliza udereva, ninaweza kuwasaidia na kuwaambia la kufanya. Lakini ushiriki wa kazi wa Yandex katika maendeleo ya mradi bado haujajadiliwa.
Alexey Milovidov: Kwa kweli, hakuna urasimu kuhusu madereva hawa bado. Jambo pekee ni kwamba zinawasilishwa kwa shirika rasmi, ambayo ni kwamba, dereva huyu anatambuliwa kama suluhisho rasmi la msingi la Go. Kuna madereva wengine, lakini wanakuja tofauti.
Hatuna maendeleo yoyote ya ndani kwa madereva hawa. Swali ni kama tunaweza kuajiri mtu binafsi, si kwa ajili ya dereva huyu, lakini kwa ajili ya maendeleo ya madereva wote wa jumuiya, au tunaweza kupata mtu kutoka nje.
Kamusi ya nje haipakii baada ya kuwasha upya na mpangilio wa lazy_load umewezeshwa. Nini cha kufanya?
Tuna mpangilio wa lazy_load kuwezeshwa, na baada ya seva kuwashwa upya, kamusi haipakii yenyewe. Inatolewa tu baada ya mtumiaji kufikia kamusi hii. Na mara ya kwanza ninapoifikia, inatoa hitilafu. Je, inawezekana kwa namna fulani kupakia kamusi kiotomatiki kwa kutumia ClickHouse, au unahitaji kudhibiti utayari wao kila wakati ili watumiaji wasipate makosa?
Labda tuna toleo la zamani la ClickHouse, kwa hivyo kamusi haikupakia kiotomatiki. Je, hii inaweza kuwa hivyo?
Kwanza, kamusi zinaweza kulazimishwa kupakiwa kwa kutumia hoja pakia upya kamusi za mfumo. Pili, kuhusu kosa - ikiwa kamusi tayari imepakiwa, basi maswali yatafanya kazi kulingana na data iliyopakiwa. Ikiwa kamusi bado haijapakiwa, itapakiwa moja kwa moja wakati wa ombi.
Hii si rahisi sana kwa kamusi nzito. Kwa mfano, unahitaji kuvuta safu milioni kutoka MySQL. Mtu hufanya chaguo rahisi, lakini chaguo hili litasubiri safu milioni sawa. Kuna suluhisho mbili hapa. Ya kwanza ni kuzima lazy_load. Pili, wakati seva iko juu, kabla ya kuweka mzigo juu yake, fanya pakia upya kamusi ya mfumo au fanya tu swali linalotumia kamusi. Kisha kamusi itapakiwa. Unahitaji kudhibiti upatikanaji wa kamusi na mpangilio wa lazy_load umewezeshwa, kwa sababu ClickHouse haizipakii kiotomatiki.
Jibu la swali la mwisho ni labda toleo ni la zamani au linahitaji kutatuliwa.
Nini cha kufanya na ukweli kwamba mfumo wa kupakia upya kamusi haipakii kamusi yoyote kati ya nyingi ikiwa angalau moja yao itaanguka na makosa?
Kuna swali lingine kuhusu kamusi za upakiaji upya wa mfumo. Tuna kamusi mbili - moja haijapakiwa, ya pili imejaa. Katika hali hii, kamusi za upakiaji upya wa Mfumo hazipakii kamusi yoyote, na inabidi upakie moja kwa moja moja maalum kwa jina lake kwa kutumia kamusi ya upakiaji upya wa mfumo. Je! hii pia inahusiana na toleo la ClickHouse?
Nataka kukufanya uwe na furaha. Tabia hii ilikuwa inabadilika. Hii ina maana kwamba ikiwa utasasisha ClickHouse, itabadilika pia. Ikiwa haufurahii na tabia yako ya sasa pakia upya kamusi za mfumo, sasisha, na tutegemee itabadilika kuwa bora.
Kuna njia ya kusanidi maelezo katika usanidi wa ClickHouse, lakini sio kuwaonyesha ikiwa kuna makosa?
Swali linalofuata ni kuhusu makosa yanayohusiana na kamusi, yaani maelezo. Tumebainisha maelezo ya muunganisho katika usanidi wa ClickHouse kwa kamusi, na ikiwa kuna hitilafu, tunapokea maelezo haya na nenosiri kwa kujibu.
Tulitatua hitilafu hii kwa kuongeza maelezo kwenye usanidi wa kiendeshaji cha ODBC. Kuna njia yoyote ya kusanidi maelezo katika usanidi wa ClickHouse, lakini usionyeshe maelezo haya ikiwa kuna makosa?
Suluhisho la kweli hapa ni kubainisha sifa hizi katika odbc.ini, na katika ClickHouse yenyewe taja tu Jina la Chanzo cha Data la ODBC. Hili halitafanyika kwa vyanzo vingine vya kamusi - wala kwa kamusi iliyo na MySQL, wala kwa zingine, hupaswi kuona nenosiri unapopokea ujumbe wa makosa. Kwa ODBC, nitaangalia pia - ikiwa iko, unahitaji tu kuiondoa.
Bonasi: asili kwa Zoom kutoka kwa mikusanyiko
Kwa kubofya picha, mandharinyuma ya bonasi kutoka kwenye mikusanyiko yatafunguliwa kwa wasomaji wanaoendelea zaidi. Tunazima moto pamoja na mascots ya teknolojia ya Avito, tunawasiliana na wenzetu kutoka kwa chumba cha msimamizi wa mfumo au klabu ya kompyuta ya shule ya zamani, na tunafanya mikutano ya kila siku chini ya daraja dhidi ya historia ya graffiti.
Chanzo: mapenzi.com