HighLoad++ Moscow 2018, Congress Hall. 9. nóvember, 15:00
Ágrip og kynning:
Yuri Nasretdinov (VKontakte): skýrslan mun fjalla um reynsluna af því að innleiða ClickHouse í fyrirtækinu okkar - hvers vegna við þurfum það, hversu mikið af gögnum við geymum, hvernig við skrifum þau og svo framvegis.
Viðbótarefni:
Yuri Nasretdinov: - Hæ allir! Ég heiti Yuri Nasretdinov, eins og ég hef þegar verið kynntur. Ég vinn hjá VKontakte. Ég mun tala um hvernig við setjum gögn inn í ClickHouse frá netþjónaflotanum okkar (tugþúsundir).
Hvað eru logs og hvers vegna safna þeim?
Það sem við munum segja þér: hvað við gerðum, hvers vegna við þurftum „ClickHouse“, í sömu röð, hvers vegna við völdum það, hvers konar frammistöðu þú getur náð án þess að stilla neitt sérstaklega. Ég skal segja þér frekar um biðminnistöflur, um vandamálin sem við áttum við þær og um lausnir okkar sem við þróuðum frá opnum uppspretta - KittenHouse og Lighthouse.
Af hverju þurftum við að gera eitthvað (allt er alltaf gott á VKontakte, ekki satt?). Okkur langaði til að safna kembiforritum (og það voru hundruð terabæta af gögnum þar), kannski væri einhvern veginn þægilegra að reikna út tölfræði; og við höfum flota af tugum þúsunda netþjóna sem allt þetta þarf að gera frá.
Hvers vegna ákváðum við? Við höfðum líklega lausnir til að geyma logs. Hér - það er svo opinber "Backend VK". Ég mæli eindregið með því að gerast áskrifandi að því.
Hvað eru logs? Þetta er vél sem skilar tómum fylkjum. Vélar í VK eru það sem aðrir kalla örþjónustur. Og hér er brosandi límmiði (alveg mikið af likes). Hvernig þá? Jæja, hlustaðu frekar!
Hvað er hægt að nota til að geyma logs? Það er ekki hægt að minnast á Hadup. Þá, til dæmis, Rsyslog (geymir þessar logs í skrám). LSD. Hver veit hvað LSD er? Nei, ekki þetta LSD. Geymdu skrár, í sömu röð, líka. Jæja, ClickHouse er undarlegur valkostur.
Clickhouse og samkeppnisaðilar: kröfur og tækifæri
Hvað viljum við? Við viljum tryggja að við þurfum ekki að hafa of miklar áhyggjur af aðgerðinni, svo að hún virki út úr kassanum, helst með lágmarks stillingum. Okkur langar að skrifa mikið og skrifa fljótt. Og við viljum halda því í alls kyns mánuði, ár, það er að segja í langan tíma. Við gætum viljað skilja eitthvað vandamál sem þeir komu til okkar með og sögðu: "Eitthvað er ekki að virka hér," og það var fyrir 3 mánuðum síðan), og við viljum geta séð hvað gerðist fyrir 3 mánuðum síðan " Gagnaþjöppun - það er ljóst hvers vegna það væri plús - vegna þess að það dregur úr plássinu sem það tekur.
Og við höfum svo áhugaverða kröfu: við skrifum stundum úttak sumra skipana (til dæmis logs), það getur auðveldlega verið meira en 4 kílóbæti. Og ef þessi hlutur virkar yfir UDP, þá þarf hann ekki að eyða ... það mun ekki hafa nein "kostnaður" fyrir tenginguna og fyrir mikinn fjölda netþjóna mun þetta vera plús.
Við skulum sjá hvað opinn uppspretta býður okkur. Í fyrsta lagi höfum við Logs Engine - þetta er vélin okkar; Í grundvallaratriðum getur hann allt, hann getur jafnvel skrifað langar línur. Jæja, það þjappar ekki gagnsæjum gögnum - við getum þjappað stórum dálkum sjálf ef við viljum... við viljum það auðvitað ekki (ef mögulegt er). Vandamálið er bara að hann getur aðeins gefið frá sér það sem passar í minningu hans; Til að lesa restina þarftu að fá binlog þessarar vélar og því tekur það nokkuð langan tíma.
Hvaða aðrir valkostir eru í boði? Til dæmis, "Hadup". Auðvelt í rekstri... Hver heldur að Hadup sé auðvelt að setja upp? Auðvitað eru engin vandamál með upptökuna. Við lestur vakna stundum spurningar. Í grundvallaratriðum myndi ég segja líklega ekki, sérstaklega fyrir logs. Langtíma geymsla - auðvitað, já, gagnaþjöppun - já, langir strengir - það er ljóst að þú getur tekið upp. En að taka upp frá miklum fjölda netþjóna... Þú verður samt að gera eitthvað sjálfur!
Rsyslog. Reyndar notuðum við það sem öryggisafrit þannig að við gætum lesið það án þess að henda binloginu, en það getur ekki skrifað langar línur, í grundvallaratriðum getur það ekki skrifað meira en 4 kílóbæti. Þú verður að gera gagnaþjöppun á sama hátt sjálfur. Lestur mun koma úr skrám.
Svo er það „badushka“ þróun LSD. Í meginatriðum það sama og „Rsyslog“: það styður langa strengi, en það getur ekki virkað í gegnum UDP og í raun, vegna þessa, því miður þarf að endurskrifa töluvert af hlutum þar. LSD þarf að endurhanna til að hægt sé að taka upp frá tugþúsundum netþjóna.
Og hér! Fyndinn valkostur er ElasticSearch. Hvernig á að segja? Honum gengur vel að lesa, það er að segja að hann les fljótt, en ekki mjög vel að skrifa. Í fyrsta lagi, ef það þjappar gögnum, er það mjög veikt. Líklegast er að full leit krefst stærri gagnauppbyggingar en upprunalega rúmmálsins. Það er erfitt í rekstri og oft koma upp vandamál við það. Og aftur, taka upp í Elastic - við verðum að gera allt sjálf.
Hér er ClickHouse auðvitað kjörinn kostur. Það eina er að upptaka frá tugþúsundum netþjóna er vandamál. En það er allavega eitt vandamál, við getum reynt að leysa það einhvern veginn. Og restin af skýrslunni er um þetta vandamál. Hvers konar frammistöðu geturðu búist við frá ClickHouse?
Hvernig ætlum við að setja það inn? MergeTree
Hver af ykkur hefur ekki heyrt eða veit um „ClickHouse“? Ég þarf að segja þér það, er það ekki? Mjög hratt. Innsetningin þarna - 1-2 gígabit á sekúndu, allt að 10 gígabit á sekúndu þolir í raun þessa stillingu - það eru tveir 6 kjarna Xeons (það er ekki einu sinni þeir öflugustu), 256 gígabæti af vinnsluminni, 20 terabæta í RAID (enginn stilltur, sjálfgefnar stillingar). Alexey Milovidov, ClickHouse verktaki, situr líklega þarna og grætur vegna þess að við stilltum ekki neitt (allt virkaði þannig fyrir okkur). Samkvæmt því er hægt að fá skönnunarhraða upp á td um 6 milljarða lína á sekúndu ef gögnin eru vel þjappuð. Ef þér líkar við % á textastreng - 100 milljón línur á sekúndu, það er, það virðist vera frekar hratt.
Hvernig ætlum við að setja það inn? Jæja, þú veist að VK notar PHP. Við munum setja frá hverjum PHP starfsmanni í gegnum HTTP inn í „ClickHouse“ í MergeTree töfluna fyrir hverja skrá. Hver sér vandamál við þetta kerfi? Einhverra hluta vegna réttu ekki allir upp hönd. Leyfðu mér að segja þér.
Í fyrsta lagi eru margir netþjónar - í samræmi við það verða margar tengingar (slæmar). Þá er betra að setja gögn inn í MergeTree ekki oftar en einu sinni á sekúndu. Og hver veit hvers vegna? Allt í lagi, allt í lagi. Ég skal segja þér aðeins meira um þetta. Önnur áhugaverð spurning er sú að við erum ekki að gera greiningar, við þurfum ekki að auðga gögnin, við þurfum ekki millistigsþjóna, við viljum setja beint inn í „ClickHouse“ (helst - því beint, því betra).
Í samræmi við það, hvernig er innsetning gerð í MergeTree? Af hverju er betra að setja inn í það ekki oftar en einu sinni á sekúndu eða sjaldnar? Staðreyndin er sú að "ClickHouse" er dálkagagnagrunnur og flokkar gögnin í hækkandi röð eftir aðallyklinum og þegar þú setur inn er fjöldi skráa búinn til að minnsta kosti jafn fjölda dálka sem gögnin eru flokkuð í. í hækkandi röð aðallykilsins (sérstök mappa er búin til, sett af skrám á diski fyrir hverja innsetningu). Svo kemur næsta innsetning og í bakgrunni eru þau sameinuð í stærri „skilrúm“. Þar sem gögnin eru flokkuð er hægt að „sameina“ tvær flokkaðar skrár án þess að eyða miklu minni.
En, eins og þú gætir giska á, ef þú skrifar 10 skrár fyrir hverja innskot, þá mun ClickHouse (eða þjónninn þinn) fljótt enda, svo það er mælt með því að setja inn í stórar lotur. Í samræmi við það settum við aldrei fyrsta kerfið í framleiðslu. Við settum strax af stað einn, sem hér hefur nr. 2:
Ímyndaðu þér að það séu um þúsund netþjónar sem við höfum sett af stað á, það er bara PHP. Og á hverjum netþjóni er staðbundinn umboðsmaður okkar, sem við kölluðum „Kettlingahús“, sem heldur einni tengingu við „ClickHouse“ og setur inn gögn á nokkurra sekúndna fresti. Setur gögn ekki inn í MergeTree, heldur í biðminni töflu, sem þjónar einmitt til að forðast að setja beint inn í MergeTree strax.
Vinna með biðminni töflur
Hvað það er? Stuðlartöflur eru minnisstykki sem er rifið (það er hægt að setja það oft inn í það). Þeir samanstanda af nokkrum hlutum, og hver hluti virkar sem sjálfstæður biðminni, og þeir eru skolaðir sjálfstætt (ef þú ert með marga hluti í biðminni, þá verður mikið af innskotum á sekúndu). Það er hægt að lesa úr þessum töflum - þá lestu samruna innihalds biðminni og foreldratöflunnar, en á þessari stundu er skrifin læst, svo það er betra að lesa ekki þaðan. Og biðminni töflur sýna mjög gott QPS, það er allt að 3 þúsund QPS þú munt ekki eiga í neinum vandræðum þegar þú setur inn. Það er ljóst að ef þjónninn missir afl, þá geta gögnin glatast, því þau voru aðeins geymd í minni.
Á sama tíma flækir kerfið með biðminni ALTER, vegna þess að þú þarft fyrst að sleppa gömlu biðminni töflunni með gamla kerfinu (gögnin hverfa hvergi, því þau verða skoluð áður en töflunni er eytt). Síðan „breytir“ töflunni sem þú þarft og býrð til biðminnistöfluna aftur. Í samræmi við það, á meðan það er engin biðminni tafla, munu gögnin þín ekki flæða neitt, en þú getur haft þau á disknum að minnsta kosti á staðnum.
Hvað er Kittenhouse og hvernig virkar það?
Hvað er KittenHouse? Þetta er umboð. Giska á hvaða tungumál? Ég safnaði mestu hype-umræðunum í skýrslunni minni - "Clickhouse", Go, kannski man ég eftir einhverju öðru. Já, þetta er skrifað í Go, því ég kann ekki alveg hvernig á að skrifa í C, ég vil það ekki.
Í samræmi við það heldur það tengingu við hvern netþjón og getur skrifað í minni. Til dæmis, ef við skrifum villuskrár í Clickhouse, þá ef Clickhouse hefur ekki tíma til að setja inn gögn (eftir allt, ef of mikið er skrifað), þá stækkum við ekki minnið - við hendum einfaldlega restinni út. Vegna þess að ef við skrifum nokkra gígabita á sekúndu af villum, þá getum við líklega hent einhverjum út. Kittenhouse getur gert þetta. Auk þess getur það framkvæmt áreiðanlega afhendingu, það er að segja að skrifa á disk á staðbundinni vél og einu sinni í hvert skipti (þar, einu sinni á nokkurra sekúndna fresti) reynir það að skila gögnum úr þessari skrá. Og í fyrstu notuðum við venjulegt gildissnið - ekki eitthvert tvöfalt snið, textasnið (eins og í venjulegu SQL).
En svo gerðist þetta. Við notuðum áreiðanlega afhendingu, skrifuðum logs, ákváðum svo (það var skilyrt prófþyrping)... Hann var settur út í nokkrar klukkustundir og færður aftur upp og innsetning byrjaði frá þúsund netþjónum - það kom í ljós að Clickhouse var enn með „Þráður við tengingu“ - í samræmi við það, í þúsund tengingum, leiðir virk innsetning til að meðaltali álags á netþjóninn er um eitt og hálft þúsund. Það kom á óvart að þjónninn samþykkti beiðnir, en gögnin voru samt sett inn eftir nokkurn tíma; en það var mjög erfitt fyrir þjóninn að þjóna því...
Bættu við nginx
Slík lausn fyrir Thread per connection líkanið er nginx. Við settum upp nginx fyrir framan Clickhouse, settum á sama tíma upp jafnvægi fyrir tvær eftirmyndir (innsetningarhraði okkar jókst um 2 sinnum, þó það sé ekki staðreynd að þetta ætti að vera raunin) og takmörkuðum fjölda tenginga við Clickhouse, við andstreymis og, í samræmi við það, meira en í 50 tengingum, það virðist vera ekkert vit í að setja inn.
Þá komumst við að því að þetta kerfi hefur almennt ókosti, vegna þess að við höfum aðeins einn nginx hér. Í samræmi við það, ef þessi nginx hrynur, þrátt fyrir tilvist eftirlíkinga, týnum við gögnum eða, að minnsta kosti, skrifum hvergi. Þess vegna gerðum við okkar eigin álagsjafnvægi. Við áttum okkur líka á því að „Clickhouse“ hentar enn fyrir logs og „púkinn“ byrjaði líka að skrifa logs sína í „Clickhouse“ - mjög þægilegt, satt að segja. Við notum það enn fyrir aðra „djöfla“.
Síðan uppgötvuðum við þetta áhugaverða vandamál: ef þú notar óstöðluð aðferð við að setja inn í SQL ham, þvingar það fram fullgildan AST-undirstaða SQL flokka, sem er frekar hægur. Í samræmi við það höfum við bætt við stillingum til að tryggja að þetta gerist aldrei. Við gerðum álagsjöfnun, heilsufarsskoðun, þannig að ef einhver deyr, skiljum við gögnin eftir. Við erum núna með töluvert af borðum sem við þurfum til að hafa mismunandi Clickhouse klasa. Og við byrjuðum líka að hugsa um aðra notkun - til dæmis vildum við skrifa logs úr nginx einingum, en þeir vita ekki hvernig á að hafa samskipti með RPC okkar. Jæja, mig langar að kenna þeim hvernig á að senda að minnsta kosti einhvern veginn - til dæmis að taka á móti viðburðum á localhost í gegnum UDP og senda þá síðan til Clickhouse.
Eitt skref frá lausn
Lokakerfið byrjaði að líta svona út (fjórða útgáfan af þessu kerfi): á hverjum netþjóni fyrir framan Clickhouse er nginx (á sama netþjóni) og það sendir einfaldlega beiðnir til localhost með takmörkun á fjölda tenginga upp á 50 stykki. Og þetta kerfi var nú þegar alveg að virka, allt var frekar gott með það.
Við bjuggum svona í rúman mánuð. Allir voru ánægðir, þeir bættu við töflum, þeir bættu við, þeir bættu við... Almennt kom í ljós að það hvernig við bættum við biðminnistöflum var ekki mjög ákjósanlegt (við skulum orða það þannig). Við gerðum 16 stykki í hverju borði og nokkrar sekúndur á milli; við vorum með 20 borð og hvert borð fékk 8 innskot á sekúndu - og á þessum tímapunkti byrjaði “Clickhouse”... færslurnar fóru að hægja á sér. Ekki nóg með að þær stóðust ekki... Sjálfgefið var að nginx var með svo áhugaverðan hlut að ef tengingar enduðu í andstreymi, þá skilaði það einfaldlega „502“ í allar nýjar beiðnir.
Og hér höfum við (ég horfði bara á annálana í Clickhouse sjálfu) um hálft prósent af beiðnum mistókst. Samkvæmt því var diskanýting mikil, það var mikið um sameiningu. Jæja, hvað gerði ég? Auðvitað nennti ég ekki að átta mig á hvers vegna nákvæmlega tengingunni og andstreymis lauk.
Skipt um nginx fyrir öfugt umboð
Ég ákvað að við þyrftum að stjórna þessu sjálf, við þurfum ekki að láta nginx það eftir - nginx veit ekki hvaða töflur það eru í Clickhouse og ég skipti nginx út fyrir öfugt umboð, sem ég skrifaði líka sjálfur.
Hvað er hann að gera? Það virkar byggt á fasthttp bókasafninu „goshnoy“, það er hratt, næstum jafn hratt og nginx. Því miður, Igor, ef þú ert til staðar hér (athugið: Igor Sysoev er rússneskur forritari sem bjó til nginx vefþjóninn). Það getur skilið hvers konar fyrirspurnir þetta eru - INSERT eða SELECT - í samræmi við það, það hefur mismunandi tengingarhópa fyrir mismunandi gerðir fyrirspurna.
Í samræmi við það, jafnvel þótt við höfum ekki tíma til að klára innsetningarbeiðnirnar, munu „valið“ standast og öfugt. Og það flokkar gögnin í biðminni töflur - með litlum biðminni: ef það voru einhverjar villur, setningafræðivillur og svo framvegis - þannig að þær hefðu ekki mikil áhrif á restina af gögnunum, því þegar við einfaldlega settum inn í biðminni töflur, hafði lítið "bachi", og allar setningafræðivillur höfðu aðeins áhrif á þetta litla verk; og hér munu þeir þegar hafa áhrif á stóran biðminni. Lítið er 1 megabæti, það er, ekki svo lítið.
Að setja inn samstillingu og í rauninni skipta um nginx, gerir í meginatriðum það sama og nginx gerði áður - þú þarft ekki að breyta staðbundnu „Kettlingahúsi“ fyrir þetta. Og þar sem það notar fasthttp er það mjög hratt - þú getur gert meira en 100 þúsund beiðnir á sekúndu fyrir stakar innsetningar í gegnum öfugt umboð. Fræðilega séð geturðu sett eina línu í einu inn í kettlingahúsið öfugt umboð, en auðvitað gerum við það ekki.
Kerfið byrjaði að líta svona út: „Kettlingahús“, andstæða umboðið flokkar margar beiðnir í töflur og aftur á móti setja biðminnistöflurnar þær inn í þær helstu.
Killer er tímabundin lausn, Kitten er varanleg
Þetta er áhugavert vandamál... Hefur einhver ykkar notað fasthttp? Hver notaði fasthttp með POST beiðnum? Sennilega hefði þetta í raun ekki átt að vera gert, vegna þess að það biðjast sjálfgefið fyrir meginmál beiðninnar og biðminni okkar var stillt á 16 megabæti. Innsetningin hætti að halda í við einhvern tíma og 16 megabæta klumpur fóru að berast frá öllum tugþúsundum netþjóna og þeir voru allir í biðminni áður en þeir voru sendir til Clickhouse. Í samræmi við það kláraðist minnið, morðinginn utan minnis kom og drap öfuga umboðið (eða „Clickhouse“, sem gæti fræðilega „borðað“ meira en öfuga umboðið). Hringrásin endurtók sig. Ekki mjög skemmtilegt vandamál. Þó við lentum í þessu aðeins eftir nokkurra mánaða rekstur.
Hvað hef ég gert? Aftur, mér líkar ekki alveg að skilja hvað nákvæmlega gerðist. Ég held að það sé nokkuð augljóst að þú ættir ekki að buffa inn í minnið. Ég gat ekki patchað fasthttp, þó ég hafi reynt. En ég fann leið til að gera það þannig að það væri engin þörf á að patcha neitt, og ég kom með mína eigin aðferð í HTTP - ég kallaði það KITTEN. Jæja, það er rökrétt - "VK", "Kettlingur" ... Hvað annað? ..
Ef beiðni kemur til netþjónsins með kettlingaaðferðinni, þá ætti þjónninn að svara „mjá“ - rökrétt. Ef hann bregst við þessu, þá er talið að hann skilji þessa samskiptareglu, og þá hlera ég tenginguna (fasthttp er með slíka aðferð), og tengingin fer í “raw” mode. Af hverju þarf ég það? Ég vil stjórna því hvernig lestur úr TCP tengingum gerist. TCP hefur dásamlega eiginleika: ef enginn er að lesa frá hinni hliðinni, þá byrjar skrifin að bíða og minni er ekki sérstaklega varið í þetta.
Og svo las ég frá um 50 viðskiptavinum í einu (frá fimmtíu vegna þess að fimmtíu ætti örugglega að vera nóg, jafnvel þó gjaldið komi frá öðru DC)... Neysla hefur minnkað með þessari nálgun að minnsta kosti 20 sinnum, en ég, satt að segja , Ég gat ekki mælt nákvæmlega hvaða tíma, því það er nú þegar tilgangslaust (það er nú þegar komið á villustigið). Samskiptareglur eru tvöfaldar, það er að segja að hún inniheldur töfluheitið og gögnin; það eru engir http-hausar, svo ég notaði ekki vefinnstungu (ég þarf ekki að eiga samskipti við vafra - ég bjó til samskiptareglur sem hentar þörfum okkar). Og allt varð í lagi með hann.
Buffertaflan er sorgleg
Nýlega rákumst við á annan áhugaverðan eiginleika biðminnistöflum. Og þetta vandamál er nú þegar miklu sársaukafyllra en hin. Við skulum ímynda okkur þetta ástand: þú ert nú þegar virkur að nota Clickhouse, þú ert með heilmikið af Clickhouse netþjónum og þú ert með nokkrar beiðnir sem taka mjög langan tíma að lesa (við skulum segja meira en 60 sekúndur); og þú kemur og gerir Alter á þessu augnabliki... Í millitíðinni verða „velur“ sem hófust á undan „Alter“ ekki með í þessari töflu, „Alter“ mun ekki byrja - líklega eru einhverjir eiginleikar þess hvernig „Clickhouse“ virkar í þessi staður. Kannski er hægt að laga þetta? Eða er það ekki hægt?
Almennt séð er ljóst að í raun er þetta ekki svo stórt vandamál, en með biðminni töflum verður það sársaukafyllra. Vegna þess að ef, við skulum segja, "Alter" tímamörk þín (og það gæti hætt á öðrum hýsil - ekki á þínum, heldur á eftirmynd, til dæmis), þá... Þú eyddir biðminni töflunni, "Alter" þínum ( eða einhver annar gestgjafi) rann út á tíma. þá hefur „Breyta“ villa átt sér stað) - þú þarft samt að tryggja að gögnin haldi áfram að vera skrifuð: þú býrð til biðminnistöflurnar til baka (samkvæmt sama kerfi og yfirtaflan), síðan „Alter“ fer í gegnum, endar eftir allt saman, og biðminni sem borðið byrjar að vera frábrugðið foreldrinu í skema. Það fer eftir því hvað „Alter“ var, innskotið gæti ekki lengur farið í þessa biðminni - þetta er mjög sorglegt.
Það er líka slíkt merki (kannski hefur einhver tekið eftir því) - það heitir query_thread_log í nýjum útgáfum af Clickhouse. Sjálfgefið, í einhverri útgáfu var einn. Hér höfum við safnað 840 milljón færslum á nokkrum mánuðum (100 gígabæta). Þetta er vegna þess að „innskot“ voru skrifaðar þar (kannski núna, við the vegur, eru þær ekki skrifaðar). Eins og ég sagði þér eru „innskotin“ okkar lítil - við vorum með fullt af „innskotum“ í biðminnistöflurnar. Það er ljóst að þetta er óvirkt - ég er bara að segja þér hvað ég sá á þjóninum okkar. Hvers vegna? Þetta er önnur rök gegn því að nota biðminni töflur! Spotty er mjög leiður.
Hver vissi að þessi gaur héti Spotty? Starfsmenn VK réttu upp hönd. Allt í lagi.
Um áætlanir fyrir "KittenHouse"
Venjulega er áætlunum ekki deilt, ekki satt? Allt í einu muntu ekki uppfylla þau og líta ekki mjög vel út í augum annarra. En ég tek áhættuna! Við viljum gera eftirfarandi: biðminni töflur, sýnist mér, eru enn hækja og við þurfum að biðja innsetninguna sjálf. En við viljum samt ekki setja það í biðminni á disknum, svo við munum biðja innsetninguna í minni.
Í samræmi við það, þegar „innsetning“ er gerð, mun hún ekki lengur vera samstillt - hún mun nú þegar virka sem biðminni tafla, mun setja inn í móðurtöfluna (jæja, einhvern daginn seinna) og tilkynna um sérstaka rás hvaða innskot hafa liðið og hvaða hafa ekki.
Af hverju get ég ekki skilið samstilltu innleggið? Það er miklu þægilegra. Staðreyndin er sú að ef þú setur inn frá 10 þúsund vélum, þá er allt í lagi - þú færð smá frá hverjum gestgjafa, þú setur inn einu sinni á sekúndu, allt er í lagi. En ég myndi vilja að þetta kerfi virki, til dæmis, frá tveimur vélum, þannig að þú getir halað niður á miklum hraða - kannski ekki fengið hámarks út úr Clickhouse, en skrifað að minnsta kosti 100 megabæti á sekúndu frá einni vél í gegnum öfugt umboð - þetta verður kerfið að stækka í bæði stórt og lítið magn, svo við getum ekki beðið í eina sekúndu eftir hverri innsetningu, svo það verður að vera ósamstilltur. Og á sama hátt ættu ósamstilltar staðfestingar að koma eftir að innsetningunni er lokið. Við fáum að vita hvort það hafi gengið eftir eða ekki.
Mikilvægast er að í þessu kerfi vitum við með vissu hvort innsetningin átti sér stað eða ekki. Ímyndaðu þér þessar aðstæður: þú ert með biðminni töflu, þú skrifaðir eitthvað inn í hana, og við skulum segja að taflan fór í skrifvarinn ham og reyndi að skola biðminni. Hvert munu gögnin fara? Þeir verða áfram í biðminni. En við getum ekki verið viss um þetta - hvað ef það er einhver önnur villa, vegna þess að gögnin verða ekki áfram í biðminni... (Hefur Alexey Milovidov, Yandex, ClickHouse verktaki) Eða verða þau áfram? Alltaf? Alexey sannfærir okkur um að allt verði í lagi. Við höfum enga ástæðu til að trúa honum ekki. En allt það sama: ef við notum ekki biðminni töflur, þá verða engin vandamál með þær. Að búa til tvöfalt fleiri borð er líka óþægilegt, þó í grundvallaratriðum séu engin stór vandamál. Þetta er planið.
Við skulum tala um lestur
Nú skulum við tala um lestur. Við skrifuðum líka okkar eigin verkfæri hér. Það virðist, jæja, hvers vegna að skrifa þitt eigið hljóðfæri hér? .. Og hver notaði Tabix? Einhvern veginn réttu fáir upp hönd... Og hver er sáttur við frammistöðu Tabix? Jæja, við erum ekki ánægð með það og það er ekki mjög þægilegt til að skoða gögn. Það er fínt fyrir greiningar, en bara til að skoða það er greinilega ekki bjartsýni. Svo ég skrifaði mitt eigið viðmót.
Það er mjög einfalt - það getur aðeins lesið gögn. Hann kann ekki að sýna grafík, hann kann ekki að gera neitt. En það getur sýnt hvað við þurfum: til dæmis hversu margar línur eru í töflunni, hversu mikið pláss það tekur (án þess að skipta því niður í dálka), það er að segja mjög undirstöðuviðmót er það sem við þurfum.
Og það lítur mjög svipað út og Sequel Pro, en aðeins gert á Twitter Bootstrap og annarri útgáfunni. Þú spyrð: "Yuri, hvers vegna í annarri útgáfunni?" Hvaða ár? 2018? Almennt séð gerði ég þetta fyrir nokkuð löngu síðan fyrir "Muscle" (MySQL) og breytti bara nokkrum línum í fyrirspurnunum þar, og það byrjaði að virka fyrir "Clickhouse", sem þakkar sérstaklega fyrir! Vegna þess að flokkarinn er mjög svipaður „vöðva“ og fyrirspurnirnar eru mjög svipaðar - mjög þægilegt, sérstaklega í fyrstu.
Jæja, það getur síað töflur, getur sýnt uppbyggingu og innihald töflunnar, gerir þér kleift að raða, sía eftir dálkum, sýnir fyrirspurnina sem leiddi til niðurstöðunnar, þær línur sem verða fyrir áhrifum (hversu margar í kjölfarið), þ.e. grunnatriði til að skoða gögn. Frekar hratt.
Það er líka ritstjóri. Ég reyndi heiðarlega að stela öllu ritstjóranum frá Tabix, en ég gat það ekki. En einhvern veginn virkar þetta. Í grundvallaratriðum, það er allt.
"Clickhouse" er hentugur fyrir bæli
Ég vil segja þér að Clickhouse, þrátt fyrir öll vandamálin sem lýst er, hentar mjög vel fyrir logs. Mikilvægast er að það leysir vandamál okkar - það er mjög hratt og gerir þér kleift að sía annála eftir dálkum. Í grundvallaratriðum hafa biðminni töflur ekki reynst vel, en venjulega veit enginn hvers vegna... Kannski veistu nú betur hvar þú munt eiga í vandræðum.
TCP? Almennt, í VK er venjan að nota UDP. Og þegar ég notaði TCP... Auðvitað sagði enginn við mig: „Yuri, hvað ertu að tala um! Þú getur það ekki, þú þarft UDP. Það kom í ljós að TCP er ekki svo ógnvekjandi. Málið er bara að ef þú ert með tugþúsundir virkra efnasambanda sem þú skrifar þarftu að undirbúa það aðeins betur; en það er hægt og frekar auðvelt.
Ég lofaði að setja „Kettlingahús“ og „Lighthouse“ á HighLoad Siberia ef allir gerast áskrifendur að opinberu „VK backend“ okkar... Og þú veist, það voru ekki allir áskrifendur... Auðvitað mun ég ekki krefjast þess að þú gerist áskrifandi að okkar almennings. Þið eruð enn of mörg, einhver gæti jafnvel móðgast, en samt endilega gerið áskrifandi (og hér verð ég að gera augu eins og köttur). Það er . Þakka þér kærlega fyrir! Github er okkar . Með Clickhouse verður hárið þitt mjúkt og silkimjúkt.
Fremstur: - Vinir, nú fyrir spurningar. Rétt eftir að við kynnum þakklætisvottorðið og skýrslu þína um VHS.
Yuri Nasretdinov (hér eftir nefndur YN): – Hvernig tókst þér að taka upp skýrsluna mína á VHS ef henni lauk bara?
Fremstur: - Þú getur líka ekki alveg ákveðið hvernig "Clickhouse" mun virka eða ekki! Vinir, 5 mínútur fyrir spurningar!
spurningar
Spurning úr sal (hér eftir nefnd Q): - Góðan daginn. Þakka þér kærlega fyrir skýrsluna. Ég er með tvær spurningar. Ég byrja á einhverju léttúðugu: hefur fjöldi bókstafa t í nafninu „Kettlingahús“ á skýringarmyndunum (3, 4, 7...) áhrif á ánægju kattanna?
YN: - Magn af hverju?
Z: – Bókstafur t. Það eru þrjú t, einhvers staðar í kringum þrjú t.
YN: — Lagaði ég það ekki? Jæja, auðvitað gerir það það! Þetta eru mismunandi vörur - ég var bara að blekkja þig allan þennan tíma. Allt í lagi, ég er að grínast - það skiptir ekki máli. Ah, hérna! Nei, það er það sama, ég gerði innsláttarvillu.
Z: - Þakka þér fyrir. Önnur spurningin er alvarleg. Eftir því sem ég skil, í Clickhouse, lifa biðminni töflur eingöngu í minni, eru ekki í biðminni á disk og eru þar af leiðandi ekki viðvarandi.
YN: - Já.
Z: – Og á sama tíma, biðminni þinn biðminni á disk, sem felur í sér einhverja tryggingu fyrir afhendingu þessara sömu annála. En þetta er engan veginn tryggt hjá Clickhouse. Útskýrðu hvernig ábyrgðin er framkvæmd, vegna hvers?.. Hér er þessi vélbúnaður nánar
YN: – Já, fræðilega séð eru engar mótsagnir hér, því þegar Clickhouse fellur geturðu í raun greint það á milljón mismunandi vegu. Ef Clickhouse hrynur (ef það endar vitlaust) geturðu, í grófum dráttum, spólað aðeins til baka af logginu þínu sem þú skrifaðir niður og byrjað á því augnabliki þegar allt var nákvæmlega í lagi. Segjum að þú spólar eina mínútu til baka, það er, það er talið að þú hafir skolað allt á mínútu.
Z: – Það er, „Kettlingahús“ heldur glugganum lengur og getur, ef það fellur, þekkt hann og spólað honum til baka?
YN: — En þetta er í orði. Í reynd gerum við þetta ekki og áreiðanleg afhending er frá núlli til óendanlega tíma. En að meðaltali einn. Við erum ánægð með að ef Clickhouse hrynur af einhverjum ástæðum eða netþjónarnir „endurræsa“ þá töpum við aðeins. Í öllum öðrum tilfellum mun ekkert gerast.
Z: - Halló. Frá upphafi virtist mér að þú myndir örugglega nota UDP alveg frá upphafi skýrslunnar. Þú ert með http, allt það... Og flest vandamálin sem þú lýstir, eins og ég skil það, stafaði af þessari tilteknu lausn...
YN: - Hvað notum við TCP?
Z: - Í meginatriðum já.
YN: - Nei.
Z: – Það var með fasthttp sem þú áttir í vandræðum, með tenginguna sem þú áttir í vandræðum. Ef þú hefðir bara notað UDP hefðirðu sparað þér tíma. Jæja, það yrðu vandamál með löng skilaboð eða eitthvað annað...
YN: - Með hverju?
Z: – Með löngum skilaboðum, þar sem það passar kannski ekki inn í MTU, eitthvað annað... Jæja, það geta verið vandamál þeirra. Spurningin er: hvers vegna ekki UDP?
YN: – Ég tel að höfundarnir sem þróuðu TCP/IP séu miklu gáfaðari en ég og viti betur en ég hvernig á að raðgreina pakka (svo að þeir fari), á sama tíma stilla sendingargluggann, ekki ofhlaða netið, gefa endurgjöf um hvað er ekki lesið, ekki talið á hinni hliðinni... Öll þessi vandamál væru að mínu mati til í UDP, bara ég þyrfti að skrifa enn meiri kóða en ég skrifaði þegar til að útfæra það sama sjálfur og líklegast illa. Mér finnst ekki einu sinni mjög gaman að skrifa á C, hvað þá þar...
Z: - Bara þægilegt! Sent í lagi og ekki bíða eftir neinu - það er algjörlega ósamstillt. Tilkynning kom til baka um að allt væri í lagi - það þýðir að það kom; Ef það kemur ekki þýðir það að það er slæmt.
YN: – Ég þarf bæði – ég þarf að geta sent bæði með tryggingu fyrir afhendingu og án tryggingar fyrir afhendingu. Þetta eru tvær ólíkar aðstæður. Ég þarf ekki að týna einhverjum annálum eða ekki týna þeim innan skynsamlegrar skynsemi.
Z: — Ég mun ekki eyða tíma. Þetta þarf að ræða betur. Þakka þér fyrir.
Fremstur: – Hver hefur spurningar – hendur til himins!
Z: - Halló, ég heiti Sasha. Einhvers staðar í miðri skýrslunni kom upp sú tilfinning að auk TCP væri hægt að nota tilbúna lausn - einhvers konar Kafka.
YN: – Jæja... ég sagði þér að ég vil ekki nota millimiðlara, vegna þess að... í Kafka kemur í ljós að við höfum tíu þúsund gestgjafa; í raun höfum við fleiri - tugþúsundir gestgjafa. Það getur líka verið sársaukafullt að gera við Kafka án nokkurra umboðsmanna. Að auki, síðast en ekki síst, það gefur enn „leynd“, það gefur auka gestgjafa sem þú þarft að hafa. En ég vil ekki hafa þá - ég vil...
Z: "En á endanum varð þetta samt þannig."
YN: – Nei, það eru engir gestgjafar! Þetta virkar allt á Clickhouse gestgjöfum.
Z: - Jæja, og "Kettlingahús", sem er öfugt - hvar býr hann?
YN: – Á Clickhouse gestgjafanum skrifar það ekki neitt á diskinn.
Z: - Gerum ráð fyrir.
Fremstur: — Ertu sáttur? Getum við gefið þér laun?
Z: - Já þú getur. Reyndar eru margar hækjur til að fá það sama, og núna - fyrra svarið um TCP stangast á, að mínu mati, þessu ástandi. Mér líður bara eins og allt hefði getað verið gert á hnjánum á mér á mun styttri tíma.
YN: – Og líka hvers vegna ég vildi ekki nota Kafka, vegna þess að það voru töluvert margar kvartanir í Clickhouse Telegram spjallinu um að til dæmis skilaboð frá Kafka hafi glatast. Ekki frá Kafka sjálfum, heldur í samþættingu Kafka og Clickhaus; eða eitthvað tengdist ekki þarna. Í grófum dráttum þyrfti þá að skrifa viðskiptavin fyrir Kafka. Ég held að það gæti ekki verið til einfaldari eða áreiðanlegri lausn.
Z: – Segðu mér, hvers vegna prófaðirðu engar biðraðir eða einhvers konar almennan strætó? Þar sem þú segir að með ósamstillingu gætirðu sent loggana sjálfa í gegnum biðröðina og fengið svarið ósamstillt í gegnum biðröðina?
YN: – Vinsamlegast komdu með tillögur um hvaða biðraðir gætu verið notaðar?
Z: - Allir, jafnvel án þess að tryggja að þeir séu í lagi. Einhvers konar Redis, RMQ...
YN: – Ég hef það á tilfinningunni að Redis muni líklegast ekki geta dregið slíkt magn innsetningar jafnvel á einn gestgjafa (í skilningi nokkurra netþjóna) sem dregur út Clickhouse. Ég get ekki stutt þetta með neinum sönnunargögnum (ég hef ekki benchmarkað það), en mér sýnist að Redis sé ekki besta lausnin hér. Í grundvallaratriðum er hægt að líta á þetta kerfi sem spuna skilaboðaröð, en hún er aðeins sniðin fyrir „Clickhouse“
Fremstur: — Júrí, þakka þér kærlega fyrir. Ég legg til að hér verði lokið spurningum og svörum og sagt hverjum þeirra sem spurðu spurningarinnar við munum gefa bókina.
YN: – Mig langar að gefa fyrsta manneskju sem spurði spurningu bók.
Fremstur: - Dásamlegt! Frábært! Stórkostlegt! Kærar þakkir!
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com