HighLoad++ Moskë 2018, Salla e Kongresit. 9 Nëntor, ora 15:00
Abstrakte dhe prezantim:
Yuri Nasretdinov (VKontakte): raporti do të flasë për përvojën e zbatimit të ClickHouse në kompaninë tonë - pse na duhen, sa të dhëna ruajmë, si i shkruajmë, etj.
Materialet shtesë:
Yuri Nasretdinov: - Pershendetje te gjitheve! Unë quhem Yuri Nasretdinov, siç jam prezantuar tashmë. Unë punoj në VKontakte. Unë do të flas se si ne futim të dhëna në ClickHouse nga flota jonë e serverëve (dhjetëra mijëra).
Çfarë janë shkrimet dhe pse i mbledhim ato?
Çfarë do t'ju tregojmë: çfarë bëmë, pse na duhej "ClickHouse", përkatësisht, pse e zgjodhëm atë, çfarë lloj performance mund të merrni përafërsisht pa konfiguruar asgjë posaçërisht. Unë do t'ju tregoj më tej për tabelat e tamponit, për problemet që patëm me to dhe për zgjidhjet tona që kemi zhvilluar nga burimi i hapur - KittenHouse dhe Lighthouse.
Pse na duhej të bënim diçka fare (gjithçka është gjithmonë mirë në VKontakte, apo jo?). Ne donim të mblidhnim regjistrat e korrigjimit (dhe kishte qindra terabajt të dhëna atje), ndoshta disi do të ishte më i përshtatshëm për të llogaritur statistikat; dhe ne kemi një flotë prej dhjetëra mijëra serverësh nga të cilët duhet të bëhet e gjithë kjo.
Pse vendosëm? Ndoshta kishim zgjidhje për ruajtjen e shkrimeve. Këtu - ekziston një "Backend VK" i tillë publik. Unë rekomandoj shumë të abonoheni në të.
Çfarë janë shkrimet? Ky është një motor që kthen vargje boshe. Motorët në VK janë ato që të tjerët i quajnë mikroshërbime. Dhe këtu është një ngjitëse e qeshur (shumë pëlqime). Si keshtu? Epo, dëgjoni më tej!
Çfarë mund të përdoret për të ruajtur shkrimet? Është e pamundur të mos përmendet Hadupi. Pastaj, për shembull, Rsyslog (ruajtja e këtyre regjistrave në skedarë). LSD. Kush e di se çfarë është LSD? Jo, jo kjo LSD. Ruani skedarët, respektivisht, gjithashtu. Epo, ClickHouse është një opsion i çuditshëm.
Clickhouse dhe konkurrentët: kërkesat dhe mundësitë
Çfarë duam ne? Ne duam të sigurohemi që nuk duhet të shqetësohemi shumë për funksionimin, në mënyrë që të funksionojë jashtë kutisë, mundësisht me konfigurim minimal. Ne duam të shkruajmë shumë dhe të shkruajmë shpejt. Dhe ne duam ta mbajmë atë për të gjitha llojet e muajve, viteve, domethënë për një kohë të gjatë. Ne mund të duam të kuptojmë një problem me të cilin ata erdhën tek ne dhe thanë, "Diçka nuk po funksionon këtu", dhe kjo ishte 3 muaj më parë), dhe ne duam të jemi në gjendje të shohim se çfarë ndodhi 3 muaj më parë " Kompresimi i të dhënave - është e qartë pse do të ishte një plus - sepse zvogëlon sasinë e hapësirës që zë.
Dhe ne kemi një kërkesë kaq interesante: ne ndonjëherë shkruajmë daljen e disa komandave (për shembull, regjistrat), mund të jetë më shumë se 4 kilobajt mjaft lehtë. Dhe nëse kjo gjë funksionon mbi UDP, atëherë nuk ka nevojë të shpenzojë ... nuk do të ketë asnjë "të lartë" për lidhjen, dhe për një numër të madh serverësh kjo do të jetë një plus.
Le të shohim se çfarë na ofron burimi i hapur. Së pari, ne kemi Logs Engine - ky është motori ynë; Në parim, ai mund të bëjë gjithçka, madje mund të shkruajë rreshta të gjatë. Epo, nuk i ngjesh në mënyrë transparente të dhënat - ne mund të kompresojmë vetë kolona të mëdha nëse duam ... ne, natyrisht, nuk duam (nëse është e mundur). Problemi i vetëm është se ai mund të japë vetëm atë që i përshtatet në kujtesën e tij; Për të lexuar pjesën tjetër, duhet të merrni bilogun e këtij motori dhe, në përputhje me rrethanat, kërkon mjaft kohë.
Çfarë opsionesh të tjera ka? Për shembull, "Hadup". Lehtësia e funksionimit... Kush mendon se Hadup është i lehtë për t'u ngritur? Sigurisht, nuk ka probleme me regjistrimin. Kur lexoni, ndonjëherë lindin pyetje. Në parim, unë do të thoja ndoshta jo, veçanërisht për shkrimet. Ruajtja afatgjatë - sigurisht, po, kompresimi i të dhënave - po, vargjet e gjata - është e qartë se mund të regjistroni. Por regjistrimi nga një numër i madh serverësh... Ju ende duhet të bëni diçka vetë!
Rsyslog. Në fakt, ne e përdorëm atë si një opsion rezervë që të mund ta lexonim pa hedhur bilogun, por ai nuk mund të shkruajë rreshta të gjatë; në parim, nuk mund të shkruajë më shumë se 4 kilobajt. Ju duhet të bëni vetë kompresimin e të dhënave në të njëjtën mënyrë. Leximi do të vijë nga skedarët.
Pastaj është zhvillimi "badushka" i LSD. Në thelb i njëjtë me "Rsyslog": ai mbështet vargje të gjata, por nuk mund të funksionojë përmes UDP dhe, në fakt, për shkak të kësaj, për fat të keq, shumë gjëra duhet të rishkruhen atje. LSD duhet të ridizajnohet që të jetë në gjendje të regjistrojë nga dhjetëra mijëra serverë.
Dhe këtu! Një opsion qesharak është ElasticSearch. Si të thuash? Me lexim ia del mire, pra lexon shpejt, por jo shume mire me shkrimin. Së pari, nëse i ngjesh të dhënat, është shumë i dobët. Me shumë mundësi, një kërkim i plotë kërkon struktura të dhënash më të mëdha se vëllimi origjinal. Është e vështirë të operohet dhe shpesh lindin probleme me të. Dhe, përsëri, regjistrimi në Elastic - ne duhet të bëjmë gjithçka vetë.
Këtu ClickHouse është një opsion ideal, sigurisht. E vetmja gjë është se regjistrimi nga dhjetëra mijëra serverë është një problem. Por të paktën ka një problem, ne mund të përpiqemi ta zgjidhim atë disi. Dhe pjesa tjetër e raportit ka të bëjë me këtë problem. Çfarë lloj performance mund të prisni nga ClickHouse?
Si do ta fusim? MergeTree
Kush prej jush nuk ka dëgjuar ose di për "ClickHouse"? Duhet t'ju them, apo jo? Shumë shpejt. Futja atje - 1-2 gigabit në sekondë, shpërthime deri në 10 gigabit në sekondë mund t'i rezistojë në të vërtetë këtij konfigurimi - ka dy Xeon me 6 bërthama (d.m.th., as më të fuqishmit), 256 gigabajt RAM, 20 terabajt. në RAID (askush nuk është konfiguruar, cilësimet e paracaktuara). Alexey Milovidov, zhvilluesi i ClickHouse, ndoshta është ulur atje duke qarë sepse ne nuk kemi konfiguruar asgjë (gjithçka funksionoi kështu për ne). Prandaj, një shpejtësi skanimi prej, të themi, rreth 6 miliardë linja në sekondë mund të merret nëse të dhënat janë të ngjeshura mirë. Nëse ju pëlqen % në një varg teksti - 100 milionë rreshta në sekondë, domethënë, duket mjaft i shpejtë.
Si do ta fusim? Epo, ju e dini që VK përdor PHP. Ne do të fusim nga çdo punonjës PHP nëpërmjet HTTP në "ClickHouse", në tabelën MergeTree për çdo rekord. Kush e sheh problem këtë skemë? Për disa arsye, jo të gjithë ngritën duart. Më lejoni t'ju them.
Së pari, ka shumë serverë - në përputhje me rrethanat, do të ketë shumë lidhje (të këqija). Atëherë është më mirë të futni të dhëna në MergeTree jo më shpesh se një herë në sekondë. Dhe kush e di pse? Ne rregull ne rregull. Unë do t'ju tregoj pak më shumë për këtë. Një pyetje tjetër interesante është se ne nuk po bëjmë analitikë, nuk kemi nevojë të pasurojmë të dhënat, nuk kemi nevojë për serverë të ndërmjetëm, duam të fusim direkt në "ClickHouse" (mundësisht - sa më drejtpërdrejt, aq më mirë).
Prandaj, si bëhet futja në MergeTree? Pse është më mirë të futet në të jo më shpesh se një herë në sekondë ose më rrallë? Fakti është se "ClickHouse" është një bazë të dhënash kolone dhe i rendit të dhënat në rendin rritës të çelësit primar, dhe kur bëni një futje, krijohen një numër skedarësh të paktën i barabartë me numrin e kolonave në të cilat renditen të dhënat. në rendin rritës të çelësit primar (krijohet një drejtori e veçantë, një grup skedarësh në disk për çdo insert). Pastaj vjen futja tjetër, dhe në sfond ato kombinohen në "ndarje" më të mëdha. Meqenëse të dhënat janë të renditura, është e mundur të "bashkohen" dy skedarë të renditur pa konsumuar shumë memorie.
Por, siç mund ta merrni me mend, nëse shkruani 10 skedarë për çdo insert, atëherë ClickHouse (ose serveri juaj) do të përfundojë shpejt, kështu që rekomandohet të futni në grupe të mëdha. Prandaj, ne kurrë nuk e hodhëm në prodhim skemën e parë. Ne lançuam menjëherë një të tillë, i cili këtu nr. 2 ka:
Këtu imagjinoni që ka rreth një mijë serverë në të cilët kemi nisur, ka vetëm PHP. Dhe në çdo server është agjenti ynë lokal, të cilin e quajtëm "Kittenhouse", i cili mban një lidhje me "ClickHouse" dhe fut të dhëna çdo disa sekonda. Fut të dhënat jo në MergeTree, por në një tabelë buffer, e cila shërben pikërisht për të shmangur futjen e drejtpërdrejtë në MergeTree menjëherë.
Puna me tabela buffer
Cfare eshte? Tabelat buffer janë një pjesë e memories që është e copëtuar (d.m.th., ajo mund të futet në të shpesh). Ato përbëhen nga disa pjesë, dhe secila prej pjesëve funksionon si një tampon i pavarur, dhe ato shpërlahen në mënyrë të pavarur (nëse keni shumë pjesë në tampon, atëherë do të ketë shumë futje në sekondë). Është e mundur të lexohet nga këto tabela - atëherë ju lexoni bashkimin e përmbajtjes së bufferit dhe tabelës prind, por në këtë moment shkrimi është i bllokuar, kështu që është më mirë të mos lexoni nga atje. Dhe tabelat buffer tregojnë QPS shumë të mirë, domethënë deri në 3 mijë QPS nuk do të keni fare problem gjatë futjes. Është e qartë se nëse serveri humbet energjinë, atëherë të dhënat mund të humbasin, sepse ato u ruajtën vetëm në memorie.
Në të njëjtën kohë, skema me një tampon komplikon ALTER, sepse fillimisht duhet të hiqni tabelën e vjetër të buferit me skemën e vjetër (të dhënat nuk do të zhduken askund, sepse do të fshihen përpara se tabela të fshihet). Pastaj ju "ndryshoni" tabelën që ju nevojitet dhe krijoni përsëri tabelën buffer. Prandaj, ndërsa nuk ka tabelë buffer, të dhënat tuaja nuk do të rrjedhin askund, por mund t'i keni në disk të paktën në nivel lokal.
Çfarë është Kittenhouse dhe si funksionon?
Çfarë është KittenHouse? Ky është një përfaqësues. Gjeni se çfarë gjuhe? Kam mbledhur temat më të zhurmshme në raportin tim - "Clickhouse", Shko, mbase do të kujtoj diçka tjetër. Po, kjo është shkruar në Go, sepse nuk di vërtet të shkruaj në C, nuk dua.
Prandaj, ai mban një lidhje me çdo server dhe mund të shkruajë në memorie. Për shembull, nëse shkruajmë regjistrat e gabimeve në Clickhouse, atëherë nëse Clickhouse nuk ka kohë për të futur të dhëna (në fund të fundit, nëse është shkruar shumë), atëherë ne nuk e fryjmë kujtesën - thjesht hedhim pjesën tjetër. Sepse nëse shkruajmë disa gigabit për sekondë gabime, atëherë ndoshta mund të hedhim disa jashtë. Shtëpia e koteleve mund ta bëjë këtë. Plus, ai mund të kryejë dorëzim të besueshëm, domethënë të shkruajë në disk në makinën lokale dhe një herë në çdo herë (atje, një herë në dy sekonda) përpiqet të japë të dhëna nga ky skedar. Dhe në fillim përdorëm formatin e rregullt Values - jo ndonjë format binar, një format teksti (si në SQL të rregullt).
Por më pas kjo ndodhi. Ne përdorëm dërgesë të besueshme, shkruajmë regjistrat, më pas vendosëm (ishte një grup testimi i kushtëzuar)... Ai u nxor për disa orë dhe u rikthye, dhe një futje filloi nga një mijë serverë - doli që Clickhouse kishte ende një "Fije në lidhje" - në përputhje me rrethanat, në një mijë lidhje, një futje aktive çon në një mesatare të ngarkesës në server prej rreth një mijë e gjysmë. Çuditërisht, serveri pranoi kërkesat, por të dhënat u futën ende pas disa kohësh; por ishte shumë e vështirë për serverin ta shërbente atë ...
Shtoni nginx
Një zgjidhje e tillë për modelin Thread per lidhje është nginx. Ne instaluam nginx përballë Clickhouse, në të njëjtën kohë vendosëm balancimin për dy kopje (shpejtësia jonë e futjes u rrit me 2 herë, megjithëse nuk është fakt që duhet të jetë kështu) dhe kufizuam numrin e lidhjeve me Clickhouse, në në rrjedhën e sipërme dhe, në përputhje me rrethanat, më shumë se në 50 lidhje, duket se nuk ka kuptim të futet.
Më pas kuptuam se kjo skemë përgjithësisht ka disavantazhe, sepse këtu kemi vetëm një nginx. Prandaj, nëse ky nginx rrëzohet, pavarësisht nga prania e kopjeve, ne humbim të dhënat ose, të paktën, nuk shkruajmë askund. Kjo është arsyeja pse ne bëmë balancimin tonë të ngarkesës. Ne gjithashtu kuptuam se "Clickhouse" është ende i përshtatshëm për shkrimet, dhe "demoni" gjithashtu filloi të shkruajë shkrimet e tij në "Clickhouse" - shumë i përshtatshëm, për të qenë i sinqertë. Ne ende e përdorim atë për "demonët" e tjerë.
Pastaj zbuluam këtë problem interesant: nëse përdorni një metodë jo standarde të futjes në modalitetin SQL, ajo detyron një analizues të plotë SQL të bazuar në AST, i cili është mjaft i ngadalshëm. Prandaj, ne kemi shtuar cilësime për të siguruar që kjo të mos ndodhë kurrë. Ne bëmë balancimin e ngarkesës, kontrollet shëndetësore, në mënyrë që nëse dikush vdes, të lëmë përsëri të dhënat. Tani kemi mjaft tabela që na duhen për të pasur grupime të ndryshme Clickhouse. Dhe ne gjithashtu filluam të mendojmë për përdorime të tjera - për shembull, ne donim të shkruanim regjistra nga modulet nginx, por ata nuk dinë se si të komunikojnë duke përdorur RPC-në tonë. Epo, unë do të doja t'i mësoja se si të dërgojnë të paktën disi - për shembull, të marrin ngjarje në localhost përmes UDP dhe pastaj t'i përcjellin ato në Clickhouse.
Një hap larg zgjidhjes
Skema përfundimtare filloi të dukej kështu (versioni i katërt i kësaj skeme): në secilin server përballë Clickhouse ka nginx (në të njëjtin server) dhe thjesht proxon kërkesat për localhost me një kufi në numrin e lidhjeve prej 50 copa. Dhe kjo skemë tashmë funksiononte mjaft mirë, gjithçka ishte mjaft mirë me të.
Jetuam kështu për rreth një muaj. Të gjithë u gëzuan, shtuan tabela, shtuan, shtuan... Në përgjithësi, rezultoi se mënyra se si shtonim tabelat buffer nuk ishte shumë optimale (le ta themi kështu). Ne bëmë 16 pjesë në secilën tabelë dhe një interval flash prej disa sekondash; ne kishim 20 tabela dhe secila tabelë merrte 8 futje në sekondë - dhe në këtë pikë filloi "Clickhouse"... regjistrimet filluan të ngadalësohen. Ata as nuk kaluan... Nginx si parazgjedhje kishte një gjë kaq interesante saqë nëse lidhjet përfundonin në rrjedhën e sipërme, atëherë thjesht kthente "502" në të gjitha kërkesat e reja.
Dhe këtu kemi (sapo shikova regjistrat në vetë Clickhouse) rreth gjysmë për qind e kërkesave dështuan. Prandaj, përdorimi i diskut ishte i lartë, kishte shumë bashkime. Epo, çfarë bëra? Natyrisht, nuk u mërzita të kuptoja pse pikërisht lidhja dhe rrjedha e sipërme përfunduan.
Zëvendësimi i nginx me një përfaqësues të kundërt
Vendosa që ne duhet ta menaxhojmë vetë këtë, nuk kemi nevojë t'ia lëmë nginx - nginx nuk e di se çfarë tabelash ka në Clickhouse, dhe e zëvendësova nginx me një përfaqësues të kundërt, të cilin e shkrova edhe vetë.
Çfarë po bën ai? Ai funksionon bazuar në bibliotekën fasthttp "goshnoy", domethënë shpejt, pothuajse aq shpejt sa nginx. Na vjen keq, Igor, nëse je i pranishëm këtu (shënim: Igor Sysoev është një programues rus që krijoi ueb serverin nginx). Mund të kuptojë se çfarë lloj pyetjesh janë këto - INSERT ose SELECT - në përputhje me rrethanat, ai mban grupe të ndryshme lidhjesh për lloje të ndryshme pyetjesh.
Prandaj, edhe nëse nuk kemi kohë për të plotësuar kërkesat e futjes, "përzgjedhja" do të kalojë dhe anasjelltas. Dhe i grupon të dhënat në tabela buffer - me një bufer të vogël: nëse do të kishte ndonjë gabim, gabim sintaksor, e kështu me radhë - në mënyrë që ato të mos ndikojnë shumë në pjesën tjetër të të dhënave, sepse kur ne thjesht i futim në tabela buferike, ne kishte "bachi" të vogël dhe të gjitha gabimet sintaksore prekën vetëm këtë pjesë të vogël; dhe këtu ata tashmë do të ndikojnë në një tampon të madh. I vogël është 1 megabajt, domethënë jo aq i vogël.
Futja e një sinkronizimi dhe në thelb zëvendësimi i nginx, në thelb bën të njëjtën gjë që bëri nginx më parë - nuk keni nevojë të ndryshoni "Kittenhouse" lokale për këtë. Dhe meqenëse përdor fasthttp, është shumë i shpejtë - mund të bëni më shumë se 100 mijë kërkesa në sekondë për futje të vetme përmes një përfaqësuesi të kundërt. Teorikisht, ju mund të futni një rresht në një kohë në përfaqësuesin e kundërt të shtëpisë së koteleve, por sigurisht që ne nuk e bëjmë këtë.
Skema filloi të dukej kështu: "Kittenhouse", përfaqësuesi i kundërt grupon shumë kërkesa në tabela dhe, nga ana tjetër, tabelat buffer i futin ato në ato kryesore.
Killer është një zgjidhje e përkohshme, Kotele është e përhershme
Ky është një problem interesant... A ka përdorur ndonjë nga ju fasthttp? Kush përdori fasthttp me kërkesat POST? Ndoshta, kjo me të vërtetë nuk duhet të ishte bërë, sepse ajo ruan trupin e kërkesës si parazgjedhje, dhe madhësia jonë e tamponit u vendos në 16 megabajt. Futja pushoi së funksionuari në një moment, dhe copa 16 megabajt filluan të mbërrinin nga të gjithë dhjetëra mijëra serverët, dhe të gjithë u ruajtën në memorie përpara se të dërgoheshin në Clickhouse. Prandaj, kujtesa mbaroi, Vrasësi jashtë kujtese erdhi dhe vrau përfaqësuesin e kundërt (ose "Clickhouse", i cili teorikisht mund të "hante" më shumë se përfaqësuesi i kundërt). Cikli u përsërit. Një problem jo shumë i këndshëm. Edhe pse ne e gjetëm këtë vetëm pas disa muajsh funksionimi.
Cfare kam bere? Përsëri, nuk më pëlqen shumë të kuptoj se çfarë ka ndodhur saktësisht. Mendoj se është shumë e qartë se nuk duhet të futesh në memorie. Nuk munda ta patch-in shpejt, edhe pse u përpoqa. Por gjeta një mënyrë për ta bërë atë në mënyrë që të mos kishte nevojë të rregulloja asgjë dhe dola me metodën time në HTTP - e quajta KOTELE. Epo, është logjike - "VK", "Kitten" ... Çfarë tjetër? ..
Nëse një kërkesë vjen në server me metodën Kitten, atëherë serveri duhet të përgjigjet "meow" - logjikisht. Nëse ai i përgjigjet kësaj, atëherë konsiderohet se ai e kupton këtë protokoll, dhe atëherë unë përgjoj lidhjen (fasthttp ka një metodë të tillë), dhe lidhja kalon në modalitetin "raw". Pse më duhet? Unë dua të kontrolloj se si ndodh leximi nga lidhjet TCP. TCP ka një veti të mrekullueshme: nëse askush nuk po lexon nga ana tjetër, atëherë shkrimi fillon të presë, dhe kujtesa nuk shpenzohet veçanërisht për këtë.
Dhe kështu lexova nga rreth 50 klientë në të njëjtën kohë (nga pesëdhjetë sepse pesëdhjetë duhet të mjaftojnë patjetër, edhe nëse norma vjen nga një DC tjetër)... Konsumi është ulur me këtë qasje të paktën 20 herë, por unë, të them të drejtën , Unë nuk mund të mata saktësisht se çfarë ore, sepse tashmë është e pakuptimtë (ka arritur tashmë nivelin e gabimit). Protokolli është binar, domethënë përmban emrin e tabelës dhe të dhënat; nuk ka tituj http, kështu që nuk kam përdorur një prizë në internet (nuk kam nevojë të komunikoj me shfletues - kam bërë një protokoll që i përshtatet nevojave tona). Dhe gjithçka u bë mirë me të.
Tabela e tamponit është e trishtuar
Kohët e fundit kemi hasur në një tjetër veçori interesante të tabelave buffer. Dhe ky problem është tashmë shumë më i dhimbshëm se të tjerët. Le të imagjinojmë këtë situatë: ju tashmë jeni duke përdorur në mënyrë aktive Clickhouse, keni dhjetëra serverë Clickhouse dhe keni disa kërkesa që kërkojnë një kohë shumë të gjatë për t'u lexuar (le të themi, më shumë se 60 sekonda); dhe ju vini dhe bëni Alterin në këtë moment... Ndërkohë, "zgjedhjet" që kanë filluar para "Alter" nuk do të përfshihen në këtë tabelë, "Alter" nuk do të fillojë - ndoshta disa veçori se si funksionon "Clickhouse" në ky vend. Ndoshta kjo mund të rregullohet? Apo është e pamundur?
Në përgjithësi, është e qartë se në realitet ky nuk është një problem aq i madh, por me tabelat buffer bëhet më i dhimbshëm. Sepse, nëse, le të themi, koha juaj "Alter" skadon (dhe mund të përfundojë në një host tjetër - jo në tuajin, por në një kopje, për shembull), atëherë... Ju fshive tabelën e tamponit, "Alter"-in tuaj ( ose ndonjë host tjetër) ka skaduar. atëherë ka ndodhur një gabim "Alter") - ju duhet të siguroheni që të dhënat vazhdojnë të shkruhen: ju krijoni tabelat e buferit mbrapa (sipas të njëjtës skemë si tabela mëmë), më pas "Alter" kalon, përfundon në fund të fundit dhe buferi i tabelës fillon të ndryshojë në skemë nga prindi. Në varësi të asaj që ishte "Alter", futja mund të mos shkojë më në këtë tabelë tampon - kjo është shumë e trishtueshme.
Ekziston edhe një shenjë e tillë (ndoshta dikush e vuri re) - quhet query_thread_log në versionet e reja të Clickhouse. Si parazgjedhje, në disa versione kishte një. Këtu kemi grumbulluar 840 milionë regjistrime në disa muaj (100 gigabajt). Kjo për faktin se "insertet" janë shkruar atje (ndoshta tani, nga rruga, ato nuk janë shkruar). Siç ju thashë, "insertet" tona janë të vogla - ne kishim shumë "inserte" në tabelat e tamponit. Është e qartë se kjo është e çaktivizuar - Unë thjesht po ju them atë që pashë në serverin tonë. Pse? Ky është një argument tjetër kundër përdorimit të tabelave buffer! Spotty është shumë i trishtuar.
Kush e dinte që emri i këtij djali ishte Spotty? Punonjësit e VK-së ngritën duart lart. NE RREGULL.
Rreth planeve për "KitttenHouse"
Planet zakonisht nuk ndahen, apo jo? Papritur nuk do t'i përmbushni ato dhe nuk do të dukeni shumë mirë në sytë e të tjerëve. Por unë do të rrezikoj! Ne duam të bëjmë sa më poshtë: tabelat e tamponit, më duket, janë ende një patericë dhe ne duhet ta ruajmë vetë futjen. Por ne ende nuk duam ta ruajmë atë në disk, kështu që do ta ruajmë futjen në memorie.
Prandaj, kur të bëhet një "insert", ai nuk do të jetë më sinkron - ai tashmë do të funksionojë si një tabelë buffer, do të futet në tabelën mëmë (mirë, një ditë më vonë) dhe do të raportojë përmes një kanali të veçantë se cilat inserte kanë kaluar dhe cilat nuk kam.
Pse nuk mund të largohem nga inserti sinkron? Është shumë më i përshtatshëm. Fakti është se nëse futni nga 10 mijë host, atëherë gjithçka është në rregull - do të merrni pak nga secili host, futni atje një herë në sekondë, gjithçka është në rregull. Por unë do të doja që kjo skemë të funksiononte, për shembull, nga dy makina, në mënyrë që të shkarkoni me shpejtësi të lartë - mbase të mos merrni maksimumin nga Clickhouse, por shkruani të paktën 100 megabajt në sekondë nga një makinë përmes një përfaqësuesi të kundërt - kjo skema duhet të shkallëzohet në sasi të mëdha dhe të vogla, kështu që nuk mund të presim një sekondë për çdo futje, kështu që duhet të jetë asinkron. Dhe në të njëjtën mënyrë, konfirmimet asinkrone duhet të vijnë pasi të ketë përfunduar futja. Do ta dimë nëse ka kaluar apo jo.
Gjëja më e rëndësishme është që në këtë skemë të dimë me siguri nëse ka ndodhur apo jo futja. Imagjinoni këtë situatë: ju keni një tabelë buffer, keni shkruar diçka në të dhe më pas, le të themi, tabela hyri në modalitetin vetëm për lexim dhe u përpoq të fshijë buferin. Ku do të shkojnë të dhënat? Ata do të qëndrojnë në tampon. Por ne nuk mund të jemi të sigurt për këtë - po sikur të ketë ndonjë gabim tjetër, për shkak të të cilit të dhënat nuk do të mbeten në tampon... (Adresohet Alexey Milovidov, Yandex, zhvilluesi i ClickHouse) Apo do të mbetet? Gjithmonë? Alexey na bind se gjithçka do të jetë mirë. Nuk kemi pse të mos e besojmë. Por e njëjta gjë: nëse nuk përdorim tabela buffer, atëherë nuk do të ketë asnjë problem me to. Krijimi i dyfishtë i tabelave është gjithashtu i papërshtatshëm, megjithëse në parim nuk ka probleme të mëdha. Ky është plani.
Le të flasim për leximin
Tani le të flasim për leximin. Ne gjithashtu kemi shkruar mjetin tonë këtu. Do të duket, mirë, pse të shkruani instrumentin tuaj këtu?.. Dhe kush e përdori Tabix-in? Disi pak njerëz ngritën duart... Dhe kush është i kënaqur me performancën e Tabix? Epo, ne nuk jemi të kënaqur me të dhe nuk është shumë i përshtatshëm për të parë të dhënat. Është mirë për analitikën, por thjesht për shikimin nuk është qartësisht i optimizuar. Kështu që unë shkrova ndërfaqen time, ndërfaqen time.
Është shumë e thjeshtë - mund të lexojë vetëm të dhëna. Ai nuk di të tregojë grafikë, nuk di të bëjë asgjë. Por mund të tregojë atë që na nevojitet: për shembull, sa rreshta ka në tabelë, sa hapësirë zë (pa e ndarë në kolona), domethënë, një ndërfaqe shumë bazë është ajo që na nevojitet.
Dhe duket shumë e ngjashme me Sequel Pro, por e bërë vetëm në Bootstrap të Twitter, dhe versionin e dytë. Ju pyesni: "Yuri, pse në versionin e dytë?" Çfarë viti? 2018? Në përgjithësi, unë e bëra këtë shumë kohë më parë për "Muscle" (MySQL) dhe sapo ndryshova disa rreshta në pyetjet atje, dhe filloi të funksionojë për "Clickhouse", për të cilën faleminderit të veçantë! Sepse analizuesi është shumë i ngjashëm me atë "muskulor", dhe pyetjet janë shumë të ngjashme - shumë të përshtatshme, veçanërisht në fillim.
Epo, mund të filtrojë tabela, mund të tregojë strukturën dhe përmbajtjen e tabelës, ju lejon të renditni, filtroni sipas kolonave, tregon pyetjen që rezultoi në rezultat, rreshtat e prekur (sa si rezultat), domethënë gjërat themelore për shikimin e të dhënave. Shumë shpejt.
Ekziston edhe një redaktor. Sinqerisht u përpoqa të vidha të gjithë redaktorin nga Tabix, por nuk munda. Por disi funksionon. Në parim, kjo është e gjitha.
"Clickhouse" është i përshtatshëm për strofkat
Dua t'ju them se Clickhouse, pavarësisht nga të gjitha problemet e përshkruara, është shumë i përshtatshëm për shkrimet. Më e rëndësishmja, zgjidh problemin tonë - është shumë i shpejtë dhe ju lejon të filtroni regjistrat sipas kolonave. Në parim, tabelat buffer nuk kanë performuar mirë, por zakonisht askush nuk e di pse... Ndoshta tani ju e dini më mirë se ku do të keni probleme.
TCP? Në përgjithësi, në VK është zakon të përdoret UDP. Dhe kur përdora TCP... Sigurisht, askush nuk më tha: “Juri, çfarë po flet! Ju nuk mundeni, keni nevojë për UDP." Doli që TCP nuk është aq e frikshme. E vetmja gjë është, nëse keni dhjetëra mijëra përbërës aktivë që shkruani, duhet ta përgatisni me pak më shumë kujdes; por është e mundur, dhe mjaft e lehtë.
Unë premtova të postoja "Kittenhouse" dhe "Lighthouse" në HighLoad Siberia nëse të gjithë do të abonoheshin në "VK backend" tonë publik... Dhe ju e dini, jo të gjithë u pajtuan... Sigurisht, nuk do të kërkoj që të abonoheni në tonë publike. Jeni ende shumë, dikush edhe mund të ofendohet, por megjithatë, ju lutemi abonohuni (dhe këtu më duhet t'i bëj sytë si ato të maces). Kjo është . Faleminderit shumë! Github është i yni . Me Clickhouse flokët tuaj do të jenë të butë dhe të mëndafshtë.
Moderator: - Miq, tani për pyetje. Menjëherë pasi kemi paraqitur certifikatën e vlerësimit dhe raportin tuaj për VHS.
Yuri Nasretdinov (në tekstin e mëtejmë YN): – Si keni mundur të regjistroni raportin tim në VHS nëse sapo ka përfunduar?
Moderator: – Edhe ju nuk mund të përcaktoni plotësisht se si do të funksionojë apo jo “Clickhouse”! Miq, 5 minuta për pyetje!
Pyetjet tuaja
Pyetje nga audienca (më tej referuar si Q): - Mirembrema. Faleminderit shumë për raportin. Kam dy pyetje. Do të filloj me diçka joserioze: a ndikon numri i shkronjave t në emrin "Kittenhouse" në diagramet (3, 4, 7...) në kënaqësinë e maceve?
YN: - Sasia e çfarë?
З: – Shkronja t. Ka tre t, diku rreth tre t.
YN: - Nuk e rregullova? Epo, sigurisht që po! Këto janë produkte të ndryshme - Unë thjesht po ju mashtroja gjatë gjithë kësaj kohe. Mirë, po bëj shaka - nuk ka rëndësi. Ah, pikërisht këtu! Jo, është e njëjta gjë, kam bërë një gabim shtypi.
З: - Faleminderit. Pyetja e dytë është serioze. Me sa kuptoj unë, në Clickhouse, tabelat e tamponit jetojnë ekskluzivisht në memorie, nuk futen në disk dhe, në përputhje me rrethanat, nuk janë të qëndrueshme.
YN: - Po.
З: – Dhe në të njëjtën kohë, klienti juaj kalon në disk, gjë që nënkupton njëfarë garancie për dërgimin e të njëjtave regjistra. Por kjo nuk është aspak e garantuar në Clickhouse. Shpjegoni si kryhet garancia, për çfarë?.. Ja ky mekanizëm më i detajuar
YN: – Po, teorikisht nuk ka kontradikta këtu, sepse kur Clickhouse bie, ju mund ta zbuloni atë në një milion mënyra të ndryshme. Nëse Clickhouse rrëzohet (nëse përfundon gabimisht), mundeni, përafërsisht, të ktheni pak nga regjistri juaj që keni shkruar dhe të filloni nga momenti kur gjithçka ishte saktësisht në rregull. Le të themi se e ktheni një minutë prapa, domethënë, konsiderohet se keni shpëlarë gjithçka në një minutë.
З: – Domethënë, “Kittenhouse” e mban dritaren më gjatë dhe, në rast rënieje, a mund ta njohë dhe ta kthejë prapa?
YN: – Por kjo është në teori. Në praktikë, ne nuk e bëjmë këtë, dhe dorëzimi i besueshëm është nga zero në pafundësi herë. Por mesatarisht një. Jemi të kënaqur që nëse Clickhouse dështon për ndonjë arsye ose serverët "rifillojnë", atëherë ne humbasim pak. Në të gjitha rastet e tjera, asgjë nuk do të ndodhë.
З: - Përshëndetje. Që në fillim më dukej se ju me të vërtetë do të përdornit UDP që në fillim të raportit. Ju keni http, të gjitha këto... Dhe shumica e problemeve që përshkruat, siç e kuptoj unë, janë shkaktuar nga kjo zgjidhje e veçantë...
YN: – Çfarë përdorim TCP?
З: - Në thelb po.
YN: - Jo.
З: – Me fasthttp kishe probleme, me lidhjen kishe probleme. Nëse sapo kishit përdorur UDP, do t'i kishit kursyer vetes pak kohë. Epo, do të kishte probleme me mesazhe të gjata ose diçka tjetër...
YN: - Me çfarë?
З: – Me mesazhe të gjata, meqë mund të mos futet në MTU, diçka tjetër... Epo, mund të ketë probleme të tyre. Pyetja është: pse jo UDP?
YN: – Besoj se autorët që zhvilluan TCP/IP janë shumë më të zgjuar se unë dhe dinë më mirë se unë si të serializojnë paketat (në mënyrë që ato të shkojnë), në të njëjtën kohë të rregullojnë dritaren e dërgimit, të mos mbingarkojnë rrjetin, të japin komente se çfarë nuk lexohet, pa llogaritur nga ana tjetër... Të gjitha këto probleme, për mendimin tim, do të ekzistonin në UDP, vetëm se unë do të më duhej të shkruaja edhe më shumë kod seç kam shkruar tashmë për të zbatuar të njëjtën gjë vetë dhe me shumë mundësi dobet. Nuk më pëlqen shumë të shkruaj në C, e lëre më atje ...
З: - Thjesht i përshtatshëm! Dërguar në rregull dhe mos prisni asgjë - është plotësisht asinkron. U kthye një njoftim se gjithçka ishte në rregull - kjo do të thotë se mbërriti; Nëse nuk vjen, do të thotë se është keq.
YN: – Më duhen të dyja – duhet të jem në gjendje t’i dërgoj të dyja me garanci për dorëzim dhe pa garanci për dorëzim. Këto janë dy skenarë të ndryshëm. Më duhet të mos humbas disa shkrime ose të mos i humbas ato brenda arsyes.
З: – Nuk do të humbas kohë. Kjo duhet të diskutohet më shumë. Faleminderit.
Moderator: – Kush ka pyetje – duart drejt qiellit!
З: - Përshëndetje, unë jam Sasha. Diku në mes të raportit, u shfaq një ndjenjë se, përveç TCP, ishte e mundur të përdorej një zgjidhje e gatshme - një lloj Kafka.
YN: – Epo... të thashë që nuk dua të përdor serverë të ndërmjetëm, se... në Kafka na del se kemi dhjetë mijë hostë; në fakt, ne kemi më shumë - dhjetëra mijëra hostë. Mund të jetë gjithashtu e dhimbshme të bësh me Kafkën pa asnjë përfaqësues. Për më tepër, më e rëndësishmja, ai ende jep "latente", jep hoste shtesë që duhet të keni. Por unë nuk dua t'i kem ato - dua ...
З: "Por në fund gjithsesi doli kështu."
YN: – Jo, nuk ka nikoqirë! E gjithë kjo funksionon në hostet e Clickhouse.
З: - Epo, dhe "Kittenhouse", e cila është e kundërta - ku jeton ai?
YN: – Në hostin Clickhouse, ai nuk shkruan asgjë në disk.
З: - Le të supozojmë.
Moderator: - A je i kenaqur? Mund t'ju japim një rrogë?
З: - Po ti mundesh. Në fakt, ka shumë paterica për të marrë të njëjtën gjë, dhe tani - përgjigja e mëparshme në temën e TCP kundërshton, për mendimin tim, këtë situatë. Thjesht më duket sikur gjithçka mund të ishte bërë në gjunjë në shumë më pak kohë.
YN: – Dhe gjithashtu pse nuk doja të përdorja Kafkën, sepse kishte mjaft ankesa në bisedën Telegram të Clickhouse se, për shembull, mesazhet nga Kafka humbën. Jo nga vetë Kafka, por në integrimin e Kafkës dhe Clickhaus-it; ose diçka nuk lidhej atje. Përafërsisht, atëherë do të ishte e nevojshme të shkruante një klient për Kafkën. Nuk mendoj se mund të ketë një zgjidhje më të thjeshtë apo më të besueshme.
З: – Më thuaj, pse nuk provove ndonjë radhë apo ndonjë lloj autobusi të zakonshëm? Meqë thoni se me asinkroni mund t'i dërgoni vetë regjistrat përmes radhës dhe të merrni përgjigjen në mënyrë asinkrone përmes radhës?
YN: – Ju lutemi sugjeroni se cilat radhë mund të përdoren?
З: – Çdo, edhe pa garanci se janë në rregull. Një lloj Redis, RMQ...
YN: – Kam një ndjenjë që Redis me shumë mundësi nuk do të jetë në gjendje të tërheqë një vëllim të tillë futjeje edhe në një host (në kuptimin e disa serverëve) që nxjerr Clickhouse. Këtë nuk mund ta mbështes me asnjë provë (nuk e kam krahasuar), por më duket se Redis nuk është zgjidhja më e mirë këtu. Në parim, ky sistem mund të konsiderohet si një radhë e improvizuar mesazhesh, por që është përshtatur vetëm për "Clickhouse"
Moderator: - Yuri, faleminderit shumë. Unë propozoj t'i mbyllim këtu pyetjet dhe përgjigjet dhe të them se kujt prej atyre që e bënë pyetjen do t'ia japim librin.
YN: – Do të doja t'i dhuroja një libër personit të parë që bëri një pyetje.
Moderator: - E mrekullueshme! E shkëlqyeshme! I mrekullueshëm! Faleminderit shume!
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com