Aprila so se Avitovi inženirji zbrali na spletnih srečanjih z glavnim razvijalcem ClickHouse Alexeyjem Milovidovim in Kirillom Shvakovom, razvijalcem Golang iz Integrosa. Pogovarjali smo se o tem, kako uporabljamo sistem za upravljanje baz podatkov in s kakšnimi težavami se srečujemo.
Na podlagi srečanja smo pripravili članek z odgovori strokovnjakov na naša vprašanja in vprašanja občinstva o varnostnih kopijah, ponovnem razdeljevanju podatkov, zunanjih slovarjih, gonilniku Golang in posodabljanju različic ClickHouse. Morda bo koristen razvijalcem, ki že aktivno delajo z Yandex DBMS in jih zanima njegova sedanjost in prihodnost. Privzeto so odgovori Alexey Milovidov, razen če ni drugače napisano.
Bodite previdni, pod rezom je veliko besedila. Upamo, da vam bo vsebina z vprašanji pomagala pri navigaciji.
Vsebina
Če ne želite brati besedila, si lahko ogledate posnetek druženja . Časovne kode so v prvem komentarju pod videom.
ClickHouse se nenehno posodablja, naši podatki pa ne. Kaj storiti glede tega?
ClickHouse se nenehno posodablja, naši podatki, ki so bili optimizirani dokončno obdelani, pa niso posodobljeni in so v varnostni kopiji.
Recimo, da smo imeli težave in so se podatki izgubili. Odločili smo se za obnovitev in izkazalo se je, da se stare particije, ki so shranjene na rezervnih strežnikih, zelo razlikujejo od trenutno uporabljene različice ClickHouse. Kaj storiti v takšni situaciji in ali je to mogoče?
Situacija, v kateri ste obnovili podatke iz varnostne kopije v stari obliki, vendar se ta ne poveže z novo različico, je nemogoča. Skrbimo, da format podatkov v ClickHouse vedno ostane združljiv za nazaj. To je veliko bolj pomembno kot povratna združljivost v funkcionalnosti, če se je vedenje redko uporabljene funkcije spremenilo. Nova različica ClickHouse bi morala imeti vedno možnost branja podatkov, ki so shranjeni na disku. To je zakon.
Kakšne so trenutne najboljše prakse za varnostno kopiranje podatkov iz ClickHouse?
Kako narediti varnostne kopije, glede na to, da imamo optimizirane končne operacije, ogromno bazo terabajtov in podatke, ki se ažurirajo recimo zadnje tri dni, potem pa se z njimi ne zgodijo nobeni postopki?
Lahko naredimo svojo rešitev in napišemo na bash: zberi te varnostne kopije na tak in tak način. Mogoče ni treba ničesar berglati in je bilo kolo izumljeno že zdavnaj?
Začnimo z najboljšimi praksami. Moji kolegi vedno svetujejo, da jih v odgovor na vprašanja o varnostnih kopijah spomnim na storitev Yandex.Cloud, kjer je ta težava že rešena. Zato ga uporabite, če je mogoče.
Ne obstaja popolna rešitev za varnostne kopije, stoodstotno vgrajena v ClickHouse. Obstaja nekaj praznih delov, ki jih je mogoče uporabiti. Če želite dobiti popolno rešitev, boste morali bodisi ročno malo poigrati ali ustvariti ovoje v obliki skriptov.
Začel bom z najpreprostejšimi rešitvami in končal z najbolj sofisticiranimi, odvisno od količine podatkov in velikosti gruče. Večji kot je grozd, bolj zapletena postane rešitev.
Če tabela s podatki zavzema le nekaj gigabajtov, lahko varnostno kopirate tako:
- Shrani definicijo tabele, tj. metapodatke − pokaži ustvari tabelo.
- Naredite izmet z odjemalcem ClickHouse - izberite * iz tabele vložiti. Privzeto boste prejeli datoteko v formatu TabSeparated. Če želite biti učinkovitejši, lahko to storite v izvornem formatu.
Če je količina podatkov večja, bo varnostna kopija vzela več časa in veliko prostora. To se imenuje logična varnostna kopija; ni vezana na format podatkov ClickHouse. Če je, lahko v skrajnem primeru naredite varnostno kopijo in jo naložite v MySQL za obnovitev.
Za zahtevnejše primere ima ClickHouse vgrajeno možnost ustvarjanja posnetka particij v lokalnem datotečnem sistemu. Ta funkcija je na voljo kot zahteva spremeni zamrznitev particije tabele. Ali preprosto spremeni zamrznitev tabele - to je posnetek celotne tabele.
Posnetek bo ustvarjen konsistentno za eno tabelo na enem shardu, kar pomeni, da na ta način ni mogoče ustvariti konsistentnega posnetka celotne gruče. Toda za večino nalog te potrebe ni in dovolj je, da izvedete zahtevo na vsakem delcu in dobite dosleden posnetek. Izdelan je v obliki trdih povezav in zato ne zavzame dodatnega prostora. Nato kopirate ta posnetek v strežnik za varnostno kopiranje ali v shrambo, ki jo uporabljate za varnostne kopije.
Obnovitev takšne varnostne kopije je precej enostavna. Najprej ustvarite tabele z uporabo obstoječih definicij tabel. Nato kopirajte shranjene posnetke particij v Directory-Detached za te tabele in zaženite poizvedbo pritrdite particijo. Ta rešitev je zelo primerna za največje količine podatkov.
Včasih potrebujete nekaj še bolj kul - v primerih, ko imate na desetine ali celo stotine terabajtov na vsakem strežniku in na stotine strežnikov. Tukaj je rešitev, ki sem jo pobral od kolegov iz Yandex.Metrice. Ne priporočam vsem – preberite in presodite sami, ali je primerna ali ne.
Najprej morate ustvariti več strežnikov z velikimi diskovnimi policami. Nato na teh strežnikih dvignite več strežnikov ClickHouse in jih konfigurirajte tako, da bodo delovali kot druga replika za iste drobce. Nato uporabite datotečni sistem ali kakšno orodje na teh strežnikih, ki vam omogoča ustvarjanje posnetkov. Tukaj sta dve možnosti. Prva možnost so posnetki LVM, druga možnost je ZFS na Linuxu.
Po tem morate vsak dan ustvariti posnetek, ki bo ležal in zavzel nekaj prostora. Seveda, če se podatki spremenijo, se bo količina prostora sčasoma povečala. Ta posnetek je mogoče kadar koli odstraniti in obnoviti podatke, tako čudna rešitev. Poleg tega moramo te replike omejiti tudi v konfiguraciji, da ne bodo poskušale postati vodilne.
Ali bo mogoče organizirati nadzorovano zaostajanje replik v jaških?
Letos načrtujete izdelavo jaškov v ClickHouse. Ali bo v njih mogoče organizirati nadzorovano zaostajanje replik? Z njim bi se radi zaščitili pred negativnimi scenariji s spremembami in drugimi spremembami.
Ali je mogoče narediti nekakšno vrnitev za spremembe? Na primer, v obstoječem jašku vzemite in povejte, da do tega trenutka uveljavljate spremembe in od tega trenutka nehate uveljavljati spremembe?
Če je ukaz prišel v našo gručo in jo zlomil, potem imamo pogojno repliko z enournim zamikom, kjer lahko rečemo, da jo uporabimo trenutno, vendar ne bomo uporabili sprememb zanjo zadnjih deset minut?
Najprej o nadzorovanem zamiku replik. Bila je taka zahteva uporabnikov in na Githubu smo ustvarili težavo z zahtevo: "Če kdo to potrebuje, mu je všeč, daj srce." Nihče ni dostavil in zadeva je bila zaključena. Vendar pa lahko to priložnost dobite že z nastavitvijo ClickHouse. Res je, šele od različice 20.3 naprej.
ClickHouse nenehno izvaja združevanje podatkov v ozadju. Ko je združevanje končano, se določen niz podatkov nadomesti z večjim delom. Hkrati podatki, ki so bili tam, še nekaj časa ostanejo na disku.
Prvič, še naprej se shranjujejo, dokler obstajajo izbirne poizvedbe, ki jih uporabljajo, da se zagotovi delovanje brez blokiranja. Izbrane poizvedbe je enostavno prebrati iz starih kosov.
Drugič, obstaja tudi časovni prag - stari podatki ležijo na disku osem minut. Teh osem minut je mogoče prilagoditi in celo spremeniti v en dan. To bo stalo prostor na disku: odvisno od pretoka podatkov se izkaže, da se v zadnjem dnevu podatki ne bodo samo podvojili, temveč bi se lahko povečali petkrat. Če pa pride do resne težave, lahko zaustavite strežnik ClickHouse in vse uredite.
Zdaj se postavlja vprašanje, kako to ščiti pred spremembami. Tukaj je vredno pogledati globlje, ker je v starejših različicah ClickHouse spreminjanje delovalo tako, da je preprosto neposredno spreminjalo dele. Obstaja del podatkov z nekaterimi datotekami, mi pa npr. spremeni izpusti stolpec. Nato se ta stolpec fizično odstrani iz vseh kosov.
Toda od različice 20.3 je bil mehanizem spreminjanja popolnoma spremenjen in zdaj so deli podatkov vedno nespremenljivi. Sploh se ne spremenijo - spremembe zdaj delujejo skoraj enako kot spajanja. Namesto da bi kos zamenjali na licu mesta, ustvarimo novega. V novem delu datoteke, ki se niso spremenile, postanejo trde povezave in če stolpec izbrišemo, bo v novem delu preprosto manjkal. Stari del bo privzeto izbrisan po osmih minutah, tukaj pa lahko prilagodite zgoraj omenjene nastavitve.
Enako velja za spremembe, kot so mutacije. Ko to storite spremeni izbrisati ali spremeni posodobitev, ne spremeni komada, ampak ustvari novega. In potem izbriše starega.
Kaj pa, če se struktura tabele spremeni?
Kako obnoviti varnostno kopijo, ki je bila narejena s staro shemo? In drugo vprašanje se nanaša na primer s posnetki in orodji datotečnega sistema. Je Btrfs tukaj dober namesto ZFS na Linux LVM?
Če narediš pritrdite particijo particije z drugačno strukturo, vam bo ClickHouse povedal, da to ni mogoče. To je rešitev. Prvi je ustvariti začasno tabelo tipa MergeTree s staro strukturo, vanjo priložiti podatke z uporabo pripojitve in narediti poizvedbo za spremembo. Nato lahko kopirate ali prenesete te podatke in jih znova priložite ali uporabite zahtevo spremeni tabelo premakni particijo.
Zdaj je drugo vprašanje, ali je Btrfs mogoče uporabiti. Za začetek, če imate LVM, so posnetki LVM dovolj, datotečni sistem pa je lahko ext4, ni pomembno. Pri Btrts je vse odvisno od vaših izkušenj z uporabo. Gre za zrel datotečni sistem, vendar je še vedno nekaj dvomov o tem, kako bo vse potekalo v praksi v določenem scenariju. Ne priporočam uporabe tega, razen če imate Btrfs v proizvodnji.
Katere so trenutne najboljše prakse pri ponovnem razdeljevanju podatkov?
Vprašanje ponovnega shranjevanja je zapleteno in večplastno. Tukaj je več možnih odgovorov. Lahko greste z ene strani in rečete to - ClickHouse nima vgrajene funkcije ponovnega razdeljevanja. Vendar se bojim, da ta odgovor ne bo nikomur ustrezal. Zato lahko greste z druge strani in rečete, da ima ClickHouse veliko načinov za ponovno razdelitev podatkov.
Če gruči zmanjka prostora ali ne prenese obremenitve, dodate nove strežnike. Toda ti strežniki so privzeto prazni, na njih ni podatkov, ni obremenitve. Podatke morate preurediti tako, da bodo enakomerno porazdeljeni po novi, večji gruči.
Prvi način, kako to lahko storite, je kopiranje dela particij na nove strežnike z uporabo zahteve spremeniti particijo pridobivanja tabele. Na primer, imeli ste particije po mesecih in vzamete prvi mesec leta 2017 ter ga kopirate na nov strežnik, nato pa kopirate tretji mesec na drug nov strežnik. In to počnite, dokler ne postane bolj ali manj enakomerno.
Prenos se lahko izvede samo za tiste particije, ki se med snemanjem ne spreminjajo. Za sveže particije bo treba snemanje onemogočiti, ker njihov prenos ni atomaren. V nasprotnem primeru boste imeli dvojnike ali vrzeli v podatkih. Vendar je ta metoda praktična in deluje zelo učinkovito. Pripravljene stisnjene particije se prenašajo po omrežju, to pomeni, da podatki niso stisnjeni ali ponovno kodirani.
Ta metoda ima eno pomanjkljivost in je odvisna od sheme razčlenjevanja, od tega, ali ste se zavezali tej shemi razčlenjevanja, kakšen ključ za razčlenjevanje ste imeli. V vašem primeru za metriko je ključ za razčlenjevanje zgoščena vrednost poti. Ko izberete porazdeljeno tabelo, gre na vse drobce v gruči hkrati in od tam vzame podatke.
To pomeni, da vam pravzaprav ni pomembno, kateri podatki so končali na katerem shardu. Glavno je, da podatki po eni poti končajo na enem shardu, na katerem pa ni pomembno. V tem primeru je prenos že pripravljenih particij popoln, saj boste z izbranimi poizvedbami prejeli tudi popolne podatke – ali pred vnovično delitvijo ali po njej, shema ni pomembna.
So pa primeri, ki so bolj zapleteni. Če se na ravni aplikacije zanašate na posebno shemo shardinga, se ta odjemalec nahaja na takem in takem shardu in se lahko zahteva pošlje neposredno tja in ne v Distributed tabelo. Ali pa uporabljate dokaj novo različico ClickHouse in ste omogočili nastavitev optimiziraj preskoči neuporabljene drobce. V tem primeru bo med izbirno poizvedbo analiziran izraz v razdelku where in izračunano bo, katere drobce je treba uporabiti v skladu s shemo razrezovanja. To deluje pod pogojem, da so podatki razdeljeni natančno v skladu s to shemo razdeljevanja. Če ste jih ročno preuredili, se lahko korespondenca spremeni.
To je torej metoda številka ena. In čakam na vaš odgovor, ali je metoda primerna ali gremo naprej.
Vladimir Kolobaev, vodilni sistemski skrbnik v podjetju Avito: Alexey, metoda, ki ste jo omenili, ne deluje dobro, ko morate porazdeliti breme, vključno z branjem. Lahko vzamemo particijo, ki je mesečna, in lahko prenesemo prejšnji mesec v drugo vozlišče, ko pa pride zahteva za te podatke, jih bomo samo naložili. Radi pa bi naložili celotno gručo, ker drugače bosta nekaj časa celotno bralno obremenitev obdelovala dva sharda.
Aleksej Milovidov: Odgovor je čuden - da, slabo je, vendar bi lahko delovalo. Natančno bom razložil, kako. Vredno si je ogledati scenarij obremenitve, ki prihaja za vašimi podatki. Če gre za spremljanje podatkov, potem lahko skoraj zagotovo rečemo, da je velika večina zahtevkov za sveže podatke.
Namestili ste nove strežnike, preselili stare particije, spremenili pa ste tudi način beleženja svežih podatkov. In sveži podatki se bodo širili po gruči. Tako bodo že po petih minutah zahteve za zadnjih pet minut enakomerno obremenile gručo, po enem dnevu pa zahteve za XNUMX ur enakomerno obremenile gručo. In zahteve za pretekli mesec bodo na žalost šle le na del strežnikov gruče.
Toda pogosto ne boste imeli zahtev posebej za februar 2019. Najverjetneje, če gredo zahteve v 2019, potem bodo za celotno leto 2019 - za veliko časovno obdobje in ne za neko majhno območje. In takšne zahteve bodo lahko tudi enakomerno obremenile gručo. Toda na splošno je vaša pripomba popolnoma pravilna, da gre za ad hoc rešitev, ki podatkov ne porazdeli povsem enakomerno.
Imam še nekaj točk za odgovor na vprašanje. Eden od njih govori o tem, kako na začetku oblikovati shemo razčlenjevanja, tako da bo ponovno razčlenjevanje povzročilo manj bolečine. To ni vedno mogoče.
Na primer, imate podatke o spremljanju. Podatki spremljanja naraščajo iz treh razlogov. Prvi je kopičenje zgodovinskih podatkov. Drugi je rast prometa. In tretje je povečanje števila stvari, ki so predmet nadzora. Obstajajo nove mikrostoritve in metrike, ki jih je treba shraniti.
Možno je, da je od teh največje povečanje povezano s tretjim razlogom - povečanjem uporabe monitoringa. In v tem primeru je vredno pogledati naravo obremenitve, katere so glavne izbirne poizvedbe. Osnovne izbirne poizvedbe bodo najverjetneje temeljile na neki podnaboru meritev.
Na primer, uporaba procesorja na nekaterih strežnikih s strani neke storitve. Izkazalo se je, da obstaja določena podmnožica ključev, po katerih dobite te podatke. In sama zahteva po teh podatkih je najverjetneje precej preprosta in se opravi v desetinah milisekund. Uporablja se za spremljanje storitev in nadzornih plošč. Upam, da to prav razumem.
Vladimir Kolobaev: Dejstvo je, da se zelo pogosto sklicujemo na zgodovinske podatke, saj trenutno stanje primerjamo z zgodovinskim v realnem času. Pomembno nam je, da imamo hiter dostop do velike količine podatkov in ClickHouse to odlično opravlja.
Popolnoma prav imate, večino zahtev za branje doživimo v zadnjem dnevu, kot vsak nadzorni sistem. A hkrati je tudi obremenitev zgodovinskih podatkov precej velika. V bistvu je iz sistema za opozarjanje, ki se vrti vsakih trideset sekund in ClickHousu reče: »Daj mi podatke za zadnjih šest tednov. Sedaj pa mi iz njih zgradi nekakšno drseče povprečje in primerjajmo trenutno vrednost z zgodovinsko.«
Rad bi povedal, da imamo za takšne zelo nedavne zahteve še eno majhno tabelo, v kateri hranimo samo dva dni podatkov, glavne zahteve pa letijo vanjo. V veliko razdeljeno tabelo pošiljamo samo velike zgodovinske poizvedbe.
Aleksej Milovidov: Na žalost se je izkazalo, da je slabo uporabna za vaš scenarij, vendar vam bom povedal opis dveh slabih in zapletenih shem razčlenjevanja, ki ju ni treba uporabljati, vendar se uporabljata v storitvi mojih prijateljev.
Obstaja glavna gruča z dogodki Yandex.Metrica. Dogodki so ogledi strani, kliki in konverzije. Večina zahtev gre na določeno spletno mesto. Odprete storitev Yandex.Metrica, imate spletno mesto - avito.ru, pojdite na poročilo in zahteva se za vaše spletno mesto.
Obstajajo pa tudi druge zahteve – analitične in globalne –, ki jih postavljajo notranji analitiki. Za vsak slučaj ugotavljam, da notranji analitiki zahtevajo samo storitve Yandex. Toda kljub temu tudi storitve Yandex zavzemajo pomemben delež vseh podatkov. To niso zahteve za posebne števce, ampak za širše filtriranje.
Kako organizirati podatke tako, da vse deluje učinkovito za en števec in tudi globalne poizvedbe? Druga težava je, da je število zahtevkov v ClickHouse za gruče Metrics nekaj tisoč na sekundo. Hkrati en strežnik ClickHouse ne more obravnavati netrivialnih zahtev, na primer več tisoč na sekundo.
Velikost gruče je šeststo in nekaj strežnikov. Če preprosto potegnete porazdeljeno tabelo čez to gručo in tja pošljete več tisoč zahtev, bo to postalo še slabše, kot če bi jih poslali enemu strežniku. Po drugi strani pa je možnost, da so podatki enakomerno porazdeljeni in zahtevamo vse strežnike, takoj zavrnjena.
Obstaja možnost, ki je diametralno nasprotna. Predstavljajte si, da podatke razdelimo na več spletnih mest in da gre zahteva za eno spletno mesto na en del. Zdaj bo gruča lahko obravnavala deset tisoč zahtevkov na sekundo, vendar bo na enem shardu katera koli zahteva delovala prepočasi. Ne bo se več spreminjal v smislu prepustnosti. Še posebej, če je to spletno mesto avito.ru. Ne bom razkril skrivnosti, če rečem, da je Avito eno najbolj obiskanih spletnih mest v RuNetu. In predelava na enem drobcu bi bila norost.
Zato je shema razrezovanja zasnovana na bolj zvit način. Celotna gruča je razdeljena na več gruč, ki jih imenujemo plasti. Vsaka gruča vsebuje od ducat do nekaj ducatov drobcev. Skupaj je takih grozdov devetintrideset.
Kako se vse to meri? Število grozdov se ne spreminja – kot jih je bilo pred nekaj leti devetintrideset, tako tudi ostaja. Toda znotraj vsakega od njih postopoma povečujemo število drobcev, ko zbiramo podatke. Celotna shema razdeljevanja je taka: ti grozdi so razdeljeni na spletna mesta in da bi razumeli, katero spletno mesto je v katerem grozdu, se uporablja ločena metabaza v MySQL. Eno spletno mesto - na enem grozdu. Znotraj tega se razdeli glede na ID-je obiskovalcev.
Pri beleženju jih delimo z ostankom delitve ID-ja obiskovalca. Pri dodajanju novega sharda pa se shema razrezovanja spremeni; nadaljujemo z delitvijo, vendar z ostankom delitve z drugo številko. To pomeni, da se en obiskovalec že nahaja na več strežnikih in se na to ne morete zanesti. To se naredi izključno zato, da se zagotovi boljša stiskanost podatkov. In ko postavljamo zahteve, gremo v tabelo Distributed, ki gleda na gručo in dostopa do desetine strežnikov. To je tako neumna shema.
Toda moja zgodba bo nepopolna, če ne povem, da smo to shemo opustili. V novi shemi smo vse spremenili in s pomočjo clickhouse-copierja kopirali vse podatke.
V novi shemi so vsa mesta razdeljena v dve kategoriji - velika in majhna. Ne vem, kako je bil izbran prag, ampak rezultat je bil, da so velika spletna mesta zabeležena v enem grozdu, kjer je 120 shardov s po tremi replikami - torej 360 strežnikov. In shema razdeljevanja je taka, da gre katera koli zahteva na vse razdelke hkrati. Če zdaj odprete katero koli stran s poročilom za avito.ru v Yandex.Metrici, bo zahteva poslana na 120 strežnikov. V Runetu je malo velikih spletnih mest. In zahtevkov ni tisoč na sekundo, ampak celo manj kot sto. Vse to tiho prežveči tabela Distributed, ki jo vsak obdeluje s 120 strežniki.
In drugi grozd je za majhna mesta. Tukaj je shema razdeljevanja, ki temelji na ID-ju spletnega mesta, vsaka zahteva pa gre na točno en delček.
ClickHouse ima pripomoček Clickhouse-copier. Nam lahko poveste kaj o njej?
Takoj bom rekel, da je ta rešitev bolj okorna in nekoliko manj produktivna. Prednost je v tem, da podatke popolnoma razmaže po vzorcu, ki ga določite. Toda pomanjkljivost pripomočka je, da sploh ne rešardira. Kopira podatke iz ene sheme gruče v drugo shemo gruče.
To pomeni, da morate za delovanje imeti dve gruči. Lahko se nahajajo na istih strežnikih, vendar se kljub temu podatki ne bodo postopoma premikali, temveč kopirali.
Na primer, bili so štirje strežniki, zdaj jih je osem. Ustvarite novo porazdeljeno tabelo na vseh strežnikih, nove lokalne tabele in zaženete clickhouse-copier, v njej navedete delovno shemo, ki naj jo bere od tam, sprejmete novo shemo razdeljevanja in prenesete podatke tja. In na starih strežnikih boste potrebovali enkrat in pol več prostora, kot ga je zdaj, ker morajo na njih ostati stari podatki, nanje pa bo prispela polovica istih starih podatkov. Če ste vnaprej mislili, da je treba podatke ponovno razdeliti in je prostor, potem je ta metoda primerna.
Kako Clickhouse-copier deluje znotraj? Vse delo razdeli na nabor nalog za obdelavo ene particije ene tabele na enem drobcu. Vse te naloge je mogoče izvajati vzporedno in Clickhouse-copier je mogoče izvajati na različnih strojih v več primerih, vendar to, kar naredi za eno particijo, ni nič drugega kot izbira vstavljanja. Podatki se preberejo, dekompresirajo, ponovno razdelijo, nato znova stisnejo, nekam zapišejo in ponovno razvrstijo. To je težja odločitev.
Imeli ste pilotno stvar, imenovano resharding. Kaj z njo?
Leta 2017 ste imeli pilotno stvar, imenovano resharding. Obstaja celo možnost v ClickHouse. Kolikor razumem, ni vzletelo. Mi lahko poveste, zakaj se je to zgodilo? Zdi se, da je zelo relevantno.
Celotna težava je v tem, da če je treba znova razdeliti podatke na mestu, je potrebna zelo zapletena sinhronizacija, da se to izvede atomsko. Ko smo začeli preučevati, kako ta sinhronizacija deluje, je postalo jasno, da obstajajo temeljne težave. In ti temeljni problemi niso samo teoretični, ampak so se takoj začeli kazati tudi v praksi v obliki nečesa, kar je mogoče razložiti zelo preprosto - nič ne deluje.
Ali je mogoče združiti vse podatke, preden jih premaknete na počasne diske?
Vprašanje o TTL z možnostjo premika na počasen disk v kontekstu združevanja. Ali obstaja način, razen prek crona, da združi vse dele v enega, preden jih premakne na počasne diske?
Odgovor na vprašanje, ali je mogoče vse dele nekako samodejno zlepiti v enega, preden jih prenesemo - ne. Mislim, da to ni potrebno. Ni vam treba združiti vseh delov v enega, ampak preprosto računajte na to, da se bodo samodejno prenesli na počasne diske.
Imamo dva kriterija za pravila prenosa. Prvi je tak, kot je napolnjen. Če ima trenutna raven pomnilnika manj kot določen odstotek prostega prostora, izberemo en kos in ga premaknemo v počasnejši pomnilnik. Oziroma ne počasnejši, ampak naslednji - kot konfigurirate.
Drugi kriterij je velikost. Gre za premikanje velikih kosov. Prag lahko prilagodite glede na prosti prostor na hitrem disku in podatki se bodo samodejno prenesli.
Kako preiti na nove različice ClickHouse, če združljivosti ni mogoče preveriti vnaprej?
O tej temi se redno razpravlja ob upoštevanju različnih različic in še vedno. Kako varna je nadgradnja z različice 19.11 na 19.16 in na primer z 19.16 na 20.3. Kateri je najboljši način za prehod na nove različice, ne da bi lahko vnaprej preverili združljivost v peskovniku?
Tu obstaja več "zlatih" pravil. prvi - . Je velik, vendar obstajajo ločeni odstavki o nazaj nezdružljivih spremembah. Ne obravnavajte teh točk kot rdeče zastave. To so običajno manjše nezdružljivosti, ki vključujejo nekatere robne funkcije, ki jih zelo verjetno ne uporabljate.
Drugič, če ni možnosti za preverjanje združljivosti v peskovniku in želite posodobitev izvesti takoj v produkciji, priporočamo, da vam tega ni treba storiti. Najprej ustvarite peskovnik in preizkusite. Če testnega okolja ni, potem najverjetneje nimate zelo velikega podjetja, kar pomeni, da lahko nekatere podatke kopirate na svoj prenosnik in se prepričate, da na njem vse deluje pravilno. Lahko celo ustvarite več replik lokalno na vašem računalniku. Lahko pa vzamete novo različico nekje v bližini in tja naložite nekaj podatkov - torej ustvarite improvizirano testno okolje.
Drugo pravilo je, da ne posodabljajte teden dni po izdaji različice zaradi lovljenja napak v proizvodnji in kasnejših hitrih popravkov. Ugotovimo oštevilčenje različic ClickHouse, da se ne zmedemo.
Obstaja različica 20.3.4. Številka 20 označuje leto izdelave - 2020. Z vidika tega, kaj je v notranjosti, to ni pomembno, zato temu ne bomo posvečali pozornosti. Naprej - 20.3. Drugo številko povečamo - v tem primeru 3 - vsakič, ko izdamo izdajo z neko novo funkcionalnostjo. Če želimo ClickHouseu dodati kakšno funkcijo, moramo to število povečati. To pomeni, da bo v različici 20.4 ClickHouse deloval še bolje. Tretja številka je 20.3.4. Tukaj je 4 število izdaj popravkov, v katerih nismo dodali novih funkcij, vendar smo odpravili nekaj napak. In 4 pomeni, da smo to storili štirikrat.
Ne mislite, da je to nekaj groznega. Običajno lahko uporabnik namesti najnovejšo različico in bo delovala brez težav z delovanjem na leto. Toda predstavljajte si, da se v neki funkciji za obdelavo bitnih slik, ki so jo dodali naši kitajski tovariši, strežnik zruši pri posredovanju napačnih argumentov. Imamo odgovornost, da to popravimo. Izdali bomo novo različico popravka in ClickHouse bo postal stabilnejši.
Če imate ClickHouse, ki teče v produkciji, in se izda nova različica ClickHouse z dodatnimi funkcijami - na primer, 20.4.1 je prva, ne hitite, da bi jo dali v produkcijo že prvi dan. Zakaj je sploh potreben? Če ClickHouse še ne uporabljate, jo lahko namestite in najverjetneje bo vse v redu. Če pa ClickHouse že deluje stabilno, bodite pozorni na popravke in posodobitve, da vidite, katere težave odpravljamo.
Kiril Švakov: Rad bi dodal nekaj o testnih okoljih. Vsi se zelo bojijo testnih okolij in iz neznanega razloga verjamejo, da če imate zelo veliko gručo ClickHouse, potem mora biti testno okolje nič manj ali vsaj desetkrat manjše. Sploh ni tako.
Povem vam iz lastnega primera. Imam projekt in tu je ClickHouse. Naše testno okolje je samo zanj - to je majhen virtualni stroj v Hetznerju za dvajset evrov, kjer je razporejeno čisto vse. Za to imamo v Ansibleu popolno avtomatizacijo, zato načeloma ni razlike, kam iti - na strežnike strojne opreme ali samo uvesti v virtualne stroje.
Kaj se lahko naredi? Lepo bi bilo, če bi v dokumentaciji ClickHouse podali primer o tem, kako uvesti majhno gručo v svojem domu – v Dockerju, v LXC, morda ustvarite Ansible playbook, ker imajo različni ljudje različne uvedbe. To bo marsikaj poenostavilo. Ko vzamete in uvedete gručo v petih minutah, je veliko lažje poskusiti nekaj ugotoviti. To je veliko bolj priročno, saj je potiskanje proizvodne različice, ki je niste preizkusili, pot v nikamor. Včasih deluje, včasih pa ne. In zato je upanje na uspeh slabo.
Maxim Kotyakov, višji backend inženir Avito: Dodal bom nekaj o testnih okoljih iz vrste težav, s katerimi se soočajo velika podjetja. Imamo polnopravni sprejemni grozd ClickHouse, kar zadeva podatkovne sheme in nastavitve, je natančna kopija tega, kar je v proizvodnji. Ta gruča je razporejena v dokaj obrabljenih vsebnikih z minimalno količino virov. Tja zapišemo določen odstotek proizvodnih podatkov, na srečo je možno replicirati tok v Kafki. Tam je vse sinhronizirano in skalirano – tako glede zmogljivosti kot pretoka, in v teoriji bi se moralo, če so vse ostale enake, glede metrike obnašati kot proizvodnja. Vse, kar je potencialno eksplozivno, se najprej skotali na to stojalo in tam pusti nekaj dni, dokler ni pripravljeno. Toda seveda je ta rešitev draga, težka in ima različne stroške podpore.
Aleksej Milovidov: Povedal vam bom, kakšno je testno okolje naših prijateljev iz Yandex.Metrice. En grozd je imel 600 strežnikov, drugi 360, tretji pa več grozdov. Testno okolje za enega od njih sta preprosto dva sharda z dvema replikama v vsakem. Zakaj dva drobca? Da ne boste sami. In tudi replike bi morale biti. Samo določen minimalni znesek, ki si ga lahko privoščite.
To preskusno okolje vam omogoča, da preverite, ali vaše poizvedbe delujejo in ali je kaj večjega pokvarjeno. Toda pogosto se pojavijo težave povsem drugačne narave, ko vse deluje, vendar so majhne spremembe v obremenitvi.
Naj vam povem primer. Odločili smo se za namestitev nove različice ClickHouse. Objavljeno je bilo v testnem okolju, v sami Yandex.Metrici so bili opravljeni avtomatizirani testi, ki primerjajo podatke o stari in novi različici, pri čemer poteka celoten cevovod. In seveda zeleni testi našega CI. Sicer te različice sploh ne bi predlagali.
Vse je vredu. Začenjamo se seliti v proizvodnjo. Dobim sporočilo, da se je obremenitev grafov večkrat povečala. Različico vračamo nazaj. Pogledam graf in vidim: obremenitev se je med uvedbo dejansko večkrat povečala in zmanjšala, ko so se uvedle. Nato smo začeli vračati različico. In tovor se je povečal na enak način in nazadoval na enak način. Zaključek je torej naslednji: obremenitev se je povečala zaradi postavitve, nič presenetljivega.
Potem je bilo težko prepričati kolege, da namestijo novo različico. Rečem: »V redu je, razvaljaj se. Držimo pesti, vse bo uspelo. Zdaj se je obremenitev grafov povečala, vendar je vse v redu. Zdrži." Na splošno smo to naredili in to je to - različica je bila izdana za proizvodnjo. Toda skoraj pri vsaki postavitvi se pojavijo podobne težave.
Kill query naj bi uničil poizvedbe, vendar jih ne. Zakaj?
Uporabnik, nekakšen analitik, je prišel do mene in ustvaril zahtevo, ki je postavila mojo gručo ClickHouse. Neko vozlišče ali celotna gruča, odvisno od tega, na katero repliko ali delček je šla zahteva. Vidim, da so vsi viri procesorja na tem strežniku na polici, vse je rdeče. Hkrati ClickHouse sam odgovarja na zahteve. In napišem: "Prosim, pokažite mi, seznam procesov, katera zahteva je povzročila to norost."
Najdem to prošnjo in ji napišem kill. In vidim, da se nič ne dogaja. Moj strežnik je na polici, ClickHouse mi nato da nekaj ukazov, pokaže, da je strežnik živ in je vse super. Vendar imam degradacijo v vseh uporabniških zahtevah, degradacija se začne z zapisi v ClickHouse in moja poizvedba za uničenje ne deluje. Zakaj? Mislil sem, da naj bi kill query uničil poizvedbe, vendar jih ni.
Zdaj bo precej čuden odgovor. Bistvo je, da kill query ne uniči poizvedb.
Kill query potrdi majhno polje z imenom "Želim, da se ta poizvedba uniči." In sama zahteva gleda na to zastavico pri obdelavi vsakega bloka. Če je nastavljena, zahteva preneha delovati. Izkazalo se je, da nihče ne ubije zahteve, sam mora vse preveriti in se ustaviti. In to bi moralo delovati v vseh primerih, ko je zahteva v stanju obdelave blokov podatkov. Obdelal bo naslednji blok podatkov, preveril zastavico in se ustavil.
To ne deluje v primerih, ko je zahteva blokirana pri neki operaciji. Res je, najverjetneje to ni vaš primer, saj po vašem mnenju uporablja tono strežniških virov. Možno je, da to ne deluje v primeru zunanjega razvrščanja in v nekaterih drugih podrobnostih. Toda na splošno se to ne bi smelo zgoditi, to je napaka. In edina stvar, ki jo lahko priporočam, je posodobitev ClickHouse.
Kako izračunati odzivni čas pri bralni obremenitvi?
Obstaja tabela, ki shranjuje agregate postavk - različne števce. Število vrstic je približno sto milijonov. Ali je mogoče računati na predvidljiv odzivni čas, če nalijete 1K RPS za 1K artiklov?
Po kontekstu sodeč govorimo o bralni obremenitvi, saj s pisanjem ni težav – vstavi se lahko tudi tisoč, tudi sto tisoč, včasih pa tudi več milijonov vrstic.
Zahteve za branje so zelo različne. Pri izbiri 1 lahko ClickHouse izvede približno deset tisoč zahtevkov na sekundo, tako da bodo tudi zahteve za en ključ že zahtevale nekaj virov. In takšne točkovne poizvedbe bodo težje kot v nekaterih bazah podatkov ključ-vrednost, ker je za vsako branje potrebno prebrati blok podatkov po indeksu. Naš indeks ne obravnava vsakega zapisa, ampak vsak obseg. To pomeni, da boste morali prebrati celoten obseg - to je privzeto 8192 vrstic. In stisnjen podatkovni blok boste morali razpakirati s 64 KB na 1 MB. Običajno takšne poizvedbe po točkah trajajo nekaj milisekund. Toda to je najpreprostejša možnost.
Poskusimo nekaj preproste aritmetike. Če pomnožite nekaj milisekund s tisoč, dobite nekaj sekund. Kot da je nemogoče slediti tisoč zahtevam na sekundo, a v bistvu je mogoče, saj imamo več procesorskih jeder. Torej, načeloma lahko ClickHouse včasih drži 1000 RPS, vendar za kratke zahteve, posebej ciljane.
Če morate gručo ClickHouse povečati glede na število preprostih zahtev, potem priporočam najpreprostejšo stvar - povečajte število replik in pošljite zahteve naključni replici. Če ena replika sprejme petsto zahtevkov na sekundo, kar je povsem realno, jih tri replike prenesejo na tisoč in pol.
Včasih lahko ClickHouse seveda konfigurirate za največje število odčitkov točk. Kaj je potrebno za to? Prvi je zmanjšati razdrobljenost indeksa. V tem primeru ga ne bi smeli zmanjšati na enega, ampak na podlagi tega, da bo število vnosov v indeks več milijonov ali desetine milijonov na strežnik. Če ima tabela sto milijonov vrstic, je lahko razdrobljenost nastavljena na 64.
Velikost stisnjenega bloka lahko zmanjšate. Za to obstajajo nastavitve najmanjša velikost stisnjenega bloka, največja velikost stisnjenega bloka. Lahko jih zmanjšate, ponovno napolnite s podatki in takrat bodo ciljne poizvedbe hitrejše. Kljub temu ClickHouse ni baza podatkov ključev in vrednosti. Veliko število majhnih zahtev je nevzorec obremenitve.
Kiril Švakov: Svetoval bom, če so tam navadni računi. To je dokaj standardna situacija, ko ClickHouse shrani nekakšen števec. Imam uporabnika, je iz te in te države, pa nekega tretjega področja in moram postopoma nekaj povečati. Vzemite MySQL, naredite edinstven ključ - v MySQL je to podvojen ključ, v PostgreSQL pa konflikt - in dodajte znak plus. To bo delovalo veliko bolje.
Če nimate veliko podatkov, nima smisla uporabljati ClickHouse. Obstajajo redne podatkovne baze in to dobro počnejo.
Kaj lahko prilagodim v ClickHouse, da bo več podatkov v predpomnilniku?
Predstavljajmo si situacijo - strežniki imajo 256 GB RAM-a, v dnevni rutini ClickHouse zavzame približno 60-80 GB, na vrhuncu - do 130. Kaj je mogoče omogočiti in prilagoditi, tako da je v predpomnilniku več podatkov in v skladu s tem je manj potovanj na disk?
Običajno predpomnilnik strani operacijskega sistema to dobro opravi. Če samo odprete vrh, pogledate predpomnjeno ali prosto - piše tudi, koliko je predpomnjenega - potem boste opazili, da je ves prosti pomnilnik uporabljen za predpomnilnik. In pri branju teh podatkov se ne bodo prebrali z diska, ampak iz RAM-a. Hkrati lahko rečem, da je predpomnilnik učinkovito uporabljen, saj se predpomnijo stisnjeni podatki.
Če pa želite še bolj pospešiti nekatere preproste poizvedbe, je mogoče omogočiti predpomnilnik v dekompresiranih podatkih znotraj ClickHouse. Se imenuje nestisnjen predpomnilnik. V konfiguracijski datoteki config.xml nastavite velikost nestisnjenega predpomnilnika na vrednost, ki jo potrebujete - priporočam največ polovico prostega RAM-a, ker bo ostalo v predpomnilniku strani.
Poleg tega obstajata dve nastavitvi ravni zahteve. Prva nastavitev - uporabite nestisnjeni predpomnilnik - vključuje njegovo uporabo. Priporočljivo je, da ga omogočite za vse zahteve, razen za težke, ki lahko preberejo vse podatke in izpraznijo predpomnilnik. In druga nastavitev je nekaj podobnega največjemu številu vrstic za uporabo predpomnilnika. Samodejno omeji velike poizvedbe, tako da obidejo predpomnilnik.
Kako lahko konfiguriram storage_configuration za shranjevanje v RAM?
V novi dokumentaciji ClickHouse sem prebral razdelek, povezan . Opis vsebuje primer s hitrim SSD.
Zanima me, kako je mogoče isto stvar konfigurirati z volumskim vročim pomnilnikom. In še eno vprašanje. Kako select deluje s to organizacijo podatkov, ali bo prebral celoten niz ali samo tistega, ki je na disku, in ali so ti podatki stisnjeni v pomnilnik? In kako razdelek prewhere deluje s takšno organizacijo podatkov?
Ta nastavitev vpliva na shranjevanje kosov podatkov in njihov format se na noben način ne spremeni.
Pa poglejmo pobliže.
Shranjevanje podatkov lahko konfigurirate v RAM-u. Vse, kar je konfigurirano za disk, je njegova pot. Ustvarite particijo tmpfs, ki je priklopljena na neko pot v datotečnem sistemu. To pot določite kot pot za shranjevanje podatkov za najbolj vročo particijo, podatki začnejo prihajati in se zapisovati tja, vse je v redu.
Vendar tega ne priporočam zaradi nizke zanesljivosti, čeprav, če imate vsaj tri replike v različnih podatkovnih centrih, je to mogoče. Če se kar koli zgodi, bodo podatki obnovljeni. Predstavljajmo si, da je bil strežnik nenadoma izklopljen in ponovno vklopljen. Pregrada je bila ponovno nameščena, vendar tam ni bilo ničesar. Ko se strežnik ClickHouse zažene, vidi, da teh kosov nima, čeprav bi glede na metapodatke ZooKeeperja morali biti tam. Pogleda, katere replike jih imajo, jih zahteva in prenese. Na ta način bodo podatki obnovljeni.
V tem smislu se shranjevanje podatkov v RAM ne razlikuje bistveno od shranjevanja na disk, saj ko se podatki zapišejo na disk, tudi ti najprej končajo v predpomnilniku strani in se kasneje fizično zapišejo. To je odvisno od možnosti namestitve datotečnega sistema. Ampak za vsak slučaj bom rekel, da ClickHouse ne fsync pri vstavljanju.
V tem primeru so podatki v RAM-u shranjeni v popolnoma enaki obliki kot na disku. Izbirna poizvedba na enak način izbere dele, ki jih je treba prebrati, izbere potrebne obsege podatkov v delih in jih prebere. In prewhere deluje popolnoma enako, ne glede na to, ali so bili podatki v RAM-u ali na disku.
Do katerega števila edinstvenih vrednosti je nizka kardinalnost učinkovita?
Nizka kardinalnost je pametno zasnovana. Sestavlja podatkovne slovarje, ki pa so lokalni. Prvič, obstajajo različni slovarji za vsak del, in drugič, tudi znotraj enega dela so lahko različni za vsak obseg. Ko število edinstvenih vrednosti doseže mejno številko – mislim, da en milijon –, se slovar preprosto odloži in ustvari nov.
Odgovor je na splošno: za vsak lokalni obseg - recimo za vsak dan - nekje do milijon edinstvenih vrednosti Nizka kardinalnost je učinkovita. Nato bo preprosto nadomestni, v katerem bo uporabljenih veliko različnih slovarjev in ne samo en. Deloval bo približno enako kot običajni nizni stolpec, morda malo manj učinkovito, vendar ne bo resnega poslabšanja zmogljivosti.
Kateri so najboljši postopki za iskanje po celotnem besedilu v tabeli s petimi milijardami vrstic?
Obstajajo različni odgovori. Prvi je, da ClickHouse ni iskalnik po celotnem besedilu. Za to obstajajo posebni sistemi, npr. и . Vendar vse pogosteje vidim ljudi, ki pravijo, da prehajajo z Elasticsearch na ClickHouse.
Zakaj se to zgodi? To pojasnjujejo z dejstvom, da Elasticsearch preneha obvladovati obremenitev pri nekaterih količinah, začenši z gradnjo indeksov. Indeksi postanejo preokorni in če podatke preprosto prenesete v ClickHouse, se izkaže, da so količinsko shranjeni nekajkrat bolj učinkovito. Hkrati pa iskalne poizvedbe pogosto niso bile takšne, da bi bilo treba v celotnem obsegu podatkov najti neko besedno zvezo, upoštevajoč morfologijo, ampak povsem drugačne. Na primer, poiščite nekaj podzaporedij bajtov v dnevnikih v zadnjih nekaj urah.
V tem primeru ustvarite indeks v ClickHouse, katerega prvo polje bosta datum in ura. In največji prerez podatkov bo temeljil na časovnem obdobju. Znotraj izbranega časovnega obdobja je praviloma že mogoče izvesti iskanje po celotnem besedilu, tudi z metodo surove sile z všečkom. Operator like v ClickHouse je najučinkovitejši operator like, kar jih lahko najdete. Če najdeš kaj boljšega, povej.
Ampak še vedno, kot je popoln pregled. In popolno skeniranje je lahko počasno ne samo na CPE, ampak tudi na disku. Če imate nenadoma en terabajt podatkov na dan in čez dan iščete besedo, boste morali pregledati terabajt. In verjetno je na navadnih trdih diskih, na koncu pa bodo naloženi tako, da do tega strežnika ne boste mogli dostopati prek SSH.
V tem primeru sem pripravljen ponuditi še en mali trik. Je eksperimentalno – morda bo delovalo, morda ne. ClickHouse ima indekse celotnega besedila v obliki trigramskih Bloomovih filtrov. Naši kolegi pri Arenadata so te indekse že preizkusili in pogosto delujejo točno tako, kot je predvideno.
Da bi jih pravilno uporabljali, bi morali dobro razumeti, kako natančno delujejo: kaj je trigram Bloom filter in kako izbrati njegovo velikost. Lahko rečem, da bodo pomagali pri poizvedbah o nekaterih redkih frazah, podnizih, ki jih redko najdemo v podatkih. V tem primeru bodo podrazponi izbrani z indeksi in prebranih bo manj podatkov.
Pred kratkim je ClickHouse dodal še več naprednih funkcij za iskanje po celotnem besedilu. To je, prvič, iskanje množice podnizov hkrati v enem prehodu, vključno z možnostmi, ki razlikujejo med velikimi in malimi črkami, neobčutljive med velikimi in malimi črkami, s podporo za UTF-8 ali samo za ASCII. Izberite najučinkovitejšega, ki ga potrebujete.
Pojavilo se je tudi iskanje več regularnih izrazov naenkrat. Ni vam treba pisati X kot en podniz ali X kot drug podniz. Pišete takoj in vse je narejeno čim bolj učinkovito.
Tretjič, zdaj obstaja približno iskanje regularnih izrazov in približno iskanje podnizov. Če je nekdo napačno črkoval besedo, se bo iskalo največje ujemanje.
Kako najbolje organizirati dostop do ClickHouse za večje število uporabnikov?
Povejte nam, kako najbolje organizirati dostop za veliko število potrošnikov in analitikov. Kako oblikovati čakalno vrsto, dati prednost največjemu številu sočasnih poizvedb in s katerimi orodji?
Če je gruča dovolj velika, bi bila dobra rešitev dvig še dveh strežnikov, ki bosta postala vstopna točka za analitike. To pomeni, da analitikom ne dovolite dostopa do določenih drobcev v gruči, temveč preprosto ustvarite dva prazna strežnika brez podatkov in na njih konfigurirajte pravice dostopa. V tem primeru se uporabniške nastavitve za porazdeljene zahteve prenesejo na oddaljene strežnike. To pomeni, da vse konfigurirate na teh dveh strežnikih, nastavitve pa vplivajo na celotno gručo.
Ti strežniki načeloma nimajo podatkov, vendar je količina RAM-a na njih zelo pomembna za izvajanje zahtev. Disk se lahko uporablja tudi za začasne podatke, če je omogočeno zunanje združevanje ali zunanje razvrščanje.
Pomembno je pogledati nastavitve, ki so povezane z vsemi možnimi omejitvami. Če zdaj grem v gručo Yandex.Metrica kot analitik in vprašam zahtevo izberite štetje zadetkov, potem bom takoj dobil izjemo, da ne morem izvršiti zahteve. Največje število vrstic, ki jih smem pregledati, je sto milijard, skupaj pa jih je v eni tabeli v gruči petdeset bilijonov. To je prva omejitev.
Recimo, da odstranim omejitev vrstice in znova zaženem poizvedbo. Nato bom videl naslednjo izjemo - nastavitev omogočena indeks sile po datumu. Ne morem dokončati poizvedbe, če nisem določil časovnega obdobja. Ni se vam treba zanašati na analitike, da bi ga določili ročno. Tipičen primer je, ko je datumsko obdobje zapisano tam, kjer je datum dogodka med tednom. In potem so preprosto navedli oklepaj na napačnem mestu in namesto in se je izkazalo, da je ali - ali URL ujemanje. Če ni omejitve, bo preiskal stolpec URL in samo zapravil ogromno virov.
Poleg tega ima ClickHouse dve prednostni nastavitvi. Na žalost so zelo primitivni. Ena se preprosto imenuje prednostna naloga. Če je prioriteta ≠ 0 in se izvajajo zahteve z določeno prioriteto, vendar se izvaja zahteva z vrednostjo prioritete manjšo od, kar pomeni višjo prioriteto, potem zahteva z vrednostjo prioritete večjo, kar pomeni nižjo prioriteto , je preprosto začasno ustavljen in v tem času sploh ne bo deloval.
To je zelo groba nastavitev in ni primerna za primere, kjer je gruča konstantno obremenjena. Toda če imate kratke, hitre zahteve, ki so pomembne, in je gruča večinoma nedejavna, je ta nastavitev primerna.
Prikliče se naslednja prednostna nastavitev Prednost niti OS. Preprosto nastavi lepo vrednost za vse niti izvajanja zahtev za razporejevalnik Linuxa. Deluje tako-tako, ampak vseeno deluje. Če nastavite najmanjšo lepo vrednost - je največja vrednost in zato najnižja prioriteta - in nastavite -19 za zahteve z visoko prioriteto, bo CPE porabil zahteve z nizko prioriteto približno štirikrat manj kot zahteve z visoko prioriteto.
Prav tako morate konfigurirati najdaljši čas izvedbe zahteve - recimo pet minut. Minimalna hitrost izvajanja poizvedbe je najbolj kul stvar. Ta nastavitev je prisotna že dolgo in potrebna je ne le za trditev, da ClickHouse ne upočasni, ampak za to, da jo vsili.
Predstavljajte si, da ste nastavili: če neka poizvedba obdela manj kot milijon vrstic na sekundo, tega ne morete storiti. To sramoti naše dobro ime, našo dobro bazo podatkov. Samo prepovedajmo to. Pravzaprav obstajata dve nastavitvi. Ena se imenuje minimalna hitrost izvajanja - v vrsticah na sekundo, sekunda pa se imenuje časovna omejitev pred preverjanjem minimalne hitrosti izvajanja - privzeto petnajst sekund. To pomeni, da je možnih petnajst sekund, nato pa, če je počasno, samo vrzite izjemo in prekinite zahtevo.
Določiti morate tudi kvote. ClickHouse ima vgrajeno funkcijo kvote, ki šteje porabo virov. Toda na žalost ne viri strojne opreme, kot so CPE, diski, ampak logični - število obdelanih zahtev, vrstic in prebranih bajtov. Konfigurirate lahko na primer največ sto zahtev v petih minutah in tisoč zahtev na uro.
Zakaj je pomembno? Ker bodo nekatere analitične poizvedbe izvedene ročno neposredno iz odjemalca ClickHouse. In vse bo dobro. Če pa imate v podjetju napredne analitike, bodo ti napisali skripto in v skripti je lahko napaka. Ta napaka bo povzročila, da se bo zahteva izvršila v neskončni zanki. Pred tem se moramo zaščititi.
Ali je mogoče rezultate ene poizvedbe posredovati desetim strankam?
Imamo več uporabnikov, ki radi pridejo z zelo velikimi zahtevami na isti točki. Zahteva je velika in načeloma hitro izvedena, vendar zaradi dejstva, da je takih zahtevkov veliko hkrati, postane zelo boleča. Ali je mogoče isto zahtevo, ki je prispela desetkrat zapored, izvršiti enkrat in dati rezultat desetim strankam?
Težava je v tem, da nimamo rezultatov predpomnilnika ali predpomnilnika vmesnih podatkov. Obstaja stranski predpomnilnik operacijskega sistema, ki vam bo onemogočil ponovno branje podatkov z diska, žal pa bodo podatki še vedno razpakirani, deserializirani in ponovno obdelani.
Temu bi se rad nekako izognil, bodisi s predpomnjenjem vmesnih podatkov bodisi z zvrstitvijo podobnih poizvedb v nekakšno čakalno vrsto in dodajanjem predpomnilnika rezultatov. Trenutno imamo v razvoju eno zahtevo za vleko, ki doda predpomnilnik zahtev, vendar le za podpoizvedbe v razdelkih in in join – to pomeni, da rešitev ni popolna.
Vendar se tudi mi soočamo s takšno situacijo. Posebej kanoničen primer so paginirane poizvedbe. Obstaja poročilo, ima več strani, in tam je zahteva za omejitev 10. Potem isto, vendar omejitev 10,10. Nato še ena naslednja stran. In vprašanje je, zakaj vse to vsakič štejemo? Toda zdaj ni rešitve in ni se ji mogoče izogniti.
Obstaja alternativna rešitev, ki je postavljena kot stranska prikolica poleg ClickHouse - .
Kiril Švakov: ClickHouse Proxy ima vgrajen omejevalnik hitrosti in vgrajen predpomnilnik rezultatov. Tam je bilo narejenih veliko nastavitev, ker se je reševal podoben problem. Proxy vam omogoča, da omejite zahteve tako, da jih postavite v čakalno vrsto, in konfigurirate, kako dolgo živi predpomnilnik zahtev. Če so bile zahteve res enake, jih bo Proxy poslal večkrat, na ClickHouse pa le enkrat.
Nginx ima tudi predpomnilnik v brezplačni različici in tudi to bo delovalo. Nginx ima celo nastavitve, da če zahteve prispejo istočasno, bo druge upočasnil, dokler ena ni dokončana. Toda v ClickHouse Proxyju je nastavitev veliko boljša. Narejen je bil posebej za ClickHouse, posebej za te zahteve, zato je bolj primeren. No, namestitev je enostavna.
Kaj pa asinhrone operacije in materializirani pogledi?
Težava je v tem, da so operacije z mehanizmom za predvajanje asinhrone - najprej se podatki zapišejo, nato se zrušijo. Če pod znakom živi materializirana tablica z nekaj agregati, se ji bodo zapisali dvojniki. In če ni zapletene logike, se bodo podatki podvojili. Kaj lahko storite glede tega?
Obstaja očitna rešitev - implementirati sprožilec na določen razred matviewov med asinhrono operacijo zrušitve. Ali obstajajo kakšne srebrne krogle ali načrti za implementacijo podobne funkcionalnosti?
Vredno je razumeti, kako deluje deduplikacija. To, kar vam bom zdaj povedal, ni pomembno za vprašanje, ampak za vsak slučaj je vredno zapomniti.
Pri vstavljanju v podvojeno tabelo pride do deduplikacije celotnih vstavljenih blokov. Če znova vstavite isti blok, ki vsebuje enako število istih vrstic v istem vrstnem redu, se podatki odstranijo podvojeni. V odgovor boste prejeli »V redu« za vstavljanje, vendar bo dejansko en paket podatkov zapisan in ne bo podvojen.
To je potrebno za gotovost. Če med vstavljanjem prejmete »V redu«, so bili vaši podatki vstavljeni. Če od ClickHouse prejmete napako, to pomeni, da niso bili vstavljeni in morate vstavljanje ponoviti. Če pa se povezava med vstavljanjem prekine, potem ne veste, ali so bili podatki vstavljeni ali ne. Edina možnost je ponovitev vstavljanja. Če so bili podatki dejansko vstavljeni in ste jih znova vstavili, je prišlo do deduplikacije blokov. To je potrebno, da se izognete dvojnikom.
In pomembno je tudi, kako deluje za materializirane poglede. Če so bili podatki depodvojeni, ko so bili vstavljeni v glavno tabelo, tudi ne bodo šli v materializiran pogled.
Zdaj o vprašanju. Vaša situacija je bolj zapletena, ker snemate dvojnike posameznih vrstic. To pomeni, da se ne podvaja celoten paket, ampak določene vrstice, ki se zrušijo v ozadju. Dejansko se bodo podatki strnili v glavni tabeli, vendar bodo nestrnjeni podatki šli v materializirani pogled in med združevanjem se materializiranim pogledom ne bo zgodilo nič. Ker materializiran pogled ni nič drugega kot sprožilec za vstavljanje. Med drugimi operacijami se z njim ne zgodi nič dodatnega.
In tukaj te ne morem osrečiti. Samo za ta primer morate poiskati specifično rešitev. Na primer, ali ga je mogoče ponovno predvajati v materializiranem pogledu in metoda deduplikacije morda deluje na enak način. A žal ne vedno. Če se združuje, ne bo delovalo.
Kiril Švakov: Včasih smo imeli tudi gradnjo bergel. Prišlo je do težave, da obstajajo prikazi oglaševanja in obstajajo nekateri podatki, ki jih lahko prikažemo v realnem času - to so samo prikazi. Redko se podvajajo, a če se to zgodi, jih bomo kasneje vseeno sesuli. In bile so stvari, ki jih ni bilo mogoče podvajati – kliki in vsa ta zgodba. A želel sem jih tudi pokazati skoraj takoj.
Kako so nastali materializirani pogledi? Obstajajo pogledi, kjer je bilo zapisano neposredno - zapisano je bilo v neobdelane podatke in zapisano v poglede. Tam na neki točki podatki niso zelo pravilni, se podvajajo itd. In obstaja drugi del tabele, kjer so videti popolnoma enako kot materializirani pogledi, to je, da so po strukturi popolnoma enaki. Občasno preračunamo podatke, preštejemo podatke brez dvojnikov, zapišemo v tiste tabele.
Šli smo skozi API - to v ClickHouse ne bo delovalo ročno. In API pogleda: ko imam datum zadnjega dodajanja v tabelo, kjer je zagotovljeno, da so že izračunani pravilni podatki, in naredi zahtevo eni in drugi tabeli. Iz enega zahteva izbere do določenega časa, iz drugega pa dobi tisto, kar še ni izračunano. In deluje, vendar ne samo prek ClickHouse.
Če imate nekakšen API - za analitike, za uporabnike - potem je to načeloma možnost. Vedno šteješ, vedno šteješ. To lahko storite enkrat na dan ali ob drugem času. Sami izberete obseg, ki ga ne potrebujete in ni kritičen.
ClickHouse ima veliko dnevnikov. Kako lahko na prvi pogled vidim vse, kar se dogaja s strežnikom?
ClickHouse ima zelo veliko različnih dnevnikov in to število se povečuje. V novih različicah so nekateri med njimi celo privzeto omogočeni, v starejših pa jih je treba omogočiti ob posodabljanju. Teh pa je vedno več. Navsezadnje bi rad videl, kaj se zdaj dogaja z mojim strežnikom, morda na kakšni nadzorni plošči s povzetkom.
Ali imate ekipo ClickHouse ali ekipe vaših prijateljev, ki podpirajo nekatere funkcije že pripravljenih nadzornih plošč, ki bi te dnevnike prikazale kot končni izdelek? Konec koncev je samo ogled dnevnikov v ClickHouse odličen. Bilo pa bi zelo kul, če bi bil že pripravljen v obliki armaturne plošče. Mene bi to kar navdušilo.
Obstajajo nadzorne plošče, čeprav niso standardizirane. V našem podjetju ClickHouse uporablja okoli 60 timov in najbolj čudno je, da imajo številni nadzorne plošče, ki so si jih izdelali sami, in to malo drugačne. Nekatere ekipe uporabljajo notranjo namestitev Yandex.Cloud. Nekaj že pripravljenih poročil je, čeprav ne vsa potrebna. Drugi imajo svoje.
Moji kolegi iz Metrice imajo svojo armaturno ploščo v Grafani, jaz pa svojo za njihov grozd. Gledam stvari, kot je zadetek predpomnilnika za serifni predpomnilnik. In še težje je, da uporabljamo različna orodja. Svojo nadzorno ploščo sem ustvaril z zelo starim orodjem, imenovanim Graphite-web. Popolnoma je grd. In še vedno ga uporabljam tako, čeprav bi bil Grafana verjetno bolj priročen in lep.
Osnovna stvar pri nadzornih ploščah je enaka. To so sistemske metrike za gručo: CPU, pomnilnik, disk, omrežje. Drugo – število sočasnih zahtev, število sočasnih spajanj, število zahtev na sekundo, največje število kosov za particije tabele MergeTree, zakasnitev replikacije, velikost čakalne vrste replikacije, število vstavljenih vrstic na sekundo, število vstavljenih blokov na sekundo. To je vse, kar ni pridobljeno iz dnevnikov, ampak iz meritev.
Vladimir Kolobaev: Alexey, rad bi malo popravil. Tam je Grafana. Grafana ima vir podatkov, ki je ClickHouse. To pomeni, da lahko od Grafana zahtevam neposredno ClickHouse. ClickHouse ima mizo s poleni, za vse je enaka. Zato želim dostopati do te tabele dnevnika v Grafani in si ogledati zahteve, ki jih postavlja moj strežnik. Super bi bilo imeti takšno armaturno ploščo.
Sam sem ga kolesaril. Ampak imam vprašanje - če je vse standardizirano in Grafana uporabljajo vsi, zakaj Yandex nima takšne uradne nadzorne plošče?
Kiril Švakov: Pravzaprav vir podatkov, ki gre v ClickHouse, zdaj podpira Altinity. In samo želim dati vektor, kam kopati in koga potisniti. Lahko jih vprašate, saj Yandex še vedno ustvarja ClickHouse in ne zgodbo okoli njega. Altinity je glavno podjetje, ki trenutno promovira ClickHouse. Ne bodo ga zapustili, ampak ga bodo podprli. Ker načeloma se je treba za nalaganje nadzorne plošče na spletno stran Grafana le registrirati in naložiti - ni posebnih težav.
Aleksej Milovidov: V zadnjem letu je ClickHouse dodal številne zmožnosti profiliranja poizvedb. Za vsako zahtevo o uporabi virov obstajajo metrike. Ravno pred kratkim smo dodali profiler poizvedb na še nižji ravni, da vidimo, kje poizvedba porabi vsako milisekundo. Toda za uporabo te funkcionalnosti moram odpreti odjemalca konzole in vnesti zahtevo, kar vedno pozabim. Nekje sem ga shranil in vedno znova pozabljam, kje točno.
Želim si, da bi obstajalo orodje, ki pravi samo, tukaj so vaše težke poizvedbe, razvrščene po razredu poizvedbe. Pritisnil sem na eno, pa so mi rekli, da je zato težka. Zdaj te rešitve ni. In res je precej nenavadno, da ko me ljudje vprašajo: »Povejte mi, ali obstajajo že pripravljene nadzorne plošče za Grafano?«, rečem: »Pojdite na spletno stran Grafana, tam je skupnost »Nadzorne plošče« in tam je nadzorna plošča. od Dimke je armaturna plošča od Kostyana. Ne vem, kaj je, sam ga nisem uporabljal."
Kako vplivati na spajanja, da se strežnik ne zruši v OOM?
Imam tabelo, v tabeli je samo ena particija, to je ReplacingMergeTree. Štiri leta sem vanj zapisoval podatke. Moral sem ga spremeniti in izbrisati nekaj podatkov.
To sem naredil in med obdelavo te zahteve je bil porabljen ves pomnilnik na vseh strežnikih v gruči in vsi strežniki v gruči so šli v OOM. Nato so vsi skupaj vstali, začeli združevati to isto operacijo, ta podatkovni blok in spet padli v OOM. Potem so spet vstali in spet padli. In ta stvar se ni ustavila.
Potem se je izkazalo, da je to pravzaprav napaka, ki so jo fantje odpravili. To je zelo kul, hvala lepa. Toda ostanek je ostal. In zdaj, ko razmišljam, da bi naredil nekakšno spajanje v tabeli, imam vprašanje - zakaj ne morem nekako vplivati na te spajanja? Omejite jih na primer s količino zahtevanega RAM-a ali načeloma s količino, ki bo obdelala to posebno tabelo.
Imam tabelo z imenom »Metrike«, obdelajte jo zame v dveh nitih. Ni potrebe po ustvarjanju desetih ali petih združitev vzporedno, naredite to v dveh. Mislim, da imam dovolj pomnilnika za dva, za obdelavo desetih pa morda premalo. Zakaj strah ostaja? Ker tabela raste in nekoč se bom soočil s situacijo, ki načeloma ni več posledica hrošča, ampak zato, ker se bodo podatki spreminjali v tako veliki količini, da preprosto ne bom imel dovolj pomnilnika na strežnik. In potem se bo strežnik pri združevanju zrušil v OOM. Poleg tega lahko prekličem mutacijo, vendar Merji ni več tam.
Veste, pri združevanju strežnik ne bo padel v OOM, ker se pri združevanju količina RAM-a porabi samo za en majhen obseg podatkov. Torej bo vse v redu ne glede na količino podatkov.
Vladimir Kolobaev: Globa. Tu je trenutek tak, da sem po odpravi napake zase prenesel novo različico in na drugi tabeli, manjši, kjer je veliko particij, sem izvedel podobno operacijo. In med spajanjem je bilo na strežniku zgorelo približno 100 GB RAM-a. Imel sem 150 zasedenih, 100 pojedenih in še 50 GB okna, tako da nisem padel v OOM.
Kaj me trenutno ščiti pred padcem v OOM, če dejansko porabi 100 GB RAM-a? Kaj storiti, če nenadoma zmanjka RAM-a pri združitvah?
Aleksej Milovidov: Obstaja tak problem, da poraba RAM-a posebej za združevanje ni omejena. In druga težava je, da če je bilo dodeljeno nekakšno spajanje, ga je treba izvesti, ker je zabeleženo v dnevniku replikacije. Dnevnik podvajanja so dejanja, ki so potrebna, da se replika spravi v konsistentno stanje. Če ne izvedete ročnih manipulacij, ki bodo povrnile ta dnevnik podvajanja, bo treba spajanje tako ali drugače izvesti.
Seveda ne bi bila odveč omejitev RAM-a, ki "za vsak slučaj" ščiti pred OOM. To ne bo pomagalo dokončati spajanja, začelo se bo znova, doseglo določen prag, vrglo izjemo in nato znova začelo - iz tega ne bo nič dobrega. A načeloma bi bilo koristno uvesti to omejitev.
Kako bo razvit gonilnik Golang za ClickHouse?
Gonilnik Golang, ki ga je napisal Kirill Shvakov, zdaj uradno podpira ekipa ClickHouse. On , zdaj je velik in pravi.
Majhna opomba. Obstaja čudovito in ljubljeno skladišče normalnih oblik neskončnega reda – to je Vertica. Imajo tudi svoj uradni gonilnik za python, ki ga podpirajo razvijalci Vertica. Večkrat se je zgodilo, da so se različice za shranjevanje in različice gonilnikov precej razlikovale in je gonilnik na neki točki prenehal delovati. In druga točka. Podporo za ta uradni gonilnik, se mi zdi, izvaja sistem "nipple" - napišete jim težavo in ta visi za vedno.
Imam dve vprašanji. Zdaj je Kirilov gonilnik Golang skoraj privzeti način za komunikacijo iz Golanga s ClickHouse. Razen če kdo še vedno komunicira preko http vmesnika, ker mu je tako všeč. Kako bo potekal razvoj tega gonilnika? Ali bo sinhroniziran s kakršnimi koli prelomnimi spremembami v samem skladišču? In kakšen je postopek obravnave zadeve?
Kiril Švakov: Prvi je, kako je vse birokratsko organizirano. O tej točki se ni razpravljalo, zato nimam kaj odgovoriti.
Za odgovor na vprašanje o težavi potrebujemo malo zgodovine gonilnika. Delal sem za podjetje, ki je imelo veliko podatkov. Šlo je za reklamni spinner z ogromno dogodki, ki jih je bilo treba nekam shraniti. In na neki točki se je pojavil ClickHouse. Napolnili smo ga s podatki in najprej je bilo vse v redu, potem pa se je ClickHouse sesul. V tistem trenutku smo se odločili, da ga ne potrebujemo.
Leto kasneje smo se vrnili k ideji o uporabi ClickHouse in tja smo morali nekako zapisati podatke. Uvodno sporočilo je bilo naslednje: strojna oprema je zelo šibka, sredstev je malo. Vendar smo vedno delali na ta način in smo se zato ozirali proti domačemu protokolu.
Ker smo delali v Go, je bilo jasno, da potrebujemo voznika Go. To sem delal skoraj polno - to je bila moja delovna naloga. Pripeljali smo ga do neke točke in načeloma nihče ni predvideval, da ga bo uporabljal kdo drug kot mi. Potem je prišel CloudFlare s popolnoma enakim problemom in nekaj časa smo z njimi delali zelo gladko, saj so imeli enake naloge. Poleg tega smo to storili tako v ClickHouse sami kot v gonilniku.
V nekem trenutku sem s tem preprosto nehal, ker se je moja aktivnost v smislu ClickHouse in dela malo spremenila. Zato vprašanja niso zaprta. Občasno se ljudje, ki sami kaj potrebujejo, zavežejo v skladišče. Potem pogledam pull request in včasih tudi sam kaj uredim, vendar se to zgodi redko.
Želim se vrniti k vozniku. Pred nekaj leti, ko se je vse skupaj začelo, je bil tudi ClickHouse drugačen in z drugačnimi zmogljivostmi. Zdaj vemo, kako predelati gonilnik, da bo dobro deloval. Če se to zgodi, potem bo verzija 2 zaradi nakopičenih bergel v vsakem primeru nekompatibilna.
Ne vem, kako naj organiziram to zadevo. Sam nimam veliko časa. Če nekateri ljudje dokončajo voznika, jim lahko pomagam in jim povem, kaj naj naredijo. Toda o aktivni udeležbi Yandexa pri razvoju projekta še niso razpravljali.
Aleksej Milovidov: Pravzaprav glede teh voznikov še ni birokracije. Edina stvar je, da so predloženi uradni organizaciji, to pomeni, da je ta gonilnik priznan kot uradna privzeta rešitev za Go. Obstaja še nekaj gonilnikov, vendar pridejo ločeno.
Za te voznike nimamo notranjega razvoja. Vprašanje je, ali lahko zaposlimo posamezno osebo, ne za tega voznika, ampak za razvoj vseh voznikov skupnosti, ali lahko poiščemo nekoga od zunaj.
Zunanji slovar se ne naloži po ponovnem zagonu z omogočeno nastavitvijo lazy_load. Kaj storiti?
Omogočeno imamo nastavitev lazy_load in po ponovnem zagonu strežnika se slovar ne naloži sam od sebe. Dvigne se šele, ko uporabnik dostopi do tega slovarja. In ko prvič dostopam do njega, prikaže napako. Ali je mogoče nekako samodejno naložiti slovarje s pomočjo ClickHouse ali morate vedno sami nadzorovati njihovo pripravljenost, da uporabniki ne prejmejo napak?
Morda imamo staro različico ClickHouse, zato se slovar ni samodejno naložil. Bi lahko bilo tako?
Prvič, slovarje je mogoče prisilno naložiti s poizvedbo sistemsko ponovno nalaganje slovarjev. Drugič, glede napake - če je slovar že naložen, bodo poizvedbe delovale glede na podatke, ki so bili naloženi. Če slovar še ni naložen, se bo naložil neposredno med zahtevo.
To ni zelo priročno za težke slovarje. Na primer, iz MySQL morate potegniti milijon vrstic. Nekdo naredi preprosto izbiro, vendar bo ta izbira čakala na isti milijon vrstic. Tukaj sta dve rešitvi. Prvi je, da izklopite lazy_load. Drugič, ko strežnik deluje, preden ga obremenite, naredite slovar za ponovno nalaganje sistema ali samo naredite poizvedbo, ki uporablja slovar. Nato se bo slovar naložil. Morate nadzorovati razpoložljivost slovarjev z omogočeno nastavitvijo lazy_load, ker jih ClickHouse ne naloži samodejno.
Odgovor na zadnje vprašanje je, ali je različica stara ali pa jo je treba odpraviti.
Kaj storiti z dejstvom, da sistemsko ponovno nalaganje slovarjev ne naloži nobenega od številnih slovarjev, če se vsaj eden od njih zruši z napako?
Obstaja še eno vprašanje glede slovarjev za ponovno nalaganje sistema. Imamo dva slovarja - eden ni naložen, drugi je naložen. V tem primeru Slovarji za ponovno nalaganje sistema ne naložijo nobenega slovarja in morate naložiti določenega po točkah po njegovem imenu z uporabo slovarja za ponovno nalaganje sistema. Je to povezano tudi z različico ClickHouse?
Želim te osrečiti. To vedenje se je spreminjalo. To pomeni, da se bo spremenil tudi ClickHouse, če ga posodobite. Če niste zadovoljni s svojim trenutnim vedenjem sistemsko ponovno nalaganje slovarjev, posodobite in upajmo, da se bo spremenilo na bolje.
Ali obstaja način, da konfigurirate podrobnosti v konfiguraciji ClickHouse, vendar jih ne prikažete v primeru napak?
Naslednje vprašanje je o napakah v zvezi s slovarjem, in sicer podrobnosti. Podrobnosti povezave smo določili v konfiguraciji ClickHouse za slovar in če pride do napake, prejmemo te podrobnosti in geslo v odgovor.
To napako smo rešili z dodajanjem podrobnosti v konfiguracijo gonilnika ODBC. Ali obstaja način, da konfigurirate podrobnosti v konfiguraciji ClickHouse, vendar ne prikažete teh podrobnosti v primeru napak?
Prava rešitev tukaj je, da te poverilnice določite v odbc.ini, v samem ClickHouse pa določite samo ime vira podatkov ODBC. To se ne bo zgodilo za druge slovarske vire - niti za slovar z MySQL niti za druge ne bi smeli videti gesla, ko prejmete sporočilo o napaki. Za ODBC bom tudi pogledal - če obstaja, ga morate samo odstraniti.
Bonus: ozadja za Zoom iz srečanj
S klikom na sliko se najbolj vztrajnim bralcem odprejo bonus ozadja z druženj. Gasimo požar skupaj z maskotami tehnologije Avito, se posvetujemo s kolegi iz sistemske administratorke ali starodobnega računalniškega krožka in vsakodnevno vodimo srečanja pod mostom v ozadju grafitov.
Vir: www.habr.com