V apríli sa inžinieri Avito stretli na online stretnutiach s hlavným vývojárom ClickHouse Alexeyom Milovidovom a Kirillom Shvakovom, vývojárom Golang zo spoločnosti Integros. Diskutovali sme o tom, ako používame systém správy databáz a s akými ťažkosťami sa stretávame.
Na základe stretnutia sme zostavili článok s odpoveďami odborníkov na naše otázky a otázky publika týkajúce sa zálohovania, opätovného zdieľania údajov, externých slovníkov, ovládača Golang a aktualizácií verzií ClickHouse. Môže to byť užitočné pre vývojárov, ktorí už aktívne pracujú s Yandex DBMS a zaujímajú sa o jeho súčasnosť a budúcnosť. Štandardne sú odpovede od Alexeja Milovidova, pokiaľ nie je napísané inak.
Pozor, pod strihom je veľa textu. Dúfame, že obsah s otázkami vám pomôže zorientovať sa.
Obsah
Ak sa vám nechce čítať text, môžete si pozrieť záznam zo stretnutí . Časové kódy sú v prvom komentári pod videom.
ClickHouse sa neustále aktualizuje, ale naše údaje nie. Čo s tým robiť?
ClickHouse sa neustále aktualizuje a naše údaje, ktoré boli optimalizované a spracované, sa neaktualizujú a sú v záložnej kópii.
Povedzme, že sme mali nejaký problém a údaje sa stratili. Rozhodli sme sa obnoviť a ukázalo sa, že staré oddiely, ktoré sú uložené na záložných serveroch, sa veľmi líšia od aktuálne používanej verzie ClickHouse. Čo robiť v takejto situácii a je to možné?
Situácia, v ktorej ste obnovili údaje zo zálohy v starom formáte, ale nepripojí sa k novej verzii, je nemožná. Dbáme na to, aby formát údajov v ClickHouse zostal vždy spätne kompatibilný. Toto je oveľa dôležitejšie ako spätná kompatibilita vo funkčnosti, ak sa zmenilo správanie niektorých zriedkavo používaných funkcií. Nová verzia ClickHouse by mala byť vždy schopná čítať dáta, ktoré sú uložené na disku. Toto je zákon.
Aké sú aktuálne osvedčené postupy na zálohovanie údajov z ClickHouse?
Ako robiť zálohy, berúc do úvahy, že máme optimalizované finálne operácie, obrovskú databázu terabajtov a dáta, ktoré sa aktualizujú povedzme za posledné tri dni a potom sa s tým nerobia žiadne procedúry?
Môžeme si vytvoriť vlastné riešenie a napísať na bash: zbierajte tieto záložné kópie takým a takým spôsobom. Možno nie je potrebné nič brať a bicykel bol vynájdený už dávno?
Začnime osvedčenými postupmi. Moji kolegovia vždy radia v odpovedi na otázky týkajúce sa zálohovania, aby im pripomenuli službu Yandex.Cloud, kde už bol tento problém vyriešený. Takže ak je to možné, použite to.
Neexistuje žiadne úplné riešenie zálohovania, ktoré je na sto percent zabudované do ClickHouse. Existuje niekoľko polotovarov, ktoré možno použiť. Ak chcete získať úplné riešenie, budete musieť buď trochu pohrať ručne, alebo vytvoriť obaly vo forme skriptov.
Začnem najjednoduchšími riešeniami a skončím tými najsofistikovanejšími v závislosti od objemu dát a veľkosti klastra. Čím je klaster väčší, tým je riešenie zložitejšie.
Ak tabuľka s údajmi zaberá len niekoľko gigabajtov, zálohu je možné vykonať takto:
- Uložiť definíciu tabuľky t.j. metaúdaje − zobraziť vytvoriť tabuľku.
- Vytvorte výpis pomocou klienta ClickHouse - vybrať * zo stola vyplniť. V predvolenom nastavení dostanete súbor vo formáte TabSeparated. Ak chcete byť efektívnejší, môžete to urobiť v natívnom formáte.
Ak je množstvo údajov väčšie, záloha zaberie viac času a veľa miesta. Toto sa nazýva logické zálohovanie, nie je viazané na formát údajov ClickHouse. Ak áno, ako poslednú možnosť si môžete urobiť zálohu a nahrať ju do MySQL na obnovenie.
Pre pokročilejšie prípady má ClickHouse zabudovanú schopnosť vytvoriť snímku oddielov v lokálnom súborovom systéme. Táto funkcia je k dispozícii na požiadanie zmeniť oblasť zmrazenia tabuľky. Alebo jednoducho zmeniť zmrazenie stola - toto je snímka celej tabuľky.
Snímka sa vytvorí konzistentne pre jednu tabuľku na jednom zlomku, to znamená, že týmto spôsobom nie je možné vytvoriť konzistentnú snímku celého klastra. Pre väčšinu úloh však takáto potreba nie je potrebná a stačí vykonať požiadavku na každom zlomku a získať konzistentnú snímku. Je vytvorený vo forme pevných odkazov, a preto nezaberá ďalšie miesto. Potom túto snímku skopírujete na záložný server alebo do úložiska, ktoré používate na zálohovanie.
Obnovenie takejto zálohy je celkom jednoduché. Najprv vytvorte tabuľky pomocou existujúcich definícií tabuliek. Ďalej skopírujte uložené snímky oddielov do adresára-oddeleného pre tieto tabuľky a spustite dotaz pripojiť oddiel. Toto riešenie je celkom vhodné pre najvážnejšie objemy dát.
Niekedy potrebujete niečo ešte chladnejšie - v prípadoch, keď máte desiatky alebo dokonca stovky terabajtov na každom serveri a stovky serverov. Tu je riešenie, ktoré som prevzal od svojich kolegov z Yandex.Metrica. Neodporúčal by som to každému - prečítajte si to a sami sa rozhodnite, či je to vhodné alebo nie.
Najprv musíte vytvoriť niekoľko serverov s veľkými policami na disky. Ďalej na týchto serveroch vytvorte niekoľko serverov ClickHouse a nakonfigurujte ich tak, aby fungovali ako ďalšia replika pre rovnaké fragmenty. A potom použite súborový systém alebo nejaký nástroj na týchto serveroch, ktorý vám umožní vytvárať snímky. Tu sú dve možnosti. Prvou možnosťou sú snímky LVM, druhou možnosťou je ZFS na Linuxe.
Potom musíte každý deň vytvoriť snímku, bude ležať a zaberie trochu miesta. Prirodzene, ak sa údaje zmenia, množstvo miesta sa časom zvýši. Túto snímku je možné kedykoľvek vytiahnuť a údaje obnoviť, také zvláštne riešenie. Navyše musíme tieto repliky obmedziť v konfigurácii, aby sa nesnažili stať sa lídrami.
Bude možné zorganizovať kontrolované oneskorenie replík v šachtách?
Tento rok plánujete robiť šachty v ClickHouse. Podarí sa v nich zorganizovať kontrolované oneskorenie replík? Radi by sme sa ním chránili pred negatívnymi scenármi zmien a iných zmien.
Je možné urobiť nejaký návrat pre zmeny? Napríklad v existujúcej šachte, povedzte, že do tohto momentu aplikujete zmeny a od tohto momentu prestanete aplikovať zmeny?
Ak do nášho klastra prišiel príkaz a porušil ho, máme podmienenú repliku s hodinovým oneskorením, kde môžeme povedať, že ho momentálne použijeme, ale posledných desať minút naň nepoužijeme zmeny?
Po prvé, o kontrolovanom oneskorení replík. Od používateľov bola taká požiadavka a na Github sme vytvorili problém s požiadavkou: „Ak to niekto potrebuje, nech sa páči, dajte srdce.“ Nikto nedoručil a problém bol uzavretý. Túto možnosť však už môžete získať nastavením ClickHouse. Pravda, až od verzie 20.3.
ClickHouse neustále vykonáva zlučovanie údajov na pozadí. Po dokončení zlúčenia sa určitá množina údajov nahradí väčšou časťou. Zároveň kusy údajov, ktoré tam boli predtým, zostávajú na disku nejaký čas.
Po prvé, budú naďalej uložené, pokiaľ existujú vybrané dopyty, ktoré ich používajú, aby sa zabezpečila neblokujúca prevádzka. Vybrané dotazy sa dajú ľahko prečítať zo starých častí.
Po druhé, je tu aj časový prah – staré dáta ležia na disku osem minút. Týchto osem minút je možné prispôsobiť a dokonca premeniť na jeden deň. To bude stáť miesto na disku: v závislosti od toku dát sa ukazuje, že za posledný deň sa dáta nielen zdvojnásobia, ale môžu byť aj päťkrát viac. Ak sa však vyskytne vážny problém, môžete server ClickHouse zastaviť a všetko vyriešiť.
Teraz vyvstáva otázka, ako to chráni pred zmenami. Tu sa oplatí pozrieť hlbšie, pretože v starších verziách ClickHouse alter fungoval tak, že jednoducho priamo menil kusy. S niektorými súbormi je kus údajov a my robíme napr. zmeniť stĺpec poklesu. Potom sa tento stĺpec fyzicky odstráni zo všetkých častí.
Ale počnúc verziou 20.3 bol mechanizmus zmeny úplne zmenený a teraz sú časti údajov vždy nemenné. Vôbec sa nemenia – zmeny teraz fungujú v podstate rovnakým spôsobom ako zlúčenie. Namiesto výmeny kusu na mieste vytvoríme nový. V novom bloku sa súbory, ktoré sa nezmenili, stanú pevnými odkazmi a ak odstránime stĺpec, v novom bloku bude jednoducho chýbať. Starý kus sa štandardne vymaže po ôsmich minútach a tu si môžete doladiť vyššie spomenuté nastavenia.
To isté platí pre zmeny, ako sú mutácie. Keď to urobíte zmeniť vymazať alebo zmeniť aktualizáciu, nezmení kus, ale vytvorí nový. A potom vymaže ten starý.
Čo ak sa štruktúra tabuľky zmenila?
Ako obnoviť zálohu, ktorá bola vytvorená so starou schémou? A druhá otázka sa týka prípadu so snímkami a nástrojmi súborového systému. Je tu Btrfs dobrý namiesto ZFS na Linuxe LVM?
Ak urobíš pripojiť oddiel oddiely s inou štruktúrou, potom vám ClickHouse povie, že to nie je možné. Toto je riešenie. Prvým je vytvoriť dočasnú tabuľku typu MergeTree so starou štruktúrou, priložiť tam údaje pomocou prílohy a urobiť alter dotaz. Potom môžete tieto údaje skopírovať alebo preniesť a znova priložiť, alebo použiť požiadavku zmeniť tabuľku presunúť oddiel.
Teraz je druhou otázkou, či je možné použiť Btrfs. Na začiatok, ak máte LVM, stačia snímky LVM a súborový systém môže byť ext4, na tom nezáleží. S Btrts všetko závisí od vašich skúseností s jeho používaním. Toto je vyspelý súborový systém, ale stále existujú určité podozrenia o tom, ako bude všetko v praxi fungovať v konkrétnom scenári. Toto by som neodporúčal používať, pokiaľ nemáte vo výrobe Btrfs.
Aké sú aktuálne osvedčené postupy v oblasti opätovného spracovania údajov?
Problematika reshardingu je zložitá a mnohostranná. Tu je viacero možných odpovedí. Môžete ísť z jednej strany a povedať toto – ClickHouse nemá vstavanú funkciu opätovného skartovania. Obávam sa však, že táto odpoveď nebude vyhovovať nikomu. Preto môžete ísť z druhej strany a povedať, že ClickHouse má mnoho spôsobov, ako prerobiť údaje.
Ak v klastri dôjde miesto alebo nezvládne zaťaženie, pridajte nové servery. Ale tieto servery sú štandardne prázdne, nie sú na nich žiadne dáta, nie je tam žiadna záťaž. Údaje musíte usporiadať tak, aby sa rovnomerne rozložili v novom, väčšom klastri.
Prvý spôsob, ako to urobiť, je skopírovať časť oddielov na nové servery pomocou požiadavky zmeniť oblasť načítania tabuľky. Napríklad ste mali oddiely podľa mesiacov a vezmete si prvý mesiac roku 2017 a skopírujete ho na nový server, potom skopírujete tretí mesiac na nejaký iný nový server. A robíte to dovtedy, kým to nebude viac-menej rovnomerné.
Prenos je možné vykonať len pre tie partície, ktoré sa počas nahrávania nemenia. V prípade nových oddielov bude potrebné vypnúť nahrávanie, pretože ich prenos nie je atómový. V opačnom prípade skončíte s duplikátmi alebo medzerami v údajoch. Táto metóda je však praktická a funguje celkom efektívne. Hotové komprimované oddiely sa prenášajú cez sieť, to znamená, že údaje nie sú komprimované ani prekódované.
Táto metóda má jednu nevýhodu a závisí od schémy shardingu, či ste sa zaviazali k tejto schéme shardingu, aký kľúč ste mali. Vo vašom príklade pre metriky je kľúčom sharding hash cesty. Keď vyberiete distribuovanú tabuľku, prejde do všetkých zlomkov v klastri naraz a vezme odtiaľ údaje.
To znamená, že v skutočnosti nezáleží na tom, aké údaje skončili na ktorom zlomku. Hlavná vec je, že údaje pozdĺž jednej cesty končia na jednom zlomku, ale ktorý z nich nie je dôležitý. V tomto prípade je prenos hotových partícií perfektný, pretože s vybranými dotazmi dostanete aj kompletné dáta – či už pred opätovným shardovaním alebo po ňom, na schéme v skutočnosti nezáleží.
Sú však prípady, ktoré sú zložitejšie. Ak sa na úrovni aplikačnej logiky spoliehate na špeciálnu schému shardingu, že tento klient sa nachádza na takom a takom fragmente a požiadavku možno odoslať priamo tam, a nie do distribuovanej tabuľky. Alebo používate pomerne najnovšiu verziu ClickHouse a povolili ste toto nastavenie optimalizovať preskočiť nepoužívané zlomky. V tomto prípade sa počas výberového dotazu analyzuje výraz v sekcii kde a vypočíta sa, ktoré fragmenty je potrebné použiť podľa schémy shardingu. Funguje to za predpokladu, že údaje sú rozdelené presne podľa tejto schémy shardingu. Ak ste ich preusporiadali ručne, korešpondencia sa môže zmeniť.
Takže toto je metóda číslo jedna. A čakám na vašu odpoveď, či je metóda vhodná, alebo poďme ďalej.
Vladimir Kolobaev, hlavný správca systému v spoločnosti Avito: Alexey, metóda, ktorú ste spomenuli, nefunguje veľmi dobre, keď potrebujete rozložiť záťaž vrátane čítania. Môžeme si vziať oddiel, ktorý je mesačný a môže preniesť predchádzajúci mesiac do iného uzla, ale keď príde požiadavka na tieto údaje, iba ich načítame. Chceli by sme však načítať celý klaster, pretože v opačnom prípade bude nejaký čas celé zaťaženie čítania spracovávať dva úlomky.
Alexey Milovidov: Odpoveď je zvláštna - áno, je to zlé, ale môže to fungovať. Vysvetlím presne ako. Stojí za to pozrieť sa na scenár zaťaženia, ktorý sa skrýva za vašimi údajmi. Ak ide o údaje z monitorovania, potom môžeme takmer s istotou povedať, že veľká väčšina žiadostí sa týka čerstvých údajov.
Nainštalovali ste nové servery, migrovali ste staré oddiely, ale zmenili ste aj spôsob zaznamenávania čerstvých údajov. A čerstvé údaje sa budú šíriť po celom klastri. Už po piatich minútach teda požiadavky na posledných päť minút rovnomerne zaťažia klaster, po dni požiadavky na XNUMX hodín rovnomerne zaťažia klaster. A požiadavky za predchádzajúci mesiac, žiaľ, pôjdu len na časť serverov klastra.
Často však nebudete mať žiadosti konkrétne na február 2019. S najväčšou pravdepodobnosťou, ak sa žiadosti dostanú do roku 2019, potom budú na celý rok 2019 – na veľké časové obdobie, a nie na nejaký malý rozsah. A takéto požiadavky budú tiež schopné rovnomerne zaťažiť klaster. Ale vo všeobecnosti je vaša poznámka úplne správna, že ide o ad hoc riešenie, ktoré neroznáša dáta úplne rovnomerne.
Na zodpovedanie otázky mám ešte niekoľko bodov. Jedna z nich je o tom, ako na začiatku navrhnúť schému shardingu tak, aby opätovné sharovanie spôsobovalo menšiu bolesť. Nie vždy je to možné.
Napríklad máte monitorovacie údaje. Údaje z monitorovania rastú z troch dôvodov. Prvým je hromadenie historických údajov. Druhým je nárast dopravy. A tretím je nárast počtu vecí, ktoré podliehajú monitorovaniu. Existujú nové mikroslužby a metriky, ktoré je potrebné uložiť.
Je možné, že z nich je najväčší nárast spojený s tretím dôvodom – nárastom využívania monitoringu. A v tomto prípade stojí za to pozrieť sa na povahu zaťaženia, aké sú hlavné vybrané otázky. Základné výberové dopyty budú s najväčšou pravdepodobnosťou založené na nejakej podmnožine metrík.
Napríklad využitie CPU na niektorých serveroch nejakou službou. Ukazuje sa, že existuje určitá podmnožina kľúčov, pomocou ktorých získate tieto údaje. A samotná požiadavka na tieto údaje je s najväčšou pravdepodobnosťou celkom jednoduchá a je dokončená v priebehu desiatok milisekúnd. Používa sa na monitorovanie služieb a dashboardov. Dúfam, že tomu rozumiem správne.
Vladimír Kolobajev: Faktom je, že veľmi často apelujeme na historické údaje, keďže v reálnom čase porovnávame súčasnú situáciu s historickou. A je pre nás dôležité, aby sme mali rýchly prístup k veľkému množstvu údajov a ClickHouse s tým robí skvelú prácu.
Máte úplnú pravdu, väčšinu žiadostí o čítanie zažívame za posledný deň, ako každý monitorovací systém. Zároveň je však zaťaženie historických údajov pomerne veľké. Je to v podstate z varovného systému, ktorý chodí každých tridsať sekúnd a hovorí ClickHouse: „Dajte mi údaje za posledných šesť týždňov. Teraz mi z nich zostavte nejaký kĺzavý priemer a porovnajme súčasnú hodnotu s historickou.“
Chcel by som povedať, že pre takéto veľmi nedávne požiadavky máme ďalšiu malú tabuľku, v ktorej ukladáme iba dva dni údajov a hlavné požiadavky do nej lietajú. Veľké historické dopyty posielame len na veľkú črepinu.
Alexey Milovidov: Žiaľ, ukázalo sa, že je zle použiteľný pre váš scenár, ale poviem vám popis dvoch zlých a zložitých schém shardingu, ktoré nie je potrebné používať, ale ktoré sa používajú v službe mojich priateľov.
Existuje hlavný klaster s udalosťami Yandex.Metrica. Udalosti sú zobrazenia stránky, kliknutia a konverzie. Väčšina žiadostí smeruje na konkrétnu webovú stránku. Otvoríte službu Yandex.Metrica, máte webovú stránku - avito.ru, prejdite na správu a odošle sa žiadosť o vašu webovú stránku.
Existujú však aj ďalšie požiadavky – analytické a globálne – ktoré predkladajú interní analytici. Len pre prípad si všimnem, že interní analytici žiadajú iba služby Yandex. Napriek tomu však aj služby Yandex zaberajú významný podiel všetkých údajov. Nejde o požiadavky na konkrétne počítadlá, ale na širšie filtrovanie.
Ako organizovať dáta tak, aby všetko fungovalo efektívne pre jeden počítadlo a tiež globálne dopyty? Ďalším problémom je, že počet požiadaviek v ClickHouse pre klaster Metrics je niekoľko tisíc za sekundu. Jeden server ClickHouse zároveň nedokáže spracovať netriviálne požiadavky, napríklad niekoľko tisíc za sekundu.
Veľkosť klastra je šesťsto serverov. Ak jednoducho natiahnete distribuovanú tabuľku cez tento klaster a odošlete tam niekoľko tisíc požiadaviek, bude to ešte horšie, ako keď ich pošlete na jeden server. Na druhej strane, možnosť, že dáta sú rozložené rovnomerne a my ideme žiadať zo všetkých serverov, je okamžite zamietnutá.
Existuje možnosť, ktorá je diametrálne opačná. Predstavte si, že údaje rozdelíme naprieč webmi a žiadosť o jeden web prejde na jeden zlomok. Teraz bude klaster schopný spracovať desaťtisíc požiadaviek za sekundu, ale na jednom zlomku bude každá požiadavka pracovať príliš pomaly. Už sa nebude škálovať z hľadiska priepustnosti. Najmä ak ide o stránku avito.ru. Neprezradím tajomstvo, ak poviem, že Avito je jednou z najnavštevovanejších stránok v RuNet. A spracovať to na jednom črepe by bolo šialenstvo.
Preto je schéma shardingu navrhnutá prefíkanejším spôsobom. Celý zhluk je rozdelený na množstvo zhlukov, ktoré nazývame vrstvy. Každý zhluk obsahuje tucet až niekoľko desiatok črepov. Celkovo existuje tridsaťdeväť takýchto zhlukov.
Ako sa to všetko mení? Počet klastrov sa nemení – ako to bolo pred pár rokmi tridsaťdeväť, zostáva. Ale v rámci každého z nich postupne zvyšujeme počet úlomkov, keď hromadíme dáta. A schéma shardingu ako celku je takáto: tieto klastre sú rozdelené na webové stránky a aby sme pochopili, ktorá webová stránka je na ktorom klastri, používa sa samostatná metabáza v MySQL. Jedna lokalita – na jednom klastri. A v jeho vnútri dochádza k shardingu podľa ID návštevníkov.
Pri zaznamenávaní ich delíme zvyškom delenia ID návštevníka. Ale pri pridávaní nového úlomku sa mení schéma štiepenia, pokračujeme v delení, ale so zvyškom delenia o iné číslo. To znamená, že jeden návštevník sa už nachádza na viacerých serveroch a nemôžete sa na to spoľahnúť. Deje sa tak len preto, aby sa zabezpečila lepšia komprimácia údajov. A pri vytváraní požiadaviek prejdeme do distribuovanej tabuľky, ktorá sa pozerá na klaster a pristupuje k desiatkam serverov. Toto je taká hlúpa schéma.
Môj príbeh však nebude úplný, ak nepoviem, že sme od tohto plánu upustili. V novej schéme sme všetko zmenili a všetky dáta sme skopírovali pomocou clickhouse-copier.
V novej schéme sú všetky stránky rozdelené do dvoch kategórií – veľké a malé. Neviem, ako bol zvolený prah, ale výsledkom bolo, že veľké stránky sú zaznamenané na jednom klastri, kde je 120 fragmentov s tromi replikami - to znamená 360 serverov. A schéma shardingu je taká, že akákoľvek požiadavka ide na všetky shardy naraz. Ak teraz otvoríte akúkoľvek stránku prehľadu pre avito.ru v Yandex.Metrica, žiadosť sa odošle na 120 serverov. V RuNet je málo veľkých stránok. A požiadavky nie sú tisíc za sekundu, ale dokonca menej ako sto. To všetko v tichosti prežúva distribuovaná tabuľka, ktorú každý z nich spracováva so 120 servermi.
A druhý klaster je pre malé lokality. Tu je schéma zdieľania založená na ID lokality a každá požiadavka smeruje presne na jeden fragment.
ClickHouse má pomôcku na kopírovanie clickhouse. Môžete nám o nej povedať?
Hneď poviem, že toto riešenie je ťažkopádnejšie a o niečo menej produktívne. Výhodou je, že dáta rozmazáva úplne podľa vzoru, ktorý určíte. Ale nevýhodou utility je, že sa vôbec nereharduje. Kopíruje údaje z jednej klastrovej schémy do inej klastrovej schémy.
To znamená, že na to, aby to fungovalo, musíte mať dva klastre. Môžu byť umiestnené na rovnakých serveroch, ale napriek tomu sa údaje nebudú presúvať postupne, ale budú skopírované.
Napríklad, tam boli štyri servery, teraz je ich osem. Na všetkých serveroch vytvoríte novú distribuovanú tabuľku, nové lokálne tabuľky a spustíte clickhouse-copier, v ktorom uvediete pracovnú schému, ktorú má odtiaľ čítať, prijmete novú schému shardingu a prenesiete tam údaje. A na starých serveroch budete potrebovať jeden a pol krát viac miesta ako je teraz, pretože staré dáta na nich musia zostať a polovica tých istých starých dát príde na ne. Ak ste si vopred mysleli, že dáta treba prerobiť a je tam priestor, tak je tento spôsob vhodný.
Ako funguje clickhouse-copier vo vnútri? Rozdeľuje všetku prácu do súboru úloh na spracovanie jednej partície jednej tabuľky na jednom zlomku. Všetky tieto úlohy môžu byť vykonávané paralelne a clickhouse-copier môže byť spustený na rôznych počítačoch vo viacerých inštanciách, ale to, čo robí pre jeden oddiel, nie je nič iné ako výber vloženia. Dáta sa čítajú, dekomprimujú, prerozdeľujú, potom znova skomprimujú, niekde sa zapíšu a pretriedia. Toto je ťažšie rozhodnutie.
Mali ste pilotnú vec zvanú resharding. Čo s ňou?
V roku 2017 ste mali pilotnú vec s názvom resharding. V ClickHouse je dokonca možnosť. Ako som pochopil, nevzlietlo to. Môžete mi povedať, prečo sa to stalo? Zdá sa, že je to veľmi relevantné.
Celý problém je v tom, že ak je potrebné preshardovať dáta na mieste, je potrebná veľmi zložitá synchronizácia, aby sa to urobilo atomicky. Keď sme sa začali zaoberať tým, ako táto synchronizácia funguje, bolo jasné, že existujú zásadné problémy. A tieto zásadné problémy nie sú len teoretické, ale okamžite sa začali prejavovať v praxi v podobe niečoho, čo sa dá veľmi jednoducho vysvetliť – nič nefunguje.
Je možné zlúčiť všetky údaje pred ich presunom na pomalé disky?
Otázka o TTL s možnosťou prechodu na pomalý disk v kontexte zlučovania. Existuje iný spôsob ako cez cron zlúčiť všetky časti do jednej pred ich presunom na pomalé disky?
Odpoveď na otázku je, že pred prenosom je možné nejako automaticky zlepiť všetky kusy do jedného - nie. Myslím, že to nie je potrebné. Nemusíte spájať všetky časti do jednej, ale jednoducho rátajte s tým, že sa automaticky prenesú na pomalé disky.
Pre pravidlá prestupu máme dve kritériá. Prvý je taký, ako je naplnený. Ak má aktuálna vrstva úložiska menej ako určité percento voľného miesta, vyberieme jeden kus a presunieme ho do pomalšieho úložiska. Alebo skôr nie pomalšie, ale ďalšie - ako si nakonfigurujete.
Druhým kritériom je veľkosť. Ide o premiestňovanie veľkých kusov. Prahovú hodnotu môžete upraviť podľa voľného miesta na rýchlom disku a dáta sa prenesú automaticky.
Ako migrovať na nové verzie ClickHouse, ak neexistuje spôsob, ako vopred skontrolovať kompatibilitu?
O tejto téme sa pravidelne diskutuje berúc do úvahy rôzne verzie a stále. Ako bezpečný je upgrade z verzie 19.11 na 19.16 a napríklad z 19.16 na 20.3. Aký je najlepší spôsob migrácie na nové verzie bez možnosti vopred skontrolovať kompatibilitu v karanténe?
Existuje niekoľko „zlatých“ pravidiel. Najprv - . Je veľký, ale sú tam samostatné odseky o spätne nekompatibilných zmenách. Nepovažujte tieto body za červenú vlajku. Zvyčajne ide o menšie nekompatibility, ktoré zahŕňajú niektoré okrajové funkcie, ktoré veľmi pravdepodobne nepoužívate.
Po druhé, ak neexistuje spôsob, ako skontrolovať kompatibilitu v karanténe a chcete aktualizovať okamžite vo výrobe, odporúča sa, že to nemusíte robiť. Najprv vytvorte pieskovisko a otestujte. Ak neexistuje testovacie prostredie, potom s najväčšou pravdepodobnosťou nemáte veľmi veľkú spoločnosť, čo znamená, že si môžete skopírovať niektoré údaje do prenosného počítača a uistiť sa, že na ňom všetko funguje správne. Môžete dokonca vytvoriť niekoľko replík lokálne na vašom počítači. Alebo si môžete niekde nablízku vyzdvihnúť novú verziu a tam nahrať nejaké tie dáta – teda vytvoriť improvizované testovacie prostredie.
Ďalším pravidlom je neaktualizovať týždeň po vydaní verzie z dôvodu vychytávania chýb vo výrobe a následných rýchlych opráv. Poďme zistiť číslovanie verzií ClickHouse, aby sme sa nemýlili.
Existuje verzia 20.3.4. Číslica 20 označuje rok výroby - 2020. Z pohľadu toho, čo je vo vnútri, je to jedno, preto sa tomu venovať nebudeme. Najbližšie - 20.3. Druhé číslo - v tomto prípade 3 - zvyšujeme vždy, keď vydávame vydanie s nejakou novou funkcionalitou. Ak chceme do ClickHouse pridať nejakú funkciu, musíme toto číslo zvýšiť. To znamená, že vo verzii 20.4 bude ClickHouse fungovať ešte lepšie. Tretia číslica je 20.3.4. Tu je 4 počet vydaní opráv, do ktorých sme nepridali nové funkcie, ale opravili sme niektoré chyby. A 4 znamená, že sme to urobili štyrikrát.
Nemyslite si, že je to niečo strašné. Zvyčajne si používateľ môže nainštalovať najnovšiu verziu a bude fungovať bez problémov s dobou prevádzky za rok. Predstavte si však, že v nejakej funkcii na spracovanie bitmapy, ktorú pridali naši čínski súdruhovia, server spadne pri odovzdávaní nesprávnych argumentov. Máme zodpovednosť to napraviť. Vydáme novú verziu opravy a ClickHouse sa stane stabilnejším.
Ak máte ClickHouse spustený v produkcii a je vydaná nová verzia ClickHouse s ďalšími funkciami - napríklad 20.4.1 je úplne prvá, neponáhľajte sa s jej uvedením do produkcie v prvý deň. Prečo je to vôbec potrebné? Ak ClickHouse ešte nepoužívate, môžete si ho nainštalovať a s najväčšou pravdepodobnosťou bude všetko v poriadku. Ak však ClickHouse už funguje stabilne, sledujte opravy a aktualizácie, aby ste videli, aké problémy riešime.
Kirill Shvakov: Chcel by som pridať niečo o testovacích prostrediach. Každý sa veľmi bojí testovacích prostredí a z nejakého dôvodu verí, že ak máte veľmi veľký klaster ClickHouse, testovacie prostredie by nemalo byť menšie alebo aspoň desaťkrát menšie. Vôbec to tak nie je.
Môžem vám to povedať z vlastného príkladu. Mám projekt a je tu ClickHouse. Práve jemu je určené naše testovacie prostredie – ide o malý virtuálny stroj v Hetznerovi za dvadsať eur, kde je nasadené úplne všetko. Aby sme to dosiahli, máme v Ansible plnú automatizáciu, a preto v zásade nezáleží na tom, kam ísť - na hardvérové servery alebo len nasadiť vo virtuálnych strojoch.
Čo sa dá robiť? Bolo by pekné uviesť v dokumentácii ClickHouse príklad, ako nasadiť malý klaster vo vašom vlastnom dome – v Dockeri, v LXC možno vytvorte príručku Ansible, pretože rôzni ľudia majú rôzne nasadenia. Tým sa veľa zjednoduší. Keď vezmete a nasadíte klaster za päť minút, je oveľa jednoduchšie pokúsiť sa niečo vymyslieť. Je to oveľa pohodlnejšie, pretože prechod do produkčnej verzie, ktorú ste ešte netestovali, je cesta nikam. Niekedy to funguje a niekedy nie. A preto dúfať v úspech je zlé.
Maxim Kotyakov, hlavný backendový inžinier Avito: Pridám niečo o testovacích prostrediach zo série problémov, ktorým čelia veľké spoločnosti. Máme plnohodnotný akceptačný klaster ClickHouse, z hľadiska dátových schém a nastavení ide o presnú kópiu toho, čo je vo výrobe. Tento klaster je nasadzovaný v pomerne spotrebovaných kontajneroch s minimom zdrojov. Zapisujeme tam určité percento výrobných údajov, našťastie je možné stream v Kafke replikovať. Všetko je tam synchronizované a škálované – z hľadiska kapacity aj toku, a teoreticky, ak sú všetky ostatné veci rovnaké, malo by sa to z hľadiska metrík správať ako výroba. Všetko potenciálne výbušné sa najprv navalí na tento stojan a nechá sa tam niekoľko dní, kým nie je pripravené. Ale prirodzene, toto riešenie je drahé, náročné a má nenulové náklady na podporu.
Alexey Milovidov: Poviem vám, aké je testovacie prostredie našich priateľov z Yandex.Metrica. Jeden klaster mal 600-nepárnych serverov, druhý mal 360 a existuje tretí a niekoľko klastrov. Testovacie prostredie pre jeden z nich sú jednoducho dva fragmenty s dvoma replikami v každom. Prečo dva črepy? Aby ste neboli sami. A mali by tam byť aj repliky. Stačí určitá minimálna suma, ktorú si môžete dovoliť.
Toto testovacie prostredie vám umožňuje skontrolovať, či vaše dotazy fungujú a či nie je niečo dôležité. Často však vznikajú problémy úplne iného charakteru, keď všetko funguje, ale dochádza k malým zmenám v záťaži.
Uvediem príklad. Rozhodli sme sa nainštalovať novú verziu ClickHouse. Bol zverejnený v testovacom prostredí, v samotnom Yandex.Metrica boli dokončené automatizované testy, ktoré porovnávajú údaje o starej a novej verzii, pričom prebieha celý kanál. A samozrejme, zelené testy našej CI. Inak by sme túto verziu ani nenavrhli.
Všetko je v poriadku. Začíname sa presúvať do výroby. Dostávam správu, že zaťaženie grafov sa niekoľkonásobne zvýšilo. Vraciame späť verziu. Pozerám sa na graf a vidím: záťaž sa v skutočnosti počas zavádzania niekoľkokrát zvýšila a po spustení sa opäť znížila. Potom sme začali vracať verziu späť. A náklad sa zvýšil rovnakým spôsobom a rovnakým spôsobom klesol späť. Záver je teda takýto: záťaž sa vďaka rozloženiu zvýšila, nič prekvapivé.
Potom bolo ťažké presvedčiť kolegov, aby si nainštalovali novú verziu. Hovorím: „To je v poriadku, rozbehni sa. Držte palce, všetko bude fungovať. Teraz sa zaťaženie grafov zvýšilo, ale všetko je v poriadku. Drž sa." Vo všeobecnosti sme to urobili, a to je všetko - verzia bola uvoľnená na výrobu. Ale takmer pri každom usporiadaní vznikajú podobné problémy.
Zabíjací dopyt má zabíjať dotazy, ale nie. prečo?
Používateľ, nejaký analytik, prišiel za mnou a vytvoril požiadavku, ktorá vložila môj klaster ClickHouse. Nejaký uzol alebo celý klaster, v závislosti od toho, na ktorú repliku alebo zlomok smerovala požiadavka. Vidím, že všetky prostriedky CPU na tomto serveri sú v poličke, všetko je červené. Na požiadavky zároveň reaguje aj samotný ClickHouse. A ja píšem: "Ukáž mi, prosím, zoznam procesov, aká požiadavka vyvolala toto šialenstvo."
Nájdem túto požiadavku a napíšem k nej kill. A vidím, že sa nič nedeje. Môj server je v poličke, ClickHouse mi potom dáva nejaké príkazy, ukazuje, že server je nažive a všetko je skvelé. Ale mám degradáciu vo všetkých požiadavkách používateľov, degradácia začína záznamami v ClickHouse a môj dotaz na zabíjanie nefunguje. prečo? Myslel som si, že kill query mal zabíjať dotazy, ale nie je to tak.
Teraz príde dosť zvláštna odpoveď. Ide o to, že zabíjací dotaz nezabíja dotazy.
Kill query zaškrtne malé políčko s názvom „Chcem, aby bol tento dotaz zabitý“. A samotná požiadavka sa pozerá na tento príznak pri spracovaní každého bloku. Ak je nastavený, požiadavka prestane fungovať. Ukazuje sa, že žiadosť nikto nezabije, on sám musí všetko skontrolovať a zastaviť. A to by malo fungovať vo všetkých prípadoch, keď je požiadavka v stave spracovania blokov údajov. Spracuje ďalší blok údajov, skontroluje príznak a zastaví sa.
Toto nefunguje v prípadoch, keď je požiadavka zablokovaná pri nejakej operácii. Je pravda, že to s najväčšou pravdepodobnosťou nie je váš prípad, pretože podľa vás používa veľa serverových zdrojov. Je možné, že to nefunguje v prípade externého triedenia a v niektorých ďalších detailoch. Ale vo všeobecnosti by sa to nemalo stávať, je to chyba. A jediné, čo môžem odporučiť, je aktualizovať ClickHouse.
Ako vypočítať čas odozvy pri zaťažení čítaním?
Je tam tabuľka, v ktorej sú uložené agregáty položiek – rôzne počítadlá. Počet liniek je približne sto miliónov. Je možné počítať s predvídateľným časom odozvy, ak nalejete 1K RPS na 1K položiek?
Súdiac podľa kontextu hovoríme o čitateľskej záťaži, pretože s písaním nie sú žiadne problémy - možno vložiť aj tisíc, dokonca stotisíc a niekedy aj niekoľko miliónov riadkov.
Požiadavky na čítanie sú veľmi odlišné. Vo výbere 1 môže ClickHouse vykonať približne desiatky tisíc požiadaviek za sekundu, takže aj požiadavky na jeden kľúč si už budú vyžadovať určité zdroje. A takéto bodové dotazy budú náročnejšie ako v niektorých databázach kľúč-hodnota, pretože na každé čítanie je potrebné prečítať blok údajov podľa indexu. Náš index sa nezaoberá každým záznamom, ale každým rozsahom. To znamená, že budete musieť prečítať celý rozsah - štandardne je to 8192 riadkov. A budete musieť dekomprimovať blok komprimovaných údajov zo 64 KB na 1 MB. Dokončenie takýchto cielených dopytov zvyčajne trvá niekoľko milisekúnd. Ale toto je najjednoduchšia možnosť.
Skúsme jednoduchú aritmetiku. Ak vynásobíte niekoľko milisekúnd tisícmi, dostanete niekoľko sekúnd. Je to, ako keby bolo nemožné držať krok s tisíckami požiadaviek za sekundu, ale v skutočnosti je to možné, pretože máme niekoľko procesorových jadier. Takže v princípe môže ClickHouse niekedy držať 1000 RPS, ale pre krátke požiadavky, konkrétne cielené.
Ak potrebujete škálovať klaster ClickHouse podľa počtu jednoduchých požiadaviek, potom odporúčam najjednoduchšiu vec - zvýšiť počet replík a odoslať požiadavky náhodnej replike. Ak jedna replika pojme päťsto požiadaviek za sekundu, čo je úplne reálne, potom tri repliky vybavia jeden a pol tisíc.
Niekedy, samozrejme, môžete nakonfigurovať ClickHouse na maximálny počet bodov. Čo je k tomu potrebné? Prvým je zníženie zrnitosti indexu. V tomto prípade by sa nemal znížiť na jeden, 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, úroveň podrobnosti možno nastaviť na 64.
Veľkosť komprimovaného bloku môžete zmenšiť. Na to existujú nastavenia minimálna veľkosť kompresného bloku, maximálna veľkosť kompresného bloku. Dajú sa zredukovať, naplniť údajmi a potom budú cielené dopyty rýchlejšie. ClickHouse však stále nie je databázou hodnôt kľúča. Veľký počet malých požiadaviek je antivzorom zaťaženia.
Kirill Shvakov: Poradím v prípade, že tam budú bežné účty. Toto je pomerne štandardná situácia, keď ClickHouse skladuje nejaký druh pultu. Mám užívateľa, je z takej a takej krajiny a nejaké tretie pole a potrebujem postupne niečo zvýšiť. Vezmite MySQL, vytvorte jedinečný kľúč - v MySQL je to duplicitný kľúč a v PostgreSQL je to konflikt - a pridajte znamienko plus. Toto bude fungovať oveľa lepšie.
Keď nemáte veľa údajov, nemá zmysel používať ClickHouse. Existujú pravidelné databázy a robia to dobre.
Čo môžem v ClickHouse vyladiť, aby bolo vo vyrovnávacej pamäti viac údajov?
Predstavme si situáciu - servery majú 256 GB RAM, v dennej rutine zaberá ClickHouse asi 60 - 80 GB, v špičke - až 130. Čo je možné povoliť a vyladiť, aby bolo vo vyrovnávacej pamäti viac údajov a podľa toho je menej výletov na disk?
Vyrovnávacia pamäť stránok operačného systému zvyčajne robí dobrú prácu. Ak len otvoríte hornú časť, pozriete sa tam vo vyrovnávacej pamäti alebo vo voľnom – hovorí sa aj o tom, koľko je vo vyrovnávacej pamäti – potom si všimnete, že všetka voľná pamäť sa používa na vyrovnávaciu pamäť. A pri čítaní týchto údajov sa nenačítajú z disku, ale z pamäte RAM. Zároveň môžem povedať, že vyrovnávacia pamäť sa využíva efektívne, pretože sa do vyrovnávacej pamäte ukladajú komprimované údaje.
Ak však chcete niektoré jednoduché dopyty ešte viac zrýchliť, je možné povoliť vyrovnávaciu pamäť v dekomprimovaných údajoch vo vnútri ClickHouse. To sa nazýva nekomprimovaná vyrovnávacia pamäť. V konfiguračnom súbore config.xml nastavte veľkosť nekomprimovanej vyrovnávacej pamäte na hodnotu, ktorú potrebujete – odporúčam nie viac ako polovicu voľnej pamäte RAM, pretože zvyšok pôjde pod vyrovnávaciu pamäť stránky.
Okrem toho existujú dve nastavenia úrovne požiadaviek. Prvé nastavenie - použite nekomprimovanú vyrovnávaciu pamäť - zahŕňa jeho použitie. Odporúča sa povoliť pre všetky požiadavky okrem náročných, ktoré dokážu prečítať všetky údaje a vyprázdniť vyrovnávaciu pamäť. A druhé nastavenie je niečo ako maximálny počet riadkov na použitie vyrovnávacej pamäte. Automaticky obmedzuje veľké dopyty tak, aby obchádzali vyrovnávaciu pamäť.
Ako môžem nakonfigurovať storage_configuration pre ukladanie v RAM?
V novej dokumentácii ClickHouse som si prečítal súvisiacu časť . Popis obsahuje príklad s rýchlym SSD.
Zaujímalo by ma, ako sa to isté dá nakonfigurovať s objemovou horúcou pamäťou. A ešte jedna otázka. Ako funguje select s touto organizáciou dát, načíta celú sadu alebo len tú, ktorá je na disku a sú tieto dáta komprimované v pamäti? A ako funguje sekcia prewhere s takouto organizáciou údajov?
Toto nastavenie ovplyvňuje ukladanie dátových blokov a ich formát sa nijako nemení.
Poďme sa na to pozrieť bližšie.
Môžete nakonfigurovať ukladanie údajov do pamäte RAM. Všetko, čo je pre disk nakonfigurované, je jeho cesta. Vytvoríte oddiel tmpfs, ktorý je pripojený k nejakej ceste v systéme súborov. Túto cestu zadáte ako cestu pre ukladanie údajov pre najhorúcejší oddiel, začnú prichádzať a zapisovať sa tam kusy údajov, všetko je v poriadku.
Neodporúčam to však robiť kvôli nízkej spoľahlivosti, hoci ak máte aspoň tri repliky v rôznych dátových centrách, je to možné. Ak sa niečo stane, údaje sa obnovia. Predstavme si, že server bol náhle vypnutý a znova zapnutý. Prepážka bola znovu namontovaná, ale nebolo tam nič. Keď sa server ClickHouse spustí, zistí, že tieto časti nemá, hoci podľa metadát ZooKeeper by tam mali byť. Pozrie sa, ktoré repliky ich majú, vyžiada si ich a stiahne si ich. Týmto spôsobom sa údaje obnovia.
V tomto zmysle sa ukladanie údajov do pamäte RAM zásadne nelíši od ich ukladania na disk, pretože pri zápise údajov na disk tiež najskôr skončia vo vyrovnávacej pamäti stránok a fyzicky sa zapíšu až neskôr. Závisí to od možnosti pripojenia súborového systému. Ale pre každý prípad poviem, že ClickHouse sa pri vkladaní nesynchronizuje.
V tomto prípade sú dáta v RAM uložené presne v rovnakom formáte ako na disku. Výberový dotaz rovnakým spôsobom vyberie časti, ktoré je potrebné prečítať, vyberie potrebné rozsahy údajov v častiach a prečíta ich. A prewhere funguje úplne rovnako, bez ohľadu na to, či boli dáta v RAM alebo na disku.
Do akého počtu jedinečných hodnôt je nízka kardinalita účinná?
Low Cardinality je šikovne navrhnutý. Zostavuje dátové slovníky, ale tie sú lokálne. Po prvé, pre každý kus sú iné slovníky a po druhé, aj v rámci jedného kusu môžu byť pre každý rozsah iné. Keď počet jedinečných hodnôt dosiahne prahové číslo – myslím, že jeden milión – slovník sa jednoducho odloží a vytvorí sa nový.
Odpoveď je všeobecná: pre každý miestny rozsah – povedzme pre každý deň – niekde platí až milión jedinečných hodnôt Nízka mohutnosť. Potom bude jednoducho záložný, v ktorom sa použije veľa rôznych slovníkov, a nie len jeden. Bude fungovať približne rovnako ako bežný reťazec, možno o niečo menej efektívne, ale nedôjde k vážnemu zníženiu výkonu.
Aké sú najlepšie postupy pre fulltextové vyhľadávanie v tabuľke s piatimi miliardami riadkov?
Sú rôzne odpovede. Prvým je povedať, že ClickHouse nie je fulltextový vyhľadávač. Na to existujú špeciálne systémy, napr. и . Čoraz častejšie však vidím ľudí, 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ť záťaž pri niektorých objemoch, počnúc konštrukciou indexov. Indexy sú príliš ťažkopádne a ak jednoducho prenesiete údaje do ClickHouse, ukáže sa, že sú z hľadiska objemu uložené niekoľkonásobne efektívnejšie. Zároveň vyhľadávacie dopyty často neboli také, aby bolo potrebné nájsť nejakú frázu v celom objeme údajov s prihliadnutím na morfológiu, ale úplne iné. Nájdite napríklad nejakú podsekvenciu bajtov v protokoloch za posledných niekoľko hodín.
V tomto prípade vytvoríte index v ClickHouse, ktorého prvé pole bude dátum a čas. A najväčší limit údajov bude založený na rozsahu dátumov. V rámci zvoleného rozsahu dátumov je už spravidla možné vykonať fulltextové vyhľadávanie, a to aj metódou hrubej sily s použitím like. Podobný operátor v ClickHouse je najefektívnejší podobný operátor, aký môžete nájsť. Ak nájdete niečo lepšie, povedzte mi to.
Ale stále, ako je úplné skenovanie. A úplné skenovanie môže byť pomalé nielen na CPU, ale aj na disku. Ak zrazu máte jeden terabajt údajov za deň a hľadáte slovo počas dňa, budete musieť tento terabajt naskenovať. A pravdepodobne je to na bežných pevných diskoch a nakoniec budú načítané tak, že nebudete mať prístup k tomuto serveru cez SSH.
V tomto prípade som pripravený ponúknuť ešte jeden malý trik. Je to experimentálne - môže to fungovať, nemusí. ClickHouse má fulltextové indexy vo forme trigramových Bloom filtrov. Naši kolegovia z Arenadata už tieto indexy vyskúšali a často fungujú presne podľa predstáv.
Aby ste ich mohli správne používať, mali by ste dobre rozumieť tomu, ako presne fungujú: čo je to trigramový Bloom filter a ako zvoliť jeho veľkosť. Môžem povedať, že pomôžu pri dotazoch na niektoré zriedkavé frázy, podreťazce, ktoré sa v údajoch nachádzajú len zriedka. V tomto prípade sa podrozsahy vyberú podľa indexov a načíta sa menej údajov.
Nedávno ClickHouse pridal ešte pokročilejšie funkcie pre fulltextové vyhľadávanie. Toto je po prvé, hľadanie množstva podreťazcov naraz v jednom prechode, vrátane možností, ktoré rozlišujú malé a veľké písmená, nerozlišujú veľké a malé písmená, s podporou UTF-8 alebo len pre ASCII. Vyberte si ten najúčinnejší, ktorý potrebujete.
Objavilo sa aj hľadanie viacerých regulárnych výrazov v jednom prechode. Nemusíte písať X ako jeden podreťazec alebo X ako iný podreťazec. Okamžite píšete a všetko sa robí čo najefektívnejšie.
Po tretie, teraz existuje približné vyhľadávanie regulárnych výrazov a približné vyhľadávanie podreťazcov. Ak niekto nesprávne napíše slovo, bude sa v ňom hľadať maximálna zhoda.
Aký je najlepší spôsob organizácie prístupu k ClickHouse pre veľký počet používateľov?
Povedzte nám, ako najlepšie zorganizovať prístup pre veľký počet spotrebiteľov a analytikov. Ako vytvoriť front, uprednostniť maximálny počet súbežných dopytov a pomocou akých nástrojov?
Ak je klaster dostatočne veľký, dobrým riešením by bolo zvýšiť dva ďalšie servery, ktoré sa stanú vstupným bodom pre analytikov. To znamená, že neumožnite analytikom pristupovať ku konkrétnym fragmentom v klastri, ale jednoducho vytvorte dva prázdne servery bez údajov a nakonfigurujte na nich prístupové práva. V tomto prípade sa používateľské nastavenia pre distribuované požiadavky prenesú na vzdialené servery. To znamená, že všetko nakonfigurujete na týchto dvoch serveroch a nastavenia budú mať vplyv na celý klaster.
V zásade tieto servery nemajú žiadne údaje, ale množstvo pamäte RAM na nich je veľmi dôležité pre vykonávanie požiadaviek. Disk možno použiť aj na dočasné dáta, ak je povolená externá agregácia alebo externé triedenie.
Je dôležité pozrieť sa na nastavenia, ktoré sú spojené so všetkými možnými limitmi. Ak teraz pôjdem do klastra Yandex.Metrica ako analytik a požiadam o žiadosť vyberte počet z hitov, potom mi bude okamžite udelená výnimka, že nemôžem vykonať požiadavku. Maximálny počet riadkov, ktoré môžem naskenovať, je sto miliárd a celkovo ich je v jednej tabuľke na klastri päťdesiat biliónov. Toto je prvé obmedzenie.
Povedzme, že odstránim limit riadkov a znova spustím dotaz. Potom sa mi zobrazí nasledujúca výnimka - nastavenie povolené index sily podľa dátumu. Nemôžem dokončiť dotaz, ak som neurčil rozsah dátumov. Nemusíte sa spoliehať na to, že analytici to špecifikujú manuálne. Typický prípad je, keď je rozsah dátumov napísaný tam, kde je dátum udalosti medzi týždňom. A potom jednoducho špecifikovali zátvorku na nesprávnom mieste a namiesto a ukázalo sa, že je alebo - alebo zhoda URL. Ak neexistuje žiadny limit, prehľadá stĺpec s adresou URL a stratí množstvo zdrojov.
Okrem toho má ClickHouse dve prioritné nastavenia. Bohužiaľ sú veľmi primitívni. Jeden sa jednoducho volá priorita. Ak priorita ≠ 0 a požiadavky s určitou prioritou sa vykonávajú, ale vykonáva sa požiadavka s hodnotou priority menšou ako, čo znamená vyššiu prioritu, potom požiadavka s hodnotou priority vyššou, čo znamená nižšiu prioritu , je jednoducho pozastavený a počas tejto doby nebude fungovať vôbec.
Toto je veľmi hrubé nastavenie a nie je vhodné pre prípady, keď má klaster konštantné zaťaženie. Ale ak máte krátke, nárazové požiadavky, ktoré sú dôležité, a klaster je väčšinou nečinný, toto nastavenie je vhodné.
Volá sa ďalšie nastavenie priority Priorita vlákna OS. Jednoducho nastaví peknú hodnotu pre všetky vlákna vykonávania požiadaviek pre plánovač Linux. Funguje to tak-tak, ale stále to funguje. Ak nastavíte minimálnu hodnotu nice - je to najväčšia hodnota, a teda najnižšia priorita - a nastavíte -19 pre požiadavky s vysokou prioritou, potom CPU spotrebuje požiadavky s nízkou prioritou asi štyrikrát menej ako požiadavky s vysokou prioritou.
Musíte tiež nakonfigurovať maximálny čas vykonania požiadavky - povedzme päť minút. Minimálna rýchlosť vykonávania dotazu je najlepšia vec. Toto nastavenie existuje už dlho a je potrebné nielen potvrdiť, že ClickHouse nespomalí, ale aj vynútiť.
Predstavte si, že ste nastavili: ak niektorý dotaz spracuje menej ako milión riadkov za sekundu, nemôžete to urobiť. To hanobí naše dobré meno, našu dobrú databázu. Len to zakážme. V skutočnosti existujú dve nastavenia. Jeden sa volá min rýchlosť vykonávania - v riadkoch za sekundu a druhý sa nazýva časový limit pred kontrolou minimálnej rýchlosti vykonávania - štandardne pätnásť sekúnd. To znamená, že je možné pätnásť sekúnd a potom, ak je to pomalé, stačí vyvolať výnimku a zrušiť požiadavku.
Musíte tiež nastaviť kvóty. ClickHouse má vstavanú funkciu kvót, ktorá počíta spotrebu zdrojov. Ale, bohužiaľ, nie hardvérové prostriedky, ako sú CPU, disky, ale logické - počet spracovaných požiadaviek, riadkov a prečítaných bajtov. A konfigurovať môžete napríklad maximálne sto požiadaviek do piatich minút a tisíc požiadaviek za hodinu.
Prečo je to dôležité? Pretože niektoré analytické dotazy sa budú vykonávať manuálne priamo z klienta ClickHouse. A všetko bude dobré. Ak však máte vo svojej spoločnosti pokročilých analytikov, napíšu skript a v skripte môže byť chyba. A táto chyba spôsobí, že požiadavka bude vykonaná v nekonečnej slučke. Pred týmto sa musíme chrániť.
Je možné dať výsledky jedného dopytu desiatim klientom?
Máme niekoľko používateľov, ktorí radi prichádzajú s veľkými požiadavkami v rovnakom čase. Žiadosť je veľká a v zásade rýchlo vykonaná, ale vzhľadom na to, že takýchto žiadostí je súčasne veľa, stáva sa veľmi bolestivou. Je možné tú istú požiadavku, ktorá prišla desaťkrát za sebou, vykonať raz a dať výsledok desiatim klientom?
Problém je v tom, že nemáme výsledky vyrovnávacej pamäte alebo vyrovnávacej pamäte medziľahlých údajov. K dispozícii je vyrovnávacia pamäť stránok operačného systému, ktorá vám zabráni v opätovnom čítaní údajov z disku, no, žiaľ, údaje budú stále dekomprimované, deserializované a znova spracované.
Chcel by som sa tomu nejako vyhnúť, či už cachovaním medziľahlých údajov, alebo zoraďovaním podobných dotazov do nejakého frontu a pridávaním cache výsledkov. V súčasnosti máme vo vývoji jednu požiadavku na stiahnutie, ktorá pridáva vyrovnávaciu pamäť požiadaviek, ale iba pre poddotazy v sekciách in a join – to znamená, že riešenie je neúplné.
Aj my však čelíme takejto situácii. Obzvlášť kanonickým príkladom sú stránkované dopyty. Je tam výkaz, má niekoľko strán a je tam požiadavka na limit 10. Potom to isté, ale limit 10,10. Potom ďalšia ďalšia stránka. A otázka je, prečo to všetko zakaždým počítame? Teraz však neexistuje žiadne riešenie a neexistuje spôsob, ako sa mu vyhnúť.
Existuje alternatívne riešenie, ktoré je umiestnené ako postranný vozík vedľa ClickHouse - .
Kirill Shvakov: ClickHouse Proxy má vstavaný obmedzovač rýchlosti a vstavanú vyrovnávaciu pamäť výsledkov. Urobilo sa tam veľa nastavení, pretože sa riešil podobný problém. Proxy vám umožňuje obmedziť požiadavky ich zaradením do frontu a nakonfigurovať, ako dlho žije vyrovnávacia pamäť požiadaviek. Ak boli požiadavky skutočne rovnaké, Proxy ich pošle mnohokrát, ale do ClickHouse pôjde iba raz.
Nginx má tiež vyrovnávaciu pamäť v bezplatnej verzii a bude to tiež fungovať. Nginx má dokonca nastavenia, že ak žiadosti prídu v rovnakom čase, spomalí ostatné, kým sa nedokončí jedna. Ale práve v ClickHouse Proxy sa nastavenie robí oveľa lepšie. Bol vyrobený špeciálne pre ClickHouse, špeciálne pre tieto požiadavky, takže je vhodnejší. No, je ľahké ho nainštalovať.
A čo asynchrónne operácie a materializované pohľady?
Je tu problém, že operácie s replay engine sú asynchrónne – najprv sa dáta zapíšu, potom sa zrútia. Ak pod znakom žije materializovaná tableta s nejakými agregátmi, potom sa do nej zapíšu duplikáty. A ak neexistuje žiadna zložitá logika, údaje sa duplikujú. Čo s tým môžete urobiť?
Existuje zrejmé riešenie - implementovať spúšťač na určitú triedu matviews počas operácie asynchrónneho zrútenia. Existujú nejaké strieborné odrážky alebo plány na implementáciu podobnej funkcie?
Stojí za to pochopiť, ako funguje deduplikácia. To, čo vám teraz poviem, nie je pre túto otázku relevantné, ale pre prípad, že by to stálo za zapamätanie.
Pri vkladaní do replikovanej tabuľky dochádza k deduplikácii celých vložených blokov. Ak znova vložíte rovnaký blok obsahujúci rovnaký počet rovnakých riadkov v rovnakom poradí, údaje sa deduplikujú. Ako odpoveď na vloženie dostanete „OK“, ale v skutočnosti sa zapíše jeden paket údajov, ktorý nebude duplikovaný.
To je potrebné pre istotu. Ak počas vkladania dostanete „OK“, vaše údaje boli vložené. Ak dostanete chybu od ClickHouse, znamená to, že neboli vložené a musíte vloženie zopakovať. Ak sa však spojenie počas vkladania preruší, potom neviete, či boli údaje vložené alebo nie. Jedinou možnosťou je zopakovať vkladanie znova. Ak boli údaje skutočne vložené a vy ste ich znova vložili, došlo k deduplikácii bloku. Je to potrebné, aby sa predišlo duplikáciám.
A je tiež dôležité, ako to funguje pre zhmotnené pohľady. Ak boli údaje pri vkladaní do hlavnej tabuľky deduplikované, neprejdú ani do materializovaného zobrazenia.
Teraz k otázke. Vaša situácia je zložitejšia, pretože evidujete duplikáty jednotlivých riadkov. To znamená, že nie je duplikovaný celý balík, ale konkrétne línie, ktoré sa zrútia na pozadí. V skutočnosti sa údaje v hlavnej tabuľke zbalia, ale nezbalené údaje prejdú do materializovaného zobrazenia a počas zlučovania sa so zhmotnenými zobrazeniami nič nestane. Pretože zhmotnený pohľad nie je nič iné ako spúšťač vloženia. Pri iných operáciách sa s ním nič navyše nedeje.
A nemôžem ťa tu urobiť šťastným. Len treba hľadať konkrétne riešenie pre tento prípad. Je napríklad možné prehrať ho v materializovanom zobrazení a metóda deduplikácie môže fungovať rovnakým spôsobom. Ale bohužiaľ, nie vždy. Ak je to agregované, nebude to fungovať.
Kirill Shvakov: V ten deň sme mali aj stavbu barlí. Vyskytol sa problém, že existujú zobrazenia reklamy a niektoré údaje môžeme zobraziť v reálnom čase – sú to len zobrazenia. Zriedkavo sa duplikujú, ale ak sa to stane, aj tak ich neskôr zbalíme. A boli veci, ktoré sa nedali duplikovať – kliknutia a celý tento príbeh. Ale tiež som ich chcel takmer okamžite ukázať.
Ako vznikali zhmotnené pohľady? Boli pohľady, kde sa to písalo priamo – zapisovalo sa do nespracovaných údajov a zapisovalo sa do pohľadov. Tam v istom momente údaje nie sú veľmi správne, sú duplicitné atď. A je tu druhá časť tabuľky, kde vyzerajú úplne rovnako ako zhmotnené pohľady, to znamená, že majú absolútne rovnakú štruktúru. Raz za čas prepočítame dáta, spočítame dáta bez duplicít, zapíšeme do tých tabuliek.
Prešli sme cez API – v ClickHouse to nebude fungovať manuálne. A API vyzerá: keď mám dátum posledného pridania do tabuľky, kde je zaručené, že už sú vypočítané správne údaje a urobí požiadavku na jednu tabuľku a na druhú tabuľku. Z jedného si požiadavka vyberie do určitého času a z druhého dostane to, čo ešte nebolo vypočítané. A funguje to, ale nie iba prostredníctvom ClickHouse.
Ak máte nejaký druh API - pre analytikov, pre používateľov - potom je to v zásade možnosť. Stále počítate, stále počítate. To možno vykonať raz denne alebo inokedy. Sami si vyberiete rozsah, ktorý nepotrebujete a nie je kritický.
ClickHouse má veľa protokolov. Ako môžem na prvý pohľad vidieť všetko, čo sa deje so serverom?
ClickHouse má veľmi veľký počet rôznych protokolov a tento počet sa zvyšuje. V nových verziách sú niektoré z nich dokonca štandardne povolené, v starších verziách musia byť povolené pri aktualizácii. Je ich však stále viac. Nakoniec by som chcel vidieť, čo sa teraz deje s mojím serverom, možno na nejakom súhrnnom dashboarde.
Máte tím ClickHouse alebo tímy vašich priateľov, ktorí podporujú niektoré funkcie hotových informačných panelov, ktoré by zobrazovali tieto záznamy ako hotový produkt? V konečnom dôsledku je skvelý už len pohľad na záznamy v ClickHouse. Bolo by však veľmi cool, keby už bol pripravený vo forme palubnej dosky. Dostal by som z toho kopu.
Existujú prístrojové dosky, aj keď nie sú štandardizované. V našej spoločnosti používa ClickHouse asi 60 tímov a najzvláštnejšie je, že mnohé z nich majú dashboardy, ktoré si vyrobili pre seba, a trochu iné. Niektoré tímy používajú internú inštaláciu Yandex.Cloud. Existuje niekoľko hotových správ, aj keď nie všetky potrebné. Iní majú svoje.
Moji kolegovia z Metricy majú svoj vlastný prístrojový panel v Grafane a ja mám vlastný pre ich cluster. Pozerám sa na veci ako cache hit pre serif cache. A ešte ťažšie je, že používame rôzne nástroje. Svoj informačný panel som vytvoril pomocou veľmi starého nástroja s názvom Graphite-web. Je úplne škaredý. A takto to používam doteraz, aj keď Grafana by bola asi výhodnejšia a krajšia.
Základná vec v prístrojových doskách je rovnaká. Toto sú systémové metriky pre klaster: CPU, pamäť, disk, sieť. Ostatné - počet simultánnych požiadaviek, počet simultánnych zlúčení, počet požiadaviek za sekundu, maximálny počet chunkov pre oddiely tabuľky MergeTree, oneskorenie replikácie, veľkosť replikačného frontu, počet vložených riadkov za sekundu, počet vložených blokov za sekundu. To je všetko, čo sa nezíska z protokolov, ale z metrík.
Vladimír Kolobajev: Alexey, rád by som to trochu poopravil. Tam je Grafana. Grafana má zdroj údajov, ktorým je ClickHouse. To znamená, že môžem zadávať požiadavky z Grafany priamo ClickHouse. ClickHouse má tabuľku s protokolmi, tá je rovnaká pre všetkých. V dôsledku toho chcem pristupovať k tejto tabuľke denníkov v Grafane a vidieť požiadavky, ktoré odošle môj server. Bolo by skvelé mať takúto palubnú dosku.
Sám som to bicykloval. Ale mám otázku - ak je to všetko štandardizované a Grafana používa každý, prečo Yandex nemá taký oficiálny informačný panel?
Kirill Shvakov: V skutočnosti zdroj údajov, ktorý ide do ClickHouse, teraz podporuje Altinity. A chcem len dať vektor, kde kopať a koho tlačiť. Môžete sa ich opýtať, pretože Yandex stále vyrába ClickHouse, a nie príbeh okolo neho. Altinity je hlavnou spoločnosťou, ktorá v súčasnosti propaguje ClickHouse. Neopustia ho, ale budú ho podporovať. Pretože v zásade sa na nahranie dashboardu na webovú stránku Grafana stačí zaregistrovať a nahrať ho - neexistujú žiadne špeciálne problémy.
Alexey Milovidov: Za posledný rok ClickHouse pridal mnoho možností profilovania dopytov. Pre každú požiadavku existujú metriky využitia zdrojov. A len nedávno sme pridali profilovač dopytov ešte nižšej úrovne, aby sme videli, kde každú milisekundu strávi dopyt. Ale aby som mohol použiť túto funkciu, musím otvoriť konzolového klienta a zadať požiadavku, na ktorú vždy zabudnem. Niekam som si to uložil a stále zabúdam, kde presne.
Prial by som si, aby existoval nástroj, ktorý by práve povedal, tu sú vaše ťažké dotazy zoskupené podľa triedy dotazov. Stlačil som jeden a oni mi povedali, že preto je ťažký. Teraz také riešenie neexistuje. A je naozaj dosť zvláštne, že keď sa ma ľudia pýtajú: „Povedz mi, existujú nejaké hotové dashboardy pre Grafana?“, poviem: „Choď na webovú stránku Grafany, je tam komunita „Dashboards“ a tam je dashboard od Dimka, tam je prístrojová doska od Kostjana. Neviem, čo to je, sám som to nepoužil."
Ako ovplyvniť zlúčenie, aby server nespadol do OOM?
Mám tabuľku, v tabuľke je iba jedna oblasť, je to ReplaceingMergeTree. Údaje som do nej zapisoval štyri roky. Potreboval som to zmeniť a odstrániť niektoré údaje.
Urobil som to a počas spracovania tejto požiadavky bola spotrebovaná všetka pamäť na všetkých serveroch v klastri a všetky servery v klastri prešli do OOM. Potom všetci vstali, začali spájať tú istú operáciu, tento dátový blok a opäť spadli do OOM. Potom opäť vstali a znova spadli. A táto vec sa nezastavila.
Potom sa ukázalo, že to bola v skutočnosti chyba, ktorú chlapci opravili. To je skvelé, ďakujem veľmi pekne. Zostal však zvyšok. A teraz, keď premýšľam o nejakom zlúčení v tabuľke, mám otázku - prečo nemôžem nejako ovplyvniť tieto zlúčenia? Obmedzte ich napríklad množstvom potrebnej pamäte RAM alebo v zásade množstvom, ktoré spracuje túto konkrétnu tabuľku.
Mám tabuľku s názvom „Metriky“, spracujte mi ju v dvoch vláknach. Nie je potrebné vytvárať desať alebo päť spojení paralelne, urobte to v dvoch. Myslím, že mám dosť pamäte na dvoch, ale na spracovanie desiatich to nemusí stačiť. Prečo zostáva strach? Pretože tabuľka sa zväčšuje a raz sa ocitnem v situácii, ktorá už v zásade nie je spôsobená chybou, ale tým, že sa údaje zmenia v takom veľkom množstve, že jednoducho nebudem mať dostatok pamäte na server. A potom server pri zlučovaní spadne do OOM. Navyše, môžem zrušiť mutáciu, ale Merji tam už nie je.
Viete, pri zlučovaní server nespadne do OOM, pretože pri zlučovaní sa množstvo RAM spotrebuje len na jeden malý rozsah údajov. Takže všetko bude v poriadku bez ohľadu na množstvo dát.
Vladimír Kolobajev: Dobre. Tu je moment taký, že po odstránení chyby som si stiahol novú verziu pre seba a na inom stole, menšom, kde je veľa oddielov, som vykonal podobnú operáciu. A počas zlúčenia bolo na serveri spálených asi 100 GB pamäte RAM. Mal som 150 obsadených, 100 zjedených a zostalo mi 50 GB okno, takže som nespadol do OOM.
Čo ma momentálne chráni pred pádom do OOM, ak skutočne spotrebuje 100 GB RAM? Čo robiť, ak sa náhle minie RAM pri zlúčení?
Alexey Milovidov: Je tu taký problém, že spotreba RAM špeciálne na zlúčenie nie je obmedzená. A druhý problém je, že ak bol priradený nejaký druh zlúčenia, musí sa vykonať, pretože je zaznamenaný v protokole replikácie. Protokol replikácie predstavuje akcie, ktoré sú potrebné na uvedenie repliky do konzistentného stavu. Ak nevykonáte manuálne manipulácie, ktoré vrátia tento protokol replikácie späť, zlúčenie sa bude musieť vykonať tak či onak.
Samozrejme, nebolo by zbytočné mať obmedzenie RAM, ktoré „pre každý prípad“ chráni pred OOM. Nepomôže to dokončiť zlúčenie, začne sa znova, dosiahne nejaký prah, vyvolá výnimku a potom začne znova – nič dobré z toho nebude. Ale v zásade by bolo užitočné zaviesť toto obmedzenie.
Ako sa bude vyvíjať ovládač Golang pre ClickHouse?
Ovládač Golang, ktorý napísal Kirill Shvakov, je teraz oficiálne podporovaný tímom ClickHouse. On , teraz je veľký a skutočný.
Malá poznámka. Existuje úžasné a milované úložisko normálnych foriem nekonečného poriadku - to je Vertica. Majú tiež svoj vlastný oficiálny python ovládač, ktorý podporujú vývojári Vertica. A niekoľkokrát sa stalo, že verzie úložiska a verzie ovládača sa dosť dramaticky rozchádzali a ovládač v určitom okamihu prestal fungovať. A druhý bod. Zdá sa mi, že podporu tohto oficiálneho ovládača vykonáva systém „vsuviek“ - napíšete im problém a zostane navždy.
mam dve otazky. Teraz je Kirillov ovládač Golang takmer predvoleným spôsobom komunikácie z Golang s ClickHouse. Pokiaľ niekto stále nekomunikuje cez http rozhranie, lebo sa mu to tak páči. Ako bude vývoj tohto ovládača pokračovať? Bude to synchronizované s nejakými prelomovými zmenami v samotnom úložisku? A aký je postup pri posudzovaní problému?
Kirill Shvakov: Prvým je, ako je všetko byrokraticky organizované. O tomto bode sa nediskutovalo, takže nemám na čo odpovedať.
Aby sme odpovedali na otázku týkajúcu sa problému, potrebujeme malú históriu ovládača. Pracoval som pre spoločnosť, ktorá mala veľa údajov. Bol to reklamný spinner s obrovským množstvom udalostí, ktoré bolo potrebné niekam uložiť. A v určitom okamihu sa objavil ClickHouse. Naplnili sme ho údajmi a spočiatku bolo všetko v poriadku, no potom ClickHouse zlyhal. V tej chvíli sme sa rozhodli, že to nepotrebujeme.
O rok neskôr sme sa vrátili k myšlienke používania ClickHouse a potrebovali sme tam nejakým spôsobom zapisovať dáta. Úvodná hláška znela: hardvér je veľmi slabý, zdrojov je málo. Vždy sme však takto fungovali, a preto sme sa priklonili k natívnemu protokolu.
Keďže sme pracovali v Go, bolo jasné, že potrebujeme vodiča Go. Robil som to takmer na plný úväzok – bola to moja pracovná úloha. Dotiahli sme to do určitého bodu a v zásade nikto nepredpokladal, že by to niekto iný okrem nás použil. Potom prišiel CloudFlare presne s rovnakým problémom a nejaký čas sme s nimi pracovali veľmi hladko, pretože mali rovnaké úlohy. Navyše sme to urobili v ClickHouse sami aj v ovládači.
V určitom momente som to jednoducho prestal robiť, pretože moja činnosť v rámci ClickHouse a práce sa trochu zmenila. Problémy preto nie sú uzavreté. Ľudia, ktorí sami niečo potrebujú, sa pravidelne zaväzujú k úložisku. Potom sa pozriem na požiadavku na stiahnutie a niekedy aj sám niečo upravím, ale to sa stáva zriedka.
Chcem sa vrátiť k vodičovi. Pred niekoľkými rokmi, keď sa to celé začalo, bol ClickHouse tiež iný a mal iné schopnosti. Teraz už rozumieme tomu, ako prerobiť ovládač tak, aby fungoval dobre. Ak sa tak stane, verzia 2 bude v každom prípade nekompatibilná kvôli nahromadeným barličkám.
Neviem, ako túto záležitosť zorganizovať. Sama nemám veľa času. Ak niektorí dokončia vodičák, môžem im pomôcť a povedať im, čo majú robiť. O aktívnej účasti spoločnosti Yandex na vývoji projektu sa však ešte nehovorilo.
Alexey Milovidov: V skutočnosti zatiaľ s týmito vodičmi neexistuje žiadna byrokracia. Jediná vec je, že sú predložené oficiálnej organizácii, to znamená, že tento ovládač je uznávaný ako oficiálne predvolené riešenie pre Go. Existuje niekoľko ďalších ovládačov, ale prichádzajú samostatne.
Pre tieto ovládače nemáme žiadny interný vývoj. Otázkou je, či dokážeme najať jednotlivca, nie pre tohto konkrétneho vodiča, ale pre rozvoj všetkých vodičov komunity, alebo nájdeme niekoho zvonku.
Externý slovník sa po reštarte s povoleným nastavením lazy_load nenačíta. Čo robiť?
Máme povolené nastavenie lazy_load a po reštarte servera sa slovník nenačíta sám. Vyvolá sa až potom, čo používateľ pristúpi k tomuto slovníku. A keď k nemu pristúpim prvýkrát, zobrazí sa chyba. Je možné nejakým spôsobom automaticky načítať slovníky pomocou ClickHouse, alebo je potrebné vždy kontrolovať ich pripravenosť sami, aby používatelia nedostali chyby?
Možno máme starú verziu ClickHouse, takže slovník sa nenačítal automaticky. Môže to byť tento prípad?
Po prvé, slovníky je možné vynútiť pomocou dotazu slovníky na opätovné načítanie systému. Po druhé, pokiaľ ide o chybu - ak je slovník už načítaný, dotazy budú fungovať na základe načítaných údajov. Ak slovník ešte nebol načítaný, načíta sa priamo počas požiadavky.
To nie je príliš vhodné pre ťažké slovníky. Napríklad potrebujete stiahnuť milión riadkov z MySQL. Niekto urobí jednoduchý výber, ale tento výber bude čakať na rovnaký milión riadkov. Tu sú dve riešenia. Prvým je vypnutie lazy_load. Po druhé, keď je server v prevádzke, pred vložením záťaže naň urobte systémový reload slovník alebo jednoducho urobte dotaz, ktorý používa slovník. Potom sa načíta slovník. Dostupnosť slovníkov musíte ovládať so zapnutým nastavením lazy_load, pretože ClickHouse ich nenačítava automaticky.
Odpoveď na poslednú otázku je buď verzia je stará, alebo ju treba odladiť.
Čo robiť s tým, že slovníky pre opätovné načítanie systému nenačítajú žiadny z množstva slovníkov, ak aspoň jeden z nich spadne s chybou?
Existuje ďalšia otázka týkajúca sa slovníkov na obnovenie systému. Máme dva slovníky – jeden sa nenačíta, druhý sa načíta. V tomto prípade System reload dictionaries nenačítava žiadny slovník a vy musíte bod po bode načítať konkrétny podľa jeho názvu pomocou system reload dictionary. Súvisí to aj s verziou ClickHouse?
Chcem ti urobiť radosť. Toto správanie sa menilo. To znamená, že ak aktualizujete ClickHouse, zmení sa aj to. Ak nie ste spokojní so svojím súčasným správaním slovníky na opätovné načítanie systému, aktualizujte a dúfajme, že sa to zmení k lepšiemu.
Existuje spôsob, ako nakonfigurovať podrobnosti v konfigurácii ClickHouse, ale nezobrazovať ich v prípade chýb?
Ďalšia otázka sa týka chýb súvisiacich so slovníkom, konkrétne podrobností. Podrobnosti o pripojení sme špecifikovali v konfigurácii ClickHouse pre slovník a ak sa vyskytne chyba, dostaneme tieto podrobnosti a heslo ako odpoveď.
Túto chybu sme vyriešili pridaním podrobností do konfigurácie ovládača ODBC. Existuje nejaký spôsob, ako nakonfigurovať podrobnosti v konfigurácii ClickHouse, ale nezobraziť tieto podrobnosti v prípade chýb?
Skutočným riešením je zadať tieto poverenia v odbc.ini a v samotnom ClickHouse zadať iba názov zdroja údajov ODBC. To sa nestane pre iné zdroje slovníkov - ani pre slovník s MySQL, ani pre ostatné, by ste nemali vidieť heslo, keď dostanete chybové hlásenie. V prípade ODBC sa tiež pozriem - ak existuje, stačí ho odstrániť.
Bonus: pozadia pre Zoom zo stretnutí
Kliknutím na obrázok sa pre najvytrvalejších čitateľov otvoria bonusové pozadia zo stretnutí. Hasíme spolu s maskotmi technológie Avito, radíme sa s kolegami z miestnosti správcu systému či oldschoolového počítačového klubu a vedieme denné stretnutia pod mostom na pozadí graffiti.
Zdroj: hab.com