Í apríl komu Avito verkfræðingar saman til funda á netinu með aðal ClickHouse verktaki Alexey Milovidov og Kirill Shvakov, Golang verktaki frá Integros. Við ræddum hvernig við notum gagnagrunnsstjórnunarkerfi og hvaða erfiðleika við lendum í.
Byggt á fundinum höfum við tekið saman grein með svörum sérfræðinga við spurningum okkar og áhorfenda um öryggisafrit, endurhleðslu gagna, utanaðkomandi orðabækur, Golang bílstjórann og uppfærslu ClickHouse útgáfur. Það gæti verið gagnlegt fyrir forritara sem eru nú þegar virkir að vinna með Yandex DBMS og hafa áhuga á nútíð og framtíð þess. Sjálfgefið er að svörin séu eftir Alexey Milovidov, nema annað sé skrifað.
Farðu varlega, það er mikill texti undir skurðinum. Við vonum að innihaldið með spurningum hjálpi þér að rata.
efni
Ef þú vilt ekki lesa textann geturðu horft á upptökuna af samkomunum . Tímakóðar eru í fyrstu athugasemd undir myndbandinu.
ClickHouse er stöðugt uppfært, en gögnin okkar eru það ekki. Hvað á að gera við því?
ClickHouse er stöðugt uppfært og gögnin okkar, sem voru fíngerð endanlega unnin, eru ekki uppfærð og eru í öryggisafriti.
Segjum að við höfum átt í vandræðum og gögnin týndust. Við ákváðum að endurheimta og það kom í ljós að gömlu skiptingarnar, sem eru geymdar á öryggisafritunarþjónunum, eru mjög frábrugðnar þeirri útgáfu sem nú er notuð af ClickHouse. Hvað á að gera í slíkum aðstæðum og er það mögulegt?
Aðstæður þar sem þú endurheimtir gögn úr öryggisafriti á gömlu sniði, en það tengist ekki nýju útgáfunni, er ómögulegt. Við tryggjum að gagnasniðið í ClickHouse haldist alltaf afturábak samhæft. Þetta er miklu mikilvægara en afturábak samhæfni í virkni ef hegðun sumra sjaldan notaðra aðgerða hefur breyst. Nýja útgáfan af ClickHouse ætti alltaf að geta lesið gögnin sem eru geymd á disknum. Þetta eru lögin.
Hver eru núverandi bestu starfsvenjur til að taka öryggisafrit af gögnum frá ClickHouse?
Hvernig á að taka öryggisafrit, að teknu tilliti til þess að við höfum fínstillt lokaaðgerðir, risastóran gagnagrunn af terabætum og gögn sem eru uppfærð, til dæmis, síðustu þrjá daga, og þá gerast engar aðgerðir við það?
Við getum búið til okkar eigin lausn og skrifað á bash: safna þessum öryggisafritum á svona og þannig hátt. Kannski er óþarfi að hækja neitt og reiðhjólið var fundið upp fyrir löngu?
Byrjum á bestu starfsvenjunum. Samstarfsmenn mínir ráðleggja alltaf, sem svar við spurningum um öryggisafrit, að minna þá á Yandex.Cloud þjónustuna, þar sem þetta vandamál hefur þegar verið leyst. Svo notaðu það ef mögulegt er.
Það er engin heildarlausn fyrir öryggisafrit, hundrað prósent innbyggð í ClickHouse. Það eru nokkrar eyður sem hægt er að nota. Til að fá heildarlausn þarftu annað hvort að fikta aðeins handvirkt eða búa til umbúðir í formi skrifta.
Ég mun byrja á einföldustu lausnunum og enda á þeim flóknustu, allt eftir gagnamagni og stærð klasans. Því stærri sem klasinn er, því flóknari verður lausnin.
Ef taflan með gögnum tekur aðeins nokkur gígabæt er hægt að taka öryggisafrit á þennan hátt:
- Vista töfluskilgreiningu þ.e. lýsigögn − sýna búa til töflu.
- Búðu til sorp með því að nota ClickHouse biðlarann - velja * frá borði að skrá. Sjálfgefið er að þú færð skrá á TabSeparated sniði. Ef þú vilt vera skilvirkari geturðu gert það á Native sniði.
Ef gagnamagnið er meira mun öryggisafritið taka lengri tíma og mikið pláss. Þetta er kallað rökrétt öryggisafrit; það er ekki bundið við ClickHouse gagnasniðið. Ef svo er, þá geturðu sem síðasta úrræði tekið öryggisafrit og hlaðið því upp á MySQL til endurheimtar.
Fyrir lengra komna tilvik hefur ClickHouse innbyggða getu til að búa til skyndimynd af skiptingum í staðbundnu skráarkerfi. Þessi eiginleiki er fáanlegur sem beiðni breyta töflufrysti skiptingunni. Eða einfaldlega breyta borðfrystingu - þetta er skyndimynd af öllu borðinu.
Skyndimyndin verður búin til stöðugt fyrir eina töflu á einni brot, það er, það er ómögulegt að búa til samræmda skyndimynd af öllu þyrpingunni á þennan hátt. En fyrir flest verkefni er engin slík þörf, og það er nóg að framkvæma beiðni á hverri brot og fá samræmda skyndimynd. Það er búið til í formi harðlenka og tekur því ekki aukapláss. Næst afritarðu þessa skyndimynd á afritunarþjóninn eða í geymsluna sem þú notar fyrir afrit.
Það er frekar auðvelt að endurheimta slíkt öryggisafrit. Fyrst skaltu búa til töflur með því að nota núverandi töfluskilgreiningar. Næst skaltu afrita vistaðar skyndimyndir af skiptingunum í Directory-Detached fyrir þessar töflur og keyra fyrirspurnina festa skipting. Þessi lausn hentar vel fyrir alvarlegustu gagnamagn.
Stundum þarftu eitthvað enn svalara - í þeim tilvikum þar sem þú ert með tugi eða jafnvel hundruð terabæta á hverjum netþjóni og hundruð netþjóna. Það er lausn hér sem ég tók upp frá samstarfsmönnum mínum frá Yandex.Metrica. Ég myndi ekki mæla með henni fyrir alla - lestu hana og ákváðu sjálfur hvort hún henti eða ekki.
Fyrst þarftu að búa til nokkra netþjóna með stórum diskahillum. Næst skaltu hækka nokkra ClickHouse netþjóna á þessum netþjónum og stilla þá þannig að þeir virki sem önnur eftirmynd fyrir sömu brotin. Og notaðu síðan skráarkerfi eða eitthvað tól á þessum netþjónum sem gerir þér kleift að búa til skyndimyndir. Hér eru tveir kostir. Fyrsti valkosturinn er LVM skyndimynd, seinni valkosturinn er ZFS á Linux.
Eftir það, á hverjum degi sem þú þarft að búa til skyndimynd, mun hún liggja og taka pláss. Auðvitað, ef gögnin breytast, mun plássið aukast með tímanum. Þessa skyndimynd er hægt að taka út hvenær sem er og endurheimta gögnin, svo undarleg lausn. Auk þess þurfum við líka að takmarka þessar eftirmyndir í stillingunum svo þær reyni ekki að verða leiðtogar.
Verður hægt að skipuleggja stýrða töf eftirlíkinga í stokkunum?
Á þessu ári ætlar þú að búa til stokka í ClickHouse. Verður hægt að skipuleggja stýrða töf eftirlíkinga í þeim? Við viljum nota það til að verja okkur fyrir neikvæðum aðstæðum með breytingum og öðrum breytingum.
Er hægt að gera einhvers konar afturköllun fyrir breytingar? Til dæmis, í núverandi skafti, taktu og segðu að þangað til þú notar breytingarnar, og frá þessari stundu hættir þú að beita breytingunum?
Ef skipun kom til þyrpingarinnar okkar og braut hana, þá erum við með skilyrta eftirmynd með klukkutíma seinkun, þar sem við getum sagt að við skulum nota hana í augnablikinu, en við munum ekki beita breytingum á henni síðustu tíu mínúturnar?
Í fyrsta lagi um stjórnaða töf eftirlíkinga. Það var slík beiðni frá notendum og við bjuggum til mál á Github með beiðninni: „Ef einhver þarf þetta, líkar við það, settu þá hjarta. Enginn afhenti og málið var lokað. Hins vegar geturðu nú þegar fengið þetta tækifæri með því að setja upp ClickHouse. Satt, aðeins frá útgáfu 20.3.
ClickHouse framkvæmir stöðugt gagnasamruna í bakgrunni. Þegar sameiningu er lokið er ákveðnu safni gagna skipt út fyrir stærra hluta. Á sama tíma halda gögn sem voru þar áður áfram á disknum í nokkurn tíma.
Í fyrsta lagi halda þær áfram að vera geymdar svo framarlega sem það eru valdar fyrirspurnir sem nota þær, til að veita aðgerð sem ekki hindrar. Auðvelt er að lesa valdar fyrirspurnir úr gömlum klumpum.
Í öðru lagi er líka tímaþröskuldur - gömul gögn liggja á disknum í átta mínútur. Þessar átta mínútur er hægt að aðlaga og jafnvel breyta í einn dag. Þetta mun kosta diskpláss: það fer eftir gagnaflæðinu að á síðasta degi munu gögnin ekki aðeins tvöfaldast, þau gætu orðið fimm sinnum fleiri. En ef það er alvarlegt vandamál geturðu stöðvað ClickHouse netþjóninn og reddað öllu.
Nú vaknar spurningin um hvernig þetta verndar gegn breytingum. Það er þess virði að skoða nánar hér, því í eldri útgáfum af ClickHouse virkaði breytingin þannig að hún breytti einfaldlega hlutum beint. Það er gögn með sumum skrám og við gerum td. breyta fall dálki. Þá er þessi dálkur fjarlægður líkamlega úr öllum klumpur.
En frá og með útgáfu 20.3 hefur breytingakerfi verið gjörbreytt og nú eru gögn alltaf óbreytanleg. Þær breytast alls ekki - breytingar virka nú á svipaðan hátt og sameining. Í stað þess að skipta um hlut á staðnum búum við til nýtt. Í nýja klumpnum verða skrár sem hafa ekki breyst að harðtengingum og ef við eyðum dálki þá vantar hann einfaldlega í nýja klumpinn. Gamla verkinu verður sjálfgefið eytt eftir átta mínútur og hér geturðu lagfært stillingarnar sem nefnd eru hér að ofan.
Sama á við um breytingar eins og stökkbreytingar. Þegar þú gerir það breyta eyða eða breyta uppfærslu, það breytir ekki verkinu, heldur býr til nýtt. Og eyðir svo gömlu.
Hvað ef töfluskipan hefur breyst?
Hvernig á að endurheimta öryggisafrit sem var gert með gamla kerfinu? Og önnur spurningin er um málið með skyndimyndir og skráarkerfisverkfæri. Er Btrfs gott hér í stað ZFS á Linux LVM?
Ef þú gerir festa skipting skipting með annarri uppbyggingu, þá mun ClickHouse segja þér að þetta sé ekki mögulegt. Þetta er lausnin. Í fyrsta lagi er að búa til tímabundna töflu af MergeTree gerðinni með gömlu uppbyggingunni, hengja gögn þar við með því að nota attach og gera breytingarfyrirspurn. Síðan geturðu annað hvort afritað eða flutt þessi gögn og hengt við aftur, eða notað beiðni breyta skiptingunni til að færa töfluna.
Nú er önnur spurning hvort hægt sé að nota Btrfs. Til að byrja með, ef þú ert með LVM, þá eru LVM skyndimyndir nóg, og skráarkerfið getur verið ext4, það skiptir ekki máli. Með Btrts fer allt eftir reynslu þinni af því að nota það. Þetta er þroskað skráarkerfi, en það eru samt einhverjar grunsemdir um hvernig allt muni ganga upp í reynd í tiltekinni atburðarás. Ég myndi ekki mæla með því að nota þetta nema þú sért með Btrfs í framleiðslu.
Hver eru núverandi bestu starfsvenjur við endurnýtingu gagna?
Málið um endurnýtingu er flókið og margþætt. Hér eru nokkur svör möguleg. Þú getur farið frá annarri hliðinni og sagt þetta - ClickHouse er ekki með innbyggðan endurhleðsluaðgerð. En ég er hræddur um að þetta svar henti engum. Þess vegna geturðu farið frá hinni hliðinni og sagt að ClickHouse hafi margar leiðir til að endurherða gögn.
Ef þyrpingin klárast á plássi eða hann ræður ekki við álagið bætirðu við nýjum netþjónum. En þessir netþjónar eru sjálfgefið tómir, það eru engin gögn á þeim, það er ekkert álag. Þú þarft að endurraða gögnunum þannig að þau dreifist jafnt yfir nýja, stærri þyrpinguna.
Fyrsta leiðin sem hægt er að gera er að afrita hluta af skiptingunum á nýja netþjóna með því að nota beiðni breyta töflu sækja skipting. Til dæmis, þú varst með skipting eftir mánuðum og þú tekur fyrsta mánuðinn af 2017 og afritar hann á nýjan netþjón, afritar síðan þriðja mánuðinn á einhvern annan nýjan netþjón. Og þú gerir þetta þar til það verður meira og minna jafnt.
Flutningur er aðeins hægt að framkvæma fyrir þá skipting sem breytast ekki við upptöku. Fyrir nýja skipting verður að slökkva á upptöku, vegna þess að flutningur þeirra er ekki atóm. Annars endar þú með afrit eða eyður í gögnunum. Hins vegar er þessi aðferð hagnýt og virkar nokkuð vel. Tilbúnar þjappaðar skiptingar eru sendar yfir netið, það er að segja að gögnin eru ekki þjöppuð eða endurkóðuð.
Þessi aðferð hefur einn galli og það fer eftir skurðarkerfinu, hvort þú lofaðir þessu klippikerfi, hvaða klippilykill þú hafðir. Í dæminu þínu fyrir tilvikið með mæligildi, er klippingarlykillinn kjötkássa leiðarinnar. Þegar þú velur dreifða töflu fer hún í öll brot í þyrpingunni í einu og tekur gögn þaðan.
Þetta þýðir að það skiptir þig í raun ekki máli hvaða gögn enduðu á hvaða broti. Aðalatriðið er að gögn eftir einni slóð endi á einni braut, en hver skiptir ekki máli. Í þessu tilfelli er flutningur á tilbúnum skiptingum fullkominn, vegna þess að með völdum fyrirspurnum færðu einnig fullkomin gögn - hvort sem það er fyrir endurhleðslu eða eftir, kerfið skiptir í raun ekki máli.
En það eru mál sem eru flóknari. Ef þú á rökfræðistigi forritsins treystir þér á sérstakt sundrunarkerfi, að þessi viðskiptavinur sé staðsettur á slíku og slíku broti, og beiðnina er hægt að senda beint þangað, en ekki á dreifða töfluna. Eða þú ert að nota nokkuð nýlega útgáfu af ClickHouse og hefur virkjað stillinguna hagræða sleppa ónotuðum brotum. Í þessu tilviki, meðan á valfyrirspurninni stendur, verður tjáningin í where hlutanum greind og reiknað út hvaða shards þarf að nota samkvæmt sharding kerfinu. Þetta virkar að því tilskildu að gögnin séu skipt nákvæmlega í samræmi við þetta sundrunarkerfi. Ef þú endurraðaðir þeim handvirkt gæti samsvörunin breyst.
Þannig að þetta er aðferð númer eitt. Og ég bíð eftir svari þínu, hvort aðferðin henti, eða við skulum halda áfram.
Vladimir Kolobaev, aðalkerfisstjóri hjá Avito: Alexey, aðferðin sem þú nefndir virkar ekki mjög vel þegar þú þarft að dreifa álaginu, þar á meðal lestri. Við getum tekið skipting sem er mánaðarleg og getur tekið fyrri mánuði í annan hnút, en þegar beiðni kemur um þessi gögn munum við aðeins hlaða þeim. En við viljum hlaða allan klasann, því annars mun allt lestrarálagið í einhvern tíma verða unnið með tveimur brotum.
Alexey Milovidov: Svarið hér er skrítið - já, það er slæmt, en það gæti virkað. Ég skal útskýra nákvæmlega hvernig. Það er þess virði að skoða álagssviðið sem kemur á bak við gögnin þín. Ef þetta er eftirlitsgögn, þá getum við næstum örugglega sagt að langflestar beiðnir séu um fersk gögn.
Þú settir upp nýja netþjóna, fluttir gamla skipting, en breyttir líka því hvernig ný gögn eru skráð. Og ferskum gögnum verður dreift um allan klasann. Þannig, eftir aðeins fimm mínútur munu beiðnir fyrir síðustu fimm mínúturnar hlaða þyrpingunni jafnt; eftir sólarhring munu beiðnir um XNUMX klukkustundir hlaða þyrpingunni jafnt. Og beiðnir fyrir mánuðinn á undan munu því miður aðeins fara til hluta klasaþjónanna.
En oft muntu ekki hafa beiðnir sérstaklega fyrir febrúar 2019. Líklegast, ef beiðnir fara inn í 2019, þá verða þær fyrir allt árið 2019 - í langan tíma, en ekki fyrir lítið svið. Og slíkar beiðnir munu einnig geta hlaðið þyrpingunni jafnt. En almennt séð er þessi athugasemd þín alveg rétt um að þetta sé ad hoc lausn sem dreifir gögnunum ekki alveg jafnt.
Ég hef nokkra punkta í viðbót til að svara spurningunni. Einn þeirra snýst um hvernig eigi að hanna klippingarkerfi í upphafi þannig að endurklipping myndi valda minni sársauka. Þetta er ekki alltaf hægt.
Til dæmis ertu með vöktunargögn. Eftirlitsgögnum fjölgar af þremur ástæðum. Í fyrsta lagi er uppsöfnun sögulegra gagna. Annað er umferðaraukning. Og í þriðja lagi fjölgar þeim hlutum sem eru eftirlitsskyldir. Það eru nýjar örþjónustur og mælikvarðar sem þarf að vista.
Hugsanlegt er að þar af tengist mesta aukningin þriðju ástæðunni - aukinni notkun vöktunar. Og í þessu tilfelli er það þess virði að skoða eðli álagsins, hverjar eru helstu valfyrirspurnirnar. Grunnvalfyrirspurnir munu líklegast byggjast á einhverju undirmengi mæligilda.
Til dæmis, CPU notkun á sumum netþjónum af einhverri þjónustu. Það kemur í ljós að það er ákveðið undirmengi lykla sem þú færð þessi gögn með. Og beiðnin sjálf um þessi gögn er líklega frekar einföld og er lokið á tugum millisekúndna. Notað fyrir eftirlitsþjónustu og mælaborð. Ég vona að ég skilji þetta rétt.
Vladimir Kolobaev: Staðreyndin er sú að við höfðum mjög oft til sögulegra gagna þar sem við berum núverandi aðstæður saman við þær sögulegu í rauntíma. Og það er mikilvægt fyrir okkur að hafa skjótan aðgang að miklu magni af gögnum og ClickHouse gerir frábært starf með þetta.
Það er alveg rétt hjá þér, við upplifum flestar lesbeiðnir síðasta daginn, eins og hvert eftirlitskerfi. En á sama tíma er álagið á söguleg gögn líka nokkuð mikið. Það er í grundvallaratriðum frá viðvörunarkerfi sem fer í kringum á þrjátíu sekúndna fresti og segir við ClickHouse: „Gefðu mér gögnin fyrir síðustu sex vikurnar. Búðu nú til mér einhvers konar hreyfanlegt meðaltal úr þeim og við skulum bera saman núverandi gildi við það sögulega."
Ég vil segja að fyrir svo mjög nýlegar beiðnir höfum við aðra litla töflu þar sem við geymum aðeins tvo daga af gögnum og helstu beiðnir fljúga inn í hana. Við sendum aðeins stórar sögulegar fyrirspurnir í stóra rifnu töfluna.
Alexey Milovidov: Því miður, það reynist illa viðeigandi fyrir atburðarás þína, en ég mun segja þér lýsingu á tveimur slæmum og flóknum sharding kerfum sem þarf ekki að nota, en sem eru notuð í þjónustu vina minna.
Það er aðalþyrping með Yandex.Metrica viðburðum. Viðburðir eru síðuflettingar, smellir og viðskipti. Flestar beiðnir fara á tiltekna vefsíðu. Þú opnar Yandex.Metrica þjónustuna, þú ert með vefsíðu - avito.ru, farðu í skýrsluna og beiðni er gerð um vefsíðuna þína.
En það eru aðrar beiðnir - greinandi og alþjóðlegar - sem eru gerðar af innri sérfræðingum. Bara í tilfelli, tek ég fram að innri sérfræðingar gera beiðnir eingöngu um Yandex þjónustu. En engu að síður tekur jafnvel Yandex þjónusta umtalsverðan hluta af öllum gögnum. Þetta eru beiðnir ekki um sérstaka teljara, heldur um víðtækari síun.
Hvernig á að skipuleggja gögn á þann hátt að allt virki á skilvirkan hátt fyrir einn teljara, og alþjóðlegar fyrirspurnir líka? Annar vandi er sá að fjöldi beiðna í ClickHouse fyrir mælikvarðaklasann er nokkur þúsund á sekúndu. Á sama tíma getur einn ClickHouse þjónn ekki séð um óskir sem ekki eru léttvægar, til dæmis nokkur þúsund á sekúndu.
Klasastærðin er sexhundruð-eitthvað netþjónar. Ef þú einfaldlega dregur dreifða töflu yfir þennan klasa og sendir nokkur þúsund beiðnir þangað, verður það enn verra en að senda þær á einn netþjón. Á hinn bóginn er valmöguleikinn um að gögnin dreifist jafnt og við förum og óskum eftir öllum netþjónum, samstundis hafnað.
Það er valkostur sem er þveröfugt. Ímyndaðu þér ef við spörum gögnunum á milli vefsvæða og beiðni um eina síðu færist í eina brot. Nú mun þyrpingin geta sinnt tíu þúsund beiðnum á sekúndu, en á einu broti mun hver beiðni vinna of hægt. Það mun ekki lengur skalast hvað varðar afköst. Sérstaklega ef þetta er síða avito.ru. Ég mun ekki opinbera leyndarmálið ef ég segi að Avito sé ein af mest heimsóttu síðunum í RuNet. Og það væri brjálæði að vinna úr því á einni mold.
Þess vegna er klippingarkerfið hannað á lævísari hátt. Öllum klasanum er skipt í fjölda klasa sem við köllum lög. Hver þyrping inniheldur frá tugi upp í nokkra tugi brota. Alls eru þrjátíu og níu slíkir klasar.
Hvernig mælist þetta allt saman? Fjöldi klasa breytist ekki - eins og hann var fyrir þrjátíu og níu fyrir nokkrum árum er hann enn svo. En innan hvers þeirra fjölgum við smám saman fjölda brota eftir því sem við söfnum gögnum. Og klippingarkerfið í heild sinni er svona: þessum klösum er skipt í vefsíður og til að skilja hvaða vefsíða er á hvaða klasa er sérstakur metabasi í MySQL notaður. Ein síða - á einum klasa. Og inni í henni á sér stað klipping samkvæmt auðkenni gesta.
Við upptöku deilum við þeim með því sem eftir er af skiptingu gestaauðkennisins. En þegar nýrri möl er bætt við breytist brotakerfið; við höldum áfram að skipta, en með afgangi af deilingunni með annarri tölu. Þetta þýðir að einn gestur er nú þegar staðsettur á nokkrum netþjónum og þú getur ekki treyst á þetta. Þetta er eingöngu gert til að tryggja að gögnin séu betur þjöppuð. Og þegar við gerum beiðnir förum við í dreifða töfluna, sem lítur á þyrpinguna og opnar tugi netþjóna. Þetta er svo heimskulegt kerfi.
En saga mín verður ófullkomin ef ég segi ekki að við hættum þessu skipulagi. Í nýja kerfinu breyttum við öllu og afrituðum öll gögnin með því að nota clickhouse-copier.
Í nýja kerfinu er öllum vefsvæðum skipt í tvo flokka - stóra og smáa. Ég veit ekki hvernig þröskuldurinn var valinn, en niðurstaðan var sú að stórar síður eru skráðar á einn þyrping, þar sem eru 120 brot með þremur eftirmyndum hver - það er 360 netþjónar. Og brotakerfið er þannig að allar beiðnir fara til allra brota í einu. Ef þú opnar nú einhverja skýrslusíðu fyrir avito.ru í Yandex.Metrica mun beiðnin fara á 120 netþjóna. Það eru fáar stórar síður í RuNet. Og beiðnirnar eru ekki þúsund á sekúndu, heldur jafnvel innan við hundrað. Allt þetta er hljóðlega tuggið upp af dreifða töflunni, sem hver þeirra vinnur með 120 netþjónum.
Og seinni þyrpingin er fyrir litlar síður. Hér er brotakerfi byggt á auðkenni vefsvæðisins og hver beiðni fer í nákvæmlega eitt brot.
ClickHouse er með clickhouse-ljósritunartæki. Geturðu sagt mér frá henni?
Ég segi strax að þessi lausn er fyrirferðarmeiri og heldur minna afkastamikill. Kosturinn er sá að það smyr gögnin algjörlega í samræmi við mynstrið sem þú tilgreinir. En gallinn við tólið er að það endurharðist alls ekki. Það afritar gögn frá einu klasaskema yfir í annað klasaskema.
Þetta þýðir að til að það virki þarftu að hafa tvo klasa. Þau geta verið staðsett á sömu netþjónum, en engu að síður verða gögnin ekki færð smám saman heldur afrituð.
Til dæmis voru fjórir netþjónar, nú eru þeir átta. Þú býrð til nýja Dreifða töflu á öllum netþjónum, nýjar staðbundnar töflur og ræsir clickhouse-copier, gefur til kynna vinnukerfið sem það ætti að lesa þaðan, samþykkir nýja sharding kerfið og flytur gögnin þangað. Og á gömlum netþjónum þarftu einu og hálfu sinnum meira pláss en það er núna, því gömlu gögnin verða að vera áfram á þeim og helmingur af sömu gömlu gögnunum kemur ofan á þá. Ef þú hélst fyrirfram að gögnin þurfi að endurharka og það er pláss, þá hentar þessi aðferð.
Hvernig virkar clickhouse-ljósritunarvél inni? Það sundrar allri vinnu í sett af verkefnum til að vinna úr einni skiptingu af einni töflu á einni brot. Öll þessi verkefni er hægt að framkvæma samhliða, og clickhouse-copier er hægt að keyra á mismunandi vélum í mörgum tilfellum, en það sem það gerir fyrir eina skipting er ekkert annað en insert select. Gögnin eru lesin, þjappað niður, skipt aftur, síðan þjappað aftur, skrifað einhvers staðar og raðað aftur. Þetta er erfiðari ákvörðun.
Þú varst með flugmann sem heitir endurherding. Hvað með hana?
Árið 2017 varstu með tilraunaverkefni sem hét endurherding. Það er meira að segja valkostur í ClickHouse. Eins og ég skil þetta þá tók það ekki af. Geturðu sagt mér hvers vegna þetta gerðist? Það virðist vera mjög viðeigandi.
Allt vandamálið er að ef nauðsynlegt er að endurherða gögn á sínum stað, þarf mjög flókna samstillingu til að gera þetta frumeindafræðilega. Þegar við fórum að skoða hvernig þessi samstilling virkar kom í ljós að það voru grundvallarvandamál. Og þessi grundvallarvandamál eru ekki aðeins fræðileg, heldur fóru þau strax að sýna sig í reynd í formi einhvers sem hægt er að útskýra mjög einfaldlega - ekkert virkar.
Er hægt að sameina öll gögn áður en þau eru færð yfir á hæga diska?
Spurning um TTL með því að færa til hægur diskur í tengslum við sameiningu. Er einhver leið, önnur en með cron, til að sameina alla hlutana í einn áður en þeir eru færðir yfir á hæga diska?
Svarið við spurningunni er hægt að einhvern veginn sjálfkrafa líma alla bitana í einn áður en þú flytur þá - nei. Ég held að þetta sé ekki nauðsynlegt. Þú þarft ekki að sameina alla hlutana í einn, heldur einfaldlega treysta á þá staðreynd að þeir verða fluttir sjálfkrafa á hæga diska.
Við höfum tvö viðmið fyrir flutningsreglur. Sá fyrsti er eins og hann er fylltur. Ef núverandi geymsluþrep hefur minna en ákveðið hlutfall af lausu plássi veljum við einn bita og færum hann í hægari geymslu. Eða réttara sagt, ekki hægari, heldur sá næsti - eins og þú stillir.
Annað viðmiðið er stærð. Þetta snýst um að flytja stóra bita. Þú getur stillt þröskuldinn í samræmi við laust pláss á hraðdisknum og gögnin verða flutt sjálfkrafa.
Hvernig á að flytja í nýjar útgáfur af ClickHouse ef engin leið er til að athuga eindrægni fyrirfram?
Þetta efni er rætt reglulega að teknu tilliti til mismunandi útgáfur, og enn. Hversu öruggt er að uppfæra úr útgáfu 19.11 í 19.16 og til dæmis úr 19.16 í 20.3. Hver er besta leiðin til að flytja yfir í nýjar útgáfur án þess að geta athugað samhæfni í sandkassanum fyrirfram?
Það eru nokkrar „gylltar“ reglur hér. Fyrst - . Það er stórt, en það eru sérstakar málsgreinar um breytingar sem eru ósamrýmanlegar afturábak. Ekki meðhöndla þessa punkta sem rauðan fána. Þetta er venjulega minniháttar ósamrýmanleiki sem felur í sér einhverja brúnvirkni sem þú notar mjög líklega ekki.
Í öðru lagi, ef það er engin leið til að athuga eindrægni í sandkassanum og þú vilt uppfæra strax í framleiðslu, þá er mælt með því að þú þurfir ekki að gera þetta. Búðu fyrst til sandkassa og prófaðu. Ef það er ekkert prófumhverfi, þá ertu líklega ekki með mjög stórt fyrirtæki, sem þýðir að þú getur afritað hluta af gögnunum yfir á fartölvuna þína og gengið úr skugga um að allt virki rétt á henni. Þú getur jafnvel hækkað nokkrar eftirmyndir á staðnum á vélinni þinni. Eða þú getur tekið upp nýja útgáfu einhvers staðar í nágrenninu og hlaðið upp einhverjum af gögnunum þangað - það er að segja búið til spunnið prófunarumhverfi.
Önnur regla er að uppfæra ekki í viku eftir útgáfu útgáfunnar vegna galla í framleiðslu og síðari skyndilausna. Við skulum reikna út númerið á ClickHouse útgáfum til að ruglast ekki.
Það er útgáfa 20.3.4. Talan 20 gefur til kynna framleiðsluárið - 2020. Frá sjónarhóli þess sem er inni skiptir þetta ekki máli, svo við munum ekki borga eftirtekt til þess. Næst - 20.3. Við hækkum seinni töluna - í þessu tilviki 3 - í hvert skipti sem við gefum út útgáfu með einhverjum nýjum virkni. Ef við viljum bæta einhverjum eiginleikum við ClickHouse verðum við að hækka þennan fjölda. Það er, í útgáfu 20.4 mun ClickHouse virka enn betur. Þriðji stafurinn er 20.3.4. Hérna 4 er fjöldi plástraútgáfunnar þar sem við bættum ekki við nýjum eiginleikum, heldur laguðum nokkrar villur. Og 4 þýðir að við gerðum það fjórum sinnum.
Ekki halda að þetta sé eitthvað hræðilegt. Venjulega getur notandinn sett upp nýjustu útgáfuna og það mun virka án vandræða með spenntur á ári. En ímyndaðu þér að í einhverri aðgerð til að vinna úr punktamyndum, sem kínverskir félagar okkar bættu við, hrynji þjónninn þegar röng rök eru send. Okkur ber skylda til að laga þetta. Við munum gefa út nýja plástursútgáfu og ClickHouse verður stöðugra.
Ef þú ert með ClickHouse í gangi í framleiðslu og ný útgáfa af ClickHouse er gefin út með viðbótareiginleikum - til dæmis, 20.4.1 er sá allra fyrsti, ekki flýta þér að setja það í framleiðslu á fyrsta degi. Hvers vegna er það jafnvel þörf? Ef þú notar ekki ClickHouse nú þegar, þá geturðu sett það upp og líklega verður allt í lagi. En ef ClickHouse er nú þegar að virka stöðugt, hafðu þá auga með plástra og uppfærslur til að sjá hvaða vandamál við erum að laga.
Kirill Shvakov: Mig langar að bæta aðeins við um prófunarumhverfi. Allir eru mjög hræddir við prófunarumhverfi og af einhverjum ástæðum trúa þeir því að ef þú ert með mjög stóran ClickHouse þyrping þá ætti prófumhverfið að vera hvorki minna né að minnsta kosti tífalt minna. Það er alls ekki þannig.
Ég get sagt þér frá mínu eigin dæmi. Ég er með verkefni og þar er ClickHouse. Prófunarumhverfið okkar er bara fyrir hann - þetta er lítil sýndarvél í Hetzner fyrir tuttugu evrur, þar sem nákvæmlega allt er notað. Til að gera þetta höfum við fulla sjálfvirkni í Ansible og því skiptir í grundvallaratriðum engu máli hvert á að fara - á vélbúnaðarþjóna eða bara innleiða í sýndarvélar.
Hvað er hægt að gera? Það væri gaman að koma með dæmi í ClickHouse skjölunum um hvernig á að setja upp lítinn klasa á þínu eigin heimili - í Docker, í LXC, búðu til kannski Ansible leikbók, vegna þess að mismunandi fólk hefur mismunandi dreifingu. Þetta mun einfalda mikið. Þegar þú tekur og setur þyrping í notkun á fimm mínútum er miklu auðveldara að reyna að finna út úr einhverju. Þetta er miklu þægilegra, því að rúlla inn í framleiðsluútgáfu sem þú hefur ekki prófað er leið til hvergi. Stundum virkar það og stundum ekki. Og þess vegna er von um árangur slæm.
Maxim Kotyakov, eldri bakendaverkfræðingur Avito: Ég bæti aðeins við um prófunarumhverfi úr röð vandamála sem stór fyrirtæki standa frammi fyrir. Við erum með fullgildan ClickHouse samþykkisklasa; hvað varðar gagnakerfi og stillingar er það nákvæm afrit af því sem er í framleiðslu. Þessi klasi er settur á vettvang í nokkuð niðurtípuðum gámum með lágmarks fjármagni. Þar skrifum við ákveðið hlutfall af framleiðslugögnum, sem betur fer er hægt að endurtaka strauminn í Kafka. Þar er allt samstillt og skalað - bæði hvað varðar afkastagetu og flæði, og fræðilega séð, að öllu öðru óbreyttu, ætti það að haga sér eins og framleiðsla hvað varðar mælikvarða. Öllu hugsanlegu sprengiefni er fyrst rúllað upp á þennan stand og látið liggja þar í nokkra daga þar til það er tilbúið. En náttúrulega er þessi lausn dýr, erfið og hefur stuðningskostnað sem er ekki núll.
Alexey Milovidov: Ég skal segja þér hvernig prófunarumhverfi vina okkar frá Yandex.Metrica er. Einn þyrping var með 600 netþjóna, annar með 360 og það er þriðji og nokkrir þyrpingar. Prófunarumhverfi annars þeirra er einfaldlega tvö brot með tveimur eftirmyndum í hvoru. Af hverju tvær klippur? Svo að þú sért ekki einn. Og það ættu að vera eftirlíkingar líka. Bara ákveðin lágmarksupphæð sem þú hefur efni á.
Þetta prófunarumhverfi gerir þér kleift að athuga hvort fyrirspurnir þínar virka og hvort eitthvað stórt sé bilað. En oft koma upp vandamál af allt öðrum toga, þegar allt gengur upp, en það eru smá breytingar á álaginu.
Leyfðu mér að gefa þér dæmi. Við ákváðum að setja upp nýja útgáfu af ClickHouse. Það hefur verið sett á prófunarumhverfi, sjálfvirkum prófunum hefur verið lokið í Yandex.Metrica sjálfu, sem bera saman gögn um gömlu útgáfuna og þá nýju, sem keyra alla leiðsluna. Og auðvitað, græn próf á CI okkar. Annars hefðum við ekki einu sinni lagt til þessa útgáfu.
Allt er í lagi. Við erum að byrja að fara í framleiðslu. Ég fæ skilaboð um að álagið á línuritin hafi aukist nokkrum sinnum. Við erum að draga útgáfuna til baka. Ég horfi á línuritið og sé: álagið jókst í raun nokkrum sinnum við útsetningu og minnkaði aftur þegar það rúllaði út. Svo fórum við að snúa útgáfunni til baka. Og álagið jókst á sama hátt og féll aftur á sama hátt. Þannig að niðurstaðan er þessi: álagið hefur aukist vegna skipulagsins, ekkert sem kemur á óvart.
Þá var erfitt að sannfæra samstarfsmenn um að setja upp nýju útgáfuna. Ég segi: „Það er allt í lagi, rúllaðu út. Krossa puttana, allt mun ganga upp. Nú hefur álagið á línuritin aukist en allt er í lagi. Bíddu þarna." Almennt gerðum við þetta, og það er það - útgáfan var gefin út til framleiðslu. En næstum með hverju skipulagi koma upp svipuð vandamál.
Kill query á að drepa fyrirspurnir, en það gerir það ekki. Hvers vegna?
Notandi, einhvers konar sérfræðingur, kom til mín og bjó til beiðni sem setti ClickHouse klasann minn. Einhvern hnút eða heilan þyrpingu, eftir því til hvaða eftirlíkingar eða brot beiðnin fór. Ég sé að öll CPU auðlindir á þessum server eru í hillu, allt er rautt. Á sama tíma bregst ClickHouse sjálft við beiðnum. Og ég skrifa: "Vinsamlegast sýndu mér, vinnslulista, hvaða beiðni olli þessari brjálæði."
Ég finn þessa beiðni og skrifa drep á hana. Og ég sé að ekkert er að gerast. Miðlarinn minn er í hillu, ClickHouse gefur mér svo nokkrar skipanir, sýnir að þjónninn er á lífi og allt er frábært. En ég er með hnignun í öllum notendabeiðnum, hnignun byrjar með færslum í ClickHouse og drápsfyrirspurnin mín virkar ekki. Hvers vegna? Ég hélt að kill query ætti að drepa fyrirspurnir, en það gerir það ekki.
Nú verður frekar undarlegt svar. Málið er að drepa fyrirspurn drepur ekki fyrirspurnir.
Kill query hakar við lítinn reit sem heitir "Ég vil að þessi fyrirspurn verði drepin." Og beiðnin sjálf lítur á þennan fána þegar unnið er úr hverri blokk. Ef það er stillt hættir beiðnin að virka. Það kemur í ljós að enginn drepur beiðnina, hann verður sjálfur að athuga allt og hætta. Og þetta ætti að virka í öllum tilvikum þar sem beiðnin er í því ástandi að vinna úr gagnablokkum. Það mun vinna úr næsta gagnablokk, athuga fánann og hætta.
Þetta virkar ekki í þeim tilvikum þar sem beiðnin er læst á einhverri aðgerð. Að vísu er þetta líklega ekki þitt mál, því samkvæmt þér notar það fullt af netþjónaauðlindum. Hugsanlegt er að þetta virki ekki þegar um ytri flokkun er að ræða og í sumum öðrum smáatriðum. En almennt ætti þetta ekki að gerast, þetta er galli. Og það eina sem ég get mælt með er að uppfæra ClickHouse.
Hvernig á að reikna út viðbragðstíma við lestrarálag?
Það er tafla sem geymir vörusamstæður - ýmsir teljarar. Fjöldi lína er um eitt hundrað milljónir. Er hægt að treysta á fyrirsjáanlegan viðbragðstíma ef þú hellir 1K RPS fyrir 1K hluti?
Af samhenginu að dæma erum við að tala um lestrarálagið, því það eru engin vandamál með að skrifa - jafnvel þúsund, jafnvel hundrað þúsund og stundum nokkrar milljónir raðir geta verið settar inn.
Lestrarbeiðnir eru mjög mismunandi. Í vali 1 getur ClickHouse framkvæmt um það bil tugþúsundir beiðna á sekúndu, svo jafnvel beiðnir um einn lykil munu nú þegar þurfa nokkur úrræði. Og slíkar punktafyrirspurnir verða erfiðari en í sumum lykilgilda gagnagrunnum, því fyrir hverja lestur er nauðsynlegt að lesa gagnablokk eftir vísitölu. Vísitalan okkar fjallar ekki um hverja skrá, heldur hvert svið. Það er, þú verður að lesa allt svið - þetta er sjálfgefið 8192 línur. Og þú verður að þjappa þjappað gagnablokk úr 64 KB í 1 MB. Venjulega tekur slíkar markvissar fyrirspurnir nokkrar millisekúndur að ljúka. En þetta er einfaldasti kosturinn.
Prófum einfaldan reikning. Ef þú margfaldar nokkrar millisekúndur með þúsund færðu nokkrar sekúndur. Það er eins og það sé ómögulegt að halda í við þúsund beiðnir á sekúndu, en í raun er það mögulegt, vegna þess að við erum með nokkra örgjörvakjarna. Svo, í grundvallaratriðum, getur ClickHouse stundum haldið 1000 RPS, en fyrir stuttar beiðnir, sérstaklega miðaðar.
Ef þú þarft að skala ClickHouse þyrping eftir fjölda einfaldra beiðna, þá mæli ég með því einfaldasta - fjölga eftirlíkingum og senda beiðnir á handahófskennda eftirmynd. Ef ein eftirlíking geymir fimm hundruð beiðnir á sekúndu, sem er algjörlega raunhæft, þá munu þrjár eftirmyndir höndla eitt og hálft þúsund.
Stundum er auðvitað hægt að stilla ClickHouse fyrir hámarksfjölda punktalestra. Hvað þarf til þessa? Í fyrsta lagi er að draga úr nákvæmni vísitölunnar. Í þessu tilviki ætti ekki að fækka henni í eina, heldur á grundvelli þess að fjöldi færslur í vísitölunni verði nokkrar milljónir eða tugir milljóna á hvern netþjón. Ef taflan hefur hundrað milljónir raða, þá er hægt að stilla kornhlutfallið á 64.
Þú getur minnkað stærð þjappaðs blokkar. Það eru stillingar fyrir þetta mín þjappa blokk stærð, hámarks þjöppunarstærð. Hægt er að fækka þeim, fylla aftur með gögnum og þá verða markvissar fyrirspurnir hraðari. En samt, ClickHouse er ekki lykilgildi gagnagrunnur. Mikill fjöldi lítilla beiðna er álagsvörn.
Kirill Shvakov: Ég mun gefa ráð ef það eru venjulegir reikningar þar. Þetta er nokkuð staðlað ástand þegar ClickHouse geymir einhvers konar afgreiðsluborð. Ég er með notanda, hann er frá svona og svona landi, og einhver þriðja sviði, og ég þarf að auka eitthvað stigvaxandi. Taktu MySQL, búðu til einstakan lykil - í MySQL er það tvítekinn lykill, og í PostgreSQL er það átök - og bættu við plúsmerki. Þetta mun virka miklu betur.
Þegar þú ert ekki með mikið af gögnum er ekki mikill tilgangur að nota ClickHouse. Það eru reglulegar gagnagrunnar og þeir gera þetta vel.
Hvað get ég lagað í ClickHouse þannig að fleiri gögn séu í skyndiminni?
Við skulum ímynda okkur aðstæður - netþjónarnir eru með 256 GB af vinnsluminni, í daglegu lífi tekur ClickHouse um 60-80 GB, þegar mest er - allt að 130. Hvað er hægt að virkja og fínstilla þannig að fleiri gögn séu í skyndiminni og í samræmi við það, það eru færri ferðir á diskinn?
Venjulega gerir síðuskyndiminni stýrikerfisins gott starf í þessu. Ef þú opnar bara toppinn, lítur þar í skyndiminni eða laus - það segir líka hversu mikið er í skyndiminni - þá muntu taka eftir því að allt laust minni er notað fyrir skyndiminni. Og þegar þessi gögn eru lesin verða þau ekki lesin af disknum, heldur úr vinnsluminni. Á sama tíma get ég sagt að skyndiminni sé notað á áhrifaríkan hátt vegna þess að það eru þjöppuðu gögnin sem eru í skyndiminni.
Hins vegar, ef þú vilt flýta fyrir nokkrum einföldum fyrirspurnum enn meira, þá er hægt að virkja skyndiminni í afþjöppuðu gögnunum inni í ClickHouse. Það er kallað óþjappað skyndiminni. Í config.xml stillingarskránni skaltu stilla óþjappaða skyndiminni stærðina á það gildi sem þú þarft - ég mæli ekki með meira en helmingi ókeypis vinnsluminni, því restin fer undir skyndiminni síðunnar.
Að auki eru tvær beiðnistigsstillingar. Fyrsta stilling - nota óþjappað skyndiminni - felur í sér notkun þess. Mælt er með því að virkja það fyrir allar beiðnir, nema þungar, sem geta lesið öll gögnin og skolað skyndiminni. Og önnur stillingin er eitthvað eins og hámarksfjöldi lína til að nota skyndiminni. Það takmarkar sjálfkrafa stórar fyrirspurnir þannig að þær fara framhjá skyndiminni.
Hvernig get ég stillt storage_configuration fyrir geymslu í vinnsluminni?
Í nýju ClickHouse skjölunum las ég hlutann sem tengist . Lýsingin inniheldur dæmi með hraðvirkum SSD.
Ég velti því fyrir mér hvernig hægt er að stilla það sama með heitu hljóðstyrk minni. Og ein spurning í viðbót. Hvernig virkar select með þessari gagnastofnun, mun það lesa allt settið eða aðeins það sem er á disknum og eru þessi gögn þjappuð í minni? Og hvernig virkar prewhere-hlutinn með slíkri gagnastofnun?
Þessi stilling hefur áhrif á geymslu gagnabita og snið þeirra breytist ekki á nokkurn hátt.
Við skulum skoða nánar.
Þú getur stillt gagnageymslu í vinnsluminni. Allt sem er stillt fyrir diskinn er slóð hans. Þú býrð til tmpfs skipting sem er fest á einhverja slóð í skráarkerfinu. Þú tilgreinir þessa slóð sem slóð til að geyma gögn fyrir heitasta skiptinguna, gagnastykki byrja að berast og skrifast þar, allt er í lagi.
En ég mæli ekki með því að gera þetta vegna lítillar áreiðanleika, þó að ef þú ert með að minnsta kosti þrjár eftirlíkingar í mismunandi gagnaverum, þá er það mögulegt. Ef eitthvað gerist verða gögnin endurheimt. Ímyndum okkur að skyndilega hafi verið slökkt á þjóninum og kveikt aftur á honum. Skilrúmið var sett upp aftur, en það var ekkert þar. Þegar ClickHouse þjónninn fer í gang sér hann að hann er ekki með þessa hluti, þó samkvæmt ZooKeeper lýsigögnum ættu þeir að vera þar. Hann skoðar hvaða eftirlíkingar hafa þær, biður um þær og halar þeim niður. Þannig verða gögnin endurheimt.
Í þessum skilningi er það að geyma gögn í vinnsluminni ekki í grundvallaratriðum frábrugðin því að geyma þau á diski, því þegar gögn eru skrifuð á disk lenda þau líka fyrst í skyndiminni síðunnar og eru líkamlega skrifuð síðar. Þetta fer eftir uppsetningarvalkosti skráarkerfisins. En bara í tilfelli, ég segi að ClickHouse samstillir ekki þegar það er sett inn.
Í þessu tilviki eru gögnin í vinnsluminni geymd á nákvæmlega sama sniði og á disknum. Valfyrirspurnin velur á sama hátt þau stykki sem þarf að lesa, velur nauðsynleg gagnasvið í stykkin og les þau. Og prewhere virkar nákvæmlega eins, óháð því hvort gögnin voru í vinnsluminni eða á diski.
Allt að hvaða fjölda einstakra gilda er Low Cardinality áhrifaríkt?
Low Cardinality er snjallt hannað. Það tekur saman gagnaorðabækur, en þær eru staðbundnar. Í fyrsta lagi eru mismunandi orðabækur fyrir hvert stykki, og í öðru lagi, jafnvel innan eins stykkis geta þær verið mismunandi fyrir hvert svið. Þegar fjöldi einstakra gilda nær þröskuldstölu - ein milljón held ég - er orðabókin einfaldlega sett á hilluna og ný er búin til.
Svarið er almennt: fyrir hvert staðbundið svið - segjum, fyrir hvern dag - einhvers staðar er allt að milljón einstök gildi Lágt kardinalitet virkt. Eftir það verður einfaldlega fallback, þar sem margar mismunandi orðabækur verða notaðar, en ekki bara ein. Það mun virka um það bil það sama og venjulegur strengjadálkur, kannski aðeins minna skilvirkur, en það verður engin alvarleg hnignun á frammistöðu.
Hverjar eru bestu vinnubrögðin við leit í fullri texta í töflu með fimm milljörðum lína?
Það eru mismunandi svör. Í fyrsta lagi er að segja að ClickHouse sé ekki leitarvél í fullum texta. Það eru sérstök kerfi fyrir þetta, td. и . Hins vegar sé ég í auknum mæli að fólk segist vera að skipta úr Elasticsearch yfir í ClickHouse.
Hvers vegna gerist þetta? Þeir útskýra þetta með því að Elasticsearch hættir að takast á við álagið í sumum magni, og byrjar með byggingu vísitölu. Vísitölur verða of fyrirferðarmiklar og ef þú einfaldlega flytur gögnin yfir í ClickHouse kemur í ljós að þau eru geymd nokkrum sinnum á skilvirkari hátt miðað við magn. Jafnframt voru leitarfyrirspurnir oft ekki þannig að nauðsynlegt væri að finna einhverja setningu í öllu gagnamagninu, að teknu tilliti til formfræði, heldur allt öðruvísi. Til dæmis, finndu einhverja eftirröð bæta í annálum síðustu klukkustunda.
Í þessu tilviki býrðu til vísitölu í ClickHouse, fyrsti reiturinn sem verður dagsetning og tími. Og stærsti gagnaskerðingurinn verður byggður á dagsetningarbilinu. Innan valins dagsetningabils er að jafnaði nú þegar hægt að framkvæma leit í fullri texta, jafnvel með því að nota brute force aðferðina með like. Sambærilegur rekstraraðili í ClickHouse er skilvirkasti eins rekstraraðili sem þú getur fundið. Ef þú finnur eitthvað betra, segðu mér það.
En samt, eins og er full skönnun. Og full skönnun getur verið hæg, ekki aðeins á örgjörvanum, heldur einnig á disknum. Ef þú ert skyndilega með eitt terabæt af gögnum á dag og þú leitar að orði yfir daginn, þá þarftu að skanna terabætið. Og það er líklega á venjulegum hörðum diskum og á endanum verða þeir hlaðnir á þann hátt að þú munt ekki geta nálgast þennan netþjón í gegnum SSH.
Í þessu tilfelli er ég tilbúinn að bjóða upp á enn eitt lítið bragð. Það er tilraunaverkefni - það gæti virkað, það gæti ekki. ClickHouse hefur heildartextavísitölur í formi þrírita Bloom sía. Samstarfsmenn okkar hjá Arenadata hafa þegar prófað þessar vísitölur og þær virka oft nákvæmlega eins og til er ætlast.
Til þess að nota þau rétt ættir þú að hafa góðan skilning á nákvæmlega hvernig þau virka: hvað þrígrams Bloom sía er og hvernig á að velja stærð hennar. Ég get sagt að þeir munu hjálpa fyrir fyrirspurnir um nokkrar sjaldgæfar setningar, undirstrengi sem finnast sjaldan í gögnunum. Í þessu tilviki verða undirsvið valin af vísitölum og minna gögn verða lesin.
Nýlega hefur ClickHouse bætt við enn fullkomnari aðgerðum fyrir leit í fullri texta. Þetta er í fyrsta lagi leit að fullt af undirstrengjum í einu í einni umferð, þar á meðal valmöguleikum sem eru há- og hástafanæm, með stuðningi fyrir UTF-8 eða aðeins fyrir ASCII. Veldu þann árangursríkasta sem þú þarft.
Leit að mörgum reglulegum tjáningum í einni umferð hefur einnig birst. Þú þarft ekki að skrifa X eins og einn undirstreng eða X eins og annan undirstreng. Þú skrifar strax og allt er gert eins vel og hægt er.
Í þriðja lagi er nú áætlað leit að regexps og áætlaða leit að undirstrengjum. Ef einhver stafsetti orð vitlaust verður leitað að hámarkssamsvöruninni.
Hver er besta leiðin til að skipuleggja aðgang að ClickHouse fyrir fjölda notenda?
Segðu okkur hvernig best er að skipuleggja aðgang fyrir fjölda neytenda og greiningaraðila. Hvernig á að mynda biðröð, forgangsraða hámarks samhliða fyrirspurnum og með hvaða verkfærum?
Ef þyrpingin er nógu stór, þá væri góð lausn að hækka tvo netþjóna til viðbótar, sem verða aðgangsstaður greiningaraðila. Það er að segja, ekki leyfa greiningaraðilum að fá aðgang að sérstökum brotum í þyrpingunni, heldur einfaldlega búa til tvo tóma netþjóna, án gagna, og stilla aðgangsréttindi á þá. Í þessu tilviki eru notendastillingar fyrir dreifðar beiðnir fluttar á ytri netþjóna. Það er, þú stillir allt á þessum tveimur netþjónum og stillingarnar hafa áhrif á allan klasann.
Í grundvallaratriðum hafa þessir netþjónar engin gögn, en magn vinnsluminni á þeim er mjög mikilvægt til að framkvæma beiðnir. Einnig er hægt að nota diskinn fyrir tímabundin gögn ef ytri samsöfnun eða ytri flokkun er virkjuð.
Það er mikilvægt að skoða þær stillingar sem tengjast öllum mögulegum takmörkunum. Ef ég fer nú í Yandex.Metrica klasann sem sérfræðingur og spyr um beiðni veldu fjölda úr heimsóknum, þá mun ég strax fá undanþágu um að ég geti ekki framfylgt beiðninni. Hámarksfjöldi lína sem ég má skanna er hundrað milljarðar og alls eru fimmtíu billjónir af þeim í einni töflu á þyrpingunni. Þetta er fyrsta takmörkunin.
Segjum að ég fjarlægi línumörkin og keyri fyrirspurnina aftur. Þá mun ég sjá eftirfarandi undantekningu - stilling virkjuð gildisvísitala eftir dagsetningu. Ég get ekki klárað fyrirspurnina ef ég hef ekki tilgreint tímabil. Þú þarft ekki að treysta á sérfræðinga til að tilgreina það handvirkt. Dæmigert tilvik er þegar dagsetningarbil er skrifað þar sem atburðardagur er á milli vikna. Og þá tilgreindu þeir einfaldlega sviga á röngum stað, og í staðinn fyrir og reyndist það vera eða - eða URL samsvörun. Ef það er engin takmörk mun það skríða URL dálkinn og eyða bara fullt af fjármagni.
Að auki hefur ClickHouse tvær forgangsstillingar. Því miður eru þær mjög frumstæðar. Einn er einfaldlega kallaður forgang. Ef forgangur ≠ 0, og beiðnir með einhvern forgang eru framkvæmdar, en beiðni með forgangsgildi sem er minna en, sem þýðir meiri forgang, er framkvæmd, þá er beiðni með forgangsgildi hærra, sem þýðir lægri forgang , er einfaldlega lokað og mun alls ekki virka á þessum tíma.
Þetta er mjög gróf stilling og hentar ekki fyrir tilvik þar sem þyrpingin er með stöðugt álag. En ef þú ert með stuttar, sprungnar beiðnir sem eru mikilvægar og þyrpingin er að mestu aðgerðalaus, þá hentar þessi uppsetning.
Næsta forgangsstilling er kölluð OS þráður forgangur. Það stillir einfaldlega fínt gildi fyrir alla framkvæmdarþræði fyrir beiðna fyrir Linux tímaáætlun. Það virkar svo sem svo, en það virkar samt. Ef þú stillir lágmarks fínt gildi - það er stærst í gildi, og þar af leiðandi lægsta forgang - og stillir -19 fyrir beiðnir með háan forgang, þá mun örgjörvinn neyta lágforgangsbeiðna um það bil fjórum sinnum minna en háum forgangi.
Þú þarft líka að stilla hámarks framkvæmdartíma beiðni - segjum fimm mínútur. Lágmarkshraðinn við framkvæmd fyrirspurnar er það flottasta. Þessi stilling hefur verið til í langan tíma og það þarf ekki aðeins að fullyrða að ClickHouse hægi ekki á sér heldur til að þvinga hana.
Ímyndaðu þér, þú setur upp: ef einhver fyrirspurn vinnur minna en eina milljón línur á sekúndu geturðu ekki gert það. Þetta skammar okkar góða nafn, okkar góða gagnagrunn. Við skulum bara banna þetta. Það eru í raun tvær stillingar. Einn er kallaður mín framkvæmdarhraði - í línum á sekúndu, og annað er kallað timeout áður en minnst framkvæmdarhraða er athugað - fimmtán sekúndur sjálfgefið. Það er, fimmtán sekúndur eru mögulegar, og þá, ef það er hægt, þá skaltu bara henda undanþágu og hætta við beiðnina.
Þú þarft líka að setja upp kvóta. ClickHouse er með innbyggðan kvótaeiginleika sem telur auðlindanotkun. En, því miður, ekki vélbúnaðarauðlindir eins og örgjörva, diskar, heldur rökrétt - fjöldi afgreiddra beiðna, línur og bæti lesinn. Og þú getur stillt, til dæmis, að hámarki hundrað beiðnir innan fimm mínútna og þúsund beiðnir á klukkustund.
Hvers vegna er það mikilvægt? Vegna þess að sumar greiningarfyrirspurnir verða gerðar handvirkt beint frá ClickHouse viðskiptavininum. Og allt verður gott. En ef þú ert með háþróaða sérfræðinga í fyrirtækinu þínu munu þeir skrifa handrit og það gæti verið villa í handritinu. Og þessi villa mun valda því að beiðnin verður keyrð í óendanlega lykkju. Þetta er það sem við þurfum að verjast.
Er hægt að gefa tíu viðskiptavinum niðurstöður úr einni fyrirspurn?
Við höfum nokkra notendur sem vilja koma inn með mjög stórar beiðnir á sama tíma. Beiðnin er stór og í grundvallaratriðum hraðvirk, en vegna þess að það eru margar slíkar beiðnir á sama tíma verður hún mjög sársaukafull. Er hægt að framkvæma sömu beiðnina, sem barst tíu sinnum í röð, einu sinni, og gefa tíu viðskiptavinum niðurstöðuna?
Vandamálið er að við höfum ekki niðurstöður skyndiminni eða skyndiminni milliupplýsinga. Það er síðuskyndiminni stýrikerfisins sem kemur í veg fyrir að þú lesir gögn af disknum aftur, en því miður verða gögnin samt afþjöppuð, raðlaus og endurunnin.
Ég myndi einhvern veginn vilja forðast þetta, annað hvort með því að vista milligögn í skyndiminni eða með því að stilla upp svipuðum fyrirspurnum í einhvers konar biðröð og bæta við niðurstöðu skyndiminni. Eins og er erum við með eina dráttarbeiðni í þróun sem bætir við skyndiminni beiðni, en aðeins fyrir undirfyrirspurnir í inn og sameiningu hlutanum - það er að segja að lausnin er ófullnægjandi.
Hins vegar stöndum við líka frammi fyrir slíkri stöðu. Sérstaklega kanónískt dæmi eru blaðsíðusettar fyrirspurnir. Það er skýrsla, hún hefur nokkrar síður, og það er beiðni um hámark 10. Síðan það sama, en takmörk 10,10. Svo önnur næsta síða. Og spurningin er, hvers vegna teljum við þetta allt saman í hvert skipti? En nú er engin lausn og engin leið til að forðast hana.
Það er önnur lausn sem er sett sem hliðarvagn við hlið ClickHouse - .
Kirill Shvakov: ClickHouse Proxy er með innbyggðan hraðatakmarkara og innbyggt niðurstöðuskyndiminni. Þar voru gerðar margar stillingar vegna þess að verið var að leysa svipað vandamál. Umboð gerir þér kleift að takmarka beiðnir með því að setja þær í biðröð og stilla hversu lengi beiðni skyndiminni lifir. Ef beiðnirnar voru raunverulega þær sömu mun Proxy senda þær mörgum sinnum, en fara aðeins einu sinni í ClickHouse.
Nginx er líka með skyndiminni í ókeypis útgáfunni og þetta mun líka virka. Nginx hefur meira að segja stillingar að ef beiðnir berast á sama tíma mun það hægja á öðrum þar til einni er lokið. En það er í ClickHouse Proxy sem uppsetningin er miklu betri. Það var gert sérstaklega fyrir ClickHouse, sérstaklega fyrir þessar beiðnir, svo það hentar betur. Jæja, það er auðvelt að setja upp.
Hvað með ósamstilltar aðgerðir og raunhæfar skoðanir?
Það er vandamál að aðgerðir með endurspilunarvélinni eru ósamstilltar - fyrst eru gögnin skrifuð, síðan hrynja þau. Ef efnisleg tafla með einhverju efni býr undir merkinu, þá verða afrit skrifaðar á hana. Og ef það er engin flókin rökfræði, þá verða gögnin afrituð. Hvað getur þú gert í því?
Það er augljós lausn - að innleiða kveikju á ákveðnum flokki matviews meðan á ósamstilltri hrunaðgerð stendur. Eru einhverjar silfurkúlur eða áform um að innleiða svipaða virkni?
Það er þess virði að skilja hvernig tvítekning virkar. Það sem ég segi þér núna á ekki við um spurninguna, heldur bara ef það er þess virði að muna það.
Þegar sett er inn í endurtekna töflu er aftvíföldun á öllu settu kubbunum. Ef þú setur inn aftur sama blokk sem inniheldur sama fjölda af sömu línum í sömu röð, þá eru gögnin aftvífölduð. Þú munt fá „Ok“ sem svar við innsetningu, en í raun verður einn pakki af gögnum skrifaður og hann verður ekki afritaður.
Þetta er nauðsynlegt fyrir vissu. Ef þú færð „Ok“ við innsetningu, þá hafa gögnin þín verið sett inn. Ef þú færð villu frá ClickHouse þýðir það að þær voru ekki settar inn og þú þarft að endurtaka innsetninguna. En ef tengingin rofnar við innsetningu, þá veistu ekki hvort gögnin voru sett inn eða ekki. Eini kosturinn er að endurtaka innsetninguna aftur. Ef gögnin voru í raun sett inn og þú settir þau inn aftur, þá er um að ræða blokkaaftvítekningu. Þetta er nauðsynlegt til að forðast tvítekningar.
Og það er líka mikilvægt hvernig það virkar fyrir efnislegar skoðanir. Ef gögnin voru aftvífölduð þegar þau voru sett inn í aðaltöfluna, þá fara þau ekki heldur í efnislega sýn.
Nú um spurninguna. Staðan þín er flóknari vegna þess að þú ert að taka upp afrit af einstökum línum. Það er, það er ekki allur pakkinn sem er afritaður, heldur sérstakar línur og þær hrynja saman í bakgrunni. Reyndar munu gögnin hrynja í aðaltöflunni, en ósamrunnu gögnin fara í raunveruleikasýnið og við sameiningu mun ekkert gerast við efnislegar skoðanir. Vegna þess að efnisbundið útsýni er ekkert annað en innsetningarkveikja. Við aðrar aðgerðir gerist ekkert meira við það.
Og ég get ekki glatt þig hér. Þú þarft bara að leita að ákveðinni lausn fyrir þetta mál. Til dæmis, er hægt að spila það aftur í efnislegri mynd og aftvíföldunaraðferðin gæti virkað á sama hátt. En því miður ekki alltaf. Ef það er að safnast saman mun það ekki virka.
Kirill Shvakov: Við vorum líka með hækjusmíði á sínum tíma. Það kom upp vandamál að það eru auglýsingabirtingar og það eru nokkur gögn sem við getum sýnt í rauntíma - þetta eru bara birtingar. Þau eru sjaldan afrituð, en ef þetta gerist munum við samt sem áður fella þau saman síðar. Og það voru hlutir sem ekki var hægt að afrita - smellir og öll þessi saga. En mig langaði líka að sýna þá næstum strax.
Hvernig urðu til efnislegar skoðanir? Það voru skoðanir þar sem það var skrifað beint - það var skrifað í hrá gögn og skrifað á skoðanir. Þar eru gögnin á einhverjum tímapunkti ekki mjög réttar, þau eru afrituð o.s.frv. Og það er annar hluti töflunnar, þar sem þær líta nákvæmlega eins út og raunhæfar skoðanir, það er að segja að þær eru algjörlega eins að uppbyggingu. Af og til endurreiknaum við gögnin, teljum gögnin án afrita, skrifum í þær töflur.
Við fórum í gegnum API - þetta mun ekki virka handvirkt í ClickHouse. Og API lítur út: þegar ég hef dagsetningu síðustu viðbótarinnar við töfluna, þar sem það er tryggt að rétt gögn hafi þegar verið reiknuð út, og það gerir beiðni um eina töflu og aðra töflu. Frá annarri velur beiðnin allt að ákveðinn tíma og frá hinni fær hún það sem ekki hefur enn verið reiknað út. Og það virkar, en ekki í gegnum ClickHouse eingöngu.
Ef þú ert með einhvers konar API - fyrir greinendur, fyrir notendur - þá er þetta í grundvallaratriðum valkostur. Þú ert alltaf að telja, alltaf að telja. Þetta er hægt að gera einu sinni á dag eða á öðrum tíma. Þú velur sjálfur svið sem þú þarft ekki og er ekki mikilvægt.
ClickHouse hefur mikið af annálum. Hvernig get ég séð allt sem gerist á netþjóninum í fljótu bragði?
ClickHouse er með mjög mikinn fjölda mismunandi annála og þessi fjöldi fer vaxandi. Í nýjum útgáfum eru sumar þeirra jafnvel virkjaðar sjálfgefið; í eldri útgáfum verður að virkja þær við uppfærslu. Hins vegar eru þeir fleiri og fleiri. Að lokum myndi ég vilja sjá hvað er að gerast með netþjóninn minn núna, kannski á einhvers konar yfirlitsstjórnborði.
Ertu með ClickHouse teymi, eða teymi vina þinna, sem styðja einhverja virkni tilbúinna mælaborða sem myndu sýna þessar annála sem fullunnina vöru? Að lokum, bara að horfa á annála í ClickHouse er frábært. En það væri mjög flott ef það væri þegar undirbúið í formi mælaborðs. Ég myndi fá kikk út úr þessu.
Það eru til mælaborð, þó þau séu ekki staðlað. Í fyrirtækinu okkar nota um 60 teymi ClickHouse og það undarlegasta er að mörg þeirra eru með mælaborð sem þau bjuggu til fyrir sig og aðeins önnur. Sum lið nota innri Yandex.Cloud uppsetningu. Það eru nokkrar tilbúnar skýrslur, þó ekki allar nauðsynlegar. Aðrir eiga sína eigin.
Samstarfsmenn mínir frá Metrica eru með sitt eigið mælaborð í Grafana og ég er með mitt fyrir þyrpinguna þeirra. Ég er að skoða hluti eins og skyndiminni fyrir serif skyndiminni. Og enn erfiðara er að við notum mismunandi verkfæri. Ég bjó til mælaborðið mitt með því að nota mjög gamalt tól sem heitir Graphite-web. Hann er alveg ljótur. Og ég nota það enn þannig, þó Grafana væri líklega þægilegra og fallegra.
Grunnatriðið í mælaborðum er það sama. Þetta eru kerfismælingar fyrir klasann: CPU, minni, diskur, net. Aðrir - fjöldi beiðna samtímis, fjöldi samtímis sameiningum, fjöldi beiðna á sekúndu, hámarksfjöldi bita fyrir MergeTree töfluskiptingar, afritunartöf, stærð afritunarraðar, fjöldi settra raða á sekúndu, fjöldi settra blokka á sekúndu. Þetta er allt sem fæst ekki úr annálum heldur úr mælingum.
Vladimir Kolobaev: Alexey, mig langar að leiðrétta það aðeins. Þar er Grafana. Grafana er með gagnaveitu, sem er ClickHouse. Það er, ég get gert beiðnir frá Grafana beint til ClickHouse. ClickHouse er með töflu með annálum, það er eins fyrir alla. Þar af leiðandi vil ég fá aðgang að þessari annálatöflu í Grafana og sjá þær beiðnir sem þjónninn minn gerir. Það væri frábært að hafa svona mælaborð.
Ég hjólaði það sjálfur. En ég er með spurningu - ef það er allt staðlað og Grafana er notað af öllum, hvers vegna er Yandex ekki með svona opinbert mælaborð?
Kirill Shvakov: Reyndar styður gagnagjafinn sem fer til ClickHouse nú Altinity. Og ég vil bara gefa vektor fyrir hvar á að grafa og hverjum á að ýta. Þú getur spurt þá, vegna þess að Yandex framleiðir enn ClickHouse, en ekki sagan í kringum það. Altinity er aðalfyrirtækið sem nú kynnir ClickHouse. Þeir munu ekki yfirgefa hann, heldur styðja hann. Vegna þess að í grundvallaratriðum, til að hlaða upp mælaborði á vefsíðu Grafana, þarftu aðeins að skrá þig og hlaða því upp - það eru engin sérstök vandamál.
Alexey Milovidov: Undanfarið ár hefur ClickHouse bætt við mörgum möguleikum á fyrirspurnarsniði. Það eru mælikvarðar fyrir hverja beiðni um auðlindanotkun. Og nýlega bættum við við enn lægra stigi fyrirspurnasniði til að sjá hvar fyrirspurn eyðir hverri millisekúndu. En til að nota þessa virkni þarf ég að opna stjórnborðsbiðlarann og slá inn beiðni, sem ég gleymi alltaf. Ég vistaði það einhvers staðar og gleymi alltaf hvar nákvæmlega.
Ég vildi að það væri tól sem sagði bara, hér eru þungar fyrirspurnir þínar, flokkaðar eftir fyrirspurnaflokki. Ég ýtti á einn og þeir myndu segja mér að þess vegna er hann þungur. Það er engin slík lausn núna. Og það er eiginlega alveg skrítið að þegar fólk spyr mig: „Segðu mér, eru til tilbúin mælaborð fyrir Grafana?“ þá segi ég: „Farðu á Grafana vefsíðuna, það er „Dashboards“ samfélag og það er mælaborð. frá Dimka, það er mælaborð frá Kostyan. Ég veit ekki hvað það er, ég hef ekki notað það sjálfur."
Hvernig á að hafa áhrif á sameiningu þannig að þjónninn hrynji ekki inn í OOM?
Ég er með töflu, það er aðeins ein skipting í töflunni, það er ReplaceingMergeTree. Ég hef skrifað gögn inn í það í fjögur ár. Ég þurfti að breyta því og eyða einhverjum gögnum.
Ég gerði þetta og við vinnslu þessarar beiðni var allt minni á öllum serverum í klasanum eytt og allir serverar í klasanum fóru inn í OOM. Svo stóðu þeir allir upp saman, byrjuðu að sameina þessa sömu aðgerð, þessa gagnablokk, og féllu aftur inn í OOM. Síðan stóðu þeir upp aftur og féllu aftur. Og þetta mál hætti ekki.
Svo kom í ljós að þetta var í raun og veru galli sem strákarnir laguðu. Þetta er mjög flott, takk kærlega. En leifar var eftir. Og núna, þegar ég hugsa um að gera einhvers konar sameiningu í töflunni, þá er ég með spurningu - hvers vegna get ég ekki haft áhrif á þessa sameiningu á einhvern hátt? Til dæmis, takmarkaðu þær við magn vinnsluminni sem þarf, eða, í grundvallaratriðum, við magnið sem mun vinna úr þessari tilteknu töflu.
Ég er með töflu sem heitir „Mælingar“, vinsamlegast vinnið hana fyrir mig í tveimur þráðum. Það er engin þörf á að búa til tíu eða fimm sameiningar samhliða, gerðu það í tveimur. Ég held að ég hafi nóg minni fyrir tvo, en það er kannski ekki nóg til að vinna úr tíu. Hvers vegna er ótti enn? Vegna þess að borðið er að stækka og einhvern tíma mun ég standa frammi fyrir aðstæðum sem í grundvallaratriðum er ekki lengur vegna galla, heldur vegna þess að gögnin munu breytast í svo miklu magni að ég mun einfaldlega ekki hafa nóg minni á miðlara. Og þá mun þjónninn hrynja í OOM við sameiningu. Þar að auki get ég hætt við stökkbreytinguna, en Merji er ekki lengur til staðar.
Þú veist, við sameiningu mun þjónninn ekki falla inn í OOM, því við sameiningu er magn vinnsluminni aðeins notað fyrir eitt lítið gagnasvið. Þannig að allt verður í lagi óháð gagnamagni.
Vladimir Kolobaev: Fínt. Hér er augnablikið þannig að eftir að villan var lagfærð sótti ég nýja útgáfu fyrir sjálfan mig og á öðru borði, minna, þar sem eru mörg skipting, framkvæmdi ég svipaða aðgerð. Og við sameininguna var um 100 GB af vinnsluminni brennt á þjóninum. Ég átti 150 upptekna, 100 borðaða og 50 GB glugga eftir, svo ég datt ekki inn í OOM.
Hvað verndar mig núna frá því að falla í OOM ef það eyðir í raun 100 GB af vinnsluminni? Hvað á að gera ef skyndilega vinnsluminni á sameiningunum klárast?
Alexey Milovidov: Það er svo vandamál að neysla á vinnsluminni sérstaklega fyrir sameiningu er ekki takmörkuð. Og annað vandamálið er að ef einhvers konar sameiningu hefur verið úthlutað, þá verður að framkvæma það vegna þess að það er skráð í afritunarskránni. Afritunarskráin er aðgerðirnar sem þarf til að koma eftirmyndinni í stöðugt ástand. Ef þú gerir ekki handvirkar meðhöndlun sem mun afturkalla þennan afritunarskrá, verður sameiningin að fara fram á einn eða annan hátt.
Auðvitað væri ekki óþarfi að hafa takmörkun á vinnsluminni sem „bara ef“ verndar gegn OOM. Það mun ekki hjálpa sameiningunni að klárast, hún mun byrja aftur, ná einhverjum þröskuldi, kasta undanþágu og byrja svo aftur - ekkert gott kemur úr þessu. En í grundvallaratriðum væri gagnlegt að taka upp þessa takmörkun.
Hvernig verður Golang bílstjórinn fyrir ClickHouse þróaður?
Golang ökumaðurinn, sem var skrifaður af Kirill Shvakov, er nú opinberlega studdur af ClickHouse teyminu. Hann , hann er nú stór og raunverulegur.
Smá aths. Það er dásamleg og ástsæl geymsla af venjulegum formum óendanlega röð - þetta er Vertica. Þeir hafa líka sinn eigin opinbera python-rekla sem er studdur af Vertica hönnuðum. Og nokkrum sinnum gerðist það að geymsluútgáfur og ökumannsútgáfur skiptust verulega á og ökumaðurinn hætti á einhverjum tímapunkti að virka. Og annað atriðið. Stuðningur við þennan opinbera ökumann, að því er mér sýnist, fer fram með „geirvörtu“ kerfinu - þú skrifar þeim mál og það hangir að eilífu.
Ég er með tvær spurningar. Nú er Golang bílstjóri Kirill næstum sjálfgefna leiðin til að hafa samskipti frá Golang með ClickHouse. Nema einhver hafi enn samskipti í gegnum http viðmótið vegna þess að honum líkar það þannig. Hvernig mun þróun þessa bílstjóra halda áfram? Verður það samstillt við allar brotlegar breytingar á geymslunni sjálfri? Og hvernig er málsmeðferðin við að íhuga mál?
Kirill Shvakov: Í fyrsta lagi er það hvernig allt er skipulagt á skriffinnskulegan hátt. Þetta atriði var ekki rætt og því hef ég engu að svara.
Til að svara spurningunni um málið þurfum við smá sögu ökumannsins. Ég vann hjá fyrirtæki sem átti mikið af gögnum. Þetta var auglýsingasnúður með gífurlegum fjölda viðburða sem þurfti að geyma einhvers staðar. Og á einhverjum tímapunkti birtist ClickHouse. Við fylltum það af gögnum og fyrst var allt í lagi, en síðan hrundi ClickHouse. Á því augnabliki ákváðum við að við þyrftum þess ekki.
Ári síðar snerum við aftur að hugmyndinni um að nota ClickHouse og við þurftum að skrifa gögn þar einhvern veginn. Kynningarskilaboðin voru þessi: vélbúnaðurinn er mjög veikburða, það eru fáir úrræði. En við höfum alltaf unnið á þennan hátt og þess vegna horfðum við til innfæddra siðareglur.
Þar sem við vorum að vinna í Go var ljóst að okkur vantaði Go bílstjóra. Ég gerði það nánast í fullu starfi - þetta var vinnuverkefni mitt. Við komum því að vissu marki og í grundvallaratriðum gerði enginn ráð fyrir því að aðrir en við myndu nota það. Svo kom CloudFlare með nákvæmlega sama vandamálið og í nokkurn tíma unnum við mjög vel með þá, því þeir höfðu sömu verkefni. Þar að auki gerðum við þetta bæði í ClickHouse sjálfum og í bílstjóranum.
Á einhverjum tímapunkti hætti ég einfaldlega að gera það, vegna þess að virkni mín hvað varðar ClickHouse og vinnu breyttist aðeins. Þess vegna er málum ekki lokað. Reglulega skuldbindur fólk sig sem þarf eitthvað sjálft til geymslunnar. Svo horfi ég á pull request og stundum breyti ég einhverju sjálfur, en þetta gerist sjaldan.
Ég vil snúa aftur til bílstjórans. Fyrir nokkrum árum, þegar allt þetta hófst, var ClickHouse líka öðruvísi og með mismunandi getu. Nú höfum við skilning á því hvernig á að endurgera ökumanninn þannig að hann virki vel. Ef þetta gerist, þá verður útgáfa 2 ósamrýmanleg í öllum tilvikum vegna uppsafnaðra hækja.
Ég veit ekki hvernig ég á að skipuleggja þetta mál. Sjálf hef ég ekki mikinn tíma. Ef einhverjir klára bílstjórann get ég hjálpað þeim og sagt þeim hvað þeir eigi að gera. En virka þátttaka Yandex í þróun verkefnisins hefur ekki enn verið rædd.
Alexey Milovidov: Reyndar er ekkert skrifræði um þessa ökumenn ennþá. Málið er bara að þau eru send til opinberra stofnana, það er að þessi bílstjóri er viðurkenndur sem opinber sjálfgefin lausn fyrir Go. Það eru nokkrir aðrir ökumenn, en þeir koma sérstaklega.
Við erum ekki með neina innri þróun fyrir þessa ökumenn. Spurningin er hvort við getum ráðið einstakling, ekki fyrir þennan tiltekna bílstjóra, heldur fyrir þróun allra samfélagsbílstjóra, eða getum við fundið einhvern utan frá.
Ytri orðabók hleðst ekki eftir endurræsingu með lazy_load stillingu virka. Hvað skal gera?
Við höfum lazy_load stillinguna virka og eftir að þjónninn er endurræstur hleðst orðabókin ekki sjálf. Það er hækkað aðeins eftir að notandinn hefur opnað þessa orðabók. Og í fyrsta skipti sem ég opna það, þá gefur það villu. Er hægt að hlaða orðabókum sjálfkrafa á einhvern hátt með því að nota ClickHouse, eða þarftu alltaf að stjórna viðbúnaði þeirra sjálfur svo notendur fái ekki villur?
Kannski erum við með gamla útgáfu af ClickHouse, þannig að orðabókin hlóðst ekki sjálfkrafa. Gæti þetta verið raunin?
Í fyrsta lagi er hægt að þvinga orðabækur með því að nota fyrirspurn kerfi endurhlaða orðabækur. Í öðru lagi, varðandi villuna - ef orðabókin er þegar hlaðin, þá munu fyrirspurnirnar virka út frá gögnunum sem voru hlaðnir. Ef orðabókinni hefur ekki enn verið hlaðið verður henni hlaðið beint meðan á beiðni stendur.
Þetta er ekki mjög þægilegt fyrir þungar orðabækur. Til dæmis þarftu að draga milljón raðir úr MySQL. Einhver gerir einfalt val, en þetta val mun bíða eftir sömu milljón línum. Hér eru tvær lausnir. Í fyrsta lagi er að slökkva á lazy_load. Í öðru lagi, þegar þjónninn er uppi, áður en þú leggur álag á hann, gerðu það kerfi endurhlaða orðabók eða bara gera fyrirspurn sem notar orðabók. Þá verður orðabókin hlaðin. Þú þarft að stjórna framboði orðabóka með lazy_load stillingunni virka, vegna þess að ClickHouse hleður þeim ekki sjálfkrafa.
Svarið við síðustu spurningunni er annað hvort að útgáfan er gömul eða það þarf að kemba hana.
Hvað á að gera við þá staðreynd að endurhlaða orðabækur kerfisins hleður engum af mörgum orðabókum ef að minnsta kosti ein þeirra hrynur með villu?
Það er önnur spurning um kerfisendurhleðsluorðabækur. Við höfum tvær orðabækur - önnur er ekki hlaðin, önnur er hlaðin. Í þessu tilviki hleður kerfisendurhleðsluorðabækur enga orðabók og þú verður að hlaða ákveðna orðabók punkt fyrir punkt með nafni hennar með því að nota kerfisendurhleðsluorðabók. Er þetta líka tengt ClickHouse útgáfunni?
Ég vil gleðja þig. Þessi hegðun var að breytast. Þetta þýðir að ef þú uppfærir ClickHouse mun það líka breytast. Ef þú ert ekki ánægður með núverandi hegðun þína kerfi endurhlaða orðabækur, uppfærðu, og við skulum vona að það breytist til hins betra.
Er einhver leið til að stilla upplýsingar í ClickHouse stillingunni, en ekki birta þær ef villur koma upp?
Næsta spurning er um villur tengdar orðabókinni, nefnilega smáatriði. Við höfum tilgreint tengingarupplýsingarnar í ClickHouse stillingunni fyrir orðabókina og ef það er villa fáum við þessar upplýsingar og lykilorð sem svar.
Við leystum þessa villu með því að bæta upplýsingum við ODBC ökumannsstillinguna. Er einhver leið til að stilla upplýsingarnar í ClickHouse stillingunni, en sýna ekki þessar upplýsingar ef villur koma upp?
Raunverulega lausnin hér er að tilgreina þessi skilríki í odbc.ini og í ClickHouse sjálfu tilgreinir aðeins ODBC Data Source Name. Þetta mun ekki gerast fyrir aðrar orðabókarheimildir - hvorki fyrir orðabókina með MySQL, né fyrir hina, þú ættir ekki að sjá lykilorðið þegar þú færð villuboð. Fyrir ODBC mun ég líka skoða - ef það er til þarftu bara að fjarlægja það.
Bónus: bakgrunnur fyrir Zoom frá samkomum
Með því að smella á myndina opnast bónusbakgrunnur frá samkomunum fyrir þrálátustu lesendurna. Við slökktum eldinn ásamt Avito tækni lukkudýrunum, ráðfærum okkur við samstarfsmenn úr herbergi kerfisstjóra eða tölvuklúbbi gamla skólans og höldum daglega fundi undir brúnni í bakgrunni veggjakrots.
Heimild: www.habr.com