In April het Avito-ingenieurs bymekaargekom vir aanlynbyeenkomste met Alexey Milovidov, die hoofontwikkelaar van ClickHouse, en Kirill Shvakov, 'n Golang-ontwikkelaar van Integros. Ons het bespreek hoe ons die databasisbestuurstelsel gebruik en watter probleme ons in die gesig staar.
Gebaseer op die vergadering, het ons 'n artikel saamgestel met kundiges se antwoorde op ons en gehoorvrae oor rugsteun, dataherverdeling, eksterne woordeboeke, die Golang-bestuurder en ClickHouse-weergawe-opdaterings. Dit kan nuttig wees vir ontwikkelaars wat reeds aktief met die Yandex DBMS werk en belangstel in die hede en toekoms daarvan. Aleksey Milovidov se antwoorde by verstek, tensy anders vermeld.
Pasop, daar is baie teks onder die snit. Ons hoop dat die inhoud met vrae jou sal help om te navigeer.
inhoud
As jy nie die teks wil lees nie, kan jy die opname van byeenkomste kyk . Tydstempels is in die eerste opmerking onder die video.
ClickHouse word voortdurend bygewerk, maar ons data is nie. Wat om daarmee te doen?
ClickHouse word voortdurend opgedateer, en ons data wat deur optimize final verwerk is, word nie opgedateer nie en is in 'n rugsteun.
Gestel ons het 'n soort probleem gehad en die data is verlore. Ons het besluit om te herstel, en dit het geblyk dat die ou partisies, wat in die rugsteunbedieners gestoor word, baie verskil van die weergawe van ClickHouse wat tans gebruik word. Wat om te doen in so 'n situasie, en is dit moontlik?
Die situasie waarin u data vanaf 'n rugsteun in die ou formaat herstel het, maar op die nuwe weergawe is hulle nie gekoppel nie, is onmoontlik. Ons maak seker dat die dataformaat in ClickHouse altyd agteruit versoenbaar bly. Dit is baie belangriker as terugwaartse versoenbaarheid in funksionaliteit as die gedrag van 'n paar selde gebruikte funksie verander het. Die data wat op skyf gestoor word, moet die nuwe weergawe van ClickHouse altyd kan lees. Dit is die wet.
Wat is die huidige beste praktyke vir die rugsteun van data vanaf ClickHouse?
Hoe om rugsteun te maak, met inagneming dat ons finale bewerkings geoptimaliseer het, 'n groot databasis van teragrepe, en data wat opgedateer word, kom ons sê, vir die laaste drie dae, en dan gebeur daar geen prosedures met hulle nie?
Ons kan ons eie oplossing saamstel en op die kop skryf: versamel hierdie rugsteun op so en so 'n manier. Miskien hoef jy niks te kruk nie, en die fiets is lank gelede uitgevind?
Kom ons begin met die beste praktyke. My kollegas adviseer altyd in antwoord op vrae oor rugsteun om hulle te herinner aan die Yandex.Cloud-diens, waar hierdie taak reeds opgelos is. Gebruik dit dus indien moontlik.
Daar is geen volledige oplossing, honderd persent ingebou in ClickHouse, vir rugsteun nie. Daar is 'n paar spasies wat jy kan gebruik. Om 'n volledige oplossing te kry, sal jy óf 'n bietjie met die hand moet peuter, óf omhulsels in die vorm van skrifte moet maak.
Ek sal begin met die eenvoudigste oplossings en eindig met die mees gesofistikeerde, afhangende van die hoeveelheid data en groepgrootte. Hoe groter die groep, hoe moeiliker word die oplossing.
As die datatabel slegs 'n paar gigagrepe beslaan, kan die rugsteun so gedoen word:
- Stoor die definisie van tabelle, dit wil sê metadata − wys skep tabel.
- Maak 'n storting met die ClickHouse-kliënt − kies * van tafel af om te liasseer. By verstek sal jy 'n lêer in die TabSeparated-formaat ontvang. As jy meer doeltreffend wil wees, kan jy die Native-formaat gebruik.
As die hoeveelheid data groter is, sal die rugsteun meer tyd en baie spasie neem. Dit word 'n logiese rugsteun genoem, dit is nie gekoppel aan die ClickHouse-dataformaat nie. As dit is, kan jy in 'n knippie 'n rugsteun neem en dit na MySQL oplaai vir herstel.
Vir meer gevorderde gevalle het ClickHouse 'n ingeboude vermoë om 'n momentopname van partisies in die plaaslike lêerstelsel te skep. Hierdie kenmerk is beskikbaar as 'n versoek. verander tabel vries partisie. Of eenvoudig verander tafel vries is 'n momentopname van die hele tabel.
Die momentopname sal konsekwent vir een tabel op een skerf geskep word, dit wil sê, dit is onmoontlik om op hierdie manier 'n konsekwente momentopname van die hele groepering te skep. Maar vir die meeste take is daar nie so 'n behoefte nie, en dit is genoeg om 'n versoek op elke skerf uit te voer en 'n konsekwente momentopname te kry. Dit word geskep in die vorm van harde skakels en neem dus nie bykomende spasie op nie. Dan kopieer jy hierdie momentopname na die rugsteunbediener of na die berging wat jy vir rugsteun gebruik.
Om so 'n rugsteun te herstel is redelik maklik. Eerstens skep jy tabelle volgens die bestaande tabeldefinisies. Kopieer dan die gestoorde partisie-kiekies na Directory-Detached vir hierdie tabelle en voer die navraag uit heg partisie aan. Hierdie oplossing is baie geskik vir die mees ernstige hoeveelhede data.
Soms het jy iets nog koeler nodig – in gevalle waar jy tiene of selfs honderde teragrepe op elke bediener en honderde bedieners het. Daar is 'n oplossing hier waarna ek gespioeneer het van kollegas van Yandex.Metrica. Ek sal dit nie vir almal aanbeveel nie – lees dit en besluit self of dit geskik is of nie.
Eerstens moet u verskeie bedieners met groot skyfrakke skep. Verhoog dan verskeie ClickHouse-bedieners op hierdie bedieners en stel hulle in sodat hulle as 'n ander replika vir dieselfde skerwe werk. En gebruik dan die lêerstelsel op hierdie bedieners of een of ander hulpmiddel waarmee u foto's kan skep. Daar is twee opsies hier. Die eerste opsie is LVM-kiekies, die tweede opsie is ZFS op Linux.
Daarna, elke dag wat jy 'n momentopname moet skep, sal dit lê en 'n bietjie spasie opneem. Natuurlik, as die data verander, sal die hoeveelheid spasie mettertyd toeneem. Jy kan hierdie momentopname enige tyd kry en die data herstel, so 'n vreemde besluit. Boonop moet u steeds hierdie replikas in die konfigurasie beperk sodat hulle nie leiers probeer word nie.
Sal dit moontlik wees om 'n beheerde agterstand van replikas in die skagte te organiseer?
Hierdie jaar beplan jy om skagte in ClickHouse te maak. Sal dit moontlik wees om 'n beheerde agterstand van replikas daarin te organiseer? Ons wil dit graag gebruik om onsself te beskerm teen negatiewe scenario's met veranderinge en ander veranderinge.
Is dit moontlik om 'n soort terugrol vir veranderings te doen? Byvoorbeeld, in 'n bestaande skag, neem en sê dat tot op hierdie oomblik, pas die veranderinge toe, en van hierdie oomblik af, hou op om die veranderinge toe te pas?
As 'n opdrag na ons groep kom en dit breek, dan het ons 'n voorwaardelike replika met 'n uur vertraging, waar ons kan sê dat kom ons gebruik dit op die oomblik, maar ons sal nie die veranderinge daarin toepas vir die laaste tien minute nie?
Om mee te begin, oor die beheerde agterstand van replikas. Daar was so 'n versoek van gebruikers, en ons het 'n probleem op Github geskep met 'n versoek: "As iemand dit nodig het, plaas 'n like, sit 'n hart." Niemand het gewed nie, en die kwessie is gesluit. U kan egter reeds hierdie geleentheid kry deur ClickHouse op te stel. Dit is waar, slegs vanaf weergawe 20.3.
ClickHouse voeg voortdurend data in die agtergrond saam - voeg saam. Wanneer 'n samesmelting gemaak word, word 'n stel datastukke vervang met 'n groter stuk. Terselfdertyd bly stukke data wat voorheen was, vir 'n geruime tyd op die skyf.
Eerstens, dit bly gestoor solank daar uitgesoekte navrae is wat dit gebruik, om nie-blokkerende werking te verseker. Geselekteerde versoeke word stilweg uit ou stukke gelees.
Tweedens is daar ook 'n tyddrempel - ou stukkies data lê vir agt minute op die skyf. Hierdie agt minute kan aangepas word en in selfs een dag verander word. Dit sal skyfspasie kos: afhangend van die datavloei, sal dit blyk dat die data oor die laaste dag nie net sal verdubbel nie, dit kan vyf keer meer word. Maar in die geval van 'n ernstige probleem, kan jy die ClickHouse-bediener stop en alles hanteer.
Nou is die vraag hoe beskerm dit teen veranderings. Dit is die moeite werd om hier dieper te kyk, want in ouer weergawes van ClickHouse het die alter so gewerk dat dit eenvoudig die stukke direk verander het. Daar is 'n stukkie data met sommige lêers, en ons doen bv. verander druppelkolom. Dan word hierdie kolom fisies uit alle stukke verwyder.
Maar sedert weergawe 20.3 is die wysigingsmeganisme heeltemal verander, en nou is datastukke altyd onveranderlik. Hulle verander glad nie - alters werk nou op baie dieselfde manier as samesmeltings. In plaas daarvan om 'n stuk in plek te verander, skep ons 'n nuwe een. In die nuwe deel word lêers wat nie verander het nie harde skakels, en as ons 'n kolom uitvee, sal dit eenvoudig in die nuwe deel ontbreek. Die ou stuk sal by verstek na agt minute uitgevee word, en hier kan jy die instellings wat hierbo genoem word, aanpas.
Dieselfde geld vir veranderinge soos mutasies. Wanneer jy dit doen verander verwyder of opdatering verander, dit verander nie die stuk nie, maar skep 'n nuwe een. En verwyder dan die ou een.
Wat as die struktuur van die tabel verander het?
Hoe om 'n rugsteun in te samel wat met die ou skema gemaak is? En die tweede vraag gaan oor die geval met momentopnames en lêerstelselgereedskap. Is Btrfs hier geskik in plaas van ZFS op Linux LVM?
As jy dit doen heg partisie aan partisies met 'n ander struktuur, dan sal ClickHouse jou vertel dat dit nie moontlik is nie. Die oplossing is dit. Die eerste is om 'n tydelike tabel van die MergeTree-tipe met die ou struktuur te skep, data daar aan te heg met behulp van attach, en 'n wysigingsnavraag uit te reik. Dan kan jy hierdie data óf kopieer óf oordra en weer aanheg, óf die navraag gebruik verander tafelskuif partisie.
Nou is die tweede vraag of dit moontlik is om Btrfs te gebruik. Om mee te begin, as jy LVM het, dan is LVM-kiekies genoeg, en die lêerstelsel kan ext4 wees, dit maak nie saak nie. Met Btrts hang dit alles af van jou ervaring daarmee. Dit is 'n volwasse lêerstelsel, maar daar is steeds 'n paar vermoedens oor hoe alles in die praktyk in 'n spesifieke scenario sal uitwerk. Ek sal nie aanbeveel om dit te gebruik nie, tensy jy Btrfs in produksie het.
Wat is die huidige beste praktyke vir die herverdeling van data?
Die kwessie van herharding is kompleks en veelsydig. Hier kan jy verskeie opsies tegelyk beantwoord. Jy kan van die een kant af ingaan en dit sê - daar is geen ingeboude herhardingsopsie in ClickHouse nie. Maar ek is bevrees dat hierdie antwoord niemand sal pas nie. Daarom kan jy van die ander kant af gaan en sê dat ClickHouse baie maniere het om data te herhard.
As die cluster se spasie opraak of dit nie die las kan hanteer nie, voeg jy nuwe bedieners by. Maar hierdie bedieners is by verstek leeg, daar is geen data op hulle nie, daar is geen las nie. Jy moet die data verskuif sodat dit eweredig oor die nuwe, groter groepering versprei word.
Die eerste manier om dit te doen is om 'n deel van die partisies na nuwe bedieners te kopieer deur die navraag te gebruik verander tabel haal partisie. Byvoorbeeld, jy het partisies volgens maande gehad, en jy neem die eerste maand van 2017 en kopieer dit na 'n nuwe bediener, kopieer dan die derde maand na 'n ander nuwe bediener. En so doen jy totdat dit min of meer gelyk word.
Migrasie kan slegs uitgevoer word vir daardie partisies wat nie tydens opname verander nie. Vir vars partisies sal skryf gedeaktiveer moet word, want hul oordrag is nie atoom nie. Andersins sal jy duplikate of leemtes in die data hê. Hierdie metode is egter prakties en werk redelik effektief. Klaargemaakte saamgeperste partisies word oor die netwerk versend, dit wil sê die data word nie saamgepers of her-enkodeer nie.
Hierdie metode het een nadeel, en dit hang af van die skeuringskema, of jy aan hierdie skeuringskema belowe het, watter skeringsleutel jy gehad het. In jou voorbeeld vir die geval met metrieke, is die sharding-sleutel 'n hash van die pad. Wanneer jy 'n Verspreide tabel kies, gaan dit gelyktydig na al die stukke van die groepering en neem data van daar af.
Dit beteken dat dit nie eintlik vir jou saak maak watter data op watter skerf beland nie. Die belangrikste ding is dat data langs een pad op een skerf beland, maar watter een is nie belangrik nie. In hierdie geval is die oordrag van klaargemaakte partisies perfek, want met uitgesoekte navrae sal jy ook volledige data ontvang - beide voor herharding en daarna maak die skema nie regtig saak nie.
Maar daar is gevalle wat meer ingewikkeld is. As jy op die vlak van toepassingslogika staatmaak op 'n spesiale skeuringskema, dat hierdie kliënt op so en so 'n skerf geleë is, en die versoek kan dadelik daarheen gestuur word, en nie na die Verspreide tabel nie. Of gebruik jy 'n redelik onlangse weergawe van ClickHouse en het die instelling geaktiveer optimeer slaan ongebruikte skerwe oor. In hierdie geval, tydens die seleksie-navraag, sal die uitdrukking in die where-afdeling ontleed word en dit sal bereken word na watter skerwe om te gaan volgens die shardingskema. Dit werk mits die data presies in ooreenstemming met hierdie skeuringskema ontbind word. As jy hulle met die hand geskuif het, kan die korrespondensie verander.
So dit is die nommer een manier. En ek wag vir jou antwoord, is die metode geskik, of gaan aan.
Vladimir Kolobaev, hoofstelseladministrateur in Avito: Alexey, die metode wat jy genoem het, pas nie baie goed wanneer jy die vrag moet versprei nie, insluitend lees. Ons kan 'n partisie neem wat maandeliks is en ons kan die vorige maand na 'n ander nodus neem, maar wanneer 'n versoek vir hierdie data inkom, sal ons dit net laai. Maar ek wil graag die hele cluster laai, want anders, vir 'n geruime tyd, sal die hele leeslading deur twee skerwe verwerk word.
Alexey Milovidov: Die antwoord hier is vreemd – ja, dit is sleg, maar dit kan werk. Ek sal presies verduidelik hoe. Dit is die moeite werd om te kyk na die vrag-scenario wat saam met jou data kom. As dit monitering van data is, is dit byna seker dat die oorgrote meerderheid versoeke vir vars data is.
Jy het nuwe bedieners geïnstalleer, ou partisies gemigreer, maar ook verander hoe vars data geskryf word. En vars data sal deur die groep versprei word. Dus, na vyf minute, sal versoeke vir die laaste vyf minute die groep eweredig laai, na 'n dag sal versoeke vir 'n dag die groep eweredig laai. En versoeke vir die vorige maand sal ongelukkig net na 'n deel van die groepbedieners gaan.
Maar dikwels sal jy nie versoeke vir Februarie 2019 hê nie. Heel waarskynlik, as versoeke na 2019 gaan, sal dit vir die hele 2019 wees - vir 'n groot tydsinterval, en nie vir 'n klein reeks nie. En sulke versoeke sal ook die groep eweredig kan laai. Maar oor die algemeen is jou opmerking heeltemal korrek dat dit 'n ad hoc-oplossing is wat nie die data heeltemal eweredig versprei nie.
Ek het nog 'n paar punte om die vraag te beantwoord. Een daarvan handel oor hoe om die skeuringskema aanvanklik so te maak dat daar minder pyn is as gevolg van herharding. Dit is nie altyd moontlik nie.
Byvoorbeeld, jy het moniteringsdata. Moniteringsdata groei om drie redes. Die eerste is die versameling van historiese data. Die tweede is verkeersgroei. En die derde is 'n toename in die aantal dinge wat onderhewig is aan monitering. Daar is nuwe mikrodienste en maatstawwe wat gestoor moet word.
Dit is moontlik dat van hierdie die grootste toename te wyte is aan die derde rede - dit is 'n toename in die gebruik van monitering. En in hierdie geval is dit die moeite werd om te kyk na die aard van die vrag, wat is die belangrikste versoeke om te kies. Die hoofseleksie-navrae sal waarskynlik 'n deel van die maatstawwe volg.
Byvoorbeeld, CPU-gebruik op sommige bedieners deur een of ander diens. Dit blyk dat daar 'n subset van sleutels is waarmee jy hierdie data kry. En die versoek self vir hierdie data is heel waarskynlik redelik eenvoudig en loop in tien millisekondes. Word gebruik vir moniteringsdienste, vir dashboards. Ek hoop ek verstaan dit reg.
Vladimir Kolobaev: Die feit is dat ons baie dikwels 'n beroep doen op historiese data, aangesien ons die huidige posisie met die historiese een in reële tyd vergelyk. En dit is vir ons belangrik om vinnige toegang tot 'n groot hoeveelheid data te hê, en ClickHouse doen goeie werk hiermee.
Jy is heeltemal reg, die meeste van die leesversoeke wat ons in die laaste dag ervaar, soos enige moniteringstelsel. Maar terselfdertyd is die las op historiese data ook redelik groot. Dit is meestal van 'n waarskuwingstelsel wat elke dertig sekondes rondgaan en vir ClickHouse sê, "Gee my die data vir die afgelope ses weke. En bou nou vir my 'n bewegende gemiddelde van hulle, en kom ons vergelyk die huidige waarde met die historiese waarde.
Ek wil graag sê dat ons vir sulke baie vars versoeke nog 'n klein tabel het waarin ons net twee dae se data stoor, en die hoofversoeke vlieg daarin. Ons stuur slegs groot geskiedkundige navrae na 'n groot geskeurde tabel.
Alexey Milovidov: Ongelukkig blyk dit swak toepaslik te wees vir jou scenario, maar ek sal twee slegte en komplekse skeuringskemas beskryf wat nie gebruik hoef te word nie, maar in my vriendediens gebruik word.
Daar is 'n hoofgroep met Yandex.Metrics-geleenthede. Gebeurtenisse is bladsyaansigte, klikke en oorgange. Die meeste versoeke gaan na 'n spesifieke webwerf. U maak die Yandex.Metrica-diens oop, u het 'n webwerf - avito.ru, gaan na die verslag, en 'n versoek word vir u webwerf gedoen.
Maar daar is ander versoeke - analitiese en globale, wat deur interne ontleders gemaak word. Net vir ingeval, let ek daarop dat interne ontleders slegs versoeke vir Yandex-dienste rig. Maar nietemin, selfs Yandex-dienste beslaan 'n beduidende deel van alle data. Dit is versoeke nie vir spesifieke tellers nie, maar vir breër filtering.
Hoe om data op so 'n manier te organiseer dat alles doeltreffend werk vir een teller, en globale navrae ook? Nog 'n probleem lê in die feit dat die aantal versoeke in ClickHouse vir die Metrics-groepering 'n paar duisend per sekonde is. Terselfdertyd hanteer een ClickHouse-bediener nie nie-onbeduidende versoeke nie, byvoorbeeld etlike duisende per sekonde.
Die groepgrootte is seshonderd en iets bedieners. As jy bloot 'n verspreide tabel oor hierdie groepie strek en 'n paar duisend versoeke daarheen stuur, sal dit selfs erger word as om dit na een bediener te stuur. Aan die ander kant word die opsie dat die data eweredig versprei word, en ons gaan vra van alle bedieners, onmiddellik van die hand gewys.
Daar is 'n diametraal teenoorgestelde opsie. Stel jou voor dat ons data per werf verdeel, en 'n versoek vir een werf gaan na een skerf. Nou sal die groep tienduisend versoeke per sekonde kan uittrek, maar op een skerf sal een versoek te stadig werk. Dit sal nie meer in bandwydte skaal nie. Veral as dit 'n webwerf avito.ru is. Ek sal nie 'n geheim verklap as ek sê dat Avito een van die mees besoekte webwerwe in Runet is nie. En om dit op een skerf te verwerk sal kranksinnig wees.
Daarom is die skeuringskema op 'n meer moeilike manier gereël. Die hele groep is verdeel in 'n aantal trosse, wat ons lae noem. Binne elke tros is daar van tien tot etlike dosyn skerwe. Daar is altesaam nege-en-dertig sulke trosse.
Hoe skaal dit alles? Die aantal trosse verander nie – soos dit nege-en-dertig jaar gelede was, bly dit dieselfde. Maar binne elkeen van hulle vermeerder ons geleidelik die aantal skerwe soos data ophoop. En die versplinteringskema as geheel is dit - die verdeling in hierdie groepe gaan deur webwerwe, en om te verstaan watter webwerf op watter groep is, word 'n aparte metabasis in MySQL oor die algemeen gebruik. Een terrein - op een groep. En daarbinne vind skering plaas volgens die identifiseerders van besoekers.
Wanneer ons opneem, verdeel ons hulle volgens die res van die besoeker-ID. Maar wanneer 'n nuwe skerf bygevoeg word, verander die skeurselskema, ons gaan voort om te verdeel, maar met die res van deling deur 'n ander getal. Dit beteken dat een besoeker reeds op verskeie bedieners geleë is, en jy kan nie daarop wed nie. Dit word uitsluitlik gedoen om te verseker dat die data beter saamgepers word. En wanneer ons navraag doen, gaan ons na die Verspreide tabel, wat na die groep kyk en toegang tot dosyne bedieners het. Dit is so 'n dom skema.
Maar my storie sal onvolledig wees as ek nie sê dat ons hierdie skema laat vaar het nie. In die nuwe skema het ons alles verander en al die data met clickhouse-copier gekopieer.
In die nuwe skema word alle terreine in twee kategorieë verdeel - groot en klein. Ek weet nie hoe die drempel daar gekies is nie, maar as gevolg daarvan het dit geblyk dat groot werwe op een groep aangeteken is, waar daar 120 skerwe met drie replikas in elk is - dit wil sê 360 bedieners. En die skeuringskema is sodanig dat enige versoek gelyktydig na alle skerwe gaan. As jy nou enige verslagbladsy vir avito.ru in Yandex.Metrica oopmaak, sal die versoek na 120 bedieners gaan. Daar is min groot werwe in Runet. En die versoeke is nie duisend per sekonde nie, maar selfs minder as honderd. Dit alles word stilweg deur die Distributed-tabel gekou, wat elkeen 120 bedieners verwerk.
En die tweede groep is vir klein terreine. Hier is 'n skeuringskema volgens werf-ID, en elke versoek gaan na presies een skerf.
ClickHouse het 'n clickhouse-kopieerder-nutsding. Kan jy van haar vertel?
Ek moet dadelik sê dat hierdie oplossing meer omslagtig en ietwat minder produktief is. Die voordeel is dat dit die data heeltemal smeer volgens die skema wat jy spesifiseer. Maar die nadeel van die nut is dat dit glad nie herhard nie. Dit kopieer data van een klusterskema na 'n ander klusterskema.
Dit beteken dat jy twee groepe moet hê om te werk. Hulle kan op dieselfde bedieners geleë wees, maar die data sal nietemin nie inkrementeel geskuif word nie, maar sal gekopieer word.
Daar was byvoorbeeld vier bedieners, nou is daar agt. Jy skep 'n nuwe verspreide tabel op alle bedieners, nuwe plaaslike tabelle, en begin clickhouse-kopieerder, spesifiseer daarin die werkskema wat dit van daar af moet lees, aanvaar die nuwe skeuringskema en dra data daarheen oor. En jy sal een en 'n half keer meer spasie op die ou bedieners nodig hê as wat jy nou het, want die ou data moet daarop bly, en die helfte van dieselfde ou data sal bo-op hulle kom. As jy vooraf gedink het dat die data herskerp moet word en daar spasie is, dan is hierdie metode geskik.
Hoe werk clickhouse-kopieerder binne? Dit breek al die werk in 'n stel take vir die verwerking van een partisie van een tabel op een skerf. Al hierdie take kan parallel loop, en clickhouse-copier kan verskeie gevalle op verskillende masjiene laat loop, maar wat dit vir 'n enkele partisie doen, is niks meer as 'n invoegsel seleksie nie. Die data word gelees, gedekomprimeer, herpartisioneer, dan weer saamgepers, iewers geskryf, weer gesorteer. Dit is 'n moeiliker besluit.
Jy het 'n loodsding gehad genaamd herharding. Wat met haar?
In 2017 het jy 'n loodsding gehad genaamd herharding. Daar is selfs 'n opsie in ClickHouse. Ek verstaan dit het nie opgestyg nie. Kan jy sê hoekom dit gebeur het? Dit blyk baie relevant te wees.
Die hele probleem is dat as jy data in plek moet herhard, 'n baie komplekse sinchronisasie nodig is om dit atomies te kan doen. Toe ons begin kyk het na hoe hierdie sinchronisasie werk, het dit duidelik geword dat daar fundamentele probleme is. En hierdie fundamentele probleme is nie net teoreties nie, maar het hulself dadelik in die praktyk begin wys in die vorm van iets wat baie eenvoudig verklaar kan word – niks werk nie.
Is dit moontlik om alle dele van data saam te voeg voordat jy na stadige skywe beweeg?
'N Vraag oor TTL met die skuif na stadige skyf opsie in die konteks van samesmeltings. Is daar 'n ander manier as cron om alle dele in een saam te voeg voordat jy na stadige skywe beweeg?
Die antwoord op die vraag of dit moontlik is om al die stukke outomaties in een te plak voordat dit oorgedra word, is nee. Dit lyk vir my of dit nie nodig is nie. Jy kan nie al die dele in een saamvoeg nie, maar net staatmaak op die feit dat hulle outomaties na stadige skywe oorgedra sal word.
Ons het twee kriteria vir oordragreëls. Die eerste is soos dit vol word. As die huidige bergingsvlak minder as 'n sekere persentasie vrye spasie het, kies ons een stuk en skuif dit na 'n stadiger berging. Of eerder, nie stadiger nie, maar die volgende – hoe jy dit opstel.
Die tweede maatstaf is grootte. Hy praat van die oordrag van groot stukke. U kan die drempel aanpas op grond van vrye spasie op 'n vinnige skyf en die data sal outomaties gemigreer word.
Hoe om na nuwe weergawes van ClickHouse te migreer as daar geen manier is om versoenbaarheid vooraf na te gaan nie?
Hierdie onderwerp word gereeld bespreek met inagneming van verskillende weergawes, en tog. Hoe veilig is dit om op te gradeer vanaf weergawe 19.11 na 19.16 en byvoorbeeld van 19.16 na 20.3. Wat is die beste manier om na nuwe weergawes te beweeg sonder om vooraf versoenbaarheid in die sandbox na te gaan?
Hier is 'n paar goue reëls. Eerstens - . Dit is groot, maar daar is afsonderlike punte oor terugwaartse onversoenbare veranderinge. Moenie hierdie items as 'n rooi vlag behandel nie. Dit is gewoonlik geringe onverenigbaarhede wat verband hou met een of ander randfunksie wat u waarskynlik nie gebruik nie.
Tweedens, as daar geen manier is om versoenbaarheid in die sandbox na te gaan nie, en jy wil dadelik in produksie opgradeer, is die aanbeveling dat jy dit nie hoef te doen nie. Skep eers 'n sandbox en toets. As daar nie 'n toetsomgewing is nie, het jy heel waarskynlik nie 'n baie groot maatskappy nie, wat beteken dat jy van die data na jou skootrekenaar kan kopieer en seker maak dat alles reg daarop werk. U kan selfs 'n paar replikas plaaslik op u masjien opbring. Of jy kan 'n nuwe weergawe iewers naby oplaai en 'n paar data daar oplaai - dit wil sê, 'n impromptu toetsomgewing maak.
Nog 'n reël is om nie binne 'n week na die vrystelling van die weergawe op te dateer nie as gevolg van foute in produksie en daaropvolgende kitsoplossings. Kom ons verstaan die ClickHouse-weergawenommering om nie deurmekaar te raak nie.
Daar is weergawe 20.3.4. Die nommer 20 dui die vervaardigingsjaar aan - 2020. Vanuit die oogpunt van wat binne is, maak dit nie saak nie, so ons sal nie daaraan aandag gee nie. Verder - 20.3. Die tweede getal - in hierdie geval 3 - verhoog ons elke keer as ons 'n vrystelling met 'n paar nuwe funksionaliteit vrystel. As ons een of ander kenmerk by ClickHouse wil voeg, moet ons hierdie getal verhoog. Dit wil sê, in weergawe 20.4 sal ClickHouse selfs beter werk. Die derde syfer is 20.3.4. Hier 4 is die aantal pleistervrystellings waarin ons nie nuwe kenmerke bygevoeg het nie, maar 'n paar foute reggestel het. En 4 beteken ons het dit vier keer gedoen.
Moenie dink dis iets vreesliks nie. Gewoonlik kan die gebruiker die nuutste weergawe installeer en dit sal sonder enige probleme met uptyd per jaar werk. Maar stel jou voor dat in een of ander funksie vir die verwerking van bitmaps, wat deur ons Chinese kamerade bygevoeg is, die bediener ineenstort wanneer verkeerde argumente deurgegee word. Ons moet dit regmaak. Ons sal 'n nuwe pleister weergawe vrystel en ClickHouse sal meer stabiel word.
As jy ClickHouse het wat in produksie werk, en 'n nuwe weergawe van ClickHouse met bykomende kenmerke word vrygestel - byvoorbeeld, 20.4.1 is die heel eerste een, moenie haastig wees om dit op die eerste dag in produksie te plaas nie. Hoekom is sy enigsins nodig? As jy nog nie ClickHouse gebruik nie, dan kan jy dit installeer, en heel waarskynlik sal alles in orde wees. Maar as ClickHouse reeds stabiel werk, bly dan ingeskakel vir pleisters en opdaterings - watter probleme ons regstel.
Kirill Shvakov: Ek wil 'n bietjie byvoeg oor toetsomgewings. Almal is baie bang vir toetsomgewings en glo om een of ander rede dat as jy 'n baie groot ClickHouse-kluster het, dan moet die toetsomgewing nie kleiner of ten minste tien keer kleiner wees nie. Dit is glad nie so nie.
Ek kan aan my voorbeeld sê. Ek het 'n projek en daar is ClickHouse. Ons toetsomgewing vir hom is 'n klein virtuele masjien in Hetzner vir twintig euro, waar absoluut alles ontplooi word. Om dit te doen, het ons volle outomatisering in Ansible, en daarom is daar in beginsel geen verskil waar om te rol nie - op ysterbedieners of net in virtuele masjiene te ontplooi.
Wat kan gedoen word? Dit sal lekker wees om 'n voorbeeld in die ClickHouse-dokumentasie te maak oor hoe om 'n klein groepie op jou eie te ontplooi - in Docker, in LXC, skep dalk 'n Ansible-speelboek, want verskillende mense het verskillende ontplooiings. Dit sal baie dinge makliker maak. Wanneer jy 'n groep in vyf minute neem en ontplooi, is dit baie makliker om iets te probeer uitvind. Dit is baie geriefliker op hierdie manier, want om 'n weergawe wat jy nie getoets het in produksie te rol nie, is 'n pad na nêrens. Soms werk dit en soms nie. En so is dit sleg om op sukses te hoop.
Maxim Kotyakov, senior backend-ingenieur Avito: Ek sal 'n bietjie byvoeg oor toetsomgewings uit 'n reeks probleme vir groot maatskappye. Ons het 'n volwaardige ClickHouse-aanvaardingskluster, volgens dataskemas en instellings, 'n presiese kopie van wat in produksie is. Hierdie groep word in taamlik vrot houers met 'n minimum van hulpbronne ontplooi. Ons skryf 'n sekere persentasie van die produksiedata daar, aangesien daar 'n geleentheid is om die stroom in Kafka te herhaal. Alles word daar gesinchroniseer en afgeskaal – beide in terme van kapasiteit en vloei, en, in teorie, moet dit, alles gelyk, soos 'n produksie in terme van metrieke gedra. Alles wat potensieel plofbaar is, word eers op hierdie staander gerol en vir 'n paar dae daar ingespuit totdat dit gereed is. Maar natuurlik is hierdie oplossing duur, swaar en met nie-nul ondersteuningskoste.
Alexey Milovidov: Ek sal jou vertel hoe die toetsomgewing van ons vriende van Yandex.Metrica is. Een groep was vir 600-iets-bedieners, die ander vir 360, en daar is 'n derde en verskeie groepe. Die toetsomgewing vir een van hulle is net twee skerwe met twee replikas in elk. Hoekom twee skerwe? Om nie alleen te wees nie. En replikas ook om te wees. Net 'n minimum bedrag wat jy kan bekostig.
Hierdie toetsomgewing laat jou toe om die gesondheid van versoeke te kontroleer en of iets grootliks gebreek is. Maar dikwels ontstaan probleme van 'n heeltemal ander aard, wanneer alles werk, maar daar is 'n paar klein veranderinge met die las.
Ek sal vir jou 'n voorbeeld gee. Ons het besluit om 'n nuwe weergawe van ClickHouse te installeer. Dit is uitgelê op 'n toetsomgewing, outomatiese toetse word in Yandex.Metrica self geslaag, wat data op die ou weergawe en op die nuwe een vergelyk, wat die hele pyplyn bestuur. En natuurlik, groen toetse van ons CI. Andersins sou ons nie eers hierdie weergawe voorgestel het nie.
Alles is reg. Ons begin in produksie rol. Ek ontvang 'n boodskap dat die las verskeie kere op die grafieke toegeneem het. Ons rol die weergawe terug. Ek kyk na die grafiek en sien: die vrag het regtig verskeie kere toegeneem tydens die uitrol, en het teruggedaal wanneer dit uitgerol word. Toe begin ons die weergawe terugrol. En die vrag het op dieselfde manier toegeneem en op dieselfde manier teruggesak. So die gevolgtrekking is dit - die las het toegeneem in verband met die berekening, niks verbasend nie.
Toe was dit moeilik om kollegas te oortuig om tog die nuwe weergawe te installeer. Ek sê: “Dis oukei, rol uit. Hou duim vas, alles sal werk. Nou het die las op die kaarte toegeneem, maar alles is reg. Hou vas." Oor die algemeen het ons dit gedoen, en dit is dit - die weergawe word op die produksiewebwerf geplaas. Maar byna met elke berekening duik soortgelyke probleme op.
Doodnavraag is veronderstel om navrae dood te maak, maar dit doen nie. Hoekom?
'n Gebruiker het na my toe gekom, 'n soort ontleder, en 'n sekere versoek geskep, wat my ClickHouse-kluster geplaas het. Een of ander nodus of 'n hele groep, afhangende van watter replika of skerf die versoek beland het. Ek sien dat alle SVE-hulpbronne op hierdie bediener in die rak is, alles is rooi. Terselfdertyd reageer ClickHouse self op versoeke. En ek skryf: "Wys my asseblief die proseslys, watter versoek hierdie waansin gegenereer het."
Ek vind hierdie versoek en skryf dood daaraan. En ek sien niks gebeur nie. My bediener is in die rak, ClickHouse gee my dan 'n paar opdragte, wys dat die bediener lewendig is, en alles is in orde. Maar ek het agteruitgang in alle gebruikersversoeke, agteruitgang deur inskrywing in ClickHouse begin, en my doodmaaknavraag werk nie. Hoekom? Ek het gedink doodmaaknavraag is veronderstel om navrae dood te maak, maar dit doen nie.
Nou sal daar nogal 'n vreemde antwoord wees. Die punt is dat doodnavraag nie navrae doodmaak nie.
Kill-navraag plaas 'n klein merkblokkie genaamd "Ek wil hê hierdie navraag moet doodgemaak word". En die versoek self, wanneer elke blok verwerk word, kyk na hierdie vlag. As dit gestel is, hou die versoek op om te werk. Dit blyk dat niemand die versoek doodmaak nie, hy moet self alles nagaan en stop. En dit behoort te werk in alle gevalle waar die versoek in 'n blokverwerkingstoestand is. Dit sal die volgende blok data verwerk, die vlag nagaan en stop.
Dit werk nie in gevalle waar die versoek op een of ander operasie geblokkeer word nie. Dit is waar, dit is heel waarskynlik nie jou geval nie, want volgens jou gebruik dit 'n klomp bedienerhulpbronne. Dit is moontlik dat dit nie werk in die geval van eksterne sortering en in sommige ander besonderhede nie. Maar in die algemeen behoort dit nie te wees nie, dit is 'n fout. En die enigste ding wat ek kan adviseer, is om ClickHouse op te dateer.
Hoe om reaksietyd onder leeslading te bereken?
Daar is 'n tabel wat itemaggregate stoor - verskeie tellers. Die aantal reëls is ongeveer honderd miljoen. Is dit moontlik om op 'n voorspelbare reaksietyd te reken as jy 1K RPS op 1K items gooi?
Te oordeel aan die konteks, praat ons van 'n leeslading, want daar is geen probleme met skryf nie - ten minste 'n duisend, ten minste 'n honderdduisend, en soms 'n paar miljoen reëls kan ingevoeg word.
Leesversoeke verskil baie. In geselekteerde 1 kan ClickHouse ongeveer tienduisende versoeke per sekonde uitvoer, so selfs versoeke vir 'n enkele sleutel sal reeds 'n paar hulpbronne benodig. En sulke puntnavrae sal moeiliker wees as in sommige sleutel-waarde databasisse, want vir elke lees is dit nodig om die data blok vir indeks te lees. Ons indeks spreek nie elke rekord aan nie, maar elke reeks. Dit wil sê, jy moet die hele reeks lees - dit is by verstek 8192 reëls. En jy moet die saamgeperste datablok van 64 KB tot 1 MB dekomprimeer. Tipies neem sulke puntnavrae vanaf 'n paar millisekondes. Maar dit is die maklikste opsie.
Kom ons probeer 'n paar eenvoudige rekenkunde. As jy 'n paar millisekondes met 'n duisend vermenigvuldig, kry jy 'n paar sekondes. Asof dit onmoontlik is om 'n duisend versoeke per sekonde te hou, maar in werklikheid is dit moontlik, want ons het verskeie verwerkerkerne. So, in beginsel, kan 1000 RPS ClickHouse soms hou, maar op kort versoeke, naamlik puntversoeke.
As jy die ClickHouse-groepering volgens die aantal eenvoudige versoeke moet skaal, beveel ek die eenvoudigste ding aan - vermeerder die aantal replikas en stuur versoeke na 'n ewekansige replika. As een replika vyfhonderd versoeke per sekonde bevat, wat heeltemal realisties is, sal drie replikas een en 'n half duisend hou.
Soms kan jy natuurlik ook ClickHouse instel vir die maksimum aantal puntlesings. Wat is hiervoor nodig? Die eerste is om die korreligheid van die indeks te verminder. Terselfdertyd moet dit nie tot een verminder word nie, maar op grond daarvan dat die aantal rekords in die indeks etlike miljoene of tienmiljoene per bediener sal wees. As die tabel honderd miljoen rye het, kan 64 as korreligheid gestel word.
Jy kan die grootte van die saamgeperste blok verminder. Daar is instellings hiervoor. min kompresblokgrootte, maksimum kompressieblokgrootte. Jy kan dit verminder, data herlaai, en dan sal puntnavrae vinniger wees. Maar steeds, ClickHouse is nie 'n sleutelwaarde-databasis nie. 'n Groot aantal klein versoeke is 'n las-anti-patroon.
Kirill Shvakov: Ek sal raad gee ingeval daar gewone rekenmeesters is. Dit is 'n redelik standaard situasie wanneer 'n soort toonbank in ClickHouse gestoor word. Ek het 'n gebruiker, hy is van so en so 'n land, 'n ander derde veld, en ek moet iets inkrementeel vermeerder. Neem MySQL, maak 'n unieke sleutel - in MySQL is dit 'n duplikaatsleutel, en in PostgreSQL is dit 'n konflik - en voeg 'n plusteken by. Dit sal baie beter werk.
As jy min data het, is daar nie veel sin om ClickHouse te gebruik nie. Daar is gereelde databasisse, en hulle doen 'n goeie werk daarvan.
Wat om in ClickHouse aan te pas sodat meer data in die kas is?
Kom ons stel ons die situasie voor - die bedieners het 256 GB RAM, in die daaglikse roetine neem ClickHouse ongeveer 60-80 GB, op die hoogtepunt - tot 130. Wat kan geaktiveer en aangepas word sodat meer data in die kas is en dienooreenkomstig , is daar minder ritte na die skyf?
As 'n reël doen die bladsykas van die bedryfstelsel hierdie taak goed. As jy net die bokant oopmaak, kyk daar cached of free - dit sê ook hoeveel is cache - dan kan jy sien dat al die vrye geheue vir die cache gebruik word. En wanneer hierdie data gelees word, sal dit nie vanaf die skyf gelees word nie, maar vanaf die RAM. Terselfdertyd kan ek sê dat die kas doeltreffend gebruik word, want dit is die saamgeperste data wat gekas word.
As u egter 'n paar eenvoudige navrae selfs meer wil bespoedig, is dit moontlik om 'n kas in die gedekomprimeerde data binne ClickHouse te aktiveer. Dit word genoem ongecomprimeerde kas. Stel die ongecomprimeerde kasgrootte in die config.xml-konfigurasielêer op die waarde wat u benodig - ek raai nie meer as die helfte van die gratis RAM aan nie, want die res sal onder die bladsykas gaan.
Daarbenewens is daar twee versoekvlakinstellings. Eerste instelling - gebruik ongecomprimeerde kas - sluit die gebruik daarvan in. Dit word aanbeveel om dit te aktiveer vir alle versoeke, behalwe vir swaar versoeke, wat al die data kan lees en hierdie kas kan spoel. En die tweede instelling is iets soos die maksimum aantal reëls om die kas te gebruik. Dit beperk outomaties groot versoeke sodat hulle verby die kas is.
Hoe kan ek storage_configuration vir berging in RAM instel?
In die nuwe ClickHouse-dokumentasie lees ek die afdeling wat verband hou . In die beskrywing is daar 'n voorbeeld met 'n vinnige SSD.
Ek wonder hoe jy dieselfde kan instel met volume warm geheue. En nog 'n vraag. Hoe werk select met hierdie data-organisasie, sal dit die hele stel lees of net die een op skyf, en is hierdie data in die geheue saamgepers? En hoe werk die prewhere-afdeling op so 'n data-organisasie?
Hierdie instelling beïnvloed die berging van stukke data, en hul formaat verander op geen manier nie.
Kom ons kyk van naderby.
U kan die stoor van data in die RAM opstel. Alles wat vir 'n skyf gekonfigureer is, is sy pad. Jy skep 'n tmpfs-partisie wat op een of ander pad in die lêerstelsel gemonteer is. Spesifiseer hierdie pad as die databergingspad vir die warmste partisie, stukke data begin aankom en word daar geskryf, alles is in orde.
Maar ek beveel nie aan om dit te doen nie as gevolg van lae betroubaarheid, alhoewel as jy ten minste drie replikas in verskillende datasentrums het, dan kan jy. Indien wel, sal die data herstel word. Stel jou voor dat die bediener skielik afgeskakel en weer aangeskakel is. Die gedeelte is weer gemonteer, maar daar is 'n leemte. By opstart sien die ClickHouse-bediener dat hierdie stukke ontbreek, hoewel dit volgens ZooKeeper-metadata behoort te wees. Hy kyk op watter replikas hulle is, versoek dit en laai dit af. Die data sal dus herstel word.
In hierdie sin is die stoor van data in RAM nie fundamenteel anders as om dit op skyf te stoor nie, want wanneer data op skyf geskryf word, val dit ook eers in die bladsykas en word later fisies geskryf. Dit hang af van hoe die lêerstelsel gemonteer is. Maar net vir ingeval, sal ek sê dat ClickHouse nie fsynchroniseer met invoeging nie.
In hierdie geval word die data in die RAM in presies dieselfde formaat as op die skyf gestoor. Die kiesnavraag kies die stukke wat gelees moet word op dieselfde manier, kies die vereiste datareekse in die stukke en lees dit. En prewhere werk presies dieselfde, ongeag of die data in RAM of op skyf was.
Tot watter aantal unieke waardes is Lae Kardinaliteit effektief?
Lae kardinaliteit is lastig. Dit stel datawoordeboeke saam, maar hulle is plaaslik. Eerstens is die woordeboeke verskillend vir elke stuk, en tweedens kan dit selfs binne een stuk verskil vir elke reeks. Wanneer die aantal unieke waardes 'n drempel bereik - een miljoen, dink ek - word die woordeboek eenvoudig opsy gesit en 'n nuwe een word geskep.
Die antwoord is in die algemeen: vir elke plaaslike reeks - sê maar vir elke dag - iewers tot 'n miljoen unieke waardes, is Lae Kardinaliteit effektief. Daarna sal daar net 'n terugval wees, waarin baie verskillende woordeboeke gebruik sal word, en nie net een nie. Dit sal op baie dieselfde manier werk as 'n gewone kolom van die snaartipe, miskien 'n bietjie minder doeltreffend, maar daar sal geen ernstige prestasieagteruitgang wees nie.
Wat is die beste praktyke vir voltekssoektog op 'n tabel met vyf miljard rye?
Daar is verskillende antwoorde. Die eerste is om te sê dat ClickHouse nie 'n volteks-soekenjin is nie. Daar is spesiale stelsels hiervoor, bv. и . Ek sien egter meer en meer mense wat sê hulle beweeg van Elasticsearch na ClickHouse.
Hoekom gebeur dit? Hulle verduidelik dit deur die feit dat Elasticsearch ophou om die las op sommige volumes te hanteer, begin met die bou van indekse. Indekse raak te omslagtig, en as jy bloot die data na ClickHouse oordra, blyk dit dat dit 'n paar keer meer doeltreffend gestoor word in terme van volume. Terselfdertyd was soeknavrae dikwels nie so dat dit nodig was om een of ander frase in die hele hoeveelheid data te vind, met inagneming van morfologie nie, maar heeltemal verskillendes. Byvoorbeeld, om die laaste paar uur in die logs vir 'n opeenvolging van grepe te vind.
In hierdie geval skep jy 'n indeks in ClickHouse, die eerste veld waarin die datum met tyd sal wees. En die grootste afsnypunt van data sal presies vir die datumreeks wees. Binne die geselekteerde datumreeks is dit as 'n reël reeds moontlik om 'n voltekssoektog uit te voer, selfs met behulp van die brute-force-metode met gebruik van like. Die soortgelyke stelling in ClickHouse is die doeltreffendste soortgelyke stelling wat jy kan vind. As jy 'n beter een kry, vertel my.
Maar steeds, soos 'n volledige skandering. En volledige skandering kan stadig wees, nie net op die SVE nie, maar ook op die skyf. As jy skielik een teragreep data per dag het, en jy soek 'n woord in 'n dag, sal jy 'n teragreep moet skandeer. En dit is waarskynlik op gewone hardeskywe, en as gevolg daarvan sal hulle so gelaai word dat jy nie hierdie bediener via SSH sal betree nie.
In hierdie geval is ek gereed om nog een klein truuk aan te bied. Dit is uit die kategorie eksperimenteel - dit kan werk, of dit mag nie. ClickHouse het volteks-indekse in die vorm van trigram-blomfilters. Ons kollegas by Arenadata het reeds hierdie indekse probeer, en dikwels werk dit presies soos bedoel.
Om hulle korrek te gebruik, moet jy 'n goeie begrip hê van presies hoe hulle werk: wat 'n trigram-blomfilter is en hoe om die grootte daarvan te kies. Ek kan sê dat hulle sal help vir navrae oor sommige seldsame frases, substringe wat selde in die data gevind word. In hierdie geval sal subreekse deur indekse gekies word, en minder data sal gelees word.
ClickHouse het onlangs nog meer gevorderde kenmerke bygevoeg vir voltekssoektog. Dit is eerstens die soektog na 'n klomp substringe gelyktydig in een pas, insluitend hooflettersensitiewe, hoofletteronsensitiewe, UTF-8-ondersteunde of ASCII-alleen opsies. Kies die mees doeltreffende een wat jy nodig het.
Daar is ook gesoek na verskeie gewone uitdrukkings in een pas. Jy hoef nie X soos een substring of X soos 'n ander substring te skryf nie. Skryf dadelik, en alles word so doeltreffend moontlik gedoen.
Derdens is daar nou 'n benaderde soektog na regexps en 'n benaderde soektog vir substringe. As iemand 'n woord met 'n tikfout geskryf het, sal dit vir die maksimum passing gesoek word.
Wat is die beste manier om toegang tot ClickHouse vir 'n groot aantal gebruikers te organiseer?
Vertel ons hoe om toegang vir 'n groot aantal verbruikers en ontleders die beste te organiseer. Hoe om 'n tou te vorm, maksimum gelyktydige navrae te prioritiseer, en met watter gereedskap?
As die groep groot genoeg is, sal 'n goeie oplossing wees om nog twee bedieners in te samel, wat die toegangspunt vir ontleders sal word. Dit wil sê, moenie ontleders in spesifieke groepskerwe toelaat nie, maar skep eenvoudig twee leë bedieners, sonder data, en stel reeds toegangsregte daarop. Terselfdertyd word gebruikersinstellings na afgeleë bedieners oorgedra tydens verspreide versoeke. Dit wil sê, jy konfigureer alles op hierdie twee bedieners, en die instellings het 'n effek op die hele groep.
In beginsel is hierdie bedieners sonder data, maar die hoeveelheid RAM op hulle is baie belangrik vir die uitvoering van versoeke. Skyf kan ook vir tydelike data gebruik word as eksterne samevoeging of eksterne sortering geaktiveer is.
Dit is belangrik om te kyk na die instellings wat met alle moontlike limiete geassosieer word. As ek nou as 'n ontleder na die Yandex.Metrics-kluster gaan en 'n navraag stel kies telling uit treffers, dan sal ek dadelik 'n uitsondering gegee word dat ek nie aan die versoek kan voldoen nie. Die maksimum aantal rye wat ek mag skandeer is honderd biljoen, en daar is in totaal vyftig biljoen op die groep in een tabel. Dit is die eerste beperking.
Kom ons sê ek verwyder die limiet op die aantal rye, en voer die navraag weer uit. Dan sal ek die volgende uitsondering sien - die instelling is geaktiveer kragindeks volgens datum. Ek kan nie die navraag laat loop as ek nie 'n datumreeks gespesifiseer het nie. Jy hoef nie op ontleders staat te maak om dit met die hand in te voer nie. 'n Tipiese geval - 'n datumreeks word geskryf waar gebeurtenisdatum tussen 'n week is. En dan het hulle net nie 'n hakie daar gespesifiseer nie, en in plaas van en blyk dit of - of URL-passing te wees. As daar geen beperking is nie, sal dit die URL-kolom gaan deurkruip en 'n klomp hulpbronne mors.
Boonop het ClickHouse twee prioriteitsinstellings. Ongelukkig is hulle baie primitief. Een word eenvoudig genoem prioriteit. As prioriteit ≠ 0, en versoeke met 'n sekere prioriteit uitgevoer word, maar 'n versoek met 'n prioriteitswaarde wat laer is, wat 'n hoër prioriteit beteken, word uitgevoer, dan is 'n versoek met 'n prioriteitswaarde groter as, wat 'n laer prioriteit beteken, eenvoudig opgeskort en glad nie sal werk gedurende hierdie tyd nie.
Dit is 'n baie rowwe omgewing en is nie geskik vir situasies waar daar 'n konstante las op die groep is nie. Maar as jy kort, impulsiewe versoeke het wat belangrik is, en die groep is meestal ledig, sal hierdie instelling werk.
Die volgende prioriteitinstelling word genoem OS draad prioriteit. Dit stel bloot alle versoekuitvoerdrade bloot aan die goeie waarde vir die Linux-skeduleerder. Dit werk so-so, maar werk steeds. As jy die minimum mooi waarde stel - dit is die grootste waarde, en dus die laagste prioriteit - en stel -19 vir hoë prioriteit versoeke, dan sal die SVE lae prioriteit versoeke ongeveer vier keer minder as hoë prioriteits verbruik.
Jy moet ook die maksimum navraaguitvoertyd stel - sê, vyf minute. Die minimum versoekuitvoerspoed is die coolste ding. Hierdie instelling bestaan al lank, en dit is nie net nodig om te beweer dat ClickHouse nie vertraag nie, maar om dit te dwing.
Stel jou voor jy stel op: as 'n navraag minder as een miljoen rye per sekonde verwerk, kan jy dit nie doen nie. Dit bring ons goeie naam, ons goeie databasis oneer aan. Kom ons verbied dit net. Daar is eintlik twee instellings. Een word genoem min uitvoering spoed - in reëls per sekonde, en die tweede word time-out genoem voordat die minimum uitvoeringspoed nagegaan word - vyftien sekondes by verstek. Dit wil sê, vyftien sekondes is moontlik, en dan, as dit stadig is, gooi dan net 'n uitsondering - staak die versoek.
Jy moet ook kwotas opstel. ClickHouse het 'n ingeboude kwota-funksie wat hulpbronverbruik tel. Maar, ongelukkig, nie yster hulpbronne soos SVE, skywe, maar logiese kinders - die aantal verwerkte versoeke, lyne en grepe gelees. En jy kan byvoorbeeld 'n maksimum van honderd versoeke binne vyf minute en 'n duisend versoeke per uur opstel.
Hoekom is dit belangrik? Omdat sommige van die ontledingsversoeke met die hand direk vanaf die ClickHouse-kliënt uitgevoer sal word. En alles sal goed wees. Maar as jy gevorderde ontleders in jou maatskappy het, sal hulle 'n draaiboek skryf, en daar kan 'n fout in die draaiboek wees. En hierdie fout sal veroorsaak dat die versoek in 'n oneindige lus uitgevoer word. Dit is wat beskerm moet word.
Is dit moontlik om die resultate van een versoek aan tien kliënte te gee?
Ons het verskeie gebruikers wat daarvan hou om terselfdertyd met baie groot versoeke in te kom. Die versoek is groot, in beginsel word dit vinnig uitgevoer, maar as gevolg van die feit dat daar baie sulke versoeke op dieselfde tyd is, raak dit baie pynlik. Is dit moontlik om dieselfde versoek, wat tien keer in 'n ry opgedaag het, een keer uit te voer en die resultaat aan tien kliënte te gee?
Die probleem is dat ons nie kasresultate of intermediêre datakas het nie. Daar is 'n bladsykas van die bedryfstelsel, wat jou sal toelaat om nie weer data van die skyf af te lees nie, maar die data sal ongelukkig steeds gedekomprimeer, gedeserialiseer en herverwerk word.
Ek wil dit op een of ander manier vermy, hetsy deur tussentydse data te kas, of deur soortgelyke navrae in 'n soort tou op te stel en 'n kas van resultate by te voeg. Nou het ons een trekversoek in ontwikkeling, wat 'n versoekkas byvoeg, maar slegs vir subversoeke in die in- en aansluitafdelings - dit wil sê, die oplossing is minderwaardig.
Ons het egter ook so 'n situasie. 'n Besonder kanonieke voorbeeld is versoeke met paginering. Daar is 'n verslag, dit het verskeie bladsye, en daar is 'n limiet 10 versoek. Dan dieselfde ding, maar limiet 10,10. Dan nog 'n bladsy. En die vraag is, hoekom tel ons dit alles elke keer? Maar nou is daar geen oplossing nie, en daar is geen manier om dit te vermy nie.
Daar is 'n alternatiewe oplossing wat as 'n syspan langs ClickHouse geplaas word - .
Kirill Shvakov: ClickHouse Proxy het 'n ingeboude koersbeperker en 'n ingeboude resultatekas. Baie instellings is daar gemaak, want 'n soortgelyke taak is opgelos. Proxy laat jou toe om versoeke te beperk deur hulle in tou te plaas, en instel hoe lank die versoekkas leef. As die versoeke regtig dieselfde was, sal die Proxy dit baie keer gee en slegs een keer na ClickHouse gaan.
Nginx het ook 'n kas in die gratis weergawe en dit sal ook werk. Nginx het selfs instellings sodat as versoeke terselfdertyd inkom, dit ander sal laat staan totdat een voltooi is. Maar dit is in ClickHouse Proxy dat die instellings baie beter gemaak word. Dit is spesifiek vir ClickHouse gemaak, spesifiek vir hierdie versoeke, so dit is meer geskik. Wel, dit is maklik om op te stel.
Wat van asinchroniese bewerkings en gematerialiseerde sienings?
Daar is so 'n probleem dat bedrywighede met die vervangingsenjin asynchronies is - data word eers geskryf, dan stort dit in duie. As 'n gematerialiseerde tablet met sommige aggregate onder die tablet woon, sal duplikate daarop geskryf word. En as daar geen komplekse logika is nie, sal die data gedupliseer word. Wat kan daaraan gedoen word?
Daar is 'n ooglopende oplossing - om 'n sneller op 'n spesifieke matview-klas te implementeer tydens 'n asynchrone ineenstortingsoperasie. Is daar enige "silwer bullets"-planne om sulke funksionaliteit te implementeer?
Dit is die moeite werd om te verstaan hoe deduplisering werk. Wat ek gaan sê hou nie verband met die vraag nie, maar dit is die moeite werd om te onthou vir ingeval.
Wanneer in 'n herhaalde tabel ingevoeg word, is daar deduplisering van die hele ingevoegde blokke. As jy dieselfde blok wat dieselfde aantal van dieselfde rye in dieselfde volgorde bevat, weer invoeg, dan word die data gededupliseer. Jy sal "Ok" kry in reaksie op die insetsel, maar een bondel data sal eintlik geskryf word en dit sal nie gedupliseer word nie.
Dit is nodig vir sekerheid. As jy "Ok" kry tydens die invoeging, dan is jou data ingevoeg. As u 'n fout van ClickHouse ontvang, word dit nie ingevoeg nie, en u moet die invoeging herhaal. Maar as die verbinding verbreek word tydens die invoeging, dan weet jy nie of die data ingevoeg is of nie. Die enigste opsie is om die insetsel weer te herhaal. As die data werklik ingevoeg is en jy het dit weer ingevoeg, is daar blokdeduplisering. Dit is nodig om duplikate te vermy.
En dit is ook belangrik hoe dit werk vir gematerialiseerde sienings. As die data gededupliseer is toe dit in die hooftabel ingevoeg is, sal hulle ook nie na die gematerialiseerde aansig gaan nie.
Nou oor die vraag. Jou situasie is meer ingewikkeld omdat jy duplikate van individuele reëls skryf. Dit wil sê, nie die hele pak is gedupliseer nie, maar spesifieke lyne, en hulle val in die agtergrond ineen. Inderdaad, die data sal ineenstort in die hooftabel, en die nie-ingevou sal na die gematerialiseerde aansig gaan, en niks sal met gematerialiseerde aansigte gebeur tydens samesmelting nie. Want 'n gematerialiseerde siening is niks meer as 'n sneller op insetsel nie. Niks anders gebeur daarmee tydens ander operasies nie.
En ek kan nie gelukkig wees hier nie. Dit is net nodig om na 'n spesifieke oplossing vir hierdie saak te soek. Is dit byvoorbeeld moontlik om dit in 'n gematerialiseerde aansig te vervang, en die dedupliseringsmetode sal miskien op dieselfde manier werk. Maar ongelukkig nie altyd nie. As dit saamvoeg, sal dit nie werk nie.
Kirill Shvakov: Ons het ook op 'n tyd beenbou gehad. Daar was 'n probleem dat daar advertensie-indrukke is, en daar is 'n paar data wat ons intyds kan wys - dit is net indrukke. Hulle word selde gedupliseer, maar as hulle dit doen, sal ons hulle in elk geval later ineenvou. En daar was dinge wat nie gedupliseer kan word nie – kliks en hierdie hele storie. Maar ek wou hulle ook amper dadelik wys.
Hoe is gematerialiseerde sienings gemaak? Daar was aansigte waar dit direk geskryf is - daar is 'n rekord in rou data, en dit is geskryf in aansigte. Daar, op 'n stadium, is die data nie baie korrek nie, hulle word gedupliseer, ensovoorts. En daar is die tweede deel van die tabel, waar hulle presies dieselfde lyk as die gematerialiseerde sienings, dit wil sê, hulle is presies dieselfde in struktuur. Af en toe herbereken ons die data, tel die data sonder duplikate, skryf aan daardie tabelle.
Ons het deur die API gegaan - dit sal nie met die hand in ClickHouse werk nie. En die API lyk: wanneer ek die datum van die laaste toevoeging tot die tabel het, waar dit gewaarborg is dat die korrekte data reeds bereken is, en dit maak 'n versoek na een tabel en na 'n ander tabel. Van een versoek kies tot 'n sekere hoeveelheid tyd, en van die ander kry dit wat nog nie bereken is nie. En dit werk, maar nie deur middel van een ClickHouse nie.
As jy 'n soort API het - vir ontleders, vir gebruikers - dan is dit in beginsel 'n opsie. Jy tel altyd, tel altyd. Dit kan een keer per dag of op 'n ander tyd gedoen word. Jy kies self die reeks wat jy nie nodig het nie en nie krities is nie.
ClickHouse het baie logs. Hoe kan ek alles sien wat in 'n oomblik met die bediener gebeur?
ClickHouse het 'n baie groot aantal verskillende logs, en hierdie getal neem toe. In nuwe weergawes is sommige van hulle selfs by verstek geaktiveer, in ouer weergawes moet dit geaktiveer word wanneer dit opgedateer word. Daar is egter meer en meer van hulle. Ek wil uiteindelik sien wat nou met my bediener gebeur, miskien op een of ander opsommingspaneelbord.
Het jy in die ClickHouse-span, of in die spanne van jou vriende, wat die een of ander funksionaliteit van klaargemaakte dashboards ondersteun wat hierdie logs as 'n voltooide produk sal vertoon? Uiteindelik is dit wonderlik om net na die logboeke in ClickHouse te kyk. Maar dit sal baie gaaf wees as dit reeds in die vorm van 'n dashboard voorberei is. Ek sou hoog raak hieroor.
Daar is dashboards, hoewel hulle nie gestandaardiseer is nie. Ons het ongeveer 60 spanne in ons maatskappy wat ClickHouse gebruik, en die vreemdste ding is dat baie van hulle dashboards het wat hulle self gemaak het, en 'n bietjie anders. Sommige spanne gebruik die interne installasie van Yandex.Cloud. Daar is 'n paar klaargemaakte verslae, hoewel nie almal nodig is nie. Ander het hulle s'n.
My kollegas van Metrica het hul eie dashboard in Grafana, en ek het myne vir hul eie cluster. Ek kyk na dinge soos 'n kas-treffer vir 'n serif-kas. En nog moeiliker is dat ons verskillende gereedskap gebruik. Ek het my dashboard geskep op 'n baie ou instrument genaamd Graphite-web. Hy is heeltemal lelik. En ek gebruik dit steeds so, hoewel Grafana seker geriefliker en mooier sou wees.
Die basiese ding in dashboards is dieselfde. Dit is stelselstatistieke vir die groepering: SVE, geheue, skyf, netwerk. Ander is die aantal gelyktydige versoeke, die aantal gelyktydige samesmeltings, die aantal versoeke per sekonde, die maksimum aantal stukke vir MergeTree-tabelpartisies, die replikasievertraging, die grootte van die replikasie-tou, die aantal rye wat per sekonde ingevoeg word, die aantal blokkies wat per sekonde ingevoeg word. Dit is al wat nie uit die logboeke verkry word nie, maar uit die metrieke.
Vladimir Kolobaev: Alexey, ek wil graag 'n bietjie regstel. Daar is Grafana. Grafana het 'n databron wat ClickHouse is. Dit wil sê, ek kan versoeke van Grafana direk na ClickHouse rig. ClickHouse het 'n tabel met logs, dit is dieselfde vir almal. As gevolg hiervan wil ek toegang tot hierdie logtabel in Grafana verkry en die versoeke sien wat my bediener toepas. Dit sal wonderlik wees om so 'n paneelbord te hê.
Ek het dit self gery. Maar ek het 'n vraag - as dit alles gestandaardiseer is, en Grafana word deur almal gebruik, hoekom het Yandex nie so 'n amptelike dashboard nie?
Kirill Shvakov: Trouens, die databron wat ClickHouse nou ondersteun Altinity. En ek wil net 'n vektor gee van waar om te grawe en wie om te stoot. Jy kan hulle vra, want Yandex maak steeds ClickHouse, en nie die storie daaromtrent nie. Altinity is die hoofmaatskappy wat tans ClickHouse bevorder. Hulle sal hom nie verlaat nie, maar sal hom ondersteun. Want in beginsel, om 'n dashboard na die Grafana-webwerf op te laai, hoef jy net te registreer en dit op te laai - daar is geen spesifieke probleme nie.
Alexey Milovidov: Die afgelope jaar het ClickHouse baie navraagprofielfunksies bygevoeg. Daar is maatstawwe vir elke hulpbrongebruikversoek. En meer onlangs is 'n selfs laer-vlak navraagprofieler bygevoeg om te sien waar die navraag elke millisekonde spandeer. Maar om hierdie funksionaliteit te gebruik, moet ek die konsolekliënt oopmaak en 'n navraag intik wat ek aanhou vergeet. Ek het dit iewers gebêre en vergeet altyd waar presies.
Ek wens daar was 'n instrument wat net sê - hier is jou swaar navrae, gegroepeer volgens navraagklas. Ek het op een geklik, en hulle sou vir my sê dat dit dus swaar is. Nou is daar nie so 'n oplossing nie. En dis eintlik nogal vreemd dat wanneer mense my vra: “Sê vir my, is daar enige klaargemaakte dashboards vir Grafana?” van Kostyan. Ek weet nie wat dit is nie, ek het dit nie self gebruik nie.”
Hoe om merdzhi te beïnvloed sodat die bediener nie in OOM val nie?
Ek het 'n tabel, daar is net een partisie in die tabel, dit is ReplaceingMergeTree. Ek skryf al vier jaar lank data daaraan. Ek moes 'n verandering daarin maak en sommige data uitvee.
Ek het dit gedoen, en in die loop van die verwerking van hierdie versoek, is al die geheue op alle bedieners in die cluster geëet, en al die bedieners in die cluster het saam in OOM gegaan. Toe staan hulle almal saam op, begin om dieselfde operasie, hierdie datablok saam te voeg, en val weer in OOM. Toe staan hulle weer op en val weer neer. En hierdie ding het nie opgehou nie.
Toe blyk dit dat dit eintlik 'n fout is wat die ouens reggemaak het. Dit is baie cool, baie dankie. Maar die oorblyfsel het oorgebly. En nou, as ek dink oor die behoefte om 'n sekere samesmelting in die tabel te doen, het ek 'n vraag - hoekom kan ek nie hierdie samesmeltings neem en hulle op een of ander manier beïnvloed nie? Beperk hulle byvoorbeeld deur die hoeveelheid RAM wat benodig word, of, in beginsel, deur hul aantal, wat hierdie spesifieke tabel sal verwerk.
Ek het 'n tabel genaamd "Metrics", verwerk dit asseblief vir my in twee strome. Nie nodig om tien of vyf samesmeltings in parallel te produseer nie, doen dit in twee. Ek dink in twee het ek genoeg geheue, maar dit is dalk nie genoeg om tien te verwerk nie. Hoekom bly vrees? Want die tabel groei, en ek sal eendag 'n situasie teëkom wat in beginsel nie meer as gevolg van 'n fout is nie, maar as gevolg van die feit dat die data in so 'n groot hoeveelheid sal verander dat ek eenvoudig nie genoeg geheue op het nie. die bediener. En dan sal die bediener tydens die samesmelting in OOM val. Boonop kan ek die mutasie kanselleer, maar die samesmelting is weg.
Jy weet, wanneer die bediener saamsmelt, sal die bediener nie in OOM val nie, want wanneer dit saamgevoeg word, word die hoeveelheid RAM slegs vir een klein datareeks gebruik. Alles sal dus goed wees, ongeag die hoeveelheid data.
Vladimir Kolobaev: Goed. Hier is die oomblik so dat nadat ons 'n foutoplossing gemaak het, ek 'n nuwe weergawe vir myself afgelaai het, en op 'n ander tafel, kleiner, waar daar baie partisies is, het ek 'n soortgelyke bewerking gedoen. En tydens die samesmelting is ongeveer 100 GB RAM op die bediener verbrand. Ek het 150 besig gehad, 100 geëet, en daar was 'n venster van 50 GB oor, so ek het nie in OOM geval nie.
Wat beskerm my tans om in OOM te val as dit regtig 100 GB RAM verbruik? Wat om te doen in 'n situasie as die RAM op die merdzh skielik opraak?
Alexey Milovidov: Daar is so 'n probleem dat die verbruik van RAM nie beperk is tot merdzhi nie. En die tweede probleem is dat as 'n samesmelting toegewys is, dan moet dit uitgevoer word, want dit word na die replikasielog geskryf. Die replikasielogboek is die aksies wat nodig is om die replika in 'n konsekwente toestand te bring. As jy nie handmatige manipulasies doen wat hierdie replikasielogboek sal terugrol nie, sal die samevoeging op een of ander manier uitgevoer moet word.
Natuurlik sal dit nie oorbodig wees om 'n beperking op die RAM te hê nie, wat "net ingeval" teen OOM beskerm. Dit sal nie die samesmelting help nie, dit sal weer begin, die een of ander drempel bereik, 'n uitsondering gooi en dan weer begin - niks goeds sal daarvan kom nie. Maar in beginsel sou dit nuttig wees om hierdie beperking in te stel.
Hoe sal die ontwikkeling van die Golang-bestuurder vir ClickHouse plaasvind?
Die Golang-bestuurder wat deur Kirill Shvakov geskryf is, word nou amptelik deur die ClickHouse-span ondersteun. Hy , hy is nou groot en eg.
'n Klein nota. Daar is 'n wonderlike en geliefde bewaarplek van normale vorme van oneindige orde - dit is Vertica. Hulle het ook hul eie amptelike luislangbestuurder, wat deur Vertica-ontwikkelaars onderhou word. En 'n paar keer het dit gebeur dat die weergawes van die stoor en die weergawes van die bestuurder redelik skielik geskei het, en die bestuurder het op 'n stadium opgehou werk. En die tweede punt. Ondersteuning vir hierdie amptelike bestuurder, lyk dit vir my, word onderhou deur die "tepel"-stelsel - jy skryf 'n probleem aan hulle, en dit hang vir ewig.
Ek het twee vrae. Nou is Kirill se Golang-bestuurder 'n byna verstek manier om vanaf Golang met ClickHouse te kommunikeer. Tensy iemand nog deur die http-koppelvlak kommunikeer, want hy hou so baie daarvan. Hoe sal hierdie drywer ontwikkel word? Sal dit gesinchroniseer word met 'n paar veranderinge in die bewaarplek self? En wat is die prosedure om die kwessie te oorweeg?
Kirill Shvakov: Die eerste is hoe alles burokraties gereël word. Hierdie punt is nie bespreek nie, so ek het niks om te antwoord nie.
Om die vraag oor die probleem te beantwoord, benodig ons 'n bietjie geskiedenis van die bestuurder. Ek het vir 'n maatskappy gewerk wat baie data gehad het. Dit was 'n advertensiedraaier met 'n groot aantal gebeurtenisse wat iewers gestoor moes word. En op 'n stadium het ClickHouse verskyn. Ons het data daarin gegooi, en eers was alles goed, maar toe val ClickHouse. Op daardie tydstip het ons besluit dat ons dit nie nodig het nie.
’n Jaar later het ons teruggekeer na die idee om ClickHouse te gebruik, en ons moes op een of ander manier data daar skryf. Die inset was dit - die yster is baie swak, daar is min hulpbronne. Maar ons het nog altyd so gewerk, en daarom het ons na die inheemse protokol gekyk.
Aangesien ons aan Go gewerk het, was dit duidelik dat ons 'n Go-bestuurder nodig het. Ek het dit amper voltyds gedoen – dit was my werkstaak. Tot op 'n sekere punt het ons dit ter sprake gebring, en in beginsel het niemand verwag dat iemand anders as ons dit sou gebruik nie. Toe kom CloudFlare met presies dieselfde probleem, en vir 'n rukkie het ons baie glad met hulle gewerk, want hulle het dieselfde take gehad. En ons het dit beide in ClickHouse self en in die bestuurder gedoen.
Op 'n stadium het ek eenvoudig opgehou om dit te doen, want my aktiwiteit in terme van ClickHouse en met werk het 'n bietjie verander. Daarom is kwessies nie gesluit nie. Mense wat self iets nodig het, verbind hulle van tyd tot tyd tot die bewaarplek. Dan kyk ek na die trekversoek en soms redigeer ek selfs iets self, maar dit gebeur min.
Ek wil terugkeer na die bestuurder. 'n Paar jaar gelede, toe hierdie hele ding begin het, was ClickHouse ook anders en met verskillende kenmerke. Nou is daar 'n begrip van hoe om die bestuurder te hermaak sodat dit goed is. As dit gebeur, sal weergawe 2 in elk geval onversoenbaar wees as gevolg van opgehoopte krukke.
Ek weet nie hoe om dit te reël nie. Ek het self nie baie tyd nie. As sommige mense die bestuurder klaarmaak, kan ek hulle help en vir hulle sê wat om te doen. Maar dit is die aktiewe deelname van Yandex aan die ontwikkeling van die projek wat nog op geen manier bespreek is nie.
Alexey Milovidov: Trouens, daar is nog geen burokrasie oor hierdie bestuurders nie. Die enigste ding is dat hulle na 'n amptelike organisasie geskuif word, dit wil sê, hierdie bestuurder word erken as die amptelike verstekoplossing vir Go. Daar is 'n paar ander bestuurders, maar hulle kom apart.
Ons het geen ontwikkeling vir hierdie bestuurders binne nie. Die vraag is of ons 'n individu kan aanstel, nie spesifiek vir hierdie bestuurder nie, maar vir die ontwikkeling van alle gemeenskapsbestuurders, of kan ons iemand buite kry.
Eksterne woordeboek word nie na herlaai met lazy_load aangeskakel nie. Wat om te doen?
Ons het die lazy_load-instelling geaktiveer, en nadat die bediener herbegin is, styg die woordeboek self nie. Dit word eers verhoog nadat die gebruiker toegang tot hierdie woordeboek verkry het. En dit gooi 'n fout op die eerste oproep. Is dit moontlik om op een of ander manier outomaties woordeboeke met ClickHouse te laai, of moet jy altyd self die gereedheid daarvan beheer sodat gebruikers nie foute ontvang nie?
Miskien het ons 'n ou weergawe van ClickHouse, so die woordeboek is nie outomaties gelaai nie. Kan dit wees?
Eerstens kan woordeboeke gedwonge gelaai word deur die navraag te gebruik stelsel herlaai woordeboeke. Tweedens, oor die fout - as die woordeboek reeds gelaai is, sal die navrae werk op die data wat gelaai is. As die woordeboek nog nie gelaai is nie, sal dit reg op die tyd van die versoek gelaai word.
Vir swaar woordeboeke is dit nie baie gerieflik nie. Byvoorbeeld, jy moet 'n miljoen rye van MySQL gaan haal. Iemand maak 'n eenvoudige keuse, maar hierdie keuse sal vir dieselfde miljoen rye wag. Hier is twee oplossings. Die eerste is om lazy_load af te skakel. Die tweede is wanneer die bediener styg, voordat die las daarop aangeskakel word, doen stelsel herlaai woordeboek of voer net 'n navraag uit wat 'n woordeboek gebruik. Dan sal die woordeboek gelaai word. Jy moet die beskikbaarheid van woordeboeke beheer met die lazy_load-instelling geaktiveer, want ClickHouse trek hulle nie outomaties op nie.
Die antwoord op die laaste vraag is óf die weergawe is oud, óf dit moet ontfout word.
Wat van die feit dat stelselherlaaiwoordeboeke nie een van die baie woordeboeke laai as ten minste een van hulle met 'n fout ineenstort nie?
Daar is nog 'n vraag oor stelselherlaaiwoordeboeke. Ons het twee woordeboeke - een is nie gelaai nie, die tweede is gelaai. Stelsel herlaai woordeboeke in hierdie geval laai geen woordeboek nie, en jy moet 'n spesifieke een op sy naam laai met behulp van stelsel herlaai woordeboek. Hou dit ook verband met ClickHouse-weergawe?
Ek wil asseblief. Hierdie gedrag het verander. Dus, as jy ClickHouse opdateer, sal dit ook verander. As jy nie tevrede is met die huidige gedrag nie stelsel herlaai woordeboeke, werk op, en kom ons hoop dat dit ten goede verander.
Is daar 'n manier om die besonderhede in die ClickHouse-konfigurasie op te stel, maar dit nie op foute aan te lig nie?
Die volgende vraag gaan oor foute wat met die woordeboek verband hou, naamlik besonderhede. Ons het die verbindingbesonderhede in die ClickHouse-konfigurasie na die woordeboek geregistreer, en in die geval van 'n fout, ontvang ons hierdie besonderhede en die wagwoord in reaksie.
Ons het hierdie fout opgelos deur besonderhede by die ODBC-bestuurderkonfigurasie by te voeg. Is daar 'n manier om die besonderhede in die ClickHouse-konfigurasie op te stel, maar om nie hierdie besonderhede op foute te wys nie?
Hier is die oplossing regtig - om hierdie geloofsbriewe in odbc.ini te spesifiseer, en in ClickHouse self, spesifiseer slegs die ODBC-databronnaam. Dit sal nie vir ander woordeboekbronne gebeur nie - nie vir 'n woordeboek met MySQL nie, en ook nie vir die res nie, jy behoort nie die wagwoord in die foutboodskap te sien nie. Vir ODBC sal ek ook kyk - as daar so iets is, moet jy dit net verwyder.
Bonus: agtergronde vir Zuma van byeenkomste
Deur op die prentjie te klik vir die mees volhardende lesers, sal bonus agtergronde van byeenkomste oopmaak. Om die vuur te blus saam met Avito se tegnologie-gelukbringers, oorleg met kollegas van die stelseladministrateur se kamer of 'n ou-skool rekenaarklub, en hou 'n daaglikse onder die brug teen die agtergrond van graffiti.
Bron: will.com