Keďže ClickHouse je špecializovaný systém, pri jeho používaní je dôležité brať do úvahy vlastnosti jeho architektúry. V tejto správe bude Alexey hovoriť o príkladoch bežných chýb pri používaní ClickHouse, ktoré môžu viesť k neefektívnej práci. Praktické príklady ukážu, ako môže výber jednej alebo druhej schémy spracovania údajov zmeniť výkon rádovo.
Ahojte všetci! Volám sa Alexey, vyrábam ClickHouse.
Po prvé, ponáhľam sa vás hneď potešiť, dnes vám nepoviem, čo je ClickHouse. Úprimne povedané, som z toho unavený. Zakaždým, keď ti poviem, čo to je. A to už asi každý vie.
Namiesto toho vám poviem, aké sú tam možné chyby, teda ako môžete ClickHouse používať nesprávne. V skutočnosti sa toho netreba báť, pretože ClickHouse vyvíjame ako systém, ktorý je jednoduchý, pohodlný a funguje hneď po vybalení. Nainstaloval som, bez problemov.
Stále ale treba počítať s tým, že tento systém je špecializovaný a ľahko môžete naraziť na nezvyčajný prípad použitia, ktorý tento systém vyvedie z komfortnej zóny.
Takže, aké sú tam hrable? Väčšinou budem hovoriť o samozrejmých veciach. Všetkým je všetko jasné, každý všetkému rozumie a môže byť rád, že je taký šikovný, a kto nerozumie, naučí sa niečo nové.
Prvým a najjednoduchším príkladom, ktorý sa, žiaľ, často vyskytuje, je veľké množstvo vložiek s malými šaržami, t. j. veľké množstvo malých vložiek.
Ak vezmeme do úvahy, ako ClickHouse vykonáva vkladanie, potom môžete poslať aspoň terabajt údajov v jednej žiadosti. To nie je problém.
A pozrime sa, aký by bol typický výkon. Napríklad máme tabuľku z údajov Yandex.Metrica. Hity. 105 niektoré stĺpce. 700 bajtov nekomprimovaných. A vložíme v pohode v dávkach po milión riadkov.
Vložíme MergeTree do tabuľky, ukáže sa pol milióna riadkov za sekundu. Skvelé. V replikovanej tabuľke bude o niečo menšia, približne 400 000 riadkov za sekundu.
A ak povolíte vkladanie kvóra, získate o niečo menší, ale stále slušný výkon, 250 000 výrazov za sekundu. Vkladanie kvóra je nezdokumentovaná funkcia v ClickHouse*.
*od roku 2020, .
Čo sa stane, ak urobíte niečo zlé? Vložíme jeden riadok do tabuľky MergeTree a získame 59 riadkov za sekundu. To je 10 000 krát pomalšie. V ReplicatedMergeTree – 6 riadkov za sekundu. A ak je kvórum zapnuté, ukáže sa to 2 riadky za sekundu. Podľa mňa je to absolútna kravina. Ako môžeš takto spomaliť? Dokonca mám na tričku napísané, že ClickHouse by nemal spomaliť. Ale aj tak sa to občas stáva.
V skutočnosti je to náš nedostatok. Mohli sme ľahko zabezpečiť, aby všetko fungovalo dobre, ale nepodarilo sa nám to. A neurobili sme to, pretože náš scenár to nevyžadoval. Už sme mali mäsiarov. Práve sme dostali dávky pri našom vchode a žiadne problémy. Vložíme ho a všetko funguje dobre. Ale, samozrejme, sú možné všetky možné scenáre. Napríklad, keď máte veľa serverov, na ktorých sa generujú údaje. A nevkladajú údaje tak často, ale stále končia pri častých vkladoch. A tomu sa musíme nejako vyhnúť.
Z technického hľadiska ide o to, že keď urobíte insert v ClickHouse, dáta neskončia v žiadnej pamäti. Nemáme ani skutočnú štruktúru denníka MergeTree, ale iba MergeTree, pretože neexistuje ani denník, ani memTable. Dáta jednoducho okamžite zapíšeme do súborového systému, už usporiadané v stĺpcoch. A ak máte 100 stĺpcov, potom bude potrebné zapísať viac ako 200 súborov do samostatného adresára. To všetko je veľmi ťažkopádne.
A vyvstáva otázka: "Ako to urobiť správne?" Ak je situácia taká, že stále potrebujete nejakým spôsobom zaznamenávať údaje v ClickHouse.
Metóda 1. Toto je najjednoduchší spôsob. Použite nejaký druh distribuovaného frontu. Napríklad Kafka. Jednoducho vytiahnete dáta z Kafky a dávkujete ich raz za sekundu. A všetko bude v poriadku, nahrávate, všetko funguje dobre.
Nevýhody sú, že Kafka je ďalší objemný distribuovaný systém. Chápem aj to, ak už máte vo firme Kafku. Je to dobré, pohodlné. Ak však neexistuje, mali by ste sa trikrát zamyslieť, kým do svojho projektu vtiahnete ďalší distribuovaný systém. A preto sa oplatí zvážiť alternatívy.
Metóda 2. Toto je alternatíva zo starej školy a zároveň veľmi jednoduchá. Máte nejaký server, ktorý generuje vaše denníky. A len zapíše vaše záznamy do súboru. A napríklad raz za sekundu premenujeme tento súbor a odtrhneme nový. A samostatný skript, buď cez cron alebo nejakého démona, vezme najstarší súbor a zapíše ho do ClickHouse. Ak budete zaznamenávať protokoly raz za sekundu, všetko bude v poriadku.
Nevýhodou tejto metódy však je, že ak niekde zmizne váš server, na ktorom sa generujú protokoly, zmiznú aj údaje.
Metóda 3. Existuje ďalšia zaujímavá metóda, ktorá vôbec nevyžaduje dočasné súbory. Napríklad máte nejaký reklamný spinner alebo iného zaujímavého démona, ktorý generuje dáta. A môžete hromadiť množstvo údajov priamo v RAM, vo vyrovnávacej pamäti. A keď uplynie dostatok času, odložíte tento buffer, vytvoríte nový a do samostatného vlákna vložíte to, čo sa už nahromadilo do ClickHouse.
Na druhej strane údaje zmiznú aj s kill -9. Ak váš server zlyhá, stratíte tieto údaje. Ďalším problémom je, že ak ste nemohli zapisovať do databázy, vaše dáta sa nahromadia v RAM. A buď sa minie RAM, alebo jednoducho prídete o dáta.
Metóda 4. Ďalšia zaujímavá metóda. Máte nejaký serverový proces. A dokáže odosielať údaje do ClickHouse okamžite, ale urobte to v jednom pripojení. Napríklad som poslal požiadavku http s kódovaním prenosu: chunked with insert. A generuje kúsky nie príliš zriedka, môžete poslať každý riadok, aj keď bude existovať réžia na rámcovanie týchto údajov.
V tomto prípade však budú údaje okamžite odoslané spoločnosti ClickHouse. A ClickHouse ich bude vyrovnávať sám.
Ale vznikajú aj problémy. Teraz prídete o údaje, a to aj vtedy, keď je váš proces zabitý a ak je zabitý proces ClickHouse, pretože to bude neúplná vložka. A v ClickHouse sú vložky atómové až do určitej špecifikovanej hranice veľkosti riadkov. V princípe je to zaujímavý spôsob. Dá sa tiež použiť.
Metóda 5. Tu je ďalšia zaujímavá metóda. Toto je nejaký komunitou vyvinutý server na dávkovanie údajov. Sám som to nepozeral, takže nemôžem zaručiť nič. Na samotný ClickHouse však nie sú poskytované žiadne záruky. Toto je tiež open source, ale na druhej strane môžete byť zvyknutí na nejaký štandard kvality, ktorý sa snažíme poskytnúť. Ale pre túto vec - neviem, choďte na GitHub, pozrite sa na kód. Možno napísali niečo normálne.
* od roku 2020 by sa malo tiež zvážiť .
Metóda 6. Ďalšou metódou je použitie vyrovnávacích tabuliek. Výhodou tejto metódy je, že je veľmi jednoduché ju začať používať. Vytvorte tabuľku vyrovnávacej pamäte a vložte ju do nej.
Nevýhodou je, že problém nie je úplne vyriešený. Ak pri rýchlosti, ako je MergeTree, musíte zoskupiť údaje podľa jednej dávky za sekundu, potom pri rýchlosti v tabuľke vyrovnávacej pamäte musíte zoskupiť aspoň niekoľko tisíc za sekundu. Ak je to viac ako 10 000 za sekundu, stále to bude zlé. A ak ho vložíte v dávkach, uvidíte, že je to stotisíc riadkov za sekundu. A to je už na dosť ťažkých dátach.
A tiež vyrovnávacie tabuľky nemajú protokol. A ak je s vaším serverom niečo v neporiadku, údaje sa stratia.
A ako bonus sme nedávno dostali v ClickHouse možnosť získať dáta od Kafku. Je tu stolový motor - Kafka. Jednoducho tvoríte. A môžete naň zavesiť zhmotnené reprezentácie. V tomto prípade si sám vytiahne údaje z Kafky a vloží ich do tabuliek, ktoré potrebujete.
A čo je na tejto príležitosti obzvlášť potešujúce je, že sme to neboli my, kto to urobil. Toto je funkcia komunity. A keď hovorím „funkcia komunity“, myslím to bez akéhokoľvek pohŕdania. Prečítali sme si kód, urobili kontrolu, malo by to fungovať dobre.
* od roku 2020 sa objavila podobná podpora .
Čo ešte môže byť nepohodlné alebo neočakávané pri vkladaní údajov? Ak požiadate o vloženie hodnôt a zapíšete do hodnôt nejaké vypočítané výrazy. Napríklad now() je tiež vypočítaný výraz. A v tomto prípade je ClickHouse nútený spustiť prekladač týchto výrazov na každom riadku a výkon klesne rádovo. Tomu je lepšie sa vyhnúť.
* momentálne je problém úplne vyriešený, pri použití výrazov v VALUES už nedochádza k žiadnej výkonnostnej regresii.
Ďalším príkladom je situácia, keď môžu nastať nejaké problémy, keď máte údaje na jednej dávke, ktorá patrí do viacerých oddielov. V predvolenom nastavení sú oddiely ClickHouse podľa mesiaca. A ak vložíte dávku miliónov riadkov a sú tam dáta na niekoľko rokov, tak tam budete mať niekoľko desiatok partícií. A to je ekvivalentné tomu, že budú dávky niekoľko desiatok krát menšie, pretože vo vnútri sú vždy najskôr rozdelené na oddiely.
* Nedávno, v experimentálnom režime, ClickHouse pridal podporu pre kompaktný formát blokov a blokov v pamäti RAM s protokolom zápisu vopred, čo takmer úplne rieši problém.
Teraz sa pozrime na druhý typ problému – zadávanie údajov.
Zadávanie údajov môže byť prísne alebo reťazcové. Reťazec je, keď ste ho práve vzali a vyhlásili, že všetky vaše polia sú typu string. Toto je na hovno. Nie je potrebné to robiť.
Poďme prísť na to, ako to urobiť správne v tých prípadoch, keď chcete povedať, že máme nejaké pole, reťazec, a nechajte ClickHouse, aby si to vyriešil sám, a nebudem sa obťažovať. Ale stále stojí za to vynaložiť trochu úsilia.
Napríklad máme IP adresu. V jednom prípade sme ho uložili ako reťazec. Napríklad 192.168.1.1. A v inom prípade to bude číslo typu UInt32*. Na adresu IPv32 stačí 4 bitov.
Po prvé, napodiv, údaje budú komprimované približne rovnako. Rozdiel tam samozrejme bude, ale nie až taký veľký. Takže neexistujú žiadne špeciálne problémy s diskovými I/O.
Existuje však vážny rozdiel v čase procesora a čase vykonania dotazu.
Spočítajme počet jedinečných IP adries, ak sú uložené ako čísla. To vychádza na 137 miliónov riadkov za sekundu. Ak je to isté vo forme reťazcov, potom 37 miliónov riadkov za sekundu. Neviem, prečo sa táto náhoda stala. Sám som tieto požiadavky zrealizoval. Ale stále asi 4x pomalšie.
A ak vypočítate rozdiel v priestore na disku, potom je tu tiež rozdiel. A rozdiel je asi jedna štvrtina, pretože existuje pomerne veľa jedinečných IP adries. A ak by existovali riadky s malým počtom rôznych významov, potom by sa ľahko skomprimovali podľa slovníka do približne rovnakého objemu.
A štvornásobný časový posun neleží na ceste. Možno vám to je jedno, samozrejme, ale keď vidím taký rozdiel, je mi z toho smutno.
Pozrime sa na rôzne prípady.
1. Jeden prípad, keď máte niekoľko rôznych jedinečných hodnôt. V tomto prípade používame jednoduchú prax, ktorú pravdepodobne poznáte a môžete ju použiť pre akýkoľvek DBMS. Toto všetko dáva zmysel nielen pre ClickHouse. Stačí zapísať číselné identifikátory do databázy. A môžete previesť na reťazce a späť na strane vašej aplikácie.
Napríklad máte región. A snažíte sa ho uložiť ako reťazec. A bude tam napísané: Moskva a Moskovský región. A keď vidím, že je napísané „Moskva“, nič to nie je, ale keď je to Moskva, je to akosi úplne smutné. To je koľko bajtov.
Namiesto toho si jednoducho zapíšeme číslo Ulnt32 a 250. V Yandex máme 250, ale váš môže byť iný. Pre každý prípad poviem, že ClickHouse má vstavanú schopnosť pracovať s geobázou. Jednoducho si zapíšete adresár s regiónmi, vrátane hierarchického, t.j. bude tam Moskva, Moskovský región a všetko, čo potrebujete. A môžete konvertovať na úrovni požiadavky.
Druhá možnosť je približne rovnaká, ale s podporou vo vnútri ClickHouse. Toto je typ údajov Enum. Do Enum jednoducho napíšete všetky potrebné hodnoty. Napríklad typ zariadenia a tam napíšte: desktop, mobil, tablet, TV. Celkom sú 4 možnosti.
Nevýhodou je, že ho musíte pravidelne meniť. Pridaná len jedna možnosť. Urobme zmenu tabuľky. V skutočnosti je alter table v ClickHouse zadarmo. Zvlášť zadarmo pre Enum, pretože dáta na disku sa nemenia. Ale napriek tomu alter získa zámok* na stole a musí počkať, kým sa nevykonajú všetky výbery. A až po vykonaní tejto zmeny, t.j. stále existujú nejaké nepríjemnosti.
* v najnovších verziách ClickHouse je ALTER vyrobený úplne bez blokovania.
Ďalšou možnosťou, ktorá je pre ClickHouse celkom jedinečná, je pripojenie externých slovníkov. V ClickHouse môžete písať čísla a uchovávať svoje adresáre v akomkoľvek systéme, ktorý vám vyhovuje. Môžete napríklad použiť: MySQL, Mongo, Postgres. Môžete si dokonca vytvoriť vlastnú mikroslužbu, ktorá bude tieto údaje odosielať cez http. A na úrovni ClickHouse napíšete funkciu, ktorá prevedie tieto údaje z čísel na reťazce.
Toto je špecializovaný, ale veľmi efektívny spôsob vykonania spojenia na externej tabuľke. A sú dve možnosti. V jednom uskutočnení budú tieto dáta úplne uložené do vyrovnávacej pamäte, plne prítomné v RAM a aktualizované s určitou frekvenciou. A v inej možnosti, ak sa tieto údaje nezmestia do pamäte RAM, môžete ich čiastočne uložiť do vyrovnávacej pamäte.
Tu je príklad. Existuje Yandex.Direct. A je tu reklamná spoločnosť a bannery. Reklamných spoločností sú pravdepodobne asi desiatky miliónov. A zhruba sa zmestia do RAM. A existujú miliardy bannerov, ktoré sa nehodia. A používame slovník uložený vo vyrovnávacej pamäti z MySQL.
Jediným problémom je, že slovník uložený vo vyrovnávacej pamäti bude fungovať správne, ak sa miera prístupu blíži k 100 %. Ak je menší, potom pri spracovaní dotazov pre každú dávku údajov budete musieť v skutočnosti vziať chýbajúce kľúče a získať údaje z MySQL. Čo sa týka ClickHouse, stále to môžem zaručiť - áno, nespomalí sa, nebudem hovoriť o iných systémoch.
A ako bonus sú slovníky veľmi jednoduchým spôsobom spätnej aktualizácie údajov v ClickHouse. To znamená, že ste mali prehľad o reklamných spoločnostiach, používateľ jednoducho zmenil reklamnú spoločnosť a vo všetkých starých údajoch sa vo všetkých prehľadoch zmenili aj tieto údaje. Ak zapíšete riadky priamo do tabuľky, nebude možné ich aktualizovať.
Ďalší spôsob, keď neviete, kde získať identifikátory pre vaše reťazce. môžete to jednoducho hashovať. Najjednoduchšou možnosťou je navyše použiť 64-bitový hash.
Jediným problémom je, že ak je hash 64-bitový, takmer určite budete mať kolízie. Pretože ak je tam miliarda riadkov, pravdepodobnosť je už zrejmá.
A takto hašovať názvy reklamných spoločností by nebolo veľmi dobré. Ak sa reklamné kampane rôznych spoločností zmiešajú, bude tam niečo nepochopiteľné.
A existuje jednoduchý trik. Je pravda, že to tiež nie je príliš vhodné pre seriózne údaje, ale ak niečo nie je veľmi závažné, stačí pridať identifikátor klienta do kľúča slovníka. A potom budete mať kolízie, ale len v rámci jedného klienta. A túto metódu používame pre mapy odkazov v Yandex.Metrica. Máme tam adresy URL, ukladáme hashe. A vieme, že samozrejme dochádza ku kolíziám. Keď sa však stránka zobrazí, pravdepodobnosť, že na jednej stránke jedného používateľa sú nejaké adresy URL zlepené pohromade a bude to zaznamenané, môže byť zanedbaná.
Bonusom je, že pre mnohé operácie postačujú samotné hashe a samotné reťazce nie je potrebné nikde ukladať.
Ďalším príkladom je, ak sú reťazce krátke, napríklad domény webových stránok. Môžu byť uložené tak, ako sú. Alebo napríklad jazyk prehliadača ru je 2 bajty. Samozrejme, je mi ľúto tých bajtov, ale nebojte sa, 2 bajty nie sú škoda. Prosím, ponechajte to tak, ako je, nebojte sa.
Iný prípad je, keď je naopak línií veľa a je v nich veľa unikátov a aj zostava je potenciálne neobmedzená. Typickým príkladom sú hľadané frázy alebo adresy URL. Hľadané frázy vrátane preklepov. Pozrime sa, koľko jedinečných vyhľadávacích fráz je za deň. A ukazuje sa, že sú takmer polovicou všetkých udalostí. A v tomto prípade si možno myslíte, že musíte normalizovať údaje, spočítať identifikátory a umiestniť ich do samostatnej tabuľky. Ale nemusíte to robiť. Len ponechajte tieto riadky tak, ako sú.
Je lepšie nič nevymýšľať, pretože ak to uložíte samostatne, budete sa musieť pripojiť. A toto spojenie je v najlepšom prípade náhodný prístup k pamäti, ak sa ešte zmestí do pamäte. Ak sa nezmestí, nastanú problémy.
A ak sú dáta uložené na mieste, potom sa jednoducho načítajú v požadovanom poradí zo súborového systému a všetko je v poriadku.
Ak máte adresy URL alebo nejaký iný zložitý dlhý reťazec, potom stojí za zváženie, že si môžete vopred vypočítať nejaký extrakt a zapísať ho do samostatného stĺpca.
Pre adresy URL môžete napríklad uložiť doménu samostatne. A ak naozaj potrebujete doménu, použite tento stĺpec a adresy URL tam budú ležať a ani sa ich nedotknete.
Pozrime sa, aký je rozdiel. ClickHouse má špecializovanú funkciu, ktorá vypočítava doménu. Je veľmi rýchly, optimalizovali sme ho. A úprimne povedané, nespĺňa ani RFC, no napriek tomu zohľadňuje všetko, čo potrebujeme.
A v jednom prípade jednoducho získame adresy URL a vypočítame doménu. To vychádza na 166 milisekúnd. A ak si vezmete hotovú doménu, ukáže sa to len 67 milisekúnd, teda takmer trikrát rýchlejšie. A je to rýchlejšie nie preto, že potrebujeme robiť nejaké výpočty, ale preto, že čítame menej údajov.
Preto jedna požiadavka, ktorá je pomalšia, má vyššiu rýchlosť gigabajtov za sekundu. Pretože číta viac gigabajtov. Ide o úplne zbytočné údaje. Zdá sa, že žiadosť beží rýchlejšie, no jej dokončenie trvá dlhšie.
A ak sa pozriete na množstvo údajov na disku, ukáže sa, že adresa URL je 126 megabajtov a doména iba 5 megabajtov. Ukazuje sa to 25-krát menej. Žiadosť je však vykonaná iba 4-krát rýchlejšie. Ale to preto, že dáta sú horúce. A ak by bola zima, pravdepodobne by to bolo 25-krát rýchlejšie kvôli diskovým vstupom a výstupom.
Mimochodom, ak odhadnete, o koľko je doména menšia ako adresa URL, ukáže sa, že je asi 4-krát menšia. Ale z nejakého dôvodu zaberajú dáta na disku 25-krát menej. prečo? Kvôli kompresii. A adresa URL je komprimovaná a doména je komprimovaná. Adresa URL však často obsahuje veľa odpadu.
A samozrejme sa oplatí používať správne dátové typy, ktoré sú navrhnuté špeciálne pre požadované hodnoty alebo ktoré sú vhodné. Ak používate IPv4, uložte UInt32*. Ak IPv6, tak FixedString(16), pretože adresa IPv6 je 128 bitová, teda uložená priamo v binárnom formáte.
Ale čo ak máte niekedy adresy IPv4 a niekedy IPv6? Áno, môžete uložiť oboje. Jeden stĺpec pre IPv4, druhý pre IPv6. Samozrejmosťou je možnosť zobrazenia IPv4 v IPv6. To bude tiež fungovať, ale ak často potrebujete adresu IPv4 v požiadavkách, bolo by pekné dať ju do samostatného stĺpca.
* ClickHouse má teraz samostatné dátové typy IPv4, IPv6, ktoré ukladajú dáta rovnako efektívne ako čísla, no reprezentujú ich rovnako pohodlne ako reťazce.
Je tiež dôležité poznamenať, že sa oplatí vopred spracovať údaje. Napríklad dostanete nejaké surové protokoly. A možno by ste ich nemali hneď vložiť do ClickHouse, hoci je veľmi lákavé nerobiť nič a všetko bude fungovať. Stále však stojí za to vykonať výpočty, ktoré sú možné.
Napríklad verzia prehliadača. V nejakom neďalekom oddelení, na ktoré nechcem ukazovať prstom, je verzia prehliadača uložená takto, teda ako reťazec: 12.3. A potom, aby vytvorili správu, vezmú tento reťazec a rozdelia ho na pole a potom na prvý prvok poľa. Prirodzene, všetko sa spomalí. Spýtal som sa, prečo to robia. Povedali mi, že nemajú radi predčasnú optimalizáciu. A nemám rád predčasnú pesimizáciu.
Takže v tomto prípade by bolo správnejšie rozdeliť do 4 stĺpcov. Tu sa nebojte, pretože toto je ClickHouse. ClickHouse je stĺpcová databáza. A čím viac úhľadných malých stĺpcov, tým lepšie. Bude 5 verzií prehliadača, vytvorte 5 stĺpcov. Toto je fajn.
Teraz sa pozrime na to, čo robiť, ak máte veľa veľmi dlhých reťazcov, veľmi dlhých polí. V ClickHouse ich vôbec netreba skladovať. Namiesto toho môžete v ClickHouse uložiť iba identifikátor. A vložte tieto dlhé riadky do nejakého iného systému.
Jedna z našich analytických služieb má napríklad parametre udalosti. A ak existuje veľa parametrov pre udalosti, jednoducho uložíme prvých 512, ktoré sa objavia. Pretože 512 nie je škoda.
A ak sa nemôžete rozhodnúť pre svoje typy údajov, potom môžete údaje zaznamenávať aj v ClickHouse, ale v dočasnej tabuľke typu Log, špeciálnej pre dočasné údaje. Potom môžete analyzovať, aké rozdelenie hodnôt tam máte, čo tam je vo všeobecnosti a vytvoriť správne typy.
*ClickHouse má teraz typ údajov čo umožňuje efektívne ukladanie strún s menšou námahou.
Teraz sa pozrime na ďalší zaujímavý prípad. Niekedy veci fungujú na ľudí zvláštne. Prídem a uvidím toto. A hneď sa zdá, že to urobil nejaký veľmi skúsený, šikovný admin, ktorý má bohaté skúsenosti s nastavením MySQL verzie 3.23.
Tu vidíme tisíc tabuliek, z ktorých každá zaznamenáva zvyšok delenia ktovie čoho tisícmi.
V zásade rešpektujem skúsenosti iných ľudí, vrátane pochopenia utrpenia, ktoré sa dá touto skúsenosťou získať.
A dôvody sú viac-menej jasné. Sú to staré stereotypy, ktoré sa mohli nahromadiť pri práci s inými systémami. Napríklad tabuľky MyISAM nemajú klastrovaný primárny kľúč. A tento spôsob delenia dát môže byť zúfalým pokusom získať rovnakú funkcionalitu.
Ďalším dôvodom je, že je ťažké vykonávať akékoľvek zmeny operácií na veľkých stoloch. Všetko bude zablokované. Aj keď v moderných verziách MySQL už tento problém nie je taký vážny.
Alebo napríklad microsharding, ale o tom neskôr.
V ClickHouse to nie je potrebné robiť, pretože po prvé, primárny kľúč je zoskupený, údaje sú usporiadané podľa primárneho kľúča.
A niekedy sa ma ľudia pýtajú: „Ako sa mení výkon dotazov na rozsah v ClickHouse v závislosti od veľkosti tabuľky? Hovorím, že sa to vôbec nemení. Napríklad máte tabuľku s miliardou riadkov a čítate rozsah jedného milióna riadkov. Všetko je v poriadku. Ak je v tabuľke bilión riadkov a prečítate jeden milión riadkov, bude to takmer to isté.
A po druhé, nie sú potrebné všetky druhy vecí, ako sú manuálne oddiely. Ak vojdete dnu a pozriete sa, čo je na súborovom systéme, uvidíte, že tabuľka je dosť veľká vec. A vo vnútri je niečo ako priečky. To znamená, že ClickHouse urobí všetko za vás a vy nemusíte trpieť.
Zmeniť v ClickHouse je zadarmo, ak zmeníte stĺpec Pridať/Povoliť.
A nemali by ste robiť malé tabuľky, pretože ak máte v tabuľke 10 riadkov alebo 10 000 riadkov, potom na tom vôbec nezáleží. ClickHouse je systém, ktorý optimalizuje priepustnosť, nie latenciu, takže nemá zmysel spracovávať 10 riadkov.
Je správne použiť jeden veľký stôl. Zbavte sa starých stereotypov, všetko bude v poriadku.
A ako bonus, v najnovšej verzii máme teraz možnosť vytvoriť ľubovoľný rozdeľovací kľúč na vykonávanie najrôznejších operácií údržby na jednotlivých oddieloch.
Napríklad potrebujete veľa malých tabuliek, napríklad keď je potrebné spracovať nejaké prechodné dáta, dostanete kúsky a musíte na nich vykonať transformáciu pred zápisom do konečnej tabuľky. Pre tento prípad je tu nádherný stolový engine – StripeLog. Je to niečo ako TinyLog, len lepšie.
* teraz má aj ClickHouse .
Ďalším antivzorom je microsharding. Napríklad potrebujete shardovať dáta a máte 5 serverov a zajtra tu bude 6 serverov. A premýšľate o tom, ako tieto údaje vyvážiť. A namiesto toho sa nerozbijete na 5 úlomkov, ale na 1 000 úlomkov. A potom namapujete každý z týchto mikroúlomkov na samostatný server. A získate napríklad 200 ClickHouses na jednom serveri. Samostatné inštancie na samostatných portoch alebo samostatných databázach.
To však v ClickHouse nie je veľmi dobré. Pretože aj jedna inštancia ClickHouse sa snaží využiť všetky dostupné zdroje servera na spracovanie jednej požiadavky. To znamená, že máte nejaký server a ten má napríklad 56 procesorových jadier. Spúšťate dotaz, ktorý trvá jednu sekundu a bude používať 56 jadier. A ak tam umiestnite 200 ClickHouses na jeden server, potom sa ukáže, že sa spustí 10 000 vlákien. Vo všeobecnosti bude všetko veľmi zlé.
Ďalším dôvodom je, že rozdelenie práce v týchto prípadoch bude nerovnomerné. Niektorí skončia skôr, niektorí neskôr. Ak by sa to všetko stalo v jednom prípade, potom by samotný ClickHouse prišiel na to, ako správne distribuovať údaje medzi vlákna.
A ďalším dôvodom je, že budete mať medziprocesorovú komunikáciu cez TCP. Dáta budú musieť byť serializované, deserializované, a to je obrovské množstvo mikroúlomkov. Jednoducho to nebude fungovať efektívne.
Ďalší antivzor, aj keď ho možno len ťažko nazvať antivzorom. Ide o veľké množstvo predagregácie.
Vo všeobecnosti je predagregácia dobrá. Mali ste miliardu riadkov, agregovali ste to a stalo sa z toho 1 000 riadkov a teraz sa dotaz vykoná okamžite. Všetko je skvelé. Dokážeš to. A na tento účel má aj ClickHouse špeciálny typ tabuľky AggregatingMergeTree, ktorý vykonáva prírastkovú agregáciu pri vkladaní údajov.
Sú však chvíle, keď si myslíte, že budeme údaje takto agregovať a údaje takto agregovať. A v niektorom susednom oddelení, tiež nechcem povedať v ktorom z nich, používajú tabuľky SummingMergeTree na zhrnutie podľa primárneho kľúča a ako primárny kľúč sa používa asi 20 stĺpcov. Pre každý prípad som zmenil názvy niektorých stĺpcov kvôli utajeniu, ale to je skoro všetko.
A takéto problémy vznikajú. Po prvé, objem vašich dát sa príliš nezníži. Napríklad sa zníži trikrát. Trikrát by bola dobrá cena za poskytnutie neobmedzených analytických možností, ktoré vznikajú, ak vaše údaje nie sú agregované. Ak sú údaje agregované, potom namiesto analýzy získate iba žalostné štatistiky.
A čo je na ňom také zvláštne? Faktom je, že títo ľudia zo susedného oddelenia niekedy chodia a žiadajú pridať ďalší stĺpec do primárneho kľúča. To znamená, že sme takto agregovali údaje, ale teraz chceme trochu viac. ClickHouse však nemá alter primárny kľúč. Preto musíme niektoré skripty napísať v C++. A nemám rád skripty, aj keď sú v C++.
A ak sa pozriete na to, na čo bol ClickHouse vytvorený, potom neagregované dáta sú presne tým scenárom, pre ktorý sa zrodil. Ak používate ClickHouse pre neagregované údaje, robíte to správne. Ak agregujete, niekedy sa to dá odpustiť.
Ďalším zaujímavým prípadom sú dotazy v nekonečnej slučke. Občas zájdem na nejaký produkčný server a pozriem si tam zoznam procesov. A zakaždým, keď zistím, že sa deje niečo hrozné.
Napríklad takto. Okamžite je jasné, že všetko sa dá urobiť v jednej žiadosti. Stačí napísať url a zoznam tam.
Prečo je veľa takýchto dopytov v nekonečnej slučke zlých? Ak sa index nepoužíva, budete mať veľa prechodov cez rovnaké údaje. Ale ak sa použije index, tak máš primárny kľúč pre ru a tam napíšeš url = niečo. A myslíte si, že ak sa z tabuľky načíta iba jedna URL, všetko bude v poriadku. Ale vlastne nie. Pretože ClickHouse robí všetko v dávkach.
Keď potrebuje prečítať určitý rozsah údajov, prečíta o niečo viac, pretože index v ClickHouse je riedky. Tento index vám neumožňuje nájsť jeden samostatný riadok v tabuľke, iba určitý rozsah. A údaje sú komprimované v blokoch. Aby ste prečítali jeden riadok, musíte vziať celý blok a uvoľniť ho. A ak robíte veľa otázok, budete mať veľa prekrývania a budete mať veľa práce znova a znova.
A ako bonus môžete poznamenať, že v ClickHouse by ste sa nemali báť preniesť do sekcie IN aj megabajty a dokonca stovky megabajtov. Z našej praxe si pamätám, že ak v MySQL prenesieme kopu hodnôt do sekcie IN, napríklad tam prenesieme 100 megabajtov nejakých čísel, tak MySQL zožerie 10 gigabajtov pamäte a nič iné sa mu nestane, všetko funguje zle.
A druhá je, že v ClickHouse, ak vaše dotazy používajú index, potom to nie je vždy pomalšie ako úplné skenovanie, t. j. ak potrebujete prečítať takmer celú tabuľku, prejde postupne a prečíta celú tabuľku. Vo všeobecnosti na to príde sám.
Ale napriek tomu existujú určité ťažkosti. Napríklad skutočnosť, že IN s poddotazom nepoužíva index. Ale toto je náš problém a musíme ho vyriešiť. Nie je tu nič zásadné. Opravíme to*.
A ďalšia zaujímavá vec je, že ak máte veľmi dlhú požiadavku a prebieha spracovanie distribuovanej požiadavky, tak táto veľmi dlhá požiadavka bude odoslaná na každý server bez kompresie. Napríklad 100 megabajtov a 500 serverov. A podľa toho budete mať 50 gigabajtov prenesených cez sieť. Odošle sa a potom sa všetko úspešne dokončí.
* už používa; Všetko bolo opravené, ako bolo sľúbené.
A celkom bežný prípad je, keď požiadavky prichádzajú z API. Napríklad ste vytvorili nejakú vlastnú službu. A ak niekto potrebuje vašu službu, otvoríte API a doslova o dva dni neskôr uvidíte, že sa deje niečo nepochopiteľné. Všetko je preťažené a prichádzajú hrozné požiadavky, ktoré sa nikdy nemali stať.
A existuje len jedno riešenie. Ak ste otvorili API, budete ho musieť vystrihnúť. Napríklad zaviesť nejaké kvóty. Neexistujú žiadne iné normálne možnosti. V opačnom prípade okamžite napíšu scenár a budú problémy.
A ClickHouse má špeciálnu funkciu - výpočet kvóty. Okrem toho môžete preniesť svoj kľúč kvóty. Ide napríklad o interné ID používateľa. A kvóty budú vypočítané nezávisle pre každú z nich.
Teraz ďalšia zaujímavosť. Toto je manuálna replikácia.
Poznám veľa prípadov, keď aj napriek tomu, že ClickHouse má vstavanú podporu replikácie, ľudia replikujú ClickHouse manuálne.
Aký je princíp? Máte kanál na spracovanie údajov. A funguje nezávisle, napríklad v rôznych dátových centrách. Rovnaké údaje zapíšete rovnakým spôsobom v ClickHouse. Pravda, prax ukazuje, že údaje sa budú stále líšiť v dôsledku niektorých funkcií vo vašom kóde. Dúfam, že je to v tvojom.
A z času na čas budete musieť synchronizovať manuálne. Napríklad raz za mesiac spravia správcovia rsync.
V skutočnosti je oveľa jednoduchšie použiť replikáciu zabudovanú do ClickHouse. Môžu však existovať určité kontraindikácie, pretože na to musíte použiť ZooKeeper. Na ZooKeeper nepoviem nič zlé, v zásade systém funguje, ale stáva sa, že ho ľudia nepoužívajú kvôli java-fóbii, pretože ClickHouse je taký dobrý systém, napísaný v C++, ktorý môžete používať a všetko bude v poriadku. A ZooKeeper je v jave. A nejako sa ani nechcete pozerať, ale potom môžete použiť manuálnu replikáciu.
ClickHouse je praktický systém. Berie do úvahy vaše potreby. Ak máte manuálnu replikáciu, môžete vytvoriť distribuovanú tabuľku, ktorá sa pozrie na vaše manuálne repliky a vykoná medzi nimi núdzové prepnutie. A dokonca existuje špeciálna možnosť, ktorá vám umožní vyhnúť sa prepadákom, aj keď sa vaše línie systematicky rozchádzajú.
Ďalšie problémy môžu nastať, ak použijete primitívne stolové motory. ClickHouse je konštruktor, ktorý má množstvo rôznych stolových motorov. Pre všetky vážne prípady, ako je napísané v dokumentácii, použite tabuľky z rodiny MergeTree. A všetko ostatné - je to tak, pre jednotlivé prípady alebo pre testy.
V tabuľke MergeTree nemusíte mať žiadny dátum a čas. Stále ho môžete použiť. Ak neexistuje dátum a čas, napíšte, že predvolená hodnota je 2000. Bude to fungovať a nebude to vyžadovať zdroje.
A v novej verzii servera môžete dokonca určiť, že máte vlastné rozdelenie bez kľúča oddielu. Bude to rovnaké.
Na druhej strane môžete použiť primitívne stolové motory. Napríklad vyplňte údaje raz a pozrite sa, otočte a odstráňte. Môžete použiť Log.
Alebo ukladanie malých objemov na medzispracovanie je StripeLog alebo TinyLog.
Pamäť je možné použiť, ak je množstvo údajov malé a môžete jednoducho niečo v pamäti RAM zakrútiť.
ClickHouse naozaj nemá rád renormalizované dáta.
Tu je typický príklad. Ide o obrovské množstvo adries URL. Položíte ich na ďalšiu tabuľku. A potom sa rozhodli urobiť s nimi JOIN, ale spravidla to nebude fungovať, pretože ClickHouse podporuje iba Hash JOIN. Ak nie je dostatok pamäte RAM pre veľa údajov, ktoré je potrebné pripojiť, funkcia JOIN nebude fungovať*.
Ak majú údaje vysokú mohutnosť, nebojte sa, uložte ich v denormalizovanej forme, adresy URL sú priamo na mieste v hlavnej tabuľke.
* a teraz má ClickHouse aj zlučovacie spojenie a funguje v podmienkach, keď sa prechodné údaje nezmestia do pamäte RAM. To je však neúčinné a odporúčanie zostáva v platnosti.
Niekoľko ďalších príkladov, ale už pochybujem, či sú proti vzoru alebo nie.
ClickHouse má jednu známu chybu. Nevie, ako aktualizovať*. V niektorých ohľadoch je to dokonca dobré. Ak máte nejaké dôležité údaje, napríklad účtovníctvo, nikto vám ich nebude môcť odoslať, pretože neexistujú žiadne aktualizácie.
* podpora pre aktualizáciu a mazanie v dávkovom režime bola pridaná už dávno.
Existuje však niekoľko špeciálnych spôsobov, ktoré umožňujú aktualizácie akoby na pozadí. Napríklad tabuľky ako ReplaceMergeTree. Aktualizujú sa počas spájania na pozadí. Môžete to vynútiť pomocou tabuľky optimalizácie. Nerobte to však príliš často, pretože to úplne prepíše oddiel.
Distribuované JOINy v ClickHouse sú tiež zle spracované plánovačom dotazov.
Zlé, ale niekedy OK.
Použitie ClickHouse iba na spätné čítanie údajov pomocou select*.
Neodporúčam používať ClickHouse na ťažkopádne výpočty. Nie je to ale celkom pravda, pretože od tohto odporúčania sa už vzďaľujeme. A nedávno sme pridali možnosť aplikovať modely strojového učenia v ClickHouse – Catboost. A trápi ma to, pretože si myslím: „Aká hrôza. Takto sa ukáže, koľko cyklov na bajt! Naozaj neznášam plytvanie hodinami na bajty.
Ale nebojte sa, nainštalujte ClickHouse, všetko bude v poriadku. Ak niečo, máme komunitu. Mimochodom, komunita ste vy. A ak máte nejaké problémy, môžete ísť aspoň na náš chat a snáď vám pomôžu.
otázky
Ďakujeme za správu! Kde sa môžem sťažovať na zlyhanie ClickHouse?
Momentálne sa mi môžete osobne sťažovať.
Nedávno som začal používať ClickHouse. Okamžite som vypustil rozhranie cli.
Aké skóre.
O niečo neskôr som zrútil server s malým výberom.
Máš talent.
Otvoril som chybu GitHub, ale bola ignorovaná.
Poďme sa pozrieť.
Alexey ma oklamal, aby som sa zúčastnil hlásenia a sľúbil mi, že mi povie, ako máte prístup k údajom vo vnútri.
Veľmi jednoduchý.
Uvedomil som si to včera. Viac špecifikácií.
Nie sú tam žiadne strašné triky. Existuje len kompresia blok po bloku. Predvolená hodnota je LZ4, môžete povoliť ZSTD*. Bloky od 64 kilobajtov do 1 megabajtu.
* K dispozícii je tiež podpora pre špecializované kompresné kodeky, ktoré možno použiť v reťazci s inými algoritmami.
Sú bloky len nespracované údaje?
Nie úplne surové. Existujú polia. Ak máte číselný stĺpec, čísla v riadku sa umiestnia do poľa.
Vidím.
Alexey, príklad, ktorý bol s uniqExact cez IP, t. j. skutočnosť, že výpočet uniqExact trvá dlhšie podľa riadkov ako podľa čísel atď. Čo ak v čase korektúry použijeme fintu s ušami a odliatím? To znamená, že ste si zrejme povedali, že na našom disku sa to veľmi nelíši. Ak budeme čítať riadky z disku a odliatku, budú naše agregáty rýchlejšie alebo nie? Alebo tu ešte mierne priberieme? Zdá sa mi, že ste to testovali, ale z nejakého dôvodu ste to neuviedli v benchmarku.
Myslím, že to pôjde pomalšie ako bez kastingu. V tomto prípade musí byť IP adresa analyzovaná z reťazca. Samozrejme, v ClickHouse je naša analýza IP adries tiež optimalizovaná. Veľmi sme sa snažili, ale tam máte čísla napísané v desaťtisícovom tvare. Veľmi nepríjemné. Na druhej strane, funkcia uniqExact bude pracovať na reťazcoch pomalšie, nielen preto, že ide o reťazce, ale aj preto, že je zvolená iná špecializácia algoritmu. Struny sú jednoducho spracované inak.
Čo ak vezmeme primitívnejší typ údajov? Napríklad sme si zapísali ID používateľa, ktoré máme, zapísali sme ho ako riadok a potom sme ho zakódovali, bude to zábavnejšie alebo nie?
Pochybujem. Myslím, že to bude ešte smutnejšie, pretože koniec koncov, analýza čísel je vážny problém. Zdá sa mi, že tento kolega dokonca podal správu o tom, aké ťažké je analyzovať čísla v desaťtisícovej forme, ale možno nie.
Alexey, ďakujem veľmi pekne za správu! A veľmi pekne ďakujem za ClickHouse! Mám otázku ohľadom plánov. Existujú nejaké plány na funkciu na neúplnú aktualizáciu slovníkov?
Čiastočný reštart?
Áno áno. Rovnako ako možnosť nastaviť tam pole MySQL, teda aktualizovať potom, aby sa načítali iba tieto údaje, ak je slovník veľmi veľký.
Veľmi zaujímavá funkcia. A myslím, že to niekto navrhol v našom rozhovore. Možno si to bol dokonca ty.
Myslím, že nie.
Skvelé, teraz sa ukázalo, že existujú dve žiadosti. A môžete to pomaly začať robiť. Ale chcem vás hneď varovať, že implementácia tejto funkcie je celkom jednoduchá. To znamená, že teoreticky stačí napísať číslo verzie do tabuľky a potom napísať: verzia menšia ako taká a taká. To znamená, že to s najväčšou pravdepodobnosťou ponúkneme nadšencom. Si nadšenec?
Áno, ale bohužiaľ nie v C++.
Vedia vaši kolegovia písať v C++?
niekoho si nájdem.
Skvelé*.
* funkcia bola pridaná dva mesiace po správe - autor otázky ju vyvinul a poslal svoju .
Ďakujeme!
Ahoj! Ďakujeme za správu! Spomenuli ste, že ClickHouse je veľmi dobrý v spotrebe všetkých zdrojov, ktoré má k dispozícii. A rečník vedľa Luxoft hovoril o svojom riešení pre Ruskú poštu. Povedal, že ClickHouse majú veľmi radi, ale nepoužili ho namiesto svojho hlavného konkurenta práve preto, že požieral celý procesor. A nemohli to zapojiť do svojej architektúry, do svojho ZooKeepera s dokovacími stanicami. Je možné nejako obmedziť ClickHouse, aby nespotreboval všetko, čo má k dispozícii?
Áno, je to možné a veľmi jednoduché. Ak chcete spotrebovať menej jadier, tak stačí napísať set max_threads = 1. A to je všetko, vykoná požiadavku v jednom jadre. Okrem toho môžete určiť rôzne nastavenia pre rôznych používateľov. Takže žiadny problém. A povedzte svojim kolegom z Luxoft, že nie je dobré, že toto nastavenie nenašli v dokumentácii.
Alexey, ahoj! Chcel by som sa opýtať na túto otázku. Toto nie je prvýkrát, čo som počul, že veľa ľudí začína používať ClickHouse ako úložisko protokolov. V správe ste povedali, že to nemáte robiť, t. j. nemusíte ukladať dlhé reťazce. Čo si o tom myslíš?
Po prvé, polená spravidla nie sú dlhé reťazce. Samozrejme, existujú aj výnimky. Napríklad nejaká služba napísaná v jazyku java vyvolá výnimku, zaloguje sa. A tak ďalej v nekonečnej slučke a miesto na pevnom disku sa míňa. Riešenie je veľmi jednoduché. Ak sú čiary veľmi dlhé, odrežte ich. Čo znamená dlho? Desiatky kilobajtov sú zlé*.
* v najnovších verziách ClickHouse je povolená „prispôsobivá indexová granularita“, ktorá z väčšej časti eliminuje problém s ukladaním dlhých riadkov.
Je kilobajt normálny?
Je to normálne.
Ahoj! Ďakujeme za správu! Už som sa na to pýtal v chate, ale nepamätám si, či som dostal odpoveď. Plánuje sa nejako rozšíriť sekciu WITH na spôsob CTE?
Ešte nie. Naša sekcia WITH je trochu neseriózna. Je to pre nás ako malá funkcia.
Rozumiem. Ďakujem!
Ďakujeme za správu! Veľmi zaujímavé! Globálna otázka. Existujú nejaké plány na úpravu vymazania údajov, možno vo forme nejakých útržkov?
Nevyhnutne. Toto je naša prvá úloha v našom rade. Teraz aktívne premýšľame o tom, ako urobiť všetko správne. A mali by ste začať stláčať klávesnicu*.
* stlačil tlačidlá na klávesnici a urobil všetko.
Ovplyvní to nejako výkon systému alebo nie? Bude vkladanie také rýchle ako teraz?
Možno budú samotné mazanie a samotné aktualizácie veľmi ťažké, ale to neovplyvní výkon selectov ani výkon insertov.
A ešte jedna malá otázka. Na prezentácii ste hovorili o primárnom kľúči. V súlade s tým máme rozdelenie, ktoré je štandardne mesačné, však? A keď nastavíme rozsah dátumov, ktorý sa zmestí do mesiaca, potom sa číta iba tento oddiel, však?
Áno.
Otázka. Ak nemôžeme vybrať žiadny primárny kľúč, je správne to urobiť konkrétne podľa poľa „Dátum“, aby na pozadí došlo k menšiemu preskupeniu týchto údajov, aby sa zmestili usporiadanejším spôsobom? Ak nemáte dotazy na rozsah a nemôžete ani vybrať žiadny primárny kľúč, oplatí sa dať do primárneho kľúča dátum?
Áno.
Možno má zmysel vložiť do primárneho kľúča pole, ktoré bude dáta lepšie komprimovať, ak budú zoradené podľa tohto poľa. Napríklad ID používateľa. Používateľ napríklad prejde na rovnakú stránku. V tomto prípade zadajte ID používateľa a čas. A potom budú vaše dáta lepšie komprimované. Pokiaľ ide o dátum, ak naozaj nemáte a nikdy nemáte dotazy na rozsah dátumov, nemusíte dátum vkladať do primárneho kľúča.
OK ďakujem pekne!
Zdroj: hab.com