HighLoad++ Moscow 2018, Ukumbi wa Congress. Novemba 9, 15:00
Muhtasari na uwasilishaji:
Yuri Nasretdinov (VKontakte): ripoti itazungumzia kuhusu uzoefu wa kutekeleza ClickHouse katika kampuni yetu - kwa nini tunahitaji, ni kiasi gani cha data tunachohifadhi, jinsi tunavyoandika, na kadhalika.
Vifaa vya ziada:
Yuri Nasretdinov: - Salaam wote! Jina langu ni Yuri Nasretdinov, kama nimeshatambulishwa. Ninafanya kazi katika VKontakte. Nitazungumza juu ya jinsi tunavyoingiza data kwenye ClickHouse kutoka kwa meli zetu za seva (makumi ya maelfu).
Magogo ni nini na kwa nini kukusanya yao?
Tutakuambia nini: tulifanya nini, kwa nini tulihitaji "ClickHouse", mtawaliwa, kwa nini tuliichagua, ni aina gani ya utendaji unaweza takriban kupata bila kusanidi chochote haswa. Nitakuambia zaidi kuhusu majedwali ya bafa, kuhusu matatizo tuliyokuwa nayo na kuhusu masuluhisho yetu ambayo tulitengeneza kutoka kwa chanzo huria - KittenHouse na Lighthouse.
Kwa nini tulihitaji kufanya chochote (kila kitu ni nzuri kila wakati kwenye VKontakte, sawa?). Tulitaka kukusanya kumbukumbu za utatuzi (na kulikuwa na mamia ya terabytes ya data hapo), labda kwa njia fulani itakuwa rahisi zaidi kukokotoa takwimu; na tunayo kundi la makumi ya maelfu ya seva ambapo haya yote yanahitaji kufanywa.
Kwa nini tuliamua? Labda tulikuwa na suluhisho za kuhifadhi kumbukumbu. Hapa - kuna "Backend VK" ya umma kama hiyo. Ninapendekeza sana kujiandikisha kwake.
Kumbukumbu ni nini? Hii ni injini ambayo inarudisha safu tupu. Injini katika VK ni nini wengine huita microservices. Na hapa kuna kibandiko cha kutabasamu (imependeza sana). Jinsi gani? Naam, sikiliza zaidi!
Ni nini kinachoweza kutumika kuhifadhi kumbukumbu? Haiwezekani kutaja Hadup. Kisha, kwa mfano, Rsyslog (kuhifadhi kumbukumbu hizi kwenye faili). LSD. Nani anajua LSD ni nini? Hapana, sio LSD hii. Hifadhi faili, kwa mtiririko huo, pia. Kweli, ClickHouse ni chaguo la kushangaza.
Clickhouse na washindani: mahitaji na fursa
Tunataka nini? Tunataka kuhakikisha kuwa hatuhitaji kuwa na wasiwasi sana kuhusu operesheni, ili ifanye kazi nje ya boksi, ikiwezekana kwa usanidi mdogo. Tunataka kuandika mengi, na kuandika haraka. Na tunataka kuiweka kwa kila aina ya miezi, miaka, yaani, kwa muda mrefu. Huenda tukataka kuelewa tatizo ambalo walikuja nalo na kusema, "Kuna kitu hakifanyiki hapa," na hiyo ilikuwa miezi 3 iliyopita), na tunataka kuona kilichotokea miezi 3 iliyopita " Ukandamizaji wa data - ni wazi kwa nini itakuwa ya ziada - kwa sababu inapunguza kiasi cha nafasi inachukua.
Na tunayo mahitaji ya kuvutia kama haya: wakati mwingine tunaandika matokeo ya amri fulani (kwa mfano, magogo), inaweza kuwa zaidi ya kilobytes 4 kwa urahisi kabisa. Na ikiwa jambo hili linafanya kazi juu ya UDP, basi haina haja ya kutumia ... haitakuwa na "overhead" yoyote kwa uunganisho, na kwa idadi kubwa ya seva hii itakuwa pamoja.
Wacha tuone chanzo wazi kinatupa nini. Kwanza, tunayo Injini ya Magogo - hii ndiyo injini yetu; Kimsingi, anaweza kufanya kila kitu, anaweza hata kuandika mistari mirefu. Kweli, haibandishi data kwa uwazi - tunaweza kushinikiza safu kubwa sisi wenyewe ikiwa tunataka ... sisi, kwa kweli, hatutaki (ikiwezekana). Tatizo pekee ni kwamba anaweza tu kutoa kile kinachofaa katika kumbukumbu yake; Ili kusoma iliyobaki, unahitaji kupata binlog ya injini hii na, ipasavyo, inachukua muda mrefu sana.
Kuna chaguzi gani zingine? Kwa mfano, "Hadup". Urahisi wa kufanya kazi... Nani anadhani kuwa Hadup ni rahisi kusanidi? Bila shaka, hakuna matatizo na kurekodi. Wakati wa kusoma, wakati mwingine maswali hutokea. Kimsingi, ningesema labda sio, haswa kwa magogo. Uhifadhi wa muda mrefu - bila shaka, ndiyo, ukandamizaji wa data - ndiyo, kamba ndefu - ni wazi kwamba unaweza kurekodi. Lakini kurekodi kutoka kwa idadi kubwa ya seva ... Bado unapaswa kufanya kitu mwenyewe!
Rsyslog. Kwa kweli, tuliitumia kama chaguo la chelezo ili tuweze kuisoma bila kutupa binlog, lakini haiwezi kuandika mistari mirefu; kwa kanuni, haiwezi kuandika zaidi ya kilobaiti 4. Lazima ufanye ukandamizaji wa data kwa njia ile ile mwenyewe. Kusoma kutatoka kwa faili.
Kisha kuna maendeleo ya "badushka" ya LSD. Kimsingi ni sawa na "Rsyslog": inasaidia kamba ndefu, lakini haiwezi kufanya kazi kupitia UDP na, kwa kweli, kwa sababu ya hili, kwa bahati mbaya, mambo mengi kabisa yanahitaji kuandikwa tena huko. LSD inahitaji kusanifiwa upya ili kuweza kurekodi kutoka makumi ya maelfu ya seva.
Na hapa! Chaguo la kuchekesha ni ElasticSearch. Jinsi ya kusema? Anasoma vizuri, yaani, anasoma haraka, lakini sio vizuri sana katika kuandika. Kwanza, ikiwa inabana data, ni dhaifu sana. Uwezekano mkubwa zaidi, utafutaji kamili unahitaji miundo mikubwa ya data kuliko kiasi asili. Ni vigumu kufanya kazi na mara nyingi matatizo hutokea nayo. Na, tena, kurekodi katika Elastic - tunapaswa kufanya kila kitu sisi wenyewe.
Hapa ClickHouse ni chaguo bora, bila shaka. Jambo pekee ni kwamba kurekodi kutoka kwa makumi ya maelfu ya seva ni tatizo. Lakini angalau kuna tatizo moja, tunaweza kujaribu kutatua kwa namna fulani. Na ripoti iliyosalia inahusu tatizo hili. Ni aina gani ya utendaji unaweza kutarajia kutoka kwa ClickHouse?
Je, tutaiingizaje? MergeTree
Ni nani kati yenu ambaye hajasikia au kujua kuhusu "ClickHouse"? Ninahitaji kukuambia, sivyo? Haraka sana. Uingizaji hapo - gigabiti 1-2 kwa sekunde, kupasuka kwa hadi gigabiti 10 kwa sekunde kunaweza kuhimili usanidi huu - kuna Xeons mbili za msingi 6 (hiyo ni, hata isiyo na nguvu zaidi), gigabytes 256 za RAM, terabytes 20. katika RAID (hakuna mtu aliyesanidiwa, mipangilio chaguo-msingi). Alexey Milovidov, msanidi wa ClickHouse, labda ameketi huko akilia kwa sababu hatukusanidi chochote (kila kitu kilifanya kazi kama hiyo kwetu). Ipasavyo, kasi ya skanning, sema, kama mistari bilioni 6 kwa sekunde inaweza kupatikana ikiwa data imebanwa vizuri. Ikiwa unapenda % kwenye mfuatano wa maandishi - mistari milioni 100 kwa sekunde, yaani, inaonekana haraka sana.
Je, tutaiingizaje? Kweli, unajua kuwa VK hutumia PHP. Tutaingiza kutoka kwa kila mfanyakazi wa PHP kupitia HTTP kwenye "ClickHouse", kwenye jedwali la MergeTree kwa kila rekodi. Nani anaona tatizo na mpango huu? Kwa sababu fulani, sio kila mtu aliinua mikono yake. Ngoja nikuambie.
Kwanza, kuna seva nyingi - ipasavyo, kutakuwa na miunganisho mingi (mbaya). Kisha ni bora kuingiza data kwenye MergeTree si mara nyingi zaidi ya mara moja kwa pili. Na ni nani anayejua kwa nini? Sawa, sawa. Nitakuambia zaidi kidogo kuhusu hili. Swali lingine la kufurahisha ni kwamba hatufanyi uchanganuzi, hatuitaji kuboresha data, hatuitaji seva za kati, tunataka kuingiza moja kwa moja kwenye "ClickHouse" (ikiwezekana - moja kwa moja, bora zaidi).
Ipasavyo, kuingizwa kunafanywaje katika MergeTree? Kwa nini ni bora kuingiza ndani yake si mara nyingi zaidi ya mara moja kwa pili au chini mara nyingi? Ukweli ni kwamba "ClickHouse" ni hifadhidata ya safu na hupanga data kwa mpangilio wa ufunguo wa msingi, na unapoingiza, idadi ya faili huundwa angalau sawa na idadi ya safu ambazo data imepangwa. kwa utaratibu wa kupanda kwa ufunguo wa msingi (saraka tofauti imeundwa, seti ya faili kwenye diski kwa kila kuingiza). Kisha uingizaji unaofuata unakuja, na kwa nyuma wameunganishwa kwenye "partitions" kubwa. Kwa kuwa data imepangwa, inawezekana "kuunganisha" faili mbili zilizopangwa bila kutumia kumbukumbu nyingi.
Lakini, kama unavyoweza kudhani, ukiandika faili 10 kwa kila kuingiza, basi ClickHouse (au seva yako) itaisha haraka, kwa hiyo inashauriwa kuingiza katika makundi makubwa. Ipasavyo, hatukuwahi kuzindua mpango wa kwanza katika uzalishaji. Mara moja tulizindua moja, ambayo hapa Nambari 2 ina:
Hapa fikiria kuwa kuna seva elfu moja ambazo tumezindua, kuna PHP tu. Na kwenye kila seva kuna wakala wetu wa ndani, ambaye tulimwita "Kittenhouse", ambayo hudumisha uhusiano mmoja na "ClickHouse" na kuingiza data kila sekunde chache. Huingiza data si kwenye MergeTree, lakini kwenye jedwali la bafa, ambalo hutumika kwa usahihi ili kuepuka kuingiza moja kwa moja kwenye MergeTree mara moja.
Kufanya kazi na meza za buffer
Ni nini? Majedwali ya buffer ni kipande cha kumbukumbu ambacho kimegawanywa (hiyo ni, inaweza kuingizwa ndani yake mara kwa mara). Zinajumuisha vipande kadhaa, na kila moja ya vipande hufanya kazi kama buffer ya kujitegemea, na hupigwa kwa kujitegemea (ikiwa una vipande vingi kwenye buffer, basi kutakuwa na kuingiza nyingi kwa pili). Inawezekana kusoma kutoka kwa meza hizi - basi unasoma umoja wa yaliyomo kwenye buffer na meza ya wazazi, lakini kwa wakati huu uandishi umezuiwa, kwa hivyo ni bora kutosoma kutoka hapo. Na meza za buffer zinaonyesha QPS nzuri sana, yaani, hadi QPS elfu 3 huwezi kuwa na matatizo yoyote wakati wa kuingiza. Ni wazi kwamba ikiwa seva inapoteza nguvu, basi data inaweza kupotea, kwa sababu ilihifadhiwa tu kwenye kumbukumbu.
Wakati huo huo, mpango ulio na buffer unachanganya ALTER, kwa sababu kwanza unahitaji kuacha meza ya zamani ya buffer na mpango wa zamani (data haitapotea popote, kwa sababu itafutwa kabla ya meza kufutwa). Kisha "unabadilisha" jedwali unayohitaji na kuunda jedwali la bafa tena. Ipasavyo, ingawa hakuna jedwali la bafa, data yako haitatiririka popote, lakini unaweza kuwa nayo kwenye diski angalau ndani ya nchi.
Kittenhouse ni nini na inafanya kazije?
KittenHouse ni nini? Hii ni wakala. Nadhani lugha gani? Nilikusanya mada nyingi zaidi katika ripoti yangu - "Clickhouse", Nenda, labda nitakumbuka kitu kingine. Ndiyo, hii imeandikwa katika Go, kwa sababu sijui jinsi ya kuandika katika C, sitaki.
Ipasavyo, hudumisha muunganisho na kila seva na inaweza kuandika kwa kumbukumbu. Kwa mfano, ikiwa tunaandika kumbukumbu za makosa kwa Clickhouse, basi ikiwa Clickhouse haina wakati wa kuingiza data (baada ya yote, ikiwa imeandikwa nyingi), basi hatuna kuvimba kumbukumbu - tunatupa tu wengine. Kwa sababu ikiwa tunaandika gigabits kadhaa kwa sekunde ya makosa, basi tunaweza pengine kutupa nje. Kittenhouse inaweza kufanya hivyo. Zaidi, inaweza kufanya utoaji wa kuaminika, yaani, kuandika kwenye diski kwenye mashine ya ndani na mara moja kila wakati (huko, mara moja kila sekunde) inajaribu kutoa data kutoka kwa faili hii. Na mwanzoni tulitumia muundo wa kawaida wa Maadili - sio muundo fulani wa binary, muundo wa maandishi (kama katika SQL ya kawaida).
Lakini basi hii ilitokea. Tulitumia utoaji wa kuaminika, tukaandika magogo, kisha tukaamua (ilikuwa kikundi cha mtihani wa masharti) ... Iliwekwa nje kwa saa kadhaa na kuletwa nyuma, na uingizaji ulianza kutoka kwa seva elfu - ikawa kwamba Clickhouse bado ina "Thread kwenye unganisho" - ipasavyo, katika viunganisho elfu, kuingizwa kwa kazi husababisha wastani wa mzigo kwenye seva ya karibu elfu moja na nusu. Kwa kushangaza, seva ilikubali maombi, lakini data bado iliingizwa baada ya muda fulani; lakini ilikuwa ngumu sana kwa seva kuitumikia ...
Ongeza nginx
Suluhisho kama hilo kwa muundo wa Thread kwa unganisho ni nginx. Tuliweka nginx mbele ya Clickhouse, wakati huo huo tukaweka kusawazisha kwa nakala mbili (kasi yetu ya kuingiza iliongezeka kwa mara 2, ingawa sio ukweli kwamba hii inapaswa kuwa hivyo) na kupunguza idadi ya miunganisho kwa Clickhouse, kwa juu na, ipasavyo, zaidi, kuliko katika viunganisho 50, inaonekana hakuna maana ya kuingiza.
Kisha tuligundua kuwa kwa ujumla mpango huu una hasara, kwa sababu tuna nginx moja tu hapa. Ipasavyo, ikiwa nginx hii itaanguka, licha ya uwepo wa nakala, tunapoteza data au, angalau, usiandike popote. Ndio maana tulifanya kusawazisha mzigo wetu wenyewe. Tuligundua pia kuwa "Clickhouse" bado inafaa kwa magogo, na "pepo" pia alianza kuandika kumbukumbu zake katika "Clickhouse" - rahisi sana, kuwa waaminifu. Bado tunaitumia kwa "pepo" wengine.
Kisha tukagundua shida hii ya kupendeza: ikiwa unatumia njia isiyo ya kawaida ya kuingiza katika hali ya SQL, inalazimisha kichanganuzi kamili cha AST-based SQL, ambacho ni polepole sana. Ipasavyo, tumeongeza mipangilio ili kuhakikisha kuwa hili halifanyiki kamwe. Tulifanya kusawazisha mzigo, ukaguzi wa afya, ili mtu akifa, bado tunaacha data. Sasa tunayo meza nyingi sana ambazo tunahitaji kuwa na nguzo tofauti za Clickhouse. Na pia tulianza kufikiria matumizi mengine - kwa mfano, tulitaka kuandika kumbukumbu kutoka kwa moduli za nginx, lakini hawajui jinsi ya kuwasiliana kwa kutumia RPC yetu. Kweli, ningependa kuwafundisha jinsi ya kutuma angalau kwa njia fulani - kwa mfano, kupokea matukio kwenye localhost kupitia UDP na kisha kuyasambaza kwa Clickhouse.
Hatua moja mbali na suluhisho
Mpango wa mwisho ulianza kuonekana kama hii (toleo la nne la mpango huu): kwenye kila seva mbele ya Clickhouse kuna nginx (kwenye seva hiyo hiyo) na proxies tu maombi ya localhost na kikomo juu ya idadi ya miunganisho ya vipande 50. . Na mpango huu ulikuwa tayari ukifanya kazi, kila kitu kilikuwa kizuri nacho.
Tuliishi hivi kwa takriban mwezi mmoja. Kila mtu alifurahi, waliongeza meza, waliongeza, waliongeza ... Kwa ujumla, ikawa kwamba njia tuliyoongeza meza za buffer haikuwa bora sana (hebu tuweke hivyo). Tulifanya vipande 16 katika kila meza na muda wa sekunde kadhaa; tulikuwa na meza 20 na kila meza ilipokea kuingiza 8 kwa pili - na kwa wakati huu "Clickhouse" ilianza ... rekodi zilianza kupungua. Hawakupitia hata ... Nginx kwa chaguo-msingi ilikuwa na jambo la kuvutia sana kwamba ikiwa miunganisho iliishia kwenye mto, basi ilirudi tu "502" kwa maombi yote mapya.
Na hapa tunayo (niliangalia magogo kwenye Clickhouse yenyewe) karibu nusu ya asilimia ya maombi yalishindwa. Ipasavyo, utumiaji wa diski ulikuwa juu, kulikuwa na unganisho nyingi. Naam, nilifanya nini? Kwa kawaida, sikujisumbua kujua kwa nini uunganisho na mkondo wa juu uliisha.
Kubadilisha nginx na proksi ya nyuma
Niliamua kwamba tunahitaji kudhibiti hili sisi wenyewe, hatuna haja ya kuiacha kwa nginx - nginx haijui ni meza gani kwenye Clickhouse, na nikabadilisha nginx na proksi ya reverse, ambayo pia niliandika mwenyewe.
Anafanya nini? Inafanya kazi kulingana na maktaba ya fasthttp "goshnoy", ambayo ni, haraka, karibu haraka kama nginx. Samahani, Igor, ikiwa upo hapa (kumbuka: Igor Sysoev ni mtayarishaji programu wa Kirusi aliyeunda seva ya wavuti ya nginx). Inaweza kuelewa ni aina gani ya maswali haya - WEKA au CHAGUA - ipasavyo, ina miunganisho tofauti kwa aina tofauti za hoja.
Ipasavyo, hata kama hatuna muda wa kukamilisha maombi ya kuingiza, "chaguzi" zitapita, na kinyume chake. Na inaweka data katika majedwali ya bafa - na bafa ndogo: ikiwa kungekuwa na makosa yoyote, makosa ya sintaksia, na kadhalika - ili yasiathiri sana data iliyobaki, kwa sababu tunapoingiza tu kwenye jedwali la buffer, ilikuwa na "bachi" ndogo, na makosa yote ya syntax yaliathiri tu kipande hiki kidogo; na hapa tayari zitaathiri bafa kubwa. Ndogo ni megabyte 1, ambayo ni, sio ndogo sana.
Kuingiza maingiliano na kimsingi kuchukua nafasi ya nginx, hufanya jambo lile lile ambalo nginx ilifanya hapo awali - hauitaji kubadilisha "Kittenhouse" ya ndani kwa hili. Na kwa kuwa hutumia harakahttp, ni haraka sana - unaweza kufanya maombi zaidi ya elfu 100 kwa sekunde moja kwa uwekaji mmoja kupitia proksi ya nyuma. Kinadharia, unaweza kuingiza mstari mmoja kwa wakati kwenye wakala wa reverse wa kittenhouse, lakini bila shaka hatufanyi hivyo.
Mpango huo ulianza kuonekana kama hii: "Kittenhouse", wakala wa nyuma hukusanya maombi mengi kwenye meza na, kwa upande wake, meza za buffer huziingiza kwenye kuu.
Killer ni suluhisho la muda, Kitten ni ya kudumu
Hili ni tatizo la kuvutia... Je, kuna yeyote kati yenu aliyetumia fasthttp? Nani alitumia fasthttp na maombi ya POST? Labda, hii haikupaswa kufanywa, kwa sababu huhifadhi mwili wa ombi kwa chaguo-msingi, na saizi yetu ya bafa iliwekwa kuwa megabytes 16. Uingizaji huo uliacha kuendelea wakati fulani, na vipande vya megabyte 16 vilianza kuwasili kutoka kwa makumi ya maelfu ya seva, na zote zilihifadhiwa kwenye kumbukumbu kabla ya kutumwa kwa Clickhouse. Ipasavyo, kumbukumbu iliisha, Killer Out-Of-Memory Killer alikuja na kuua proksi ya nyuma (au "Clickhouse", ambayo inaweza "kula" kinadharia zaidi kuliko proksi ya nyuma). Mzunguko ulijirudia. Sio shida ya kupendeza sana. Ingawa tulijikwaa juu ya hii tu baada ya miezi kadhaa ya operesheni.
Nilichofanya? Tena, sipendi kuelewa ni nini hasa kilitokea. Nadhani ni dhahiri kuwa haupaswi kubaki kwenye kumbukumbu. Sikuweza kiraka harakahttp, ingawa nilijaribu. Lakini nilipata njia ya kuifanya ili hakuna haja ya kuunganisha chochote, na nilikuja na njia yangu mwenyewe katika HTTP - niliiita KITTEN. Kweli, ni mantiki - "VK", "Kitten"... Nini kingine? ..
Ikiwa ombi linakuja kwa seva na njia ya Kitten, basi seva inapaswa kujibu "meow" - kimantiki. Ikiwa anajibu kwa hili, basi inachukuliwa kuwa anaelewa itifaki hii, na kisha ninakataza unganisho (fasthttp ina njia kama hiyo), na unganisho huenda kwenye hali ya "mbichi". Kwa nini ninahitaji? Ninataka kudhibiti jinsi kusoma kutoka kwa miunganisho ya TCP hufanyika. TCP ina mali ya ajabu: ikiwa hakuna mtu anayesoma kutoka upande mwingine, basi uandishi huanza kusubiri, na kumbukumbu haitumiwi hasa kwa hili.
Na kwa hivyo nilisoma kutoka kwa wateja wapatao 50 kwa wakati mmoja (kutoka hamsini kwa sababu hamsini inapaswa kuwa ya kutosha, hata kama kiwango kinatoka kwa DC mwingine)... Matumizi yamepungua kwa njia hii angalau mara 20, lakini mimi, kuwa waaminifu. , sikuweza kupima hasa wakati gani, kwa sababu tayari haina maana (tayari imefikia kiwango cha makosa). Itifaki ni ya binary, yaani, ina jina la meza na data; hakuna vichwa vya http, kwa hivyo sikutumia tundu la wavuti (siitaji kuwasiliana na vivinjari - nilitengeneza itifaki inayolingana na mahitaji yetu). Na kila kitu kilikuwa sawa naye.
Jedwali la bafa linasikitisha
Hivi majuzi tulipata kipengele kingine cha kuvutia cha meza za bafa. Na shida hii tayari ni chungu zaidi kuliko wengine. Hebu fikiria hali hii: tayari unatumia Clickhouse kikamilifu, una seva nyingi za Clickhouse, na una maombi ambayo huchukua muda mrefu sana kusoma (hebu sema, zaidi ya sekunde 60); na unakuja na kufanya Alter kwa wakati huu... Kwa sasa, "teua" zilizoanza kabla ya "Alter" hazitajumuishwa kwenye jedwali hili, "Alter" haitaanza - labda baadhi ya vipengele vya jinsi "Clickhouse" inavyofanya kazi katika hapa. Labda hii inaweza kurekebishwa? Au haiwezekani?
Kwa ujumla, ni wazi kuwa kwa kweli hii sio shida kubwa, lakini kwa meza za buffer inakuwa chungu zaidi. Kwa sababu, kama, tuseme, muda wako wa Alter umekwisha (na huenda muda ukaisha kwa mwenyeji mwingine - sio wako, lakini kwenye nakala, kwa mfano), basi... Ulifuta jedwali la bafa, Alter yako (au mwenyeji mwingine. ) muda umeisha. kisha hitilafu ya "Badilisha" imetokea) - bado unahitaji kuhakikisha kuwa data inaendelea kuandikwa: unaunda majedwali ya bafa nyuma (kulingana na mpango sawa na jedwali kuu), kisha "Badilisha" huenda. kupitia, huisha baada ya yote, na buffer meza huanza kutofautiana katika schema kutoka kwa mzazi. Kulingana na "Alter" ilikuwa nini, ingizo linaweza lisiende tena kwenye jedwali hili la bafa - hii inasikitisha sana.
Pia kuna ishara kama hiyo (labda mtu aliiona) - inaitwa query_thread_log katika matoleo mapya ya Clickhouse. Kwa msingi, katika toleo fulani kulikuwa na moja. Hapa tumekusanya rekodi milioni 840 katika miezi michache (gigabytes 100). Hii ni kutokana na ukweli kwamba "kuingiza" ziliandikwa pale (labda, kwa njia, hazijaandikwa sasa). Kama nilivyokuambia, "viingilio" vyetu ni vidogo - tulikuwa na "viingilio" vingi kwenye meza za bafa. Ni wazi kuwa hii imezimwa - ninakuambia tu nilichoona kwenye seva yetu. Kwa nini? Hii ni hoja nyingine dhidi ya kutumia meza za buffer! Spotty inasikitisha sana.
Nani alijua kuwa huyu jamaa anaitwa Spotty? Wafanyikazi wa VK waliinua mikono yao. SAWA.
Kuhusu mipango ya "KitttenHouse"
Mipango kawaida haishirikiwi, sivyo? Ghafla hutawatimizia na hautaonekana vizuri sana machoni pa watu wengine. Lakini nitachukua hatari! Tunataka kufanya yafuatayo: meza za bafa, inaonekana kwangu, bado ni mkongojo na tunahitaji kuachilia uingizaji sisi wenyewe. Lakini bado hatutaki kuiwekea akiba kwenye diski, kwa hivyo tutaweka bafa uwekaji kwenye kumbukumbu.
Ipasavyo, "ingizo" inapotengenezwa, haitakuwa sawa - tayari itafanya kazi kama jedwali la buffer, itaingiza kwenye jedwali la wazazi (vizuri, siku moja baadaye) na kuripoti kupitia chaneli tofauti ambayo viingilio vimepita na ambavyo hawana.
Kwa nini siwezi kuacha kipengee cha kusawazisha? Inafaa zaidi. Ukweli ni kwamba ikiwa utaingiza kutoka kwa majeshi elfu 10, basi kila kitu ni sawa - utapata kidogo kutoka kwa kila mwenyeji, ukiingiza huko mara moja kwa pili, kila kitu ni sawa. Lakini ningependa mpango huu ufanye kazi, kwa mfano, kutoka kwa mashine mbili, ili uweze kupakua kwa kasi ya juu - labda usipate upeo kutoka kwa Clickhouse, lakini andika angalau megabytes 100 kwa pili kutoka kwa mashine moja kupitia wakala wa nyuma - mpango huu lazima uongezwe kwa idadi kubwa na ndogo, kwa hivyo hatuwezi kungojea sekunde kwa kila uingilizi, kwa hivyo lazima iwe sawa. Na kwa njia hiyo hiyo, uthibitisho wa asynchronous unapaswa kuja baada ya kuingizwa kukamilika. Tutajua ikiwa imepita au la.
Jambo muhimu zaidi ni kwamba katika mpango huu tunajua kwa hakika ikiwa uingizaji ulifanyika au la. Hebu fikiria hali hii: una meza ya buffer, uliandika kitu ndani yake, na kisha, hebu sema, meza iliingia katika hali ya kusoma tu na kujaribu kufuta buffer. Data itaenda wapi? Watabaki kwenye buffer. Lakini hatuwezi kuwa na uhakika wa hili - ni nini ikiwa kuna hitilafu nyingine, kutokana na ambayo data haitabaki kwenye buffer ... (Anwani Alexey Milovidov, Yandex, ClickHouse developer) Au itabaki? Kila mara? Alexey anatushawishi kuwa kila kitu kitakuwa sawa. Hatuna sababu ya kutomwamini. Lakini sawa: ikiwa hatutumii meza za buffer, basi hakutakuwa na matatizo yoyote nao. Kuunda meza mara mbili pia sio ngumu, ingawa kwa kanuni hakuna shida kubwa. Huu ndio mpango.
Hebu tuzungumze kuhusu kusoma
Sasa hebu tuzungumze juu ya kusoma. Pia tuliandika zana yetu hapa. Inaweza kuonekana, vizuri, kwa nini uandike chombo chako hapa? .. Na ni nani aliyetumia Tabix? Kwa namna fulani watu wachache waliinua mikono yao ... Na ni nani anayeridhika na utendaji wa Tabix? Kweli, hatufurahii nayo, na sio rahisi sana kutazama data. Ni sawa kwa uchanganuzi, lakini kwa kutazama tu haijaboreshwa. Kwa hivyo niliandika yangu mwenyewe, interface yangu mwenyewe.
Ni rahisi sana - inaweza tu kusoma data. Hajui jinsi ya kuonyesha michoro, hajui jinsi ya kufanya chochote. Lakini inaweza kuonyesha kile tunachohitaji: kwa mfano, ni safu ngapi kwenye meza, ni nafasi ngapi inachukua (bila kuivunja kwenye safu), yaani, interface ya msingi sana ndiyo tunayohitaji.
Na inaonekana sawa na Sequel Pro, lakini imetengenezwa tu kwenye Bootstrap ya Twitter, na toleo la pili. Unauliza: "Yuri, kwa nini kwenye toleo la pili?" Mwaka gani? 2018? Kwa ujumla, nilifanya hivi muda mrefu uliopita kwa "Misuli" (MySQL) na nilibadilisha tu mistari kadhaa kwenye maswali huko, na ilianza kufanya kazi kwa "Clickhouse", ambayo shukrani maalum! Kwa sababu mjumbe ni sawa na "misuli", na maswali ni sawa - rahisi sana, haswa mwanzoni.
Kweli, inaweza kuchuja meza, inaweza kuonyesha muundo na yaliyomo kwenye jedwali, hukuruhusu kupanga, kuchuja kwa safuwima, inaonyesha swali lililosababisha matokeo, safu zilizoathiriwa (matokeo ngapi), ambayo ni, mambo ya msingi ya kuangalia data. Haraka sana.
Pia kuna mhariri. Nilijaribu kwa uaminifu kuiba mhariri mzima kutoka kwa Tabix, lakini sikuweza. Lakini kwa namna fulani inafanya kazi. Kimsingi, hiyo ndiyo yote.
"Clickhouse" inafaa kwa pango
Ninataka kukuambia kwamba Clickhouse, licha ya matatizo yote yaliyoelezwa, inafaa sana kwa magogo. Muhimu zaidi, hutatua tatizo letu - ni haraka sana na inakuwezesha kuchuja magogo kwa safu. Kimsingi, meza za buffer hazijafanya vizuri, lakini kwa kawaida hakuna mtu anayejua kwa nini ... Labda sasa unajua vizuri zaidi ambapo utakuwa na matatizo.
TCP? Kwa ujumla, katika VK ni desturi kutumia UDP. Na nilipotumia TCP... Bila shaka, hakuna mtu aliyeniambia: “Yuri, unazungumzia nini! Hauwezi, unahitaji UDP." Ilibadilika kuwa TCP sio ya kutisha sana. Jambo pekee ni, ikiwa una makumi ya maelfu ya misombo ya kazi unayoandika, unahitaji kuitayarisha kwa uangalifu zaidi; lakini inawezekana, na ni rahisi kabisa.
Niliahidi kuchapisha "Kittenhouse" na "Lighthouse" kwenye HighLoad Siberia ikiwa kila mtu alijiandikisha kwa "VK backend" yetu ya umma ... Na unajua, sio kila mtu alijiandikisha ... Bila shaka, sitakuomba ujiandikishe kwenye tovuti yetu. umma. Bado kuna wengi wenu, mtu anaweza hata kukasirika, lakini bado, tafadhali jiandikishe (na hapa lazima nifanye macho kama ya paka). Hiyo ni . Asante sana! Github ni yetu . Kwa Clickhouse nywele yako itakuwa laini na silky.
Anayeongoza: - Marafiki, sasa kwa maswali. Mara tu baada ya kuwasilisha cheti cha shukrani na ripoti yako kuhusu VHS.
Yuri Nasretdinov (baadaye anajulikana kama YN): - Uliwezaje kurekodi ripoti yangu kuhusu VHS ikiwa itaisha tu?
Anayeongoza: - Pia huwezi kuamua kikamilifu jinsi "Clickhouse" itafanya kazi au la! Marafiki, dakika 5 kwa maswali!
maswali
Swali kutoka kwa hadhira (hapa inajulikana kama Q): - Mchana mzuri. Asante sana kwa ripoti. Nina maswali mawili. Nitaanza na kitu kisicho na maana: je, idadi ya barua t kwa jina "Kittenhouse" kwenye michoro (3, 4, 7 ...) huathiri kuridhika kwa paka?
YN: - Kiasi cha nini?
З: - Barua t. Kuna t tatu, mahali fulani karibu na t tatu.
YN: - Je, sikuirekebisha? Naam, bila shaka inafanya! Hizi ni bidhaa tofauti - nilikuwa nikikudanganya tu wakati huu wote. Sawa, ninatania - haijalishi. Ah, hapa! Hapana, ni kitu kimoja, nilifanya makosa ya kuchapa.
З: - Asante. Swali la pili ni zito. Kwa kadiri ninavyoelewa, katika Clickhouse, meza za bafa huishi kwa kumbukumbu pekee, hazijaangaziwa kwenye diski na, ipasavyo, haziendelei.
YN: - Ndiyo.
З: - Na wakati huo huo, mteja wako huweka akiba kwenye diski, ambayo inamaanisha dhamana fulani ya uwasilishaji wa kumbukumbu hizi. Lakini hii haijahakikishwa kwa njia yoyote katika Clickhouse. Eleza jinsi dhamana inafanywa, kutokana na nini? .. Hapa kuna utaratibu huu kwa undani zaidi
YN: - Ndio, kinadharia hakuna ukinzani hapa, kwa sababu wakati Clickhouse inapoanguka, unaweza kugundua kwa njia tofauti milioni. Ikiwa Clickhouse itaacha kufanya kazi (ikiwa itaisha vibaya), unaweza, kwa kusema, kurudisha nyuma kidogo kumbukumbu yako uliyoandika na kuanza kutoka wakati kila kitu kilikuwa sawa. Wacha tuseme unarudisha nyuma kwa dakika, ambayo ni, inachukuliwa kuwa umefuta kila kitu kwa dakika.
З: - Hiyo ni, "Kittenhouse" inashikilia dirisha kwa muda mrefu na, ikiwa ni kuanguka, inaweza kuitambua na kuirudisha nyuma?
YN: - Lakini hii ni katika nadharia. Kwa mazoezi, hatufanyi hivi, na utoaji wa kuaminika ni kutoka kwa sifuri hadi nyakati zisizo na mwisho. Lakini kwa wastani moja. Tumeridhika kwamba ikiwa Clickhouse itaacha kufanya kazi kwa sababu fulani au seva "kuwasha upya," basi tunapoteza kidogo. Katika visa vingine vyote, hakuna kitakachotokea.
З: - Habari. Tangu mwanzo kabisa ilionekana kwangu kuwa ungekuwa unatumia UDP tangu mwanzo wa ripoti. Una http, yote hayo... Na shida nyingi ulizoelezea, kama ninavyoelewa, zilisababishwa na suluhisho hili ...
YN: Je, tunatumia TCP nini?
З: - Kimsingi ndiyo.
YN: - Hapana.
З: - Ilikuwa na fasthttp kwamba ulikuwa na matatizo, na muunganisho ulikuwa na matatizo. Ikiwa ungetumia UDP tu ungejiokoa kwa muda. Kweli, kungekuwa na shida na ujumbe mrefu au kitu kingine ...
YN: - Na nini?
З: - Pamoja na ujumbe mrefu, kwa kuwa hauwezi kuingia kwenye MTU, kitu kingine ... Naam, kunaweza kuwa na matatizo yao wenyewe. Swali ni: kwa nini sio UDP?
YN: - Ninaamini kuwa waandishi waliotengeneza TCP/IP ni werevu kuliko mimi na wanajua bora kuliko mimi jinsi ya kusasisha pakiti (ili ziende), wakati huo huo kurekebisha dirisha la kutuma, sio kupakia mtandao kupita kiasi, toa maoni juu ya nini haijasomwa, bila kuhesabu upande wa pili ... Shida zote hizi, kwa maoni yangu, zingekuwepo katika UDP, tu ningelazimika kuandika nambari zaidi kuliko nilivyoandika tayari ili kutekeleza jambo lile lile mimi mwenyewe na uwezekano mkubwa. hafifu. Sipendi hata kuandika kwa C, achilia hapo ...
З: - Inafaa tu! Imetumwa sawa na usisubiri chochote - ni sawa kabisa. Arifa ilirudi kwamba kila kitu kiko sawa - hiyo inamaanisha ilifika; Ikiwa haikuja, inamaanisha kuwa ni mbaya.
YN: - Nahitaji zote mbili - ninahitaji kuwa na uwezo wa kutuma zote mbili kwa dhamana ya kujifungua na bila dhamana ya kujifungua. Haya ni matukio mawili tofauti. Sihitaji kupoteza magogo kadhaa au nisiyapoteze kwa sababu.
З: - Sitapoteza wakati. Hili linahitaji kujadiliwa zaidi. Asante.
Anayeongoza: - Nani ana maswali - mikono mbinguni!
З: - Habari, mimi ni Sasha. Mahali fulani katikati ya ripoti, hisia ilionekana kwamba, pamoja na TCP, inawezekana kutumia suluhisho tayari - aina fulani ya Kafka.
YN: - Naam ... nilikuambia kwamba sitaki kutumia seva za kati, kwa sababu ... huko Kafka, inageuka kuwa tuna majeshi elfu kumi; kwa kweli, tuna zaidi - makumi ya maelfu ya majeshi. Inaweza pia kuwa chungu kufanya na Kafka bila wakala wowote. Kwa kuongeza, muhimu zaidi, bado inatoa "latency", inatoa majeshi ya ziada ambayo unahitaji kuwa nayo. Lakini sitaki kuwa nao - nataka ...
З: "Lakini mwishowe ikawa hivyo."
YN: - Hapana, hakuna mwenyeji! Hii yote inafanya kazi kwa wapangishi wa Clickhouse.
З: - Kweli, na "Kittenhouse", ambayo ni kinyume - anaishi wapi?
YN: - Kwenye mwenyeji wa Clickhouse, haiandiki chochote kwenye diski.
З: - Wacha tuseme.
Anayeongoza: - Je, umeridhika? Je, tunaweza kukupa mshahara?
З: - Ndio unaweza. Kwa kweli, kuna magongo mengi ili kupata kitu kimoja, na sasa - jibu la awali juu ya mada ya TCP inapingana, kwa maoni yangu, hali hii. Inahisi kama kila kitu kingeweza kufanywa kwa magoti yangu kwa muda mfupi zaidi.
YN: - Na pia kwa nini sikutaka kutumia Kafka, kwa sababu kulikuwa na malalamiko mengi kwenye gumzo la Clickhouse Telegram kwamba, kwa mfano, ujumbe kutoka Kafka ulipotea. Sio kutoka kwa Kafka yenyewe, lakini katika ushirikiano wa Kafka na Clickhaus; au kitu hakikuunganishwa hapo. Kwa kusema, itakuwa muhimu kuandika mteja kwa Kafka basi. Sidhani kama kunaweza kuwa na suluhisho rahisi au la kuaminika zaidi.
З: - Niambie, kwa nini hukujaribu foleni yoyote au aina fulani ya basi ya kawaida? Kwa kuwa unasema kwamba kwa asynchrony unaweza kutuma kumbukumbu zenyewe kupitia foleni na kupokea jibu bila mpangilio kupitia foleni?
YN: - Tafadhali pendekeza ni foleni gani zinaweza kutumika?
З: - Yoyote, hata bila dhamana ya kuwa iko katika mpangilio. Aina fulani ya Redis, RMQ...
YN: - Nina hisia kwamba Redis uwezekano mkubwa hautaweza kuvuta kiasi kama hicho cha kuingizwa hata kwenye mwenyeji mmoja (kwa maana ya seva kadhaa) ambayo huchota Clickhouse. Siwezi kuunga mkono hii na ushahidi wowote (sijaiweka alama), lakini inaonekana kwangu kuwa Redis sio suluhisho bora hapa. Kimsingi, mfumo huu unaweza kuzingatiwa kama foleni ya ujumbe ulioboreshwa, lakini iliyoundwa kwa ajili ya "Clickhouse" pekee.
Anayeongoza: - Yuri, asante sana. Napendekeza kumalizia maswali na majibu hapa na kusema ni nani kati ya waliouliza swali tutampa kitabu.
YN: - Ningependa kutoa kitabu kwa mtu wa kwanza ambaye aliuliza swali.
Anayeongoza: - Ajabu! Kubwa! Fabulous! Asante sana!
Baadhi ya matangazo 🙂
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com