U travnju su se Avitovi inženjeri okupili na online sastancima s glavnim ClickHouse programerom Alexeyem Milovidovim i Kirillom Shvakovom, Golang programerom iz Integrosa. Razgovarali smo o tome kako koristimo sustav za upravljanje bazom podataka i na koje poteškoće nailazimo.
Na temelju sastanka sastavili smo članak s odgovorima stručnjaka na naša i pitanja publike o sigurnosnim kopijama, ponovnom dijeljenju podataka, vanjskim rječnicima, Golang driveru i ažuriranju verzija ClickHousea. Može biti korisno programerima koji već aktivno rade s Yandex DBMS-om i zainteresirani su za njegovu sadašnjost i budućnost. Prema zadanim postavkama, odgovore daje Alexey Milovidov, osim ako nije drugačije napisano.
Budite oprezni, ispod reza ima puno teksta. Nadamo se da će vam sadržaj s pitanjima pomoći u navigaciji.
sadržaj
Ako ne želite čitati tekst, možete pogledati snimku druženja . Vremenski kodovi su u prvom komentaru ispod videa.
ClickHouse se stalno ažurira, ali naši podaci nisu. Što učiniti u vezi s tim?
ClickHouse se stalno ažurira, a naši podaci, koji su optimizirani i konačno obrađeni, nisu ažurirani i nalaze se u sigurnosnoj kopiji.
Recimo da smo imali neki problem i podaci su izgubljeni. Odlučili smo se vratiti i pokazalo se da se stare particije, koje su pohranjene na rezervnim poslužiteljima, jako razlikuju od trenutno korištene verzije ClickHousea. Što učiniti u takvoj situaciji i je li to moguće?
Situacija u kojoj ste vratili podatke iz sigurnosne kopije u starom formatu, ali se oni ne povezuju s novom verzijom, je nemoguća. Brinemo se da format podataka u ClickHouseu uvijek ostane kompatibilan unazad. To je puno važnije od kompatibilnosti s prethodnim verzijama u funkcionalnosti ako se promijenilo ponašanje neke rijetko korištene funkcije. Nova verzija ClickHousea uvijek bi trebala moći čitati podatke koji su pohranjeni na disku. Ovo je zakon.
Koje su trenutačne najbolje prakse za sigurnosno kopiranje podataka iz ClickHousea?
Kako napraviti sigurnosne kopije, s obzirom da imamo optimizirane završne operacije, ogromnu bazu podataka od terabajta i podatke koji se ažuriraju, recimo, zadnja tri dana, a onda im se ne događaju nikakve procedure?
Možemo napraviti vlastito rješenje i napisati na bash: prikupite ove sigurnosne kopije na takav i takav način. Možda nema potrebe za štakama, a bicikl je davno izumljen?
Počnimo s najboljim primjerima iz prakse. Moji kolege uvijek savjetuju, kao odgovor na pitanja o sigurnosnim kopijama, podsjetiti ih na uslugu Yandex.Cloud, gdje je ovaj problem već riješen. Stoga ga koristite ako je moguće.
Ne postoji cjelovito rješenje za sigurnosne kopije, sto posto ugrađeno u ClickHouse. Postoje praznine koje se mogu koristiti. Da biste dobili cjelovito rješenje, morat ćete ili malo petljati ručno ili stvoriti omote u obliku skripti.
Započet ću s najjednostavnijim rješenjima, a završiti s najsofisticiranijima, ovisno o količini podataka i veličini klastera. Što je veći klaster, to rješenje postaje složenije.
Ako tablica s podacima zauzima samo nekoliko gigabajta, backup se može napraviti ovako:
- Spremi definiciju tablice tj. metapodatke − pokazati stvoriti tablicu.
- Napravite ispis koristeći ClickHouse klijent - odabrati * sa stola podnijeti. Prema zadanim postavkama primit ćete datoteku u formatu odvojenom tabulatorom. Ako želite biti učinkovitiji, možete to učiniti u izvornom formatu.
Ako je količina podataka veća, sigurnosna kopija će oduzeti više vremena i puno prostora. To se zove logička sigurnosna kopija; nije vezana za format podataka ClickHouse. Ako jest, u krajnjem slučaju možete napraviti sigurnosnu kopiju i učitati je u MySQL radi oporavka.
Za naprednije slučajeve, ClickHouse ima ugrađenu mogućnost stvaranja snimke particija u lokalnom datotečnom sustavu. Ova je značajka dostupna kao zahtjev alter tablica zamrznuti particiju. Ili jednostavno alter zamrznuti stol - ovo je snimka cijele tablice.
Snapshot će biti kreiran konzistentno za jednu tablicu na jednom shardu, odnosno na ovaj način je nemoguće kreirati konzistentan snapshot cijelog klastera. Ali za većinu zadataka nema takve potrebe, a dovoljno je izvršiti zahtjev na svakom shardu i dobiti konzistentnu snimku. Izrađen je u obliku tvrdih veza i stoga ne zauzima dodatni prostor. Zatim kopirate ovu snimku na poslužitelj za sigurnosne kopije ili u pohranu koju koristite za sigurnosne kopije.
Vraćanje takve sigurnosne kopije vrlo je jednostavno. Najprije izradite tablice pomoću postojećih definicija tablica. Zatim kopirajte spremljene snimke particija u Directory-Detached za ove tablice i pokrenite upit pričvrstiti particiju. Ovo rješenje je sasvim prikladno za najozbiljnije količine podataka.
Ponekad vam treba nešto još hladnije - u slučajevima kada imate desetke ili čak stotine terabajta na svakom poslužitelju i stotine poslužitelja. Ovdje postoji rješenje koje sam pokupio od svojih kolega iz Yandex.Metrice. Ne bih je preporučio svima - pročitajte je i zaključite sami je li prikladna ili ne.
Prvo morate stvoriti nekoliko poslužitelja s velikim policama za diskove. Zatim na tim poslužiteljima podignite nekoliko ClickHouse poslužitelja i konfigurirajte ih tako da rade kao još jedna replika za iste šardove. Zatim upotrijebite datotečni sustav ili neki alat na tim poslužiteljima koji vam omogućuje stvaranje snimki. Ovdje postoje dvije mogućnosti. Prva opcija su LVM snimke, druga opcija je ZFS na Linuxu.
Nakon toga, svaki dan trebate stvoriti snimku, ona će ležati i zauzeti malo prostora. Naravno, ako se podaci promijene, količina prostora će se s vremenom povećati. Ova snimka se može izvaditi u bilo kojem trenutku i vratiti podatke, tako čudno rješenje. Osim toga, također moramo ograničiti te replike u konfiguraciji kako ne bi pokušale postati vođe.
Hoće li se moći organizirati kontrolirani zastoj replika u oknima?
Ove godine planirate napraviti okna u ClickHouseu. Hoće li u njima biti moguće organizirati kontrolirano zaostajanje replika? Njime bismo se htjeli zaštititi od negativnih scenarija izmjenama i drugim promjenama.
Je li moguće napraviti neku vrstu vraćanja za izmjene? Na primjer, u postojećem oknu uzmite i recite da do ovog trenutka primjenjujete promjene, a od ovog trenutka prestajete primjenjivati promjene?
Ako je naredba došla do našeg klastera i pokvarila ga, tada imamo uvjetnu repliku s odmakom od sat vremena, gdje možemo reći da je koristimo trenutno, ali nećemo primijeniti promjene na nju zadnjih deset minuta?
Prvo, o kontroliranom kašnjenju replika. Bio je takav zahtjev od korisnika, a mi smo napravili problem na Githubu sa zahtjevom: "Ako nekome ovo treba, lajkajte, stavite srce." Nitko nije isporučio i problem je zatvoren. Međutim, tu priliku već možete dobiti postavljanjem ClickHousea. Istina, samo počevši od verzije 20.3.
ClickHouse stalno izvodi spajanje podataka u pozadini. Kada se spajanje završi, određeni skup dijelova podataka zamjenjuje se većim dijelom. Istodobno, dijelovi podataka koji su prije bili tu još neko vrijeme ostaju na disku.
Prvo, oni se nastavljaju pohranjivati sve dok postoje upiti odabira koji ih koriste, kako bi se osigurala operacija bez blokiranja. Odabrani upiti lako se čitaju iz starih dijelova.
Drugo, postoji i vremenski prag - stari podaci leže na disku osam minuta. Tih osam minuta može se prilagoditi i čak pretvoriti u jedan dan. To će koštati prostora na disku: ovisno o protoku podataka, pokazalo se da će se podaci u zadnjem danu ne samo udvostručiti, već bi mogli postati i pet puta više. Ali ako postoji ozbiljan problem, možete zaustaviti ClickHouse poslužitelj i sve riješiti.
Sada se postavlja pitanje kako to štiti od promjena. Ovdje vrijedi dublje pogledati jer je u starijim verzijama ClickHousea alter radio na takav način da je jednostavno izravno mijenjao dijelove. Postoji dio podataka s nekim datotekama, a mi radimo, na primjer, alter drop stupac. Zatim se ovaj stupac fizički uklanja iz svih dijelova.
Ali počevši od verzije 20.3, mehanizam mijenjanja potpuno je promijenjen i sada su dijelovi podataka uvijek nepromjenjivi. Oni se uopće ne mijenjaju - izmjene sada rade na isti način kao i spajanja. Umjesto da dio zamijenimo na licu mjesta, stvaramo novi. U novom dijelu datoteke koje nisu promijenjene postaju tvrde veze, a ako izbrišemo stupac, on će jednostavno nedostajati u novom dijelu. Stari će se dio prema zadanim postavkama izbrisati nakon osam minuta, a ovdje možete podesiti gore navedene postavke.
Isto se odnosi na promjene kao što su mutacije. Kada to učinite mijenjati izbrisati ili mijenjati ažuriranje, ne mijenja komad, već stvara novi. I onda briše staru.
Što ako se promijenila struktura tablice?
Kako vratiti sigurnosnu kopiju koja je napravljena sa starom shemom? A drugo pitanje odnosi se na slučaj sa snimkama i alatima za datotečni sustav. Je li Btrfs dobar ovdje umjesto ZFS-a na Linux LVM-u?
Ako to uradiš pričvrstiti particiju particije s drugačijom strukturom, tada će vam ClickHouse reći da to nije moguće. Ovo je rješenje. Prvi je stvoriti privremenu tablicu tipa MergeTree sa starom strukturom, priložiti podatke tamo pomoću privitka i napraviti upit za promjenu. Zatim možete kopirati ili prenijeti te podatke i ponovno ih priložiti ili upotrijebiti zahtjev alter tablica premjestiti particiju.
Sada je drugo pitanje može li se koristiti Btrfs. Za početak, ako imate LVM, onda su LVM snimke dovoljne, a datotečni sustav može biti ext4, nije bitno. Kod Btrtsa sve ovisi o vašem iskustvu u korištenju. Ovo je zreo datotečni sustav, ali još uvijek postoje neke sumnje o tome kako će sve funkcionirati u praksi u određenom scenariju. Ne bih preporučio korištenje ovoga osim ako nemate Btrfs u produkciji.
Koje su trenutačne najbolje prakse u dijeljenju podataka?
Pitanje ponovnog dijeljenja složeno je i višestruko. Ovdje postoji nekoliko mogućih odgovora. Možete krenuti s jedne strane i reći ovo - ClickHouse nema ugrađenu značajku ponovnog dijeljenja. Ali bojim se da ovaj odgovor nikome neće odgovarati. Stoga, možete ići s druge strane i reći da ClickHouse ima mnogo načina za ponovno dijeljenje podataka.
Ako klasteru ponestane prostora ili ne može podnijeti opterećenje, dodajete nove poslužitelje. Ali ti su poslužitelji standardno prazni, na njima nema podataka, nema opterećenja. Morate preurediti podatke tako da budu ravnomjerno raspoređeni po novom, većem klasteru.
Prvi način na koji se to može učiniti je kopiranje dijela particija na nove poslužitelje pomoću zahtjeva mijenjati particiju dohvaćanja tablice. Na primjer, imali ste particije po mjesecima i uzmete prvi mjesec 2017. i kopirate ga na novi server, zatim kopirate treći mjesec na neki drugi novi server. I to činite sve dok se više-manje ne ujednači.
Prijenos se može izvršiti samo za one particije koje se ne mijenjaju tijekom snimanja. Za svježe particije, snimanje će morati biti onemogućeno, jer njihov prijenos nije atomski. U protivnom ćete dobiti duplikate ili praznine u podacima. Međutim, ova metoda je praktična i djeluje prilično učinkovito. Mrežom se prenose gotove komprimirane particije, odnosno podaci se ne komprimiraju niti ponovno kodiraju.
Ova metoda ima jedan nedostatak, a ovisi o shemi dijeljenja, jeste li se pridružili ovoj shemi dijeljenja, koji ste ključ za dijeljenje imali. U vašem primjeru za slučaj s metrikom, ključ dijeljenja je hash putanje. Kada odaberete Distribuiranu tablicu, ona ide na sve fragmente u klasteru odjednom i od tamo preuzima podatke.
To znači da vam zapravo nije bitno koji su podaci završili na kojem shardu. Glavno je da podaci duž jedne staze završe na jednom shardu, ali nije važno na kojem. U ovom slučaju, prijenos gotovih particija je savršen, jer s upitima odabira također ćete dobiti potpune podatke - prije ponovnog dijeljenja ili nakon, shema zapravo nije bitna.
Ali postoje slučajevi koji su složeniji. Ako se na razini logike aplikacije oslanjate na posebnu shemu šardinga, taj klijent se nalazi na tom i tom shardu i zahtjev se može poslati izravno tamo, a ne u Distribuiranu tablicu. Ili koristite relativno noviju verziju ClickHousea i omogućili ste postavku optimiziraj preskoči neiskorištene dijelove. U ovom slučaju, tijekom upita odabira, analizirat će se izraz u odjeljku where i izračunat će se koji se shardovi trebaju koristiti prema shemi dijeljenja. Ovo radi pod uvjetom da su podaci particionirani točno prema ovoj shemi dijeljenja. Ako ste ih ručno preuređivali, korespondencija se može promijeniti.
Dakle, ovo je metoda broj jedan. I čekam vaš odgovor, je li metoda prikladna ili idemo dalje.
Vladimir Kolobaev, glavni administrator sustava u Avitu: Alexey, metoda koju ste spomenuli ne funkcionira dobro kada trebate rasporediti teret, uključujući čitanje. Možemo uzeti particiju koja je mjesečna i možemo uzeti prethodni mjesec u drugi čvor, ali kada dođe zahtjev za ove podatke, učitat ćemo samo njih. No željeli bismo učitati cijeli klaster jer će u suprotnom neko vrijeme cijelo opterećenje čitanja obrađivati dva sharda.
Aleksej Milovidov: Odgovor je ovdje čudan - da, loše je, ali moglo bi djelovati. Objasnit ću točno kako. Vrijedno je pogledati scenarij opterećenja koji dolazi iza vaših podataka. Ako se radi o podacima praćenja, onda gotovo sigurno možemo reći da se velika većina zahtjeva odnosi na svježe podatke.
Instalirali ste nove poslužitelje, migrirali stare particije, ali i promijenili način bilježenja svježih podataka. A svježi podaci će se širiti po cijelom klasteru. Tako će nakon samo pet minuta zahtjevi za zadnjih pet minuta ravnomjerno opteretiti klaster, a nakon jednog dana zahtjevi za XNUMX sata ravnomjerno će opteretiti klaster. A zahtjevi za prethodni mjesec, nažalost, ići će samo na dio servera klastera.
Ali često nećete imati zahtjeve posebno za veljaču 2019. Najvjerojatnije, ako zahtjevi uđu u 2019. godinu, onda će to biti za cijelu 2019. godinu - za veliki vremenski period, a ne za neki mali raspon. A takvi će zahtjevi također moći ravnomjerno opteretiti klaster. Ali općenito, potpuno je točna vaša primjedba da se radi o ad hoc rješenju koje ne raspoređuje podatke potpuno ravnomjerno.
Imam još nekoliko točaka za odgovor na pitanje. Jedan od njih je o tome kako inicijalno dizajnirati shemu dijeljenja tako da bi ponovno dijeljenje uzrokovalo manje boli. To nije uvijek moguće.
Na primjer, imate podatke praćenja. Podaci praćenja rastu iz tri razloga. Prvi je prikupljanje povijesnih podataka. Drugi je rast prometa. I treće je povećanje broja stvari koje podliježu nadzoru. Postoje nove mikrousluge i metrike koje je potrebno spremiti.
Moguće je da je od ovih najveći porast povezan s trećim razlogom - povećanjem korištenja monitoringa. I u ovom slučaju, vrijedi pogledati prirodu opterećenja, koji su glavni upiti za odabir. Osnovni odabirni upiti najvjerojatnije će se temeljiti na nekom podskupu metrike.
Na primjer, upotreba CPU-a na nekim poslužiteljima od strane neke usluge. Ispostavilo se da postoji određeni podskup ključeva pomoću kojih dobivate te podatke. A sam zahtjev za tim podacima najvjerojatnije je prilično jednostavan i završava se u desecima milisekundi. Koristi se za nadzor usluga i nadzornih ploča. Nadam se da sam ovo dobro shvatio.
Vladimir Kolobajev: Činjenica je da se vrlo često pozivamo na povijesne podatke, budući da sadašnje stanje uspoređujemo s povijesnim u stvarnom vremenu. I važno nam je da imamo brz pristup velikoj količini podataka, a ClickHouse to radi izvrstan posao.
Potpuno ste u pravu, većinu zahtjeva za čitanje doživljavamo u zadnjem danu, kao i svaki sustav za praćenje. Ali u isto vrijeme, opterećenje povijesnih podataka također je prilično veliko. To je zapravo iz sustava za uzbunjivanje koji se okreće svakih trideset sekundi i kaže ClickHouseu: “Dajte mi podatke za posljednjih šest tjedana. Sada mi napravi neku vrstu pomičnog prosjeka od njih i usporedimo trenutnu vrijednost s povijesnom."
Želio bih reći da za takve vrlo nedavne zahtjeve imamo još jednu malu tablicu u kojoj spremamo samo dva dana podataka, a glavni zahtjevi lete u nju. Šaljemo samo velike povijesne upite u veliku razdijeljenu tablicu.
Aleksej Milovidov: Nažalost, pokazalo se da je slabo primjenjivo za vaš scenarij, ali reći ću vam opis dvije loše i složene sheme dijeljenja koje ne treba koristiti, ali koje se koriste u servisu mojih prijatelja.
Postoji glavni klaster s Yandex.Metrica događajima. Događaji su prikazi stranica, klikovi i konverzije. Većina zahtjeva ide na određenu web stranicu. Otvorite uslugu Yandex.Metrica, imate web stranicu - avito.ru, idite na izvješće i postavlja se zahtjev za vašu web stranicu.
Ali postoje i drugi zahtjevi - analitički i globalni - koje postavljaju interni analitičari. Za svaki slučaj, napominjem da interni analitičari podnose zahtjeve samo za Yandexove usluge. Ali ipak, čak i usluge Yandexa zauzimaju značajan udio u svim podacima. Ovo nisu zahtjevi za određene brojače, već za šire filtriranje.
Kako organizirati podatke na način da sve radi učinkovito za jedan brojač, a i globalni upiti? Druga poteškoća je što je broj zahtjeva u ClickHouseu za klaster Metrics nekoliko tisuća u sekundi. U isto vrijeme, jedan ClickHouse poslužitelj ne može podnijeti netrivijalne zahtjeve, na primjer, nekoliko tisuća u sekundi.
Veličina klastera je šest stotina i nešto poslužitelja. Ako jednostavno povučete Distribuiranu tablicu preko ovog klastera i tamo pošaljete nekoliko tisuća zahtjeva, to će postati još gore od slanja na jedan poslužitelj. S druge strane, odmah se odbacuje opcija da se podaci ravnomjerno rasporede, a mi odemo i tražimo sa svih servera.
Postoji opcija koja je dijametralno suprotna. Zamislite da podijelimo podatke na više web-mjesta, a zahtjev za jedno web-mjesto ide na jedan shard. Sada će klaster moći obraditi deset tisuća zahtjeva u sekundi, ali na jednom shardu bilo koji će zahtjev raditi presporo. Više se neće skalirati u smislu propusnosti. Pogotovo ako je ovo stranica avito.ru. Neću otkriti tajnu ako kažem da je Avito jedno od najposjećenijih mjesta u RuNetu. A obraditi ga na jednu krhotinu bila bi ludost.
Stoga je shema dijeljenja dizajnirana na lukaviji način. Cjelokupni klaster podijeljen je u nekoliko klastera koje nazivamo slojevima. Svaki klaster sadrži od desetak do nekoliko desetaka krhotina. Ukupno ima trideset i devet takvih klastera.
Kako se sve to mjeri? Broj klastera se ne mijenja - kako ih je bilo prije nekoliko godina trideset i devet, tako je i ostalo. Ali unutar svakog od njih postupno povećavamo broj fragmenata kako prikupljamo podatke. A shema šardinga u cjelini je ovakva: ti su klasteri podijeljeni na web stranice, a kako bi se razumjelo koja je web stranica na kojem klasteru, koristi se zasebna metabaza u MySQL-u. Jedno mjesto - na jednom klasteru. A unutar njega se događa dijeljenje prema ID-ovima posjetitelja.
Prilikom snimanja dijelimo ih s ostatkom dijeljenja ID-a posjetitelja. Ali kada dodajemo novi shard, shema dijeljenja se mijenja; nastavljamo dijeliti, ali s ostatkom dijeljenja s drugim brojem. To znači da se jedan posjetitelj već nalazi na nekoliko poslužitelja i na to se ne možete osloniti. Ovo se radi isključivo kako bi se osiguralo da su podaci bolje komprimirani. A kada postavljamo zahtjeve, idemo na tablicu Distributed, koja gleda na klaster i pristupa desecima poslužitelja. Ovo je tako glupa shema.
Ali moja će priča biti nepotpuna ako ne kažem da smo napustili ovu shemu. U novoj shemi promijenili smo sve i kopirali sve podatke koristeći clickhouse-copier.
U novoj shemi sva su mjesta podijeljena u dvije kategorije - velike i male. Ne znam kako je odabran prag, ali rezultat je bio da su velika mjesta zabilježena na jednom klasteru, gdje ima 120 shardova s po tri replike - dakle, 360 poslužitelja. A shema šardinga je takva da svaki zahtjev ide na sve šardove odjednom. Ako sada otvorite bilo koju stranicu izvješća za avito.ru u Yandex.Metrici, zahtjev će ići na 120 poslužitelja. U Runetu postoji nekoliko velikih stranica. A zahtjeva nije tisuću u sekundi, nego čak manje od sto. Sve to tiho žvače Distributed table koju svaki od njih obrađuje sa 120 servera.
A drugi klaster je za mala mjesta. Ovdje je shema dijeljenja temeljena na ID-u web-mjesta, a svaki zahtjev ide na točno jedan shard.
ClickHouse ima uslužni program za kopiranje Clickhouse. Možete li nam reći nešto o njoj?
Odmah ću reći da je ovo rješenje glomaznije i nešto manje produktivno. Prednost je u tome što potpuno razmazuje podatke prema uzorku koji odredite. Ali nedostatak uslužnog programa je taj što uopće ne radi ponovno. Kopira podatke iz jedne sheme klastera u drugu shemu klastera.
To znači da za rad morate imati dva klastera. Mogu se nalaziti na istim poslužiteljima, ali se podaci ipak neće premještati inkrementalno, već će se kopirati.
Na primjer, bila su četiri poslužitelja, sada ih je osam. Kreirate novu Distribuiranu tablicu na svim poslužiteljima, nove lokalne tablice i pokrenete clickhouse-copier, naznačite u njoj radnu shemu koju treba čitati od tamo, prihvatite novu shemu šardinga i tamo prenesite podatke. A na starim poslužiteljima trebat će vam jedan i pol puta više prostora nego sada jer na njima moraju ostati stari podaci, a na njih će stići pola istih starih podataka. Ako ste unaprijed mislili da podatke treba ponovno podijeliti i da ima prostora, onda je ova metoda prikladna.
Kako Clickhouse-copier radi unutra? Sav posao rastavlja u skup zadataka za obradu jedne particije jedne tablice na jednom shardu. Svi ovi zadaci mogu se izvršavati paralelno, a clickhouse-copier se može pokrenuti na različitim strojevima u više instanci, ali ono što radi za jednu particiju nije ništa više od odabira umetanja. Podaci se čitaju, dekomprimiraju, ponovno particioniraju, zatim ponovno komprimiraju, negdje zapisuju i ponovno sortiraju. Ovo je teža odluka.
Imali ste pilot stvar koja se zove resharding. Što s njom?
Još 2017. imali ste pilot stvar koja se zove resharding. Postoji čak i opcija u ClickHouseu. Koliko sam shvatio, nije poletjelo. Možete li mi reći zašto se to dogodilo? Čini se da je vrlo relevantno.
Čitav je problem u tome što ako je potrebno ponovno podijeliti podatke na mjestu, potrebna je vrlo složena sinkronizacija kako bi se to učinilo atomski. Kad smo počeli promatrati kako ta sinkronizacija funkcionira, postalo je jasno da postoje temeljni problemi. I ti temeljni problemi nisu samo teoretski, već su se odmah počeli pokazivati iu praksi u obliku nečega što se može objasniti vrlo jednostavno - ništa ne funkcionira.
Je li moguće spojiti sve dijelove podataka prije premještanja na spore diskove?
Pitanje o TTL-u s opcijom prelaska na spori disk u kontekstu spajanja. Postoji li način, osim putem crona, da spojite sve dijelove u jedan prije nego što ih premjestite na spore diskove?
Odgovor na pitanje je li moguće nekako automatski zalijepiti sve dijelove u jedan prije prijenosa - ne. Mislim da ovo nije potrebno. Ne morate spajati sve dijelove u jedan, već jednostavno računajte na to da će se automatski prebaciti na spore diskove.
Imamo dva kriterija za pravila prijenosa. Prvi je takav kakav je ispunjen. Ako trenutna razina pohrane ima manje od određenog postotka slobodnog prostora, odabiremo jedan dio i premještamo ga u sporiju pohranu. Ili bolje rečeno, ne sporiji, već sljedeći - kako konfigurirate.
Drugi kriterij je veličina. Radi se o premještanju velikih komada. Možete podesiti prag prema slobodnom prostoru na brzom disku, a podaci će se automatski prenijeti.
Kako migrirati na nove verzije ClickHousea ako ne postoji mogućnost provjere kompatibilnosti unaprijed?
O ovoj se temi redovito raspravlja uzimajući u obzir različite verzije, i dalje. Koliko je sigurna nadogradnja s verzije 19.11 na 19.16 i npr. s 19.16 na 20.3. Koji je najbolji način za prelazak na nove verzije bez mogućnosti provjere kompatibilnosti u sandboxu unaprijed?
Ovdje postoji nekoliko "zlatnih" pravila. Prvo - . Velik je, ali postoje zasebni paragrafi o unatrag nekompatibilnim promjenama. Nemojte ove točke tretirati kao crvenu zastavu. To su obično manje nekompatibilnosti koje uključuju neke rubne funkcije koje vrlo vjerojatno ne koristite.
Drugo, ako ne postoji način za provjeru kompatibilnosti u sandboxu, a želite izvršiti ažuriranje odmah u produkciji, preporuka je da to ne morate činiti. Najprije izradite sandbox i testirajte. Ako nema testnog okruženja, onda najvjerojatnije nemate veliku tvrtku, što znači da možete kopirati neke podatke na svoje prijenosno računalo i provjeriti radi li sve ispravno na njemu. Možete čak podići nekoliko replika lokalno na vašem računalu. Ili možete pokupiti novu verziju negdje u blizini i tamo učitati neke od podataka - to jest, stvoriti improvizirano testno okruženje.
Drugo pravilo je da se ne ažurira tjedan dana nakon izdavanja verzije zbog otkrivanja grešaka u proizvodnji i kasnijih brzih popravka. Razmislimo o numeriranju ClickHouse verzija kako se ne bismo zbunili.
Postoji verzija 20.3.4. Broj 20 označava godinu proizvodnje - 2020. Sa stajališta onoga što je unutra, to nije bitno, pa na to nećemo obraćati pozornost. Sljedeće - 20.3. Povećavamo drugi broj - u ovom slučaju 3 - svaki put kada objavimo izdanje s nekom novom funkcionalnošću. Ako želimo dodati neku značajku ClickHouseu, moramo povećati ovaj broj. Odnosno, u verziji 20.4 ClickHouse će raditi još bolje. Treća znamenka je 20.3.4. Ovdje je 4 broj izdanja zakrpa u kojima nismo dodali nove značajke, ali smo popravili neke greške. A 4 znači da smo to učinili četiri puta.
Nemojte misliti da je ovo nešto strašno. Obično korisnik može instalirati najnoviju verziju i ona će raditi bez ikakvih problema s produženjem rada godišnje. Ali zamislite da se u nekoj funkciji za obradu bitmapa, koju su dodali naši kineski drugovi, poslužitelj ruši prilikom prosljeđivanja netočnih argumenata. Imamo odgovornost to popraviti. Izdat ćemo novu verziju zakrpe i ClickHouse će postati stabilniji.
Ako imate ClickHouse pokrenut u produkciji, a nova verzija ClickHousea izlazi s dodatnim značajkama - na primjer, 20.4.1 je prva, nemojte žuriti s puštanjem u produkciju prvog dana. Zašto je to uopće potrebno? Ako već ne koristite ClickHouse, možete ga instalirati i najvjerojatnije će sve biti u redu. Ali ako ClickHouse već radi stabilno, onda pripazite na zakrpe i ažuriranja da vidite koje probleme rješavamo.
Kiril Švakov: Želio bih dodati nešto o testnim okruženjima. Svi se jako boje testnih okruženja i iz nekog razloga vjeruju da ako imate jako veliki ClickHouse klaster, onda testno okruženje ne bi trebalo biti ništa manje ili barem deset puta manje. Uopće nije tako.
Mogu vam reći iz vlastitog primjera. Imam projekt, a tu je i ClickHouse. Naše testno okruženje je samo za njega - ovo je mali virtualni stroj u Hetzneru za dvadeset eura, gdje je raspoređeno apsolutno sve. Da bismo to učinili, imamo potpunu automatizaciju u Ansibleu, i stoga, u načelu, nema razlike gdje ići - na hardverske poslužitelje ili samo implementirati u virtualne strojeve.
Što može biti učinjeno? Bilo bi lijepo dati primjer u ClickHouse dokumentaciji o tome kako implementirati mali klaster u vlastitom domu - u Dockeru, u LXC-u, možda izradite Ansible playbook, jer različiti ljudi imaju različite implementacije. Ovo će mnogo toga pojednostaviti. Kada uzmete i implementirate klaster u pet minuta, puno je lakše pokušati nešto smisliti. Ovo je mnogo praktičnije, jer guranje u proizvodnu verziju koju niste testirali je put u nikamo. Ponekad upali, a ponekad ne. I stoga je loše nadati se uspjehu.
Maxim Kotyakov, viši backend inženjer Avito: Dodat ću nešto o testnim okruženjima iz niza problema s kojima se suočavaju velike tvrtke. Imamo cjelovit cluster prihvaćanja ClickHouse; u pogledu podatkovnih shema i postavki, to je točna kopija onoga što je u proizvodnji. Ovaj klaster je raspoređen u prilično zapuštenim spremnicima s minimalnim resursima. Tamo upisujemo određeni postotak proizvodnih podataka, srećom moguće je replicirati tok u Kafki. Tamo je sve sinkronizirano i skalirano - i po kapacitetu i po protoku, te bi se u teoriji, uz ostale jednake stvari, metrički trebao ponašati kao proizvodnja. Sve što je potencijalno eksplozivno prvo se kotrlja na ovo postolje i ostavlja nekoliko dana dok ne bude spremno. Ali prirodno, ovo rješenje je skupo, teško i ima različite troškove podrške.
Aleksej Milovidov: Reći ću vam kakvo je testno okruženje naših prijatelja iz Yandex.Metrice. Jedan klaster je imao 600-tinjak servera, drugi 360, a tu je i treći i nekoliko klastera. Testno okruženje za jedan od njih su jednostavno dva sharda s dvije replike u svakom. Zašto dvije krhotine? Tako da ne budete sami. A trebale bi biti i replike. Samo određeni minimalni iznos koji si možete priuštiti.
Ovo testno okruženje omogućuje vam da provjerite rade li vaši upiti i je li bilo što veće pokvareno. Ali često se javljaju problemi sasvim druge prirode, kada sve radi, ali postoje male promjene u opterećenju.
Dat ću vam primjer. Odlučili smo instalirati novu verziju ClickHousea. Objavljeno je u testnom okruženju, automatizirani testovi su dovršeni u samoj Yandex.Metrici, koji uspoređuju podatke o staroj verziji i novoj, pokrećući cijeli cjevovod. I naravno, zeleni testovi našeg CI-ja. Inače ne bismo ni predlagali ovu verziju.
Sve je u redu. Krećemo u proizvodnju. Dobivam poruku da se opterećenje na grafovima povećalo nekoliko puta. Vraćamo verziju. Gledam grafikon i vidim: opterećenje se zapravo povećalo nekoliko puta tijekom uvođenja, a smanjilo se kad su uvedeni. Zatim smo počeli vraćati verziju. I teret se povećavao na isti način i padao natrag na isti način. Dakle, zaključak je sljedeći: opterećenje se povećalo zbog izgleda, ništa iznenađujuće.
Tada je bilo teško uvjeriti kolege da instaliraju novu verziju. Kažem: “U redu je, otkotrljaj se. Držite fige, sve će uspjeti. Sada se opterećenje na grafovima povećalo, ali sve je u redu. Drži se." Općenito, napravili smo ovo, i to je to - verzija je puštena u proizvodnju. Ali gotovo sa svakim rasporedom pojavljuju se slični problemi.
Kill query bi trebao ubiti upite, ali to ne čini. Zašto?
Došao mi je korisnik, nekakav analitičar, i napravio zahtjev koji je stavio moj ClickHouse klaster. Neki čvor ili cijeli klaster, ovisno o tome na koju je repliku ili shard zahtjev otišao. Vidim da su svi CPU resursi na ovom poslužitelju na polici, sve je crveno. Istovremeno, sam ClickHouse odgovara na zahtjeve. I napišem: "Molim vas, pokažite mi, popis procesa, koji je zahtjev generirao ovo ludilo."
Pronađem ovaj zahtjev i napišem mu kill. I vidim da se ništa ne događa. Server mi je na polici, ClickHouse mi onda daje neke naredbe, pokazuje da je server živ i sve je super. Ali imam degradaciju u svim korisničkim zahtjevima, degradacija počinje zapisima u ClickHouseu i moj kill upit ne radi. Zašto? Mislio sam da bi kill query trebao ubiti upite, ali nije tako.
Sada će biti prilično čudan odgovor. Poanta je da kill query ne ubija upite.
Kill query označava mali okvir pod nazivom "Želim da se ovaj upit ukine." I sam zahtjev gleda ovu zastavicu prilikom obrade svakog bloka. Ako je postavljen, zahtjev prestaje raditi. Ispada da nitko ne ubija zahtjev, on sam mora sve provjeriti i zaustaviti se. I to bi trebalo funkcionirati u svim slučajevima kada je zahtjev u stanju obrade blokova podataka. Obradit će sljedeći blok podataka, provjeriti oznaku i zaustaviti se.
Ovo ne radi u slučajevima kada je zahtjev blokiran na nekoj operaciji. Istina, najvjerojatnije ovo nije vaš slučaj, jer, prema vama, koristi tonu resursa poslužitelja. Moguće je da to ne funkcionira u slučaju vanjskog sortiranja iu nekim drugim detaljima. Ali općenito se to ne bi trebalo dogoditi, to je greška. I jedino što mogu preporučiti je da ažurirate ClickHouse.
Kako izračunati vrijeme odziva pod opterećenjem čitanja?
Postoji tablica koja pohranjuje zbrojeve stavki - razne brojače. Broj linija je približno sto milijuna. Je li moguće računati na predvidljivo vrijeme odziva ako ulijete 1K RPS za 1K stavki?
Sudeći po kontekstu, riječ je o čitalačkom opterećenju, jer s pisanjem nema problema - može se ubaciti i tisuću, pa i sto tisuća, a ponekad i nekoliko milijuna redaka.
Zahtjevi za čitanje vrlo su različiti. U odabiru 1, ClickHouse može izvesti desetak tisuća zahtjeva u sekundi, tako da će čak i zahtjevi za jednim ključem već zahtijevati neke resurse. A takvi će upiti točka biti teži nego u nekim bazama podataka ključ-vrijednost, jer je za svako čitanje potrebno pročitati blok podataka po indeksu. Naš indeks se ne bavi svakim zapisom, već svakim rasponom. Odnosno, morat ćete pročitati cijeli raspon - to je prema zadanim postavkama 8192 retka. I morat ćete dekomprimirati blok podataka sa 64 KB na 1 MB. Obično je za dovršenje takvih ciljanih upita potrebno nekoliko milisekundi. Ali ovo je najjednostavnija opcija.
Pokušajmo jednostavnu aritmetiku. Ako pomnožite nekoliko milisekundi s tisuću, dobit ćete nekoliko sekundi. Kao da je nemoguće pratiti tisuću zahtjeva u sekundi, ali zapravo je moguće, jer imamo nekoliko procesorskih jezgri. Dakle, u principu, ClickHouse ponekad može držati 1000 RPS, ali za kratke zahtjeve, specifično ciljane.
Ako trebate skalirati ClickHouse klaster prema broju jednostavnih zahtjeva, onda preporučujem najjednostavniju stvar - povećajte broj replika i pošaljite zahtjeve nasumičnoj replici. Ako jedna replika drži pet stotina zahtjeva u sekundi, što je sasvim realno, onda će tri replike obraditi tisuću i pol.
Ponekad, naravno, možete konfigurirati ClickHouse za maksimalan broj očitanja točaka. Što je potrebno za ovo? Prvi je smanjiti granularnost indeksa. U ovom slučaju ne treba ga svesti na jedan, već na temelju toga da će broj unosa u indeks biti nekoliko milijuna ili desetaka milijuna po poslužitelju. Ako tablica ima sto milijuna redaka, granularnost se može postaviti na 64.
Možete smanjiti veličinu komprimiranog bloka. Za to postoje postavke min komprimirana veličina bloka, max komprimirana veličina bloka. Mogu se smanjiti, ponovno napuniti podacima i tada će ciljani upiti biti brži. Ipak, ClickHouse nije baza podataka ključ-vrijednost. Veliki broj malih zahtjeva je antiuzorak opterećenja.
Kiril Švakov: Dat ću savjet u slučaju da postoje obični računi. Ovo je prilično standardna situacija kada ClickHouse pohranjuje neku vrstu brojača. Imam korisnika, on je iz te i te zemlje, i neko treće polje, i moram nešto postupno povećavati. Uzmite MySQL, napravite jedinstveni ključ - u MySQL-u je to dupli ključ, a u PostgreSQL-u konflikt - i dodajte znak plus. Ovo će raditi puno bolje.
Kad nemate puno podataka, nema smisla koristiti ClickHouse. Postoje regularne baze podataka i one to dobro rade.
Što mogu podesiti u ClickHouseu tako da više podataka bude u cacheu?
Zamislimo situaciju - poslužitelji imaju 256 GB RAM-a, u dnevnoj rutini ClickHouse zauzima oko 60-80 GB, na vrhuncu - do 130. Što se može omogućiti i prilagoditi tako da više podataka bude u predmemorij i, sukladno tome, ima manje putovanja na disk?
Tipično, predmemorija stranica operativnog sustava to dobro čini. Ako samo otvorite vrh, pogledate tamo predmemorirano ili slobodno - također piše koliko je predmemorirano - tada ćete primijetiti da se sva slobodna memorija koristi za predmemoriju. A kada čitate ove podatke, neće se čitati s diska, već iz RAM-a. U isto vrijeme, mogu reći da se predmemorija učinkovito koristi jer se u predmemoriju spremaju komprimirani podaci.
Međutim, ako želite još više ubrzati neke jednostavne upite, moguće je omogućiti predmemoriju u dekomprimiranim podacima unutar ClickHousea. To se zove nekomprimirana predmemorija. U konfiguracijskoj datoteci config.xml postavite veličinu nekomprimirane predmemorije na vrijednost koja vam je potrebna - preporučujem ne više od polovice slobodnog RAM-a, jer će ostatak ići u predmemoriju stranice.
Osim toga, postoje dvije postavke razine zahtjeva. Prva postavka - koristiti nekomprimiranu predmemoriju - uključuje njegovu upotrebu. Preporuča se uključiti ga za sve zahtjeve, osim za teške, koji mogu čitati sve podatke i ispirati predmemoriju. A druga postavka je nešto poput maksimalnog broja redaka za korištenje predmemorije. Automatski ograničava velike upite tako da zaobilaze predmemoriju.
Kako mogu konfigurirati storage_configuration za pohranu u RAM-u?
U novoj ClickHouse dokumentaciji pročitao sam odjeljak koji se odnosi na . Opis sadrži primjer s brzim SSD-om.
Pitam se kako se ista stvar može konfigurirati s volume hot memorijom. I još jedno pitanje. Kako select radi s ovom organizacijom podataka, hoće li čitati cijeli skup ili samo onaj koji je na disku i jesu li ti podaci komprimirani u memoriji? I kako odjeljak prewhere radi s takvom organizacijom podataka?
Ova postavka utječe na pohranjivanje dijelova podataka, a njihov se format ni na koji način ne mijenja.
Pogledajmo pobliže.
Možete konfigurirati pohranjivanje podataka u RAM-u. Sve što je konfigurirano za disk je njegov put. Stvorite tmpfs particiju koja je montirana na neku stazu u datotečnom sustavu. Ovu stazu odrediš kao stazu za spremanje podataka za najtopliju particiju, tu počnu pristizati i upisivati se dijelovi podataka, sve je u redu.
Ali ne preporučujem da to radite zbog niske pouzdanosti, iako ako imate najmanje tri replike u različitim podatkovnim centrima, onda je to moguće. Ako se nešto dogodi, podaci će biti vraćeni. Zamislimo da je poslužitelj iznenada isključen i ponovno uključen. Pregrada je ponovno montirana, ali tamo nije bilo ničega. Kada se ClickHouse poslužitelj pokrene, vidi da nema tih dijelova, iako bi, prema ZooKeeper metapodacima, trebali biti tamo. Gleda koje ih replike imaju, traži ih i preuzima. Na taj način podaci će biti vraćeni.
U tom smislu, pohranjivanje podataka u RAM nije bitno drugačije od pohranjivanja na disk, jer kada se podaci zapisuju na disk, oni također najprije završavaju u predmemoriju stranica, a kasnije se fizički zapisuju. To ovisi o opciji montiranja datotečnog sustava. Ali za svaki slučaj, reći ću da ClickHouse ne radi fsync prilikom umetanja.
U tom su slučaju podaci u RAM-u pohranjeni u potpuno istom formatu kao i na disku. Upit odabira na isti način odabire dijelove koje je potrebno pročitati, odabire potrebne raspone podataka u dijelovima i čita ih. I prewhere radi potpuno isto, bez obzira jesu li podaci u RAM-u ili na disku.
Do kojeg je broja jedinstvenih vrijednosti niska kardinalnost učinkovita?
Niska kardinalnost je pametno dizajnirana. Sastavlja rječnike podataka, ali oni su lokalni. Kao prvo, postoje različiti rječnici za svaki komad, a kao drugo, čak i unutar jednog komada mogu biti različiti za svaki raspon. Kada broj jedinstvenih vrijednosti dosegne prag - jedan milijun, mislim - rječnik se jednostavno odlaže i stvara se novi.
Odgovor je općenito: za svaki lokalni raspon - recimo, za svaki dan - negdje do milijun jedinstvenih vrijednosti Niska kardinalnost je učinkovita. Nakon toga će postojati jednostavno zamjena, u kojoj će se koristiti mnogo različitih rječnika, a ne samo jedan. Radit će približno isto kao obični stupac niza, možda malo manje učinkovito, ali neće biti ozbiljnog pada performansi.
Koji su najbolji postupci za pretraživanje cijelog teksta u tablici s pet milijardi redaka?
Postoje različiti odgovori. Prvo je reći da ClickHouse nije tražilica punog teksta. Za to postoje posebni sustavi, npr. и . Međutim, sve češće viđam ljude koji govore da se prebacuju s Elasticsearcha na ClickHouse.
Zašto se to događa? Oni to objašnjavaju činjenicom da se Elasticsearch prestaje nositi s opterećenjem na nekim volumenima, počevši od izgradnje indeksa. Indeksi postaju preglomazni, a ako podatke jednostavno prenesete u ClickHouse, ispada da su volumenski pohranjeni nekoliko puta učinkovitije. Pritom, upiti za pretraživanje često nisu bili takvi da je potrebno pronaći neku frazu u cijeloj količini podataka, uzimajući u obzir morfologiju, već sasvim druge. Na primjer, pronađite neki podslijed bajtova u zapisima u zadnjih nekoliko sati.
U ovom slučaju kreirate indeks u ClickHouseu čije će prvo polje biti datum i vrijeme. A najveće ograničenje podataka temeljit će se na datumskom rasponu. Unutar odabranog datumskog raspona, u pravilu, već je moguće izvršiti pretraživanje cijelog teksta, čak i koristeći brute force metodu koristeći like. Like operator u ClickHouseu je najučinkovitiji like operator koji možete pronaći. Ako nađeš nešto bolje, reci mi.
Ali ipak, kao što je potpuno skeniranje. A potpuno skeniranje može biti sporo ne samo na CPU-u, već i na disku. Ako odjednom imate jedan terabajt podataka dnevno, a tražite riječ tijekom dana, tada ćete morati skenirati terabajt. Vjerojatno je na običnim tvrdim diskovima, a na kraju će se učitati na takav način da nećete moći pristupiti ovom poslužitelju putem SSH-a.
U ovom slučaju spreman sam ponuditi još jedan mali trik. Eksperimentalno je - možda upali, a možda i ne. ClickHouse ima indekse punog teksta u obliku trigramskih Bloom filtera. Naši kolege iz Arenadata već su isprobali te indekse i oni često rade točno onako kako je predviđeno.
Da biste ih ispravno koristili, trebali biste dobro razumjeti kako točno rade: što je trigram Bloom filter i kako odabrati njegovu veličinu. Mogu reći da će pomoći za upite o nekim rijetkim izrazima, podstringovima koji se rijetko nalaze u podacima. U ovom slučaju, podrasponi će biti odabrani prema indeksima i bit će pročitano manje podataka.
Nedavno je ClickHouse dodao još naprednije funkcije za pretraživanje cijelog teksta. Ovo je, prvo, traženje hrpe podnizova odjednom u jednom prolazu, uključujući opcije koje su osjetljive na velika i mala slova, neosjetljive na velika i mala slova, s podrškom za UTF-8 ili samo za ASCII. Odaberite najučinkovitiji koji vam je potreban.
Pojavilo se i pretraživanje više regularnih izraza u jednom prolazu. Ne morate pisati X kao jedan podniz ili X kao drugi podniz. Pišete odmah, a sve je učinjeno što je moguće učinkovitije.
Treće, sada postoji približna potraga za regularnim izrazima i približna potraga za podnizovima. Ako je netko krivo napisao riječ, tražit će se maksimalno podudaranje.
Koji je najbolji način organiziranja pristupa ClickHouseu za veliki broj korisnika?
Recite nam kako najbolje organizirati pristup za veliki broj potrošača i analitičara. Kako formirati red čekanja, odrediti prioritet maksimalnih istodobnih upita i s kojim alatima?
Ako je klaster dovoljno velik, onda bi dobro rješenje bilo podizanje još dva poslužitelja, koji će postati ulazna točka za analitičare. Odnosno, nemojte dopustiti analitičarima pristup određenim shardovima u klasteru, već jednostavno kreirajte dva prazna poslužitelja, bez podataka, i konfigurirajte prava pristupa na njima. U tom se slučaju korisničke postavke za distribuirane zahtjeve prenose na udaljene poslužitelje. Odnosno, konfigurirate sve na ta dva poslužitelja, a postavke imaju učinak na cijeli klaster.
U principu, ovi poslužitelji nemaju podataka, ali je količina RAM-a na njima vrlo bitna za izvršavanje zahtjeva. Disk se također može koristiti za privremene podatke ako je omogućeno vanjsko prikupljanje ili vanjsko sortiranje.
Važno je pogledati postavke koje su povezane sa svim mogućim ograničenjima. Ako sada odem u klaster Yandex.Metrica kao analitičar i postavim zahtjev odaberite broj iz pogodaka, tada će mi se odmah dati izuzetak da ne mogu izvršiti zahtjev. Maksimalan broj redaka koje smijem skenirati je sto milijardi, a ukupno ih ima pedeset trilijuna u jednoj tablici na klasteru. Ovo je prvo ograničenje.
Recimo da uklonim ograničenje redaka i ponovno pokrenem upit. Tada ću vidjeti sljedeću iznimku - postavka omogućena indeks sile po datumu. Ne mogu dovršiti upit ako nisam naveo datumski raspon. Ne morate se oslanjati na analitičare koji će to ručno odrediti. Tipičan slučaj je kada je datumski raspon napisan gdje je datum događaja između tjedana. A onda su jednostavno naveli zagradu na krivom mjestu, a umjesto i ispalo je ili - ili podudaranje URL-a. Ako nema ograničenja, pretražit će URL stupac i samo uzalud potrošiti gomilu resursa.
Uz to, ClickHouse ima dvije postavke prioriteta. Nažalost, vrlo su primitivni. Jedan se jednostavno zove prioritet. Ako je prioritet ≠ 0 i izvršavaju se zahtjevi s nekim prioritetom, ali se izvršava zahtjev s vrijednošću prioriteta manjom od, što znači veći prioritet, tada se zahtjev s vrijednošću prioriteta većim, što znači niži prioritet , jednostavno je obustavljen i tijekom tog vremena uopće neće raditi.
Ovo je vrlo gruba postavka i nije prikladna za slučajeve kada klaster ima konstantno opterećenje. Ali ako imate kratke, burne zahtjeve koji su važni, a klaster je uglavnom u stanju mirovanja, ova je postavka prikladna.
Poziva se sljedeća postavka prioriteta OS prioritet niti. Jednostavno postavlja dobru vrijednost za sve niti izvršavanja zahtjeva za Linux planer. Radi tako-tako, ali ipak radi. Ako postavite minimalnu lijepu vrijednost - ona je najveće vrijednosti, a time i najnižeg prioriteta - i postavite -19 za zahtjeve s visokim prioritetom, tada će CPU potrošiti zahtjeve niskog prioriteta oko četiri puta manje od onih visokog prioriteta.
Također morate konfigurirati maksimalno vrijeme izvršenja zahtjeva - recimo, pet minuta. Minimalna brzina izvršavanja upita je najbolja stvar. Ova postavka postoji već duže vrijeme i potrebna je ne samo kako bi se potvrdilo da ClickHouse ne usporava, već da bi se to prisililo.
Zamislite, vi konfigurirate: ako neki upit obrađuje manje od milijun redaka u sekundi, to ne možete učiniti. Ovo sramoti naš dobar glas, našu dobru bazu podataka. Zabranimo ovo. Zapravo postoje dvije postavke. Jedan se zove min brzina izvršenja - u redovima po sekundi, a sekunda se naziva timeout prije provjere min. brzine izvođenja - petnaest sekundi prema zadanim postavkama. To jest, petnaest sekundi je moguće, a zatim, ako je sporo, onda samo izbacite iznimku i odbacite zahtjev.
Također morate postaviti kvote. ClickHouse ima ugrađenu značajku kvote koja broji potrošnju resursa. Ali, nažalost, ne hardverske resurse kao što su CPU, diskovi, već one logičke - broj obrađenih zahtjeva, pročitanih linija i bajtova. I možete konfigurirati, na primjer, maksimalno stotinu zahtjeva unutar pet minuta i tisuću zahtjeva po satu.
Zašto je to važno? Budući da će se neki analitički upiti izvoditi ručno izravno iz ClickHouse klijenta. I sve će biti dobro. Ali ako imate napredne analitičare u svojoj tvrtki, oni će napisati skriptu, au skripti može biti greška. A ova će pogreška uzrokovati izvršavanje zahtjeva u beskonačnoj petlji. To je ono od čega se trebamo zaštititi.
Je li moguće rezultate jednog upita dati desetorici klijenata?
Imamo nekoliko korisnika koji vole doći s vrlo velikim zahtjevima u isto vrijeme. Zahtjev je velik i, u principu, brzo se izvršava, ali zbog činjenice da postoji mnogo takvih zahtjeva u isto vrijeme, postaje vrlo bolno. Je li moguće isti zahtjev koji je stigao deset puta zaredom izvršiti jednom i dati rezultat deset klijenata?
Problem je što nemamo rezultate predmemorije ili predmemorije međupodataka. Postoji predmemorija stranica operativnog sustava, koja će vas spriječiti da ponovo čitate podatke s diska, ali, nažalost, podaci će i dalje biti dekomprimirani, deserializirani i ponovno obrađeni.
Želio bih to nekako izbjeći, bilo predmemoriranjem međupodataka, bilo postavljanjem sličnih upita u neku vrstu reda i dodavanjem predmemorije rezultata. Trenutačno imamo jedan zahtjev za povlačenjem u razvoju koji dodaje predmemoriju zahtjeva, ali samo za podupiti u odjeljcima in i join - to jest, rješenje je nepotpuno.
No, i mi se suočavamo s takvom situacijom. Posebno kanonski primjer su paginirani upiti. Postoji izvještaj, ima nekoliko stranica, i postoji zahtjev za limit 10. Onda isto, ali limit 10,10. Zatim još jedna sljedeća stranica. I postavlja se pitanje zašto svaki put sve to brojimo? Ali sada nema rješenja, i nema načina da se to izbjegne.
Postoji alternativno rješenje koje se nalazi kao prikolica uz ClickHouse - .
Kiril Švakov: ClickHouse Proxy ima ugrađeni limitator brzine i ugrađenu predmemoriju rezultata. Tu je napravljeno puno postavki jer se rješavao sličan problem. Proxy vam omogućuje da ograničite zahtjeve stavljajući ih u red čekanja i konfigurirate koliko dugo živi predmemorija zahtjeva. Ako su zahtjevi doista isti, Proxy će ih poslati više puta, ali će ClickHouseu otići samo jednom.
Nginx također ima predmemoriju u besplatnoj verziji, i to će također raditi. Nginx čak ima postavke da će, ako zahtjevi stignu u isto vrijeme, usporiti ostale dok se jedan ne završi. Ali u ClickHouse Proxyju postavljanje je mnogo bolje. Napravljen je posebno za ClickHouse, posebno za ove zahtjeve, pa je prikladniji. Pa, lako se instalira.
Što je s asinkronim operacijama i materijaliziranim pogledima?
Postoji problem što su operacije s motorom za ponavljanje asinkrone - prvo se podaci zapisuju, a zatim kolabiraju. Ako ispod znaka živi materijalizirana ploča s nekim agregatima, na nju će biti upisani duplikati. A ako nema složene logike, tada će se podaci duplicirati. Što možete učiniti u vezi s tim?
Postoji očito rješenje - implementirati okidač na određenu klasu matviewa tijekom operacije asinkronog kolapsa. Postoje li srebrni meci ili planovi za implementaciju slične funkcionalnosti?
Vrijedno je razumjeti kako radi deduplikacija. Ono što ću vam sada reći nije relevantno za pitanje, ali za svaki slučaj vrijedi zapamtiti.
Prilikom umetanja u repliciranu tablicu dolazi do deduplikacije cijelih umetnutih blokova. Ako ponovno umetnete isti blok koji sadrži isti broj istih redaka istim redoslijedom, podaci se dedupliciraju. Dobit ćete "Ok" kao odgovor na umetanje, ali zapravo će biti zapisan jedan paket podataka koji se neće duplicirati.
Ovo je neophodno za sigurnost. Ako tijekom umetanja dobijete "Ok", znači da su vaši podaci umetnuti. Ako primite pogrešku od ClickHouse, to znači da nisu umetnuti i morate ponoviti umetanje. Ali ako se veza prekine tijekom umetanja, tada ne znate jesu li podaci umetnuti ili ne. Jedina opcija je ponovno ponoviti umetanje. Ako su podaci stvarno umetnuti, a vi ste ih ponovno umetnuli, postoji deduplikacija blokova. Ovo je potrebno kako bi se izbjegli duplikati.
A također je važno kako radi za materijalizirane poglede. Ako su podaci deduplicirani prilikom umetanja u glavnu tablicu, tada neće ići ni u materijalizirani prikaz.
Sada o pitanju. Vaša situacija je kompliciranija jer snimate duplikate pojedinačnih redaka. Odnosno, ne duplicira se cijeli paket, već određene linije, a one se skupljaju u pozadini. Doista, podaci će se sažeti u glavnoj tablici, ali nesažeti podaci će ići u materijalizirani prikaz, a tijekom spajanja ništa se neće dogoditi materijaliziranim pogledima. Jer materijalizirani pogled nije ništa drugo nego okidač za umetanje. Tijekom drugih operacija ništa mu se dodatno ne događa.
I ne mogu te usrećiti ovdje. Samo trebate potražiti konkretno rješenje za ovaj slučaj. Na primjer, je li to moguće ponovno reproducirati u materijaliziranom prikazu i metoda deduplikacije bi mogla funkcionirati na isti način. Ali, nažalost, ne uvijek. Ako se agregira, neće raditi.
Kiril Švakov: Nekad smo imali i konstrukciju štaka. Došlo je do problema što postoje impresije oglašavanja, a postoje neki podaci koje možemo prikazati u stvarnom vremenu - to su samo impresije. Rijetko se dupliciraju, ali ako se to dogodi, svejedno ćemo ih kasnije sažeti. A bilo je stvari koje se nisu mogle duplirati – klikovi i cijela ova priča. Ali također sam ih htio pokazati gotovo odmah.
Kako su napravljeni materijalizirani pogledi? Bilo je pogleda u kojima se pisalo izravno - pisalo se u neobrađene podatke i pisalo u poglede. Tu u nekom trenutku podaci nisu baš točni, dupliciraju se i tako dalje. A tu je i drugi dio tablice, gdje izgledaju potpuno isto kao materijalizirani pogledi, to jest, potpuno su identične strukture. S vremena na vrijeme preračunamo podatke, prebrojimo podatke bez duplikata, zapišemo u te tablice.
Prošli smo kroz API - ovo neće raditi u ClickHouseu ručno. I API izgleda: kada imam datum zadnjeg dodavanja u tablicu, gdje je zajamčeno da su točni podaci već izračunati, i šalje zahtjev jednoj tablici i drugoj tablici. Iz jedne zahtjev bira do određenog vremena, a iz druge dobiva ono što još nije izračunato. I radi, ali ne samo kroz ClickHouse.
Ako imate neku vrstu API-ja - za analitičare, za korisnike - onda je to u principu opcija. Ti uvijek brojiš, uvijek brojiš. To se može učiniti jednom dnevno ili u neko drugo vrijeme. Sami birate raspon koji vam nije potreban i nije kritičan.
ClickHouse ima puno dnevnika. Kako mogu na prvi pogled vidjeti sve što se događa s poslužiteljem?
ClickHouse ima vrlo velik broj različitih logova, a taj broj se povećava. U novim verzijama neki od njih su čak uključeni prema zadanim postavkama; u starijim verzijama moraju biti uključeni prilikom ažuriranja. No, takvih je sve više. Naposljetku, želio bih vidjeti što se sada događa s mojim poslužiteljem, možda na nekoj vrsti nadzorne ploče sa sažetkom.
Imate li ClickHouse tim ili timove vaših prijatelja koji podržavaju neke funkcionalnosti gotovih nadzornih ploča koje bi prikazivale te zapisnike kao gotov proizvod? U konačnici, samo gledanje zapisa u ClickHouseu je super. Ali bilo bi jako cool da je već pripremljen u obliku nadzorne ploče. Dobio bih udarac od toga.
Postoje nadzorne ploče, iako nisu standardizirane. U našoj tvrtki ClickHouse koristi 60-ak timova, a najčudnije je što mnogi od njih imaju nadzorne ploče koje su sami sebi napravili i to malo drugačije. Neki timovi koriste internu instalaciju Yandex.Clouda. Postoje neka gotova izvješća, ali ne sva potrebna. Drugi imaju svoje.
Kolege iz Metrica imaju svoj dashboard u Grafani, a ja svoj za njihov klaster. Gledam stvari kao što je pogodak predmemorije za serifnu predmemoriju. A još teže je što koristimo različite alate. Napravio sam svoju nadzornu ploču koristeći vrlo stari alat koji se zove Graphite-web. Potpuno je ružan. I još uvijek ga koristim ovako, iako bi Grafana vjerojatno bila zgodnija i ljepša.
Osnovna stvar u nadzornim pločama je ista. Ovo su sistemske metrike za klaster: CPU, memorija, disk, mreža. Ostalo - broj istodobnih zahtjeva, broj istodobnih spajanja, broj zahtjeva u sekundi, maksimalan broj dijelova za particije tablice MergeTree, kašnjenje replikacije, veličina reda čekanja replikacije, broj umetnutih redaka u sekundi, broj umetnutih blokova u sekundi. Ovo je sve što se ne dobiva iz dnevnika, već iz metrike.
Vladimir Kolobajev: Alexey, želio bih to malo ispraviti. Tu je Grafana. Grafana ima izvor podataka, a to je ClickHouse. Odnosno, mogu slati zahtjeve iz Grafane direktno ClickHouseu. ClickHouse ima stol s cjepanicama, isti je za sve. Kao rezultat toga, želim pristupiti ovoj tablici dnevnika u Grafani i vidjeti zahtjeve koje postavlja moj poslužitelj. Bilo bi sjajno imati ovakvu kontrolnu ploču.
Sam sam ga vozio biciklom. Ali imam pitanje - ako je sve standardizirano, a Grafana koriste svi, zašto Yandex nema takvu službenu nadzornu ploču?
Kiril Švakov: Zapravo, izvor podataka koji ide u ClickHouse sada podržava Altinity. I samo želim dati vektor gdje kopati i koga gurati. Možete pitati njih, jer Yandex ipak radi ClickHouse, a ne priču oko njega. Altinity je glavna tvrtka koja trenutno promovira ClickHouse. Neće ga napustiti, nego će ga podržati. Jer, u principu, da biste uploadali dashboard na web stranicu Grafana, trebate se samo registrirati i uploadati - nema posebnih problema.
Aleksej Milovidov: Tijekom prošle godine ClickHouse je dodao mnoge mogućnosti profiliranja upita. Postoje metrike za svaki zahtjev o upotrebi resursa. Nedavno smo dodali profiler upita još niže razine kako bismo vidjeli gdje upit troši svaku milisekundu. Ali da bih koristio ovu funkcionalnost, moram otvoriti klijenta konzole i upisati zahtjev, što uvijek zaboravim. Negdje sam ga spremio i stalno zaboravljam gdje točno.
Volio bih da postoji alat koji samo kaže, ovdje su vaši teški upiti, grupirani po klasi upita. Pritisnuo sam jednu, a oni bi mi rekli da je zato teška. Sada tog rješenja nema. I stvarno je dosta čudno da kad me ljudi pitaju: “Reci mi, ima li gotovih nadzornih ploča za Grafanu?”, ja kažem: “Idi na stranicu Grafana, postoji zajednica “Nadzorne ploče”, a postoji nadzorna ploča. od Dimke, postoji nadzorna ploča od Kostyana. Ne znam što je to, nisam ga osobno koristio.”
Kako utjecati na spajanja da se server ne sruši na OOM?
Imam tablicu, postoji samo jedna particija u tablici, to je ReplacingMergeTree. Već četiri godine u njega upisujem podatke. Morao sam to promijeniti i izbrisati neke podatke.
Učinio sam to i tijekom obrade ovog zahtjeva potrošena je sva memorija na svim poslužiteljima u klasteru i svi poslužitelji u klasteru otišli su u OOM. Zatim su svi zajedno ustali, počeli spajati ovu istu operaciju, ovaj blok podataka, i ponovno upali u OOM. Zatim su opet ustali i opet pali. I ova stvar nije stala.
Onda se pokazalo da je to zapravo bug koji su dečki popravili. Ovo je jako cool, hvala vam puno. Ali ostao je talog. I sada, kada razmišljam o tome da napravim neku vrstu spajanja u tablici, imam pitanje - zašto ne mogu nekako utjecati na ta spajanja? Na primjer, ograničite ih potrebnom količinom RAM-a ili, u načelu, količinom koja će obraditi ovu određenu tablicu.
Imam tablicu koja se zove "Metrika", obradite je za mene u dvije niti. Nema potrebe stvarati deset ili pet spajanja paralelno, učinite to u dva. Mislim da imam dovoljno memorije za dva, ali možda neće biti dovoljno za obraditi deset. Zašto strah ostaje? Zato što tablica raste i jednog dana ću se suočiti sa situacijom koja u principu više nije zbog buga, već zato što će se podaci mijenjati u tolikoj količini da jednostavno neću imati dovoljno memorije na poslužitelj. A onda će se poslužitelj srušiti na OOM prilikom spajanja. Štoviše, mogu poništiti mutaciju, ali Merji više nema.
Znate, prilikom spajanja server neće pasti u OOM, jer se prilikom spajanja količina RAM-a koristi samo za jedan mali raspon podataka. Dakle, sve će biti u redu bez obzira na količinu podataka.
Vladimir Kolobajev: Fino. Ovdje je trenutak takav da sam, nakon što je greška ispravljena, preuzeo novu verziju za sebe, a na drugoj tablici, manjoj, gdje ima mnogo particija, izvršio sam sličnu operaciju. A tijekom spajanja, na poslužitelju je spaljeno oko 100 GB RAM-a. Imao sam 150 zauzetih, 100 pojedenih i ostalo 50 GB prozora, tako da nisam upao u OOM.
Što me trenutno štiti od pada u OOM ako stvarno troši 100 GB RAM-a? Što učiniti ako iznenada ponestane RAM-a na spajanjima?
Aleksej Milovidov: Postoji takav problem da potrošnja RAM-a posebno za spajanje nije ograničena. A drugi problem je da ako je dodijeljena neka vrsta spajanja, onda se mora izvršiti jer je zabilježeno u dnevniku replikacije. Dnevnik replikacije su radnje koje su potrebne da se replika dovede u dosljedno stanje. Ako ne izvršite ručne manipulacije koje će vratiti ovaj dnevnik replikacije, spajanje će se morati izvesti na ovaj ili onaj način.
Naravno, ne bi bilo suvišno imati ograničenje RAM-a koje "za svaki slučaj" štiti od OOM-a. To neće pomoći da se spajanje dovrši, ono će započeti iznova, dosegnuti neki prag, baciti iznimku, a zatim započeti iznova - ništa dobro neće proizaći iz ovoga. No, načelno, bilo bi korisno uvesti to ograničenje.
Kako će se razvijati Golang driver za ClickHouse?
Golang driver, koji je napisao Kirill Shvakov, sada je službeno podržan od strane ClickHouse tima. On , on je sada velik i pravi.
Mala napomena. Postoji divno i voljeno spremište normalnih oblika beskonačnog reda - ovo je Vertica. Također imaju svoj službeni upravljački program za python, koji podržavaju Vertica programeri. Nekoliko puta se dogodilo da su se verzije za pohranu i verzije upravljačkog programa prilično dramatično razlikovale, a upravljački program je u nekom trenutku prestao raditi. I druga točka. Podršku za ovaj službeni upravljački program, čini mi se, provodi sustav "bradavica" - napišete im problem i on zauvijek visi.
Imam dva pitanja. Sada je Kirillov Golang upravljački program gotovo zadani način komunikacije iz Golanga s ClickHouseom. Osim ako netko ipak komunicira preko http sučelja jer mu se tako sviđa. Kako će se odvijati razvoj ovog drajvera? Hoće li se sinkronizirati s bilo kojim prijelomnim promjenama u samom spremištu? I koja je procedura za razmatranje pitanja?
Kiril Švakov: Prvi je kako je sve birokratski organizirano. O ovoj točki se nije raspravljalo, tako da nemam što odgovoriti.
Da bismo odgovorili na pitanje o problemu, trebamo malo povijesti upravljačkog programa. Radio sam za tvrtku koja je imala puno podataka. Bio je to reklamni spinner s ogromnim brojem događaja koje je trebalo negdje pohraniti. I u jednom trenutku pojavio se ClickHouse. Napunili smo ga podacima i isprva je sve bilo u redu, no onda se ClickHouse srušio. U tom trenutku smo zaključili da nam ne treba.
Godinu dana kasnije, vratili smo se ideji da koristimo ClickHouse i morali smo tamo nekako upisati podatke. Uvodna poruka je bila sljedeća: hardver je jako slab, resursa je malo. Ali mi smo oduvijek radili na ovaj način, pa smo gledali prema nativnom protokolu.
Budući da smo radili u Go-u, bilo je jasno da nam treba Go vozač. Radio sam to gotovo puno radno vrijeme - to je bio moj radni zadatak. Doveli smo to do određene točke i u principu nitko nije pretpostavljao da će to koristiti bilo tko osim nas. Zatim je došao CloudFlare s točno istim problemom i neko smo vrijeme s njima radili vrlo glatko jer su imali iste zadatke. Štoviše, to smo učinili i sami u ClickHouseu i u vozaču.
U jednom sam trenutku jednostavno prestao s tim, jer se moja aktivnost u ClickHouseu i poslu malo promijenila. Stoga pitanja nisu zatvorena. Povremeno se ljudi koji nešto trebaju sami posvete spremištu. Zatim pogledam zahtjev za povlačenjem i ponekad čak i sam nešto uredim, ali to se rijetko događa.
Želim se vratiti vozaču. Prije nekoliko godina, kada je cijela stvar počela, ClickHouse je također bio drugačiji i s drugačijim mogućnostima. Sada znamo kako preraditi upravljački program tako da dobro radi. Ako se to dogodi, onda će verzija 2 u svakom slučaju biti nekompatibilna zbog nagomilanih štaka.
Ne znam kako organizirati ovu stvar. Ni sama nemam puno vremena. Ako neki ljudi završe vozača, mogu im pomoći i reći im što da rade. Ali o aktivnom sudjelovanju Yandexa u razvoju projekta još se nije razgovaralo.
Aleksej Milovidov: Zapravo, oko tih vozača još nema birokracije. Jedino što se dostavljaju službenoj organizaciji, odnosno ovaj je upravljački program prepoznat kao službeno zadano rješenje za Go. Ima još nekih drajvera, ali oni dolaze zasebno.
Nemamo nikakav interni razvoj za te vozače. Pitanje je možemo li zaposliti pojedinca, ne za ovog vozača, nego za razvoj svih vozača zajednice, ili možemo naći nekoga sa strane.
Vanjski rječnik se ne učitava nakon ponovnog pokretanja s omogućenom postavkom lazy_load. Što uraditi?
Omogućena nam je postavka lazy_load i nakon ponovnog pokretanja poslužitelja, rječnik se ne učitava sam od sebe. Pokreće se tek nakon što korisnik pristupi ovom rječniku. I prvi put kad mu pristupim, daje grešku. Je li moguće nekako automatski učitati rječnike pomoću ClickHousea ili morate uvijek sami kontrolirati njihovu spremnost kako korisnici ne bi primali pogreške?
Možda imamo staru verziju ClickHousea, pa se rječnik nije automatski učitao. Može li to biti slučaj?
Prvo, rječnici se mogu prisilno učitati pomoću upita ponovno učitavanje sustava rječnika. Drugo, što se tiče pogreške - ako je rječnik već učitan, onda će upiti raditi na temelju podataka koji su učitani. Ako rječnik još nije učitan, učitat će se izravno tijekom zahtjeva.
Ovo nije baš zgodno za teške rječnike. Na primjer, trebate povući milijun redaka iz MySQL-a. Netko napravi jednostavan odabir, ali ovaj odabir će čekati istih milijun redaka. Ovdje postoje dva rješenja. Prvi je da isključite lazy_load. Drugo, kada poslužitelj radi, prije nego što ga opteretite, učinite ponovno učitavanje sustava rječnik ili samo napravite upit koji koristi rječnik. Zatim će se učitati rječnik. Morate kontrolirati dostupnost rječnika s uključenom postavkom lazy_load jer ih ClickHouse ne učitava automatski.
Odgovor na posljednje pitanje je ili je verzija stara ili je treba otkloniti pogreške.
Što učiniti s činjenicom da rječnici ponovnog učitavanja sustava ne učitavaju nijedan od mnogih rječnika ako se barem jedan od njih sruši s pogreškom?
Postoji još jedno pitanje o rječnicima ponovnog učitavanja sustava. Imamo dva rječnika - jedan nije učitan, drugi je učitan. U ovom slučaju Rječnici ponovnog učitavanja sustava ne učitavaju nijedan rječnik, a vi morate učitati točku po točku određenog po imenu pomoću rječnika ponovnog učitavanja sustava. Je li i to povezano s verzijom ClickHouse?
Želim te usrećiti. Ovo se ponašanje mijenjalo. To znači da ako ažurirate ClickHouse, on će se također promijeniti. Ako niste zadovoljni svojim trenutnim ponašanjem ponovno učitavanje sustava rječnika, ažurirajte i nadajmo se da će se promijeniti na bolje.
Postoji li način da konfigurirate detalje u konfiguraciji ClickHouse, ali da ih ne prikažete u slučaju pogrešaka?
Sljedeće pitanje odnosi se na pogreške vezane uz rječnik, odnosno detalje. Naveli smo detalje o povezivanju u ClickHouse konfiguraciji za rječnik, a ako postoji pogreška, dobivamo te detalje i lozinku kao odgovor.
Riješili smo ovu pogrešku dodavanjem pojedinosti u konfiguraciju ODBC upravljačkog programa. Postoji li neki način da konfigurirate pojedinosti u konfiguraciji ClickHouse, ali da ne prikažete te pojedinosti u slučaju pogrešaka?
Pravo rješenje ovdje je navesti ove vjerodajnice u odbc.ini, au samom ClickHouseu navesti samo ODBC naziv izvora podataka. Ovo se neće dogoditi za druge izvore rječnika - ni za rječnik s MySQL-om, ni za ostale, ne biste trebali vidjeti lozinku kada primite poruku o pogrešci. Za ODBC ću također pogledati - ako postoji, samo ga trebate ukloniti.
Bonus: pozadine za Zoom sa skupova
Klikom na sliku otvaraju se bonus pozadine sa druženja za najupornije čitatelje. Gasimo požar zajedno s maskotama Avito tehnologije, savjetujemo se s kolegama iz sobe administratora sustava ili staromodnog informatičkog kluba i svakodnevno održavamo sastanke ispod mosta u pozadini grafita.
Izvor: www.habr.com