{"id":91438,"date":"2020-08-13T19:42:36","date_gmt":"2020-08-13T17:42:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks"},"modified":"2020-08-13T19:42:36","modified_gmt":"2020-08-13T17:42:36","slug":"effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","title":{"rendered":"Efekt\u00edvne vyu\u017eitie ClickHouse. Alexej Milovidov (Yandex)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Preto\u017ee ClickHouse je \u0161pecializovan\u00fd syst\u00e9m, je pri jeho pou\u017e\u00edvan\u00ed d\u00f4le\u017eit\u00e9 zoh\u013eadni\u0165 zvl\u00e1\u0161tnosti jeho architekt\u00fary. V tejto prezent\u00e1cii Alexej povie o pr\u00edkladoch typick\u00fdch ch\u00fdb pri pou\u017e\u00edvan\u00ed ClickHouse, ktor\u00e9 m\u00f4\u017eu vies\u0165 k neefekt\u00edvnej pr\u00e1ci. Na pr\u00edkladoch z praxe bude uk\u00e1zan\u00e9, ako v\u00fdber ur\u010ditej sch\u00e9my spracovania \u00fadajov m\u00f4\u017ee zmeni\u0165 v\u00fdkon o poriadky.<\/p>\n

<\/a><\/noindex><\/p>\n

Ahojte v\u0161etci! Vol\u00e1m sa Alexej, rob\u00edm ClickHouse.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Po prv\u00e9, hne\u010f v\u00e1s chcem pote\u0161i\u0165, dnes v\u00e1m nebudem rozpr\u00e1va\u0165, \u010do je ClickHouse. \u00daprimne, u\u017e ma to nud\u00ed. Ka\u017ed\u00fd raz hovor\u00edm, \u010do to je. A asi to u\u017e v\u0161etci vedia. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Namiesto toho budem hovori\u0165 o tom, ak\u00e9 s\u00fa mo\u017en\u00e9 pasce, t.j. ako sa d\u00e1 ClickHouse nespr\u00e1vne pou\u017e\u00edva\u0165. Naozaj sa netreba b\u00e1\u0165, preto\u017ee vyv\u00edjame ClickHouse ako syst\u00e9m, ktor\u00fd je jednoduch\u00fd, pohodln\u00fd a funguje out-of-the-box. Nain\u0161talujete a v\u0161etko je vybaven\u00e9, \u017eiadne probl\u00e9my. <\/p>\n

<\/p>\n

Ale napriek tomu treba zoh\u013eadni\u0165, \u017ee tento syst\u00e9m je \u0161pecializovan\u00fd a \u013eahko sa m\u00f4\u017eete stretn\u00fa\u0165 s neobvykl\u00fdm scen\u00e1rom pou\u017eitia, ktor\u00fd vyvedie tento syst\u00e9m z komfortnej z\u00f3ny.<\/p>\n

<\/p>\n

Tak\u017ee, ak\u00e9 s\u00fa pasce? V podstate budem hovori\u0165 o samozrejm\u00fdch veciach. V\u0161etk\u00fdm je v\u0161etko jasn\u00e9, v\u0161etci rozumej\u00fa a m\u00f4\u017eu sa te\u0161i\u0165, ak\u00ed s\u00fa m\u00fadri, a t\u00ed, ktor\u00ed nerozumej\u00fa, sa dozvedia nie\u010do nov\u00e9. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Prv\u00fd najjednoduch\u0161\u00ed pr\u00edklad, ktor\u00fd sa, bohu\u017eia\u013e, \u010dasto vyskytuje, je ve\u013ek\u00e9 mno\u017estvo insertov s mal\u00fdmi partami, t.j. ve\u013ek\u00e9 mno\u017estvo mal\u00fdch insertov.<\/p>\n

<\/p>\n

Ak sa pozrieme na to, ako ClickHouse vykon\u00e1va insert, m\u00f4\u017eete jedn\u00fdm dopytom posla\u0165 aj pr\u00fad \u00fadajov na terabajt. To nie je probl\u00e9m. <\/p>\n

<\/p>\n

A po\u010fme sa pozrie\u0165, ak\u00e1 bude typick\u00e1 v\u00fdkonnos\u0165. Napr\u00edklad tabu\u013eka s \u00fadajmi z Yandex.Metriky. Hity. 105 nejak\u00fdch st\u013apcov. 700 bajtov v nekomprimovanej podobe. A budeme vklada\u0165 poctivo d\u00e1vkami po jednom mili\u00f3ne riadkov. <\/p>\n

<\/p>\n

Vklad\u00e1me do tabu\u013eky MergeTree, dost\u00e1vame pol mili\u00f3na riadkov za sekundu. V\u00fdborn\u00e9. V replikovanej tabu\u013eke \u2013 bude to o nie\u010do menej, pribli\u017ene 400 000 riadkov za sekundu. <\/p>\n

<\/p>\n

A ak zapneme kv\u00f3rumov\u00fd insert, dostaneme o nie\u010do menej, ale aj tak slu\u0161n\u00fa v\u00fdkonnos\u0165, 250 000 riadkov za sekundu. Kv\u00f3rumov\u00fd insert \u2013 to je nedokumentovan\u00e1 mo\u017enos\u0165 v ClickHouse*.<\/p>\n

<\/p>\n

* k 2020 roku, u\u017e je dokumentovan\u00e1<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010co sa stane, ak to rob\u00edme zle? Vklad\u00e1me po jednom riadku do tabu\u013eky MergeTree a v\u00fdsledok je 59 riadkov za sekundu. To je 10 000-kr\u00e1t pomal\u0161ie. V ReplicatedMergeTree \u2013 6 riadkov za sekundu. A ak sa zapne aj kv\u00f3rum, dostaneme 2 riadky za sekundu. Pod\u013ea m\u0148a je to \u00fapln\u00fd prepad\u00e1k. Ako je mo\u017en\u00e9 takto brzdi\u0165? M\u00e1m dokonca na tri\u010dku nap\u00edsan\u00e9, \u017ee ClickHouse by nemal brzdi\u0165. A predsa sa to ob\u010das st\u00e1va. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

V skuto\u010dnosti \u2013 je to na\u0161a chyba. Mohli sme to zariadi\u0165 tak, aby to v\u0161etko fungovalo norm\u00e1lne, ale neurobili sme to. A neurobili sme to, preto\u017ee pre n\u00e1\u0161 scen\u00e1r to nebolo potrebn\u00e9. Mali sme aj tak d\u00e1vky. Jednoducho n\u00e1m prich\u00e1dzali d\u00e1vky na vstup a neboli \u017eiadne probl\u00e9my. Vklad\u00e1me a v\u0161etko funguje norm\u00e1lne. Ale samozrejme, m\u00f4\u017eu nasta\u0165 r\u00f4zne scen\u00e1re. Napr\u00edklad, ke\u010f m\u00e1te mno\u017estvo serverov, na ktor\u00fdch sa generuj\u00fa d\u00e1ta. A tie vkladaj\u00fa d\u00e1ta nie tak \u010dasto, ale aj tak doch\u00e1dza k \u010dast\u00fdm vkladom. A je potrebn\u00e9 tomu nejako zabr\u00e1ni\u0165. <\/p>\n

<\/p>\n

Z technick\u00e9ho h\u013eadiska spo\u010d\u00edva podstata v tom, \u017ee ke\u010f vykon\u00e1vate insert do ClickHouse, d\u00e1ta sa nedostan\u00fa do \u017eiadnej memtabu\u013eky. Nem\u00e1me ani skuto\u010dn\u00fd log structure MergeTree, ale len MergeTree, preto\u017ee nie je \u017eiadny log ani memTable. Jednoducho zapisujeme d\u00e1ta priamo do s\u00faborov\u00e9ho syst\u00e9mu, u\u017e usporiadan\u00e9 pod\u013ea st\u013apcov. A ak m\u00e1te 100 st\u013apcov, bude potrebn\u00e9 zap\u00edsa\u0165 viac ako 200 s\u00faborov do samostatn\u00e9ho adres\u00e1ra. To v\u0161etko je dos\u0165 robustn\u00e9. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A vyvst\u00e1va ot\u00e1zka: \u201eAko to robi\u0165 spr\u00e1vne?\u201c, ak t\u00e1to situ\u00e1cia nastane, \u017ee je potrebn\u00e9 nejako zapisova\u0165 d\u00e1ta do ClickHouse.<\/p>\n

<\/p>\n

Sp\u00f4sob 1. Toto je najjednoduch\u0161\u00ed sp\u00f4sob. Pou\u017ei\u0165 nejak\u00fa distribuovan\u00fa frontu. Napr\u00edklad, Kafka. Jednoducho vyber\u00e1te d\u00e1ta z Kafky, d\u00e1vkujete raz za sekundu. A v\u0161etko bude norm\u00e1lne, zapisujete a v\u0161etko funguje dobre. <\/p>\n

<\/p>\n

Nev\u00fdhody s\u00fa, \u017ee Kafka je \u010fal\u0161\u00ed robustn\u00fd distribuovan\u00fd syst\u00e9m. E\u0161te viem pochopi\u0165, ak vo va\u0161ej firme u\u017e existuje Kafka. To je dobr\u00e9, je to pohodln\u00e9. Ale ak ju nem\u00e1te, mali by ste trikr\u00e1t premyslie\u0165 predt\u00fdm, ako si do projektu prid\u00e1te e\u0161te jeden distribuovan\u00fd syst\u00e9m. Preto stoj\u00ed za to zv\u00e1\u017ei\u0165 alternat\u00edvy. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Sp\u00f4sob 2. Tak\u00e1to starom\u00f3dna alternat\u00edva je pritom ve\u013emi jednoduch\u00e1. M\u00e1te server, ktor\u00fd generuje va\u0161e logy. A jednoducho zapisuje va\u0161e logy do s\u00faboru. A raz za sekundu, napr\u00edklad, tento s\u00fabor premenov\u00e1me, otvor\u00edme nov\u00fd. A samostatn\u00fd skript, bu\u010f cez cron, alebo nejak\u00fd daemon, vezme najstar\u0161\u00ed s\u00fabor a ulo\u017e\u00ed ho do ClickHouse. Ak zapisujete logy raz za sekundu, v\u0161etko bude skvele. <\/p>\n

<\/p>\n

Ale nev\u00fdhodou tohto sp\u00f4sobu je, \u017ee ak v\u00e1\u0161 server, na ktorom sa generuj\u00fa logy, niekde zmizne, tak aj d\u00e1ta zmizn\u00fa.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Sp\u00f4sob 3. Existuje e\u0161te jeden zauj\u00edmav\u00fd sp\u00f4sob, ktor\u00fd je \u00faplne bez do\u010dasn\u00fdch s\u00faborov. Napr\u00edklad m\u00e1te nejak\u00fa reklamn\u00fa rot\u00e1ciu alebo in\u00fd zauj\u00edmav\u00fd daemon, ktor\u00fd generuje d\u00e1ta. A m\u00f4\u017eete hromadi\u0165 d\u00e1vku d\u00e1t priamo v opera\u010dnej pam\u00e4ti, v bufferi. A ke\u010f uplynie dostato\u010dn\u00e9 mno\u017estvo \u010dasu, tento buffer ulo\u017e\u00edte bokom, vytvor\u00edte nov\u00fd, a v samostatnom vl\u00e1kne to, \u010do u\u017e sa nahromadilo, vlo\u017e\u00edte do ClickHouse.<\/p>\n

<\/p>\n

Na druhej strane d\u00e1ta tie\u017e pri kill -9 zmizn\u00fa. Ak sa v\u00e1\u0161 server zr\u00fati, tieto d\u00e1ta strat\u00edte. A \u010fal\u0161\u00edm probl\u00e9mom je, \u017ee ak sa v\u00e1m nepodar\u00ed zap\u00edsa\u0165 do datab\u00e1zy, tie d\u00e1ta sa bud\u00fa hromadi\u0165 v opera\u010dnej pam\u00e4ti. A bu\u010f sa pam\u00e4\u0165 minie, alebo jednoducho strat\u00edte d\u00e1ta. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Sp\u00f4sob 4. E\u0161te jeden zauj\u00edmav\u00fd sp\u00f4sob. M\u00e1te nejak\u00fd serverov\u00fd proces. A ten m\u00f4\u017ee odosiela\u0165 d\u00e1ta do ClickHouse okam\u017eite, ale robi\u0165 to v jednom spojen\u00ed. Napr\u00edklad odoslal http-\u017eiados\u0165 s transfer-encoding: chunked s insertom. A generuje chunk-y u\u017e nie pr\u00edli\u0161 zriedka, m\u00f4\u017eete posiela\u0165 ka\u017ed\u00fa radu, hoci sa vyskytne overhead na r\u00e1mcovanie t\u00fdchto d\u00e1t. <\/p>\n

<\/p>\n

Ale aj tak, v tomto pr\u00edpade d\u00e1ta bud\u00fa odoslan\u00e9 do ClickHouse okam\u017eite. A ClickHouse si ich s\u00e1m buferizuje. <\/p>\n

<\/p>\n

Ale tie\u017e sa objavuj\u00fa probl\u00e9my. Teraz strat\u00edte d\u00e1ta vr\u00e1tane toho, ke\u010f sa v\u00e1\u0161 proces skon\u010d\u00ed a ak sa proces ClickHouse zr\u00fati, preto\u017ee to bude nedokon\u010den\u00fd insert. A v ClickHouse s\u00fa inserty atom\u00e1rne do ur\u010dit\u00e9ho stanoven\u00e9ho prahu po\u010dtu riadkov. V podstate je to zauj\u00edmav\u00fd sp\u00f4sob. M\u00f4\u017ee sa tie\u017e pou\u017ei\u0165.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Met\u00f3da 5. Tu je \u010fal\u0161\u00ed zauj\u00edmav\u00fd sp\u00f4sob. Ide o nejak\u00fd komunitou vyvinut\u00fd server na d\u00e1vkov\u00e9 spracovanie \u00fadajov. Ja som na to s\u00e1m nekukal, tak\u017ee ni\u010d zaru\u010di\u0165 nem\u00f4\u017eem. Napriek tomu ani pre samotn\u00fd ClickHouse nie s\u00fa poskytovan\u00e9 \u017eiadne z\u00e1ruky. Je to tie\u017e open source, ale na druhej strane, mohli by ste si zvykn\u00fa\u0165 na ur\u010dit\u00fd \u0161tandard kvality, ktor\u00fd sa sna\u017e\u00edme zabezpe\u010di\u0165. A oh\u013eadom tejto veci - neviem, cho\u010fte na GitHub, pozrite sa na k\u00f3d. Mo\u017eno tam nap\u00edsali nie\u010do norm\u00e1lne. <\/p>\n

<\/p>\n

* k 2020 roku, mal by sa tie\u017e zoh\u013eadni\u0165 KittenHouse<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Met\u00f3da 6. \u010eal\u0161\u00ed sp\u00f4sob je pou\u017eitie Buffer tabuliek. V\u00fdhodou tohto sp\u00f4sobu je, \u017ee je ve\u013emi jednoduch\u00e9 za\u010da\u0165 pou\u017e\u00edva\u0165. Vytvor\u00edte Buffer tabu\u013eku a vlo\u017e\u00edte do nej d\u00e1ta. <\/p>\n

<\/p>\n

Nev\u00fdhodou je, \u017ee probl\u00e9m nie je \u00faplne vyrie\u0161en\u00fd. Ak pri vkladan\u00ed typu MergeTree mus\u00edte grupova\u0165 d\u00e1ta po jednom batchi za sekundu, tak pri vkladan\u00ed do buffer tabu\u013eky mus\u00edte grupova\u0165 aspo\u0148 na nieko\u013eko tis\u00edc za sekundu. Ak bude viac ako 10 000 za sekundu, bude to op\u00e4\u0165 zl\u00fd v\u00fdkon. A ak vklad\u00e1te po d\u00e1vkach, videli ste, \u017ee tam vych\u00e1dza stotis\u00edc riadkov za sekundu. A to u\u017e na dos\u0165 \u0165a\u017ek\u00fdch d\u00e1tach. <\/p>\n

<\/p>\n

A tie\u017e buffer tabu\u013eky nemaj\u00fa log. Ak je s va\u0161\u00edm serverom nie\u010do zl\u00e9, d\u00e1ta bud\u00fa straten\u00e9. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A ako bonus, ned\u00e1vno sme v ClickHouse z\u00edskali mo\u017enos\u0165 z\u00edskava\u0165 d\u00e1ta z Kafka. Existuje tabulkov\u00fd motor - Kafka. Jednoducho vytvor\u00edte. A na to m\u00f4\u017eete pripevni\u0165 materializovan\u00e9 poh\u013eady. V tomto pr\u00edpade to samo vytiahne d\u00e1ta z Kafka a vlo\u017e\u00ed ich do potrebn\u00fdch tabuliek. <\/p>\n

<\/p>\n

A obzvl\u00e1\u0161\u0165 n\u00e1s te\u0161\u00ed, \u017ee t\u00fato mo\u017enos\u0165 nerobili my. Je to funkcia komunity. A ke\u010f hovor\u00edm 'funkcia komunity', hovor\u00edm to bez ak\u00e9hoko\u013evek opovrhnutia. K\u00f3d sme \u010d\u00edtali, robili sme rev\u00edziu, malo by to fungova\u0165 norm\u00e1lne. <\/p>\n

<\/p>\n

* k 2020 roku, podobn\u00e1 podpora bola pridan\u00e1 pre RabbitMQ<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010co \u010fal\u0161ie m\u00f4\u017ee by\u0165 nepr\u00edjemn\u00e9 alebo prekvapuj\u00face pri vkladan\u00ed \u00fadajov? Ak rob\u00edte dotaz insert values a vo values p\u00ed\u0161ete nejak\u00e9 vypo\u010d\u00edtavacie v\u00fdrazy. Napr\u00edklad, now() \u2013 to je tie\u017e vypo\u010d\u00edtavac\u00ed v\u00fdraz. A v tomto pr\u00edpade ClickHouse mus\u00ed na ka\u017ed\u00fd riadok spusti\u0165 interpreter t\u00fdchto v\u00fdrazov, a v\u00fdkon v\u00fdrazne klesne. Lep\u0161ie sa tomu vyhn\u00fa\u0165.<\/p>\n

<\/p>\n

* V s\u00fa\u010dasnosti je probl\u00e9m \u00faplne vyrie\u0161en\u00fd, regresie v\u00fdkonu pri pou\u017eit\u00ed v\u00fdrazov v VALUES u\u017e nie s\u00fa.<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed pr\u00edklad, kedy m\u00f4\u017eu vznikn\u00fa\u0165 probl\u00e9my, je, ke\u010f m\u00e1te v jednom d\u00e1vkovan\u00ed d\u00e1ta, ktor\u00e9 sa t\u00fdkaj\u00fa viacer\u00fdch part\u00edci\u00ed. Predvolen\u00fdm nastaven\u00edm v ClickHouse s\u00fa part\u00edcie pod\u013ea mesiacov. A ak vlo\u017e\u00edte d\u00e1vku z mili\u00f3na riadkov, pri\u010dom \u00fadaje s\u00fa za nieko\u013eko rokov, budete ma\u0165 nieko\u013eko desiatok part\u00edci\u00ed. A to je ekvivalentn\u00e9 tomu, \u017ee bud\u00fa d\u00e1vky o nieko\u013eko desiatok kr\u00e1t men\u0161ie, preto\u017ee vo vn\u00fatri sa najprv rozde\u013euj\u00fa pod\u013ea part\u00edci\u00ed.<\/p>\n

<\/p>\n

* Ned\u00e1vno bola v ClickHouse v experiment\u00e1lnom re\u017eime pridan\u00e1 podpora kompaktn\u00e9ho form\u00e1tu kusov a kusov v opera\u010dnej pam\u00e4ti s write-ahead logom, \u010do takmer \u00faplne rie\u0161i probl\u00e9m.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Teraz si pozrime druh\u00fd typ probl\u00e9mu \u2013 typiz\u00e1ciu d\u00e1t. <\/p>\n

<\/p>\n

Typiz\u00e1cia d\u00e1t m\u00f4\u017ee by\u0165 pr\u00edsna alebo re\u0165azcov\u00e1. Re\u0165azcov\u00e1 \u2013 to je, ke\u010f jednoducho ozn\u00e1mite, \u017ee v\u0161etky polia maj\u00fa typ string. To je zl\u00e9. Tak to robi\u0165 netreba. <\/p>\n

<\/p>\n

Po\u010fme sa pozrie\u0165 na to, ako to robi\u0165 spr\u00e1vne v pr\u00edpadoch, ke\u010f chceme poveda\u0165, \u017ee nejak\u00e9 pole m\u00e1me ako re\u0165azec, a nech ClickHouse s t\u00fdm nalo\u017e\u00ed, ale aj tak by sme mali vynalo\u017ei\u0165 nejak\u00e9 \u00fasilie. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Napr\u00edklad m\u00e1me IP adresu. V jednom pr\u00edpade ju uchov\u00e1vame ako re\u0165azec. Napr\u00edklad 192.168.1.1. A v druhom pr\u00edpade to bude \u010d\u00edslo typu UInt32*. 32 bitov sta\u010d\u00ed na IPv4 adresu.<\/p>\n

<\/p>\n

Prv\u00fdkr\u00e1t, ako to s\u00favis\u00ed, d\u00e1ta sa skompresuj\u00fa pribli\u017ene rovnako. Samozrejme, bude tam zmena, ale nie tak\u00e1 ve\u013ek\u00e1. Tak\u017ee pri diskovom vstupe-v\u00fdstupe nie s\u00fa \u017eiadne ve\u013ek\u00e9 probl\u00e9my. <\/p>\n

<\/p>\n

Ale existuje z\u00e1sadn\u00fd rozdiel v procesorovom \u010dase a v \u010dase vykonania dotazu. <\/p>\n

<\/p>\n

Po\u010d\u00edtajme po\u010det unik\u00e1tnych IP adries, ak s\u00fa ulo\u017een\u00e9 ako \u010d\u00edsla. Vyjde 137 mili\u00f3nov riadkov za sekundu. Ak je to rovnak\u00e9 ako re\u0165azce, potom 37 mili\u00f3nov riadkov za sekundu. Neviem, pre\u010do to tak vy\u0161lo. S\u00e1m som vykon\u00e1val tieto dotazy. Ale aj tak je to pribli\u017ene 4 kr\u00e1t pomal\u0161ie. <\/p>\n

<\/p>\n

Ak spo\u010d\u00edtame rozdiel v mieste na disku, existuje aj rozdiel. A rozdiel je asi jedna \u0161tvrtina, preto\u017ee unik\u00e1tnych IP adries je dos\u0165 ve\u013ea. A keby tu boli re\u0165azce s mal\u00fdm po\u010dtom r\u00f4znych hodn\u00f4t, tak by sa bez probl\u00e9mov skompresovali pod\u013ea slovn\u00edka na pribli\u017ene rovnak\u00fd objem. <\/p>\n

<\/p>\n

A \u0161tvorn\u00e1sobn\u00fd rozdiel v \u010dase na ceste sa nepova\u017euje za zanedbate\u013en\u00fd. Mo\u017eno v\u00e1m je to jedno, ale ke\u010f vid\u00edm tak\u00fd rozdiel, je mi z toho smutno.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Pozrime sa na r\u00f4zne pr\u00edpady. <\/p>\n

<\/p>\n

1. Prv\u00fd pr\u00edpad, ke\u010f m\u00e1te len nieko\u013eko r\u00f4znych unik\u00e1tnych hodn\u00f4t. V tomto pr\u00edpade pou\u017e\u00edvame jednoduch\u00fa prax, ktor\u00fa pravdepodobne pozn\u00e1te a m\u00f4\u017eete ju pou\u017ei\u0165 pre ak\u00e9ko\u013evek datab\u00e1zy. To plat\u00ed nielen pre ClickHouse. Jednoducho zapisujete \u010d\u00edseln\u00e9 identifik\u00e1tory do datab\u00e1zy. A konvertova\u0165 na re\u0165azce a sp\u00e4\u0165 m\u00f4\u017eete u\u017e na strane va\u0161ej aplik\u00e1cie. <\/p>\n

<\/p>\n

Napr\u00edklad, m\u00e1te regi\u00f3n. A sna\u017e\u00edte sa ho ulo\u017ei\u0165 ako re\u0165azec. A vyp\u00ed\u0161e sa: Moskva a MO. A ke\u010f vid\u00edm, \u017ee je tam nap\u00edsan\u00e9 \u201eMoskva\u201c, to e\u0161te nie je zl\u00e9, ale ke\u010f je tam aj MO, tak je to u\u017e rozhodne smutnej\u0161ie. Ko\u013eko to m\u00f4\u017ee by\u0165 bajtov. <\/p>\n

<\/p>\n

Namiesto toho jednoducho zapisujeme \u010d\u00edslo Ulnt32 a 250. M\u00e1me 250 v Yandexe, a u v\u00e1s to m\u00f4\u017ee by\u0165 inak. Len pre istotu poviem, \u017ee v ClickHouse je zabudovan\u00e1 mo\u017enos\u0165 pr\u00e1ce s geografickou datab\u00e1zou. Jednoducho zapisujete preh\u013ead regi\u00f3nov, vr\u00e1tane hierarchick\u00e9ho, to znamen\u00e1, \u017ee tam bude aj Moskva, aj MO, a v\u0161etko, \u010do potrebujete. A m\u00f4\u017eete konvertova\u0165 na \u00farovni dotazu. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Druh\u00fd variant je podobn\u00fd, ale u\u017e s podporou vn\u00fatri ClickHouse. To je typ d\u00e1t Enum. Jednoducho do Enum zap\u00ed\u0161ete v\u0161etky potrebn\u00e9 hodnoty. Napr\u00edklad, typ zariadenia a tam nap\u00ed\u0161ete: desktop, mobiln\u00fd, tablet, telev\u00edzor. Celkovo 4 varianty. <\/p>\n

<\/p>\n

Nev\u00fdhodou je, \u017ee je potrebn\u00e9 \u010das od \u010dasu robi\u0165 alter. Pridali sme len jeden variant. Rob\u00edme alter table. V skuto\u010dnosti je alter table v ClickHouse zadarmo. Osobitne zadarmo pre Enum, preto\u017ee d\u00e1ta na disku sa nemenia. Napriek tomu v\u0161ak alter uzamkne tabu\u013eku a mus\u00ed po\u010dka\u0165, k\u00fdm sa vykonaj\u00fa v\u0161etky selects. A a\u017e potom sa alter vykon\u00e1, \u010do znamen\u00e1, \u017ee niektor\u00e9 nepr\u00edjemnosti tu s\u00fa.<\/p>\n

<\/p>\n

* V nov\u0161\u00edch verzi\u00e1ch ClickHouse je ALTER \u00faplne neblokuj\u00faci.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed dostato\u010dne unik\u00e1tny variant pre ClickHouse \u2013 to je pripojenie extern\u00fdch slovn\u00edkov. M\u00f4\u017eete zapisova\u0165 \u010d\u00edsla do ClickHouse a va\u0161e preh\u013eady dr\u017ea\u0165 v akomko\u013evek syst\u00e9me, ktor\u00fd v\u00e1m vyhovuje. Napr\u00edklad, m\u00f4\u017eete pou\u017ei\u0165: MySQL, Mongo, Postgres. M\u00f4\u017eete dokonca vytvori\u0165 svoj mikroslu\u017ebu, ktor\u00e1 bude cez http poskytova\u0165 tieto d\u00e1ta. A na \u00farovni ClickHouse nap\u00ed\u0161ete funkciu, ktor\u00e1 tieto d\u00e1ta prevedie z \u010d\u00edsel na re\u0165azce. <\/p>\n

<\/p>\n

Toto je \u0161pecializovan\u00fd, no ve\u013emi efekt\u00edvny sp\u00f4sob, ako vykona\u0165 join s externou tabu\u013ekou. Existuj\u00fa dva varianty. V jednom variante bud\u00fa tieto \u00fadaje \u00faplne vyrovn\u00e1van\u00e9, bud\u00fa plne v opera\u010dnej pam\u00e4ti a bud\u00fa sa aktualizova\u0165 s ur\u010ditou peri\u00f3dou. V druhom variante, ak sa tieto \u00fadaje nezmestia do opera\u010dnej pam\u00e4te, m\u00f4\u017eeme ich \u010diasto\u010dne vyrovna\u0165. <\/p>\n

<\/p>\n

Tu je pr\u00edklad. Existuje Yandex.Direct. A tam s\u00fa reklamn\u00e9 kampane a bannery. Reklamn\u00fdch kampan\u00ed je pravdepodobne okolo desa\u0165 mili\u00f3nov. A zhruba sa zmestia do opera\u010dnej pam\u00e4te. Ale bannerov je miliardy, tie sa nezmestia. A pou\u017e\u00edvame cachovan\u00fd slovn\u00edk z MySQL.<\/p>\n

<\/p>\n

Jedin\u00fdm probl\u00e9mom je, \u017ee cachovan\u00fd slovn\u00edk bude fungova\u0165 norm\u00e1lne, ak je hit rate bl\u00edzko 100 %. Ak je ni\u017e\u0161\u00ed, tak pri spracovan\u00ed po\u017eiadaviek na ka\u017ed\u00fa d\u00e1vku \u00fadajov bude potrebn\u00e9 skuto\u010dne z\u00edska\u0165 ch\u00fdbaj\u00face k\u013e\u00fa\u010de a vyzdvihn\u00fa\u0165 \u00fadaje z MySQL. O ClickHouse e\u0161te m\u00f4\u017eem poveda\u0165, \u017ee - \u00e1no, nezadr\u017eiava, o in\u00fdch syst\u00e9moch rozpr\u00e1va\u0165 nebudem.<\/p>\n

<\/p>\n

A ako bonus je to, \u017ee slovn\u00edky s\u00fa ve\u013emi jednoduch\u00fd sp\u00f4sob, ako aktualizova\u0165 \u00fadaje v ClickHouse pozadu. T. j. mali ste report o reklamn\u00fdch kampaniach, pou\u017e\u00edvate\u013e jednoducho zmenil reklamn\u00fa kampa\u0148 a vo v\u0161etk\u00fdch star\u00fdch \u00fadajoch, vo v\u0161etk\u00fdch reportoch, sa tieto \u00fadaje tie\u017e zmenili. Ak by ste zapisovali riadky priamo do tabu\u013eky, aktualizova\u0165 ich by bolo nemo\u017en\u00e9. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010eal\u0161\u00edm sp\u00f4sobom, ke\u010f neviete, odkia\u013e vzia\u0165 identifik\u00e1tory pre va\u0161e riadky, je jednoducho ich zahashova\u0165. A najjednoduch\u0161ia mo\u017enos\u0165 je zobra\u0165 64-bitov\u00fd hash. <\/p>\n

<\/p>\n

Jedin\u00fd probl\u00e9m je, \u017ee ak je hash 64-bitov\u00fd, kol\u00edzie sa v\u00e1m takmer ur\u010dite vyskytn\u00fa. Preto\u017ee ak tam m\u00e1te miliardu riadkov, pravdepodobnos\u0165 sa u\u017e st\u00e1va v\u00fdznamnou. <\/p>\n

<\/p>\n

A nebolo by ve\u013emi dobr\u00e9 takto hashova\u0165 men\u00e1 reklamn\u00fdch kampan\u00ed. Ak sa reklamn\u00e9 kampane r\u00f4znych spolo\u010dnost\u00ed pom\u00fdlia, bude to nie\u010do nepreh\u013eadn\u00e9. <\/p>\n

<\/p>\n

A existuje jednoduch\u00fd trik. Pravda, pro v\u00e1\u017en\u00e1 data to tak\u00e9 nen\u00ed moc vhodn\u00e9, ale pokud jde o n\u011bco m\u00e9n\u011b d\u016fle\u017eit\u00e9ho, sta\u010d\u00ed do kl\u00ed\u010de slovn\u00edku p\u0159idat je\u0161t\u011b identifik\u00e1tor klienta. Pak budou kolize, ale jen v r\u00e1mci jednoho klienta. Tento zp\u016fsob pou\u017e\u00edv\u00e1me pro mapu odkaz\u016f v Yandex.Metrice. M\u00e1me tam URL adresy, ukl\u00e1d\u00e1me hash. A v\u00edme, \u017ee kolize samoz\u0159ejm\u011b existuj\u00ed. Ale kdy\u017e se zobraz\u00ed str\u00e1nka, pravd\u011bpodobnost, \u017ee na jedn\u00e9 str\u00e1nce u jednoho u\u017eivatele se n\u011bjak\u00e9 URL adresy slou\u010dily a je\u0161t\u011b si toho n\u011bkdo v\u0161imne, je obvykle zanedbateln\u00e1. <\/p>\n

<\/p>\n

Jako bonus \u2013 pro mnoho operac\u00ed sta\u010d\u00ed pouze hashe a samotn\u00e9 \u0159et\u011bzce nemus\u00ed b\u00fdt nikde ukl\u00e1d\u00e1ny. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad je, pokud jsou \u0159et\u011bzce kr\u00e1tk\u00e9, nap\u0159\u00edklad dom\u00e9ny str\u00e1nek. Ty lze uchov\u00e1vat tak, jak jsou. Nebo t\u0159eba jazyk prohl\u00ed\u017ee\u010de ru \u2013 2 bajty. Samoz\u0159ejm\u011b, je mi l\u00edto ka\u017ed\u00fd byte, ale nebojte se, 2 bajty nejsou probl\u00e9m. Pros\u00edm, uchov\u00e1vejte je tak, jak jsou, a neomezujte se. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Jin\u00fd p\u0159\u00edpad je, kdy\u017e m\u00e1me naopak hodn\u011b \u0159et\u011bzc\u016f a v nich je hodn\u011b unik\u00e1tn\u00edch hodnot, p\u0159i\u010dem\u017e mno\u017estv\u00ed nen\u00ed omezeno. Typick\u00fdm p\u0159\u00edkladem jsou vyhled\u00e1vac\u00ed fr\u00e1ze nebo URL adresy. Vyhled\u00e1vac\u00ed fr\u00e1ze, v\u010detn\u011b t\u011bch s p\u0159eklepy. Pod\u00edv\u00e1me se, kolik unik\u00e1tn\u00edch vyhled\u00e1vac\u00edch fr\u00e1z\u00ed m\u00e1me za den. A zjist\u00edme, \u017ee jich je t\u00e9m\u011b\u0159 polovina ze v\u0161ech ud\u00e1lost\u00ed. A v tomto p\u0159\u00edpad\u011b byste si mohli myslet, \u017ee je t\u0159eba data normalizovat, spo\u010d\u00edtat identifik\u00e1tory a ulo\u017eit do samostatn\u00e9 tabulky. Ale tak to d\u011blat nemus\u00edte. Jen je prost\u011b uchov\u00e1vejte tak, jak jsou. <\/p>\n

<\/p>\n

Lep\u0161\u00ed je \u2013 nic si nevym\u00fd\u0161let, proto\u017ee pokud je budete uchov\u00e1vat odd\u011blen\u011b, bude pot\u0159eba prov\u00e1d\u011bt join. A ten join \u2013 to je v tom nejlep\u0161\u00edm p\u0159\u00edpad\u011b n\u00e1hodn\u00fd p\u0159\u00edstup do pam\u011bti, pokud se to v\u016fbec vejde do pam\u011bti. Pokud ne, budou s t\u00edm \u00fapln\u011b probl\u00e9my. <\/p>\n

<\/p>\n

A pokud jsou data ukl\u00e1d\u00e1na na m\u00edst\u011b, pak se jednodu\u0161e na\u010d\u00edtaj\u00ed v po\u017eadovan\u00e9m po\u0159ad\u00ed z souborov\u00e9ho syst\u00e9mu a v\u0161echno je v po\u0159\u00e1dku.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Pokud m\u00e1te URL adresy nebo n\u011bjak\u00e9 slo\u017eit\u00e9 dlouh\u00e9 \u0159et\u011bzce, stoj\u00ed za to uva\u017eovat o tom, \u017ee byste mohli p\u0159edem spo\u010d\u00edtat n\u011bjakou zkratku a zapsat ji do samostatn\u00e9ho sloupce. <\/p>\n

<\/p>\n

Pro URL adresy m\u016f\u017eete nap\u0159\u00edklad zvl\u00e1\u0161\u0165 uchov\u00e1vat dom\u00e9nu. A pokud skute\u010dn\u011b pot\u0159ebujete dom\u00e9nu, prost\u011b pou\u017eijte tento sloupec, zat\u00edmco URL adresy budou ulo\u017eeny a k nim se ani nedotknete. <\/p>\n

<\/p>\n

Pozrime sa na rozdiel. V ClickHouse je \u0161pecializovan\u00e1 funkcia, ktor\u00e1 po\u010d\u00edta dom\u00e9nu. Je ve\u013emi r\u00fdchla, optimalizovali sme ju. A \u00faprimne, ani to nevyhovuje RFC, ale aj tak po\u010d\u00edta v\u0161etko, \u010do potrebujeme. <\/p>\n

<\/p>\n

V jednom pr\u00edpade jednoducho vytiahneme URL a vypo\u010d\u00edtame dom\u00e9nu. Dostaneme 166 milisek\u00fand. A ak vezmeme hotov\u00fa dom\u00e9nu, vych\u00e1dza to iba 67 milisek\u00fand, t. j. takmer trikr\u00e1t r\u00fdchlej\u0161ie. R\u00fdchlej\u0161ie to nie je preto, \u017ee by sme museli robi\u0165 nejak\u00e9 v\u00fdpo\u010dty, ale preto, \u017ee \u010d\u00edtame menej d\u00e1t. <\/p>\n

<\/p>\n

Pre\u010do m\u00e1 jeden dopyt, ktor\u00fd je pomal\u0161\u00ed, v\u00e4\u010d\u0161iu r\u00fdchlos\u0165 gigabajtov za sekundu? Lebo \u010d\u00edta viac gigabajtov. S\u00fa to \u00faplne zbyto\u010dn\u00e9 d\u00e1ta. Dopyt vlastne funguje r\u00fdchlej\u0161ie, ale trv\u00e1 dlh\u0161ie.<\/p>\n

<\/p>\n

Ak sa pozrieme na objem d\u00e1t na disku, zist\u00edme, \u017ee URL m\u00e1 126 megabajtov, zatia\u013e \u010do dom\u00e9na iba 5 megabajtov. To je 25-kr\u00e1t menej. Napriek tomu sa dopyt vykon\u00e1va iba 4-kr\u00e1t r\u00fdchlej\u0161ie. Ale to je preto, \u017ee d\u00e1ta s\u00fa hor\u00face. Ak by boli studen\u00e9, ur\u010dite by to bolo 25-kr\u00e1t r\u00fdchlej\u0161ie kv\u00f4li diskov\u00e9mu vstupu a v\u00fdstupu. <\/p>\n

<\/p>\n

Mimochodom, ak odhadneme, ko\u013eko je dom\u00e9na men\u0161ia ako URL, vyjde to niekde okolo 4-kr\u00e1t. Ale z nejak\u00e9ho d\u00f4vodu d\u00e1ta na disku zabieraj\u00fa 25-kr\u00e1t menej. Pre\u010do? Kv\u00f4li kompresii. A URL je komprimovan\u00e9, a dom\u00e9na je komprimovan\u00e1. Ale \u010dasto URL obsahuje mno\u017estvo odpadu. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A samozrejme, je potrebn\u00e9 pou\u017e\u00edva\u0165 spr\u00e1vne typy d\u00e1t, ktor\u00e9 s\u00fa \u0161peci\u00e1lne ur\u010den\u00e9 pre dan\u00e9 hodnoty alebo ktor\u00e9 sa hodia. Ak m\u00e1te IPv4, pou\u017e\u00edvajte UInt32*. Ak IPv6, tak FixedString(16), preto\u017ee IPv6 adresa m\u00e1 128 bitov, t. j. ulo\u017ete ju priamo v bin\u00e1rnom form\u00e1te. <\/p>\n

<\/p>\n

\u010co robi\u0165, ak m\u00e1te niekedy IPv4 adresy a inokedy IPv6? \u00c1no, m\u00f4\u017eete uchov\u00e1va\u0165 obe. Jeden st\u013apec pre IPv4, druh\u00fd pre IPv6. Samozrejme, existuje mo\u017enos\u0165 zobrazi\u0165 IPv4 v IPv6. To tie\u017e bude fungova\u0165, ale ak \u010dasto potrebujete presne IPv4 adresu, bolo by dobr\u00e9 ju ulo\u017ei\u0165 do samostatn\u00e9ho st\u013apca. <\/p>\n

<\/p>\n

* teraz v ClickHouse existuj\u00fa samostatn\u00e9 typy d\u00e1t IPv4, IPv6, ktor\u00e9 ukladaj\u00fa \u00fadaje rovnako efekt\u00edvne ako \u010d\u00edsla, ale zobrazuj\u00fa ich rovnako pohodlne ako re\u0165azce.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Je d\u00f4le\u017eit\u00e9 poznamena\u0165, \u017ee je vhodn\u00e9 \u00fadaje predspracova\u0165 vopred. Napr\u00edklad, ak k v\u00e1m pr\u00eddu nejak\u00e9 surov\u00e9 logy. A mo\u017eno nie je najlep\u0161ie ich hne\u010f posla\u0165 do ClickHouse, aj ke\u010f je l\u00e1kav\u00e9 ni\u010d neurobi\u0165 a v\u0161etko bude fungova\u0165. Ale predsa len by ste mali vykona\u0165 v\u00fdpo\u010dty, ktor\u00e9 s\u00fa mo\u017en\u00e9.<\/p>\n

<\/p>\n

Napr\u00edklad, verzia prehliada\u010da. V nejakom susednom oddelen\u00ed, na ktor\u00e9 sa mi nechce ukazova\u0165 prstom, sa verzia prehliada\u010da uchov\u00e1va takto, t. j. ako re\u0165azec: 12.3. A potom, aby vytvorili report, vezm\u00fa tento re\u0165azec a rozdelia ho na pole, a potom na prv\u00fa polo\u017eku po\u013ea. Samozrejme, v\u0161etko spomal\u00ed. P\u00fdtal som sa, pre\u010do to tak robia. Odpovedali mi, \u017ee nemaj\u00fa radi pred\u010dasn\u00fa optimaliz\u00e1ciu. A ja nem\u00e1m r\u00e1d pred\u010dasn\u00fa pesimiz\u00e1ciu.<\/p>\n

<\/p>\n

Tak\u017ee v tomto pr\u00edpade by bolo spr\u00e1vnej\u0161ie rozdeli\u0165 na 4 st\u013apce. Nebojte sa, preto\u017ee toto je ClickHouse. ClickHouse je st\u013apcov\u00e1 datab\u00e1za. A \u010d\u00edm viac presn\u00fdch mal\u00fdch st\u013apcov, t\u00fdm lep\u0161ie. Ak bude 5 BrowserVersion, urobte 5 st\u013apcov. To je v poriadku. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Po\u010fme sa teraz pozrie\u0165, \u010do robi\u0165, ak m\u00e1te ve\u013ea ve\u013emi dlh\u00fdch re\u0165azcov, ve\u013emi dlh\u00fdch pol\u00ed. Nemus\u00edte ich v\u00f4bec uchov\u00e1va\u0165 v ClickHouse. Namiesto toho m\u00f4\u017eete v ClickHouse ulo\u017ei\u0165 len nejak\u00fd identifik\u00e1tor. A tieto dlh\u00e9 re\u0165azce si dajte do in\u00e9ho syst\u00e9mu. <\/p>\n

<\/p>\n

Napr\u00edklad, v jednom z na\u0161ich analytick\u00fdch slu\u017eieb s\u00fa niektor\u00e9 parametre udalost\u00ed. A ak na udalosti prich\u00e1dza ve\u013ea parametrov, jednoducho ulo\u017e\u00edme prv\u00fdch 512, ktor\u00e9 sa n\u00e1m naskytn\u00fa. Preto\u017ee 512 nie je \u0161koda. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A ak si nie ste ist\u00ed svojimi typmi \u00fadajov, m\u00f4\u017eete tie\u017e zap\u00edsa\u0165 \u00fadaje do ClickHouse, ale do do\u010dasnej tabu\u013eky typu Log, \u0161peci\u00e1lnej pre do\u010dasn\u00e9 \u00fadaje. Potom m\u00f4\u017eete analyzova\u0165, ak\u00e9 m\u00e1te rozdelenie hodn\u00f4t, \u010do vlastne existuje a zostavi\u0165 spr\u00e1vne typy.<\/p>\n

<\/p>\n

* teraz v ClickHouse existuje typ \u00fadajov LowCardinality<\/a><\/noindex> ktor\u00fd umo\u017e\u0148uje efekt\u00edvne uchov\u00e1vanie re\u0165azcov s ni\u017e\u0161\u00edmi n\u00e1rokmi na zdroje.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Po\u010fme sa teraz pozrie\u0165 na e\u0161te jeden zauj\u00edmav\u00fd pr\u00edpad. Niekedy u \u013eud\u00ed v\u0161etko akosi zvl\u00e1\u0161tne funguje. Vst\u00fapim a vid\u00edm nie\u010do tak\u00e9. A okam\u017eite sa predstavi\u0165, \u017ee to robil nejak\u00fd ve\u013emi sk\u00fasen\u00fd, m\u00fadry admin, ktor\u00fd m\u00e1 ve\u013ek\u00e9 sk\u00fasenosti so nastavovan\u00edm MySQL verzie 3.23. <\/p>\n

<\/p>\n

Tu vid\u00edme tis\u00edc tabuliek, v ka\u017edej z nich je zap\u00edsan\u00fd zostatok z delenia nejasne \u010doho na tis\u00edc. <\/p>\n

<\/p>\n

V podstate re\u0161pektujem sk\u00fasenosti in\u00fdch a ch\u00e1pem, ak\u00e9 utrpenia mohli vies\u0165 k t\u00fdmto sk\u00fasenostiam. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A d\u00f4vody s\u00fa viac-menej jasn\u00e9. To s\u00fa star\u00e9 stereotypy, ktor\u00e9 sa mohli nahromadi\u0165 po\u010das pr\u00e1ce s in\u00fdmi syst\u00e9mami. Napr\u00edklad, v tabu\u013ek\u00e1ch MyISAM neexistuje klastrov\u00fd prim\u00e1rny k\u013e\u00fa\u010d. Tak\u00fdto sp\u00f4sob delenia d\u00e1t m\u00f4\u017ee by\u0165 z\u00fafal\u00fdm pokusom z\u00edska\u0165 rovnak\u00fa funk\u010dnos\u0165. <\/p>\n

<\/p>\n

\u010eal\u0161\u00ed d\u00f4vod spo\u010d\u00edva v tom, \u017ee ak\u00e9ko\u013evek oper\u00e1cie ako alter s ve\u013ek\u00fdmi tabu\u013ekami s\u00fa \u0165a\u017ek\u00e9. V\u0161etko bude zablokovan\u00e9. Hoci v s\u00fa\u010dasn\u00fdch verzi\u00e1ch MySQL u\u017e tento probl\u00e9m nie je tak\u00fd v\u00e1\u017eny. <\/p>\n

<\/p>\n

Alebo, napr\u00edklad, mikro\u0161ardovanie, ale o tom si povieme nesk\u00f4r.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

V ClickHouse to takto robi\u0165 netreba, preto\u017ee, po prv\u00e9, prim\u00e1rny k\u013e\u00fa\u010d je klastrov\u00fd a d\u00e1ta s\u00fa usporiadan\u00e9 pod\u013ea prim\u00e1rneho k\u013e\u00fa\u010da. <\/p>\n

<\/p>\n

A niekedy sa ma p\u00fdtaj\u00fa: \u201eAko sa men\u00ed v\u00fdkonnos\u0165 rozsahov\u00fdch dotazov v ClickHouse v z\u00e1vislosti od ve\u013ekosti tabu\u013eky?\u201c. Hovor\u00edm, \u017ee sa v\u00f4bec nemen\u00ed. Napr\u00edklad, m\u00e1te tabu\u013eku s miliardou riadkov a \u010d\u00edtate rozsah jeden mili\u00f3n riadkov. V\u0161etko je v poriadku. Ak je tabu\u013eka s trili\u00f3nom riadkov a \u010d\u00edtate jeden mili\u00f3n riadkov, bude to skoro to ist\u00e9. <\/p>\n

<\/p>\n

A za druh\u00e9, nepotrebujete \u017eiadne ru\u010dn\u00e9 part\u00edcie. Ak sa pozriete na s\u00faborov\u00fd syst\u00e9m, uvid\u00edte, \u017ee tabu\u013eka je dos\u0165 v\u00fdznamn\u00e1 z\u00e1le\u017eitos\u0165. A vo vn\u00fatri je nie\u010do ako part\u00edcie. Teda ClickHouse v\u0161etko rob\u00ed za v\u00e1s a nemus\u00edte trpie\u0165.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Alter v ClickHouse je bezplatn\u00fd, ak ide o alter add\/drop column. <\/p>\n

<\/p>\n

A mal\u00e9 tabu\u013eky netreba robi\u0165, preto\u017ee ak m\u00e1te v tabu\u013eke 10 riadkov alebo 10 000 riadkov, nie je to v\u00f4bec d\u00f4le\u017eit\u00e9. ClickHouse je syst\u00e9m, ktor\u00fd optimalizuje priepustnos\u0165, a nie latenciu, tak\u017ee ma\u0165 10 riadkov na spracovanie nem\u00e1 zmysel. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Spr\u00e1vne je pou\u017e\u00edva\u0165 jednu ve\u013ek\u00fa tabu\u013eku. Zbavte sa star\u00fdch stereotypov, v\u0161etko bude v poriadku. <\/p>\n

<\/p>\n

A ako bonus, v na\u0161ej poslednej verzii sa objavila mo\u017enos\u0165 robi\u0165 \u013eubovo\u013en\u00fd k\u013e\u00fa\u010d particionovania na vykon\u00e1vanie r\u00f4znych \u00fadr\u017ebov\u00fdch oper\u00e1ci\u00ed nad jednotliv\u00fdmi part\u00edciami. <\/p>\n

<\/p>\n

Napr\u00edklad, potrebujete ve\u013ea mal\u00fdch tabuliek, ke\u010f je potreba spracovania nejak\u00fdch medzi\u010dasov\u00fdch \u00fadajov, prich\u00e1dzaj\u00fa v\u00e1m \u010dasti a mus\u00edte nad nimi vykona\u0165 transform\u00e1ciu predt\u00fdm, ne\u017e ich zap\u00ed\u0161ete do kone\u010dnej tabu\u013eky. Pre tento pr\u00edpad existuje skvel\u00fd engine tabuliek \u2013 StripeLog. Je to pribli\u017ene ako TinyLog, len lep\u0161ie. <\/p>\n

<\/p>\n

* teraz v ClickHouse existuje aj tabu\u013ekov\u00e1 funkcia input<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed antipattern \u2013 mikrosharding. Napr\u00edklad, potrebujete shardova\u0165 \u00fadaje a m\u00e1te 5 serverov, ale zajtra bude 6 serverov. A rozm\u00fd\u0161\u013eate, ako tieto \u00fadaje prebalancova\u0165. Namiesto toho rozdel\u00edte nie na 5 shardov, ale na 1 000 shardov. A \u010falej mapujete ka\u017ed\u00fd z t\u00fdchto mikroshardov na samostatn\u00fd server. A na jednom serveri sa tak m\u00f4\u017ee napr\u00edklad nach\u00e1dza\u0165 200 ClickHouse, napr\u00edklad. Samostatn\u00e9 in\u0161tancie na r\u00f4znych portoch alebo samostatn\u00e9 datab\u00e1zy. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Ale v ClickHouse to nie je ve\u013emi dobre. Preto\u017ee aj jeden in\u0161tan\u010dn\u00fd ClickHouse sa sna\u017e\u00ed vyu\u017ei\u0165 v\u0161etky dostupn\u00e9 zdroje servera na spracovanie jedn\u00e9ho dopytu. T. j. m\u00e1te nejak\u00fd server a tam je napr\u00edklad 56 procesorov\u00fdch jadier. Vykon\u00e1vate dopyt, ktor\u00fd trv\u00e1 jednu sekundu, a ten vyu\u017e\u00edva 56 jadier. A ak ste umiestnili 200 ClickHouse na jeden server, tak sa spust\u00ed 10 000 vl\u00e1kien. V skratke, v\u0161etko bude ve\u013emi zl\u00e9.<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed d\u00f4vod je ten, \u017ee rozdelenie pr\u00e1ce medzi t\u00fdmito in\u0161tanciami bude nevyv\u00e1\u017een\u00e9. Nejak\u00e1 z nich skon\u010d\u00ed sk\u00f4r, in\u00e1 skon\u010d\u00ed nesk\u00f4r. Keby sa to v\u0161etko dialo v jednej in\u0161tancii, ClickHouse by s\u00e1m vedel, ako spr\u00e1vne rozdeli\u0165 \u00fadaje medzi vl\u00e1knami. <\/p>\n

<\/p>\n

A e\u0161te jeden d\u00f4vod je, \u017ee budete ma\u0165 medziprocesorov\u00fa komunik\u00e1ciu cez TCP. \u00dadaje bude potrebn\u00e9 serializova\u0165, deserializova\u0165 a s t\u00fdmto obrovsk\u00fdm mno\u017estvom mikroshardov to jednoducho nebude efekt\u00edvne.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010eal\u0161\u00ed antipattern, aj ke\u010f to \u0165a\u017eko nazva\u0165 antipatternom. Je to ve\u013ek\u00e9 mno\u017estvo predagreg\u00e1cie.<\/p>\n

<\/p>\n

Celkom, predagreg\u00e1cia \u2013 to je dobre. Mali ste miliardu riadkov, aggreovali ste ich a vzniklo 1 000 riadkov, a teraz sa dopyt vykon\u00e1va okam\u017eite. V\u0161etko je skvel\u00e9. Takto sa to d\u00e1 robi\u0165. A pre to m\u00e1 ClickHouse dokonca \u0161peci\u00e1lny typ tabu\u013eky AggregatingMergeTree, ktor\u00fd rob\u00ed inkrement\u00e1lnu agreg\u00e1ciu po\u010das vkladania \u00fadajov. <\/p>\n

<\/p>\n

Existuj\u00fa v\u0161ak pr\u00edpady, ke\u010f si mysl\u00edte, \u017ee budeme agregova\u0165 \u00fadaje takto a e\u0161te takto. A v nejakom ved\u013eaj\u0161om oddelen\u00ed, o ktorom sa mi tie\u017e nechce hovori\u0165, pou\u017e\u00edvaj\u00fa tabu\u013eky SummingMergeTree na s\u010d\u00edta\u0165 pod\u013ea prim\u00e1rneho k\u013e\u00fa\u010da, pri\u010dom ako prim\u00e1rny k\u013e\u00fa\u010d pou\u017e\u00edvaj\u00fa pribli\u017ene 20 r\u00f4znych st\u013apcov. Pre kon\u0161pir\u00e1ciu som zmenil men\u00e1 niektor\u00fdch st\u013apcov, ale je to asi takto.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A objavuj\u00fa sa tak\u00e9to probl\u00e9my. Po prv\u00e9, objem va\u0161ich \u00fadajov sa nezmen\u0161uje pr\u00edli\u0161 v\u00fdrazne. Napr\u00edklad zn\u00ed\u017eenie je len trojn\u00e1sobn\u00e9. Trojn\u00e1sobn\u00e9 zn\u00ed\u017eenie by bola dobr\u00e1 cena na to, aby ste si mohli dovoli\u0165 neobmedzen\u00e9 mo\u017enosti analytiky, ktor\u00e9 prich\u00e1dzaj\u00fa, ak \u00fadaje nie s\u00fa agregovan\u00e9. Ak s\u00fa \u00fadaje agregovan\u00e9, dostanete namiesto analytiky len slab\u00fa \u0161tatistiku. <\/p>\n

<\/p>\n

A \u010do je obzvl\u00e1\u0161\u0165 frustruj\u00face? To, \u017ee t\u00edto \u013eudia z ved\u013eaj\u0161ieho oddelenia chodia a ob\u010das \u017eiadaj\u00fa prida\u0165 \u010fal\u0161\u00ed st\u013apec do prim\u00e1rneho k\u013e\u00fa\u010da. T. j. takto sme agregovali \u00fadaje, a teraz chceme nie\u010do viac. Ale v ClickHouse nie je mo\u017en\u00e9 upravi\u0165 prim\u00e1rny k\u013e\u00fa\u010d. Preto je potrebn\u00e9 p\u00edsa\u0165 nejak\u00e9 skripty v C++. A ja nem\u00e1m r\u00e1d skripty, ani ke\u010f s\u00fa v C++.<\/p>\n

<\/p>\n

A ak sa pozriete na to, na \u010do bol ClickHouse vytvoren\u00fd, tak neagregovan\u00e9 \u00fadaje s\u00fa presne ten scen\u00e1r, pre ktor\u00fd bol zroden\u00fd. Ak pou\u017e\u00edvate ClickHouse na neagregovan\u00e9 \u00fadaje, rob\u00edte to spr\u00e1vne. Ak v\u0161ak agregujete, je to niekedy odpustite\u013en\u00e9. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

\u010eal\u0161\u00edm zauj\u00edmav\u00fdm pr\u00edpadom s\u00fa dopyty v nekone\u010dnej slu\u010dke. Niekedy sa prihl\u00e1sim na nejak\u00fd produk\u010dn\u00fd server a pozriem sa na show processlist. A ka\u017ed\u00fd raz zist\u00edm, \u017ee sa deje nie\u010do hrozn\u00e9. <\/p>\n

<\/p>\n

Napr\u00edklad toto. Tu je jasn\u00e9, \u017ee v\u0161etko sa dalo vykona\u0165 v jednom dopyte. Sta\u010d\u00ed nap\u00edsa\u0165 tam url in a zoznam.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Pre\u010do je ve\u013ea tak\u00fdch dopytov v nekone\u010dnej slu\u010dke zl\u00e9? Ak sa index nepou\u017e\u00edva, budete ma\u0165 ve\u013ea prechodov po t\u00fdch ist\u00fdch \u00fadajoch. Ale ak sa index pou\u017e\u00edva, napr\u00edklad m\u00e1te prim\u00e1rny k\u013e\u00fa\u010d pod\u013ea ru a p\u00ed\u0161ete url = nie\u010domu. A mysl\u00edte si, \u017ee bude presne \u010d\u00edtan\u00fd z tabu\u013eky jeden url, bude to v poriadku. Ale v skuto\u010dnosti to tak nie je. Preto\u017ee ClickHouse rob\u00ed v\u0161etko po d\u00e1vkach. <\/p>\n

<\/p>\n

Ke\u010f potrebuje pre\u010d\u00edta\u0165 ur\u010dit\u00fd rozsah d\u00e1t, \u010d\u00edta o trochu viac, preto\u017ee index v ClickHouse je redovan\u00fd. Tento index neumo\u017e\u0148uje n\u00e1js\u0165 v tabu\u013eke jednu individu\u00e1lnu polo\u017eku, len ur\u010dit\u00fd rozsah. A d\u00e1ta sa komprimuj\u00fa po blokoch. Na to, aby ste pre\u010d\u00edtali jednu polo\u017eku, mus\u00edte vzia\u0165 cel\u00fd blok a dekomprimova\u0165 ho. A ak vykon\u00e1vate mno\u017estvo dotazov, m\u00e1te ve\u013ea tak\u00fdchto prekr\u00fdvan\u00ed, a ve\u013ea pr\u00e1ce sa bude vykon\u00e1va\u0165 znova a znova.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A ako bonus mo\u017eno poznamena\u0165, \u017ee v ClickHouse sa nemus\u00edte b\u00e1\u0165 posiela\u0165 dokonca megabajty a stovky megabajtov do sekcie IN. Pam\u00e4t\u00e1m si z na\u0161ej praxe, \u017ee ak v MySQL posielame ve\u013ea hodn\u00f4t do sekcie IN, napr\u00edklad posielame tam 100 megabajtov nejak\u00fdch \u010d\u00edsel, MySQL zje 10 gigabajtov pam\u00e4te a viac s t\u00fdm ni\u010d neurob\u00ed, v\u0161etko funguje zle. <\/p>\n

<\/p>\n

A druh\u00e1 vec je, \u017ee v ClickHouse, ak va\u0161e dotazy pou\u017e\u00edvaj\u00fa index, tak to nikdy nie je pomal\u0161ie ako full scan, t. j. ak treba pre\u010d\u00edta\u0165 takmer cel\u00fa tabu\u013eku, ide postupne a pre\u010d\u00edta cel\u00fa tabu\u013eku. V podstate sa s t\u00fdm s\u00e1m vysporiada.<\/p>\n

<\/p>\n

Ale predsa existuj\u00fa niektor\u00e9 komplik\u00e1cie. Napr\u00edklad to, \u017ee IN s poddotazom index nevyu\u017e\u00edva. Ale to je n\u00e1\u0161 probl\u00e9m a mus\u00edme to opravi\u0165. Ni\u010d z\u00e1sadn\u00e9 tu nie je. Budeme to opravova\u0165*. <\/p>\n

<\/p>\n

A e\u0161te jedna zauj\u00edmav\u00e1 vec \u2013 ak m\u00e1te ve\u013emi dlh\u00fd dotaz a rozdelen\u00e9 spracovanie dotazov prebieha, tak tento ve\u013emi dlh\u00fd dotaz bude poslan\u00fd na ka\u017ed\u00fd server bez kompresie. Napr\u00edklad 100 megabajtov a 500 serverov. A, samozrejme, v\u00e1m cez sie\u0165 prejde 50 gigabajtov. Bude prenesen\u00e9 a n\u00e1sledne v\u0161etko \u00faspe\u0161ne vykonan\u00e9.<\/p>\n

<\/p>\n

* u\u017e pou\u017e\u00edva; v\u0161etko sme opravili, ako bolo s\u013e\u00faben\u00e9.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

A dos\u0165 \u010dast\u00fd pr\u00edpad, ak dotazy prich\u00e1dzaj\u00fa z API. Napr\u00edklad ste vytvorili nejak\u00fa svoju slu\u017ebu. A ak je va\u0161a slu\u017eba niekomu potrebn\u00e1, tak ste otvorili API a u\u017e doslova po dvoch d\u0148och vid\u00edte, \u017ee sa deje nie\u010do nepochopite\u013en\u00e9. V\u0161etko je pre\u0165a\u017een\u00e9 a prich\u00e1dzaj\u00fa nejak\u00e9 hrozn\u00e9 dotazy, ktor\u00e9 nikdy nemali by\u0165. <\/p>\n

<\/p>\n

A rie\u0161enie je jedno. Ak ste otvorili API, budete ho musie\u0165 orez\u00e1va\u0165. Napr\u00edklad zavies\u0165 nejak\u00e9 kv\u00f3ty. In\u00e9 norm\u00e1lne mo\u017enosti nie s\u00fa. Inak okam\u017eite nap\u00ed\u0161u skript a bud\u00fa probl\u00e9my. <\/p>\n

<\/p>\n

V ClickHouse m\u00e1te \u0161peci\u00e1lnu funkciu \u2013 po\u010d\u00edtanie kv\u00f3t. M\u00f4\u017eete pred\u00e1va\u0165 svoj k\u013e\u00fa\u010d kv\u00f3ty. Napr\u00edklad, m\u00f4\u017ee to by\u0165 intern\u00fd identifik\u00e1tor pou\u017e\u00edvate\u013ea. Kv\u00f3ty sa bud\u00fa po\u010d\u00edta\u0165 samostatne pre ka\u017ed\u00e9ho z nich. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Teraz \u010fal\u0161ia zauj\u00edmav\u00e1 vec. Je to replik\u00e1cia na manu\u00e1lny pohon. <\/p>\n

<\/p>\n

Pozn\u00e1m mno\u017estvo pr\u00edpadov, ke\u010f, aj ke\u010f ClickHouse m\u00e1 zabudovan\u00fa podporu replik\u00e1cie, \u013eudia replikuj\u00fa ClickHouse manu\u00e1lne.<\/p>\n

<\/p>\n

Ak\u00fd je princ\u00edp? M\u00e1te pipeline na spracovanie \u00fadajov. A ten funguje nez\u00e1visle, napr\u00edklad, v r\u00f4znych d\u00e1tov\u00fdch centr\u00e1ch. Rovnak\u00e9 \u00fadaje zapisujete do ClickHouse rovnak\u00fdm sp\u00f4sobom. Pravda, prax ukazuje, \u017ee \u00fadaje sa aj tak rozch\u00e1dzaj\u00fa kv\u00f4li nejak\u00fdm \u0161pecifik\u00e1m vo va\u0161om k\u00f3de. D\u00fafam, \u017ee vo va\u0161om pr\u00edpade nie. <\/p>\n

<\/p>\n

A pravidelne budete musie\u0165 manu\u00e1lne synchronizova\u0165. Napr\u00edklad raz za mesiac administr\u00e1tori robia rsync.<\/p>\n

<\/p>\n

Naozaj je ove\u013ea jednoduch\u0161ie pou\u017e\u00edva\u0165 zabudovan\u00fa replik\u00e1ciu v ClickHouse. Ale tu m\u00f4\u017eu by\u0165 niektor\u00e9 kontraindik\u00e1cie, preto\u017ee na to potrebujete pou\u017e\u00edva\u0165 ZooKeeper. O ZooKeeperi nebudem hovori\u0165 ni\u010d zl\u00e9, v z\u00e1sade je syst\u00e9m funk\u010dn\u00fd, ale niektor\u00ed \u013eudia ho nepou\u017e\u00edvaj\u00fa z d\u00f4vodu java-f\u00f3bie, preto\u017ee ClickHouse je dobr\u00fd syst\u00e9m nap\u00edsan\u00fd v C++, s ktor\u00fdm sa d\u00e1 pracova\u0165 a v\u0161etko bude skvel\u00e9. A ZooKeeper je na jave. A nejako sa nechce na to pozera\u0165, ale potom m\u00f4\u017eete pou\u017ei\u0165 replik\u00e1ciu na manu\u00e1lny pohon. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

ClickHouse je praktick\u00fd syst\u00e9m. Zoh\u013ead\u0148uje va\u0161e potreby. Ak m\u00e1te replik\u00e1ciu na manu\u00e1lny pohon, m\u00f4\u017eete vytvori\u0165 Distributed tabu\u013eku, ktor\u00e1 sleduje va\u0161e manu\u00e1lne repliky a sama rob\u00ed failover medzi nimi. Existuje dokonca \u0161peci\u00e1lna mo\u017enos\u0165, ktor\u00e1 umo\u017e\u0148uje vyhn\u00fa\u0165 sa zlyhaniam, aj ke\u010f sa va\u0161e repliky systematicky rozch\u00e1dzaj\u00fa.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

S\u00fa mo\u017en\u00e9 probl\u00e9my, ak pou\u017e\u00edvate primit\u00edvne table engines. ClickHouse je tak\u00fd kon\u0161trukt\u00e9r, v ktorom je mno\u017estvo r\u00f4znych typov tabuliek. Pre v\u0161etky v\u00e1\u017ene pr\u00edpady, ako je uveden\u00e9 v dokument\u00e1cii, pou\u017e\u00edvajte tabu\u013eky rodiny MergeTree. Ostatn\u00e9 s\u00fa len na samostatn\u00e9 pr\u00edpady alebo na testovanie.<\/p>\n

<\/p>\n

V tabu\u013eke MergeTree nie je nutn\u00e9, aby ste mali nejak\u00fd d\u00e1tum a \u010das. M\u00f4\u017eete ho st\u00e1le pou\u017e\u00edva\u0165. Ak nem\u00e1te d\u00e1tum a \u010das, nastavte default \u2013 2000 rok. To bude fungova\u0165 a nebude vy\u017eadova\u0165 zdroje. <\/p>\n

<\/p>\n

A v novej verzii servera m\u00f4\u017eete dokonca uvies\u0165, aby ste mali vlastn\u00e9 rozdelenie bez k\u013e\u00fa\u010da partition. Bude to to ist\u00e9. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Na druhej strane, m\u00f4\u017eete pou\u017ei\u0165 primit\u00edvne tabu\u013ekov\u00e9 motory. Napr\u00edklad, na\u010d\u00edta\u0165 d\u00e1ta raz a pozrie\u0165 sa, preklopi\u0165 a odstr\u00e1ni\u0165. M\u00f4\u017eete pou\u017ei\u0165 Log.<\/p>\n

<\/p>\n

Alebo uchov\u00e1vanie mal\u00fdch objemov na medzizpracovanie \u2013 to je StripeLog alebo TinyLog.<\/p>\n

<\/p>\n

Memory m\u00f4\u017eete pou\u017ei\u0165, ak m\u00e1te mal\u00fd objem d\u00e1t a jednoducho sk\u00fa\u0161ate nie\u010do v operat\u00edvnej pam\u00e4ti. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

ClickHouse ve\u013emi nepreferuje prenormalizovan\u00e9 d\u00e1ta. <\/p>\n

<\/p>\n

Tu je typick\u00fd pr\u00edklad. Je to obrovsk\u00e9 mno\u017estvo URL. Dali ste ich do susednej tabu\u013eky. A potom ste sa rozhodli s nimi uskuto\u010dni\u0165 JOIN, ale to obvykle nebude fungova\u0165, preto\u017ee ClickHouse podporuje iba Hash JOIN. Ak nie je dostatok pam\u00e4te pre mno\u017estvo d\u00e1t, s ktor\u00fdmi sa m\u00e1 spoji\u0165, JOIN nebude mo\u017en\u00e9 vykona\u0165*. <\/p>\n

<\/p>\n

Ak s\u00fa d\u00e1ta ve\u013ekej kardinality, nebojte sa, uchov\u00e1vajte ich v denormalizovanej podobe, URL priamo v hlavnej tabu\u013eke. <\/p>\n

<\/p>\n

* a teraz ClickHouse m\u00e1 aj merge join, ktor\u00fd funguje, ke\u010f sa medzid\u00e1ta nezmestia do operat\u00edvnej pam\u00e4te. Ale to nie je efekt\u00edvne a doporu\u010denie zost\u00e1va v platnosti.<\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

E\u0161te nieko\u013eko pr\u00edkladov, ale u\u017e pochybujem, \u010di s\u00fa protikladn\u00e9 alebo nie. <\/p>\n

<\/p>\n

V ClickHouse existuje jedna zn\u00e1ma nev\u00fdhoda. Nevie vykon\u00e1va\u0165 aktualiz\u00e1cie*. V istom zmysle je to dokonca dobr\u00e9. Ak m\u00e1te nejak\u00e9 d\u00f4le\u017eit\u00e9 d\u00e1ta, napr\u00edklad \u00fa\u010dtovn\u00edctvo, nikto ich nebude m\u00f4c\u0165 odosla\u0165, preto\u017ee aktualiz\u00e1cie neexistuj\u00fa.<\/p>\n

<\/p>\n

* d\u00e1vno bola pridan\u00e1 podpora pre update a delete v d\u00e1vkovom re\u017eime.<\/p>\n

<\/p>\n

Ale existuj\u00fa niektor\u00e9 \u0161peci\u00e1lne sp\u00f4soby, ktor\u00e9 umo\u017e\u0148uj\u00fa aktualiz\u00e1cie akoby na pozad\u00ed. Napr\u00edklad tabu\u013eky typu ReplaceMergeTree. Robia aktualiz\u00e1cie po\u010das pozadov\u00fdch zl\u00fa\u010den\u00ed. M\u00f4\u017eete to vyn\u00fati\u0165 pomocou optimize table. Ale nerobte to pr\u00edli\u0161 \u010dasto, preto\u017ee to bude \u00fapln\u00e9 prep\u00edsanie partition. <\/p>\n

<\/p>\n

Distribuovan\u00e9 JOIN v ClickHouse s\u00fa tie\u017e \u0165a\u017eko spracovate\u013en\u00e9 pl\u00e1nova\u010dom dotazov. <\/p>\n

<\/p>\n

Zle, ale niekedy v poriadku.<\/p>\n

<\/p>\n

Pou\u017eitie ClickHouse iba na to, aby ste \u010d\u00edtali d\u00e1ta sp\u00e4\u0165 pomocou select*.<\/p>\n

<\/p>\n

Odpor\u00fa\u010dam sa vyhn\u00fa\u0165 pou\u017e\u00edvaniu ClickHouse pre objemn\u00e9 v\u00fdpo\u010dty. Ale nie je to \u00faplne tak, preto\u017ee u\u017e z tejto rady ustupujeme. Ned\u00e1vno sme pridali mo\u017enos\u0165 aplikova\u0165 modely strojov\u00e9ho u\u010denia v ClickHouse \u2013 Catboost. A to ma znepokojuje, preto\u017ee si hovor\u00edm: \u201eAko hrozn\u00e9. Ko\u013eko cyklov sa vlastne na bajt spotrebuje!\u201c. Je mi \u013e\u00fato, \u017ee cykly id\u00fa na bajty. <\/p>\n

<\/p>\n

\"Efekt\u00edvne<\/p>\n

<\/p>\n

Ale nebojte sa, nain\u0161talujte si ClickHouse, v\u0161etko bude v poriadku. Ak nie\u010do, m\u00e1me komunitu. Mimochodom, komunita ste vy. A ak m\u00e1te nejak\u00e9 probl\u00e9my, m\u00f4\u017eete aspo\u0148 zav\u00edta\u0165 do n\u00e1\u0161ho chatu a d\u00fafam, \u017ee v\u00e1m pom\u00f4\u017eu. <\/p>\n

<\/p>\n

Ot\u00e1zky<\/p>\n

<\/p>\n

\u010eakujem za prezent\u00e1ciu! Kde sa m\u00f4\u017eem s\u0165a\u017eova\u0165 na p\u00e1d ClickHouse?<\/em><\/p>\n

<\/p>\n

M\u00f4\u017eete sa s\u0165a\u017eova\u0165 mne osobne hne\u010f teraz. <\/p>\n

<\/p>\n

Ned\u00e1vno som za\u010dal pou\u017e\u00edva\u0165 ClickHouse. Hne\u010f som zr\u00fatil cli rozhranie.<\/em><\/p>\n

<\/p>\n

M\u00e1te \u0161\u0165astie. <\/p>\n

<\/p>\n

Trochu nesk\u00f4r som zr\u00fatil server mal\u00fdm selectom.<\/em><\/p>\n

<\/p>\n

M\u00e1te talent. <\/p>\n

<\/p>\n

Otv\u00e1ral som bug na GitHub, ale ignorovali ho.<\/em> <\/p>\n

<\/p>\n

Uvid\u00edme. <\/p>\n

<\/p>\n

Alexej ma podvodom nal\u00e1kal na predn\u00e1\u0161ku, s\u013e\u00fabil, \u017ee povie, ako stla\u010d\u00edte \u00fadaje vo vn\u00fatri.<\/em><\/p>\n

<\/p>\n

Ve\u013emi jednoducho. <\/p>\n

<\/p>\n

To som e\u0161te v\u010dera rozumel. Viac konkr\u00e9tnost\u00ed.<\/em> <\/p>\n

<\/p>\n

Nie s\u00fa tam \u017eiadne \u00fa\u017easn\u00e9 triky. Je tam jednoducho kompresia po blokoch. Predvolene sa pou\u017e\u00edva LZ4, je mo\u017en\u00e9 aktivova\u0165 ZSTD*. Bloky od 64 kilobajtov do 1 megabajtu.<\/p>\n

<\/p>\n

* existuje aj podpora \u0161pecializovan\u00fdch kompresn\u00fdch kodekov, ktor\u00e9 je mo\u017en\u00e9 pou\u017ei\u0165 v re\u0165azci s in\u00fdmi algoritmami.<\/p>\n

<\/p>\n

S\u00fa v blokoch len surov\u00e9 d\u00e1ta?<\/em><\/p>\n

<\/p>\n

Nie \u00faplne surov\u00e9. S\u00fa tam polia. Ak m\u00e1te \u010d\u00edseln\u00fd st\u013apec, \u010d\u00edsla s\u00fa ulo\u017een\u00e9 za sebou v poli. <\/p>\n

<\/p>\n

Rozumiem.<\/em> <\/p>\n

<\/p>\n

Alexej, pr\u00edklad, ktor\u00fd bol s uniqExact nad ip adresami, t. j. to, \u017ee uniqExact sa po\u010d\u00edta dlh\u0161ie po re\u0165azcoch ako po \u010d\u00edslach a tak \u010falej. A \u010do ak urob\u00edme finty a budeme konvertova\u0165 v okamihu \u010d\u00edtania? T. j. ste, akoby povedali, \u017ee na disku to moc ner\u00f4zni. Ak budeme \u010d\u00edta\u0165 z disku re\u0165azce a konvertova\u0165, bud\u00fa na\u0161e agreg\u00e1cie r\u00fdchlej\u0161ie alebo nie? Alebo tu predsa len nevyhr\u00e1me nepatrne? Mysl\u00edm, \u017ee ste to testovali, len to v benchmarku akosi nezazneli.<\/em> <\/p>\n

<\/p>\n

Mysl\u00edm si, \u017ee to bude pomal\u0161ie ako bez castovania. V takom pr\u00edpade je potrebn\u00e9 IP adresu z re\u0165azca rozparsova\u0165. U n\u00e1s, samozrejme, je v ClickHouse parsovanie IP adries tie\u017e optimalizovan\u00e9. Ve\u013ea sme sa sna\u017eili, ale \u010d\u00edsla s\u00fa zap\u00edsan\u00e9 vo forme desatinn\u00e9ho \u010d\u00edsla. To je ve\u013emi nepraktick\u00e9. Na druhej strane, funkcia uniqExact bude na re\u0165azcoch fungova\u0165 pomal\u0161ie nielen preto, \u017ee ide o re\u0165azce, ale aj preto, \u017ee sa vyber\u00e1 in\u00e1 \u0161pecializ\u00e1cia algoritmu. Retyazce sa jednoducho sprac\u00favaj\u00fa inak.<\/p>\n

<\/p>\n

A \u010do keby sme vzali primit\u00edvnej\u0161\u00ed typ \u00fadajov? Napr\u00edklad, sme zap\u00edsali user id, ktor\u00fd m\u00e1me in, zap\u00edsali sme to ako re\u0165azec a potom to spracovali, bude to z\u00e1bavnej\u0161ie alebo nie?<\/em><\/p>\n

<\/p>\n

Som skeptick\u00fd. Mysl\u00edm si, \u017ee to bude dokonca smutnej\u0161ie, preto\u017ee parsovanie \u010d\u00edsel je v\u00e1\u017eny probl\u00e9m. Zd\u00e1 sa mi, \u017ee tento kolega mal dokonca predn\u00e1\u0161ku na t\u00e9mu, ak\u00e9 \u0165a\u017ek\u00e9 je parsova\u0165 \u010d\u00edsla v desatinnom tvare, ale mo\u017eno nie. <\/p>\n

<\/p>\n

Alexej, ve\u013emi pekne \u010fakujem za predn\u00e1\u0161ku! A e\u0161te raz \u010fakujem za ClickHouse! M\u00e1m ot\u00e1zku oh\u013eadom pl\u00e1nov. Je v pl\u00e1ne funkcia pre aktualiz\u00e1ciu slovn\u00edkov nie \u00faplne?<\/em><\/p>\n

<\/p>\n

T. j. \u010diasto\u010dn\u00e9 obnovenie?<\/p>\n

<\/p>\n

\u00c1no-\u00e1no. Nie\u010do ako mo\u017enos\u0165 zada\u0165 pole MySQL, t. j. aktualizova\u0165 po, aby sa nahr\u00e1vali iba tieto \u00fadaje, ak je slovn\u00edk ve\u013emi ve\u013ek\u00fd.<\/em><\/p>\n

<\/p>\n

Ve\u013emi zauj\u00edmav\u00e1 funkcia. A mysl\u00edm, \u017ee niekto to navrhol v na\u0161om chate. Mo\u017eno to bol dokonca vy. <\/p>\n

<\/p>\n

Nemysl\u00edm si, \u017ee ja.<\/em><\/p>\n

<\/p>\n

Skvel\u00e9, teraz to vyzer\u00e1 na dva dotazy. A m\u00f4\u017eeme za\u010da\u0165 v k\u013eude pracova\u0165. Ale chcem v\u00e1s hne\u010f varova\u0165, \u017ee t\u00e1to funkcia je ve\u013emi jednoduch\u00e1 na implement\u00e1ciu. T. j. teoreticky sta\u010d\u00ed nap\u00edsa\u0165 do tabu\u013eky \u010d\u00edslo verzie a potom p\u00edsa\u0165: verzia je men\u0161ia ako t\u00e1to. A to znamen\u00e1, \u017ee to pravdepodobne pon\u00fakneme nad\u0161encom. Ste nad\u0161enec? <\/p>\n

<\/p>\n

\u00c1no, ale, \u017eia\u013e, nie v C++.<\/em><\/p>\n

<\/p>\n

Vedia va\u0161i kolegovia p\u00edsa\u0165 v C++? <\/p>\n

<\/p>\n

N\u00e1jdem niekoho.<\/em><\/p>\n

<\/p>\n

Skvel\u00e9*.<\/p>\n

<\/p>\n

* funkcia bola pridan\u00e1 dva mesiace po predn\u00e1\u0161ke \u2013 vyvinul ju autor ot\u00e1zky a poslal svoj pull request<\/a><\/noindex>.<\/p>\n

<\/p>\n

\u010eakujeme!<\/em><\/p>\n

<\/p>\n

Dobr\u00fd de\u0148! \u010eakujem za predn\u00e1\u0161ku! Spomenuli ste, \u017ee ClickHouse ve\u013emi dobre vyu\u017e\u00edva v\u0161etky dostupn\u00e9 zdroje. A predn\u00e1\u0161aj\u00faci zo spolo\u010dnosti Luxoft hovoril o svojom rie\u0161en\u00ed pre Po\u0161tu Ruska. Povedal, \u017ee sa im ClickHouse ve\u013emi p\u00e1\u010dil, ale nepou\u017eili ho namiesto svojho hlavn\u00e9ho konkurenta pr\u00e1ve preto, \u017ee zo\u017eral cel\u00fd procesor. A nemohli ho zapoji\u0165 do svojej architekt\u00fary, do svojho ZooKeepera s docker-mi. Existuje nejak\u00e1 mo\u017enos\u0165, ako obmedzi\u0165 ClickHouse, aby nespotrebov\u00e1val v\u0161etko, \u010do sa mu st\u00e1va dostupn\u00fdm?<\/em><\/p>\n

<\/p>\n

\u00c1no, d\u00e1 sa to a ve\u013emi jednoducho. Ak chcete, aby spotreboval menej jadier, sta\u010d\u00ed nap\u00edsa\u0165 set max_threads = 1<\/code>. A v\u0161etko, bude vykon\u00e1va\u0165 dotazy na jednom jadre. A navy\u0161e, r\u00f4znym pou\u017e\u00edvate\u013eom m\u00f4\u017eete nastavi\u0165 r\u00f4zne tieto nastavenia. Tak\u017ee \u017eiadne probl\u00e9my. A kolegom z Luxoftu povedzte, \u017ee nie je dobr\u00e9, \u017ee nena\u0161li toto nastavenie v dokument\u00e1cii. <\/p>\n

<\/p>\n

Alexey, dobr\u00fd de\u0148! Chcel by som sa op\u00fdta\u0165 na jednu vec. U\u017e nie prv\u00fdkr\u00e1t po\u010dujem, \u017ee mnoh\u00ed za\u010d\u00ednaj\u00fa pou\u017e\u00edva\u0165 ClickHouse ako \u00falo\u017eisko logov. Na predn\u00e1\u0161ke ste hovorili, aby sa to nedialo, t.j. nie je potrebn\u00e9 uchov\u00e1va\u0165 dlh\u00e9 re\u0165azce. Ako sa k tomu staviate?<\/em><\/p>\n

<\/p>\n

Po prv\u00e9, logy nie s\u00fa zvy\u010dajne dlh\u00e9 re\u0165azce. Samozrejme, s\u00fa aj v\u00fdnimky. Napr\u00edklad, ak\u00fdsi servis nap\u00edsan\u00fd v jave vyhod\u00ed v\u00fdnimku a t\u00e1 sa loguje. A tak st\u00e1le do nekone\u010dna, a miesto na pevnom disku sa zapln\u00ed. Rie\u0161enie je ve\u013emi jednoduch\u00e9. Ak s\u00fa re\u0165azce ve\u013emi dlh\u00e9, tak ich skracujte. A \u010do znamen\u00e1 dlh\u00e9? Desiatky kilobajtov \u2013 to je zl\u00e9*.<\/p>\n

<\/p>\n

* V nov\u00fdch verzi\u00e1ch ClickHouse je zahrnut\u00e1 \"adapt\u00edvna granularita indexu\", \u010do v\u00e4\u010d\u0161inou odstra\u0148uje probl\u00e9m s uchov\u00e1van\u00edm dlh\u00fdch re\u0165azcov.<\/p>\n

<\/p>\n

A kilobajt \u2013 to je norm\u00e1lne?<\/em><\/p>\n

<\/p>\n

Norm\u00e1lne. <\/p>\n

<\/p>\n

Dobr\u00fd de\u0148! \u010eakujem za predn\u00e1\u0161ku! U\u017e som sa na to p\u00fdtal v chate, ale nepam\u00e4t\u00e1m si, \u010di som dostal odpove\u010f. Pl\u00e1nuje sa nejako roz\u0161\u00edri\u0165 sekcia WITH na sp\u00f4sob CTE?<\/em><\/p>\n

<\/p>\n

Zatia\u013e nie. Sekcia WITH je u n\u00e1s trochu neform\u00e1lna. M\u00e1me ju ako mal\u00fa funkciu.<\/p>\n

<\/p>\n

Rozumiem. \u010eakujem!<\/em><\/p>\n

<\/p>\n

\u010eakujem za predn\u00e1\u0161ku! Ve\u013emi zauj\u00edmav\u00e9! Ve\u013ek\u00e1 ot\u00e1zka. Pl\u00e1nuje sa vytvorenie, mo\u017eno vo forme nejak\u00fdch z\u00e1lo\u017eiek, modifik\u00e1cia odstra\u0148ovania \u00fadajov?<\/em><\/p>\n

<\/p>\n

Ur\u010dite. Toto je na\u0161a prv\u00e1 \u00faloha v na\u0161om zozname. Akt\u00edvne prem\u00fd\u0161\u013eame, ako v\u0161etko robi\u0165 spr\u00e1vne. A mali by sme za\u010da\u0165 klika\u0165 na kl\u00e1vesnicu*.<\/p>\n

<\/p>\n

* stla\u010dili ste kl\u00e1vesy na kl\u00e1vesnici a v\u0161etko ste urobili.<\/p>\n

<\/p>\n

Ovplyvn\u00ed to nejak\u00fdm sp\u00f4sobom v\u00fdkon syst\u00e9mu alebo nie? Bude vkladanie rovnako r\u00fdchle ako doteraz?<\/em><\/p>\n

<\/p>\n

Mo\u017eno samotn\u00e9 mazania a aktualiz\u00e1cie bud\u00fa ve\u013emi n\u00e1ro\u010dn\u00e9, ale na v\u00fdkon vyh\u013ead\u00e1van\u00ed a vkladania to nebude ma\u0165 vplyv.<\/p>\n

<\/p>\n

A e\u0161te jedna mal\u00e1 ot\u00e1zka. Na prezent\u00e1cii ste hovorili o prim\u00e1rnom k\u013e\u00fa\u010di. Teda m\u00e1me part\u00edcie, ktor\u00e9 s\u00fa predvolene mesa\u010dn\u00e9, je to spr\u00e1vne? A ke\u010f zad\u00e1me rozsah d\u00e1t, ktor\u00fd sa zmest\u00ed do mesiaca, tak sa na\u010d\u00edta iba t\u00e1to part\u00edcia, je to tak?<\/em><\/p>\n

<\/p>\n

\u00c1no.<\/p>\n

<\/p>\n

M\u00e1m tak\u00fa ot\u00e1zku. Ak nem\u00f4\u017eeme ur\u010di\u0165 \u017eiadny prim\u00e1rny k\u013e\u00fa\u010d, je spr\u00e1vne urobi\u0165 ho na z\u00e1klade po\u013ea \u201eD\u00e1tum\u201c, aby v pozad\u00ed bolo menej prestavieb t\u00fdchto \u00fadajov, aby boli usporiadan\u00e9? Ak nem\u00e1te rozsahov\u00e9 dopyty a ani nem\u00f4\u017eete vybra\u0165 \u017eiadny prim\u00e1rny k\u013e\u00fa\u010d, m\u00e1 zmysel zahrn\u00fa\u0165 d\u00e1tum do prim\u00e1rneho k\u013e\u00fa\u010da?<\/em><\/p>\n

<\/p>\n

\u00c1no.<\/p>\n

<\/p>\n

Mo\u017eno by malo zmysel zahrn\u00fa\u0165 do prim\u00e1rneho k\u013e\u00fa\u010da tak\u00e9 pole, pod\u013ea ktor\u00e9ho bud\u00fa \u00fadaje lep\u0161ie komprimovan\u00e9, ak bud\u00fa zoraden\u00e9 pod\u013ea tohto po\u013ea. Napr\u00edklad identifik\u00e1tor u\u017e\u00edvate\u013ea. U\u017e\u00edvate\u013e, povedzme, nav\u0161tevuje t\u00fa ist\u00fa str\u00e1nku. V tomto pr\u00edpade zahr\u0148te id u\u017e\u00edvate\u013ea a \u010das. A potom sa \u00fadaje bud\u00fa lep\u0161ie komprimova\u0165. \u010co sa t\u00fdka d\u00e1tumu, ak naozaj nem\u00e1te a nikdy nem\u00e1te rozsahov\u00e9 dopyty t\u00fdkaj\u00face sa d\u00e1tumov, m\u00f4\u017eete d\u00e1tum nezahrn\u00fa\u0165 do prim\u00e1rneho k\u013e\u00fa\u010da. <\/p>\n

<\/p>\n

Dobre, ve\u013emi pekne \u010fakujem!<\/em><\/p>\n

Zdroj: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Efekt\u00edvne vyu\u017eitie ClickHouse. Alexej Milovidov (Yandex) | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u042d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 ClickHouse. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432 (\u042f\u043d\u0434\u0435\u043a\u0441) | ProHoster","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-13T17:42:36+00:00","article:modified_time":"2020-08-13T17:42:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91438","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:27:23","updated":"2022-09-28 17:25:41","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/91438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=91438"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/91438\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/91439"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=91438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=91438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=91438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}