Avito inženjeri su se u aprilu okupili na onlajn skupovima sa Aleksejem Milovidovim, glavnim programerom ClickHouse, i Kirilom Švakovim, Golang programerom iz Integrosa. Razgovarali smo o tome kako koristimo sistem za upravljanje bazom podataka i sa kojim se poteškoćama suočavamo.
Na osnovu sastanka, sastavili smo članak sa odgovorima stručnjaka na naša i pitanja publike o sigurnosnoj kopiji, ponovnom dijeljenju podataka, vanjskim rječnicima, Golang drajveru i ažuriranjima verzije ClickHouse. Može biti korisno za programere koji već aktivno rade sa Yandex DBMS-om i zainteresirani su za njegovu sadašnjost i budućnost. Odgovori Alekseja Milovidova podrazumevano, osim ako nije drugačije naznačeno.
Pazite, ispod reza je puno teksta. Nadamo se da će vam sadržaj sa pitanjima pomoći da se snađete.
Sadržaj
Ukoliko ne želite da čitate tekst, možete pogledati snimak skupova . Vremenske oznake su u prvom komentaru ispod videa.
ClickHouse se stalno ažurira, ali naši podaci nisu. Šta učiniti s tim?
ClickHouse se stalno ažurira, a naši podaci koji su obrađeni optimizacijom finala se ne ažuriraju i nalaze se u sigurnosnoj kopiji.
Pretpostavimo da smo imali neku vrstu problema i da su podaci izgubljeni. Odlučili smo se za restauraciju i pokazalo se da se stare particije koje su pohranjene na backup serverima jako razlikuju od verzije ClickHousea koja se trenutno koristi. Šta učiniti u takvoj situaciji i da li je to moguće?
Nemoguća je situacija u kojoj ste vratili podatke iz sigurnosne kopije u starom formatu, ali na novoj verziji nisu povezani. Osiguravamo da format podataka u ClickHouse uvijek ostane kompatibilan unatrag. Ovo je mnogo važnije od povratne kompatibilnosti u funkcionalnosti ako se promijenilo ponašanje neke rijetko korištene funkcije. Podatke koji su pohranjeni na disku, nova verzija ClickHouse uvijek bi trebala moći čitati. Ovo je zakon.
Koje su trenutne najbolje prakse za sigurnosno kopiranje podataka iz ClickHouse-a?
Kako napraviti backup, s obzirom da imamo optimizirane završne operacije, ogromnu bazu terabajta i podatke koji se ažuriraju, recimo, zadnja tri dana, a onda im se ne dešavaju nikakve procedure?
Možemo sastaviti naše vlastito rješenje i napisati na glavi: prikupiti ove sigurnosne kopije na takav i takav način. Možda ne morate ništa da štirate, a bicikl je izmišljen davno?
Počnimo s najboljim praksama. Moje kolege uvijek savjetuju na pitanja o sigurnosnoj kopiji da ih podsjete na uslugu Yandex.Cloud, gdje je ovaj zadatak već riješen. Zato ga iskoristite ako je moguće.
Ne postoji kompletno rješenje, sto posto ugrađeno u ClickHouse, za sigurnosne kopije. Postoje neke praznine koje možete koristiti. Da biste dobili kompletno rješenje, morat ćete ili malo petljati ručno ili napraviti omote u obliku skripti.
Počeću s najjednostavnijim rješenjima i završiti s najsofisticiranijim, ovisno o količini podataka i veličini klastera. Što je klaster veća, rješenje postaje teže.
Ako tabela podataka zauzima samo nekoliko gigabajta, sigurnosna kopija se može napraviti na sljedeći način:
- Sačuvajte definiciju tabela, tj. metapodataka − prikaži kreiraj tabelu.
- Napravite dump koristeći ClickHouse klijent − izabrati * sa stola da fajl. Podrazumevano ćete dobiti datoteku u formatu TabSeparated. Ako želite biti efikasniji, možete koristiti izvorni format.
Ako je količina podataka veća, sigurnosna kopija će trajati više vremena i puno prostora. Ovo se zove logička rezervna kopija, nije vezana za ClickHouse format podataka. Ako jeste, onda u malom slučaju možete napraviti rezervnu kopiju i otpremiti je na MySQL radi oporavka.
Za naprednije slučajeve, ClickHouse ima ugrađenu mogućnost kreiranja snimka particija u lokalnom sistemu datoteka. Ova funkcija je dostupna na zahtjev. izmijeniti particiju zamrzavanja tablice. Ili jednostavno promijeniti zamrzavanje stola je snimak cijele tabele.
Snimak će biti kreiran konzistentno za jednu tabelu na jednom šardu, odnosno na ovaj način je nemoguće kreirati konzistentan snimak čitavog klastera. Ali za većinu zadataka nema takve potrebe, a dovoljno je izvršiti zahtjev na svakom šardu i dobiti dosljedan snimak. Kreiran je u obliku tvrdih veza i stoga ne zauzima dodatni prostor. Zatim kopirate ovaj snimak na server za rezervne kopije ili u skladište koje koristite za pravljenje rezervnih kopija.
Obnavljanje takve sigurnosne kopije je prilično jednostavno. Prvo kreirate tabele prema postojećim definicijama tabele. Zatim kopirajte spremljene snimke particije u "Directory-Detached" za ove tablice i pokrenite upit pričvrstite particiju. Ovo rješenje je sasvim prikladno za najozbiljnije količine podataka.
Ponekad vam treba nešto još hladnije - u slučajevima kada imate desetine ili čak stotine terabajta na svakom serveru i stotine servera. Ovdje postoji rješenje koje sam špijunirao od kolega iz Yandex.Metrica. Ne bih ga preporučio svima - pročitajte ga i odlučite sami da li vam odgovara ili ne.
Prvo morate kreirati nekoliko servera sa velikim diskovnim policama. Zatim podignite nekoliko ClickHouse servera na ovim serverima i konfigurišite ih tako da rade kao druga replika za iste delove. Zatim koristite sistem datoteka na ovim serverima ili neki alat koji vam omogućava da kreirate snimke. Ovdje postoje dvije opcije. Prva opcija su LVM snimci, druga opcija je ZFS na Linuxu.
Nakon toga, svaki dan trebate napraviti snimku, ona će ležati i zauzeti malo prostora. Naravno, ako se podaci promijene, s vremenom će se količina prostora povećati. Možete dobiti ovaj snimak u bilo kojem trenutku i vratiti podatke, tako čudna odluka. Osim toga, još uvijek morate ograničiti ove replike u konfiguraciji kako ne bi pokušavali postati lideri.
Hoće li biti moguće organizirati kontrolirani zaostatak replika u oknima?
Ove godine planirate da napravite okna u ClickHouse-u. Hoće li se u njima moći organizirati kontrolirani zaostatak replika? Htjeli bismo ga koristiti da se zaštitimo od negativnih scenarija promjenama i drugim promjenama.
Da li je moguće napraviti neku vrstu povrata za izmjene? Na primjer, u postojećem oknu, uzmite i recite da do ovog trenutka primjenite promjene, a od ovog trenutka prestanite primjenjivati promjene?
Ako je komanda došla u naš klaster i pokvarila ga, onda imamo uslovnu repliku sa sat vremena kašnjenja, gdje možemo reći da je koristimo trenutno, ali nećemo primijeniti promjene u njoj zadnjih deset minuta?
Za početak, o kontroliranom zaostatku replika. Postojao je takav zahtjev korisnika, a mi smo napravili izdanje na Githubu sa zahtjevom: “Ako nekome treba, lajkuj, srce.” Niko se nije kladio i pitanje je zatvoreno. Međutim, ovu priliku već možete dobiti postavljanjem ClickHouse. Istina, samo počevši od verzije 20.3.
ClickHouse konstantno spaja podatke u pozadini - spajanje. Kada se izvrši spajanje, neki skup dijelova podataka zamjenjuje se većim dijelom. U isto vrijeme, dijelovi podataka koji su bili prije i dalje ostaju na disku neko vrijeme.
Prvo, oni se i dalje pohranjuju sve dok postoje odabrani upiti koji ih koriste, kako bi se osigurao neblokirajući rad. Odabrani zahtjevi se tiho čitaju iz starih dijelova.
Drugo, postoji i vremenski prag - stari podaci leže na disku osam minuta. Ovih osam minuta može se prilagoditi i pretvoriti u čak jedan dan. To će koštati prostor na disku: ovisno o protoku podataka, ispostavit će se da će se tijekom posljednjeg dana podaci ne samo udvostručiti, već mogu postati i pet puta više. Ali u slučaju ozbiljnog problema, možete zaustaviti ClickHouse server i riješiti sve.
Sada je pitanje kako to štiti od promjena. Ovdje vrijedi pogledati dublje, jer je u starijim verzijama ClickHouse-a alter funkcionirao na takav način da je jednostavno direktno mijenjao dijelove. Postoji dio podataka sa nekim fajlovima, a mi radimo npr. izmijeniti ispusti kolonu. Zatim se ovaj stupac fizički uklanja iz svih dijelova.
Ali od verzije 20.3, alter mehanizam je potpuno promijenjen, i sada su dijelovi podataka uvijek nepromjenjivi. Oni se uopšte ne menjaju – izmene sada rade na isti način kao i spajanja. Umjesto da mijenjamo komad na mjestu, stvaramo novi. U novom dijelu, datoteke koje nisu promijenjene postaju čvrste veze, a ako izbrišemo kolonu, jednostavno će nedostajati u novom dijelu. Stari komad će se standardno izbrisati nakon osam minuta, a ovdje možete podesiti gore navedene postavke.
Isto vrijedi i za promjene poput mutacija. Kada to uradiš alter delete ili alter update, ne mijenja komad, već stvara novi. I onda briše stari.
Šta ako se struktura tabele promijenila?
Kako podići rezervnu kopiju koja je napravljena sa starom šemom? A drugo pitanje se odnosi na slučaj sa snimcima i alatima sistema datoteka. Da li je ovdje prikladan Btrfs umjesto ZFS-a na Linux LVM-u?
Ako ti uradiš pričvrstite particiju particije s drugom strukturom, ClickHouse će vam reći da to nije moguće. Rješenje je. Prvi je da kreirate privremenu tabelu tipa MergeTree sa starom strukturom, priložite podatke tamo koristeći priloži i izdate alter upit. Zatim možete kopirati ili prenijeti ove podatke i ponovo ih priložiti ili koristiti upit izmijeniti particiju pomicanja tablice.
Sada je drugo pitanje da li je moguće koristiti Btrfs. Za početak, ako imate LVM, onda su dovoljne LVM snimke, a sistem datoteka može biti ext4, nije bitno. Sa Btrts-om, sve ovisi o vašem iskustvu s njim. Ovo je zreo sistem datoteka, ali još uvijek postoje sumnje 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 trenutne najbolje prakse za ponovno dijeljenje podataka?
Pitanje reshardinga je složeno i višestruko. Ovdje možete odgovoriti na nekoliko opcija odjednom. Možete ući s jedne strane i reći ovo - u ClickHouseu nema ugrađene opcije ponovnog šardiranja. Ali bojim se da ovaj odgovor nikome neće odgovarati. Stoga, možete preći s druge strane i reći da ClickHouse ima mnogo načina da ponovo podijeli podatke.
Ako klasteru ponestane prostora ili ne može podnijeti opterećenje, dodajete nove servere. Ali ovi serveri su podrazumevano prazni, na njima nema podataka, nema opterećenja. Morate pomjeriti podatke tako da budu ravnomjerno raspoređeni po novom, većem klasteru.
Prvi način da to učinite je kopiranje dijela particija na nove servere pomoću upita izmijeniti particiju preuzimanja tablice. Na primjer, imali ste particije po mjesecima i uzmete prvi mjesec 2017. i kopirate ga na novi server, a zatim kopirate treći mjesec na neki drugi novi server. I tako radite dok ne postane manje-više ujednačeno.
Migracija se može izvršiti samo za one particije koje se ne mijenjaju tokom snimanja. Za nove particije, pisanje će morati biti onemogućeno, jer njihov prijenos nije atomski. U suprotnom ćete završiti s duplikatima ili prazninama u podacima. Međutim, ova metoda je praktična i djeluje prilično učinkovito. Gotove komprimirane particije se prenose preko mreže, odnosno podaci se ne komprimiraju niti ponovno kodiraju.
Ova metoda ima jedan nedostatak, a zavisi od šeme šardiranja, da li ste se založili na ovu šemu, koji ključ za šardiranje ste imali. U vašem primjeru za slučaj s metrikom, ključ za dijeljenje je hash putanje. Kada odaberete Distribuiranu tabelu, ona ide na sve dijelove klastera odjednom i preuzima podatke odatle.
To znači da vam zapravo nije bitno koji će podaci završiti na kojem fragmentu. Najvažnije je da podaci duž jedne putanje završe na jednom šardu, ali nije važno koji. U ovom slučaju, prijenos gotovih particija je savršen, jer ćete uz odabrane upite dobiti i pune podatke - i prije ponovnog šardiranja i poslije, shema zapravo nije bitna.
Ali postoje slučajevi koji su i komplikovaniji. Ako se na nivou aplikativne logike oslanjate na posebnu šemu dijeljenja, da se ovaj klijent nalazi na tom i tom šardu i zahtjev se može odmah poslati tamo, a ne u Distributed table. Ili koristite prilično noviju verziju ClickHousea i omogućili ste postavku optimizirati preskakanje neiskorištenih dijelova. U ovom slučaju, tokom upita za odabir, izraz u odeljku where će biti raščlanjen i izračunat će se na koje dijelove treba ići u skladu sa šemom dijeljenja. Ovo funkcionira pod uvjetom da se podaci dekomponuju tačno u skladu sa ovom šemom dijeljenja. Ako ste ih prebacili ručno, korespondencija se može promijeniti.
Dakle, to je način broj jedan. I čekam vaš odgovor, da li je metoda prikladna ili idite dalje.
Vladimir Kolobaev, vodeći sistem administrator u Avitou: Alexey, metoda koju si naveo ne pristaje baš najbolje kada treba da rasporediš opterećenje, uključujući i čitanje. Možemo uzeti particiju koja je mjesečna i možemo prenijeti prethodni mjesec na drugi čvor, ali kada dođe zahtjev za ovim podacima, samo ćemo ga učitati. Ali želio bih učitati cijeli klaster, jer će, u suprotnom, neko vrijeme cijelo opterećenje čitanja biti obrađeno od strane dva dijela.
Aleksej Milovidov: Odgovor je ovde čudan – da, loše je, ali može da funkcioniše. Objasniću tačno kako. Vrijedi pogledati scenarij učitavanja koji dolazi s vašim podacima. Ako se radi o podacima praćenja, onda je gotovo sigurno da je velika većina zahtjeva za svježim podacima.
Instalirali ste nove servere, migrirali stare particije, ali i promijenili način na koji se pišu novi podaci. I svježi podaci će se širiti po cijelom klasteru. Tako će nakon pet minuta zahtjevi za posljednjih pet minuta ravnomjerno učitati klaster, nakon jednog dana zahtjevi za dan će ravnomjerno učitati klaster. A zahtjevi za prethodni mjesec, nažalost, ići će samo na dio servera klastera.
Ali često nećete imati zahtjeve za februar 2019. Najvjerovatnije, ako zahtjevi idu u 2019., onda će biti za cijelu 2019. - za veliki vremenski interval, a ne za neki mali raspon. I takvi zahtjevi će također moći ravnomjerno učitati klaster. Ali generalno, vaša primjedba je sasvim tačna da je ovo ad hoc rješenje koje ne raspoređuje podatke potpuno ravnomjerno.
Imam još nekoliko stvari da odgovorim na pitanje. Jedna od njih je o tome kako u početku shemu šardiranja napraviti tako da bude manje boli od ponovnog šardiranja. To nije uvijek moguće.
Na primjer, imate podatke praćenja. Podaci o praćenju rastu iz tri razloga. Prvi je akumulacija istorijskih podataka. Drugi je rast prometa. I treće je povećanje broja stvari koje su predmet praćenja. Postoje nove mikroservise i metrike koje treba sačuvati.
Moguće je da je od njih najveći porast posljedica trećeg razloga - to je povećanje korištenja monitoringa. I u ovom slučaju, vrijedi pogledati prirodu opterećenja, koji su glavni zahtjevi za odabir. Glavni upiti za odabir vjerovatno će pratiti neki podskup metrika.
Na primjer, korištenje CPU-a na nekim serverima od strane neke usluge. Ispostavilo se da postoji neki podskup ključeva pomoću kojih dobijate ove podatke. A sam zahtjev za ovim podacima je najvjerovatnije prilično jednostavan i traje desetinama milisekundi. Koristi se za usluge nadzora, za kontrolne table. Nadam se da sam ovo dobro razumeo.
Vladimir Kolobaev: Činjenica je da se vrlo često pozivamo na istorijske podatke, jer trenutnu poziciju upoređujemo sa istorijskim u realnom vremenu. I važno nam je da imamo brz pristup velikoj količini podataka, a ClickHouse s tim odlično radi.
Potpuno ste u pravu, većinu zahtjeva za čitanje doživljavamo u posljednjem danu, kao i svaki sistem za praćenje. Ali u isto vrijeme, opterećenje historijskih podataka je također prilično veliko. Uglavnom je iz sistema upozorenja koji se vrti svakih trideset sekundi i govori ClickHouseu: „Daj mi podatke za posljednjih šest sedmica. A sada mi napravite njihov pokretni prosek i uporedimo trenutnu vrednost sa istorijskom vrednošću.
Želio bih da kažem da za ovako svježe zahtjeve imamo još jednu malu tabelu u koju pohranjujemo samo dva dana podataka, a glavni zahtjevi ulijeću u nju. Šaljemo samo velike istorijske upite velikoj podijeljenoj tabeli.
Aleksej Milovidov: Nažalost, ispostavilo se da je to slabo primjenjivo za vaš scenarij, ali opisaću dvije loše i složene sheme šardiranja koje ne treba koristiti, ali se koriste u servisu mojih prijatelja.
Postoji glavni klaster sa događajima Yandex.Metrica. Događaji su prikazi stranica, klikovi i prijelazi. Većina zahtjeva ide na određenu web stranicu. Otvarate uslugu Yandex.Metrica, imate web stranicu - avito.ru, idite na izvještaj 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 postavljaju zahtjeve samo za usluge Yandexa. Ali ipak, čak i usluge Yandexa zauzimaju značajan dio svih podataka. Ovo nisu zahtjevi za određene brojače, već za šire filtriranje.
Kako organizovati podatke na način da sve radi efikasno za jedan brojač, a i globalne upite? Još jedna poteškoća leži u činjenici da je broj zahtjeva u ClickHouseu za klaster Metrics nekoliko hiljada u sekundi. Istovremeno, jedan ClickHouse server ne obrađuje netrivijalne zahtjeve, na primjer, nekoliko hiljada u sekundi.
Veličina klastera je šest stotina i nešto servera. Ako jednostavno proširite distribuiranu tabelu preko ovog klastera i tamo pošaljete nekoliko hiljada zahteva, to će postati još gore nego da ih pošaljete na jedan server. S druge strane, opcija da su podaci ravnomjerno raspoređeni, a mi idemo i tražimo od svih servera, odmah se odbacuje.
Postoji dijametralno suprotna opcija. Zamislite da dijelimo podatke po web-stranici, a zahtjev za jednu lokaciju ide na jednu dionicu. Sada će klaster moći da izvuče deset hiljada zahteva u sekundi, ali će na jednom šardu jedan zahtev raditi presporo. Više se neće skalirati u propusnosti. Pogotovo ako je to stranica avito.ru. Neću otkriti tajnu ako kažem da je Avito jedna od najposjećenijih stranica u Runetu. A obraditi ga na jednom komadu bilo bi suludo.
Stoga je shema dijeljenja uređena na škakljiviji način. Čitav klaster je podijeljen na više klastera koje nazivamo slojevima. Unutar svakog klastera nalazi se od deset do nekoliko desetina krhotina. Ukupno ima trideset i devet takvih klastera.
Kako se sve to mjeri? Broj klastera se ne mijenja – kao što je bio prije trideset i devet godina, ostao je isti. Ali unutar svakog od njih postepeno povećavamo broj fragmenata kako se podaci gomilaju. A shema shardinga u cjelini je sljedeća - podjela na ove klastere ide prema web stranicama, a da bi se razumjelo koja je lokacija na kojem klasteru, općenito se koristi zasebna metabaza u MySQL-u. Jedna lokacija - na jednom klasteru. A unutar njega se odvija sharding prema identifikatorima posjetitelja.
Prilikom snimanja dijelimo ih prema ostatku ID-a posjetitelja. Ali kada se doda novi dio, shema dijeljenja se mijenja, nastavljamo dijeljenje, ali s ostatkom dijeljenja s drugim brojem. To znači da se jedan posjetitelj već nalazi na nekoliko servera i na njega se ne možete kladiti. Ovo se radi isključivo kako bi se osiguralo da su podaci bolje komprimirani. A kada postavljamo upite, idemo do Distributed table, koja gleda na klaster i pristupa desetinama servera. Ovo je tako glupa šema.
Ali moja priča će biti nepotpuna ako ne kažem da smo napustili ovu šemu. U novoj šemi smo promijenili sve i kopirali sve podatke koristeći clickhouse-copier.
U novoj shemi, sve lokacije su podijeljene u dvije kategorije - velike i male. Ne znam kako je tamo odabran prag, ali kao rezultat toga, ispostavilo se da su velike stranice snimljene na jednom klasteru, gdje se nalazi 120 fragmenata sa tri replike u svakoj - odnosno 360 servera. A šema dijeljenja je takva da svaki zahtjev ide na sve dijelove odjednom. Ako sada otvorite bilo koju stranicu izvještaja za avito.ru u Yandex.Metrica, zahtjev će ići na 120 servera. U Runetu postoji nekoliko velikih stranica. A zahtjeva nisu hiljadu u sekundi, nego čak i manje od sto. Sve to tiho žvače Distributed table, koje svaki od njih obrađuje 120 servera.
A drugi klaster je za male lokacije. Ovdje je shema dijeljenja prema ID-u web-mjesta, a svaki zahtjev ide na točno jedan dio.
ClickHouse ima uslužni program clickhouse-copier. Možete li reći o njoj?
Moram odmah reći da je ovo rješenje glomaznije i nešto manje produktivno. Prednost je što potpuno razmazuje podatke prema šemi koju navedete. Ali nedostatak uslužnog programa je što se uopće ne resardira. Kopira podatke iz jedne šeme klastera u drugu šemu klastera.
To znači da za funkcioniranje morate imati dva klastera. Mogu se nalaziti na istim serverima, ali se, ipak, podaci neće premještati postepeno, već će se kopirati.
Na primjer, bilo je četiri servera, sada ih je osam. Kreirate novu Distribuiranu tabelu na svim serverima, nove lokalne tabele i pokrećete clickhouse-copier, navodeći u njoj šemu rada koju treba da čita odatle, prihvata novu šemu šardiranja i prenosi podatke tamo. I trebat će vam jedan i po puta više prostora na starim serverima nego što je sada, jer stari podaci moraju ostati na njima, a polovina istih starih podataka će doći na njih. Ako ste unaprijed mislili da podatke treba ponovo razdijeliti i da ima prostora, onda je ova metoda prikladna.
Kako clickhouse-copier radi unutra? Razbija sav posao u skup zadataka za obradu jedne particije jedne tabele na jednom šardu. Svi ovi zadaci se mogu izvoditi paralelno, a clickhouse-copier može pokrenuti više instanci na različitim mašinama, ali ono što radi za jednu particiju nije ništa drugo do odabir umetanja. Podaci se čitaju, dekomprimiraju, ponovo particioniraju, zatim ponovo komprimiraju, negdje zapisuju, ponovo sortiraju. Ovo je teža odluka.
Imali ste pilot stvar koja se zove resharding. Šta sa njom?
Još 2017. godine imali ste pilot stvar pod nazivom resharding. Postoji čak i opcija u ClickHouseu. Razumijem da nije poletjelo. Možete li reći zašto se to dogodilo? Čini se da je veoma relevantno.
Čitav problem je u tome što ako trebate ponovo podijeliti podatke na mjestu, potrebna je vrlo složena sinhronizacija da bi se to uradilo atomski. Kada smo počeli da gledamo kako ova sinhronizacija funkcioniše, postalo je jasno da postoje fundamentalni problemi. I ovi fundamentalni problemi nisu samo teorijski, već su se odmah počeli pokazivati u praksi u obliku nečega što se može vrlo jednostavno objasniti – ništa ne funkcionira.
Da li je moguće spojiti sve dijelove podataka zajedno prije prelaska na spore diskove?
Pitanje o TTL-u s opcijom prelaska na spori disk u kontekstu spajanja. Postoji li drugi način osim cron-a da se svi dijelovi spoje u jedan prije prelaska na spore diskove?
Odgovor na pitanje da li je moguće nekako automatski zalijepiti sve dijelove u jedan prije prenošenja je ne. Čini mi se da to nije potrebno. Ne možete spojiti sve dijelove u jedan, već se jednostavno oslonite na činjenicu da će se automatski prenijeti na spore diskove.
Imamo dva kriterijuma za pravila transfera. Prvi je kako se puni. Ako trenutni nivo pohrane ima manje od određenog procenta slobodnog prostora, biramo jedan komad i premještamo ga u sporiju memoriju. Ili bolje rečeno, ne sporije, već sljedeće - kako ste to postavili.
Drugi kriterij je veličina. On govori o transferu velikih komada. Možete podesiti prag na osnovu slobodnog prostora na brzom disku i podaci će biti automatski premješteni.
Kako preći na nove verzije ClickHouse ako ne postoji način da se unaprijed provjeri kompatibilnost?
O ovoj temi se redovno raspravlja uzimajući u obzir različite verzije, a ipak. Koliko je bezbedno nadograditi sa verzije 19.11 na 19.16 i, na primer, sa 19.16 na 20.3. Koji je najbolji način za prelazak na nove verzije bez mogućnosti da unaprijed provjerite kompatibilnost u sandboxu?
Ovdje postoji nekoliko zlatnih pravila. Prvo - . Velik je, ali postoje odvojene tačke o nazadno nekompatibilnim promjenama. Ne tretirajte ove stavke kao crvenu zastavicu. To su obično manje nekompatibilnosti koje su povezane s nekom rubnom funkcijom koju vjerovatno ne koristite.
Drugo, ako ne postoji način da provjerite kompatibilnost u sandboxu, a želite odmah nadograditi u produkciji, preporuka je da to ne morate činiti. Prvo napravite sandbox i testirajte. Ako nema testnog okruženja, onda najvjerovatnije nemate veliku kompaniju, što znači da možete kopirati dio podataka na svoj laptop i uvjeriti se da sve radi ispravno na njemu. Možete čak i pokrenuti nekoliko replika lokalno na vašoj mašini. Ili možete podići novu verziju negdje u blizini i učitati neke podatke tamo - odnosno napraviti improvizirano testno okruženje.
Drugo pravilo je da se ne ažurira u roku od tjedan dana nakon objavljivanja verzije zbog hvatanja grešaka u proizvodnji i naknadnih brzih popravki. Hajde da shvatimo numerisanje verzija ClickHouse kako se ne bismo zbunili.
Postoji verzija 20.3.4. Broj 20 označava godinu proizvodnje - 2020. Sa stanovišta onoga što je unutra, to nije važno, tako da nećemo obraćati pažnju na to. Dalje - 20.3. Drugi broj - u ovom slučaju 3 - povećavamo svaki put kada izdamo izdanje s nekom novom funkcionalnošću. Ako želimo da dodamo neku funkciju ClickHouse-u, moramo povećati ovaj broj. Odnosno, u verziji 20.4 ClickHouse će raditi još bolje. Treća znamenka je 20.3.4. Ovdje 4 je broj izdanja zakrpa u kojima nismo dodali nove funkcije, ali smo ispravili neke greške. A 4 znači da smo to uradili četiri puta.
Nemojte misliti da je to nešto strašno. Obično korisnik može instalirati najnoviju verziju i ona će raditi bez ikakvih problema s uptimeom godišnje. Ali zamislite da se u nekoj funkciji za obradu bitmapa, koju su dodali naši kineski drugovi, prilikom prosljeđivanja netačnih argumenata, server ruši. Moramo ovo popraviti. Izdaćemo novu verziju zakrpe i ClickHouse će postati stabilniji.
Ako imate ClickHouse koji radi u produkciji, a izašla je nova verzija ClickHousea sa dodatnim funkcijama - na primjer, 20.4.1 je prva, nemojte žuriti s puštanjem u proizvodnju prvog dana. Zašto je ona uopšte potrebna? Ako još ne koristite ClickHouse, možete ga instalirati i, najvjerovatnije, sve će biti u redu. Ali ako ClickHouse već radi stabilno, pratite zakrpe i ažuriranja – koje probleme rješavamo.
Kiril Švakov: Želim da dodam nešto o testnim okruženjima. Svi se jako boje testnih okruženja i iz nekog razloga vjeruju da ako imate vrlo veliki ClickHouse klaster, onda testno okruženje ne bi trebalo biti manje ili barem deset puta manje. To uopšte nije tako.
Mogu to reći na svom primjeru. Imam projekat i tu je ClickHouse. Naše testno okruženje za njega je mala virtuelna mašina u Hetzneru za dvadeset evra, gde je apsolutno sve raspoređeno. Da bismo to učinili, imamo potpunu automatizaciju u Ansibleu, i stoga, u principu, nema razlike gdje se valja - na željeznim serverima ili samo implementirati u virtualne mašine.
Šta se može učiniti? Bilo bi lijepo napraviti primjer u dokumentaciji ClickHouse o tome kako sami implementirati mali klaster - u Dockeru, u LXC-u, možda napraviti Ansible playbook, jer različiti ljudi imaju različite implementacije. Ovo će olakšati mnoge stvari. Kada uzmete i rasporedite klaster za pet minuta, mnogo je lakše pokušati nešto shvatiti. Ovako je mnogo zgodnije, jer uvođenje verzije koju niste testirali u proizvodnju je put u nigdje. Ponekad radi, a ponekad ne. I tako je loše nadati se uspjehu.
Maxim Kotyakov, viši backend inženjer Avito: Dodaću malo o testnim okruženjima iz niza problema za velike kompanije. Imamo potpuni ClickHouse klaster prihvatanja, prema šemama podataka i postavkama, tačnu kopiju onoga što je u proizvodnji. Ovaj klaster je raspoređen u prilično trulim kontejnerima sa minimalnim resursima. Tamo upisujemo određeni postotak produkcijskih podataka, jer postoji mogućnost da se replicira stream u Kafki. Tamo je sve sinhronizovano i skalirano - i po kapacitetu i po protoku, a u teoriji, uz ostale jednake stvari, trebalo bi da se ponaša kao produkcija u metričkom smislu. Sve što je potencijalno eksplozivno prvo se kotrlja na ovo postolje i tamo se infundira nekoliko dana dok se ne pripremi. Ali naravno, ovo rješenje je skupo, teško i sa troškovima podrške koji nisu nuli.
Aleksej Milovidov: Reći ću vam kakvo je testno okruženje naših prijatelja iz Yandex.Metrice. Jedan klaster je bio za servere od 600 i nešto, drugi za 360, a postoji i treći i nekoliko klastera. Testno okruženje za jednu od njih su samo dva šarda sa po dve replike u svakoj. Zašto dva krhotina? Da ne bude sam. I replike, takođe, da budu. Samo neki minimalni iznos koji si možete priuštiti.
Ovo testno okruženje vam omogućava da proverite zdravlje zahteva i da li je nešto pokvareno u velikoj meri. Ali često nastaju problemi potpuno drugačije prirode, kada sve funkcionira, ali postoje male promjene s opterećenjem.
Dat ću vam primjer. Odlučili smo da instaliramo novu verziju ClickHouse-a. Postavljen je na testno okruženje, automatizovani testovi prolaze u samoj Yandex.Metrici, koji upoređuju podatke na staroj verziji i na novoj, pokrećući ceo cevovod. I naravno, zeleni testovi našeg CI. Inače, ovu verziju ne bismo ni predložili.
Sve je uredu. Počinjemo sa radom u proizvodnji. Dobijam poruku da je opterećenje na grafikonima povećano nekoliko puta. Vraćamo verziju. Pogledam grafikon i vidim: opterećenje se zaista povećalo nekoliko puta tokom uvođenja, a ponovo se smanjilo kada se izbaci. Zatim smo počeli da vraćamo verziju. I opterećenje se povećavalo na isti način i padalo nazad na isti način. Dakle, zaključak je sljedeći - opterećenje se povećalo u vezi s proračunom, ništa iznenađujuće.
Tada je bilo teško uvjeriti kolege da ipak instaliraju novu verziju. Kažem: „U redu je, izvucite. Držite fige, sve će uspjeti. Sada se opterećenje na grafikonima povećalo, ali sve je u redu. Čekaj." Općenito, uradili smo ovo, i to je to - verzija je objavljena na proizvodnom mjestu. Ali gotovo sa svakim proračunom javljaju se slični problemi.
Kill query bi trebao ubiti upite, ali nije. Zašto?
Došao mi je korisnik, neka vrsta analitičara, i napravio određeni zahtjev, koji je stavio moj ClickHouse klaster. Neki čvor ili cijeli klaster, ovisno o tome u koju repliku ili dio je zahtjev ušao. Vidim da su svi CPU resursi na ovom serveru na polici, sve je crveno. U isto vrijeme, ClickHouse i sam odgovara na zahtjeve. I pišem: "Molim vas, pokažite mi procesnu listu, koji zahtjev je stvorio ovo ludilo."
Pronalazim ovaj zahtjev i napišem mu kill. I vidim da se ništa ne dešava. Moj server je na polici, ClickHouse mi onda daje neke komande, pokazuje da je server živ i sve je u redu. Ali imam degradaciju u svim korisničkim zahtjevima, počinje degradacija unosom u ClickHouse, a moj upit za ubijanje ne radi. Zašto? Mislio sam da bi kill query trebao ubiti upite, ali nije.
Sada će biti prilično čudan odgovor. Poenta je da upit za ubijanje ne ubija upite.
Kill query stavlja mali okvir za potvrdu pod nazivom "Želim da ovaj upit bude ubijen". I sam zahtjev, prilikom obrade svakog bloka, gleda ovu zastavicu. Ako je postavljen, zahtjev prestaje raditi. Ispostavilo se da niko ne ubija zahtjev, on sam mora sve provjeriti i stati. I ovo bi trebalo funkcionirati u svim slučajevima kada je zahtjev u stanju blok obrade. Obradit će sljedeći blok podataka, provjeriti zastavicu i zaustaviti se.
Ovo ne radi u slučajevima kada je zahtjev blokiran na nekoj operaciji. Istina, ovo najvjerovatnije nije vaš slučaj, jer, po vama, koristi gomilu serverskih resursa. Moguće je da to ne funkcionira u slučaju eksternog sortiranja i u nekim drugim detaljima. Ali općenito, to ne bi trebalo biti, ovo je greška. I jedino što mogu savjetovati je ažuriranje ClickHouse.
Kako izračunati vrijeme odgovora pod opterećenjem čitanja?
Postoji tabela u kojoj se pohranjuju agregati stavki - razni brojači. Broj linija je oko sto miliona. Da li je moguće računati na predvidljivo vrijeme odgovora ako sipate 1K RPS na 1K stavki?
Sudeći po kontekstu, riječ je o opterećenju čitanjem, jer nema problema sa pisanjem - može se ubaciti najmanje hiljadu, barem sto hiljada, a ponekad i nekoliko miliona redova.
Zahtjevi za čitanje su veoma različiti. U odabiru 1, ClickHouse može izvršiti oko desetine hiljada zahtjeva u sekundi, tako da će čak i zahtjevi za jedan ključ već zahtijevati neke resurse. A takvi upiti po točkama bit će teži nego u nekim bazama podataka ključ/vrijednost, jer je za svako čitanje potrebno čitati blok podataka po indeksu. Naš indeks se ne bavi svakim zapisom, već svakim rasponom. Odnosno, morate pročitati cijeli raspon - ovo su po defaultu 8192 reda. I morate dekomprimirati komprimirani blok podataka sa 64 KB na 1 MB. Tipično, takvi upiti o tačkama traju od nekoliko milisekundi. Ali ovo je najlakša opcija.
Pokušajmo s jednostavnom aritmetikom. Ako pomnožite nekoliko milisekundi sa hiljadu, dobićete nekoliko sekundi. Kao da je nemoguće zadržati hiljadu zahtjeva u sekundi, a zapravo je moguće, jer imamo nekoliko procesorskih jezgara. Dakle, u principu, 1000 RPS ClickHouse ponekad može zadržati, ali na kratke zahtjeve, odnosno zahtjeve za točke.
Ako trebate skalirati ClickHouse klaster po broju jednostavnih zahtjeva, onda preporučujem najjednostavniju stvar - povećajte broj replika i pošaljite zahtjeve na slučajnu repliku. Ako jedna replika drži pet stotina zahtjeva u sekundi, što je sasvim realno, onda će tri replike držati hiljadu i po.
Ponekad, naravno, također možete konfigurirati ClickHouse za maksimalan broj očitavanja tačaka. Šta je potrebno za ovo? Prvi je smanjenje granularnosti indeksa. Pritom, ne treba ga svesti na jedan, već na osnovu toga da će broj zapisa u indeksu biti nekoliko miliona ili desetine miliona po serveru. Ako tabela ima sto miliona redova, onda se 64 može postaviti kao granularnost.
Možete smanjiti veličinu komprimovanog bloka. Za ovo postoje postavke. minimalna veličina bloka kompresije, maksimalna veličina bloka kompresije. Možete ih smanjiti, ponovo učitati podatke i tada će upiti po točkama biti brži. Ali ipak, ClickHouse nije baza podataka ključ/vrijednost. Veliki broj malih zahtjeva je anti-obrazac učitavanja.
Kiril Švakov: Dat ću savjet u slučaju da postoje obični računovođe. Ovo je prilično standardna situacija kada je neka vrsta brojača pohranjena u ClickHouse. Imam korisnika, on je iz te i te zemlje, neka druga treća oblast, i moram nešto postepeno povećavati. Uzmite MySQL, napravite jedinstveni ključ - u MySQL-u je to duplikat ključa, au PostgreSQL-u je konflikt - i dodajte znak plus. Ovo će raditi mnogo bolje.
Kada imate malo podataka, nema puno smisla koristiti ClickHouse. Postoje redovne baze podataka i oni to dobro rade.
Šta podesiti u ClickHouseu tako da više podataka bude u kešu?
Zamislimo situaciju - serveri imaju 256 GB RAM-a, u svakodnevnoj rutini ClickHouse zauzima oko 60-80 GB, na vrhuncu - do 130. Šta se može omogućiti i podesiti tako da više podataka bude u kešu i, shodno tome , ima manje putovanja na disk?
Po pravilu, keš stranica operativnog sistema dobro obavlja ovaj zadatak. Ako samo otvorite vrh, pogledate tamo keširano ili slobodno - također piše koliko je keširano - tada možete vidjeti da se sva slobodna memorija koristi za keš. I kada čitate ove podatke, oni se neće čitati s diska, već iz RAM-a. Istovremeno, mogu reći da se keš koristi efikasno, jer se keširaju kompresovani podaci.
Međutim, ako želite još više ubrzati neke jednostavne upite, moguće je omogućiti keš memoriju u dekomprimiranim podacima unutar ClickHousea. To se zove nekomprimovani keš. U konfiguracijskoj datoteci config.xml postavite nekomprimiranu veličinu keša na vrijednost koja vam je potrebna - savjetujem ne više od polovine slobodne RAM-a, jer će ostatak ići ispod keša stranice.
Osim toga, postoje dvije postavke nivoa zahtjeva. Prvo podešavanje - koristite nekomprimovani keš memoriju - uključuje njegovu upotrebu. Preporučuje se da ga omogućite za sve zahtjeve, osim za teške, koji mogu čitati sve podatke i isprazniti ovu keš memoriju. A druga postavka je nešto poput maksimalnog broja linija za korištenje keša. Automatski ograničava velike zahtjeve tako da oni prolaze kroz keš memoriju.
Kako mogu konfigurirati storage_configuration za pohranu u RAM-u?
U novoj ClickHouse dokumentaciji pročitao sam odjeljak koji se odnosi . U opisu se nalazi primjer sa brzim SSD-om.
Pitam se kako možete isto konfigurirati sa volumenom vruće memorije. I još jedno pitanje. Kako select radi s ovom organizacijom podataka, hoće li čitati cijeli skup ili samo onaj na disku i jesu li ti podaci komprimirani u memoriji? I kako odjeljak prewhere funkcionira na takvoj organizaciji podataka?
Ova postavka utiče na pohranjivanje dijelova podataka, a njihov se format ni na koji način ne mijenja.
Pogledajmo izbliza.
Možete podesiti skladištenje podataka u RAM-u. Sve što je konfigurirano za disk je njegova putanja. Vi kreirate tmpfs particiju koja je montirana na neku stazu u sistemu datoteka. Odredite ovu putanju kao putanju za skladištenje podataka za najtopliju particiju, komadići podataka počinju da stižu i tamo se zapisuju, 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 možete. Ako je tako, podaci će biti vraćeni. Zamislite da je server iznenada isključen i ponovo uključen. Dionica je ponovo montirana, ali postoji praznina. Prilikom pokretanja, ClickHouse server vidi da ti dijelovi nedostaju, iako bi, prema metapodacima ZooKeeper-a, trebali biti. On gleda na kojim se replikama nalaze, traži ih i preuzima. Tako će podaci biti vraćeni.
U tom smislu, pohranjivanje podataka u RAM ne razlikuje se suštinski od pohranjivanja na disk, jer kada se podaci zapisuju na disk, oni također prvo padaju u keš stranice i kasnije se fizički zapisuju. Zavisi kako je sistem datoteka montiran. Ali za svaki slučaj, reći ću da ClickHouse ne fsync na insert.
U ovom slučaju, podaci u RAM memoriji se pohranjuju u potpuno istom formatu kao na disku. Upit za odabir odabire dijelove za čitanje na isti način, odabire potrebne raspone podataka u dijelovima i čita ih. I prewhere radi potpuno isto, bez obzira da li su podaci bili u RAM-u ili na disku.
Do kojeg broja jedinstvenih vrijednosti je niska kardinalnost efektivna?
Niska kardinalnost je nezgodna. Sastavlja rječnike podataka, ali oni su lokalni. Prvo, rječnici su različiti za svaki dio, a drugo, čak i unutar jednog djela mogu biti različiti za svaki raspon. Kada broj jedinstvenih vrijednosti dostigne prag - milion, mislim - rječnik se jednostavno ostavlja po strani i stvara se novi.
Odgovor je općenito: za svaki lokalni raspon - recimo, za svaki dan - negdje do milion jedinstvenih vrijednosti, Low Cardinality je efikasan. Nakon toga, postojat će samo rezervni, u kojem će se koristiti mnogo različitih rječnika, a ne samo jedan. Radit će na isti način kao i obična kolona tipa string, možda malo manje efikasno, ali neće biti ozbiljne degradacije performansi.
Koje su najbolje prakse za pretraživanje cijelog teksta u tabeli sa pet milijardi redova?
Postoje različiti odgovori. Prvi je reći da ClickHouse nije pretraživač punog teksta. Za to postoje posebni sistemi, npr. и . Međutim, vidim sve više ljudi koji kažu da prelaze sa Elasticsearch na ClickHouse.
Zašto se ovo dešava? Oni to objašnjavaju činjenicom da Elasticsearch prestaje da se nosi s opterećenjem na nekim volumenima, počevši od indeksa izgradnje. Indeksi postaju previše glomazni, a ako jednostavno prenesete podatke u ClickHouse, ispada da se pohranjuju nekoliko puta efikasnije u smislu volumena. Istovremeno, upiti za pretraživanje često nisu bili takvi da je u cjelokupnoj količini podataka bilo potrebno pronaći neki izraz, uzimajući u obzir morfologiju, već potpuno drugačiji. Na primjer, pronaći posljednjih nekoliko sati u zapisnicima za neki podniz bajtova.
U ovom slučaju kreirate indeks u ClickHouse, prvo polje u kojem će biti datum sa vremenom. A najveća granica podataka bit će upravo za datumski raspon. Unutar odabranog raspona datuma, po pravilu, već je moguće izvršiti pretraživanje cijelog teksta čak i metodom brute-force koristeći like. Like izjava u ClickHouse je najefikasnija like izjava koju možete pronaći. Ako nađeš bolji, reci mi.
Ali ipak, like 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č za jedan dan, morat ćete skenirati terabajt. I vjerovatno je na običnim tvrdim diskovima, i kao rezultat će biti učitani na takav način da nećete ulaziti na ovaj server preko SSH-a.
U ovom slučaju, spreman sam ponuditi još jedan mali trik. To je iz kategorije eksperimentalnog - može raditi, a možda i ne. ClickHouse ima indekse punog teksta u obliku trigramskih filtera. Naše kolege iz Arenadata-e su već isprobale ove indekse i često rade upravo onako kako je predviđeno.
Da biste ih pravilno koristili, trebali biste dobro razumjeti kako točno funkcioniraju: šta je trigramski filter za cvjetanje i kako odabrati njegovu veličinu. Mogu reći da će pomoći za upite o nekim rijetkim frazama, podstringovima koji se rijetko nalaze u podacima. U ovom slučaju, podopsezi će biti odabrani indeksima, a manje podataka će biti pročitano.
ClickHouse je nedavno dodao još naprednije funkcije za pretraživanje punog teksta. Ovo je, prvo, traženje gomile podstringova odjednom u jednom prolazu, uključujući opcije osjetljive na velika i mala slova, podržane UTF-8 ili samo ASCII opcije. Odaberite najefikasniji koji vam je potreban.
Također se tražilo nekoliko regularnih izraza u jednom prolazu. Ne morate pisati X kao jedan podniz ili X kao drugi podniz. Pišite odmah, i sve je urađeno što efikasnije.
Treće, sada postoji približna pretraga redovnih izraza i približna pretraga podstringova. Ako je neko napisao riječ sa greškom u kucanju, tražit će se maksimalno podudaranje.
Koji je najbolji način da se organizuje pristup ClickHouse-u za veliki broj korisnika?
Recite nam kako najbolje organizirati pristup za veliki broj potrošača i analitičara. Kako formirati red, dati prioritet maksimalnom broju istovremenih upita i pomoću kojih alata?
Ako je klaster dovoljno velik, onda bi dobro rješenje bilo podizanje još dva servera, koji će postati ulazna tačka za analitičare. Odnosno, ne puštajte analitičare u određene dijelove klastera, već jednostavno napravite dva prazna servera, bez podataka, i već postavite prava pristupa na njima. Istovremeno, korisnička podešavanja se prenose na udaljene servere tokom distribuiranih zahteva. Odnosno, konfigurišete sve na ova dva servera, a podešavanja utiču na ceo klaster.
U principu, ovi serveri su bez podataka, ali je količina RAM-a na njima vrlo važna za izvršavanje zahtjeva. Disk se također može koristiti za privremene podatke ako je omogućeno vanjsko agregiranje ili eksterno sortiranje.
Važno je pogledati postavke koje su povezane sa svim mogućim ograničenjima. Ako sada odem u klaster Yandex.Metrics kao analitičar i postavim upit odaberite broj od pogodaka, tada ću odmah dobiti izuzetak da ne mogu ispuniti zahtjev. Maksimalan broj redova koji mi je dozvoljeno da skeniram je sto milijardi, a ukupno ih ima pedeset triliona na klasteru u jednoj tabeli. Ovo je prvo ograničenje.
Recimo da uklonim ograničenje broja redova i ponovo pokrenem upit. Tada ću vidjeti sljedeći izuzetak - postavka je omogućena indeks sile po datumu. Ne mogu pokrenuti upit ako nisam naveo raspon datuma. Ne morate se oslanjati na analitičare da ga unose ručno. Tipičan slučaj - raspon datuma je napisan gdje je datum događaja između sedmice. A onda tamo jednostavno nisu naveli zagradu, a umjesto i ispostavilo se da je ili - ili URL podudaranje. Ako nema ograničenja, krenut će indeksirati URL stupac i potrošiti tonu resursa.
Osim toga, ClickHouse ima dvije postavke prioriteta. Nažalost, veoma su primitivni. Jedan se jednostavno zove prioritet. Ako je prioritet ≠ 0, a zahtjevi sa nekim prioritetom se izvršavaju, ali se izvršava zahtjev sa nižom vrijednošću prioriteta, što znači viši prioritet, tada se izvršava zahtjev sa vrijednošću prioriteta većom od, što znači niži prioritet jednostavno suspendovan i neće raditi uopšte tokom ovog vremena.
Ovo je vrlo gruba postavka i nije prikladna za situacije u kojima je klaster stalno opterećenje. Ali ako imate kratke, impulsne zahtjeve koji su važni, a klaster je uglavnom neaktivan, ova postavka će biti dovoljna.
Poziva se sljedeća postavka prioriteta Prioritet niti OS-a. Jednostavno izlaže sve niti izvršavanja zahtjeva lijepoj vrijednosti za Linux planer. Radi tako-tako, ali još uvijek radi. Ako postavite minimalnu lijepu vrijednost - to je najveća vrijednost, a samim tim i najniži prioritet - i postavite -19 za zahtjeve visokog prioriteta, tada će CPU trošiti zahtjeve niskog prioriteta oko četiri puta manje od onih sa visokim prioritetom.
Također morate postaviti maksimalno vrijeme izvršenja upita - recimo, pet minuta. Minimalna brzina izvršavanja zahtjeva je najbolja stvar. Ova postavka postoji već duže vrijeme, a potrebna je ne samo da se potvrdi da ClickHouse ne usporava, već i da se forsira.
Zamislite da postavljate: ako upit obrađuje manje od milion redova u sekundi, to ne možete učiniti. Ovo obeščašćuje naše dobro ime, našu dobru bazu podataka. Hajde da to zabranimo. Zapravo postoje dvije postavke. Jedan se zove min. brzina izvršenja - u redovima u sekundi, a drugi se zove timeout prije provjere min. brzine izvršavanja - petnaest sekundi po defaultu. To jest, petnaest sekundi je moguće, a zatim, ako polako, onda samo izbacite izuzetak - poništite zahtjev.
Također morate postaviti kvote. ClickHouse ima ugrađenu funkciju kvote koja broji potrošnju resursa. Ali, nažalost, ne željezni resursi kao što su CPU, diskovi, već logički - broj obrađenih zahtjeva, pročitanih linija i bajtova. I možete postaviti, na primjer, maksimalno sto zahtjeva u roku od pet minuta i hiljadu zahtjeva na sat.
Zašto je to važno? Zato što će se neki od analitičkih zahtjeva izvoditi ručno direktno iz ClickHouse klijenta. I sve će biti dobro. Ali ako u svojoj kompaniji imate napredne analitičare, oni će napisati skriptu i može doći do greške u skripti. I ova greška će uzrokovati da se zahtjev izvrši u beskonačnoj petlji. To je ono što treba zaštititi.
Da li je moguće dati rezultate jednog zahtjeva na deset klijenata?
Imamo nekoliko korisnika koji vole da uđu sa veoma velikim zahtevima u isto vreme. Zahtjev je velik, u principu se brzo izvršava, ali zbog činjenice da ima mnogo takvih zahtjeva u isto vrijeme postaje veoma bolan. Da li je moguće izvršiti isti zahtjev, koji je stigao deset puta zaredom, jednom, a rezultat dati deset klijenata?
Problem je u tome što nemamo rezultate keš memorije ili međumemoriju podataka. Postoji predmemorija stranica operativnog sistema, koja će vam omogućiti da više ne čitate podatke sa diska, ali će, nažalost, podaci i dalje biti dekomprimovani, deserializovani i ponovo obrađeni.
Želio bih to nekako izbjeći, bilo keširanjem međupodataka, ili poređanjem sličnih upita u neku vrstu reda i dodavanjem keša rezultata. Sada imamo jedan pull zahtjev u razvoju, koji dodaje predmemoriju zahtjeva, ali samo za podzahtjeve u sekcijama in i join - odnosno rješenje je inferiorno.
Međutim, i mi imamo takvu situaciju. Posebno kanonski primjer su zahtjevi sa paginacijom. Postoji izvještaj, ima nekoliko stranica i postoji ograničenje zahtjeva 10. Onda isto, ali limit 10,10. Zatim drugu stranicu. I postavlja se pitanje zašto to sve brojimo svaki put? Ali sada nema rješenja i nema načina da se to izbjegne.
Postoji alternativno rješenje koje se postavlja kao prikolica pored ClickHouse-a - .
Kiril Švakov: ClickHouse Proxy ima ugrađeni limitator brzine i ugrađenu keš memoriju rezultata. Tu je napravljeno dosta podešavanja, jer je sličan zadatak riješen. Proxy vam omogućava da ograničite zahtjeve tako što ćete ih staviti u red čekanja i konfigurirati koliko dugo živi predmemorija zahtjeva. Ako su zahtjevi zaista isti, proxy će ih dati više puta, a na ClickHouse otići samo jednom.
Nginx također ima keš memoriju u besplatnoj verziji i to će također raditi. Nginx čak ima postavke tako da će, ako zahtjevi stignu u isto vrijeme, zaustaviti druge dok se jedan ne završi. Ali upravo u ClickHouse Proxyju postavke su napravljene mnogo bolje. Napravljena je posebno za ClickHouse, posebno za ove zahtjeve, pa je prikladnija. Pa, lako je postaviti.
Šta je sa asinhronim operacijama i materijalizovanim pogledima?
Postoji takav problem da su operacije sa zamjenskim motorom asinhrone - podaci se prvo pišu, a zatim se kolabiraju. Ako materijalizirana tableta s nekim agregatima živi ispod tableta, tada će na nju biti upisani duplikati. A ako nema složene logike, onda će se podaci duplicirati. Šta se može učiniti povodom toga?
Postoji očigledno rješenje - implementirati okidač na određenu klasu matview tokom asinhrone operacije kolapsa. Postoje li "srebrni meci" planovi za implementaciju takve funkcionalnosti?
Vrijedi razumjeti kako funkcionira deduplikacija. Ovo što ću sada reći nije vezano za pitanje, ali vrijedi zapamtiti za svaki slučaj.
Prilikom umetanja u repliciranu tablicu, dolazi do deduplikacije cijelih umetnutih blokova. Ako ponovo umetnete isti blok koji sadrži isti broj istih redova u istom redoslijedu, tada se podaci dedupliciraju. Dobićete "U redu" kao odgovor na umetanje, ali će jedna serija podataka biti stvarno napisana i neće biti duplicirana.
Ovo je neophodno radi sigurnosti. Ako dobijete "OK" tokom umetanja, vaši podaci su umetnuti. Ako dobijete grešku od ClickHouse-a, onda oni nisu umetnuti i morate ponoviti umetanje. Ali ako se veza prekine tokom umetanja, onda ne znate da li su podaci umetnuti ili ne. Jedina opcija je ponoviti umetanje. Ako su podaci zaista umetnuti, a vi ste ih ponovo umetnuli, postoji blokada deduplikacije. Potrebno je da se izbjegnu duplikati.
Takođe je važno kako to funkcioniše za materijalizovane poglede. Ako su podaci deduplicirani kada su umetnuti u glavnu tabelu, onda ni oni neće ići u materijalizovani prikaz.
Sada o pitanju. Vaša situacija je složenija jer pišete duplikate pojedinačnih redova. Odnosno, nije dupliciran cijeli paket, već određene linije, i one se kolabiraju u pozadini. Zaista, podaci će se skupiti u glavnoj tabeli, a oni koji nisu skupljeni će otići u materijalizovani prikaz i ništa se neće desiti materijalizovanim pogledima tokom spajanja. Zato što materijalizirani pogled nije ništa drugo do okidač na umetku. Ništa drugo mu se ne dešava tokom drugih operacija.
I ne mogu biti sretan ovdje. Potrebno je samo tražiti konkretno rješenje za ovaj slučaj. Na primjer, da li je moguće zamijeniti ga u materijaliziranom pogledu, a metoda deduplikacije će možda raditi na isti način. Ali, nažalost, ne uvijek. Ako se agregira, onda neće raditi.
Kiril Švakov: Jedno vrijeme smo imali i izgradnju kostiju. Pojavio se problem što ima impresija oglasa, a postoje neki podaci koje možemo prikazati u realnom vremenu – to su samo impresije. Rijetko se umnožavaju, ali ako se to dogodi, svejedno ćemo ih srušiti. I bilo je stvari koje se ne mogu duplirati - klikovi i cijela ova priča. Ali isto tako sam želeo da ih pokažem skoro odmah.
Kako su napravljeni materijalizovani pogledi? Bilo je pogleda u kojima se to piše direktno - postoji zapis u sirovim podacima, a on je napisan u pregledima. Tamo u nekom trenutku podaci nisu baš tačni, dupliraju se i tako dalje. A tu je i drugi dio tabele, gdje izgledaju potpuno isto kao i materijalizirani pogledi, odnosno potpuno su iste strukture. S vremena na vrijeme preračunamo podatke, prebrojimo podatke bez duplikata, upišemo u te tabele.
Prošli smo kroz API - ovo neće raditi u ClickHouseu ručno. A API izgleda: kada imam datum posljednjeg dodavanja u tablicu, gdje je zagarantovano da su tačni podaci već izračunati, i postavlja zahtjev za jednu i drugu tablicu. Iz jednog zahtjeva bira do određenog vremena, a iz drugog dobija ono što još nije izračunato. I radi, ali ne pomoću jednog ClickHouse-a.
Ako imate neku vrstu API-ja - za analitičare, za korisnike - onda je, u principu, ovo opcija. Uvek brojiš, uvek računaš. To se može raditi jednom dnevno ili u neko drugo vrijeme. Sami birate opseg koji vam nije potreban i nije kritičan.
ClickHouse ima puno dnevnika. Kako mogu vidjeti sve što se dešava sa serverom u trenutku?
ClickHouse ima veoma veliki broj različitih logova, a taj broj se povećava. U novim verzijama neke od njih su čak uključene po defaultu, u starijim verzijama moraju biti omogućene prilikom ažuriranja. Međutim, njih je sve više. Voleo bih da konačno vidim šta se sada dešava sa mojim serverom, možda na nekoj zbirnoj kontrolnoj tabli.
Imate li u ClickHouse timu, ili u timovima svojih prijatelja, koji podržavaju neku funkcionalnost gotovih dashboard-a koji bi te zapise prikazali kao gotov proizvod? Na kraju krajeva, samo gledanje dnevnika u ClickHouse je sjajno. Ali bilo bi jako cool da je već pripremljen u obliku kontrolne table. Napušio bih se na ovo.
Postoje kontrolne table, iako nisu standardizovane. U našoj kompaniji imamo oko 60 timova koji koriste ClickHouse, a najčudnije je da mnogi od njih imaju dashboarde koje su sami napravili, i to malo drugačije. Neki timovi koriste internu instalaciju Yandex.Clouda. Postoje neki gotovi izvještaji, iako ne svi potrebni. Drugi imaju svoje.
Moje kolege iz Metrice imaju svoju kontrolnu tablu u Grafani, a ja svoju za svoj klaster. Gledam na stvari kao što je cache hit za serif cache. A još teže je što koristimo različite alate. Napravio sam svoju kontrolnu tablu na vrlo starom alatu koji se zove Graphite-web. On je potpuno ružan. I dalje ga tako koristim, mada bi Grafana vjerovatno bila zgodnija i ljepša.
Osnovna stvar u kontrolnoj tabli je ista. Ovo su sistemske metrike za klaster: CPU, memorija, disk, mreža. Drugi su broj istovremenih zahtjeva, broj simultanih stapanja, broj zahtjeva u sekundi, maksimalni broj dijelova za particije tablice MergeTree, kašnjenje replikacije, veličina reda replikacije, broj redova umetnutih u sekundi, broj umetnutih blokova u sekundi. Ovo je sve što se ne dobija iz dnevnika, već iz metrike.
Vladimir Kolobaev: Alexey, ja bih malo ispravio. Tu je Grafana. Grafana ima izvor podataka koji je ClickHouse. Odnosno, mogu uputiti zahtjeve od Grafane direktno ClickHouseu. ClickHouse ima tabelu sa logovima, ista je za sve. Kao rezultat toga, želim pristupiti ovoj log tablici u Grafani i vidjeti zahtjeve koje moj server primjenjuje. Bilo bi sjajno imati ovakvu kontrolnu tablu.
I sam sam vozio bicikl. Ali imam pitanje - ako je sve to standardizirano, a Grafanu koriste svi, zašto Yandex nema takvu službenu kontrolnu tablu?
Kiril Švakov: Zapravo, izvor podataka koji ClickHouse sada podržava Altinity. I samo želim dati vektor gdje kopati, a koga gurati. Možete ih pitati, jer Yandex i dalje pravi ClickHouse, a ne priču oko njega. Altinity je glavna kompanija koja trenutno promoviše ClickHouse. Neće ga napustiti, ali će ga podržati. Jer u principu, da biste postavili kontrolnu ploču na web stranicu Grafane, trebate je samo registrirati i postaviti - nema posebnih problema.
Aleksej Milovidov: Tokom protekle godine, ClickHouse je dodao mnogo funkcija za profilisanje upita. Postoje metrika za svaki zahtjev za korištenje resursa. A nedavno je dodat još niži profiler upita da se vidi gdje upit provodi svaku milisekundu. Ali da bih koristio ovu funkcionalnost, moram otvoriti klijent konzole i ukucati upit koji stalno zaboravljam. Sačuvao sam ga negde i uvek zaboravim gde tačno.
Voleo bih da postoji alatka koja samo kaže - evo vaših teških upita, grupisanih po klasama upita. Kliknuo sam na jednu, a oni bi mi rekli da je teška. Sada takvog rješenja nema. I zaista je prilično čudno kada me ljudi pitaju: "Recite mi, ima li gotovih kontrolnih ploča za Grafanu?" od Kostyana. Ne znam šta je, nisam ga lično koristio."
Kako utjecati na merdzhi da server ne padne u OOM?
Imam tabelu, postoji samo jedna particija u tabeli, to je ReplacingMergeTree. Pisao sam podatke u njega četiri godine. Morao sam da ga izmenim i izbrišem neke podatke.
Uradio sam to i tokom obrade ovog zahtjeva sva memorija na svim serverima u klasteru je pojela, a svi serveri u klasteru su zajedno ušli u OOM. Onda su svi zajedno ustali, počeli spajati istu operaciju, ovaj blok podataka, i opet upali u OOM. Onda su ponovo ustali i ponovo pali. I ova stvar nije prestala.
Onda se ispostavilo da je ovo zapravo greška koju su momci ispravili. Ovo je super, hvala vam puno. Ali talog je ostao. I sada, kada razmišljam o potrebi da se napravi određeno spajanje u tabeli, imam pitanje - zašto ne mogu uzeti ova spajanja i nekako uticati na njih? Na primjer, ograničite ih količinom potrebne RAM-a ili, u principu, njihovim brojem koji će obraditi ovu konkretnu tablicu.
Imam tabelu koja se zove "Metrika", molim vas da je obradite za mene u dva toka. Nema potrebe da pravite deset ili pet spajanja paralelno, uradite to u dva. Mislim da za dva imam dovoljno memorije, ali možda neće biti dovoljno za obradu deset. Zašto strah ostaje? Jer tabela raste i jednog dana ću se susresti sa situacijom koja u principu više nije zbog greške, već zbog činjenice da će se podaci promijeniti u tolikoj količini da jednostavno nemam dovoljno memorije na server. I tada će server pasti u OOM tokom spajanja. Štaviše, mogu otkazati mutaciju, ali spajanje je nestalo.
Znate, prilikom spajanja server neće pasti u OOM, jer se prilikom spajanja količina RAM-a koristi samo za jedan mali raspon podataka. Tako da će sve biti u redu bez obzira na količinu podataka.
Vladimir Kolobaev: U redu. Ovdje je trenutak takav da sam nakon što smo ispravili grešku skinuo novu verziju za sebe, a na drugom stolu, manjem, gdje ima puno particija, uradio sam sličnu operaciju. I tokom spajanja, oko 100 GB RAM-a je spaljeno na serveru. Imao sam 150 zauzetih, pojeo 100, a ostao je prozor od 50 GB, tako da nisam upao u OOM.
Šta me trenutno štiti od pada u OOM ako stvarno troši 100 GB RAM-a? Šta učiniti u situaciji ako iznenada ponestane RAM-a na merdžu?
Aleksej Milovidov: Postoji takav problem da potrošnja RAM-a nije ograničena na merdži. A drugi problem je u tome što ako je dodijeljeno spajanje, onda ono mora biti izvršeno, jer je upisano u dnevnik replikacije. Dnevnik replikacije je radnja koja je potrebna da se replika dovede u konzistentno stanje. Ako ne izvršite ručne manipulacije da će se ovaj dnevnik replikacije vratiti, spajanje će se morati izvršiti 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 u izvođenju stapanja, ono će početi iznova, doći do nekog praga, izbaciti izuzetak, a zatim početi iznova - od toga neće biti ništa dobro. Ali u principu, bilo bi korisno uvesti ovo ograničenje.
Kako će se odvijati razvoj Golang drajvera za ClickHouse?
Golang vozač koji je napisao Kirill Shvakov sada je zvanično podržan od strane ClickHouse tima. On , on je sada veliki i stvaran.
Mala napomena. Postoji divno i omiljeno skladište normalnih oblika beskonačnog reda - ovo je Vertica. Oni također imaju svoj službeni drajver za python, koji održavaju Vertica programeri. I nekoliko puta se dogodilo da su se verzije skladišta i verzije drajvera prilično naglo razišle, a drajver je u jednom trenutku prestao da radi. I drugi trenutak. Podršku za ovaj zvanični drajver, čini mi se, održava sistem “bradavica” - napišete im problem i on zauvijek visi.
Imam dva pitanja. Sada je Kirillov Golang drajver skoro podrazumevani način komunikacije sa Golanga sa ClickHouse-om. Osim ako neko i dalje komunicira preko http interfejsa, jer mu se to jako sviđa. Kako će se razvijati ovaj drajver? Hoće li biti sinkroniziran s nekim kvarnim promjenama u samom spremištu? I koja je procedura za razmatranje pitanja?
Kiril Švakov: Prvi je kako je sve uredjeno birokratski. O ovom pitanju nije bilo reči, tako da nemam šta da odgovorim.
Da bismo odgovorili na pitanje o problemu, potrebno nam je malo istorije vozača. Radio sam za kompaniju koja je imala mnogo podataka. Bio je to reklamni spinner sa ogromnim brojem događaja koje je trebalo negdje pohraniti. I u nekom trenutku se pojavio ClickHouse. Sipali smo podatke u njega i u početku je sve bilo u redu, ali onda je ClickHouse pao. Tada smo odlučili da nam to ne treba.
Godinu dana kasnije, vratili smo se ideji korištenja ClickHouse-a i morali smo tu nekako upisati podatke. Ulaz je bio ovaj - gvožđe je veoma slabo, ima malo resursa. Ali mi smo oduvijek radili na ovaj način i stoga smo gledali prema domaćem protokolu.
Pošto smo radili na Go-u, bilo je jasno da nam treba Go drajver. Radio sam to skoro puno radno vrijeme - to je bio moj radni zadatak. Do određenog trenutka smo to iznosili i u principu niko nije očekivao da će to koristiti neko drugi osim nas. Zatim se CloudFlare pojavio sa potpuno istim problemom, i neko vrijeme smo radili vrlo glatko s njima, jer su imali iste zadatke. I to smo uradili i u samom ClickHouse-u i u drajveru.
U nekom trenutku sam jednostavno prestao da se bavim time, jer se moja aktivnost u ClickHouse-u i sa poslom malo promenila. Stoga pitanja nisu zatvorena. Povremeno, ljudi kojima je nešto potrebno sami se obavežu na spremište. Onda pogledam pull request i ponekad i sam nešto uredim, ali to se retko dešava.
Želim da se vratim vozaču. Prije nekoliko godina, kada je cijela ova stvar počela, ClickHouse je također bio drugačiji i sa drugačijim karakteristikama. Sada postoji razumijevanje kako prepraviti drajver tako da bude dobar. Ako se to dogodi, verzija 2 će ionako biti nekompatibilna zbog nakupljenih štaka.
Ne znam kako da ovo sredim. Ni ja nemam puno vremena. Ako neki ljudi završe vozača, mogu im pomoći i reći im šta da rade. Ali o aktivnom učešću Yandexa u razvoju projekta još se ni na koji način nije razgovaralo.
Aleksej Milovidov: Zapravo, oko ovih vozača još nema birokratije. Jedino što su premješteni u zvaničnu organizaciju, odnosno ovaj drajver je prepoznat kao službeno zadano rješenje za Go. Ima još nekih drajvera, ali dolaze zasebno.
Nemamo razvoj za ove drajvere unutra. Pitanje je da li možemo da angažujemo pojedinca, ne posebno za ovog pokretača, već za razvoj svih pokretača zajednice, ili možemo da nađemo nekog izvan.
Eksterni rječnik se ne pokreće nakon ponovnog pokretanja s uključenim lazy_load. sta da radim?
Imamo omogućenu postavku lazy_load, a nakon ponovnog pokretanja servera, sam rječnik se ne podiže. Podiže se tek nakon što korisnik pristupi ovom rječniku. I daje grešku pri prvom pozivu. Da li je moguće nekako automatski učitati rječnike koristeći ClickHouse, ili uvijek morate sami kontrolirati njihovu spremnost kako korisnici ne bi dobili greške?
Možda imamo staru verziju ClickHousea, pa se rečnik nije automatski učitao. Može li biti?
Prvo, rječnici se mogu prisilno učitati pomoću upita sistemsko ponovno učitavanje rječnika. Drugo, o grešci - ako je rječnik već učitan, onda će upiti raditi na podacima koji su učitani. Ako rječnik još nije učitan, tada će se učitati u trenutku zahtjeva.
Za teške rječnike to nije baš zgodno. Na primjer, trebate dohvatiti milion redova iz MySQL-a. Neko napravi jednostavan odabir, ali ovaj odabir će čekati isti milion redova. Ovdje postoje dva rješenja. Prvi je da isključite lazy_load. Drugi je kada se server podigne, prije nego što uključite opterećenje na njemu sistemski rečnik ponovnog učitavanja ili samo izvršite upit koji koristi rječnik. Tada će se učitati rječnik. Morate kontrolirati dostupnost rječnika s uključenom postavkom lazy_load, jer ih ClickHouse ne povlači automatski.
Odgovor na posljednje pitanje je ili je verzija stara ili je potrebno otkloniti greške.
Šta je sa činjenicom da sistemski ponovno učitavanje rječnika ne učitava nijedan od mnogih rječnika ako se barem jedan od njih sruši zbog greške?
Postoji još jedno pitanje o sistemskim rječnicima za ponovno učitavanje. Imamo dva rječnika - jedan nije učitan, drugi je učitan. Sistemski rečnik za ponovno učitavanje u ovom slučaju ne učitava nijedan rečnik, i morate od tačke do tačke učitati određeni po njegovom imenu koristeći sistemski rečnik za ponovno učitavanje. Da li je ovo povezano i sa verzijom ClickHouse?
Želim ugoditi. Ovo ponašanje se promijenilo. Dakle, ako ažurirate ClickHouse, i on će se promijeniti. Ako niste zadovoljni trenutnim ponašanjem sistemsko ponovno učitavanje rječnika, ažurirati, i nadajmo se da će se promijeniti na bolje.
Postoji li način da se konfiguriraju detalji u ClickHouse konfiguraciji, ali da se ne osvjetljavaju greške?
Sljedeće pitanje se odnosi na greške vezane za rječnik, odnosno detalje. U rečnik smo registrovali detalje veze u konfiguraciji ClickHouse, a u slučaju greške dobijamo te detalje i lozinku kao odgovor.
Ovu grešku smo riješili dodavanjem detalja u konfiguraciju ODBC drajvera. Postoji li neki način da se konfigurišu detalji u konfiguraciji ClickHouse, ali da se ti detalji ne prikazuju na greškama?
Ovdje je rješenje zaista - specificirati 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 sa MySQL, niti za ostale, ne biste trebali vidjeti lozinku u poruci o grešci. Za ODBC ću također pogledati - ako postoji takva stvar, samo je potrebno ukloniti.
Bonus: pozadine za Zumu sa druženja
Klikom na sliku za najupornije čitaoce otvaraju se bonus pozadine sa skupova. Gašenje požara zajedno sa Avitovim tehnološkim maskotama, savjetovanje sa kolegama iz sobe administratora sistema ili kompjuterskog kluba stare škole i održavanje dnevnog dana ispod mosta na pozadini grafita.
izvor: www.habr.com