HighLoad++ Moskvo 2018, Kongresejo. 9-a de novembro, 15:00
Resumoj kaj prezento:
Yuri Nasretdinov (VKontakte): la raporto parolos pri la sperto de efektivigo de ClickHouse en nia kompanio - kial ni bezonas ĝin, kiom da datumoj ni stokas, kiel ni skribas ĝin, ktp.
Pliaj materialoj:
Jurij Nasretdinov: - Saluton al ĉiuj! Mi nomiĝas Jurij Nasretdinov, ĉar mi jam estis prezentita. Mi laboras ĉe VKontakte. Mi parolos pri kiel ni enmetas datumojn en ClickHouse de nia servila floto (dekoj da miloj).
Kio estas ŝtipoj kaj kial kolekti ilin?
Kion ni diros al vi: kion ni faris, kial ni bezonis "ClickHouse", respektive, kial ni elektis ĝin, kian agadon vi povas proksimume akiri sen agordi ion speciale. Mi rakontos al vi pli pri bufrotabloj, pri la problemoj, kiujn ni havis kun ili, kaj pri niaj solvoj, kiujn ni ellaboris el malferma fonto - KittenHouse kaj Lighthouse.
Kial ni bezonis fari ion ajn (ĉio ĉiam estas bona ĉe VKontakte, ĉu ne?). Ni volis kolekti sencimigajn protokolojn (kaj tie estis centoj da terabajtoj da datumoj), eble iel estus pli oportune kalkuli statistikojn; kaj ni havas aron de dekoj da miloj da serviloj, el kiuj ĉio ĉi devas esti farita.
Kial ni decidis? Ni verŝajne havis solvojn por konservi ŝtipojn. Ĉi tie - ekzistas tia publika "Backend VK". Mi tre rekomendas aboni ĝin.
Kio estas ŝtipoj? Ĉi tio estas motoro, kiu resendas malplenajn tabelojn. Motoroj en VK estas tio, kion aliaj nomas mikroservoj. Kaj jen ridetanta glumarko (sufiĉe multe da ŝatoj). Kiel? Nu, aŭskultu plu!
Kion oni povas uzi por konservi ŝtipojn? Estas neeble ne mencii Hadup. Tiam, ekzemple, Rsyslog (stokante ĉi tiujn protokolojn en dosieroj). LSDo. Kiu scias kio estas LSDo? Ne, ne ĉi tiu LSDo. Konservu dosierojn, respektive, ankaŭ. Nu, ClickHouse estas stranga opcio.
Clickhouse kaj konkurantoj: postuloj kaj ŝancoj
Kion ni volas? Ni volas certigi, ke ni ne devas tro zorgi pri la operacio, por ke ĝi funkciu el la skatolo, prefere kun minimuma agordo. Ni volas skribi multe, kaj skribi rapide. Kaj ni volas konservi ĝin dum ĉiaj monatoj, jaroj, tio estas, dum longa tempo. Ni eble volas kompreni iun problemon, kun kiu ili venis al ni kaj diris: "Io ne funkcias ĉi tie," kaj tio okazis antaŭ 3 monatoj), kaj ni volas povi vidi kio okazis antaŭ 3 monatoj " Datuma kunpremo - estas klare kial ĝi estus pluso - ĉar ĝi reduktas la kvanton de spaco, kiun ĝi okupas.
Kaj ni havas tian interesan postulon: ni foje skribas la eligon de iuj ordonoj (ekzemple protokoloj), ĝi povas esti pli ol 4 kilobajtoj sufiĉe facile. Kaj se ĉi tiu afero funkcias super UDP, tiam ĝi ne bezonas elspezi... ĝi ne havos ajnan "superkoston" por la konekto, kaj por granda nombro da serviloj ĉi tio estos pluso.
Ni vidu kion malferma fonto proponas al ni. Unue, ni havas la Logs Engine - ĉi tiu estas nia motoro; Principe, li povas fari ĉion, li povas eĉ skribi longajn liniojn. Nu, ĝi ne travideble kunpremas datumojn - ni mem povas kunpremi grandajn kolumnojn, se ni volas... ni, kompreneble, ne volas (se eble). La nura problemo estas, ke li povas nur fordoni tion, kio taŭgas en lia memoro; Por legi la reston, vi devas akiri la binlog de ĉi tiu motoro kaj, sekve, ĝi bezonas sufiĉe longan tempon.
Kiuj aliaj ebloj ekzistas? Ekzemple, "Hadup". Facileco de operacio... Kiu pensas, ke Hadup estas facile instalebla? Kompreneble, ne estas problemoj kun la registrado. Dum legado, demandoj foje aperas. Principe mi dirus verŝajne ne, precipe por ŝtipoj. Longtempa konservado - kompreneble, jes, datumpremado - jes, longaj ŝnuroj - estas klare, ke vi povas registri. Sed registrado de granda nombro da serviloj... Vi ankoraŭ devas fari ion mem!
Rsyslog. Fakte, ni uzis ĝin kiel rezervan opcion, por ke ni povu legi ĝin sen forĵeti la binlog, sed ĝi ne povas skribi longajn liniojn; principe ĝi ne povas skribi pli ol 4 kilobajtojn. Vi devas fari datumkunpremadon en la sama maniero mem. Legado venos el dosieroj.
Tiam estas la "badushka" evoluo de LSDo. Esence same kiel "Rsyslog": ĝi subtenas longajn ŝnurojn, sed ĝi ne povas funkcii per UDP kaj, fakte, pro tio, bedaŭrinde, sufiĉe multe da aferoj devas esti reverkitaj tie. LSDo devas esti restrukturita por povi registri de dekoj da miloj da serviloj.
Kaj jen! Amuza opcio estas ElasticSearch. Kiel diri? Li fartas bone pri legado, tio estas, li legas rapide, sed ne tre bone pri skribado. Unue, se ĝi kunpremas datumojn, ĝi estas tre malforta. Plej verŝajne, plena serĉo postulas pli grandajn datumstrukturojn ol la origina volumo. Ĝi estas malfacile funkcii kaj problemoj ofte aperas kun ĝi. Kaj, denove, registrado en Elastic - ni devas fari ĉion mem.
Ĉi tie ClickHouse estas ideala elekto, kompreneble. La sola afero estas, ke registrado de dekoj da miloj da serviloj estas problemo. Sed almenaŭ estas unu problemo, ni povas provi solvi ĝin iel. Kaj la resto de la raporto temas pri ĉi tiu problemo. Kian rendimenton vi povas atendi de ClickHouse?
Kiel ni enmetos ĝin? MergeTree
Kiu el vi ne aŭdis aŭ scias pri "ClickHouse"? Mi devas diri al vi, ĉu ne? Tre rapida. La enmeto tie - 1-2 gigabitoj sekundo, eksplodoj de ĝis 10 gigabitoj sekundo povas efektive elteni ĉi tiun agordon - estas du 6-kernaj Xeon (tio estas, eĉ ne la plej potenca), 256 gigabajtoj da RAM, 20 terabajtoj. en RAID (neniu agordis, defaŭltajn agordojn). Aleksej Milovidov, programisto de ClickHouse, verŝajne sidas tie plorante ĉar ni agordis nenion (ĉio funkciis tiel por ni). Sekve, skana rapido de, ekzemple, proksimume 6 miliardoj da linioj je sekundo povas esti akirita se la datumoj estas bone kunpremitaj. Se vi ŝatas % sur teksta ĉeno - 100 milionoj da linioj sekundo, tio estas, ĝi ŝajnas sufiĉe rapida.
Kiel ni enmetos ĝin? Nu, vi scias, ke VK uzas PHP. Ni enigos de ĉiu PHP-laboristo per HTTP en "ClickHouse", en la MergeTree-tabelon por ĉiu registro. Kiu vidas problemon kun ĉi tiu skemo? Ial, ne ĉiuj levis la manojn. Mi diru al vi.
Unue, estas multaj serviloj - sekve, estos multaj rilatoj (malbonaj). Tiam estas pli bone enigi datumojn en MergeTree ne pli ofte ol unufoje por sekundo. Kaj kiu scias kial? Bone, bone. Mi rakontos al vi iom pli pri tio. Alia interesa demando estas, ke ni ne faras analizojn, ni ne bezonas riĉigi la datumojn, ni ne bezonas mezajn servilojn, ni volas enmeti rekte en "ClickHouse" (prefere - ju pli rekte, des pli bone).
Sekve, kiel estas enmeto farita en MergeTree? Kial estas pli bone enigi ĝin ne pli ofte ol unufoje sekundon aŭ malpli ofte? La fakto estas, ke "ClickHouse" estas kolumna datumbazo kaj ordigas la datumojn laŭ kreskanta ordo de la ĉefa ŝlosilo, kaj kiam vi faras enmeton, kelkaj dosieroj estas kreitaj almenaŭ egala al la nombro da kolumnoj en kiuj la datumoj estas ordigitaj. en kreskanta ordo de la ĉefa ŝlosilo (estiĝas aparta dosierujo, aro da dosieroj sur disko por ĉiu enmetaĵo). Tiam venas la sekva enmeto, kaj en la fono ili estas kombinitaj en pli grandajn "sekciojn". Ĉar la datumoj estas ordigitaj, eblas "kunfandi" du ordigitajn dosierojn sen konsumi multe da memoro.
Sed, kiel vi povas supozi, se vi skribas 10 dosierojn por ĉiu enmetaĵo, tiam ClickHouse (aŭ via servilo) rapide finiĝos, do rekomendas enmeti en grandaj aroj. Sekve, ni neniam lanĉis la unuan skemon en produktadon. Ni tuj lanĉis unu, kiu ĉi tie n-ro 2 havas:
Jen imagu, ke estas ĉirkaŭ mil serviloj sur kiuj ni lanĉis, ekzistas nur PHP. Kaj sur ĉiu servilo estas nia loka agento, kiun ni nomis "Kittenhouse", kiu konservas unu konekton kun "ClickHouse" kaj enmetas datumojn ĉiujn kelkajn sekundojn. Enmetas datumojn ne en MergeTree, sed en bufran tabelon, kiu servas ĝuste por eviti tuj enmeti rekte en MergeTree.
Laborante kun bufrotabuloj
Kio ĝi estas? Bufrtabeloj estas peco de memoro kiu estas frakasita (tio estas, ĝi povas esti enmetita en ĝi ofte). Ili konsistas el pluraj pecoj, kaj ĉiu el la pecoj funkcias kiel sendependa bufro, kaj ili estas purigitaj sendepende (se vi havas multajn pecojn en la bufro, tiam estos multaj enmetoj sekundo). Eblas legi el ĉi tiuj tabeloj - tiam oni legas la kuniĝon de la enhavo de la bufro kaj la gepatra tabelo, sed en ĉi tiu momento la skribo estas blokita, do estas pli bone ne legi de tie. Kaj bufrotabloj montras tre bonan QPS, tio estas, ĝis 3 mil QPS vi tute ne havos problemojn dum enmetado. Estas klare, ke se la servilo perdas potencon, tiam la datumoj povas esti perditaj, ĉar ĝi estis nur konservita en memoro.
Samtempe, la skemo kun bufro malfaciligas ALTER, ĉar vi unue devas faligi la malnovan bufrotabelon kun la malnova skemo (la datumoj ne malaperos ie ajn, ĉar ĝi estos forigita antaŭ ol la tabelo estas forigita). Tiam vi "ŝanĝas" la tabelon, kiun vi bezonas kaj denove kreas la bufran tablon. Sekve, dum ne ekzistas bufrotabelo, viaj datumoj ne fluos ie ajn, sed vi povas havi ĝin sur disko almenaŭ loke.
Kio estas Kittenhouse kaj kiel ĝi funkcias?
Kio estas KittenHouse? Ĉi tio estas prokurilo. Divenu kian lingvon? Mi kolektis la plej furorajn temojn en mia raporto - "Clickhouse", Iru, eble mi rememoros ion alian. Jes, ĉi tio estas skribita en Go, ĉar mi ne vere scias kiel skribi en C, mi ne volas.
Sekve, ĝi konservas konekton kun ĉiu servilo kaj povas skribi al memoro. Ekzemple, se ni skribas erarajn protokolojn al Clickhouse, tiam se Clickhouse ne havas tempon por enmeti datumojn (finfine, se tro multe estas skribita), tiam ni ne ŝveligas la memoron - ni simple forĵetas la reston. Ĉar se ni skribas plurajn gigabitojn je sekundo da eraroj, tiam ni verŝajne povas elĵeti kelkajn. Kittenhouse povas fari tion. Krome, ĝi povas plenumi fidindan liveron, tio estas, skribi al disko sur la loka maŝino kaj unufoje ĉiun fojon (tie, unufoje ĉiun du sekundojn) ĝi provas liveri datumojn de ĉi tiu dosiero. Kaj komence ni uzis la regulan formaton de Valoroj - ne iun binaran formaton, tekstan formaton (kiel en regula SQL).
Sed tiam ĉi tio okazis. Ni uzis fidindan liveron, verkis protokolojn, poste decidis (ĝi estis kondiĉa testgrupo)... Ĝi estis eligita dum kelkaj horoj kaj reportita, kaj enmeto komenciĝis de mil serviloj - montriĝis, ke Clickhouse ankoraŭ havis "Fadeno pri konekto" - sekve, en mil konektoj, aktiva enmeto kondukas al ŝarĝo averaĝa sur la servilo de ĉirkaŭ unu kaj duono mil. Surprize, la servilo akceptis petojn, sed la datumoj ankoraŭ estis enmetitaj post iom da tempo; sed estis tre malfacile por la servilo servi ĝin...
Aldonu nginx
Tia solvo por la Fadeno per koneksa modelo estas nginx. Ni instalis nginx antaŭ Clickhouse, samtempe starigis ekvilibron por du kopioj (nia enmetrapideco pliiĝis je 2 fojojn, kvankam ne estas fakto, ke tio devus esti la kazo) kaj limigis la nombron da konektoj al Clickhouse, al la kontraŭflue kaj, sekve, pli , ol en 50 konektoj, ŝajnas ke ne utilas enmeti.
Tiam ni rimarkis, ke ĉi tiu skemo ĝenerale havas malavantaĝojn, ĉar ni havas nur unu nginx ĉi tie. Sekve, se ĉi tiu nginx kraŝas, malgraŭ la ĉeesto de kopioj, ni perdas datumojn aŭ, almenaŭ, ne skribas ie ajn. Tial ni faris nian propran ŝarĝbalancadon. Ni ankaŭ rimarkis, ke "Clickhouse" ankoraŭ taŭgas por ŝtipoj, kaj la "demono" ankaŭ komencis skribi siajn protokolojn en "Clickhouse" - tre oportuna, por esti honesta. Ni ankoraŭ uzas ĝin por aliaj "demonoj".
Tiam ni malkovris ĉi tiun interesan problemon: se vi uzas ne-norman metodon de enigo en SQL-reĝimo, ĝi devigas plenrajtan AST-bazitan SQL-annalizilon, kiu estas sufiĉe malrapida. Sekve, ni aldonis agordojn por certigi, ke tio neniam okazos. Ni faris ŝarĝbalancadon, sankontrolojn, tiel ke se oni mortas, ni ankoraŭ lasas la datumojn. Ni nun havas sufiĉe multajn tabelojn, kiujn ni bezonas por havi malsamajn Clickhouse-aretojn. Kaj ni ankaŭ komencis pensi pri aliaj uzoj - ekzemple, ni volis skribi protokolojn de nginx-moduloj, sed ili ne scias kiel komuniki per nia RPC. Nu, mi ŝatus instrui ilin kiel sendi almenaŭ iel - ekzemple ricevi eventojn ĉe localhost per UDP kaj poste plusendi ilin al Clickhouse.
Unu paŝon for de solvo
La fina skemo komencis aspekti tiel (la kvara versio de ĉi tiu skemo): sur ĉiu servilo antaŭ Clickhouse estas nginx (sur la sama servilo) kaj ĝi simple transdonas petojn al localhost kun limo de la nombro da konektoj de 50. pecoj. Kaj ĉi tiu skemo jam sufiĉe funkciis, ĉio estis sufiĉe bona kun ĝi.
Ni vivis tiel dum ĉirkaŭ unu monato. Ĉiuj estis feliĉaj, ili aldonis tabelojn, ili aldonis, ili aldonis... Ĝenerale, montriĝis, ke la maniero kiel ni aldonis bufrotablojn ne estis tre optimuma (ni diru tiel). Ni faris 16 pecojn en ĉiu tablo kaj fulmintervalo de kelkaj sekundoj; ni havis 20 tabelojn kaj ĉiu tablo ricevis 8 enmetojn sekundo - kaj ĉe ĉi tiu punkto "Clickhouse" komenciĝis... la rekordoj komencis malrapidiĝi. Ili eĉ ne trapasis... Nginx defaŭlte havis tian interesan aferon, ke se konektoj finiĝis ĉe la kontraŭfluo, tiam ĝi simple resendis "502" al ĉiuj novaj petoj.
Kaj ĉi tie ni havas (mi ĵus rigardis la protokolojn en Clickhouse mem) ĉirkaŭ duonprocento de petoj malsukcesis. Sekve, diskuzado estis alta, estis multaj kunfandoj. Nu, kion mi faris? Nature, mi ne ĝenis ekscii kial ĝuste la konekto kaj kontraŭfluo finiĝis.
Anstataŭigante nginx per inversa prokurilo
Mi decidis, ke ni devas administri ĉi tion mem, ni ne bezonas lasi ĝin al nginx - nginx ne scias, kiaj tabeloj estas en Clickhouse, kaj mi anstataŭigis nginx per inversa prokurilo, kiun mi ankaŭ skribis.
Kion li faras? Ĝi funkcias surbaze de la fasthttp biblioteko "goshnoy", tio estas, rapide, preskaŭ same rapide kiel nginx. Pardonu, Igor, se vi ĉeestas ĉi tie (noto: Igor Sysoev estas rusa programisto, kiu kreis la retservilon nginx). Ĝi povas kompreni kiajn demandojn ĉi tiuj estas - INSERT aŭ SELECT - sekve, ĝi enhavas malsamajn konektajn naĝejojn por malsamaj specoj de demandoj.
Sekve, eĉ se ni ne havas tempon por plenumi la enmetajn petojn, la "elektoj" pasos, kaj inverse. Kaj ĝi grupigas la datumojn en bufrotabelojn - kun malgranda bufro: se estus eraroj, sintaksaj eraroj, ktp - por ke ili ne multe influus la ceterajn datumojn, ĉar kiam ni simple enmetis en bufrotabelojn, ni havis malgrandan "bachi", kaj ĉiuj sintaksaj eraroj nur tuŝis ĉi tiun malgrandan pecon; kaj ĉi tie ili jam influos grandan bufron. Malgranda estas 1 megabajto, tio estas, ne tiom malgranda.
Enmeti sinkronigon kaj esence anstataŭigi nginx, faras esence la samon, kion faris nginx antaŭe - vi ne bezonas ŝanĝi la lokan "Kittenhouse" por ĉi tio. Kaj ĉar ĝi uzas fasthttp, ĝi estas tre rapida - vi povas fari pli ol 100 mil petojn sekundo por unuopaj enmetoj per inversa prokurilo. Teorie, vi povas enmeti unu linion samtempe en la inversan prokurilon de kittenhouse, sed kompreneble ni ne faras tion.
La skemo komencis aspekti jene: "Kittenhouse", la inversa prokurilo grupigas multajn petojn en tabelojn kaj, siavice, la bufraj tabeloj enmetas ilin en la ĉefajn.
Murdinto estas provizora solvo, Katido estas permanenta
Ĉi tio estas interesa problemo... Ĉu iu el vi uzis fasthttp? Kiu uzis fasthttp kun POST-petoj? Verŝajne, ĉi tio vere ne devus esti farita, ĉar ĝi bufras la peton defaŭlte, kaj nia bufrograndeco estis agordita al 16 megabajtoj. La enmeto ĉesis daŭrigi ĉe iu punkto, kaj 16-megabajtaj pecoj komencis alveni de ĉiuj dekoj de miloj da serviloj, kaj ili ĉiuj estis bufritaj en memoro antaŭ esti senditaj al Clickhouse. Sekve, la memoro elĉerpiĝis, la Out-Of-Memory Killer venis kaj mortigis la inversan prokurilon (aŭ "Clickhouse", kiu teorie povus "manĝi" pli ol la inversan prokurilon). La ciklo ripetiĝis. Ne tre agrabla problemo. Kvankam ni trafis ĉi tion nur post pluraj monatoj da operacio.
Kion mi faris? Denove, mi ne tre ŝatas kompreni kio ĝuste okazis. Mi pensas, ke estas sufiĉe evidente, ke vi ne devas memori. Mi ne povis fliki rapidehttp, kvankam mi provis. Sed mi trovis manieron fari ĝin tiel ke ne necesus fliki ion, kaj mi elpensis mian propran metodon en HTTP - mi nomis ĝin KITTEN. Nu, ĝi estas logika - "VK", "Katido"... Kio alia?...
Se peto venas al la servilo kun la metodo Kitten, tiam la servilo devus respondi "miaŭ" - logike. Se li respondas al ĉi tio, tiam oni konsideras, ke li komprenas ĉi tiun protokolon, kaj tiam mi kaptas la konekton (fasthttp havas tian metodon), kaj la konekto iras en "krudan" reĝimon. Kial mi bezonas ĝin? Mi volas kontroli kiel okazas legado de TCP-konektoj. TCP havas mirindan econ: se neniu legas de la alia flanko, tiam la skribo komencas atendi, kaj memoro ne estas precipe elspezita por tio.
Kaj do mi legas de proksimume 50 klientoj samtempe (de kvindek ĉar kvindek certe sufiĉu, eĉ se la kurzo venas de alia DC)... Konsumo malpliiĝis kun ĉi tiu aliro almenaŭ 20 fojojn, sed mi, sincere. , mi ne povis mezuri precize kioma horo, ĉar ĝi jam estas sencela (ĝi jam atingis la nivelon de eraro). La protokolo estas duuma, tio estas, ĝi enhavas la tabelnomon kaj datumojn; ne estas http-kapoj, do mi ne uzis TTT-konekton (mi ne bezonas komuniki kun retumiloj - mi faris protokolon, kiu konvenas al niaj bezonoj). Kaj ĉio fariĝis bona ĉe li.
La bufrotablo estas malĝoja
Lastatempe ni renkontis alian interesan funkcion de bufrotabuloj. Kaj ĉi tiu problemo jam estas multe pli dolora ol la aliaj. Ni imagu ĉi tiun situacion: vi jam aktive uzas Clickhouse, vi havas dekojn da Clickhouse-serviloj, kaj vi havas kelkajn petojn, kiuj bezonas tre longan tempon por legi (ni diru, pli ol 60 sekundoj); kaj vi venas kaj faru Ŝanĝi en ĉi tiu momento... Intertempe, "elektoj" kiuj komenciĝis antaŭ "Alter" ne estos inkluzivitaj en ĉi tiu tabelo, "Alter" ne komenciĝos - verŝajne kelkaj trajtoj de kiel "Clickhouse" funkcias en ĉi tiu loko. Eble ĉi tio povas esti riparita? Aŭ ĉu ne eblas?
Ĝenerale, estas klare, ke fakte ĉi tio ne estas tiom granda problemo, sed kun bufrotabloj ĝi fariĝas pli dolora. Ĉar, se, ni diru, viaj "Alter"-tempotempoj (kaj ĝi eble elĉerpas ĉe alia gastiganto - ne ĉe via, sed sur kopio, ekzemple), tiam... Vi forigis la bufrotabelon, vian "Alter" ( aŭ iu alia gastiganto) eksvalidiĝis. tiam okazis "Alter" eraro) - vi ankoraŭ devas certigi, ke la datumoj daŭre estas skribitaj: vi rekreas la bufrotabelojn (laŭ la sama skemo kiel la gepatra tabelo), tiam "Alter" iras tra, finiĝas finfine, kaj la bufro la tablo komencas diferenci en skemo de la gepatro. Depende de tio, kio estis la "Alter", la enmeto eble ne plu iros al ĉi tiu bufrotabelo - ĉi tio estas tre malĝoja.
Ankaŭ ekzistas tia signo (eble iu rimarkis ĝin) - ĝi nomiĝas query_thread_log en novaj versioj de Clickhouse. Defaŭlte, en iu versio estis unu. Ĉi tie ni amasigis 840 milionojn da diskoj en kelkaj monatoj (100 gigabajtoj). Ĉi tio estas pro tio, ke tie estis skribitaj "enmetoj" (eble nun, cetere, ili ne estas skribitaj). Kiel mi diris al vi, niaj "enigaĵoj" estas malgrandaj - ni havis multajn "enigaĵojn" en la bufrotablojn. Estas klare, ke ĉi tio estas malŝaltita - mi nur rakontas al vi tion, kion mi vidis sur nia servilo. Kial? Ĉi tio estas alia argumento kontraŭ uzado de bufrotabuloj! Spotty estas tre malĝoja.
Kiu sciis, ke la nomo de ĉi tiu ulo estas Spotty? VK-dungitoj levis la manojn. BONE.
Pri la planoj por "KitttenHouse"
Planoj kutime ne estas kunhavataj, ĉu ne? Subite vi ne plenumos ilin kaj ne tre bone aspektos en la okuloj de aliaj homoj. Sed mi riskos! Ni volas fari la jenon: bufrotabloj, ŝajnas al mi, ankoraŭ estas lambastono kaj ni devas mem bufrigi la enmeton. Sed ni ankoraŭ ne volas bufri ĝin sur disko, do ni bufros la enmeton en memoron.
Sekve, kiam "enmetaĵo" estas farita, ĝi ne plu estos sinkrona - ĝi jam funkcios kiel bufrotabelo, enmetos en la gepatran tabelon (nu, iam poste) kaj raportos per aparta kanalo kiuj enmetoj pasis kaj kiuj ne havas.
Kial mi ne povas forlasi la sinkronan enmeton? Estas multe pli oportune. La fakto estas, ke se vi enmetas el 10 mil gastigantoj, tiam ĉio estas en ordo - vi ricevos iomete de ĉiu gastiganto, vi enmetas tien unufoje sekundon, ĉio estas en ordo. Sed mi ŝatus, ke ĉi tiu skemo funkciu, ekzemple, de du maŝinoj, por ke vi povu elŝuti rapide - eble ne eltiri la maksimumon el Clickhouse, sed skribu almenaŭ 100 megabajtojn sekundo de unu maŝino per inversa prokurilo - ĉi tio la skemo devas grimpi al kaj grandaj kaj malgrandaj kvantoj, do ni ne povas atendi sekundon por ĉiu enmeto, do ĝi devas esti nesinkrona. Kaj same, nesinkronaj konfirmoj devus veni post kiam la enmeto finiĝis. Ni scios ĉu ĝi pasis aŭ ne.
La plej grava afero estas, ke en ĉi tiu skemo ni certe scias, ĉu la enmeto okazis aŭ ne. Imagu ĉi tiun situacion: vi havas bufro-tabelon, vi skribis ion en ĝin, kaj tiam, ni diru, la tablo eniris nurlegeblan reĝimon kaj provis forĵeti la bufron. Kien iros la datumoj? Ili restos en la bufro. Sed ni ne povas esti certaj pri tio - kio se estas iu alia eraro, pro kiu la datumoj ne restos en la bufro... (Adresas Alexey Milovidov, Yandex, ClickHouse-programisto) Aŭ ĉu ĝi restos? Ĉiam? Aleksej konvinkas nin, ke ĉio estos en ordo. Ni ne havas kialon ne kredi al li. Sed tute egale: se ni ne uzas bufrajn tabelojn, tiam ne estos problemoj kun ili. Krei duoble pli da tabeloj ankaŭ estas maloportuna, kvankam principe ne estas grandaj problemoj. Jen la plano.
Ni parolu pri legado
Nun ni parolu pri legado. Ni ankaŭ skribis nian propran ilon ĉi tie. Ŝajnus, nu, kial skribi vian propran instrumenton ĉi tie?.. Kaj kiu uzis Tabix? Iel malmultaj homoj levis la manojn... Kaj kiu estas kontenta pri la agado de Tabix? Nu, ni ne ĝojas pri ĝi, kaj ĝi ne estas tre oportuna por vidi datumojn. Estas bone por analizo, sed nur por spektado ĝi klare ne estas optimumigita. Do mi skribis mian propran, mian propran interfacon.
Ĝi estas tre simpla - ĝi povas legi nur datumojn. Li ne scipovas montri grafikaĵojn, li ne scias fari ion ajn. Sed ĝi povas montri kion ni bezonas: ekzemple, kiom da vicoj estas en la tabelo, kiom da spaco ĝi okupas (sen disrompi ĝin en kolumnojn), tio estas, tre baza interfaco estas kion ni bezonas.
Kaj ĝi aspektas tre simila al Sequel Pro, sed nur farita sur la Bootstrap de Twitter, kaj la dua versio. Vi demandas: "Jurij, kial en la dua versio?" Kiun jaron? 2018? Ĝenerale, mi faris tion antaŭ sufiĉe longa tempo por "Muskolo" (MySQL) kaj ĵus ŝanĝis kelkajn liniojn en la konsultoj tie, kaj ĝi ekfunkciis por "Clickhouse", pro kio specialan dankon! Ĉar la analizilo estas tre simila al la "muskolo", kaj la demandoj estas tre similaj - tre oportunaj, precipe komence.
Nu, ĝi povas filtri tabelojn, povas montri la strukturon kaj enhavon de la tabelo, permesas vin ordigi, filtri laŭ kolumnoj, montras la demandon, kiu rezultigis la rezulton, la tuŝitajn vicojn (kiom kiel rezulto), tio estas, la bazaj aferoj por vidi datumojn. Sufiĉe rapide.
Estas ankaŭ redaktoro. Mi sincere provis ŝteli la tutan redaktiston de Tabix, sed mi ne povis. Sed iel ĝi funkcias. Principe, jen ĉio.
"Clickhouse" taŭgas por densejoj
Mi volas diri al vi, ke Clickhouse, malgraŭ ĉiuj priskribitaj problemoj, tre bone taŭgas por ŝtipoj. Plej grave, ĝi solvas nian problemon - ĝi estas tre rapida kaj permesas al vi filtri protokolojn laŭ kolumnoj. Principe, bufrotabeloj ne bone funkciis, sed kutime neniu scias kial... Eble nun vi scias pli bone kie vi havos problemojn.
TCP? Ĝenerale, en VK kutimas uzi UDP. Kaj kiam mi uzis TCP... Kompreneble, neniu diris al mi: “Jurij, pri kio vi parolas! Vi ne povas, vi bezonas UDP." Montriĝis, ke TCP ne tiom timigas. La sola afero estas, se vi havas dekojn da miloj da aktivaj komponaĵoj, kiujn vi skribas, vi devas prepari ĝin iom pli zorge; sed ĝi estas ebla, kaj sufiĉe facila.
Mi promesis afiŝi “Kittenhouse” kaj “Lighthouse” ĉe HighLoad Siberia, se ĉiuj abonus nian publikan “VK-backend”... Kaj vi scias, ne ĉiuj abonis... Kompreneble, mi ne postulos, ke vi abonu nian. publiko. Ankoraŭ estas tro multaj el vi, iu eble eĉ ofendiĝos, sed tamen, bonvolu aboni (kaj ĉi tie mi devas fari okulojn kiel tiujn de kato). Tio estas . Dankegon! Github estas nia . Kun Clickhouse via hararo estos mola kaj silkeca.
Plumbo: - Amikoj, nun por demandoj. Tuj poste ni prezentas la atestilon pri aprezo kaj vian raporton pri VHS.
Jurij Nasretdinov (ĉi-poste nomata YN): – Kiel vi povis registri mian raporton en VHS, se ĝi ĵus finiĝis?
Plumbo: – Vi ankaŭ ne povas plene determini kiel "Clickhouse" funkcios aŭ ne! Amikoj, 5 minutojn por demandoj!
Viaj demandoj
Demando de la spektantaro (ĉi-poste nomata Q): - Bonan posttagmezon. Koran dankon pro la raporto. Mi havas du demandojn. Mi komencos per io frivola: ĉu la nombro da literoj t en la nomo "Katidejo" en la diagramoj (3, 4, 7...) influas la kontentigon de la katoj?
YN: - Kvanto de kio?
З: – Litero t. Estas tri t-oj, ie ĉirkaŭ tri t-oj.
YN: - Ĉu mi ne riparis ĝin? Nu, kompreneble jes! Ĉi tiuj estas malsamaj produktoj - mi nur trompis vin dum ĉi tiu tempo. Bone, mi ŝercas - ne gravas. Ah, ĝuste ĉi tie! Ne, estas la sama afero, mi faris eraron.
З: - Dankon. La dua demando estas serioza. Laŭ mia kompreno, en Clickhouse, bufrotabloj vivas ekskluzive en memoro, ne estas bufritaj al disko kaj, sekve, ne estas persistaj.
YN: - Jes.
З: – Kaj samtempe via kliento bufras al disko, kio implicas iun garantion pri livero de ĉi tiuj samaj protokoloj. Sed ĉi tio neniel estas garantiita ĉe Clickhouse. Klarigu kiel la garantio estas efektivigita, pro kio?.. Jen ĉi tiu mekanismo pli detale
YN: – Jes, teorie ĉi tie ne estas kontraŭdiroj, ĉar kiam Klakdomo falas, oni efektive povas detekti ĝin en miliono da malsamaj manieroj. Se Clickhouse kraŝas (se ĝi finiĝas malĝuste), vi povas, proksimume, rebobeni iom el via protokolo, kiun vi skribis, kaj komenci de la momento, kiam ĉio estis ĝuste en ordo. Ni diru, ke vi rebobenas minuton, tio estas, ke oni konsideras, ke vi purigis ĉion en minuto.
З: – Tio estas, “Kittenhouse” tenas la fenestron pli longe kaj, kaze de falo, povas rekoni ĝin kaj rebobeni ĝin?
YN: – Sed ĉi tio estas en teorio. En praktiko, ni ne faras tion, kaj fidinda livero estas de nul ĝis senfina tempoj. Sed averaĝe unu. Ni kontentas, ke se Clickhouse ial kraŝas aŭ la serviloj "reboot", tiam ni iomete perdas. En ĉiuj aliaj kazoj, nenio okazos.
З: - Saluton. Ekde la komenco ŝajnis al mi, ke vi ja uzos UDP ekde la komenco de la raporto. Vi havas http, ĉion ĉi... Kaj la plej multaj el la problemoj, kiujn vi priskribis, kiel mi komprenas, estis kaŭzitaj de ĉi tiu aparta solvo...
YN: – Kion ni uzas TCP?
З: - Esence jes.
YN: - Ne.
З: – Estis kun fasthttp ke vi havis problemojn, kun la konekto vi havis problemojn. Se vi ĵus uzis UDP, vi ŝparus al vi iom da tempo. Nu, estus problemoj kun longaj mesaĝoj aŭ io alia...
YN: - Kun kio?
З: – Kun longaj mesaĝoj, ĉar ĝi eble ne taŭgas en la MTU, io alia... Nu, eble estas propraj problemoj. La demando estas: kial ne UDP?
YN: – Mi kredas, ke la aŭtoroj, kiuj disvolvis TCP/IP, estas multe pli inteligentaj ol mi kaj scias pli bone ol mi kiel serigi pakaĵetojn (por ke ili iru), samtempe ĝustigi la sendan fenestron, ne troŝarĝi la reton, doni komentojn pri tio. ne estas legita, ne kalkulante je la alia flanko... Ĉiuj ĉi tiuj problemoj, laŭ mi, ekzistus en UDP, nur mi devus skribi eĉ pli da kodo ol mi jam skribis por efektivigi la samon mem kaj plej verŝajne. malbone. Mi eĉ ne tre ŝatas skribi en C, des malpli tie...
З: - Nur oportune! Sendita bone kaj atendu nenion - ĝi estas tute nesinkrona. Revenis sciigo, ke ĉio estas en ordo - tio signifas, ke ĝi alvenis; Se ĝi ne venas, tio signifas, ke ĝi estas malbona.
YN: – Mi bezonas ambaŭ – mi devas povi sendi ambaŭ kun garantio de livero kaj sen garantio de livero. Ĉi tiuj estas du malsamaj scenaroj. Mi bezonas ne perdi kelkajn ŝtipojn aŭ ne perdi ilin en racio.
З: – Mi ne perdos tempon. Ĉi tio devas esti diskutita pli. Dankon.
Plumbo: – Kiu havas demandojn – manojn al la ĉielo!
З: - Saluton, mi estas Sasha. Ie meze de la raporto aperis sento, ke krom TCP eblas uzi pretan solvon – ian Kafka.
YN: – Nu... mi diris al vi, ke mi ne volas uzi mezajn servilojn, ĉar... en Kafka, rezultas, ke ni havas dek mil gastigantojn; fakte ni havas pli – dekmiloj da gastigantoj. Ĝi ankaŭ povas esti dolora fari kun Kafka sen iuj prokuriloj. Krome, plej grave, ĝi ankoraŭ donas "latentecon", ĝi donas kromajn gastigantojn, kiujn vi bezonas havi. Sed mi ne volas havi ilin - mi volas...
З: "Sed finfine ĝi tamen rezultis tiel."
YN: – Ne, ne estas gastigantoj! Ĉi ĉio funkcias ĉe Clickhouse-gastigantoj.
З: - Nu, kaj "Kittenhouse", kio estas la inversa - kie li loĝas?
YN: – Sur la Clickhouse gastiganto, ĝi skribas nenion al la disko.
З: - Ni supozu.
Plumbo: – Ĉu vi estas kontenta? Ĉu ni povas doni al vi salajron?
З: - Jes vi povas. Fakte, estas multaj lambastonoj por akiri la samon, kaj nun - la antaŭa respondo pri la temo de TCP kontraŭdiras, laŭ mi, ĉi tiun situacion. Ĝi nur sentas, ke ĉio povus esti farita sur miaj genuoj en multe malpli da tempo.
YN: – Kaj ankaŭ kial mi ne volis uzi Kafka, ĉar estis sufiĉe multe da plendoj en la babilejo de Clickhouse Telegram ke, ekzemple, mesaĝoj de Kafka estis perditaj. Ne de Kafka mem, sed en la integriĝo de Kafka kaj Clickhaus; aŭ io ne kunligis tie. Malglate, necesus tiam skribi klienton por Kafka. Mi ne pensas, ke povus esti pli simpla aŭ pli fidinda solvo.
З: – Diru al mi, kial vi ne provis iujn vicojn aŭ ian komunan buson? Ĉar vi diras, ke kun malsinkronio vi povus sendi la protokolojn mem tra la atendovico kaj ricevi la respondon nesinkrone tra la atendovico?
YN: – Bonvolu sugesti, kiajn vicojn oni povus uzi?
З: – Ajna, eĉ sen garantio, ke ili estas en ordo. Ia Redis, RMQ...
YN: – Mi havas la senton, ke Redis plej verŝajne ne povos tiri tian volumon de enmeto eĉ sur unu gastiganto (en la senco de pluraj serviloj), kiu eltiras Clickhouse. Mi ne povas subteni ĉi tion per ajna indico (mi ne komparmarkis ĝin), sed ŝajnas al mi ke Redis ne estas la plej bona solvo ĉi tie. Principe, ĉi tiu sistemo povas esti konsiderata kiel improvizita mesaĝvico, sed kiu estas tajlorita nur por "Clickhouse"
Plumbo: – Jurij, koran dankon. Mi proponas fini la demandojn kaj respondojn ĉi tie kaj diri al kiu el tiuj, kiuj faris la demandon, ni donos la libron.
YN: – Mi ŝatus doni libron al la unua persono, kiu faris demandon.
Plumbo: - Mirinde! Bonege! Mirinda! Multaj dankoj!
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com