HighLoad++ Moskva 2018, Kongresová sála. 9. novembra, 15:00
Abstrakty a prezentácia:
Yuri Nasretdinov (VKontakte): správa bude hovoriť o skúsenostiach s implementáciou ClickHouse v našej spoločnosti - prečo ho potrebujeme, koľko údajov ukladáme, ako ich zapisujeme atď.
Dodatočné materiály:
Jurij Nasretdinov: - Ahojte všetci! Volám sa Jurij Nasretdinov, ako som už bol predstavený. Pracujem vo VKontakte. Budem hovoriť o tom, ako vkladáme dáta do ClickHouse z našej serverovej flotily (desiatky tisíc).
Čo sú guľatiny a prečo ich zbierať?
Čo vám povieme: čo sme urobili, prečo sme potrebovali „ClickHouse“, respektíve, prečo sme si ho vybrali, aký výkon môžete približne získať bez toho, aby ste niečo špeciálne konfigurovali. Poviem vám ďalej o vyrovnávacích tabuľkách, o problémoch, ktoré sme s nimi mali, a o našich riešeniach, ktoré sme vyvinuli z open source – KittenHouse a Lighthouse.
Prečo sme vôbec museli niečo robiť (na VKontakte je vždy všetko dobré, však?). Chceli sme zbierať protokoly ladenia (a tam boli stovky terabajtov údajov), možno by bolo nejako pohodlnejšie vypočítať štatistiky; a máme flotilu desiatok tisíc serverov, z ktorých toto všetko treba robiť.
Prečo sme sa rozhodli? Pravdepodobne sme mali riešenia na ukladanie denníkov. Tu – existuje taký verejný „Backend VK“. Vrelo odporúčam prihlásiť sa na odber.
Čo sú denníky? Toto je motor, ktorý vracia prázdne polia. Motory vo VK sú to, čo ostatní nazývajú mikroslužby. A tu je úsmevná nálepka (celkom veľa lajkov). Ako to? No počúvaj ďalej!
Čo možno použiť na ukladanie protokolov? Nemožno nespomenúť Hadupa. Potom napríklad Rsyslog (ukladanie týchto protokolov do súborov). LSD. Kto vie, čo je LSD? Nie, toto LSD nie. Ukladať súbory, resp. ClickHouse je zvláštna možnosť.
Clickhouse a konkurenti: požiadavky a príležitosti
čo chceme? Chceme zabezpečiť, aby sme sa s prevádzkou nemuseli príliš obávať, aby fungovala hneď po vybalení, najlepšie s minimálnou konfiguráciou. Chceme písať veľa a písať rýchlo. A chceme si to uchovať všelijaké mesiace, roky, teda dlhodobo. Možno budeme chcieť porozumieť nejakému problému, s ktorým za nami prišli a povedali: „Niečo tu nefunguje“, a to bolo pred 3 mesiacmi), a chceme mať možnosť vidieť, čo sa stalo pred 3 mesiacmi. Kompresia údajov – je jasné, prečo by to bolo plus – pretože znižuje množstvo miesta, ktoré zaberá.
A máme takú zaujímavú požiadavku: občas zapisujeme výstup nejakých príkazov (napríklad logy), môže to byť celkom ľahko aj viac ako 4 kilobajty. A ak táto vec funguje cez UDP, potom to nemusí minúť... nebude mať žiadnu „réžiu“ na pripojenie a pre veľký počet serverov to bude plus.
Pozrime sa, čo nám open source ponúka. Po prvé, máme Logs Engine - to je náš engine; V zásade dokáže všetko, vie písať aj dlhé riadky. No, nekomprimuje transparentne dáta – veľké stĺpce môžeme komprimovať sami, ak chceme... samozrejme nechceme (ak je to možné). Jediný problém je, že vie dať len to, čo sa mu zmestí do pamäti; Ak si chcete prečítať zvyšok, musíte získať binlog tohto motora, a preto to trvá dosť dlho.
Aké sú ďalšie možnosti? Napríklad "Hadup". Jednoduché ovládanie... Kto si myslí, že Hadup sa dá ľahko nastaviť? S nahrávaním samozrejme nie sú žiadne problémy. Pri čítaní sa občas vynárajú otázky. V zásade by som povedal, že asi nie, hlavne pri polenách. Dlhodobé ukladanie – samozrejme, áno, kompresia údajov – áno, dlhé reťazce – je jasné, že môžete nahrávať. Ale nahrávanie z veľkého počtu serverov... Stále musíte niečo urobiť sami!
Rsyslog. V skutočnosti sme ho použili ako záložnú možnosť, aby sme ho mohli čítať bez vyprázdnenia binlogu, ale nemôže písať dlhé riadky, v zásade nemôže zapísať viac ako 4 kilobajty. Kompresiu údajov musíte vykonať rovnakým spôsobom sami. Čítanie bude pochádzať zo súborov.
Potom je tu „badushka“ vývoj LSD. V podstate to isté ako „Rsyslog“: podporuje dlhé reťazce, ale nemôže fungovať cez UDP a v skutočnosti je kvôli tomu, žiaľ, dosť veľa vecí, ktoré je potrebné prepísať. LSD je potrebné prepracovať, aby bolo možné nahrávať z desiatok tisíc serverov.
A tu! Vtipnou možnosťou je ElasticSearch. Ako to povedať? S čítaním sa mu darí, teda číta rýchlo, ale nie veľmi dobre s písaním. Po prvé, ak komprimuje údaje, sú veľmi slabé. Úplné vyhľadávanie si s najväčšou pravdepodobnosťou vyžaduje väčšie dátové štruktúry ako pôvodný objem. Je náročná na obsluhu a často s ňou vznikajú problémy. A opäť nahrávanie v Elastic – všetko si musíme robiť sami.
Tu je ClickHouse samozrejme ideálnou voľbou. Jediná vec je, že nahrávanie z desiatok tisíc serverov je problém. Ale je tu aspoň jeden problém, môžeme sa ho pokúsiť nejako vyriešiť. A zvyšok správy je o tomto probléme. Aký výkon môžete očakávať od ClickHouse?
Ako to vložíme? MergeTree
Kto z vás nepočul alebo nevie o „ClickHouse“? Musím ti to povedať, však? Veľmi rýchlo. Vloženie tam - 1-2 gigabity za sekundu, nárazy až 10 gigabitov za sekundu túto konfiguráciu skutočne znesú - sú tam dva 6-jadrové Xeóny (teda ani tie najvýkonnejšie), 256 gigabajtov RAM, 20 terabajtov v RAID (nikto nie je nakonfigurovaný, predvolené nastavenia). Alexey Milovidov, vývojár ClickHouse, tam pravdepodobne sedí a plače, pretože sme nič nenakonfigurovali (všetko nám tak fungovalo). V súlade s tým je možné dosiahnuť rýchlosť skenovania, povedzme, asi 6 miliárd riadkov za sekundu, ak sú údaje dobre komprimované. Ak máte radi % na textovom reťazci - 100 miliónov riadkov za sekundu, to znamená, že sa to zdá byť dosť rýchle.
Ako to vložíme? Viete, že VK používa PHP. Od každého PHP pracovníka cez HTTP vložíme do “ClickHouse”, do tabuľky MergeTree pre každý záznam. Kto vidí problém v tejto schéme? Z nejakého dôvodu nie všetci zdvihli ruky. Dovoľ mi povedať ti.
Po prvé, existuje veľa serverov - podľa toho bude veľa pripojení (zlé). Potom je lepšie vkladať údaje do MergeTree nie častejšie ako raz za sekundu. A ktovie prečo? Dobre dobre. Poviem vám o tom trochu viac. Ďalšou zaujímavou otázkou je, že nerobíme analytiku, nepotrebujeme obohacovať dáta, nepotrebujeme sprostredkujúce servery, chceme vkladať priamo do „ClickHouse“ (pokiaľ možno – čím priamočiarejšie, tým lepšie).
Ako sa teda robí vkladanie do MergeTree? Prečo je lepšie do neho vkladať nie častejšie ako raz za sekundu alebo menej často? Faktom je, že „ClickHouse“ je stĺpcová databáza a zoraďuje údaje vo vzostupnom poradí podľa primárneho kľúča, a keď vložíte, vytvorí sa počet súborov, ktorý sa rovná počtu stĺpcov, v ktorých sú údaje zoradené. vo vzostupnom poradí primárneho kľúča (vytvorí sa samostatný adresár, množina súborov na disku pre každú vložku). Potom príde ďalšie vloženie a na pozadí sa spoja do väčších „oddielov“. Keďže dáta sú triedené, je možné „zlúčiť“ dva zoradené súbory bez toho, aby zaberali veľa pamäte.
Ale, ako by ste mohli hádať, ak na každý vklad napíšete 10 súborov, potom ClickHouse (alebo váš server) rýchlo skončí, takže sa odporúča vkladať vo veľkých dávkach. Preto sme nikdy nespustili prvú schému do výroby. Hneď sme spustili jeden, ktorý tu č. 2 má:
Tu si predstavte, že existuje asi tisíc serverov, na ktorých sme spustili, len PHP. A na každom serveri je náš lokálny agent, ktorého sme nazvali „Kittenhouse“, ktorý udržiava jedno spojenie s „ClickHouse“ a vkladá údaje každých pár sekúnd. Vkladá dáta nie do MergeTree, ale do vyrovnávacej tabuľky, ktorá slúži práve na to, aby sa nemuselo hneď vkladať priamo do MergeTree.
Práca s vyrovnávacími tabuľkami
Čo to je? Tabuľky vyrovnávacej pamäte predstavujú časť pamäte, ktorá je rozbitá (to znamená, že ju možno do nej často vkladať). Pozostávajú z niekoľkých dielov a každý z dielov funguje ako nezávislý buffer a preplachujú sa nezávisle (ak máte veľa dielikov v bufferi, potom bude veľa vložiek za sekundu). Z týchto tabuliek je možné čítať – vtedy načítate spojenie obsahu vyrovnávacej pamäte a nadradenej tabuľky, no v tomto momente je zápis zablokovaný, preto je lepšie odtiaľ nečítať. A vyrovnávacie tabuľky ukazujú veľmi dobré QPS, to znamená, že do 3 tisíc QPS nebudete mať pri vkladaní vôbec žiadne problémy. Je jasné, že ak server stratí napájanie, môže dôjsť k strate údajov, pretože boli uložené iba v pamäti.
Schéma s vyrovnávacou pamäťou zároveň komplikuje ALTER, pretože najprv musíte zrušiť starú tabuľku vyrovnávacej pamäte so starou schémou (údaje nikam nezmiznú, pretože sa pred vymazaním tabuľky vyprázdnia). Potom „zmeníte“ tabuľku, ktorú potrebujete, a znova vytvoríte tabuľku vyrovnávacej pamäte. V súlade s tým, kým neexistuje tabuľka vyrovnávacej pamäte, vaše dáta nebudú nikam prúdiť, ale môžete ich mať na disku aspoň lokálne.
Čo je Kittenhouse a ako funguje?
Čo je KittenHouse? Toto je proxy. Hádajte akým jazykom? Vo svojej správe som zhromaždil najviac humbuk tém - „Clickhouse“, Choď, možno si spomeniem na niečo iné. Áno, toto je napísané v Go, pretože ja naozaj neviem, ako písať v C, nechcem.
V súlade s tým udržiava spojenie s každým serverom a môže zapisovať do pamäte. Napríklad, ak do Clickhouse zapisujeme chybové protokoly, tak ak Clickhouse nestihne vložiť dáta (nakoniec, ak je toho napísané príliš veľa), tak pamäť nenafúkneme – zvyšok jednoducho vyhodíme. Pretože ak napíšeme niekoľko gigabitov za sekundu chýb, pravdepodobne ich môžeme vyhodiť. Kittenhouse to dokáže. Navyše môže vykonávať spoľahlivé doručenie, to znamená zapisovať na disk na lokálnom počítači a vždy (tam, raz za pár sekúnd) sa pokúsi doručiť údaje z tohto súboru. A najprv sme použili bežný formát hodnôt - nie nejaký binárny formát, textový formát (ako v bežnom SQL).
Ale potom sa stalo toto. Použili sme spoľahlivé doručovanie, napísali sme protokoly, potom sme sa rozhodli (išlo o podmienený testovací klaster)... Na niekoľko hodín sa to uvoľnilo a obnovilo a začalo sa vkladanie z tisícky serverov – ukázalo sa, že Clickhouse má stále „Vlákno pri pripojení“ - teda pri tisícke pripojení vedie aktívne vloženie k priemernej záťaži servera asi jeden a pol tisíc. Prekvapivo server akceptoval požiadavky, ale údaje boli po určitom čase stále vložené; ale pre server bolo veľmi ťažké to obslúžiť...
Pridajte nginx
Takýmto riešením pre model Thread per connection je nginx. Nainštalovali sme nginx pred Clickhouse, zároveň sme nastavili vyvažovanie pre dve repliky (rýchlosť vkladania sa nám zvýšila 2-krát, aj keď nie je pravda, že by to tak malo byť) a obmedzili sme počet pripojení na Clickhouse na proti prúdu a teda viac ako v 50 spojeniach, zdá sa, že nemá zmysel vkladať.
Potom sme si uvedomili, že táto schéma má vo všeobecnosti nevýhody, pretože tu máme iba jeden nginx. Ak teda tento nginx zlyhá, napriek prítomnosti replík stratíme údaje alebo aspoň nikam nezapisujeme. Preto sme si spravili vlastné vyvažovanie záťaže. Tiež sme si uvedomili, že „Clickhouse“ je stále vhodný pre protokoly a „démon“ tiež začal písať svoje protokoly do „Clickhouse“ - veľmi pohodlné, aby som bol úprimný. Stále ho používame pre iných „démonov“.
Potom sme objavili tento zaujímavý problém: ak použijete neštandardnú metódu vkladania v režime SQL, vynúti si to plnohodnotný analyzátor SQL založený na AST, ktorý je dosť pomalý. V súlade s tým sme pridali nastavenia, aby sa to nikdy nestalo. Urobili sme vyvažovanie záťaže, zdravotné kontroly, takže ak niekto zomrie, stále ponecháme údaje. Teraz máme pomerne veľa tabuliek, ktoré potrebujeme na rôzne klastre Clickhouse. A začali sme uvažovať aj o iných použitiach – chceli sme napríklad písať protokoly z modulov nginx, ale nevedia, ako komunikovať pomocou nášho RPC. No rád by som ich naučil aspoň nejako posielať – napríklad prijímať udalosti na localhoste cez UDP a následne ich preposielať Clickhouse.
Jeden krok od riešenia
Finálna schéma začala vyzerať takto (štvrtá verzia tejto schémy): na každom serveri pred Clickhouse je nginx (na tom istom serveri) a jednoducho proxy posiela požiadavky na localhost s limitom na počet pripojení 50 kusov. A táto schéma už celkom fungovala, všetko s ňou bolo celkom dobré.
Žili sme takto asi mesiac. Všetci boli spokojní, pridávali tabuľky, pridávali, pridávali... Vo všeobecnosti sa ukázalo, že spôsob pridávania vyrovnávacích tabuliek nebol príliš optimálny (povedzme si to tak). Urobili sme 16 kusov v každej tabuľke a flash interval niekoľkých sekúnd; mali sme 20 tabuliek a každá tabuľka dostala 8 insertov za sekundu - a v tomto bode sa začal “Clickhouse”... záznamy sa začali spomaľovať. Nielenže neprešli... Štandardne mal nginx takú zaujímavú vec, že ak spojenia končili na upstreame, tak jednoducho vrátil „502“ všetkým novým požiadavkám.
A tu máme (práve som si pozrel logy v samotnom Clickhouse) asi pol percenta žiadostí zlyhalo. V súlade s tým bolo využitie disku vysoké, došlo k mnohým zlúčeniam. No, čo som urobil? Prirodzene, neobťažoval som sa zistiť, prečo presne skončilo spojenie a proti prúdu.
Nahradenie nginx reverzným proxy
Rozhodol som sa, že to musíme zvládnuť sami, nemusíme to nechať na nginx - nginx nevie, aké tabuľky sú v Clickhouse, a nahradil som nginx reverzným proxy, ktorý som tiež napísal sám.
Čo robí? Funguje na základe knižnice fasthttp „goshnoy“, teda rýchlo, takmer rovnako rýchlo ako nginx. Prepáč, Igor, ak si tu prítomný (poznámka: Igor Sysoev je ruský programátor, ktorý vytvoril webový server nginx). Dokáže pochopiť, o aké druhy dopytov ide – INSERT alebo SELECT – podľa toho uchováva rôzne oblasti pripojení pre rôzne typy dopytov.
Preto, aj keď nestihneme dokončiť požiadavky na vloženie, „vyberie“ prejde a naopak. A zoskupuje údaje do vyrovnávacích tabuliek – s malou vyrovnávacou pamäťou: ak by tam boli nejaké chyby, syntaktické chyby atď. mal malé "bachi" a všetky syntaktické chyby ovplyvnili iba tento malý kúsok; a tu už ovplyvnia veľkú vyrovnávaciu pamäť. Malý je 1 megabajt, teda nie až taký malý.
Vloženie synchronizácie a v podstate nahradenie nginx robí v podstate to isté, čo nginx robil predtým – na to nemusíte meniť miestny „Kittenhouse“. A keďže používa fasthttp, je veľmi rýchly – cez reverzný proxy môžete vykonať viac ako 100 tisíc požiadaviek za sekundu na jednotlivé vložky. Teoreticky môžete do reverzného proxy servera kittenhouse vložiť jeden riadok, ale my to samozrejme nerobíme.
Schéma začala vyzerať takto: „Kittenhouse“, reverzný proxy zoskupuje veľa požiadaviek do tabuliek a vyrovnávacie tabuľky ich zase vkladajú do hlavných.
Killer je dočasné riešenie, Mačiatko trvalé
Toto je zaujímavý problém... Použil niekto z vás fasthttp? Kto použil fasthttp s požiadavkami POST? Pravdepodobne by sa to naozaj nemalo robiť, pretože predvolene ukladá telo požiadavky do vyrovnávacej pamäte a veľkosť našej vyrovnávacej pamäte bola nastavená na 16 megabajtov. Vkladanie v určitom bode prestalo držať krok a 16-megabajtové kusy začali prichádzať zo všetkých desiatok tisíc serverov a všetky boli uložené v pamäti pred odoslaním do Clickhouse. V dôsledku toho sa vyčerpala pamäť, prišiel zabijak z nedostatku pamäte a zabil reverzný proxy (alebo „Clickhouse“, ktorý by teoreticky mohol „zjesť“ viac ako reverzný proxy). Cyklus sa opakoval. Nie veľmi príjemný problém. Aj keď sme na to narazili až po niekoľkých mesiacoch prevádzky.
Čo som urobil? Opäť sa mi veľmi nechce rozumieť tomu, čo sa presne stalo. Myslím, že je celkom zrejmé, že by ste nemali ukladať do pamäte. Nepodarilo sa mi opraviť fasthttp, aj keď som to skúšal. Našiel som ale spôsob, ako to urobiť tak, aby nebolo potrebné nič patchovať a prišiel som na vlastnú metódu v HTTP – nazval som ju KITTEN. No, je to logické - „VK“, „Mačiatko“... Čo ešte?...
Ak príde požiadavka na server s metódou Kitten, server by mal odpovedať „mňau“ - logicky. Ak na to odpovie, má sa za to, že tomuto protokolu rozumie, a potom zachytím spojenie (fasthttp má takúto metódu) a spojenie prejde do „surového“ režimu. Prečo to potrebujem? Chcem ovládať, ako prebieha čítanie z TCP spojení. TCP má úžasnú vlastnosť: ak nikto nečíta z druhej strany, zápis začne čakať a pamäť sa na to zvlášť nevynakladá.
A tak čítam od cca 50 klientov naraz (od päťdesiat lebo päťdesiat by určite malo stačiť, aj keď sadzba pochádza z iného DC)... Spotreba sa týmto prístupom znížila minimálne 20x, ale ja, pravdupovediac , nevedel som presne zmerať aký čas, lebo je to už nezmyselné (už sa to dostalo na úroveň chyby). Protokol je binárny, to znamená, že obsahuje názov tabuľky a údaje; neexistujú žiadne hlavičky http, takže som nepoužil webový soket (nepotrebujem komunikovať s prehliadačmi - vytvoril som protokol, ktorý vyhovuje našim potrebám). A s ním bolo všetko v poriadku.
Tabuľka vyrovnávacej pamäte je smutná
Nedávno sme narazili na ďalšiu zaujímavú vlastnosť vyrovnávacích tabuliek. A tento problém je už oveľa bolestivejší ako ostatné. Predstavme si túto situáciu: už aktívne používate Clickhouse, máte desiatky serverov Clickhouse a máte niekoľko požiadaviek, ktorých čítanie trvá veľmi dlho (povedzme viac ako 60 sekúnd); a vy prídete a urobíte zmenu v tomto momente... Medzitým „selects“, ktoré začali pred „Alter“, nebudú zahrnuté do tejto tabuľky, „Alter“ sa nespustí – pravdepodobne niektoré funkcie fungovania „Clickhouse“ v toto miesto. Možno sa to dá opraviť? Alebo je to nemožné?
Vo všeobecnosti je jasné, že v skutočnosti to nie je až taký veľký problém, no s buffer tabuľkami to začína byť bolestivejšie. Pretože, ak, povedzme, uplynú vaše časové limity „Alter“ (a môže to uplynúť na inom hostiteľovi – nie na vašom, ale napríklad na replike), potom... Vymazali ste tabuľku vyrovnávacej pamäte, svoju „Alter“ ( alebo iného hostiteľa) vypršal časový limit. potom sa vyskytla chyba „Zmeniť“ - stále musíte zabezpečiť, aby sa údaje naďalej zapisovali: vytvorte tabuľky vyrovnávacej pamäte (podľa rovnakej schémy ako nadradená tabuľka), potom „Alter“ prejde, napokon skončí a vyrovnávacia pamäť tabuľky sa začne líšiť schémou od nadradenej. V závislosti od toho, čo bol „Alter“, vložka už nemusí ísť do tejto vyrovnávacej tabuľky - to je veľmi smutné.
Existuje aj taký znak (možno si ho niekto všimol) - v nových verziách Clickhouse sa nazýva query_thread_log. V predvolenom nastavení v niektorých verziách bol jeden. Tu sme za pár mesiacov nazhromaždili 840 miliónov záznamov (100 gigabajtov). Je to spôsobené tým, že tam boli napísané „vložky“ (možno teraz, mimochodom, nie sú napísané). Ako som vám povedal, naše „vložky“ sú malé – mali sme veľa „vložiek“ do vyrovnávacích tabuliek. Je jasné, že je to zakázané - len vám hovorím, čo som videl na našom serveri. prečo? Toto je ďalší argument proti používaniu vyrovnávacích tabuliek! Spotty je veľmi smutný.
Kto vedel, že ten chlap sa volal Spotty? Zamestnanci VK zdvihli ruky. OK.
O plánoch pre „KitttenHouse“
Plány sa zvyčajne nezdieľajú, však? Zrazu ich nesplníte a v očiach iných ľudí nebudete vyzerať veľmi dobre. Ale ja to risknem! Chceme urobiť nasledovné: vyrovnávacie tabuľky, zdá sa mi, sú stále barličkou a vkladanie musíme vyrovnávať sami. Ale stále to nechceme ukladať do vyrovnávacej pamäte na disku, takže vloženie do pamäte nastavíme do vyrovnávacej pamäte.
V súlade s tým, keď sa vytvorí „vloženie“, už nebude synchrónne – už bude fungovať ako vyrovnávacia tabuľka, vloží sa do nadradenej tabuľky (no, niekedy neskôr) a prostredníctvom samostatného kanála oznámi, ktoré vložky prešli a ktoré nemať.
Prečo nemôžem opustiť synchrónnu vložku? Je to oveľa pohodlnejšie. Faktom je, že ak vložíte z 10 tisíc hostiteľov, potom je všetko v poriadku - z každého hostiteľa dostanete trochu, vložíte tam raz za sekundu, všetko je v poriadku. Chcel by som však, aby táto schéma fungovala napríklad z dvoch počítačov, aby ste mohli sťahovať vysokou rýchlosťou - možno nie dostať maximum z Clickhouse, ale zapisovať aspoň 100 megabajtov za sekundu z jedného počítača cez reverzný proxy - táto schéma sa musí škálovať na veľké aj malé množstvá, takže nemôžeme čakať sekundu na každé vloženie, takže musí byť asynchrónne. A rovnakým spôsobom by po dokončení vkladania mali prísť asynchrónne potvrdenia. Či to prešlo alebo nie, budeme vedieť.
Najdôležitejšie je, že v tejto schéme s istotou vieme, či k vloženiu došlo alebo nie. Predstavte si túto situáciu: máte tabuľku vyrovnávacej pamäte, niečo ste do nej zapísali a potom, povedzme, tabuľka prešla do režimu iba na čítanie a pokúsila sa vyprázdniť vyrovnávaciu pamäť. Kam pôjdu údaje? Zostanú vo vyrovnávacej pamäti. Tým si však nemôžeme byť istí – čo ak sa vyskytne nejaká iná chyba, kvôli ktorej nezostanú dáta vo vyrovnávacej pamäti... (Adresy Alexey Milovidov, Yandex, vývojár ClickHouse) Alebo ostanú? Vždy? Alexey nás presviedča, že všetko bude v poriadku. Nemáme dôvod mu neveriť. Ale rovnako: ak nepoužívame vyrovnávacie tabuľky, potom s nimi nebudú žiadne problémy. Vytvárať dvakrát toľko tabuliek je tiež nepohodlné, aj keď v zásade neexistujú žiadne veľké problémy. Toto je plán.
Poďme sa rozprávať o čítaní
Teraz sa bavme o čítaní. Napísali sme tu aj vlastný nástroj. Zdalo by sa, že prečo sem písať svoj vlastný nástroj?... A kto používal Tabix? Akosi málokto zdvihol ruky... A kto je spokojný s výkonom Tabixu? Nie sme s tým spokojní a nie je to príliš pohodlné na prezeranie údajov. Je to v poriadku na analýzu, ale len na prezeranie zjavne nie je optimalizované. Tak som napísal svoje vlastné, vlastné rozhranie.
Je to veľmi jednoduché – dokáže len čítať dáta. Nevie ukázať grafiku, nevie nič robiť. Môže však ukázať, čo potrebujeme: napríklad koľko riadkov je v tabuľke, koľko miesta zaberá (bez rozdelenia na stĺpce), to znamená, že potrebujeme úplne základné rozhranie.
A vyzerá to veľmi podobne ako Sequel Pro, ale vytvorené iba na Twitteri Bootstrap a v druhej verzii. Pýtate sa: "Yuri, prečo na druhej verzii?" Ktorý rok? 2018? Vo všeobecnosti som to urobil už veľmi dávno pre „Muscle“ (MySQL) a práve som tam zmenil pár riadkov v dopytoch a začalo to fungovať pre „Clickhouse“, za čo špeciálne ďakujem! Pretože analyzátor je veľmi podobný tomu „svalovému“ a otázky sú veľmi podobné – veľmi pohodlné, najmä na začiatku.
Dokáže filtrovať tabuľky, môže zobraziť štruktúru a obsah tabuľky, umožňuje triediť, filtrovať podľa stĺpcov, zobrazuje dotaz, ktorý viedol k výsledku, ovplyvnené riadky (koľko vo výsledku), teda základné veci na prezeranie údajov. Docela rýchlo.
Je tam aj editor. Úprimne som sa snažil ukradnúť celý editor z Tabixu, ale nepodarilo sa mi to. Ale nejako to funguje. V princípe je to všetko.
"Clickhouse" je vhodný do brlohov
Chcem vám povedať, že Clickhouse sa napriek všetkým popísaným problémom veľmi dobre hodí na polená. Najdôležitejšie je, že rieši náš problém – je veľmi rýchly a umožňuje filtrovať protokoly podľa stĺpcov. Buffer tables v zásade nefungovali dobre, ale zvyčajne nikto nevie prečo... Možno teraz lepšie viete, kde budete mať problémy.
TCP? Vo VK je vo všeobecnosti obvyklé používať UDP. A keď som použil TCP... Samozrejme, nikto mi nepovedal: „Juri, o čom to hovoríš! Nemôžeš, potrebuješ UDP." Ukázalo sa, že TCP nie je také strašidelné. Jediná vec je, že ak máte desiatky tisíc aktívnych zlúčenín, ktoré píšete, musíte to pripraviť trochu opatrnejšie; ale je to možné a celkom jednoduché.
Sľúbil som, že uverejním “Kittenhouse” a “Lighthouse” na HighLoad Siberia, ak sa všetci prihlásia na odber nášho verejného “VK backendu”... A viete, nie všetci sa prihlásili... Samozrejme, nebudem vyžadovať, aby ste odoberali naše verejnosti. Je vás stále priveľa, niekto sa možno aj urazí, no aj tak sa prihláste (a tu musím urobiť oči ako mačacie). To je . Ďakujem mnohokrát! Github je náš . S Clickhouse budú vaše vlasy jemné a hodvábne.
moderátor: - Priatelia, teraz otázky. Hneď po predložení ďakovného listu a vašej správy na VHS.
Jurij Nasretdinov (ďalej len YN): – Ako ste mohli nahrať moju reportáž na VHS, ak práve skončila?
moderátor: – Nemôžete tiež úplne určiť, ako bude „Clickhouse“ fungovať alebo nie! Priatelia, 5 minút na otázky!
otázky
Otázka z publika (ďalej len Q): - Dobrý deň. Ďakujem veľmi pekne za správu. mam dve otazky. Začnem niečím frivolným: ovplyvňuje počet písmen t v názve "Kittenhouse" v diagramoch (3, 4, 7...) spokojnosť mačiek?
YN: - Množstvo čoho?
W: – list t. Sú tri t, niekde okolo troch t.
YN: - Neopravil som to? No, samozrejme, že áno! Sú to rôzne produkty - celý ten čas som vás len klamal. Dobre, robím si srandu - to je jedno. Aha, tu! Nie, je to to isté, urobil som preklep.
W: - Ďakujem. Druhá otázka je vážna. Pokiaľ som pochopil, v Clickhouse tabuľky vyrovnávacej pamäte žijú výlučne v pamäti, neukladajú sa do vyrovnávacej pamäte na disku, a preto nie sú trvalé.
YN: - Áno.
W: – A zároveň váš klient ukladá na disk vyrovnávaciu pamäť, čo znamená určitú záruku doručenia rovnakých protokolov. To však v Clickhouse v žiadnom prípade nie je zaručené. Vysvetlite, ako sa záruka vykonáva, kvôli čomu?... Tu je tento mechanizmus podrobnejšie
YN: – Áno, teoreticky tu nie sú žiadne rozpory, pretože keď Clickhouse padne, môžete to v skutočnosti odhaliť miliónom rôznych spôsobov. Ak Clickhouse zlyhá (ak skončí nesprávne), môžete, zhruba povedané, pretočiť trochu svojho denníka, ktorý ste si zapísali, a začať od okamihu, keď bolo všetko v poriadku. Povedzme, že pretočíte minútu dozadu, to znamená, že sa považuje za to, že ste za minútu všetko vypláchli.
W: – To znamená, že „Kittenhouse“ drží okno dlhšie a v prípade pádu ho dokáže rozpoznať a previnúť?
YN: - Ale to je teoreticky. V praxi to nerobíme a spoľahlivé doručenie je od nuly do nekonečna. Ale v priemere jeden. Sme spokojní, že ak Clickhouse z nejakého dôvodu zlyhá alebo sa servery „reštartujú“, trochu stratíme. Vo všetkých ostatných prípadoch sa nič nestane.
W: - Ahoj. Od samého začiatku sa mi zdalo, že budete skutočne používať UDP od samého začiatku správy. Máš http, to všetko... A väčšina problémov, ktoré si opísal, ako som pochopil, bola spôsobená práve týmto riešením...
YN: – Čo používame TCP?
W: - V podstate áno.
YN: - Nie.
W: – Problémy ste mali s fasthttp, problémy s pripojením. Ak by ste práve použili UDP, ušetrili by ste si nejaký čas. No, boli by problémy s dlhými správami alebo niečím iným...
YN: - S čím?
W: – Pri dlhých správach, keďže sa to nemusí zmestiť do MTU, niečo iné... No, môžu nastať vlastné problémy. Otázka znie: prečo nie UDP?
YN: – Verím, že autori, ktorí vyvinuli TCP/IP, sú oveľa múdrejší ako ja a vedia lepšie ako ja serializovať pakety (aby išli), zároveň upraviť okno odosielania, nepreťažovať sieť, dávať spätnú väzbu o tom, čo sa nečíta, nepočítajúc na druhú stranu... Všetky tieto problémy by podľa mňa v UDP existovali, len by som musel napísať ešte viac kódu, ako som už napísal, aby som to isté implementoval sám a s najväčšou pravdepodobnosťou úboho. Ani ma veľmi nebaví písať v C, nieto tam...
W: - Len pohodlné! Odoslané v poriadku a na nič nečakajte – je to úplne asynchrónne. Prišlo upozornenie, že je všetko v poriadku – to znamená, že prišlo; Ak nepríde, znamená to, že je zle.
YN: – Potrebujem oboje – potrebujem vedieť poslať aj so zárukou doručenia aj bez záruky doručenia. Ide o dva rôzne scenáre. Potrebujem nestratiť nejaké protokoly alebo ich nestratiť v rozumnej miere.
W: — Nebudem strácať čas. O tom treba viac diskutovať. Ďakujem.
moderátor: – Kto má otázky – ruky do neba!
W: - Ahoj, ja som Sasha. Niekde v strede reportáže sa objavil pocit, že okrem TCP je možné použiť hotové riešenie – nejakého Kafku.
YN: – No... Povedal som vám, že nechcem používať medziservery, pretože... v Kafke sa ukázalo, že máme desaťtisíc hostiteľov; v skutočnosti máme viac – desaťtisíce hostiteľov. Môže byť tiež bolestivé robiť s Kafkom bez akýchkoľvek proxy. Okrem toho, čo je najdôležitejšie, stále poskytuje „latenciu“, poskytuje ďalších hostiteľov, ktorých musíte mať. Ale ja ich nechcem mať - chcem...
W: "Ale nakoniec to aj tak dopadlo."
YN: – Nie, neexistujú žiadni hostitelia! Toto všetko funguje na hostiteľoch Clickhouse.
W: - No, a "Kittenhouse", čo je naopak - kde žije?
YN: – Na hostiteľovi Clickhouse nič nezapisuje na disk.
W: - Predpokladajme.
moderátor: - Si spokojný? Môžeme vám dať plat?
W: - Áno môžeš. V skutočnosti existuje veľa bariel, aby sme dostali to isté, a teraz - predchádzajúca odpoveď na tému TCP je podľa môjho názoru v rozpore s touto situáciou. Len mám pocit, že všetko sa dalo urobiť na kolene za oveľa kratší čas.
YN: – A tiež, prečo som nechcel použiť Kafku, pretože v rozhovore Clickhouse Telegram bolo pomerne veľa sťažností, že sa napríklad stratili správy od Kafku. Nie od Kafky samotnej, ale v integrácii Kafky a Clickhausu; alebo sa tam nieco nespojilo. Zhruba povedané, vtedy by bolo potrebné napísať klienta pre Kafku. Nemyslím si, že by mohlo existovať jednoduchšie alebo spoľahlivejšie riešenie.
W: – Povedz mi, prečo si neskúsil fronty alebo nejaký spoločný autobus? Pretože hovoríte, že s asynchrónnosťou by ste mohli posielať samotné protokoly cez front a prijímať odpoveď asynchrónne cez front?
YN: – Prosím, navrhnite, aké rady by ste mohli použiť?
W: – Akékoľvek, aj bez záruky, že sú v poriadku. Nejaký druh Redis, RMQ...
YN: – Mám pocit, že Redis s najväčšou pravdepodobnosťou nezvládne natiahnuť taký objem insertov ani na jednom hostiteľovi (v zmysle viacerých serverov), ktorý vytiahne Clickhouse. Nemôžem to podložiť žiadnym dôkazom (nemám to porovnávané), ale zdá sa mi, že Redis tu nie je najlepšie riešenie. V zásade možno tento systém považovať za improvizovaný front správ, ktorý je však prispôsobený len pre „Clickhouse“
moderátor: – Yuri, ďakujem veľmi pekne. Navrhujem tu ukončiť otázky a odpovede a povedať, komu z tých, ktorí položili otázku, dáme knihu.
YN: – Chcel by som dať knihu prvému, kto položil otázku.
moderátor: - Úžasné! Skvelé! Úžasné! Mnohokrat dakujem!
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com