HighLoad++ Moskva 2018, Kongresna dvorana. 9. november, 15:00
Povzetki in predstavitev:
Yuri Nasretdinov (VKontakte): poročilo bo govorilo o izkušnjah z uvedbo ClickHouse v našem podjetju - zakaj ga potrebujemo, koliko podatkov hranimo, kako jih pišemo itd.
Dodatni materiali:
Jurij Nasretdinov: - Pozdravljeni vsi skupaj! Ime mi je Jurij Nasretdinov, kot sem bil že predstavljen. Delam v VKontakte. Govoril bom o tem, kako v ClickHouse vnašamo podatke iz naše flote strežnikov (več deset tisoč).
Kaj so polena in zakaj jih zbirati?
Kaj vam bomo povedali: kaj smo naredili, zakaj smo potrebovali »ClickHouse« oziroma, zakaj smo ga izbrali, kakšno zmogljivost lahko približno dosežete, ne da bi kaj posebej konfigurirali. Povedal vam bom še o vmesnih tabelah, o težavah, ki smo jih imeli z njimi, in o naših rešitvah, ki smo jih razvili iz odprte kode - KittenHouse in Lighthouse.
Zakaj smo sploh morali karkoli narediti (na VKontakte je vedno vse dobro, kajne?). Želeli smo zbrati dnevnike odpravljanja napak (in tam je bilo na stotine terabajtov podatkov), morda bi bilo nekako bolj priročno izračunati statistiko; in imamo floto več deset tisoč strežnikov, iz katerih je treba narediti vse to.
Zakaj smo se odločili? Verjetno smo imeli rešitve za shranjevanje dnevnikov. Tukaj - obstaja takšen javni "Backend VK". Zelo priporočam, da se nanjo naročite.
Kaj so dnevniki? To je motor, ki vrača prazne nize. Motorji v VK drugi imenujejo mikrostoritve. In tukaj je nasmejana nalepka (kar veliko všečkov). Kako to? No, poslušaj naprej!
Kaj lahko uporabimo za shranjevanje dnevnikov? Nemogoče je ne omeniti Hadupa. Nato na primer Rsyslog (shranjevanje teh dnevnikov v datoteke). LSD. Kdo ve, kaj je LSD? Ne, ne ta LSD. Shranjujte tudi datoteke. No, ClickHouse je čudna možnost.
Clickhouse in konkurenti: zahteve in priložnosti
Kaj hočemo? Želimo zagotoviti, da nam ni treba preveč skrbeti za delovanje, tako da deluje takoj, po možnosti z minimalno konfiguracijo. Želimo pisati veliko in pisati hitro. In hočemo ga obdržati za najrazličnejše mesece, leta, torej za dolgo časa. Morda želimo razumeti kakšno težavo, s katero so prišli k nam in rekli: "Tukaj nekaj ne deluje," in to je bilo pred 3 meseci), in želimo videti, kaj se je zgodilo pred 3 meseci. Stiskanje podatkov – jasno je, zakaj bi bilo to plus – saj zmanjša količino prostora, ki ga zavzame.
In imamo tako zanimivo zahtevo: včasih napišemo izhod nekaterih ukazov (na primer dnevnike), zlahka je lahko večji od 4 kilobajtov. In če ta zadeva dela preko UDP, potem ne rabi trošiti... ne bo imela nobenih "overheadov" za povezavo, za veliko število strežnikov pa bo to plus.
Poglejmo, kaj nam ponuja odprta koda. Prvič, imamo Logs Engine – to je naš motor; Načeloma zmore vse, zna celo pisati dolge vrstice. No, podatkov ne stisne transparentno - velike stolpce lahko stisnemo sami, če želimo ... tega seveda nočemo (če je mogoče). Edina težava je v tem, da lahko izda samo tisto, kar sodi v njegov spomin; Če želite prebrati ostalo, morate dobiti binlog tega motorja in zato traja precej časa.
Katere druge možnosti obstajajo? Na primer "Hadup". Enostavnost delovanja ... Kdo misli, da je Hadup enostaven za postavitev? S snemanjem seveda ni težav. Ob branju se včasih porajajo vprašanja. Načeloma bi rekel, da verjetno ne, sploh za hlode. Dolgoročno shranjevanje - seveda, da, stiskanje podatkov - da, dolgi nizi - jasno je, da lahko snemate. Ampak snemanje iz velikega števila strežnikov ... Vseeno morate nekaj narediti sami!
Rsyslog. Pravzaprav smo ga uporabili kot rezervno opcijo, da smo ga lahko brali brez dampa binloga, vendar ne more pisati dolgih vrstic, načeloma ne more pisati več kot 4 kilobajte. Stiskanje podatkov morate izvesti na enak način sami. Branje bo prišlo iz datotek.
Potem je tu še "baduška" razvoj LSD. V bistvu enako kot "Rsyslog": podpira dolge nize, vendar ne more delovati prek UDP in pravzaprav je zaradi tega na žalost kar nekaj stvari, ki jih je treba prepisati. LSD je treba preoblikovati, da bo lahko snemal z več deset tisoč strežnikov.
In tukaj! Smešna možnost je ElasticSearch. Kako naj rečem? Branje mu gre dobro od rok, se pravi hitro bere, pisanje pa ne ravno dobro. Prvič, če stisne podatke, je zelo šibek. Najverjetneje popolno iskanje zahteva večje podatkovne strukture od izvirne količine. Težko ga je upravljati in z njim se pogosto pojavljajo težave. In spet snemanje v Elastic - vse moramo narediti sami.
Tu je ClickHouse seveda idealna možnost. Težava je le snemanje iz več deset tisoč strežnikov. Ampak vsaj ena težava je, lahko jo poskušamo nekako rešiti. In preostali del poročila govori o tem problemu. Kakšno uspešnost lahko pričakujete od ClickHouse?
Kako ga bomo vstavili? MergeTree
Kdo od vas še ni slišal ali pozna za “ClickHouse”? Moram ti povedati, kajne? Zelo hitro. Vstavljanje tam je 1-2 gigabita na sekundo, izbruhi do 10 gigabitov na sekundo dejansko prenesejo to konfiguracijo - sta dva 6-jedrna Xeona (torej niti najmočnejši), 256 gigabajtov RAM-a, 20 terabajtov v RAID (nihče ni konfiguriral, privzete nastavitve). Alexey Milovidov, razvijalec ClickHouse, verjetno sedi in joka, ker nismo ničesar konfigurirali (pri nas je vse tako delovalo). V skladu s tem je mogoče doseči hitrost skeniranja na primer približno 6 milijard vrstic na sekundo, če so podatki dobro stisnjeni. Če vam je všeč % na besedilnem nizu - 100 milijonov vrstic na sekundo, se zdi precej hitro.
Kako ga bomo vstavili? No, veste, da VK uporablja PHP. Iz vsakega delavca PHP bomo vstavili prek HTTP v »ClickHouse« v tabelo MergeTree za vsak zapis. Kdo vidi problem v tej shemi? Iz neznanega razloga niso vsi dvignili rok. Naj vam povem.
Prvič, veliko je strežnikov - zato bo veliko povezav (slabih). Potem je bolje, da vstavite podatke v MergeTree največ enkrat na sekundo. In kdo ve zakaj? OK ok. Povedal vam bom nekaj več o tem. Še eno zanimivo vprašanje je, da ne delamo analitike, ni nam treba obogatiti podatkov, ne potrebujemo vmesnih strežnikov, želimo vstaviti direktno v "ClickHouse" (po možnosti - čim bolj direktno, tem bolje).
Kako torej poteka vstavljanje v MergeTree? Zakaj je bolje, da vanj vstavljate ne pogosteje kot enkrat na sekundo ali manj pogosto? Dejstvo je, da je “ClickHouse” stolpčna baza podatkov in razvršča podatke v naraščajočem vrstnem redu glede na primarni ključ, in ko naredite vstavljanje, se ustvari število datotek, ki je vsaj enako številu stolpcev, v katerih so razvrščeni podatki. v naraščajočem vrstnem redu primarnega ključa (ustvarjen je ločen imenik, nabor datotek na disku za vsak vstavek). Nato pride naslednji vstavek, v ozadju pa se združijo v večje »particije«. Ker so podatki razvrščeni, je možno "združiti" dve razvrščeni datoteki brez porabe veliko pomnilnika.
Toda, kot morda ugibate, če napišete 10 datotek za vsak vstavek, se bo ClickHouse (ali vaš strežnik) hitro končal, zato je priporočljivo vstavljanje v velikih serijah. Skladno s tem prve sheme nismo nikoli lansirali v proizvodnjo. Takoj smo lansirali eno, ki ima tukaj št. 2:
Predstavljajte si, da obstaja približno tisoč strežnikov, na katerih smo zagnali, obstaja samo PHP. In na vsakem strežniku je naš lokalni agent, ki smo ga poimenovali “Kittenhouse”, ki vzdržuje eno povezavo s “ClickHouse” in vnaša podatke vsakih nekaj sekund. Podatkov ne vstavi v MergeTree, temveč v medpomnilniško tabelo, ki služi prav temu, da se izogne takojšnjemu vstavljanju neposredno v MergeTree.
Delo z vmesnimi tabelami
Kaj je to? Vmesne tabele so del pomnilnika, ki je razdeljen (to pomeni, da ga je mogoče pogosto vstavljati vanj). Sestavljeni so iz več kosov in vsak del deluje kot neodvisen medpomnilnik in se splaknejo neodvisno (če imate v medpomnilniku veliko kosov, bo veliko vstavkov na sekundo). Iz teh tabel je mogoče brati - takrat berete združitev vsebine vmesnega pomnilnika in nadrejene tabele, vendar je v tem trenutku pisanje blokirano, zato je bolje, da ne berete od tam. In vmesne tabele kažejo zelo dober QPS, to je do 3 tisoč QPS pri vstavljanju sploh ne boste imeli težav. Jasno je, da če strežnik izgubi napajanje, se lahko podatki izgubijo, ker so bili le shranjeni v pomnilniku.
Hkrati pa shema z vmesnim pomnilnikom zaplete ALTER, ker morate najprej spustiti staro tabelo vmesnega pomnilnika s staro shemo (podatki ne bodo nikamor izginili, ker se bodo splaknili, preden bo tabela izbrisana). Nato "spremenite" tabelo, ki jo potrebujete, in znova ustvarite vmesno tabelo. Skladno s tem, medtem ko ni medpomnilniške tabele, vaši podatki ne bodo odtekli nikamor, vendar jih lahko imate na disku vsaj lokalno.
Kaj je Kittenhouse in kako deluje?
Kaj je KittenHouse? To je proxy. Uganete kateri jezik? V svojem poročilu sem zbral največ hype tem - "Clickhouse", Pojdi, morda se spomnim še česa. Da, to je napisano v Go, ker v resnici ne znam pisati v C, nočem.
V skladu s tem vzdržuje povezavo z vsakim strežnikom in lahko piše v pomnilnik. Na primer, če pišemo dnevnike napak v Clickhouse, potem, če Clickhouse nima časa za vstavljanje podatkov (navsezadnje, če je napisanega preveč), potem ne nabreknemo pomnilnika - ostalo preprosto vržemo ven. Ker če zapišemo več gigabitov na sekundo napak, potem jih verjetno lahko nekaj vržemo ven. Kittenhouse lahko to naredi. Poleg tega lahko izvaja zanesljivo dostavo, to je pisanje na disk na lokalnem računalniku in vsakič enkrat (tam enkrat na nekaj sekund) poskuša dostaviti podatke iz te datoteke. In sprva smo uporabljali običajni format vrednosti - ne nekega binarnega formata, besedilnega formata (kot v običajnem SQL).
Ampak potem se je to zgodilo. Uporabili smo zanesljivo dostavo, pisali dnevnike, se nato odločili (to je bila pogojna testna gruča) ... Za več ur je bila ugasnjena in ponovno vzpostavljena, vstavljanje pa se je začelo s tisoč strežnikov - izkazalo se je, da ima Clickhouse še vedno »Nit ob povezavi« - v skladu s tem v tisoč povezavah aktivna vstavitev povzroči povprečno obremenitev strežnika približno tisoč in pol. Presenetljivo je strežnik sprejel zahteve, vendar so bili podatki čez nekaj časa še vedno vstavljeni; vendar je bilo strežniku zelo težko postreči...
Dodajte nginx
Takšna rešitev za model Thread per connection je nginx. Namestili smo nginx pred Clickhouse, hkrati nastavili uravnoteženje za dve repliki (naša hitrost vstavljanja se je povečala za 2-krat, čeprav ni dejstvo, da bi moralo biti tako) in omejili število povezav na Clickhouse, na navzgor in s tem več , kot v 50 povezavah, se zdi, da nima smisla vstavljati.
Potem smo ugotovili, da ima ta shema na splošno slabosti, ker imamo tukaj samo en nginx. V skladu s tem, če se ta nginx zruši, kljub prisotnosti replik, izgubimo podatke ali vsaj ne pišemo nikamor. Zato smo izdelali lastno izravnavo obremenitve. Ugotovili smo tudi, da je »Clickhouse« še vedno primeren za hlode, in tudi »demon« je začel pisati svoje dnevnike v »Clickhouse« - zelo priročno, če sem iskren. Še vedno ga uporabljamo za druge »demone«.
Nato smo odkrili to zanimivo težavo: če uporabite nestandardno metodo vstavljanja v načinu SQL, vsili polnopravni razčlenjevalnik SQL, ki temelji na AST, kar je precej počasno. V skladu s tem smo dodali nastavitve, ki zagotavljajo, da se to nikoli ne zgodi. Naredili smo uravnoteženje obremenitve, zdravstvene preglede, tako da, če kdo umre, še vedno pustimo podatke. Zdaj imamo kar veliko tabel, ki jih potrebujemo za različne gruče Clickhouse. Začeli smo razmišljati tudi o drugih uporabah - na primer, želeli smo pisati dnevnike iz modulov nginx, vendar ne vedo, kako komunicirati z uporabo našega RPC. No, rad bi jih naučil vsaj nekako pošiljati - na primer prejemati dogodke na localhost preko UDP in jih potem posredovati Clickhouseu.
En korak stran od rešitve
Končna shema je začela izgledati takole (četrta različica te sheme): na vsakem strežniku pred Clickhouseom je nginx (na istem strežniku) in preprosto posreduje zahteve lokalnemu gostitelju z omejitvijo števila povezav 50. kosov. In ta shema je že precej delovala, z njo je bilo vse v redu.
Tako smo živeli kak mesec. Vsi so bili zadovoljni, dodajali so tabele, dodajali, dodajali ... Na splošno se je izkazalo, da način dodajanja medpomnilniških tabel ni ravno optimalen (recimo tako). Na vsaki mizi smo naredili 16 komadov in nekajsekundni presledek; imeli smo 20 miz in vsaka miza je prejela 8 vstavkov na sekundo - in na tej točki se je začela "Clickhouse" ... zapisi so se začeli upočasnjevati. Sploh niso šli skozi ... Nginx je imel privzeto tako zanimivo zadevo, da če se je povezava končala na zgornjem toku, je vsem novim zahtevam preprosto vrnil "502".
In tukaj imamo (pravkar sem pogledal dnevnike v sami Clickhouse) približno pol odstotka prošenj neuspešnih. Temu primerno je bila izkoriščenost diska visoka, združevanj je bilo veliko. No, kaj sem naredil? Seveda se nisem trudil ugotavljati, zakaj se je povezava in gorvodno končala.
Zamenjava nginxa z obratnim proxyjem
Odločil sem se, da moramo to urediti sami, ni nam treba prepustiti nginxu - nginx ne ve, katere tabele so v Clickhouseu, in nginx sem zamenjal z obratnim proxyjem, ki sem ga tudi sam napisal.
Kaj dela? Deluje na podlagi knjižnice fasthttp “goshnoy”, torej hitro, skoraj tako hitro kot nginx. Oprosti, Igor, če si prisoten tukaj (opomba: Igor Sysoev je ruski programer, ki je ustvaril spletni strežnik nginx). Lahko razume, kakšne vrste poizvedb so to – INSERT ali SELECT – v skladu s tem ima različna področja povezav za različne vrste poizvedb.
Skladno s tem, tudi če nimamo časa za dokončanje zahtev za vstavljanje, bodo "izberi" mimo in obratno. In združuje podatke v medpomnilniške tabele – z majhnim medpomnilnikom: če so bile kakšne napake, sintaksne napake itd. – tako da ne bi močno vplivale na ostale podatke, ker ko preprosto vstavimo v medpomnilniške tabele, imel majhen "bachi", in vse skladenjske napake so vplivale samo na ta majhen košček; in tukaj bodo že vplivali na velik medpomnilnik. Majhen je 1 megabajt, torej ni tako majhen.
Vstavljanje sinhronizacije in v bistvu zamenjava nginxa naredi v bistvu isto stvar, ki jo je nginx počel prej - za to vam ni treba spremeniti lokalne »Kittenhouse«. In ker uporablja fasthttp, je zelo hiter - naredite lahko več kot 100 tisoč zahtev na sekundo za posamezne vstavke prek obratnega posrednika. Teoretično lahko v povratni proxy kittenhouse vstavite eno vrstico naenkrat, vendar tega seveda ne počnemo.
Shema je začela izgledati takole: »Kittenhouse«, obratni proxy združuje številne zahteve v tabele, nato pa jih vmesne tabele vstavijo v glavne.
Killer je začasna rešitev, Kitten je trajna
To je zanimiv problem ... Ali je kdo od vas uporabljal fasthttp? Kdo je uporabljal fasthttp z zahtevami POST? Verjetno tega res ne bi smeli storiti, ker privzeto medpomni telo zahteve, naša velikost medpomnilnika pa je bila nastavljena na 16 megabajtov. Vstavljanje je na neki točki prenehalo slediti in 16-megabajtni kosi so začeli prihajati iz vseh deset tisoč strežnikov in vsi so bili medpomnilnik v pomnilniku, preden so bili poslani Clickhouseu. V skladu s tem je zmanjkalo pomnilnika, prišel je Out-Of-Of-Memory Killer in ubil obratni proxy (ali »Clickhouse«, ki bi teoretično lahko »pojedel« več kot obratni proxy). Cikel se je ponovil. Ni ravno prijetna težava. Čeprav smo na to naleteli šele po nekaj mesecih delovanja.
Kaj sem naredil? Še enkrat, res ne maram razumeti, kaj točno se je zgodilo. Mislim, da je precej očitno, da se ne bi smeli skrivati v spominu. Nisem mogel popraviti fasthttp, čeprav sem poskusil. Toda našel sem način, kako narediti tako, da ni bilo treba ničesar krpati, in prišel sem do lastne metode v HTTP - poimenoval sem jo KITTEN. No, logično je - "VK", "Kitten" ... Kaj še?..
Če pride zahteva do strežnika z metodo Kitten, potem bi se moral strežnik odzvati "meow" - logično. Če se na to odzove, potem se šteje, da razume ta protokol in potem prestrežem povezavo (fasthttp ima tako metodo) in povezava gre v “raw” način. Zakaj ga potrebujem? Želim nadzorovati, kako poteka branje iz povezav TCP. TCP ima čudovito lastnost: če nihče ne bere z druge strani, potem pisanje začne čakati in pomnilnik se za to ne porabi posebej.
In tako berem od približno 50 strank naenkrat (od petdeset, ker bi petdeset zagotovo moralo biti dovolj, tudi če je tarifa iz drugega DC) ... Poraba se je s tem pristopom zmanjšala vsaj 20-krat, jaz pa, če sem iskren , nisem mogel natančno izmeriti, koliko časa, ker je že nesmiselno (je že dosežena stopnja napake). Protokol je binarni, kar pomeni, da vsebuje ime tabele in podatke; ni glav http, zato nisem uporabil spletne vtičnice (ni mi treba komunicirati z brskalniki - naredil sem protokol, ki ustreza našim potrebam). In z njim je bilo vse v redu.
Tamponska miza je žalostna
Pred kratkim smo naleteli na še eno zanimivo lastnost vmesnih tabel. In ta težava je že veliko bolj boleča od ostalih. Predstavljajmo si to situacijo: že aktivno uporabljate Clickhouse, imate na desetine strežnikov Clickhouse in imate nekaj zahtev, ki trajajo zelo dolgo za branje (recimo več kot 60 sekund); in v tem trenutku prideš in narediš Alter ... Medtem »selecti«, ki so se začeli pred »Alter«, ne bodo vključeni v to tabelo, »Alter« se ne bo zagnal - verjetno nekatere značilnosti delovanja »Clickhouse« v to mesto. Mogoče se da to popraviti? Ali pa ni mogoče?
Na splošno je jasno, da v resnici to ni tako velik problem, vendar z vmesnimi tabelami postane bolj boleče. Kajti, če, recimo, poteče časovna omejitev vašega »Alterja« (in lahko poteče na drugem gostitelju - ne na vašem, ampak na replici, na primer), potem ... Izbrisali ste vmesno tabelo, svoj »Alter« ( ali kak drug gostitelj) je potekla časovna omejitev. potem je prišlo do napake »Spremeni«) - še vedno morate zagotoviti, da se podatki še naprej zapisujejo: nazaj ustvarite tabele vmesnega pomnilnika (v skladu z isto shemo kot nadrejena tabela), nato »Spremeni« gre skozi, navsezadnje se konča in vmesni pomnilnik tabele se začne razlikovati po shemi od nadrejenega. Odvisno od tega, kaj je bil »Sprememba«, vložek morda ne bo več šel v to vmesno tabelo - to je zelo žalostno.
Obstaja tudi tak znak (morda ga je kdo opazil) - v novih različicah Clickhouse se imenuje query_thread_log. Privzeto je bil v nekaterih različicah eden. Tukaj smo v nekaj mesecih nabrali 840 milijonov zapisov (100 gigabajtov). To je posledica dejstva, da so bili tam napisani "vložki" (morda zdaj, mimogrede, niso napisani). Kot sem vam rekel, so naši "vložki" majhni - imeli smo veliko "vložkov" v medpomnilniške tabele. Jasno je, da je to onemogočeno - samo povem vam, kar sem videl na našem strežniku. Zakaj? To je še en argument proti uporabi vmesnih tabel! Spotty je zelo žalosten.
Kdo je vedel, da je temu tipu ime Spotty? Zaposleni v VK so dvignili roke. V REDU.
O načrtih za “KitttenHouse”
Načrti se običajno ne delijo, kajne? Nenadoma jih ne boste izpolnili in v očeh drugih ljudi ne boste videti prav dobro. Ampak bom tvegal! Želimo narediti naslednje: medpomnilniške mize so, se mi zdi, še vedno bergla in moramo sami medpomniti vstavljanje. Vendar ga še vedno ne želimo medpomniti na disk, zato bomo vstavljanje shranili v medpomnilnik.
Skladno s tem, ko bo "vložek" narejen, ne bo več sinhron - že bo deloval kot tabela vmesnega pomnilnika, vstavil se bo v nadrejeno tabelo (no, nekega dne pozneje) in poročal prek ločenega kanala, kateri vstavitve so prešli in kateri nisem.
Zakaj ne morem zapustiti sinhronega vložka? To je veliko bolj priročno. Dejstvo je, da če vstaviš iz 10 tisoč gostiteljev, potem je vse v redu - od vsakega gostitelja boš dobil malo, tam vstaviš enkrat na sekundo, vse je v redu. Rad bi pa, da bi ta shema delovala, na primer, z dveh strojev, tako da lahko prenašate z veliko hitrostjo - morda ne bi dobili največ iz Clickhousea, vendar pišete vsaj 100 megabajtov na sekundo z enega stroja prek obratnega proxyja - to mora biti shema prilagojena tako velikim kot majhnim količinam, tako da ne moremo čakati niti sekunde za vsako vstavitev, zato mora biti asinhrona. In na enak način bi morale priti asinhrone potrditve po zaključku vstavljanja. Vedeli bomo, ali je minilo ali ne.
Najpomembneje je, da pri tej shemi zagotovo vemo, ali je do vstavitve prišlo ali ne. Predstavljajte si to situacijo: imate tabelo vmesnega pomnilnika, vanjo ste nekaj zapisali, potem pa je, recimo, tabela prešla v način samo za branje in poskušala izprazniti medpomnilnik. Kam bodo šli podatki? Ostali bodo v medpomnilniku. Vendar o tem ne moremo biti prepričani - kaj pa, če obstaja kakšna druga napaka, zaradi katere podatki ne bodo ostali v medpomnilniku ... (Naslovi Alexey Milovidov, Yandex, razvijalec ClickHouse) Ali pa bodo ostali? Nenehno? Aleksej nas prepričuje, da bo vse v redu. Nimamo razloga, da mu ne bi verjeli. Ampak vseeno: če ne uporabljamo vmesnih tabel, potem z njimi ne bo težav. Ustvarjanje dvakrat toliko tabel je tudi neprijetno, čeprav načeloma ni velikih težav. To je načrt.
Pogovorimo se o branju
Zdaj pa se pogovorimo o branju. Tukaj smo napisali tudi svoje orodje. Zdi se, no, zakaj bi tukaj napisali svoj inštrument?.. In kdo je uporabljal Tabix? Nekako malokdo je dvignil roke... In kdo je zadovoljen z delovanjem Tabixa? No, nismo zadovoljni z njim in ni zelo priročen za ogled podatkov. Za analitiko je v redu, samo za ogledovanje pa očitno ni optimizirano. Tako sem napisal svoj, svoj vmesnik.
Je zelo preprosta – lahko samo bere podatke. Ne zna pokazati grafike, ne zna narediti ničesar. Lahko pa pokaže, kaj potrebujemo: na primer, koliko vrstic je v tabeli, koliko prostora zavzame (brez razdelitve na stolpce), se pravi, zelo osnovni vmesnik je tisto, kar potrebujemo.
In izgleda zelo podobno Sequel Pro, vendar je narejeno samo na Twitterjevem Bootstrapu in drugi različici. Sprašujete: "Jurij, zakaj na drugi različici?" Katero leto? 2018? Na splošno sem to naredil precej dolgo nazaj za “Muscle” (MySQL) in samo spremenil nekaj vrstic v poizvedbah tam, in začelo je delovati za “Clickhouse”, za kar posebna hvala! Ker je razčlenjevalnik zelo podoben "mišičnemu" in poizvedbe so zelo podobne - zelo priročno, še posebej na začetku.
No, lahko filtrira tabele, lahko prikaže strukturo in vsebino tabele, omogoča razvrščanje, filtriranje po stolpcih, prikaže poizvedbo, ki je privedla do rezultata, prizadete vrstice (koliko rezultatov), tj. osnovne stvari za ogled podatkov. Precej hitro.
Obstaja tudi urednik. Pošteno sem poskušal Tabixu ukrasti celoten urejevalnik, a mi ni uspelo. Ampak nekako deluje. Načeloma je to vse.
"Clickhouse" je primeren za brloge
Želim vam povedati, da je Clickhouse kljub vsem opisanim težavam zelo primeren za hlode. Najpomembneje je, da rešuje naš problem - je zelo hiter in omogoča filtriranje dnevnikov po stolpcih. Načeloma se medpomnilniške tabele niso dobro obnesle, vendar običajno nihče ne ve zakaj ... Mogoče zdaj bolje veste, kje boste imeli težave.
TCP? Na splošno je v VK običajno uporabljati UDP. In ko sem uporabljal TCP ... Seveda mi nihče ni rekel: »Jurij, kaj govoriš! Ne morete, potrebujete UDP." Izkazalo se je, da TCP ni tako strašljiv. Edina stvar je, če imate na desettisoče aktivnih spojin, ki jih pišete, jih morate pripraviti malo bolj skrbno; vendar je možno in precej enostavno.
Obljubil sem, da bom objavil »Kittenhouse« in »Lighthouse« na HighLoad Siberia, če se vsi naročijo na naš javni »VK backend« ... In veste, niso vsi naročeni ... Seveda ne bom zahteval, da se naročite na naše javnosti. Še vedno vas je preveč, morda bo kdo celo užaljen, a vseeno se naročite (in tukaj moram narediti oči kot mačke). To je . Najlepša hvala! Github je naš . S Clickhouse bodo vaši lasje mehki in svilnati.
Svinec: - Prijatelji, zdaj pa vprašanja. Takoj ko podelimo zahvalo in vaše poročilo na VHS.
Jurij Nasretdinov (v nadaljevanju YN): – Kako ste lahko posneli moje poročilo na VHS, če se je pravkar končalo?
Svinec: – Tudi vi ne morete v celoti določiti, kako bo »Clickhouse« deloval ali ne! Prijatelji, 5 minut za vprašanja!
vprašanja
Vprašanje iz občinstva (v nadaljevanju Q): - Dober večer. Najlepša hvala za poročilo. Imam dve vprašanji. Začel bom z neresnim: ali število črk t v imenu "Kittenhouse" v diagramih (3, 4, 7 ...) vpliva na zadovoljstvo mačk?
YN: - Količina česa?
Z: – Črka t. Trije t-ji so, nekje trije t-ji.
YN: - Ali nisem popravil? No, seveda! Gre za različne izdelke – ves ta čas sem vas samo zavajal. V redu, hecam se - ni pomembno. Ah, tukaj! Ne, to je ista stvar, naredil sem tipkarsko napako.
Z: - Hvala vam. Drugo vprašanje je resno. Kolikor razumem, v Clickhouseu medpomnilniške tabele živijo izključno v pomnilniku, niso shranjene na disk in zato niso obstojne.
YN: - Da.
Z: – In hkrati vaš odjemalec medpomni na disk, kar pomeni nekaj jamstva za dostavo teh istih dnevnikov. A to pri Clickhouseu nikakor ni zagotovljeno. Pojasnite, kako se izvaja garancija, zaradi česa?.. Tukaj je ta mehanizem podrobneje
YN: – Da, teoretično tukaj ni nobenih protislovij, ker ko Clickhouse pade, lahko to dejansko zaznaš na milijon različnih načinov. Če se Clickhouse sesuje (če se nepravilno konča), lahko, grobo rečeno, previjete malo nazaj svoj dnevnik, ki ste ga zapisali, in začnete od trenutka, ko je bilo vse v redu. Recimo, da previjete minuto nazaj, se pravi, da se šteje, da ste v minuti vse splaknili.
Z: – To pomeni, da "Kittenhouse" dlje drži okno in ga v primeru padca lahko prepozna in previje nazaj?
YN: – Ampak to je v teoriji. V praksi tega ne izvajamo, zanesljiva dostava pa je od nič do neskončno krat. Ampak v povprečju ena. Zadovoljni smo, da če se Clickhouse iz nekega razloga zruši ali se strežniki »ponovno zaženejo«, malo izgubimo. V vseh drugih primerih se ne bo zgodilo nič.
Z: - Zdravo. Že od samega začetka se mi je zdelo, da boste res uporabljali UDP od samega začetka poročila. Imate http, vse to ... In kolikor razumem, je večino težav, ki ste jih opisali, povzročila ta rešitev ...
YN: – Kaj uporabljamo TCP?
Z: - V bistvu da.
YN: - Ne.
Z: – Težave ste imeli s fasthttpom, s povezavo ste imeli težave. Če bi pravkar uporabili UDP, bi si prihranili nekaj časa. No, težave bi bile z dolgimi sporočili ali kaj drugega...
YN: - S čim?
Z: – Z dolgimi sporočili, ker morda ne sodi v MTU, kaj drugega... No, lahko so sami problemi. Vprašanje je: zakaj ne UDP?
YN: – Verjamem, da so avtorji, ki so razvili TCP/IP, veliko pametnejši od mene in vedo bolje od mene, kako serializirati pakete (tako, da gredo), hkrati prilagoditi okno pošiljanja, ne preobremeniti omrežja, dati povratne informacije o tem, kaj se ne bere, ne računajoč na drugi strani... Vse te težave bi po mojem mnenju obstajale v UDP, le da bi moral napisati še več kode, kot sem jo že napisal, da bi sam implementiral isto stvar in najverjetneje slabo. Sploh ne maram pisanja v C, kaj šele tam ...
Z: - Samo priročno! Poslano v redu in ne čakajte ničesar - je popolnoma asinhrono. Vrnilo se je obvestilo, da je vse v redu – to pomeni, da je prišlo; Če ne pride, pomeni, da je slabo.
YN: – Potrebujem oboje – moram imeti možnost pošiljanja z garancijo dostave in brez garancije dostave. To sta dva različna scenarija. Nekaj dnevnikov ne smem izgubiti ali jih ne smem izgubiti v razumnem roku.
Z: – Ne bom izgubljal časa. O tem je treba več razpravljati. Hvala vam.
Svinec: – Kdor ima vprašanja – roke v nebo!
Z: - Pozdravljeni, jaz sem Sasha. Nekje na sredini poročila se je pojavil občutek, da je poleg TCP mogoče uporabiti že pripravljeno rešitev - nekakšno Kafko.
YN: – No ... rekel sem ti, da ne želim uporabljati vmesnih strežnikov, ker ... v Kafki se izkaže, da imamo deset tisoč gostiteljev; pravzaprav jih imamo več - na desettisoče gostiteljev. Lahko je tudi boleče delati s Kafko brez posrednikov. Poleg tega, kar je najpomembnejše, še vedno daje "zakasnitev", daje dodatne gostitelje, ki jih morate imeti. Ampak nočem jih imeti - hočem ...
Z: "A na koncu se je vseeno tako izkazalo."
YN: – Ne, ni gostiteljev! Vse to deluje na gostiteljih Clickhouse.
Z: - No, in "Kittenhouse", kar je obratno - kje živi?
YN: – Na gostitelju Clickhouse ne piše ničesar na disk.
Z: - Recimo.
Svinec: - Ali ste zadovoljni? Vam lahko damo plačo?
Z: - Ja lahko. Pravzaprav obstaja veliko bergel, da bi dobili isto stvar, in zdaj - prejšnji odgovor na temo TCP je po mojem mnenju v nasprotju s to situacijo. Zdi se mi, da bi lahko vse naredil na kolenih v veliko krajšem času.
YN: – In tudi zakaj nisem hotel uporabljati Kafke, ker je bilo v klepetalnici Clickhouse Telegram precej pritožb, da so se na primer sporočila Kafke izgubila. Ne od Kafke samega, ampak v integraciji Kafke in Clickhausa; ali tam nekaj ni bilo povezano. Grobo rečeno, takrat bi bilo treba napisati stranko za Kafko. Mislim, da preprostejše ali zanesljivejše rešitve ni.
Z: – Povejte mi, zakaj niste poskusili s čakalnimi vrstami ali kakšnim običajnim avtobusom? Ker pravite, da bi lahko z asinhronijo poslali same dnevnike skozi čakalno vrsto in prejeli odgovor asinhrono prek čakalne vrste?
YN: – Predlagajte, katere čakalne vrste bi lahko uporabili?
Z: – Katere koli, tudi brez garancije, da so v redu. Nekakšen Redis, RMQ...
YN: – Občutek imam, da Redis najverjetneje niti na enem hostu (v smislu več strežnikov) ne bo mogel potegniti takšnega obsega vstavljanja, ki vleče Clickhouse. Tega ne morem podpreti z nobenim dokazom (nisem primerjal), vendar se mi zdi, da Redis tukaj ni najboljša rešitev. Načeloma lahko ta sistem obravnavamo kot improvizirano čakalno vrsto sporočil, ki pa je prilagojena samo za »Clickhouse«
Svinec: – Jurij, najlepša hvala. Predlagam, da tukaj zaključimo vprašanja in odgovore in povemo, komu od tistih, ki so postavili vprašanje, bomo knjigo podarili.
YN: – Knjigo bi rad podaril prvemu, ki bi postavil vprašanje.
Svinec: - Čudovito! Super! Čudovito! Najlepša hvala!
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com