V apríli sa inžinieri Avito zúčastnili online stretnutí s hlavným vývojárom ClickHouse Alexejom Milovidovom a Kirillom Shvakovom, vývojárom v jazyku Golang zo spoločnosti Integros. Diskutovali sme o tom, ako používame systém riadenia databáz a aké ťažkosti sa nám vyskytujú.
Na základe stretnutia sme zostavili článok s odpoveďami odborníkov na naše a divácke otázky týkajúce sa záloh, resharda dát, externých slovníkov, Golang ovládača a aktualizácie verzií ClickHouse. Môže byť užitočný pre vývojárov, ktorí už aktívne pracujú so SBD 'Yandex' a zaujímajú sa o jej súčasnosť a budúcnosť. Odpovede Alexeja Milovidova sú automaticky predvolené, ak nie je uvedené inak.
Pozor, pod katom je veľa textu. Dúfame, že obsah s otázkami vám pomôže sa orientovať.
Obsah
Ak sa vám nechce čítať text, môžete si pozrieť záznam posedávania . Časové kódy sú v prvom komentári pod videom.
ClickHouse sa neustále aktualizuje, ale naše dáta nie. Čo s tým robiť?
ClickHouse sa neustále aktualizuje, ale naše dáta, ktoré boli optimalizované, sa neaktualizujú a zostávajú v zálohe.
Predpokladajme, že sme mali nejaký problém a dáta sa stratili. Rozhodli sme sa obnoviť a zistilo sa, že staré partie, ktoré sú uložené na serveroch záloh, sa veľmi rozchádzajú s používanou verziou ClickHouse. Čo robiť v takej situácii a je to možné?
Situácia, v ktorej ste obnovili dáta zo zálohy v starom formáte, a na novej verzii sa nedajú pripojiť, nie je možná. Sledujeme, aby formát dát v ClickHouse bol vždy spätne kompatibilný. To je omnoho dôležitejšie ako spätá kompatibilita po funkčnosti, ak sa zmenilo správanie nejakej zriedkavo používané funkcie. Dáta, ktoré sú uložené na disku, by mala nová verzia ClickHouse vždy vedieť čítať. To je zákon.
Aké sú aktuálne najlepšie praktiky pre zálohovanie dát z ClickHouse?
Ako robiť zálohy so zohľadnením toho, že máme operácie optimalizácie, obrovskú databázu na terabajty a dáta, ktoré sa aktualizovali, povedzme, za posledné tri dni, a ďalej sa s nimi žiadne postupy nedejú?
Môžeme si vymyslieť vlastné riešenie a na báze napísať: zbieraj tieto zálohy takto a takto. Možno, že nič nevymyslieť netreba a bicykel je už dávno vynájdený?
Najprv o najlepších praktikách. Moji kolegovia vždy radia, aby na otázky o zálohách pripomínali službu „Yandex.Cloud“, kde je táto úloha už vyriešená. Takže ju využívajte, ak máte túto možnosť.
Neexistuje kompletné riešenie, ktoré by bolo na sto percent integrované do ClickHouse na zálohovanie. Existujú však niektoré šablóny, ktoré je možné použiť. Na dosiahnutie úplného riešenia bude potrebné buď trochu ručnej práce, alebo vytvoriť obaly vo forme skriptov.
Začnem s najjednoduchšími riešeniami a skončím s najzložitejšími v závislosti od objemu údajov a veľkosti klastrov. Čím väčší je klaster, tým zložitejšie riešenie je.
Ak tabuľka s údajmi zaberá iba niekoľko gigabajtov, zálohu môžete urobiť takto:
- Uložiť definície tabuliek, teda metadata — show create table.
- Vytvoriť dump pomocou klienta ClickHouse — select * from table do súboru. Predvolene dostanete súbor vo formáte TabSeparated. Ak chcete byť efektívnejší, môžete použiť formát Native.
Ak je objem údajov väčší, záloha zaberie viac času a veľa miesta. Toto sa nazýva logická záloha, nie je viazaná na formát údajov ClickHouse. Ak existuje, v krajnom prípade môžete vziať zálohu a importovať ju do MySQL na obnovenie.
Pre pokročilejšie prípady má ClickHouse zabudovanú možnosť vytvoriť snímku partícií v lokálnom súborovom systéme. Táto možnosť je dostupná vo forme dotazu alter table freeze partition. Alebo jednoducho alter table freeze — to je snímka celej tabuľky.
Snímka bude vytvorená konzistentne pre jednu tabuľku na jednom shard-e, teda nie je možné vytvoriť konzistentnú snímku celého klasteru týmto spôsobom. Pre väčšinu úloh však táto potreba nie je, stačí vykonať dotaz na každom sharde a získať konzistentnú snímku. Vytvára sa vo forme hardlinkov a preto nezaberá ďalšie miesto. Následne túto snímku skopírujete na zálohový server alebo do úložiska, ktoré používate na zálohy.
Obnovenie takejto zálohy je dosť jednoduché. Najprv — vytvoríte tabuľky podľa existujúcich definícií tabuliek. Potom skopírujete uložené snímky partícií do Directory-Detached pre dané tabuľky a vykonáte dotaz attach partition. Takéto riešenie je celkom vhodné pre najvážnejšie objemy údajov.
Niekedy potrebujete niečo ešte skvelejšie — v prípadoch, keď máte desiatky alebo aj stovky terabajtov na každom serveri a stovky serverov. Tu je riešenie, ktoré som odpozoroval od kolegov z "Yandex.Metriky". Odporúčam to nie každému — prečítajte si to a rozhodnite sa sami, či je to pre vás vhodné.
Najskôr je potrebné vytvoriť niekoľko serverov s veľkými diskovými poličkami. Potom na týchto serveroch spustiť niekoľko ClickHouse serverov a nastaviť ich tak, aby fungovali ako ďalšia replikácia pre tie isté shardy. A následne používať na týchto serveroch súborový systém alebo nejaký nástroj, ktorý umožňuje vytvárať snapshoty. Tu sú dve možnosti. Prvá možnosť — LVM snapshoty, druhá možnosť — ZFS na Linuxe.
Potom je potrebné každý deň vytvoriť snapshot, ten bude ležať a zaberá nejaké miesto. Samozrejme, ak sa údaje menia, časom sa objem miesta zvýši. Tento snapshot môžete vytiahnuť kedykoľvek a obnoviť údaje, také zvláštne riešenie. Navyše je potrebné obmedziť tieto repliky v konfigurácii, aby sa nesnažili stať lídrami.
Bude možné organizovať kontrolované oneskorenie replik v klastroch?
Tento rok plánujete vytvárať valy v ClickHouse. Bude možné v nich organizovať kontrolované oneskorenie replik? Chceli by sme s jeho pomocou zabezpečiť, aby sme sa chránili pred negatívnymi scenármi s alternáciami a inými zmenami.
Je možné urobiť nejaké roll back pre alternácie? Napríklad, v existujúcom vale povedať, že do tohto momentu aplikuj zmeny, a od tohto momentu prestanú zmeny aplikovať?
Ak do nášho klastru prišla skupina a rozbila ho, máme podmienenú replikáciu s hodinovým oneskorením, kde môžeme povedať, že áno, poďme ju skutočne používať v danom momente, ale posledných desať minút zmien v nej nebudeme aplikovať?
Najprv o kontrolovanom oneskorení replik. Takýto požiadavok od používateľov bol a vytvorili sme issue na Githube s prosbou: "Ak to niekto potrebuje, dajte like, dajte srdiečko". Nikto nedal, a issue bolo uzavreté. Napriek tomu už teraz je možné takúto funkciu získať nastavením ClickHouse. Pravda, len od verzie 20.3.
ClickHouse neustále na pozadí vykonáva zlúčenie dát — merge. Keď je merge vykonaný, súbor menších kusov dát je nahradený väčším kusom. Pri tom zostávajú predchádzajúce kusy dát na disku ešte nejaký čas.
Po prvé, ostávajú naďalej uložené dovtedy, pokiaľ existujú select dotazy, ktoré ich používajú, aby zabezpečili neblokujúcu prevádzku. Select dotazy bez problémov čítajú zo starých kusov.
Po druhé, existuje aj časový prah — staré kusy dát ležia na disku osem minút. Tieto osem minút je možné prispôsobiť a predĺžiť dokonca na jeden deň. To si však vyžiada miesto na disku: v závislosti od toku dát môže byť výsledkom, že za posledný deň sa dáta nielen zdvojnásobia, ale môžu byť aj päťkrát viac. Avšak pri vážnych problémoch môžete zastaviť ClickHouse server a všetko vyriešiť.
Teraz sa vynára otázka, ako to chráni pred alterami. Sem je potrebné sa pozrieť hlbšie, pretože v starších verziách ClickHouse alter fungoval tak, že jednoducho priamo menil kusy. Existuje kus dát s nejakými súbormi, a robíme, napríklad, alter drop column. Vtedy sa tento stĺpec fyzicky odstráni zo všetkých kusov.
Ale od verzie 20.3 bol mechanizmus alterov úplne zmenený a teraz sú kusy dát vždy nemenné. Vôbec sa nemenia — alteri teraz fungujú približne rovnako ako merge. Namiesto toho, aby sa kus menil na mieste, vytvárame nový. V novom kuse súbory, ktoré sa nezmenili, sú hardlinkami a ak sme odstránili nejaký stĺpec, jednoducho nebude prítomný v novom kuse. Starý kus bude podľa predvoleného nastavenia odstránený po ôsmich minútach a tu je možné upraviť nastavenia, o ktorých sa hovorilo vyššie.
Obdobne to platí aj pre alteri typu mutácií. Keď robíte alter delete alebo alter update, nemení sa kus, ale vytvára sa nový. A potom sa vymaže starý.
Čo robiť, ak sa zmenila štruktúra tabuľky?
Ako obnoviť zálohu, ktorá bola vytvorená so starou schémou? A druhá otázka o prípade so snapshotmi a prostriedkami súborového systému. Je tu Btrfs vhodné namiesto ZFS na Linux LVM?
Ak robíte attach partition Ak máte oddiely s inou štruktúrou, ClickHouse vám oznámi, že to nie je možné. Riešením je: najprv vytvorte dočasnú tabuľku typu MergeTree so starou štruktúrou, pripojte k nej údaje pomocou attach, vykonajte príkaz alter. Potom môžete buď skopírovať alebo preniesť tieto údaje a znova pripojiť, alebo použiť príkaz alter table move partition.
Teraz druhá otázka je, či je možné použiť Btrfs. Ak máte LVM, stačia vám snímky LVM a súborový systém môže byť aj ext4, nezáleží na tom. S Btrfs všetko závisí od vašich skúseností s jeho prevádzkovaním. Je to zrelý súborový systém, ale aj tak existujú určité pochybnosti o tom, ako to všetko bude fungovať v praxi v konkrétnom scenári. Neodporúčal by som to používať, ak nemáte Btrfs v prevádzke.
Aké sú aktuálne najlepšie praktiky v resharde dát?
Otázka o prestavbe shardov je zložitá a mnohostranná. Na to sa dá odpovedať viacerými spôsobmi. Môže sa povedať, že v ClickHouse nie je zabudovaná možnosť prestavby shardov. Ale obávam sa, že táto odpoveď nikoho neuspokojí. Takže môžeme povedať, že v ClickHouse existuje veľa spôsobov prestavby údajov.
Ak sa končí miesto na klastri alebo nezvláda záťaž, pridávate nové servery. Ale tieto servery sú predvolene prázdne, na nich nie sú žiadne údaje a neexistuje žiadna záťaž. Musíte presunúť údaje, aby sa rovnomerne rozložili po novom, väčšom klastri.
Prvý spôsob, ako to urobiť, je skopírovať časť oddielov na nové servery pomocou príkazu alter table fetch partition. Napríklad, mali ste oddiely podľa mesiacov, a vy vezmete prvý mesiac roka 2017 a skopírujete ho na nový server, potom - tretí mesiac skopírujete na nejaký ďalší nový server. A tak robíte, kým sa to nestane viac-menej rovnomerné.
Presun môže prebiehať len pre tie oddiely, ktoré sa pri zápise nemenia. Pre čerstvé oddiely bude nutné vypnúť zápis, pretože ich presun nie je atomárny. Inak získate duplikáty alebo medzery v údajoch. Napriek tomu je tento spôsob praktický a funguje dostatočne efektívne. Po sieti sa prenášajú už pripravené komprimované oddiely, takže údaje nie sú znovu komprimované ani dekódované.
Tento způsob má jednu nevýhodu, a to závisí na schématu shardování, zda jste na toto schéma shardování spolehli, jaký jste měli klíč shardování. Ve vašem příkladu pro případ s metrikami je klíč shardování hash cesty. Když provádíte select na distribuovanou tabulku, jde to okamžitě na všechny shardy clusteru a vybírá se odtud data.
To znamená, že pro vás ve skutečnosti nezáleží na tom, jaká data se nacházejí na kterém shardu. Hlavní je to, že data podle jedné cesty se nacházejí na jednom shardu, a není důležité, na kterém konkrétně. V tomto případě je přenos hotových partií skvělý, protože při select dotazech dostáváte plné údaje jak před pře-shardováním, tak po něm, schéma hodnot je víceméně bez významu.
Ale někdy se vyskytují i složitější situace. Pokud na úrovni logiky aplikace spoléháte na speciální schéma shardování, kde je tento klient umístěn na určitém shardu, a požadavek lze okamžitě poslat tam, nikoliv do distribuované tabulky. Nebo používáte dostatečně čerstvou verzi ClickHouse a povolili jste nastavení optimize skip unused shards. V tomto případě během select dotazu bude výraz v sekci where analyzován a bude vypočítáno, na které shardy je třeba jít podle schématu shardování. To funguje za podmínky, že data jsou rozdělena přesně podle tohoto schématu shardování. Pokud jste je přeložili ručně, shoda se může změnit.
Takže, to je způsob číslo jedna. A čekám na vaši odpověď, zda tento způsob vyhovuje, nebo jdeme dál.
Vladimir Kolobaev, lead system administrator na Avito: Alexei, způsob, který jste zmínil, se příliš nehodí, když je třeba rozložit zátěž i na čtení. Můžeme vzít měsíc starou partii a předchozí měsíc přesunout na jinou node, ale když přijde žádost o tato data, budeme zatěžovat pouze tuto. A chtěli bychom zatěžovat celý cluster, protože jinak veškerá zátěž na čtení bude zpracovávána pouze dvěma shardy.
Alexei Milovidov: Odpoveď je tu zvláštna — áno, je to zlé, ale môže to aj prejsť. Vysvetlím, ako presne. Je potrebné sa pozrieť na scenár zaťaženia, ktorý prichádza za vašimi dátami. Ak ide o dáta monitorovania, tak takmer určite môžeme povedať, že prevládajúca väčšina požiadaviek prichádza po čerstvých údajoch.
Nainštalovali ste nové servery, presunuli ste staré oddiely, ale zároveň ste zmenili spôsob, akým sa zapisujú čerstvé dáta. A čerstvé dáta budú rozložené po celom klasteri. Takže už po piatich minútach požiadavky za posledných päť minút budú rovnomerne zaťažovať klaster, po dni budú požiadavky za deň rovnomerne zaťažovať klaster. A požiadavky za predchádzajúci mesiac, bohužiaľ, pôjdu len na časť serverov v klastri.
Ale často nebudete mať požiadavky za február 2019. Pravdepodobne, ak už požiadavky prichádzajú do roku 2019, budú sa týkať celého roka 2019 — za dlhší interval času, a nie za nejaký malý rozsah. A takéto požiadavky tiež dokážu rovnomerne zaťažiť klaster. Ale vo všeobecnosti je vaša poznámka úplne správna, že je to také ad hoc riešenie, ktoré nerozdeľuje dáta úplne rovnomerne.
Mám ešte niekoľko bodov na odpoveď na otázku. Jeden z nich je o tom, ako pôvodne nastaviť schému shardovania tak, aby prešardovanie spôsobilo menej problémov. To nie je vždy možné.
Napríklad máte dáta monitorovania. Dáta monitorovania rastú z troch dôvodov. Prvý — akumulácia historických dát. Druhý — rast prevádzky. A tretí — zvyšovanie počtu vecí, ktoré podliehajú monitorovaniu. Objavujú sa nové mikro služby a metriky, ktoré je potrebné uchovávať.
Je možné, že z nich najväčší rast súvisí práve s treťou príčinou — to je zvýšené využívanie monitorovania. A v takom prípade je dôležité sa pozrieť na charakter zaťaženia, aké sú hlavné požiadavky na select. Hlavné požiadavky na select pravdepodobne budú vychádzať z nejakého podmnožstva metrík.
Napríklad použitie CPU na niektorých serveroch nejakou službou. Ukazuje sa, že existuje určitá podmnožina kľúčov, podľa ktorých tieto údaje získavate. A samotný dotaz na tieto údaje je pravdepodobne dosť jednoduchý a vykonáva sa za desiatky milisekúnd. Používa sa na monitornie služieb a pre dashboardy. Dúfam, že to chápem správne.
Vladimir Kolobaev: Ide o to, že veľmi často apelujeme na historické údaje, pretože v reálnom čase porovnávame aktuálny stav s historickým. A pre nás je dôležité mať rýchly prístup k veľkému objemu údajov, a ClickHouse s tým výborne zvláda.
Máte úplnú pravdu, väčšinu dotazov na čítanie zažívame za posledný deň, tak ako každá monitorovacia sústava. Ale zároveň je na historické údaje aj taktiež značná záťaž. Pochádza hlavne zo systému alertingu, ktorý každých tridsať sekúnd chodí a hovorí ClickHouse: „Vydaj mi údaje za posledných šesť týždňov. A teraz mi z nich vytvor nejaký kĺzavý priemer a porovnaj aktuálnu hodnotu s historickou.“
Chcel by som povedať, že pre také veľmi čerstvé dotazy existuje ešte jedna malá tabuľka, v ktorej uchovávame iba dva dni údajov a hlavné dotazy smerujú tam. Do veľkej shardovanej tabuľky posielame len veľké historické dotazy.
Alexei Milovidov: Žiaľ, pre vašu situáciu to vychádza zle, ale poviem opis dvoch zlých a zložitých schém shardovania, ktoré by nemali byť používané, ale ktoré sa používajú v službe mojich priateľov.
Existuje hlavný klaster s udalosťami „Yandex.Metriky“. Udalosti sú zobrazenia stránok, kliknutia a prechody. Väčšina dotazov smeruje k konkrétnemu webovému sídlu. Otvoríte službu „Yandex.Metrika“, máte stránku — avito.ru, vstúpite do správy a ide dotaz na vašu stránku.
Ale sú aj iné dotazy — analytické a globálne, ktoré robia interní analytici. Pre každý prípad poznamenám, že interní analytici robia dotazy iba na služby „Yandexu“. Ale aj tak služby „Yandexu“ zaberajú podstatný podiel zo všetkých údajov. Ide o dotazy nie na konkrétne počítadlá, ale na širšiu filtráciu.
Ako usporiadať dáta tak, aby všetko fungovalo efektívne aj na jednom počítači, aj globálne požiadavky? Ďalšia zložitá úloha spočíva v tom, že počet požiadaviek v ClickHouse na klaster „Metódy“ je niekoľko tisíc za sekundu. Pri tom sú tu netriviálne požiadavky, napríklad niekoľko tisíc za sekundu jeden server ClickHouse nezvládne.
Veľkosť klastru je viac ako šesťsto serverov. Ak nad týmto klastrom jednoducho natiahneme distribuovanú tabuľku a posielame tam niekoľko tisíc požiadaviek, situácia bude ešte horšia, ako posielať ich na jeden server. Na druhej strane, možnosť, že sú dáta rozložené rovnomerne a my sa obraciame so všetkými servermi, hneď zamietame.
Existuje diametrálne opačná možnosť. Predstavte si, ak by sme dáta shardovali podľa stránok, tak požiadavka pre jednu stránku pôjde na jeden shard. Teraz klaster bude schopný zvládnuť desaťtisíc požiadaviek za sekundu, ale na jednom shardu bude nejaká požiadavka fungovať príliš pomaly. Už sa nebude rozširovať podľa priepustnosti. Obzvlášť ak ide o stránku avito.ru. Neodhalím žiadne tajomstvo, ak poviem, že Avito je jednou z najnavštevovanejších stránok v ru-netu. A spracovávať ju na jednom shardu by bolo šialenstvo.
Preto je schéma shardovania usporiadaná zložitejším spôsobom. Celý klaster je rozdelený na niekoľko klastroch, ktoré nazývame vrstvami. Uvnitř každého klastrochu je od desiatok po niekoľko desiatok shardov. A celkovo je takých klastroch tridsaťdeväť.
Ako sa to celé škáluje? Počet klastroch sa nezmenil - ako bolo pred niekoľkými rokmi tridsaťdeväť, tak to zostalo. Ale vo vnútri každého z nich postupne zvyšujeme počet shardov, ako sa hromadia dáta. A schéma shardovania celkovo vyzerá takto - rozdelenie na tieto klastroch prebieha podľa webových stránok, a na to, aby sa zistilo, ktorá stránka je na ktorom klastri, sa používa úplne samostatná metadáta v MySQL. Jedna stránka - v jednom klastri. A vo vnútri neho prebieha shardovanie podľa identifikátorov návštevníkov.
Pri nahrávaní ich rozdeľujeme podľa zvyšku po vydelení identifikátora návštevníka. Ale pri pridávaní nového shardu sa schéma šardovania mení, naďalej rozdeľujeme, ale pri zvyšku po vydelení iným číslom. To znamená, že jeden návštevník je už na viacerých serveroch a na to sa nemožno spoliehať. Je to urobené výlučne na to, aby sa údaje lepšie komprimovali. A pri dopytoch ideme do Distributed tabuľky, ktorá sa pozerá na klaster a oslovuje desiatky serverov. Takáto zložitá schéma.
Ale môj príbeh bude neúplný, ak nepoviem, že od tejto schémy sme sa vzdali. V novej schéme sme všetko zmenili a všetky údaje skopírovali s pomocou clickhouse-copier.
V novej schéme sú všetky stránky rozdelené do dvoch kategórií - veľké a malé. Neviem, ako bol určený prah, ale nakoniec to dopadlo tak, že veľké stránky sú zapisované na jeden klaster, kde je 120 shardov po troch replikách na každom - teda 360 serverov. A schéma šardovania je taká, že akýkoľvek dopyt ide okamžite na všetky shardy. Ak teraz v 'Yandex.Metrike' otvoríte akúkoľvek stránku správy pre avito.ru, dopyt pôjde na 120 serverov. Veľkých stránok v Runete je málo. A dopyty nie sú tisíc za sekundu, ale dokonca menej ako stovka. Všetko to pokojne spracováva Distributed tabuľka, ktorú každý z nich spracováva 120 servermi.
A druhý klaster - pre malé stránky. Tu je schéma šardovania podľa identifikátora stránky, a každý dopyt ide presne na jeden shard.
V ClickHouse je nástroj clickhouse-copier. Môžete nám o ňom povedať?
I hneď poviem, že toto riešenie je viac zložitým a trochu menej výkonným. Výhodou je, že úplne rozloží údaje podľa tej schémy, ktorú uvediete. Ale nevýhodou nástroja je, že vôbec nerobí prešardovanie. Kopíruje údaje z jednej schémy klasteru do druhej schémy klasteru.
To znamená, že pre jej fungovanie musíte mať dva klastre. Môžu byť umiestnené na rovnakých serveroch, ale aj tak údaje nebudú presúvané inkrementálne, ale budú skopírované.
Napríklad, bolo štyri servery, stalo sa osem. Vytvárate na všetkých serveroch novú distribuovanú tabuľku, nové lokálne tabuľky a spúšťate clickhouse-copier, pričom mu určujete schému práce, že musí čítať odtiaľ, prevziať novú schému shardovania a prenášať údaje tam. Na starých serveroch budete potrebovať miesto o 50 % viac, než je teraz, pretože staré údaje musia zostať na nich, a navyše na ne príde polovica týchto starých údajov. Ak ste v predstihu premýšľali o tom, že údaje treba prešardovať a je tam miesto, potom je tento spôsob vhodný.
Ako je vnútorné usporiadaný clickhouse-copier? Rozdelí celú prácu na súbor úloh spracovania jednej partition jednej tabuľky na jednom shard. Všetky tieto úlohy môžu prebiehať paralelne a clickhouse-copier môže byť spustený na rôznych strojoch v niekoľkých inštanciách, ale to, čo robí pre jednu partition — to nie je nič iné ako insert select. Údaje sa čítajú, dekomprimujú, prepíšu, potom sa znovu komprimujú a zapisujú niekam, pretriedia sa. Je to ťažšie riešenie.
Mali ste pilotný projekt, ktorý sa volal resharding. Čo je s tým?
Ešte ste mali v roku 2017 pilotnú vec, ktorá sa volala rešarding. Existuje dokonca aj možnosť v ClickHouse. Rozumiem, že to nevyšlo. Môžete povedať, prečo sa to takto stalo? Vyzeralo to, že by to bolo veľmi aktuálne.
Celý problém spočíva v tom, že pri potrebe prešardovať údaje na mieste je potrebná dosť zložitá synchronizácia na to, aby sa to dalo urobiť atomárne. Keď sme začali zisťovať, akým spôsobom je táto synchronizácia usporiadaná, bolo jasné, že existujú fundamentálne problémy. A tieto fundamentálne problémy nie sú len teoretické, ale už sa tiež okamžite ukazovali v praxi vo forme, ktorú je možné veľmi jednoducho vysvetliť — nič nefunguje.
Môžu byť všetky časti dát zlúčené do jedného pred presunom na pomalé disky?
Otázka o TTL s možnosťou presunúť na pomalý disk v kontexte merge. Existuje spôsob, okrem cron-u, zlúčiť všetky časti do jednej pred presunom na pomalé disky?
Odpoveď na otázku, či je možné automaticky zlúčiť všetky kusy do jedného pred ich presunom — nie. Zdá sa mi, že na tom nie je potrebné trvať. Nie je potrebné zlúčiť všetky časti do jednej, stačí počítať s tým, že budú automaticky prenášané na pomalé disky.
Máme dve kritériá pravidiel presunu. Prvé – na základe zaplnenia. Ak je na aktuálnej úrovni úložiska menej ako určitý percentuálny podiel voľného miesta, vyberieme jeden kus a presunieme ho na pomalšie úložisko. Skôr nie pomalšie, ale nasledujúce – ako to nastavíte.
Druhé kritérium – podľa veľkosti. Ide o presun veľkých kusov. Môžete upraviť prah voľného miesta na rýchlom disku, a dáta budú presúvané automaticky.
Ako prechádzať na nové verzie ClickHouse, ak nie je možné vopred skontrolovať kompatibilitu?
Táto téma sa pravidelne diskutuje s ohľadom na rôzne verzie, a predsa. Aké bezpečné je aktualizovať z verzie 19.11 na 19.16 a napríklad z 19.16 na 20.3? Aký je najlepší spôsob, ako prejsť na nové verzie, keď nie je možné vopred skontrolovať kompatibilitu v pieskovisku?
Tu sú niektoré "zlaté" pravidlá. Prvé – . Je rozsiahly, ale sú tam jednotlivé body o spätne nekompatibilných zmenách. Nemali by ste sa k týmto bodom stavať ako k červenému flašky. Zvyčajne ide o drobné nekompatibility, ktoré sú spojené s niektorou okrajovou funkčnosťou, ktorú pravdepodobne nepoužívate.
Druhé – ak nie je možné skontrolovať kompatibilitu v pieskovisku, a chcete sa aktualizovať okamžite v produkcii, odporúčanie je také – nerobte to. Najprv vytvorte pieskovisko a otestujte. Ak nemáte testovacie prostredie, pravdepodobne nie ste veľmi veľká spoločnosť, a teda môžete skopírovať časť dát na svoj laptop a na ňom sa uistiť, že všetko funguje správne. Môžete dokonca spustiť niekoľko replik lokálne na svojom počítači. Alebo môžete niekde blízko spustiť novú verziu a nahrať tam časť dát – teda vytvoriť improvizované testovacie prostredie.
Ešte jedno pravidlo – neaktualizujte sa počas týždňa po vydaní verzie z dôvodu odhaľovania chýb v produkcii a následných rýchlych opráv. Poďme si rozobrať číslovanie verzií ClickHouse, aby sme sa nestratili.
Existuje verzia 20.3.4. Číslo 20 označuje rok vydania — 2020. Z hľadiska toho, čo je vo vnútri, to nemá žiadny význam, takže sa na to nebudeme sústrediť. Ďalej — 20.3. Druhé číslo — v tomto prípade 3 — zvyšujeme zakaždým, keď vydáme release s nejakou novou funkčnosťou. Ak chceme pridať do ClickHouse nejakú možnosť, sme povinní zvýšiť toto číslo. To znamená, že vo verzii 20.4 sa ClickHouse stane ešte lepším. Tretie číslo — 20.3.4. Tu 4 znamená počet patch-releasov, v ktorých sme nové možnosti nepridávali, ale opravovali nejaké chyby. A 4 znamená, že sme to urobili štyrikrát.
Nehovorte si, že je to niečo desivé. Zvyčajne si používateľ môže nainštalovať najnovšiu verziu a tá bude fungovať bez problémov s uptime na rok. Ale predstavte si, že v nejakej funkcii na spracovanie bitmapov, ktorá bola pridaná našimi čínskymi kolegami, sa server zrúti pri prenose nesprávnych argumentov. Musíme to opraviť. Vydáme novú patch-verziu a ClickHouse sa stane stabilnejším.
Ak máte ClickHouse v produkcii a vyjde nová verzia ClickHouse s ďalšími funkciami — napríklad 20.4.1 — najprv sa neponáhľajte nainštalovať ju do produkcie hneď prvý deň. Načo je to vôbec potrebné? Ak ešte nevyužívate ClickHouse, môžete si ho nainštalovať a pravdepodobne všetko bude v poriadku. Ale ak ClickHouse už stabilne funguje, sledujte patche a aktualizácie — aké problémy opravujeme.
Kiril Švakov: Chcem sa trochu rozšíriť o testovacích prostrediach. Všetci sa veľmi boja testovacích prostredí a nejako si myslia, že ak máte veľmi veľký klaster ClickHouse, tak aj testovacia prostredie by mala byť minimálne rovnaká alebo aspoň desaťkrát menšia. To vôbec nie je pravda.
Môžem povedať z vlastnej skúsenosti. Mám projekt, v ktorom je ClickHouse. Naša testovacia prostredie preň — to je malý virtuálny server v Hetzner za dvadsať eur, kde je absolútne všetko nasadené. Aby sme to mohli spraviť, máme úplnú automatizáciu v Ansible, a preto v podstate nie je žiadny rozdiel, či nasadzujeme na železné servery alebo len rozbehne vo virtualkách.
Čo môžete urobiť? Bolo by dobré pridať do dokumentácie ClickHouse príklad, ako si nasadiť malý klastrom – v Dockeri, v LXC, a možno vytvoriť Ansible playbook, pretože rôzni ľudia majú rôzne nasadenia. To by veľmi uľahčilo prácu. Keď nastavíte klaster za päť minút, je oveľa jednoduchšie sa s ním zoznámiť. Je to oveľa pohodlnejšie, pretože nasadiť do produkcie verziu, ktorú ste netestovali – to je cesta nikam. Niekedy to funguje, niekedy nie. A preto dúfať v úspech nie je dobré.
Maxim Kotjakov, senior backend engineer Avito: Trochu doplním o testovacích prostrediach z problematiky veľkých spoločností. Máme plnohodnotný akceptačný klaster ClickHouse, ktorý je presnou kópiou toho, čo máme v produkcii, pokiaľ ide o dátové schémy a nastavenia. Tento klaster je nasadený v dosť slabých kontajneroch s minimom zdrojov. Zapisujeme doň určitý percentuálny podiel z produkčných dát, našťastie máme možnosť replikovať tok v Kafke. Všetko je synchronizované a škálované – čo sa týka výkonu a toku, a teoreticky by sa malo správať podľa metrík ako produkcia. Všetko potenciálne výbušné najprv ide na tento testovací stojan a niekoľko dní tam zreje do pripravenosti. Ale samozrejme, toto riešenie je nákladné, ťažké a vyžaduje si nejaké náklady na údržbu.
Alexei Milovidov: Poviem, čo predstavuje testovacie prostredie našich priateľov z „Yandex.Metriky“. Jeden klaster mal viac ako 600 serverov, druhý 360, a je tu ešte tretí a niekoľko klastrov. Testovacie prostredie pre jeden z nich – to sú jednoducho dva shard-y s dvoma replikami v každom. Prečo dva shard-y? Aby nebol len jeden. A repliky sú taktiež potrebné. Jednoducho určité minimálne množstvo, ktoré si môžete dovoliť.
Toto testovacie prostredie umožňuje overiť funkčnosť dotazov a či sa niečo veľké nepokazilo. Ale často sa objavujú problémy úplne iného charakteru, keď všetko funguje, ale existujú určité drobné zmeny v zaťažení.
Príklad. Rozhodli sme sa nainštalovať novú verziu ClickHouse. Tá je nahraná na testovacej ploche, prešli sme automatizovanými testami v samotnej „Yandex.Metrike“, ktoré porovnávajú dáta na starej verzii a na novej, pričom pretiahli celý proces. A samozrejme, zelené testy nášho CI. Inak by sme túto verziu ani neponúkli.
Všetko je skvelé. Začíname prechádzať do produkcie. Dostávam správu, že na grafoch sa záťaž zvýšila niekoľkokrát. Vraciame verziu späť. Pozerám sa na graf a vidím: záťaž sa skutočne zvýšila počas nasadenia a opäť klesla, keď sme verziu nasadili. Potom sme začali vracať verziu. A záťaž sa rovnako zvýšila a rovnako opäť klesla. Takže záver je taký — záťaž sa zvýšila v súvislosti s nasadením, nič prekvapujúce.
Ďalej bolo ťažké presvedčiť kolegov, aby nakoniec nainštalovali novú verziu. Hovorím: „Všetko je v poriadku, nasadzujte. Držte palce, všetko bude fungovať. Teraz sa zvýšila záťaž na grafoch, ale všetko je v poriadku. Držte sa“. V podstate sme to tak spravili, a všetko — verzia bola nasadená do produkcie. Ale pri každom nasadení sa objavujú podobné problémy.
Kill query by mal zabiť požiadavky, ale nerobí to. Prečo?
Prišiel za mnou používateľ, nejaký analytik, a vytvoril určité požiadavky, ktoré položili môj klaster ClickHouse. Niekolko uzlov alebo celý klaster — v závislosti od toho, do ktorej repliky alebo shardu požiadavka zasiahla. Vidím, že všetky zdroje CPU na tomto serveri sú na maxime, všetko červené. Pri tom samotný ClickHouse na požiadavky odpovedá. A píšem: „Ukáž mi, prosím, procesný zoznam, ktorá požiadavka spôsobila tento chaos“.
Nachádzam túto požiadavku a píšem mu kill. A vidím, že sa nič nedeje. Môj server je na maxime, ClickHouse stále odpovedá na niektoré príkazy, ukazuje, že server žije a všetko je v poriadku. Ale mám degráciu vo všetkých používateľských požiadavkách, začína sa degradácia pri zápise v ClickHouse a môj kill query nefunguje. Prečo? Myslel som, že kill query by malo zabiť požiadavky, ale to sa nedeje.
Teraz bude celkom zvláštna odpoveď. Vec je taká, že kill query nezabíja požiadavky.
Kill query nastavuje malú zástavku s názvom „chcem, aby bola táto požiadavka zrušená“. A samotná požiadavka pri spracovaní každého bloku sa pozerá na túto zástavku. Ak je nastavená, požiadavka prestane pracovať. Takže, nikto požiadavku nezabíja, ona sama musí všetko skontrolovať a zastaviť sa. A toto by malo fungovať vo všetkých prípadoch, keď sa požiadavka nachádza v stave spracovania blokov údajov. Spracuje nasledujúci blok údajov, skontroluje zástavku a zastaví sa.
Toto nefunguje v prípadoch, keď je požiadavka zablokovaná pri nejakej operácii. Pravda, pravdepodobne to nie je váš prípad, pretože podľa vašich slov používa veľa serverových zdrojov. Možno, že to nefunguje pri vonkajšom triedení a ešte v niektorých detailoch. Ale vo všeobecnosti by to tak byť nemalo, je to chyba. A jediné, čo môžem odporučiť, je aktualizovať ClickHouse.
Ako vypočítať čas odpovede pri čítacej záťaži?
Existuje tabuľka, v ktorej sú uložené agregáty podľa item – rôzne počítadlá. Počet riadkov – približne sto miliónov. Je možné počítať s predvídateľným časom odpovede, ak sa nalieva 1K RPS na 1K itemov?
Súdiac podľa kontextu, ide o čítaciu záťaž, pretože na zápis nie sú žiadne problémy – môžete vkladať tisíce, dokonca aj stotisíce, a niekedy aj niekoľko miliónov riadkov.
Čítacie požiadavky môžu byť veľmi rôzne. V select 1 môže ClickHouse vykonávať okolo desiatich tisíc požiadaviek za sekundu, takže aj požiadavky na jeden kľúč už vyžadujú isté zdroje. A také bodové požiadavky budú zložitejšie ako v nejakých key-value databázach, pretože na každé čítanie je potrebné prečítať blok dát podľa indexu. Index u nás adresuje nie každú záznam, ale každý rozsah. Teda je potrebné prečítať celý rozsah – to je 8192 riadkov podľa predvolenia. A bude potrebné decomprimovať komprimovaný blok dát z 64 KB na 1 MB. Zvyčajne také bodové požiadavky trvajú od niekoľkých milisekúnd. Ale to je najjednoduchšia varianta.
Poďme sa pokúsiť urobiť jednoduchú aritmetiku. Ak vynásobíte niekoľko milisekúnd tisíc, dostanete niekoľko sekúnd. Ako keby sa nedalo udržať tisíc požiadaviek za sekundu, ale v skutočnosti je to možné, pretože máme viacero procesorových jadier. Takže v princípe ClickHouse niekedy dokáže udržať 1000 RPS, ale pri krátkych požiadavkách, presne tých bodových.
Ak potrebujete škálovať klaster ClickHouse z hľadiska počtu jednoduchých požiadaviek, odporúčam najjednoduchšie – zvýšiť počet replik a posielať požiadavky na náhodnú replikáciu. Ak jedna replikácia udržiava päťsto požiadaviek za sekundu, čo je úplne realistické, tri repliky zvládnu jednu a pol tisíca.
Niekedy, samozrejme, je možné nastaviť ClickHouse na maximálny počet bodových čítaní. Čo na to potrebujete? Najprv je potrebné znížiť granularitu indexu. Pri tom by sa mala znižovať nie na jednotku, ale na základe toho, že počet záznamov v indexe bude niekoľko miliónov alebo desiatok miliónov na server. Ak má tabuľka sto miliónov riadkov, ako granularitu môžete nastaviť 64.
Môžete znížiť veľkosť komprimovaného bloku. Na to sú dostupné nastavenia min compress block size, max compress block size. Môžete ich znížiť, preenať dáta a potom budú bodové dotazy rýchlejšie. Ale aj tak ClickHouse nie je databáza typu key-value. Veľké množstvo malých dotazov je antipattern zaťaženia.
Kiril Švakov: Dám radu na prípad, ak tam sú bežné účetní. Je to dosť štandardná situácia, keď ClickHouse uchováva nejaký čítač. Mám používateľa, je z takej krajiny, je tam ešte nejaké tretie pole a potrebujete inkrementálne niečo zvyšovať. Beriete MySQL, robíte unikátny kľúč - v MySQL je to duplicate key, v PostgreSQL je to conflict - a pridávate plusom. To bude fungovať oveľa lepšie.
Keď máte málo dát, nemá zmysel používať ClickHouse. Existujú bežné databázy a tie s tým dobre zvládajú.
Čo vylepšiť v ClickHouse, aby bolo viac dát v cache?
Predstavme si situáciu - na serveroch je 256 GB RAM, v dennej rutine ClickHouse berie približne 60-80 GB, v maxime až do 130. Čo môžete zapnúť a vylepšiť, aby bolo viac dát v cache a, logicky, menej prístupov na disk?
Zvyčajne operačný systém dobre zvláda túto úlohu s page cache. Ak otvoríte jednoducho top, pozriete sa tam na cached alebo free - je tam tiež napísané, koľko je zakcached - môžete si všimnúť, že celé voľné pamäť je použité pod cache. A tieto dáta pri čítaní budú čítané nie z disku, ale z RAM. Môžem tiež povedať, že cache sa efektívne používa, pretože sa cacheujú práve komprimované dáta.
Napriek tomu, ak chcete urýchliť niektoré jednoduché dotazy ešte viac, je možné zapnúť vo vnútri ClickHouse cache v rozcompressovaných dátach. Toto sa volá uncompressed cache. V konfiguračnom súbore config.xml nastavte veľkosť nekomprimovanej cache na požadovanú hodnotu – odporúčam nie viac ako polovicu dostupnej RAM, pretože zvyšok pôjde na page cache.
Okrem toho existujú dve nastavenia úrovne požiadaviek. Prvé nastavenie je použiť nekomprimovanú cache – zapína jej používanie. Odporúča sa ju zapnúť pre všetky požiadavky, okrem ťažkých, ktoré môžu prečítať všetky dáta a týmto vymazať túto cache. A druhé nastavenie je niečo ako maximálny počet riadkov pre používanie cache. Automaticky obmedzuje veľké požiadavky, aby prechádzali mimo cache.
Ako nastaviť storage_configuration pre uchovávanie v pamäti?
V novej dokumentácii ClickHouse som našiel časť súvisiacu . V opise je príklad s rýchlym SSD.
Zaujímavé, ako je možné nakonfigurovať to isté s objemovou horúcou pamäťou. A ešte jedna otázka. Ako funguje select s takouto organizáciou dát, či bude čítať celú množinu alebo iba tú, ktorá leží na disku, a či sú tieto dáta komprimované v pamäti? A ako funguje sekcia prewhere na takejto organizácii dát?
Toto nastavenie ovplyvňuje ukladanie blokov dát, a ich formát sa nijako nemení.
Poďme sa na to pozrieť podrobnejšie.
Uloženie dát v pamäti sa dá nastaviť. Všetko, čo sa konfiguruje pre disk, je jeho cesta. Vytvoríte tmpfs oddiel, ktorý je pripojený na nejakú cestu v súborovom systéme. Uvediete túto cestu ako cestu pre ukladanie údajov pre najhorúcejší oddiel, tam začnú prichádzať a zapisovať sa bloky dát, všetko je v poriadku.
Ale neodporúčam to robiť kvôli nízkej spoľahlivosti, aj keď, ak máte minimálne tri replíky v rôznych dátových centrách, je to možné. Ak sa niečo stane, údaje sa obnovia. Predpokladajme, že server sa zrazu vypol a znova zapol. Oddiel sa znovu pripojil, ale tam je prázdnota. Server ClickHouse pri spustení vidí, že mu tieto bloky chýbajú, hoci podľa metadát ZooKeeper by mali byť. Pozrie sa, na ktorých replikách sú, požiada ich a stiahne. Takto sa údaje obnovia.
Z tohto pohľadu sa ukladanie dát v pamäti zásadne nelíši od ich ukladania na disku, pretože pri uložení dát na disk sa najprv dostanú do stránkovacej cache a fyzicky sa zaznamenávajú oneskorene. To závisí od variantu pripojenia súborového systému. Ale pre každý prípad poviem, že ClickHouse nerobí fsync pri insert.
Pri tom sa dáta v pamäti ukladajú presne v tom istom formáte, ako na disku. Dotaz select presne takisto vyberá bloky, ktoré je potrebné čítať, vyberá potrebné rozsahy dát a číta ich. A prewhere funguje úplne rovnako, bez ohľadu na to, či boli dáta v pamäti alebo na disku.
Do akého počtu unikátnych hodnôt je Low Cardinality efektívny?
Low Cardinality je chytro navrhnutý. Tvorí dátové slovníky, ale tie sú lokálne. Po prvé, sú to vlastné slovníky pre každý blok, po druhé, aj v rámci jedného bloku môžu byť rôzne pre každý rozsah. Keď počet unikátnych hodnôt dosiahne prahovú hodnotu – podľa môjho názoru jeden milión – slovník sa jednoducho uloží a vytvorí sa nový.
Odpoveď v celku: pre každý lokálny rozsah – povedzme, pre každý deň – do približne jedného milióna unikátnych hodnôt je Low Cardinality efektívny. Potom nastane len fallback, pri ktorom sa použije veľa rôznych slovníkov, nie jeden. Bude to fungovať približne tak isto, ako obyčajný stĺpec typu string, možno trochu menej efektívne, ale k vážnemu zhoršeniu výkonu nedôjde.
Aké sú najlepšie praktiky pre full-textové vyhľadávanie v tabuľke s piatimi miliardami riadkov?
Existujú rôzne možnosti odpovede. Prvá je povedať, že ClickHouse nie je systém pre fulltextové vyhľadávanie. Na to existujú špeciálne systémy, napríklad, a . Napriek tomu sa čoraz častejšie stretávam s ľuďmi, ktorí hovoria, že prechádzajú z Elasticsearch na ClickHouse.
Prečo sa to deje? Vysvetľujú to tým, že Elasticsearch prestáva zvládať zaťaženie pri určitých objemoch, počínajúc tým, čo sa týka budovania indexov. Indexy sa stávajú príliš objemnými a ak sa jednoducho prenesú dáta do ClickHouse, ukáže sa, že sú uložené niekoľkonásobne efektívnejšie z pohľadu objemu. Pri tom vyhľadávacie dotazy často neboli také, že je potrebné nájsť v celom objeme dát nejakú frázu s ohľadom na morfológiu, ale úplne iné. Napríklad nájsť za posledné niekoľko hodín v logoch podľa nejakej podradenej sekvencie bajtov.
V tomto prípade vytvoríte v ClickHouse index, ktorým prvým poľom bude dátum so časom. Najväčšie obmedzenie dát bude práve podľa rozsahu dátumov. Vnútri vybraného rozsahu dátumov sa už zvyčajne dá vykonať fulltextové vyhľadávanie aj brute-force metódou pomocou like. Operátor like v ClickHouse je najefektívnejší like operátor, aký môžete nájsť. Ak nájdete lepší, dajte mi vedieť.
Ale like je aj tak full scan. A full scan môže byť pomalý nielen kvôli CPU, ale aj kvôli disku. Ak máte napríklad jeden terabajt dát za deň a za deň hľadáte nejaké slovo, budete musieť preskenovať terabajt. A ten je určite na obyčajných pevných diskoch, a nakoniec budú tak zaťažené, že sa na tento server cez SSH nedostanete.
V tomto prípade som pripravený ponúknuť ešte jeden malý trik. Je to z kategórie experimentálnych — môže to fungovať, alebo nemusí. V ClickHouse sú dostupné fulltextové indexy vo forme trigramových Bloom filtrov. Naši kolegovia z firmy Arenadata už tieto indexy vyskúšali a často fungujú presne tak, ako sú určené.
Aby ste ich mohli správne používať, je potrebné dobre chápať, ako presne fungujú: čo predstavuje trigramový Bloom filter a ako si vybrať jeho veľkosť. Môžem povedať, že pomôžu pri dotazoch na nejaké zriedkavé frázy, podreťazce, ktoré sa zriedka vyskytujú v dátach. V tomto prípade budú podľa indexov vybrané podrozsahy a bude prečítaných menej dát.
Nedávno sa v ClickHouse objavili ešte pokročilejšie funkcie pre fulltextové vyhľadávanie. To, po prvé, je vyhľadávanie množstva podreťazcov naraz, vrátane variantov s ohľadom na veľké písmená, bez ohľadu na veľké písmená, s podporou UTF-8 alebo len pre ASCII. Vyberte si najefektívnejší, ktorý potrebujete.
Objavilo sa aj vyhľadávanie viacerých regulárnych výrazov naraz. Nemusíte písať X like jeden podreťazec or X like druhý podreťazec. Jednoducho napíšete a všetko sa vykoná maximálne efektívne.
Tretie — teraz je tu aproximatívne vyhľadávanie regexov a aproximatívne vyhľadávanie podreťazcov. Ak niekto napísal slovo s preklepom, bude hľadané podľa maximálneho zhodovania.
Ako najlepšie organizovať prístup v ClickHouse pre veľké množstvo používateľov?
Povedzte, ako najlepšie organizovať prístup pre veľké množstvo spotrebiteľov a analytikov. Ako vytvoriť radu, prioritizovať požiadavky max concurrent queries a aké nástroje použiť?
Ak je klastra dostatočne veľký, dobrým riešením bude nasadiť ďalšie dva servery, ktoré sa stanú vstupným bodom pre analytikov. To znamená, že analytikov nepustíme na konkrétne shardovanie klastra, ale jednoducho vytvoríme dva prázdne servery, bez dát, a na nich nastavíme práva prístupu. Pri tom sa nastavenia používateľov pri rozdelených požiadavkách prenášajú na vzdialené servery. To znamená, že všetko nastavíte na týchto dvoch serveroch a nastavenia budú mať efekt na celom klastri.
Tieto servery sú v podstate bez dát, ale objem RAM na nich je veľmi dôležitý pre vykonávanie požiadaviek. Disk môže byť tiež využívaný pre dočasné dáta, ak je zapnutá externá agregácia alebo externé triedenie.
Je dôležité pozrieť sa na nastavenia, ktoré súvisia so všetkými možnými limitmi. Ak teraz vstúpim do klastra "Yandex.Metriky" ako analytik a zadám požiadavku select count from hits, okamžite mi vyhodí výnimku, že nemôžem vykonať požiadavku. Maximálny počet riadkov, ktoré mám povolené skenovať, je sto miliárd, zatiaľ čo na klastri ich je päťdesiat biliónov v jednej tabuľke. To je prvé obmedzenie.
Predpokladajme, že zruším obmedzenie počtu riadkov a vykonám požiadavku znova. Potom uvidím nasledujúcu výnimku – zapnuté nastavenie force index by date. Nemôžem vykonať požiadavku, ak neuvádzam rozsah dátumov. Netreba počítať s tým, že analytici ho budú uvádzať ručne. Typický prípad – napísaný rozsah dátumov where event date between týždeň. A potom jednoducho nepresne umiestnili zátvorku, a namiesto and vzniklo or — or URL match. Ak obmedzenie neexistuje, začne skenovať stĺpec URL a spotrebuje množstvo zdrojov.
Okrem toho, v ClickHouse existujú dve nastavenia priorít. Bohužiaľ, sú veľmi primitívne. Jedno sa nazýva jednoducho priority. Ak je priority ≠ 0 a vykonávajú sa požiadavky s nejakou prioritou, ale pritom sa vykonáva požiadavka s prioritou, ktorá má hodnotu menšiu, čo znamená vyššiu prioritu, tak požiadavka s hodnotou priority väčšou, čo označuje nižšiu prioritu, sa jednoducho pozastaví a nebude fungovať vôbec za tento čas.
Toto je veľmi hrubé nastavenie a nie je vhodné pre prípady, keď je na klastri trvalá záťaž. Ale ak máte krátke, impulzívne požiadavky, ktoré sú dôležité, a v podstate klastra nečinný, takéto nastavenie bude vyhovovať.
Ďalšie nastavenie priorít sa nazýva OS thread priority. Jednoducho nastavuje pre všetky vlákna vykonávania požiadavky hodnotu nice pre plánovač Linuxu. Funguje to tak ako tak, ale predsa len funguje. Ak nastavíte najnižšiu hodnotu nice — tá je najväčšia čo sa týka veľkosti, a znamená najnižšiu prioritu — a pre požiadavky s vysokou prioritou nastavíte -19, tak CPU bude spracovávať nízkoprprioritné požiadavky približne štyrikrát menej, ako vysokoprioritné.
Ešte treba nastaviť maximálny čas vykonávania požiadavky — povedzme, päť minút. Minimálna rýchlosť vykonávania požiadavky — to je to najlepšie. Toto nastavenie je už dlho a je potrebné, aby sa len netvrdilo, že ClickHouse nezamŕza, ale aby sa to donútilo.
Predstavte si, že nastavujete: ak nejaká požiadavka spracováva menej ako milión riadkov za sekundu — takto sa správať nemôže. To haní naše dobré meno, našu dobrú databázu. Poďme to jednoducho zakázať. Tam sú v skutočnosti dve nastavenia. Jedno sa nazýva min execution speed — v riadkoch za sekundu, a druhé sa nazýva timeout before checking min execution speed — predvolene pätnásť sekúnd. To znamená, že pätnásť sekúnd je povolené, a potom, ak je to pomalé, tak jednoducho vyhodiť výnimku — prerušiť požiadavku.
Ešte treba nastaviť kvóty. V ClickHouse je zabudovaná možnosť kvót, ktorá počíta využitie zdrojov. Ale, žiaľ, nie železných zdrojov ako CPU, diskov, ale logických — počet spracovaných požiadaviek, riadkov a prečítaných bajtov. A môžete nastaviť, napríklad, maximálne sto požiadaviek počas piatich minút a tisíc požiadaviek za hodinu.
Prečo je to dôležité? Pretože niektoré analytické požiadavky sa budú vykonávať manuálne priamo z klienta ClickHouse. A všetko bude v poriadku. Ale ak máte vo svojej spoločnosti pokročilých analytikov, napíšu skript a v tomto skripte môže byť chyba. A táto chyba povedie k tomu, že požiadavka sa vykoná v nekonečnej slučke. Pred týmto sa treba ochrániť.
Je možné odovzdať výsledky jedného dotazu desiatim klientom?
Máme niekoľko používateľov, ktorí prichádzajú s veľmi veľkými požiadavkami v tom istom okamihu. Požiadavka je veľká, vykonáva sa rýchlo, ale kvôli tomu, že je veľa takýchto požiadaviek súčasne, je to veľmi bolestivé. Je možné vykonať tú istú požiadavku, ktorá prišla desaťkrát za sebou, raz a výsledok odovzdať desiatim klientom?
Problém je v tom, že nemáme výsledky cache alebo cache medzi dátami. Existuje page cache operačného systému, ktorá umožňuje nečítať dáta z disku opäť, ale bohužiaľ, dáta sa aj tak musia rozbaliť, deserializovať a znovu spracovať.
Radi by sme sa tomu nejako vyhli, buď cacheovaním medzi dátami, alebo usporiadaním podobných požiadaviek do nejakej fronty a pridaním cache výsledkov. Momentálne máme vo vývoji jeden pull request, ktorý pridáva cache požiadaviek, ale len pre podpožiadavky v sekcii in a join — čo znamená, že riešenie nie je kompletné.
Napriek tomu aj u nás vzniká takáto situácia. Najmä kanonický príklad — to sú požiadavky s stránkovaním. Existuje správa, v ktorej je niekoľko stránok, a prebieha požiadavka limit 10. Potom to isté, ale limit 10,10. Potom ďalšia stránka. A pýta sa, prečo všetko toto každým razom počítame? Ale teraz nie je žiadne riešenie a tomu sa žiaľ nedá vyhnúť.
Existuje alternatívne riešenie, ktoré sa umiestňuje vedľa ClickHouse ako sidcar — .
Kiril Švakov: V ClickHouse Proxy je zabudovaný rýchlostný obmedzovač a zabudovaný cache výsledkov. Je tam urobených veľmi veľa nastavení, pretože sa riešila podobná úloha. Proxy umožňuje limitovať požiadavky, usporiadať ich do fronty a nastaviť, ako dlho žije cache požiadaviek. Ak boli požiadavky skutočne rovnaké, Proxy ich odovzdá mnohokrát, ale do ClickHouse sa dostane iba raz.
V Nginx je tiež cache vo verzii zdarma a to tiež funguje. Nginx dokonca má nastavenia, že ak prichádzajú požiadavky súčasne, spomalí ostatné, kým jedna nebude splnená. Ale v ClickHouse Proxy je nastavenie urobené omnoho lepšie. Bol vytvorený presne pre ClickHouse a tieto požiadavky, preto je oveľa vhodnejší. A navyše sa jednoducho inštaluje.
Čo robiť s asynchrónnymi operáciami a materializovanými pohľadmi?
Existuje problém, že operácie s replikačným enginom sú asynchrónne – najprv sa zapisujú dáta, potom prebieha ich zlučovanie. Ak pod tabuľkou žije materializovaná tabuľka s nejakými agregátmi, dubliky sa do nej zapíšu. A ak nie je žiadna zložitá logika, dáta budú zdvojené. Čo s tým môžeme urobiť?
Existuje očividné riešenie – implementovať spúšť na určitú triedu matview pri asynchrónnej operácii zlučovania. Existujú nejaké „strieborné náboje“, plány na realizáciu podobných funkčností?
Je dobré sa pozrieť na to, ako funguje deduplikácia. To, o čom teraz hovorím, sa netýka otázky, ale pre istotu to stojí za pripomenutie.
Pri vkladaní do replikovanej tabuľky je deduplikácia celých vložených blokov. Ak znovu vložíte rovnaký blok, obsahujúci rovnaký počet tých istých riadkov v rovnakom poradí, dáta sa deduplikujú. Dostanete „Ok“ na odpoveď na insert, ale skutočne bude zapísaná jedna dávka dát, a tá nebude zdvojená.
Je to potrebné pre istotu. Ak ste počas vkladania dostali „Ok“, znamená to, že vaše dáta boli vložené. Ak ste dostali chybu od ClickHouse, znamená to, že neboli vložené, a vkladanie je potrebné zopakovať. Ale ak sa počas vkladania spojenie preruší, nemusíte vedieť, či boli dáta vložené alebo nie. Jediná možnosť je zopakovať vkladanie. Ak boli dáta naozaj vložené a vy ich znovu vložíte, existuje deduplikácia blokov. Je to potrebné pre zabránenie dublikátom.
A je dôležité, ako to funguje pre materializované predstavienia. Ak boli dáta deduplikované pri vkladaní do hlavnej tabuľky, tak do materializovaného predstavenia sa tiež nedostanú.
Teraz k otázke. Máte zložitejšiu situáciu, pretože zapisujete duplicitné jednotlivé riadky. Teda nie je zdvojená celá dávka, ale konkrétne riadky, a tie sa na pozadí zlučujú. Naozaj, údaje sa zlučujú v hlavnej tabuľke, zatiaľ čo do materializovaného pohľadu idú nezlučené, a pri zlúčeniach sa s materializovanými pohľadmi nič nestane. Pretože materializovaný pohľad je nič iné ako spúšťač na insert. Pri iných operáciách sa s ním nič ďalšie nedeje.
A ja vás tu nemôžem nijako potešiť. Musí sa len hľadať konkrétne riešenie pre tento prípad. Napríklad, je možné v materializovanom pohľade tiež urobiť jeho replacment, a spôsob deduplikácie možno bude fungovať rovnako. Alebo žiaľ, nie vždy. Ak je agregujúci, tak to nebude fungovať.
Kiril Švakov: Aj u nás to bolo raz naozaj problémové. Bolo tu problém, že sú zobrazenia reklamy a sú niektoré údaje, ktoré môžeme zobraziť v reálnom čase - to sú len zobrazenia. Tie sa zriedka duplicitne objavujú, ale ak sa tak stane, aj tak ich neskôr zlučujeme. A boli veci, ktoré sa nedajú duplicitne zobraziť - kliknutia a celá táto história. Ale chceli sme ich tiež prakticky okamžite zobraziť.
Ako boli vyrobené materializované pohľady? Boli tu pohľady, kde sa zapisuje priamo - ide zápis do surových údajov a zapisuje sa do výhľadov. Tam v nejakej chvíli nie sú údaje veľmi správne, duplicitne sa objavujú a tak ďalej. A je tu druhá časť tabuľky, kde vyzerajú absolútne rovnako ako materializované pohľady, teda podľa štruktúry sú úplne rovnaké. Raz za nejaký čas údaje prepočítavame, doplňujeme údaje bez duplicit, zapisujeme do tých tabuliek.
Chodili sme cez API - v ClickHouse to nebude fungovať ručne. A API kontroluje: keď mám dátum posledného prídavku do tabuľky, kde sú už zaručene správne údaje, vypočítané, a robí dotaz na jednu tabuľku a druhú tabuľku. Z jednej tabuľky vyberá do určitého časového úseku a z druhej doplňuje to, čo ešte nebolo spočítané. A to funguje, ale nie pomocou jedného ClickHouse.
Ak máte API pre analytikov alebo pre používateľov, je to v podstate možnosť. Vždy si to prepočítavate a prepočítavate. Môžete to robiť raz denne alebo v inom časovom rámci. Vy si určujete rozsah, ktorý nepotrebujete a nie je pre vás kritický.
V ClickHouse je veľa logov. Ako môžem vidieť všetko, čo sa deje so serverom, v danom momente?
V ClickHouse je veľmi veľké množstvo rôznych logov a toto množstvo neustále rastie. V nových verziách sú niektoré z nich dokonca predvolene zapnuté, zatiaľ čo v starších verziách ich treba aktivovať pri aktualizácii. Napriek tomu ich stále pribúda. Rád by som videl, čo sa teraz momentálne deje s mojím serverom, možno na nejakom súhrnnom dashboarde.
Nemáte vo svojej tímovej skupine ClickHouse, alebo v tímach vašich priateľov, ktoré by podporovali nejakú funkcionalitu hotových dashboardov, ktoré by už tieto logy zobrazovali ako hotový produkt? Konečne, len tak si pozerať logy v ClickHouse je fajn. Ale bolo by veľmi super, keby to už bolo pripravené vo forme dashboardu. To by ma veľmi potešilo.
Dashboardy existujú, aj keď nie sú štandardizované. V našej firme približne 60 tímov používa ClickHouse a najzvláštnejšie je, že mnohé z nich majú dashboardy, ktoré si sami vytvorili, a sú trochu odlišné. Niektoré tímy používajú internú inštaláciu Yandex.Cloud. Majú tam niektoré hotové správy, aj keď nie všetky potrebné. Iní majú svoje vlastné.
Moji kolegovia z Metriky majú svoj dashboard v Grafana, a ja mám svoj podľa ich klastra. Sledujem tam veci ako zásah v cache pre cachovanie údajov. A dokonca je ešte zložitejšie, že používame rôzne nástroje. Svoj dashboard som vytváral na veľmi starom nástroji, ktorý sa volá Graphite-web. Je to úplne škaredé. A stále ho používam, aj keď Grafana by bola pravdepodobne pohodlnejšia a krajšia.
Základná vec na dashboardoch je rovnaká. Sú to systémové metriky klasteru: CPU, pamäť, disk, sieť. Ďalšie metriky sú počet súčasných požiadaviek, počet súčasných zlúčení, počet požiadaviek za sekundu, maximálny počet kusov pre partition tabuliek MergeTree, zdržanie replikácie, veľkosť replikácie v rade, počet vložených riadkov za sekundu, počet vložených blokov za sekundu. Toto sú všetky údaje, ktoré nepochádzajú z logov, ale z metrík.
Vladimir Kolobaev: Alexej, chcel by som trochu zápas upraviť. Existuje Grafana. Grafana má datasource, ktorým je ClickHouse. To znamená, že môžem robiť požiadavky priamo v ClickHouse z Grafany. V ClickHouse je tabuľka s logmi, ktorá je rovnaká pre všetkých. Chcem, aby som sa v Grafane mohol odkazovať na túto tabuľku logov a vidieť tie požiadavky, ktoré posiela môj server. Bolo by skvelé mať taký dashboard.
Ja som si to spravil sám. Ale mám otázku - ak je to všetko štandardizované a Grafana sa používa všade, prečo v 'Jandexe' nie je taký oficiálny dashboard?
Kiril Švakov: V skutočnosti datasource, ktorý je k ClickHouse, momentálne podporuje Altinity. A ja jednoducho chcem poskytnúť vektor, kam sa pozrieť a koho tlačiť. Môžeme sa ich opýtať, pretože 'Yandex' predsa len robí ClickHouse, a nie príbehy okolo neho. Altinity je hlavná spoločnosť, ktorá teraz propaguje ClickHouse. Nepovedia ho, ale budú ho podporovať. Pretože v podstate na to, aby ste nahrali dashboard na stránku Grafana, stačí sa zaregistrovať a nahrať ho - nie sú s tým žiadne veľké problémy.
Alexei Milovidov: V poslednom roku sa v ClickHouse pridalo veľa možností na profilovanie požiadaviek. Existujú metriky pre každú požiadavku na využívanie zdrojov. A prednedávnom bol pridaný ešte nižšie úrovňový profilovač požiadaviek, aby som mohol sledovať, kde požiadavka stráca každú milisekundu. Ale aby som mohol využiť túto funkčnosť, musím otvoriť konzolového klienta a zadať požiadavku, ktorú neustále zabúdam. Uložil som si ju niekam a neustále zabúdam, kam presne.
Chcel by som, aby existoval nástroj, ktorý by jednoducho uviedol – tu sú vaše náročné dotazy, zoradené podľa tried dotazov. Klikol by som na nejaký a povedali by mi, prečo je ťažký. Momentálne takéto riešenie neexistuje. A naozaj je celkom zvláštne, že keď sa ma ľudia pýtajú: „Povedzte, sú nejaké hotové dashboardy pre Grafana?“, hovorím: „Choďte na stránku Grafana, tam je komunita 'Dashboardy', a tam je dashboard od Dimi, je tam dashboard od Kostyana. Čo to je, neviem, sám som ho nepoužíval."
Ako zasiahnuť do zlúčení, aby server nepadal do OOM?
Mám tabuľku, v ktorej je celkovo iba jedna partícia, je to ReplacingMergeTree. Počas štyroch rokov do nej zapisujem dáta. Musel som urobiť ALTER a odstrániť niektoré dáta.
Urobil som to, a počas spracovania tohto dopytu bola celá pamäť na všetkých serveroch v klastre vyčerpaná a všetky servery klastra sa spoločne dostali do OOM. Potom sa všetci opäť zapli, začali spracovávať zlúčenie tej istej operácie, tohto bloku dát a znovu padli do OOM. Potom sa znovu zapli a opäť padli. A táto situácia sa neopakovala.
Potom sa ukázalo, že to bol skutočne bug, ktorý chalani opravili. Je to skvelé, ďakujem veľmi pekne. Ale zostal určitý pocit. A teraz, keď rozmýšľam o tom, ako mám zrealizovať nejaké zlúčenie v tabuľke, vzniká mi otázka – prečo nemôžem nejakým spôsobom zasiahnuť do týchto zlúčení? Napríklad, obmedziť ich podľa množstva požadovanej RAM, alebo v zásade podľa ich počtu, ktorý bude spracovávať konkrétne táto tabuľka.
Mám tabuľku, ktorá sa volá 'Metрики', spracuj mi ju, prosím, v dvoch vláknach. Nemusíš množiť desať alebo päť zlúčení paralelne, sprav to v dvoch. Myslím, že v dvoch mi bude pamäť stačiť, ale na spracovanie desiatich to môže byť nedostatočné. Prečo ostáva strach? Pretože tabuľka rastie, a raz sa stretnem so situáciou, že už nie pre bug, ale kvôli tomu, že dáta budú meniť v takom veľkom množstve, že mi jednoducho na serveri nevyjde pamäť. A vtedy server padne do OOM pri zlúčení. Prípadne mutáciu môžem zrušiť, ale zlúčenia už nie.
Viete, že pri zlúčení server nespadne do OOM, pretože pri zlúčení sa používa množstvo pamäte RAM len na jeden malý rozsah dát. Takže všetko bude v poriadku bez ohľadu na objem údajov.
Vladimir Kolobaev: Dobre. Tu je situácia taká, že po tom, čo sme urobili opravu chyby, som si stiahol novú verziu a na inej tabuľke, menšej, kde je veľa systémov, som vykonal podobnú operáciu. A počas zlúčenia serveru bolo spotrebovaných približne 100 GB pamäte RAM. Mal som 150 GB obsadených, 100 GB sa spotrebovalo a zostalo mi teda 50 GB, takže som nespadol do OOM.
Čo ma v súčasnosti chráni pred pádom do OOM, ak skutočne potrebuje 100 GB pamäte RAM? Ako sa zachovať v situácii, ak náhle pamäť RAM pri zlúčeniach dôjde?
Alexei Milovidov: Existuje taký problém, že spotreba pamäte RAM pri zlúčení nie je obmedzená. A druhý problém spočíva v tom, že ak bol nejaký merge naplánovaný, je potrebné ho vykonať, pretože je zapísaný v logu replikácie. Log replikácie sú tie kroky, ktoré sú potrebné na to, aby sa replika dostala do konzistentného stavu. Ak sa neurobia ručné manipulácie, ktoré tento log replikácie vrátia späť, merge bude potrebné vykonať tak či onak.
Samozrejme, nebolo by na škodu mať obmedzenie pamäte, ktoré "pre istotu" chráni práve pred OOM. Nepomôže to zlúčeniu úspešne sa vykonať, začne sa znovu, dosiahne akúsi hranicu, vyhodí výnimku a potom sa znovu začne – nič dobré z toho nevznikne. Ale v zásade by bolo užitočné toto obmedzenie zaviesť.
Ako bude prebiehať vývoj ovládača Golang pre ClickHouse?
Ovládač Golang, ktorý napísal Kirill Shvakov, je teraz oficiálne podporovaný tímom ClickHouse. , teraz je veľký a pravý.
Malá poznámka. Existuje úžasné a všetkými obľúbené úložisko normálnych foriem nekonečného poradia — to je Vertica. Majú aj svoj oficiálny python ovládač, ktorý je podporovaný vývojármi Vertica. A niekoľkokrát sa stalo, že verzie úložiska a verzie ovládača sa dosť zásadne rozchádzali, a ovládač v istom momente prestal fungovať. A druhý bod. Podpora tohto oficiálneho ovládača, zdá sa mi, prebieha systémom "nippl" — napíšeš im otázku a tá visí večne.
Mám dve otázky. Teraz je Golang ovládač Kirilla takmer predvolený spôsob, ako komunikovať z Golang s ClickHouse. Akurát, že niekto cez http rozhranie stále komunikuje, lebo sa mu to tak páči. Ako prebieha vývoj tohto ovládača? Bude synchronizovaný s nejakými zlomy v samotnom úložisku? A aký je postup pri prehliadaní otázok?
Kiril Švakov: Prvá — ako je všetko vybavené byrokraticky. Tento moment sa nepreberal, preto nemám na to odpoveď.
Aby som mohol odpovedať na otázku o otázkach, potrebujem malú históriu ovládača. Pracoval som v spoločnosti, ktorá mala veľa údajov. Bola to reklamná platforma s obrovským množstvom udalostí, ktoré bolo potrebné niekde uchovávať. A v istom momente sa objavil ClickHouse. Naliali sme tam údaje, a prvý čas bolo všetko dobré, ale potom ClickHouse spadol. V tom čase sme sa rozhodli, že ho nepotrebujeme.
O rok sme sa vrátili k myšlienke využitia ClickHouse a potrebovali sme nejakým spôsobom zapisovať údaje. Úvodná situácia bola taká — hardware bol veľmi slabý, zdrojov bolo málo. Ale vždy sme takto pracovali, a preto sme sa pozerali na natívny protokol.
Keďže sme pracovali na Go, bolo jasné, že potrebujeme ovládač na Go. Robil som ho prakticky na plný úväzok — to bola moja pracovná úloha. Až do určitého momentu sme ho dotiahli, a vlastne nikto si nemyslel, že by ho mohol niekto okrem nás používať. Potom prišiel CloudFlare presne s rovnakým problémom, a istý čas sme s nimi pracovali veľmi synchronizovane, pretože mali tie isté úlohy. A to sme robili aj v ClickHouse samotnom, aj v ovládači.
V určitom momente som sa jednoducho prestal zaoberať, pretože moja aktivita v súvislosti s ClickHouse a pracovné zameranie sa trochu zmenili. Preto sa problémy neuzatvárajú. Priebežne do repozitára commitujú ľudia, ktorí niečo potrebujú. Potom si pozriem pull request a niekedy aj niečo opravím sám, ale to sa deje zriedkavo.
Chcel by som sa vrátiť k ovládaču. Pred niekoľkými rokmi, keď sa to celé začínalo, bol ClickHouse iný a mal iné možnosti. Teraz už máme predstavu, ako prerobiť ovládač, aby to bolo dobré. Ak sa to stane, verzia 2 bude v každom prípade nekompatibilná kvôli nahromadeným obstrukciám.
Ako to zorganizovať, neviem. Sám nemám veľa času. Ak nejakí ľudia budú ovládač vylepšovať, môžem im pomôcť a povedať, čo robiť. Ale aktívna účasť „Jandy“ na rozvoji projektu sa zatiaľ nijako nepreberala.
Alexei Milovidov: V skutočnosti zatiaľ neexistuje žiadna byrokracia ohľadom týchto ovládačov. Jediné - sú presunuté do oficiálnej organizácie, teda tento ovládač je oficiálnym riešením predvolene pre Go. Existujú nejaké ďalšie ovládače, ale tie idú oddelene.
Interné žiadna vyvoj pre tieto ovládače nemáme. Otázka - môžeme najať samostatného človeka, nie konkrétne na tento ovládač, ale na rozvoj všetkých komunitných ovládačov, alebo nájsť niekoho zvonka.
Externý slovník sa po reštarte s povoleným nastavením lazy_load nezobrazí. Čo robiť?
Máme zapnuté nastavenie lazy_load a po reštarte servera sa slovník sám nezobrazí. Objaví sa len po tom, čo sa používateľ obráti na tento slovník. A pri prvom pokuse vráti chybu. Je možné nejakým spôsobom automaticky načítať slovníky pomocou ClickHouse, alebo musíme vždy kontrolovať ich pripravenosť, aby používatelia nedostávali chyby?
Možno máme starú verziu ClickHouse, preto sa slovník automaticky nenahral. Môže to byť tak?
Po prvé, slovníky je možné nútene načítať pomocou dotazu system reload dictionaries. Po druhé, pokiaľ ide o chybu - ak bol slovník už nahraný, dotazy budú fungovať na tých údajoch, ktoré boli nahrané. Ak slovník ešte nebol nahraný, nahrá sa priamo počas dotazu.
Preťaženie ťažkých slovníkov nie je veľmi pohodlné. Napríklad, ak potrebujete načítať milión riadkov z MySQL. Niekto vykoná jednoduchý select, ale ten select bude čakať na tých milión riadkov. Tu sú dve riešenia. Prvé - vypnúť lazy_load. Druhé - keď sa server zapne, predtým ako na neho naložíte záťaž, urobiť system reload dictionary alebo jednoducho vykonať dopyt, ktorý používa slovník. Potom sa slovník načíta. Je potrebné samostatne kontrolovať dostupnosť slovníkov so zapnutým nastavením lazy_load, pretože ClickHouse ich automaticky neťahá.
Na poslednú otázku odpoveď je - buď je verzia zastaraná, alebo treba ladenie.
Čo robiť, ak system reload dictionaries nenahráva žiaden z mnohých slovníkov, keď aspoň jeden z nich zlyhá?
Existuje ešte otázka ohľadom system reload dictionaries. Máme dva slovníky - jeden sa nenahráva, druhý sa nahráva. V takom prípade system reload dictionaries nenahráva ani jeden slovník a musíme po konkrétnom názve presne nahrávať pomocou system reload dictionary. Je to tiež spojené s verziou ClickHouse?
Chcem vás potešiť. Toto správanie sa menilo. To znamená, ak aktualizujete ClickHouse, zmení sa aj to. Ak vám aktuálne správanie nevyhovuje system reload dictionaries, aktualizujte sa a dúfajme, že sa to zmení k lepšiemu.
Existuje spôsob, ako konfigurovať atribúty v konfigurácii ClickHouse, ale nezverejniť ich pri chybách?
Ďalšia otázka je o chybách súvisiacich so slovníkom, konkrétne o údajoch. Uviedli sme prístupové údaje do konfigurácie ClickHouse pre slovník a pri chybe dostávame tieto údaje a heslo v odpovedi.
Túto chybu sme vyriešili presunom údajov do konfigurácie ovládača ODBC. Existuje nejaký spôsob, ako nakonfigurovať údaje v konfigurácii ClickHouse, ale nezverejniť tieto údaje pri chybách?
Riešením je skutočne uvádzať tieto credentials v odbc.ini a v samotnom ClickHouse uvádzať len ODBC Data Source Name. Pre ostatné zdroje slovníkov to nebude fungovať - ani pre slovník s MySQL, ani pre ostatné by ste nemali vidieť heslo pri chybovom hlásení. Na ODBC sa tiež pozriem - ak to existuje, treba to jednoducho odstrániť.
Bonus: pozadia pre Zoom z posedávania
Pri kliknutí na obrázok sa pre najutršie čitateľov otvoria bonusové pozadia z posedení. Uhasíme požiar spolu s maskotmi technológií Avito, konzultujeme s kolegami z miestnosti administrátora alebo starosvetského počítačového klubu a robíme daily pod mostom na pozadí grafity.
Zdroj: habr.com
