HighLoad++ Moskou 2018, Kongressaal. 9 November, 15:00
Opsommings en aanbieding:
Yuri Nasretdinov (VKontakte): die verslag sal praat oor die ervaring van die implementering van ClickHouse in ons maatskappy - hoekom ons dit nodig het, hoeveel data ons stoor, hoe ons dit skryf, ensovoorts.
Bykomende materiale:
Yuri Nasretdinov: - Hi almal! My naam is Yuri Nasretdinov, soos ek reeds voorgestel is. Ek werk by VKontakte. Ek sal praat oor hoe ons data vanaf ons bedienervloot (tienduisende) in ClickHouse invoeg.
Wat is logs en hoekom versamel hulle?
Wat ons jou sal vertel: wat ons gedoen het, hoekom ons "ClickHouse" nodig gehad het, onderskeidelik, hoekom ons dit gekies het, watter soort prestasie jy ongeveer kan kry sonder om iets spesiaals op te stel. Ek sal jou verder vertel van buffertabelle, van die probleme wat ons daarmee gehad het en van ons oplossings wat ons uit oopbron ontwikkel het - KittenHouse en Lighthouse.
Hoekom moes ons hoegenaamd iets doen (alles is altyd goed op VKontakte, reg?). Ons wou ontfoutingslogboeke versamel (en daar was honderde teragrepe data daar), miskien sou dit op een of ander manier geriefliker wees om statistieke te bereken; en ons het 'n vloot van tienduisende bedieners waarvandaan dit alles gedoen moet word.
Hoekom het ons besluit? Ons het waarskynlik oplossings gehad vir die stoor van logs. Hier - daar is so 'n publieke "Backend VK". Ek beveel sterk aan om daarop in te teken.
Wat is logs? Dit is 'n enjin wat leë skikkings terugstuur. Enjins in VK is wat ander mikrodienste noem. En hier is 'n glimlaggende plakker (nogal baie likes). Hoe so? Wel, luister verder!
Wat kan gebruik word om logs te stoor? Dit is onmoontlik om nie van Hadup te praat nie. Dan, byvoorbeeld, Rsyslog (berging van hierdie logs in lêers). LSD. Wie weet wat LSD is? Nee, nie hierdie LSD nie. Stoor lêers ook onderskeidelik. Wel, ClickHouse is 'n vreemde opsie.
Klikhuis en mededingers: vereistes en geleenthede
Wat wil ons hê? Ons wil verseker dat ons nie te veel oor die operasie hoef te bekommer nie, sodat dit uit die boks werk, verkieslik met minimale konfigurasie. Ons wil baie skryf, en vinnig skryf. En ons wil dit vir allerhande maande, jare, dit wil sê vir 'n lang tyd hou. Ons wil dalk een of ander probleem verstaan waarmee hulle na ons toe gekom het en gesê het: "Iets werk nie hier nie," en dit was 3 maande gelede), en ons wil in staat wees om te sien wat 3 maande gelede gebeur het. Datakompressie - dit is duidelik hoekom dit 'n pluspunt sal wees - want dit verminder die hoeveelheid spasie wat dit opneem.
En ons het so 'n interessante vereiste: ons skryf soms die uitvoer van sommige opdragte (byvoorbeeld logs), dit kan redelik maklik meer as 4 kilogrepe wees. En as hierdie ding oor UDP werk, hoef dit nie te spandeer nie ... dit sal geen "bokoste" vir die verbinding hê nie, en vir 'n groot aantal bedieners sal dit 'n pluspunt wees.
Kom ons kyk wat oopbron ons bied. Eerstens het ons die Logs Engine - dit is ons enjin; In beginsel kan hy alles doen, hy kan selfs lang reëls skryf. Wel, dit komprimeer nie data deursigtig nie - ons kan self groot kolomme saampers as ons wil ... ons wil natuurlik nie (indien moontlik). Die enigste probleem is dat hy net kan weggee wat in sy geheue pas; Om die res te lees, moet jy die binlog van hierdie enjin kry en gevolglik neem dit nogal lank.
Watter ander opsies is daar? Byvoorbeeld, "Hadup". Gebruiksgemak ... Wie dink dat Hadup maklik is om op te stel? Natuurlik is daar geen probleme met die opname nie. Tydens lees duik daar soms vrae op. In beginsel sou ek sê waarskynlik nie, veral vir stompe. Langtermynberging - natuurlik, ja, datakompressie - ja, lang stringe - dit is duidelik dat jy kan opneem. Maar opname vanaf 'n groot aantal bedieners ... Jy moet nog iets self doen!
Rsyslog. Trouens, ons het dit as 'n rugsteunopsie gebruik sodat ons dit kon lees sonder om die binlog te stort, maar dit kan nie lang reëls skryf nie, in beginsel kan dit nie meer as 4 kilogrepe skryf nie. Jy moet datakompressie op dieselfde manier self doen. Lees sal uit lêers kom.
Dan is daar die "badushka" ontwikkeling van LSD. In wese dieselfde as “Rsyslog”: dit ondersteun lang stringe, maar dit kan nie via UDP werk nie en om die waarheid te sê, as gevolg hiervan, moet daar ongelukkig baie dinge oorgeskryf word. LSD moet herontwerp word om vanaf tienduisende bedieners op te neem.
En hier! 'n Snaakse opsie is ElasticSearch. Hoe om te sê? Hy vaar goed met lees, dit wil sê hy lees vinnig, maar nie baie goed met skryf nie. Eerstens, as dit data saampers, is dit baie swak. Heel waarskynlik vereis 'n volledige soektog groter datastrukture as die oorspronklike volume. Dit is moeilik om te bedryf en probleme ontstaan dikwels daarmee. En, weer, opname in Elastic - ons moet alles self doen.
Hier is ClickHouse natuurlik 'n ideale opsie. Die enigste ding is dat opname van tienduisende bedieners 'n probleem is. Maar daar is ten minste een probleem, ons kan dit op een of ander manier probeer oplos. En die res van die verslag handel oor hierdie probleem. Watter soort prestasie kan jy van ClickHouse verwag?
Hoe gaan ons dit insit? MergeTree
Wie van julle het nog nie gehoor of weet van "ClickHouse" nie? Ek moet jou vertel, nie waar nie? Baie vinnig. Die invoeging daar - 1-2 gigabit per sekonde, sarsies van tot 10 gigabit per sekonde kan eintlik hierdie konfigurasie weerstaan - daar is twee 6-kern Xeons (dit wil sê nie eers die kragtigste nie), 256 gigagrepe RAM, 20 teragrepe in RAID (niemand gekonfigureer nie, verstekinstellings). Alexey Milovidov, ClickHouse-ontwikkelaar, sit waarskynlik daar en huil, want ons het niks opgestel nie (alles het so vir ons gewerk). Gevolglik kan 'n skanderingspoed van byvoorbeeld sowat 6 miljard reëls per sekonde verkry word as die data goed saamgepers is. As jy wel % op 'n teksstring hou - 100 miljoen reëls per sekonde, dit wil sê, dit lyk redelik vinnig.
Hoe gaan ons dit insit? Wel, jy weet dat VK PHP gebruik. Ons sal van elke PHP-werker via HTTP in "ClickHouse" invoeg, in die MergeTree-tabel vir elke rekord. Wie sien 'n probleem met hierdie skema? Om een of ander rede het nie almal hul hande opgesteek nie. Laat ek jou vertel.
Eerstens is daar baie bedieners - gevolglik sal daar baie verbindings (sleg) wees. Dan is dit beter om data nie meer gereeld as een keer per sekonde in MergeTree in te voeg nie. En wie weet hoekom? Okay okay. Ek sal jou 'n bietjie meer hieroor vertel. Nog 'n interessante vraag is dat ons nie analise doen nie, ons hoef nie die data te verryk nie, ons het nie intermediêre bedieners nodig nie, ons wil direk in "ClickHouse" invoeg (verkieslik - hoe meer direk, hoe beter).
Gevolglik, hoe word invoeging in MergeTree gedoen? Hoekom is dit beter om nie meer gereeld as een keer per sekonde of minder gereeld daarin in te voeg nie? Die feit is dat "ClickHouse" 'n kolomdatabasis is en die data in stygende volgorde van die primêre sleutel sorteer, en wanneer jy 'n invoeging doen, word 'n aantal lêers geskep wat minstens gelyk is aan die aantal kolomme waarin die data gesorteer is in stygende volgorde van die primêre sleutel ('n aparte gids word geskep, 'n stel lêers op skyf vir elke insetsel). Dan kom die volgende invoeging, en in die agtergrond word hulle gekombineer in groter "partisies". Aangesien die data gesorteer is, is dit moontlik om twee gesorteerde lêers te "samevoeg" sonder om baie geheue te verbruik.
Maar, soos jy dalk kan raai, as jy 10 lêers vir elke insetsel skryf, sal ClickHouse (of jou bediener) vinnig eindig, so dit word aanbeveel om in groot bondels in te voeg. Gevolglik het ons nooit die eerste skema in produksie bekend gestel nie. Ons het dadelik een bekendgestel, wat hier nr. 2 het:
Stel jou voor dat daar ongeveer 'n duisend bedieners is waarop ons van stapel gestuur het, daar is net PHP. En op elke bediener is daar ons plaaslike agent, wat ons "Kittenhouse" genoem het, wat een verbinding met "ClickHouse" behou en data elke paar sekondes invoeg. Voeg data nie in MergeTree in nie, maar in 'n buffertabel, wat presies dien om te verhoed dat dit dadelik direk in MergeTree ingevoeg word.
Werk met buffertabelle
Wat dit is? Buffertabelle is 'n stukkie geheue wat versnipper word (dit wil sê, dit kan gereeld daarin geplaas word). Hulle bestaan uit verskeie stukke, en elkeen van die stukke werk as 'n onafhanklike buffer, en hulle word onafhanklik gespoel (as jy baie stukke in die buffer het, dan sal daar baie invoegings per sekonde wees). Dit is moontlik om uit hierdie tabelle te lees - dan lees jy die vereniging van die inhoud van die buffer en die ouertabel, maar op hierdie oomblik is die skryf geblokkeer, dus is dit beter om nie daarvandaan te lees nie. En buffertabelle toon baie goeie QPS, dit wil sê, tot 3 duisend QPS sal jy glad nie probleme hê wanneer jy invoeg nie. Dit is duidelik dat as die bediener krag verloor, dan kan die data verlore gaan, want dit is net in die geheue gestoor.
Terselfdertyd kompliseer die skema met 'n buffer ALTER, want jy moet eers die ou buffertabel met die ou skema laat val (die data sal nêrens verdwyn nie, want dit sal gespoel word voordat die tabel uitgevee word). Dan "verander" jy die tabel wat jy nodig het en skep weer die buffertabel. Gevolglik, terwyl daar geen buffertabel is nie, sal u data nêrens heen vloei nie, maar u kan dit ten minste plaaslik op die skyf hê.
Wat is Kittenhouse en hoe werk dit?
Wat is KittenHouse? Dit is 'n volmag. Raai watter taal? Ek het die meeste hype-onderwerpe in my verslag versamel - "Clickhouse", Gaan, miskien sal ek iets anders onthou. Ja, dit is in Go geskryf, want ek weet nie regtig hoe om in C te skryf nie, ek wil nie.
Gevolglik behou dit 'n verbinding met elke bediener en kan dit na die geheue skryf. Byvoorbeeld, as ons foutlogs na Clickhouse skryf, dan as Clickhouse nie tyd het om data in te voeg nie (as daar immers te veel geskryf is), dan swel ons nie die geheue nie - ons gooi eenvoudig die res uit. Want as ons verskeie gigabits per sekonde van foute skryf, dan kan ons waarskynlik sommige uitgooi. Kittenhouse kan dit doen. Boonop kan dit betroubare aflewering uitvoer, dit wil sê, skryf na skyf op die plaaslike masjien en een keer elke keer (daar, een keer elke paar sekondes) probeer dit om data van hierdie lêer af te lewer. En aanvanklik het ons die gewone waardes-formaat gebruik - nie 'n binêre formaat nie, 'n teksformaat (soos in gewone SQL).
Maar toe gebeur dit. Ons het betroubare aflewering gebruik, logs geskryf, toe besluit (dit was 'n voorwaardelike toetsgroep)... Dit is vir 'n paar uur uitgesit en teruggebring, en 'n invoeging het vanaf 'n duisend bedieners begin - dit het geblyk dat Clickhouse steeds 'n "Draad op verbinding" - gevolglik, in 'n duisend verbindings, lei 'n aktiewe invoeging tot 'n las gemiddelde op die bediener van ongeveer een en 'n half duisend. Verbasend genoeg het die bediener versoeke aanvaar, maar die data is na 'n geruime tyd steeds ingevoeg; maar dit was baie moeilik vir die bediener om dit te bedien ...
Voeg nginx by
So 'n oplossing vir die Thread per connection model is nginx. Ons het nginx voor Clickhouse geïnstalleer, terselfdertyd balansering vir twee replikas opgestel (ons invoegspoed het met 2 keer toegeneem, alhoewel dit nie 'n feit is dat dit die geval moet wees nie) en het die aantal verbindings na Clickhouse beperk, tot die stroomop en, dienooreenkomstig, meer as in 50 verbindings, lyk dit of daar geen punt is om in te voeg nie.
Toe het ons besef dat hierdie skema oor die algemeen nadele het, want ons het net een nginx hier. Gevolglik, as hierdie nginx ineenstort, ten spyte van die teenwoordigheid van replikas, verloor ons data of skryf ons ten minste nêrens nie. Daarom het ons ons eie vragbalansering gemaak. Ons het ook besef dat "Clickhouse" steeds geskik is vir logs, en die "demoon" het ook sy logs in "Clickhouse" begin skryf - baie gerieflik, om eerlik te wees. Ons gebruik dit steeds vir ander "duiwels".
Toe ontdek ons hierdie interessante probleem: as jy 'n nie-standaard metode gebruik om in SQL-modus in te voeg, dwing dit 'n volwaardige AST-gebaseerde SQL-ontleder, wat redelik stadig is. Gevolglik het ons instellings bygevoeg om te verseker dat dit nooit gebeur nie. Ons het lasbalansering, gesondheidsondersoeke gedoen, sodat as een sterf, ons steeds die data los. Ons het nou nogal baie tafels wat ons nodig het om verskillende Clickhouse-klusters te hê. En ons het ook aan ander gebruike begin dink - ons wou byvoorbeeld logs van nginx-modules skryf, maar hulle weet nie hoe om met ons RPC te kommunikeer nie. Wel, ek wil hulle graag leer hoe om ten minste op een of ander manier te stuur - byvoorbeeld om gebeurtenisse op localhost via UDP te ontvang en dit dan na Clickhouse aan te stuur.
Een stap weg van oplossing
Die finale skema het so begin lyk (die vierde weergawe van hierdie skema): op elke bediener voor Clickhouse is daar nginx (op dieselfde bediener) en dit stuur eenvoudig versoeke na localhost met 'n beperking op die aantal verbindings van 50 stukke. En hierdie skema het reeds redelik gewerk, alles was redelik goed daarmee.
Ons het so 'n maand lank geleef. Almal was gelukkig, hulle het tabelle bygevoeg, hulle het bygevoeg, hulle het bygevoeg ... Oor die algemeen het dit geblyk dat die manier waarop ons buffertabelle bygevoeg het nie baie optimaal was nie (kom ons stel dit so). Ons het 16 stukke in elke tabel gedoen en 'n flitsinterval van 'n paar sekondes; ons het 20 tafels gehad en elke tafel het 8 insetsels per sekonde ontvang - en op hierdie stadium het “Clickhouse” begin... die rekords het begin verlangsaam. Hulle het nie eers deurgegaan nie ... Nginx het by verstek so 'n interessante ding gehad dat as verbindings by die stroomop geëindig het, dan het dit eenvoudig "502" teruggestuur na alle nuwe versoeke.
En hier het ons (ek het net na die logs in Clickhouse self gekyk) ongeveer 'n halwe persent van die versoeke het misluk. Gevolglik was skyfbenutting hoog, daar was baie samesmeltings. Wel, wat het ek gedoen? Ek het natuurlik nie die moeite gedoen om uit te vind hoekom presies die verbinding en stroomop geëindig het nie.
Vervang nginx met 'n omgekeerde instaanbediener
Ek het besluit dat ons dit self moet bestuur, ons hoef dit nie aan nginx oor te laat nie - nginx weet nie watter tabelle daar in Clickhouse is nie, en ek het nginx vervang met 'n omgekeerde proxy, wat ek ook self geskryf het.
Wat doen hy? Dit werk gebaseer op die fasthttp-biblioteek "goshnoy", dit wil sê vinnig, amper so vinnig soos nginx. Jammer, Igor, as jy hier teenwoordig is (let wel: Igor Sysoev is 'n Russiese programmeerder wat die nginx-webbediener geskep het). Dit kan verstaan watter soort navrae dit is - INSERT of SELECT - dienooreenkomstig hou dit verskillende verbindingspoele vir verskillende tipes navrae.
Gevolglik, selfs al het ons nie tyd om die invoegingversoeke te voltooi nie, sal die "selektes" slaag, en omgekeerd. En dit groepeer die data in buffertabelle - met 'n klein buffer: as daar enige foute, sintaksfoute, ensovoorts was - sodat dit nie die res van die data grootliks sou beïnvloed nie, want wanneer ons bloot in buffertabelle ingevoeg het, het ons klein "bachi" gehad, en al die sintaksfoute het slegs hierdie klein stukkie beïnvloed; en hier sal hulle reeds 'n groot buffer beïnvloed. Klein is 1 megagreep, dit wil sê nie so klein nie.
Om 'n sinchronisasie in te voeg en in wese nginx te vervang, doen in wese dieselfde ding as wat nginx voorheen gedoen het - jy hoef nie die plaaslike "Katjieshuis" hiervoor te verander nie. En aangesien dit fasthttp gebruik, is dit baie vinnig - jy kan meer as 100 duisend versoeke per sekonde maak vir enkele invoegings deur 'n omgekeerde instaanbediener. Teoreties kan jy een reël op 'n slag in die kittenhouse reverse proxy invoeg, maar natuurlik doen ons dit nie.
Die skema het soos volg begin lyk: "Katjieshuis", die omgekeerde proxy groepeer baie versoeke in tabelle en op sy beurt voeg die buffertabelle dit in die belangrikste in.
Killer is 'n tydelike oplossing, Kitten is permanent
Dit is 'n interessante probleem... Het enige van julle al fasthttp gebruik? Wie het fasthttp met POST-versoeke gebruik? Dit moes waarskynlik nie gedoen word nie, want dit buffer die versoekliggaam by verstek, en ons buffergrootte is op 16 megagrepe gestel. Die invoeging het op 'n stadium opgehou om by te hou, en 16-megagreep-stukke het vanaf al tienduisende bedieners begin aankom, en hulle is almal in die geheue gebuffer voordat dit na Clickhouse gestuur is. Gevolglik het die geheue opgeraak, die Out-Of-Memory Killer het gekom en die reverse proxy (of "Clickhouse", wat teoreties meer kon "eet" as die reverse proxy) doodgemaak. Die siklus het homself herhaal. Nie 'n baie aangename probleem nie. Alhoewel ons dit eers na 'n paar maande se operasie raakgeloop het.
Wat ek gedoen het? Weereens, ek hou nie regtig daarvan om te verstaan wat presies gebeur het nie. Ek dink dit is redelik duidelik dat jy nie in die geheue moet buffer nie. Ek kon nie fasthttp pleister nie, alhoewel ek probeer het. Maar ek het 'n manier gevind om dit so te maak dat dit nie nodig was om iets te pleister nie, en ek het met my eie metode in HTTP vorendag gekom - ek het dit KITTEN genoem. Wel, dit is logies - "VK", "Katjie" ... Wat anders? ..
As 'n versoek na die bediener kom met die Kitten-metode, moet die bediener "miaau" reageer - logies. As hy hierop reageer, word dit beskou dat hy hierdie protokol verstaan, en dan onderskep ek die verbinding (fasthttp het so 'n metode), en die verbinding gaan in "rou" modus. Hoekom het ek dit nodig? Ek wil beheer hoe lees vanaf TCP-verbindings plaasvind. TCP het 'n wonderlike eienskap: as niemand van die ander kant af lees nie, begin die skryfwerk wag, en geheue word nie besonder hieraan bestee nie.
En so lees ek van so 50 kliënte op 'n slag (vanaf vyftig want vyftig behoort beslis genoeg te wees, al kom die koers van 'n ander DC)... Verbruik het met hierdie benadering ten minste 20 keer afgeneem, maar ek, om eerlik te wees , Ek kon nie presies meet hoe laat nie, want dit is reeds sinloos (dit het reeds die vlak van fout bereik). Die protokol is binêr, dit wil sê dit bevat die tabelnaam en data; daar is geen http-opskrifte nie, so ek het nie 'n websok gebruik nie (ek hoef nie met blaaiers te kommunikeer nie - ek het 'n protokol gemaak wat by ons behoeftes pas). En alles het goed geword met hom.
Die buffertabel is hartseer
Ons het onlangs nog 'n interessante kenmerk van buffertabelle teëgekom. En hierdie probleem is reeds baie pynliker as die ander. Kom ons stel ons hierdie situasie voor: jy gebruik reeds Clickhouse aktief, jy het dosyne Clickhouse-bedieners, en jy het 'n paar versoeke wat baie lank neem om te lees (kom ons sê, meer as 60 sekondes); en jy kom doen Alter op hierdie oomblik... Intussen sal “selects” wat voor “Alter” begin het nie in hierdie tabel ingesluit word nie, “Alter” sal nie begin nie - waarskynlik sommige kenmerke van hoe “Clickhouse” werk in hierdie plek. Dalk kan dit reggemaak word? Of is dit onmoontlik?
Oor die algemeen is dit duidelik dat dit in werklikheid nie so 'n groot probleem is nie, maar met buffertabelle word dit meer pynlik. Want, as, kom ons sê, jou "Alter"-time-outs (en dit kan dalk op 'n ander gasheer verval - nie op joune nie, maar op 'n replika, byvoorbeeld), dan... Jy het die buffertabel, jou "Alter" uitgevee ( of 'n ander gasheer) het uitgetel. dan het 'n "Alter"-fout voorgekom) - jy moet steeds verseker dat die data steeds geskryf word: jy skep die buffertabelle terug (volgens dieselfde skema as die ouertabel), dan "Alter" gaan deur, eindig na alles, en die buffer begin die tabel in skema van die ouer verskil. Afhangende van wat die "Alter" was, gaan die insetsel dalk nie meer na hierdie buffertabel toe nie - dit is baie hartseer.
Daar is ook so 'n teken (miskien het iemand dit opgemerk) - dit word query_thread_log genoem in nuwe weergawes van Clickhouse. By verstek was daar een in een of ander weergawe. Hier het ons 840 miljoen rekords in 'n paar maande opgehoop (100 gigagrepe). Dit is te wyte aan die feit dat daar “insetsels” geskryf is (miskien is dit nou terloops nie geskryf nie). Soos ek jou gesê het, is ons "inserts" klein - ons het baie "inserts" in die buffertabelle gehad. Dit is duidelik dat dit gedeaktiveer is - ek vertel jou net wat ek op ons bediener gesien het. Hoekom? Dit is nog 'n argument teen die gebruik van buffertabelle! Spotty is baie hartseer.
Wie het geweet dat hierdie ou se naam Spotty was? VK-werknemers het hul hande opgesteek. OK.
Oor die planne vir "KittenHouse"
Planne word gewoonlik nie gedeel nie, reg? Skielik sal jy hulle nie vervul nie en sal nie baie goed lyk in ander mense se oë nie. Maar ek sal die risiko neem! Ons wil die volgende doen: buffertabelle, lyk dit my, is steeds 'n kruk en ons moet self die invoeging buffer. Maar ons wil dit steeds nie op skyf buffer nie, so ons sal die invoeging in die geheue buffer.
Gevolglik, wanneer 'n "insert" gemaak word, sal dit nie meer sinchroon wees nie - dit sal reeds as 'n buffertabel werk, sal in die ouertabel invoeg (wel, eendag later) en via 'n aparte kanaal rapporteer watter insetsels geslaag het en watter het nie.
Hoekom kan ek nie die sinchrone insetsel verlaat nie? Dit is baie geriefliker. Die feit is dat as jy van 10 duisend leërskare invoeg, dan is alles in orde - jy sal 'n bietjie van elke gasheer kry, jy plaas een keer 'n sekonde daar in, alles is reg. Maar ek wil graag hê dat hierdie skema moet werk, byvoorbeeld vanaf twee masjiene, sodat jy teen hoë spoed kan aflaai - miskien nie die maksimum uit Clickhouse kry nie, maar ten minste 100 megagrepe per sekonde vanaf een masjien deur 'n omgekeerde instaanbediener skryf - dit moet die skema skaal tot beide groot en klein hoeveelhede, so ons kan nie 'n sekonde wag vir elke invoeging nie, so dit moet asynchronies wees. En op dieselfde manier moet asinchroniese bevestigings kom nadat die invoeging voltooi is. Ons sal weet of dit geslaag het of nie.
Die belangrikste is dat ons in hierdie skema vir seker weet of die invoeging plaasgevind het of nie. Stel jou hierdie situasie voor: jy het 'n buffertabel, jy het iets daarin geskryf, en dan, kom ons sê, die tabel het in leesalleenmodus gegaan en probeer om die buffer te spoel. Waar gaan die data heen? Hulle sal in die buffer bly. Maar ons kan nie seker wees hiervan nie - wat as daar 'n ander fout is, as gevolg waarvan die data nie in die buffer sal bly nie ... (Red Alexey Milovidov, Yandex, ClickHouse-ontwikkelaar aan) Of sal dit bly? Altyd? Alexey oortuig ons dat alles reg sal wees. Ons het geen rede om hom nie te glo nie. Maar tog: as ons nie buffertabelle gebruik nie, sal daar geen probleme daarmee wees nie. Om twee keer soveel tafels te skep is ook ongerieflik, hoewel daar in beginsel geen groot probleme is nie. Dit is die plan.
Kom ons praat oor lees
Kom ons praat nou oor lees. Ons het ook ons eie instrument hier geskryf. Dit wil voorkom, wel, hoekom skryf jy jou eie instrument hier? .. En wie het Tabix gebruik? Op een of ander manier het min mense hul hande opgesteek... En wie is tevrede met die prestasie van Tabix? Wel, ons is nie tevrede daarmee nie, en dit is nie baie gerieflik om data te bekyk nie. Dit is goed vir analise, maar net om te kyk is dit duidelik nie geoptimaliseer nie. So ek het my eie, my eie koppelvlak geskryf.
Dit is baie eenvoudig - dit kan net data lees. Hy weet nie hoe om grafika te wys nie, hy weet nie hoe om iets te doen nie. Maar dit kan wys wat ons nodig het: byvoorbeeld hoeveel rye in die tabel is, hoeveel spasie dit opneem (sonder om dit in kolomme af te breek), dit wil sê, 'n baie basiese koppelvlak is wat ons nodig het.
En dit lyk baie soortgelyk aan Sequel Pro, maar net gemaak op Twitter se Bootstrap, en die tweede weergawe. Jy vra: "Yuri, hoekom op die tweede weergawe?" Watter jaar? 2018? Oor die algemeen het ek dit baie lank gelede gedoen vir "Muscle" (MySQL) en net 'n paar reëls in die navrae daar verander, en dit het vir "Clickhouse" begin werk, waarvoor spesiale dankie! Omdat die ontleder baie soortgelyk is aan die "spier" een, en die navrae is baie soortgelyk - baie gerieflik, veral aanvanklik.
Wel, dit kan tabelle filtreer, kan die struktuur en inhoud van die tabel wys, laat jou toe om te sorteer, filter volgens kolomme, wys die navraag wat tot die resultaat gelei het, die geaffekteerde rye (hoeveel as gevolg daarvan), dit wil sê die basiese dinge om data te bekyk. Redelik vinnig.
Daar is ook 'n redakteur. Ek het eerlikwaar probeer om die hele redakteur van Tabix te steel, maar ek kon nie. Maar op een of ander manier werk dit. In beginsel is dit al.
"Clickhouse" is geskik vir holtes
Ek wil jou vertel dat Clickhouse, ten spyte van al die probleme wat beskryf word, baie geskik is vir logs. Die belangrikste is dat dit ons probleem oplos - dit is baie vinnig en laat jou toe om logs volgens kolomme te filter. In beginsel het buffertabelle nie goed gevaar nie, maar gewoonlik weet niemand hoekom nie... Miskien weet jy nou beter waar jy probleme sal hê.
TCP? Oor die algemeen is dit in VK gebruiklik om UDP te gebruik. En toe ek TCP gebruik het... Natuurlik het niemand vir my gesê: “Yuri, waarvan praat jy! Jy kan nie, jy het UDP nodig.” Dit het geblyk dat TCP nie so skrikwekkend is nie. Die enigste ding is, as jy tienduisende aktiewe verbindings het wat jy skryf, moet jy dit 'n bietjie meer versigtig voorberei; maar dit is moontlik, en redelik maklik.
Ek het belowe om “Kittenhouse” en “Lighthouse” op HighLoad Siberia te plaas as almal ingeteken het op ons publieke “VK backend”... En jy weet, nie almal het ingeteken nie... Natuurlik sal ek nie eis dat jy inteken op ons publiek. Daar is nog te veel van julle, iemand kan selfs aanstoot neem, maar steeds, teken asseblief in (en hier moet ek oë maak soos dié van 'n kat). Dit is . Baie dankie! Github is ons s'n . Met Clickhouse sal jou hare sag en syerig wees.
moderator: - Vriende, nou vir vrae. Net nadat ons die sertifikaat van waardering en jou verslag oor VHS oorhandig het.
Yuri Nasretdinov (hierna verwys as YN): – Hoe kon jy my verslag op VHS opneem as dit net geëindig het?
moderator: – Jy kan ook nie ten volle bepaal hoe “Clickhouse” sal werk of nie! Vriende, 5 minute vir vrae!
vrae
Vraag van die gehoor (hierna na verwys as V): - Goeie middag. Baie dankie vir die verslag. Ek het twee vrae. Ek begin met iets ligsinnig: beïnvloed die aantal letters t in die naam "Katjieshuis" in die diagramme (3, 4, 7...) die bevrediging van die katte?
YN: - Hoeveelheid van wat?
З: – Letter t. Daar is drie t'e, iewers rondom drie t'e.
YN: - Het ek dit nie reggemaak nie? Wel, natuurlik doen dit! Dit is verskillende produkte – ek het jou al die tyd net bedrieg. Goed, ek maak 'n grap – dit maak nie saak nie. Ag, net hier! Nee, dis dieselfde ding, ek het 'n tikfout gemaak.
З: - Dankie. Die tweede vraag is ernstig. Sover ek verstaan, leef buffertabelle in Clickhouse uitsluitlik in die geheue, word nie na skyf gebuffer nie en is gevolglik nie aanhoudend nie.
YN: - Ja.
З: - En terselfdertyd buffer jou kliënt na skyf, wat 'n mate van waarborg van aflewering van dieselfde logs impliseer. Maar dit is geensins by Clickhouse gewaarborg nie. Verduidelik hoe die waarborg uitgevoer word, as gevolg van wat?.. Hier is hierdie meganisme in meer besonderhede
YN: – Ja, teoreties is hier geen teenstrydighede nie, want wanneer Clickhouse val, kan jy dit eintlik op ’n miljoen verskillende maniere bespeur. As Clickhouse ineenstort (as dit verkeerd eindig), kan jy, rofweg gesproke, 'n bietjie van jou log wat jy neergeskryf het terugspoel en begin vanaf die oomblik toe alles presies reg was. Kom ons sê jy spoel 'n minuut terug, dit wil sê, dit word beskou as dat jy alles in 'n minuut gespoel het.
З: – Dit wil sê, “Kittenhouse” hou die venster langer vas en kan dit in geval van val dit herken en terugspoel?
YN: – Maar dit is in teorie. In die praktyk doen ons dit nie, en betroubare aflewering is van nul tot oneindig tye. Maar gemiddeld een. Ons is tevrede dat as Clickhouse om een of ander rede ineenstort of die bedieners “herlaai”, dan verloor ons 'n bietjie. In alle ander gevalle sal niks gebeur nie.
З: - Hallo. Van die begin af het dit vir my gelyk of jy inderdaad UDP van die begin van die verslag sou gebruik. Jy het http, dit alles... En die meeste van die probleme wat jy beskryf het, soos ek dit verstaan, is deur hierdie spesifieke oplossing veroorsaak...
YN: – Wat gebruik ons TCP?
З: - In wese ja.
YN: - Geen.
З: – Dit was met fasthttp dat jy probleme gehad het, met die verbinding het jy probleme gehad. As jy net UDP gebruik het, sou jy jouself tyd gespaar het. Wel, daar sal probleme wees met lang boodskappe of iets anders ...
YN: - Met wat?
З: – Met lang boodskappe, aangesien dit dalk nie in die MTU pas nie, iets anders... Wel, daar mag dalk hul eie probleme wees. Die vraag is: hoekom nie UDP nie?
YN: – Ek glo die skrywers wat TCP/IP ontwikkel het is baie slimmer as ek en weet beter as ek hoe om pakkies te serialiseer (sodat hulle gaan), terselfdertyd die stuurvenster aanpas, nie die netwerk oorlaai nie, terugvoer gee oor wat word nie gelees nie, tel nie aan die ander kant nie... Al hierdie probleme, na my mening, sal in UDP bestaan, net ek sal nog meer kode moet skryf as wat ek reeds geskryf het om dieselfde ding self te implementeer en heel waarskynlik swak. Ek hou nie eers regtig daarvan om in C te skryf nie, wat nog te sê daar...
З: - Net gerieflik! Goed gestuur en moenie wag vir enigiets nie - dit is heeltemal asynchronies. 'n Kennisgewing het teruggekom dat alles in orde is - dit beteken dit het aangekom; As dit nie kom nie, beteken dit dat dit sleg is.
YN: – Ek het albei nodig – ek moet beide kan stuur met 'n waarborg van aflewering en sonder 'n waarborg van aflewering. Dit is twee verskillende scenario's. Ek hoef nie 'n paar logs te verloor of nie binne rede verloor nie.
З: - Ek sal nie tyd mors nie. Dit moet meer bespreek word. Dankie.
moderator: – Wie het vrae – hande na die hemel!
З: - Hallo, ek is Sasha. Iewers in die middel van die berig het 'n gevoel verskyn dat dit, benewens TCP, moontlik is om 'n klaargemaakte oplossing te gebruik - 'n soort Kafka.
YN: – Wel... ek het vir jou gesê dat ek nie intermediêre bedieners wil gebruik nie, want... in Kafka blyk dit dat ons tienduisend gashere het; trouens, ons het meer – tienduisende gashere. Dit kan ook pynlik wees om sonder enige gevolmagtigdes met Kafka te doen. Boonop, die belangrikste, gee dit steeds "latency", dit gee ekstra gashere wat u moet hê. Maar ek wil hulle nie hê nie - ek wil ...
З: “Maar op die ou end het dit in elk geval so uitgedraai.”
YN: – Nee, daar is geen gashere nie! Dit werk alles op Clickhouse-gashere.
З: - Wel, en "Kittenhouse", wat is die omgekeerde - waar bly hy?
YN: – Op die Clickhouse-gasheer skryf dit niks op die skyf nie.
З: - Laat ons veronderstel.
moderator: - Is jy tevrede? Kan ons vir jou 'n salaris gee?
З: - Ja jy kan. Trouens, daar is baie krukke om dieselfde ding te kry, en nou - die vorige antwoord oor die onderwerp van TCP weerspreek, na my mening, hierdie situasie. Dit voel net asof alles in baie minder tyd op my knieë gedoen kon word.
YN: – En ook hoekom ek nie Kafka wou gebruik nie, want daar was nogal baie klagtes in die Clickhouse Telegram-klets dat byvoorbeeld boodskappe van Kafka verlore gegaan het. Nie van Kafka self nie, maar in die integrasie van Kafka en Clickhaus; of iets het nie daar geskakel nie. Rofweg gesproke sou dit dan nodig wees om 'n kliënt vir Kafka te skryf. Ek dink nie daar kan 'n eenvoudiger of meer betroubare oplossing wees nie.
З: – Sê vir my, hoekom het jy nie enige toue of 'n soort gewone bus probeer nie? Aangesien jy sê dat jy met asinchronie die logs self deur die tou kan stuur en die reaksie asinchronies deur die tou kan ontvang?
YN: – Stel asseblief voor watter toue gebruik kan word?
З: – Enige, selfs sonder 'n waarborg dat hulle in orde is. Een of ander Redis, RMQ...
YN: – Ek het 'n gevoel dat Redis heel waarskynlik nie so 'n volume van invoeging sal kan trek nie, selfs op een gasheer (in die sin van verskeie bedieners) wat Clickhouse uittrek. Ek kan dit nie met enige bewyse rugsteun nie (ek het dit nie getoets nie), maar dit lyk vir my of Redis nie die beste oplossing hier is nie. In beginsel kan hierdie stelsel as 'n geïmproviseerde boodskapwaglys beskou word, maar wat slegs vir "Clickhouse" aangepas is
moderator: – Yuri, baie dankie. Ek stel voor om die vrae en antwoorde hier te beëindig en te sê aan wie van diegene wat die vraag gevra het, ons die boek sal gee.
YN: – Ek wil graag 'n boek gee aan die eerste persoon wat 'n vraag gevra het.
moderator: - Wonderlik! Puik! Fantasties! Baie dankie!
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com