{"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\/cs\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","title":{"rendered":"Efektivn\u00ed vyu\u017eit\u00ed ClickHouse. Alexej Milovidov (Yandex)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Jeliko\u017e je ClickHouse specializovan\u00fd syst\u00e9m, je p\u0159i jeho pou\u017e\u00edv\u00e1n\u00ed d\u016fle\u017eit\u00e9 zohlednit specifika jeho architektury. V t\u00e9to prezentaci Alexej p\u0159edstav\u00ed p\u0159\u00edklady typick\u00fdch chyb p\u0159i pou\u017e\u00edv\u00e1n\u00ed ClickHouse, kter\u00e9 mohou v\u00e9st k neefektivn\u00edmu v\u00fdkonu. Na p\u0159\u00edkladech z praxe bude uk\u00e1z\u00e1no, jak m\u016f\u017ee v\u00fdb\u011br ur\u010dit\u00e9ho zpracovatelsk\u00e9ho sch\u00e9matu zm\u011bnit v\u00fdkon o \u0159\u00e1dy.<\/p>\n

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

Ahoj v\u0161ichni! Jmenuji se Alexej a d\u011bl\u00e1m ClickHouse.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Za prv\u00e9, okam\u017eit\u011b v\u00e1s chci pot\u011b\u0161it, dnes v\u00e1m nebudu \u0159\u00edkat, co je ClickHouse. Up\u0159\u00edmn\u011b, u\u017e m\u011b to nebav\u00ed. Ka\u017ed\u00fd rok to \u0159\u00edk\u00e1m. A pravd\u011bpodobn\u011b u\u017e to v\u0161ichni v\u00ed. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

M\u00edsto toho budu hovo\u0159it o tom, jak\u00e9 jsou mo\u017en\u00e9 n\u00e1strahy, tedy jak lze ClickHouse pou\u017e\u00edvat nespr\u00e1vn\u011b. Ve skute\u010dnosti se nen\u00ed \u010deho b\u00e1t, proto\u017ee vyv\u00edj\u00edme ClickHouse jako syst\u00e9m, kter\u00fd je jednoduch\u00fd, pohodln\u00fd, a kter\u00fd funguje okam\u017eit\u011b. Instalujete a \u017e\u00e1dn\u00e9 probl\u00e9my. <\/p>\n

<\/p>\n

I tak je t\u0159eba br\u00e1t v \u00favahu, \u017ee tento syst\u00e9m je specializovan\u00fd a snadno m\u016f\u017eete narazit na neobvykl\u00fd sc\u00e9n\u00e1\u0159 pou\u017eit\u00ed, kter\u00fd tuto syst\u00e9m dostane z komfortn\u00ed z\u00f3ny.<\/p>\n

<\/p>\n

Tak\u017ee, jak\u00e9 jsou ty n\u00e1strahy? Hlavn\u011b budu hovo\u0159it o z\u0159ejm\u00fdch v\u011bcech. V\u0161ichni to vid\u00ed jako jasn\u00e9, v\u0161ichni ch\u00e1pou a mohou se radovat, \u017ee jsou tak chyt\u0159\u00ed, a ti, kte\u0159\u00ed nerozum\u00ed, se dozv\u011bd\u00ed n\u011bco nov\u00e9ho. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Prvn\u00ed a velmi jednoduch\u00fd p\u0159\u00edklad, kter\u00fd, bohu\u017eel, \u010dasto nast\u00e1v\u00e1, je velk\u00e9 mno\u017estv\u00ed insert\u016f s mal\u00fdmi batchi, tedy velk\u00e9 mno\u017estv\u00ed mal\u00fdch insert\u016f.<\/p>\n

<\/p>\n

Pokud zva\u017eujeme, jak ClickHouse prov\u00e1d\u00ed insert, m\u016f\u017eete poslat za jeden dotaz klidn\u011b i proud dat a\u017e na terabajt. To nen\u00ed probl\u00e9m. <\/p>\n

<\/p>\n

A pod\u00edvejme se, jak\u00fd bude typick\u00fd v\u00fdkon. Nap\u0159\u00edklad m\u00e1me tabulku s daty z Yandex.Metriky. Hity. 105 r\u016fzn\u00fdch sloupc\u016f. 700 bajt\u016f v neza\u0161ifrovan\u00e9 podob\u011b. A budeme vkl\u00e1dat hezky po jednom milionu \u0159\u00e1dk\u016f. <\/p>\n

<\/p>\n

Vkl\u00e1d\u00e1me do tabulky MergeTree, dost\u00e1v\u00e1me p\u016fl milionu \u0159\u00e1dk\u016f za sekundu. Skv\u011bl\u00e9. Do replikovan\u00e9 tabulky \u2013 bude to o n\u011bco m\u00e9n\u011b, p\u0159ibli\u017en\u011b 400 000 \u0159\u00e1dk\u016f za sekundu. <\/p>\n

<\/p>\n

A pokud zapneme kv\u00f3rumov\u00fd insert, dostaneme o n\u011bco m\u00e9n\u011b, ale po\u0159\u00e1d slu\u0161n\u00fd v\u00fdkon, 250 000 \u0159\u00e1dk\u016f za sekundu. Kv\u00f3rumov\u00fd insert \u2013 to je nedokumentovan\u00e1 mo\u017enost v ClickHouse*.<\/p>\n

<\/p>\n

* k datu 2020, u\u017e je zdokumentov\u00e1na<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Co se stane, kdy\u017e se to pokaz\u00ed? Vkl\u00e1d\u00e1me \u0159\u00e1dek po \u0159\u00e1dku do tabulky MergeTree a dost\u00e1v\u00e1me 59 \u0159\u00e1dk\u016f za sekundu. To je 10 000kr\u00e1t pomalej\u0161\u00ed. V ReplicatedMergeTree je to 6 \u0159\u00e1dk\u016f za sekundu. A pokud se zapne quorum, dost\u00e1v\u00e1me se na 2 \u0159\u00e1dky za sekundu. Podle m\u011b je to naprost\u00fd pr\u016f\u0161vih. Jak je v\u016fbec mo\u017en\u00e9 takto zpomalit? Dokonce m\u00e1m na tri\u010dku naps\u00e1no, \u017ee ClickHouse by nem\u011bl zpomalovat. Ale ob\u010das se to st\u00e1v\u00e1. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Ve skute\u010dnosti \u2013 to je na\u0161e selh\u00e1n\u00ed. Mohli jsme to za\u0159\u00eddit tak, aby v\u0161echno fungovalo norm\u00e1ln\u011b, ale neud\u011blali jsme to. A neud\u011blali jsme to proto, \u017ee pro n\u00e1\u0161 sc\u00e9n\u00e1\u0159 to nebylo nutn\u00e9. U\u017e jsme m\u011bli d\u00e1vky. Prost\u011b k n\u00e1m p\u0159ich\u00e1zely d\u00e1vky a \u017e\u00e1dn\u00e9 probl\u00e9my. Vkl\u00e1d\u00e1me a v\u0161e funguje norm\u00e1ln\u011b. Ale samoz\u0159ejm\u011b mohou nastat r\u016fzn\u00e9 sc\u00e9n\u00e1\u0159e. Nap\u0159\u00edklad kdy\u017e m\u00e1te spoustu server\u016f, na kter\u00fdch se generuj\u00ed data. A ta data se vkl\u00e1daj\u00ed ne tak \u010dasto, ale p\u0159esto doch\u00e1z\u00ed k \u010dast\u00fdm vkl\u00e1d\u00e1n\u00edm. A je pot\u0159eba tomu n\u011bjak zabr\u00e1nit. <\/p>\n

<\/p>\n

Z technick\u00e9ho hlediska je podstatou to, \u017ee kdy\u017e prov\u00e1d\u00edte insert v ClickHouse, data nedoch\u00e1zej\u00ed do \u017e\u00e1dn\u00e9ho memtable. Nem\u00e1me ani skute\u010dn\u00fd log structure MergeTree, ale jen MergeTree, proto\u017ee nem\u00e1me ani log, ani memTable. Data zapisujeme p\u0159\u00edmo do souborov\u00e9ho syst\u00e9mu, u\u017e rozlo\u017een\u00e1 do sloupc\u016f. A pokud m\u00e1te 100 sloupc\u016f, budete muset zapsat v\u00edce ne\u017e 200 soubor\u016f do samostatn\u00e9ho adres\u00e1\u0159e. To je dost objemn\u00e9. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A vznik\u00e1 ot\u00e1zka: \u201eJak to d\u011blat spr\u00e1vn\u011b?\u201c, pokud nastane situace, \u017ee je pot\u0159eba n\u011bjak\u00fdm zp\u016fsobem zapisovat data do ClickHouse.<\/p>\n

<\/p>\n

Metoda 1. To je nejjednodu\u0161\u0161\u00ed zp\u016fsob. Pou\u017e\u00edt n\u011bjakou distribuovanou frontu. Nap\u0159\u00edklad Kafka. Prost\u011b vyt\u00e1hnete data z Kafky, d\u00e1vkujete je jednou za sekundu. A v\u0161echno bude v po\u0159\u00e1dku, zapisujete, v\u0161echno funguje. <\/p>\n

<\/p>\n

Nev\u00fdhodou je, \u017ee Kafka je dal\u0161\u00ed objemn\u00fd distribuovan\u00fd syst\u00e9m. Je\u0161t\u011b ch\u00e1pu, pokud u\u017e m\u00e1te Kafku ve firm\u011b. To je dobr\u00e9, to je pohodln\u00e9. Ale pokud ji nem\u00e1te, je dobr\u00e9 t\u0159ikr\u00e1t p\u0159em\u00fd\u0161let, ne\u017e ji p\u0159inesete do sv\u00e9ho projektu. A proto stoj\u00ed za to zv\u00e1\u017eit alternativy. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Zp\u016fsob 2. Tohle je takov\u00e1 oldschoolov\u00e1 alternativa, kter\u00e1 je velmi jednoduch\u00e1. M\u00e1te server, kter\u00fd generuje va\u0161e logy. Ten pak zapisuje va\u0161e logy do souboru. A jednou za sekundu, nap\u0159\u00edklad, tento soubor p\u0159ejmenujete a otev\u0159ete nov\u00fd. A samostatn\u00fd skript, bu\u010f podle cronu, nebo n\u011bjak\u00fd d\u00e9mon, vezme nejstar\u0161\u00ed soubor a zap\u00ed\u0161e ho do ClickHouse. Pokud zapisujete logy jednou za sekundu, v\u0161e bude skv\u011bl\u00e9. <\/p>\n

<\/p>\n

Ale nev\u00fdhodou tohoto zp\u016fsobu je, \u017ee pokud v\u00e1\u0161 server, na kter\u00e9m se logy generuj\u00ed, n\u011bkam zmiz\u00ed, tak\u00e9 zmiz\u00ed data.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Zp\u016fsob 3. Existuje je\u0161t\u011b jeden zaj\u00edmav\u00fd zp\u016fsob, kter\u00fd v\u016fbec nevy\u017eaduje do\u010dasn\u00e9 soubory. Nap\u0159\u00edklad m\u00e1te n\u011bjakou reklamn\u00ed smy\u010dku nebo jin\u00e9ho zaj\u00edmav\u00e9ho d\u00e9mona, kter\u00fd generuje data. M\u016f\u017eete hromadit mno\u017estv\u00ed dat p\u0159\u00edmo v pam\u011bti, v bufferu. A kdy\u017e uplyne dostatek \u010dasu, tento buffer odlo\u017e\u00edte na stranu, vytvo\u0159\u00edte nov\u00fd a v samostatn\u00e9m vl\u00e1kn\u011b, co se ji\u017e nashrom\u00e1\u017edilo, vlo\u017e\u00edte do ClickHouse.<\/p>\n

<\/p>\n

Na druh\u00e9 stran\u011b data tak\u00e9 zmiz\u00ed p\u0159i kill -9. Pokud v\u00e1\u0161 server spadne, tato data ztrat\u00edte. A tak\u00e9 je probl\u00e9m, \u017ee pokud se v\u00e1m nepoda\u0159\u00ed zapsat do datab\u00e1ze, data se v\u00e1m budou hromadit v pam\u011bti. A bu\u010f dojde pam\u011b\u0165, nebo jednodu\u0161e ztrat\u00edte data. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Zp\u016fsob 4. Dal\u0161\u00ed zaj\u00edmav\u00fd zp\u016fsob. M\u00e1te n\u011bjak\u00fd serverov\u00fd proces. A ten m\u016f\u017ee pos\u00edlat data do ClickHouse okam\u017eit\u011b, ale d\u011blat to v jednom spojen\u00ed. Nap\u0159\u00edklad poslal http-\u017e\u00e1dost s transfer-encoding: chunked s insertem. A generuje chunk-y ji\u017e ne p\u0159\u00edli\u0161 z\u0159\u00eddka, m\u016f\u017eete pos\u00edlat ka\u017ed\u00fd \u0159\u00e1dek, i kdy\u017e bude m\u00edt overhead na r\u00e1mcov\u00e1n\u00ed t\u011bchto dat. <\/p>\n

<\/p>\n

Ale p\u0159esto v tomto p\u0159\u00edpad\u011b budou data odesl\u00e1na do ClickHouse okam\u017eit\u011b. A ClickHouse si je s\u00e1m bude bufferovat. <\/p>\n

<\/p>\n

Ale tak\u00e9 vznikaj\u00ed probl\u00e9my. Nyn\u00ed ztrat\u00edte data, a to i v p\u0159\u00edpad\u011b, \u017ee v\u00e1\u0161 proces se zabije, a pokud se proces ClickHouse zabije, proto\u017ee to bude nedokon\u010den\u00fd insert. A v ClickHouse jsou inserts atomick\u00e9 do ur\u010dit\u00e9ho stanoven\u00e9ho prahu v po\u010dtu \u0159\u00e1dk\u016f. V z\u00e1sad\u011b je to zaj\u00edmav\u00fd zp\u016fsob. M\u016f\u017ee se tak\u00e9 pou\u017e\u00edvat.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Zp\u016fsob 5. Tady je dal\u0161\u00ed zaj\u00edmav\u00fd zp\u016fsob. Je to jak\u00fdsi komunitou vyvinut\u00fd server pro d\u00e1vkov\u00e1n\u00ed dat. S\u00e1m jsem se na to ned\u00edval, tak\u017ee nemohu nic zaru\u010dit. Nicm\u00e9n\u011b ani pro samotn\u00fd ClickHouse nejsou poskytov\u00e1ny \u017e\u00e1dn\u00e9 z\u00e1ruky. Je to tak\u00e9 open source, ale na druhou stranu jste si mohli zvyknout na ur\u010dit\u00fd standard kvality, kter\u00fd se sna\u017e\u00edme zajistit. O t\u00e9to funkci v\u0161ak nev\u00edm, zkuste se pod\u00edvat na GitHub, pod\u00edvejte se na k\u00f3d. Mo\u017en\u00e1 tam napsali n\u011bco rozumn\u00e9ho. <\/p>\n

<\/p>\n

* k datu 2020 je tak\u00e9 t\u0159eba vz\u00edt v \u00favahu KittenHouse<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Zp\u016fsob 6. Dal\u0161\u00edm zp\u016fsobem je pou\u017eit\u00ed Buffer tabulek. V\u00fdhodou tohoto zp\u016fsobu je, \u017ee je velmi jednoduch\u00e9 za\u010d\u00edt je pou\u017e\u00edvat. Vytvo\u0159\u00edte Buffer tabulku a vlo\u017e\u00edte do n\u00ed data. <\/p>\n

<\/p>\n

Nev\u00fdhodou je, \u017ee probl\u00e9m nen\u00ed vy\u0159e\u0161en \u00fapln\u011b. Pokud p\u0159i vkl\u00e1d\u00e1n\u00ed typu MergeTree mus\u00edte seskupovat data po jednom d\u00e1vce za sekundu, pak p\u0159i vkl\u00e1d\u00e1n\u00ed do buffer tabulky pot\u0159ebujete seskupit alespo\u0148 do n\u011bkolika tis\u00edc\u016f za sekundu. Pokud to bude v\u00edce ne\u017e 10 000 za sekundu, nebude to i tak dobr\u00e9. A pokud vkl\u00e1d\u00e1te d\u00e1vkami, pak jste vid\u011bli, \u017ee tam to m\u016f\u017ee b\u00fdt sto tis\u00edc \u0159\u00e1dk\u016f za sekundu. A to u\u017e na dost t\u011b\u017ek\u00fdch datech. <\/p>\n

<\/p>\n

A tak\u00e9 buffer tabulky nemaj\u00ed log. A pokud se s va\u0161\u00edm serverem n\u011bco pokaz\u00ed, data mohou b\u00fdt ztracena. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A jako bonus n\u00e1m ned\u00e1vno v ClickHouse p\u0159ibyla mo\u017enost \u010derpat data z Kafka. Existuje stroj tabulek \u2013 Kafka. Sta\u010d\u00ed, kdy\u017e vytvo\u0159\u00edte. A na to m\u016f\u017eete p\u0159ipevnit materializovan\u00e9 pohledy. V tomto p\u0159\u00edpad\u011b si s\u00e1m vyjme data z Kafka a vlo\u017e\u00ed je do po\u017eadovan\u00fdch tabulek. <\/p>\n

<\/p>\n

A obzvl\u00e1\u0161\u0165 pot\u011b\u0161uj\u00edc\u00ed na t\u00e9to mo\u017enosti je, \u017ee ji ned\u011blali my. Je to funkce komunity. A kdy\u017e \u0159\u00edk\u00e1m \"funkce komunity\", nem\u00e1m na mysli jak\u00e9koli pohrd\u00e1n\u00ed. K\u00f3d jsme p\u0159e\u010detli, provedli jsme kontrolu, m\u011blo by to fungovat norm\u00e1ln\u011b. <\/p>\n

<\/p>\n

* k datu 2020 byla k dispozici obdobn\u00e1 podpora pro RabbitMQ<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Co m\u016f\u017ee b\u00fdt je\u0161t\u011b nepohodln\u00e9 nebo p\u0159ekvapiv\u00e9 p\u0159i vkl\u00e1d\u00e1n\u00ed dat? Pokud prov\u00e1d\u00edte dotaz insert values a v values uv\u00e1d\u00edte n\u011bjak\u00e9 vypo\u010d\u00edtan\u00e9 v\u00fdrazy. Nap\u0159\u00edklad now() \u2013 to je tak\u00e9 vypo\u010d\u00edtan\u00fd v\u00fdraz. A v tomto p\u0159\u00edpad\u011b ClickHouse mus\u00ed na ka\u017ed\u00e9m \u0159\u00e1dku spustit interpret\u00e1tor t\u011bchto v\u00fdraz\u016f a v\u00fdkon se v\u00fdrazn\u011b sn\u00ed\u017e\u00ed. Je lep\u0161\u00ed se tomu vyhnout.<\/p>\n

<\/p>\n

* v sou\u010dasn\u00e9 dob\u011b je probl\u00e9m pln\u011b vy\u0159e\u0161en, regresn\u00ed probl\u00e9my s v\u00fdkonem p\u0159i pou\u017eit\u00ed v\u00fdraz\u016f v VALUES ji\u017e neexistuj\u00ed.<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad, kdy mohou nastat ur\u010dit\u00e9 probl\u00e9my, je, kdy\u017e m\u00e1te na jednom batchi data vztahuj\u00edc\u00ed se k mnoha partition. Ve v\u00fdchoz\u00edm nastaven\u00ed m\u00e1 ClickHouse partition podle m\u011bs\u00edc\u016f. A pokud vkl\u00e1d\u00e1te batch o milionu \u0159\u00e1dc\u00edch, kter\u00e9 pokr\u00fdvaj\u00ed n\u011bkolik let, bude tam n\u011bkolik des\u00edtek partition. A to se rovn\u00e1 tomu, \u017ee budou batchi o n\u011bkolik des\u00edtek men\u0161\u00ed velikosti, proto\u017ee se v\u017edy nejprve d\u011bl\u00ed podle partition.<\/p>\n

<\/p>\n

* ned\u00e1vno byla v ClickHouse v experiment\u00e1ln\u00edm re\u017eimu p\u0159id\u00e1na podpora kompaktn\u00edho form\u00e1tu blok\u016f a blok\u016f v pam\u011bti s write-ahead log, co\u017e t\u00e9m\u011b\u0159 \u00fapln\u011b vy\u0159e\u0161ilo probl\u00e9m.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Nyn\u00ed se pod\u00edvejme na druh\u00fd typ probl\u00e9mu \u2013 typizace dat. <\/p>\n

<\/p>\n

Typizace dat m\u016f\u017ee b\u00fdt p\u0159\u00edsn\u00e1 a tak\u00e9 m\u016f\u017ee b\u00fdt \u0159et\u011bzcov\u00e1. \u0158et\u011bzcov\u00e1 znamen\u00e1, \u017ee jste prost\u011b vzali a deklarovali, \u017ee v\u0161echny va\u0161e pole jsou typu string. To je \u0161patn\u011b. Takto to d\u011blat nen\u00ed dobr\u00e9. <\/p>\n

<\/p>\n

Poj\u010fme si uk\u00e1zat, jak to spr\u00e1vn\u011b ud\u011blat v p\u0159\u00edpadech, kdy chcete \u0159\u00edct, \u017ee n\u011bjak\u00e9 pole m\u00e1me jako \u0159et\u011bzec, a nech\u0165 ClickHouse se s t\u00edm u\u017e s\u00e1m vypo\u0159\u00e1d\u00e1, ale p\u0159esto je t\u0159eba vynalo\u017eit ur\u010dit\u00e9 \u00fasil\u00ed. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Nap\u0159\u00edklad m\u00e1me IP adresu. V jednom p\u0159\u00edpad\u011b jsme ji ulo\u017eili jako \u0159et\u011bzec. Nap\u0159\u00edklad 192.168.1.1. A v jin\u00e9m p\u0159\u00edpad\u011b to bude \u010d\u00edslo typu UInt32*. 32 bit\u016f sta\u010d\u00ed pro IPv4 adresu.<\/p>\n

<\/p>\n

Za prv\u00e9, jak se to divn\u011b nezd\u00e1, data se budou komprimovat p\u0159ibli\u017en\u011b stejn\u00fdm zp\u016fsobem. Samoz\u0159ejm\u011b budou rozd\u00edly, ale ne tak velk\u00e9. Tak\u017ee z hlediska diskov\u00e9ho vstupu a v\u00fdstupu nejsou \u017e\u00e1dn\u00e9 z\u00e1sadn\u00ed probl\u00e9my. <\/p>\n

<\/p>\n

Ale je tu zna\u010dn\u00fd rozd\u00edl v procesorov\u00e9m \u010dase a v \u010dase vykon\u00e1v\u00e1n\u00ed dotazu. <\/p>\n

<\/p>\n

Spo\u010d\u00edtejme po\u010det unik\u00e1tn\u00edch IP adres, pokud jsou uchov\u00e1v\u00e1ny jako \u010d\u00edsla. To vych\u00e1z\u00ed na 137 milion\u016f \u0159\u00e1dk\u016f za sekundu. Pokud tedy tot\u00e9\u017e uchov\u00e1v\u00e1me jako \u0159et\u011bzce, pak je to 37 milion\u016f \u0159\u00e1dk\u016f za sekundu. Nev\u00edm, jak k tomu do\u0161lo. Tyto dotazy jsem spou\u0161t\u011bl s\u00e1m. Ale je to p\u0159ibli\u017en\u011b \u010dty\u0159ikr\u00e1t pomalej\u0161\u00ed. <\/p>\n

<\/p>\n

A pokud spo\u010d\u00edt\u00e1me rozd\u00edl v m\u00edst\u011b na disku, tak rozd\u00edl tak\u00e9 existuje. A je n\u011bkde okolo jedn\u00e9 \u010dtvrtiny, proto\u017ee unik\u00e1tn\u00edch IP adres je docela hodn\u011b. A pokud by zde byly \u0159et\u011bzce s mal\u00fdm po\u010dtem r\u016fzn\u00fdch hodnot, pak by se pohodln\u011b komprimovaly do p\u0159ibli\u017en\u011b stejn\u00e9ho objemu pomoc\u00ed slovn\u00edku. <\/p>\n

<\/p>\n

A \u010dty\u0159n\u00e1sobn\u00fd rozd\u00edl v \u010dase na silnici se nevypl\u00e1c\u00ed. Mo\u017en\u00e1 je v\u00e1m to jedno, ale kdy\u017e vid\u00edm takov\u00fd rozd\u00edl, je mi smutno.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Pod\u00edvejme se na r\u016fzn\u00e9 p\u0159\u00edpady. <\/p>\n

<\/p>\n

1. Jeden p\u0159\u00edpad, kdy m\u00e1te m\u00e1lo r\u016fzn\u00fdch unik\u00e1tn\u00edch hodnot. V tomto p\u0159\u00edpad\u011b pou\u017eijeme jednoduchou praktiku, kterou pravd\u011bpodobn\u011b zn\u00e1te a m\u016f\u017eete ji pou\u017e\u00edt pro jakoukoli DB. D\u00e1v\u00e1 to smysl nejen pro ClickHouse. Jednodu\u0161e zapisujete do datab\u00e1ze \u010d\u00edseln\u00e9 identifik\u00e1tory. A p\u0159ev\u00e1d\u011bt na \u0159et\u011bzce a zp\u011bt lze u\u017e na stran\u011b va\u0161\u00ed aplikace. <\/p>\n

<\/p>\n

Nap\u0159\u00edklad m\u00e1te region. A sna\u017e\u00edte se ho ulo\u017eit jako \u0159et\u011bzec. A bylo by tam naps\u00e1no: Moskva a MO. A kdy\u017e vid\u00edm, \u017ee tam p\u00ed\u0161e \u201eMoskva\u201c, tak to je\u0161t\u011b nic, ale kdy\u017e je tam i MO, tak je mi to \u00fapln\u011b smutno. To je p\u0159ece kolik byt\u016f. <\/p>\n

<\/p>\n

M\u00edsto toho jednodu\u0161e zapisujeme \u010d\u00edslo Ulnt32 a 250. M\u00e1me 250 v Yandexu, ale u v\u00e1s to m\u016f\u017ee b\u00fdt jinak. Pro jistotu \u0159\u00edk\u00e1m, \u017ee v ClickHouse existuje zabudovan\u00e1 mo\u017enost pr\u00e1ce s geodatab\u00e1z\u00ed. Jednodu\u0161e zapisujete katalog s regiony, v\u010detn\u011b hierarchick\u00e9ho, t. j. tam bude Moskva, MO a v\u0161echno, co pot\u0159ebujete. A m\u016f\u017eete p\u0159ev\u00e1d\u011bt na \u00farovni dotazu. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Druh\u00e1 varianta je p\u0159ibli\u017en\u011b stejn\u00e1, ale u\u017e s podporou uvnit\u0159 ClickHouse. To je typ dat Enum. Jednodu\u0161e uvnit\u0159 Enum zap\u00ed\u0161ete v\u0161echny pot\u0159ebn\u00e9 hodnoty. Nap\u0159\u00edklad typ za\u0159\u00edzen\u00ed a tam nap\u00ed\u0161ete: desktop, mobiln\u00ed, tablet, televizor. Celkem 4 varianty. <\/p>\n

<\/p>\n

Nev\u00fdhodou je, \u017ee je nutn\u00e9 pravideln\u011b alterovat. P\u0159idali jsme pouze jednu variantu. D\u011bl\u00e1me alter table. Ve skute\u010dnosti je alter table v ClickHouse zadarmo. Zvl\u00e1\u0161\u0165 je zdarma pro Enum, proto\u017ee data na disku se nem\u011bn\u00ed. Ale p\u0159esto alter zab\u00edr\u00e1 z\u00e1mek* na tabulku a mus\u00ed \u010dekat, a\u017e se vykonaj\u00ed v\u0161echny selects. A teprve pot\u00e9 se alter provede, tedy n\u011bjak\u00e9 nep\u0159\u00edjemnosti p\u0159ece jen existuj\u00ed.<\/p>\n

<\/p>\n

* V nov\u011bj\u0161\u00edch verz\u00edch ClickHouse je ALTER prov\u00e1d\u011bn zcela neblokuj\u00edc\u00edm zp\u016fsobem.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Je\u0161t\u011b jedna varianta, kter\u00e1 je dost unik\u00e1tn\u00ed pro ClickHouse \u2013 je p\u0159ipojen\u00ed extern\u00edch slovn\u00edk\u016f. M\u016f\u017eete zapisovat do ClickHouse \u010d\u00edsla a va\u0161e katalogy uchov\u00e1vat v jak\u00e9mkoli syst\u00e9mu, kter\u00fd v\u00e1m vyhovuje. Nap\u0159\u00edklad m\u016f\u017eete pou\u017e\u00edt: MySQL, Mongo, Postgres. Dokonce si m\u016f\u017eete vytvo\u0159it vlastn\u00ed mikroslu\u017ebu, kter\u00e1 tyto \u00fadaje poskytne po http. A na \u00farovni ClickHouse p\u00ed\u0161ete funkci, kter\u00e1 tyto \u00fadaje p\u0159ev\u00e1d\u00ed z \u010d\u00edsel na \u0159et\u011bzce. <\/p>\n

<\/p>\n

To je specializovan\u00fd, ale velmi efektivn\u00ed zp\u016fsob, jak prov\u00e9st join s extern\u00ed tabulkou. Existuj\u00ed p\u0159itom dv\u011b varianty. V jedn\u00e9 variant\u011b budou tato data pln\u011b ke\u0161ov\u00e1na, budou se nach\u00e1zet v RAM a ob\u010das se aktualizuj\u00ed. V druh\u00e9 variant\u011b, pokud se tato data nevejdou do RAM, lze je \u010d\u00e1ste\u010dn\u011b ke\u0161ovat. <\/p>\n

<\/p>\n

Tady je p\u0159\u00edklad. Existuje Yandex.Direct. A tam je reklamn\u00ed kampa\u0148 a bannery. Reklamn\u00edch kampan\u00ed je pravd\u011bpodobn\u011b kolem deseti milion\u016f. A zhruba se vejdou do RAM. Ale banner\u016f je miliardy a nevejdou se. Pou\u017e\u00edv\u00e1me ke\u0161ovac\u00ed slovn\u00edk z MySQL.<\/p>\n

<\/p>\n

Jedin\u00fd probl\u00e9m je, \u017ee ke\u0161ovac\u00ed slovn\u00edk bude fungovat spr\u00e1vn\u011b, pokud hit rate bude bl\u00edzko 100 %. Pokud bude ni\u017e\u0161\u00ed, p\u0159i zpracov\u00e1v\u00e1n\u00ed dotaz\u016f na ka\u017edou d\u00e1vku dat bude t\u0159eba skute\u010dn\u011b vz\u00edt chyb\u011bj\u00edc\u00ed kl\u00ed\u010de a z\u00edskat data z MySQL. O ClickHouse mohu je\u0161t\u011b \u0159\u00edct, \u017ee \u2013 ano, nezpomaluje, o jin\u00fdch syst\u00e9mech mluvit nebudu.<\/p>\n

<\/p>\n

A jako bonus to, \u017ee slovn\u00edky jsou velmi jednoduch\u00fd zp\u016fsob, jak aktualizovat data v ClickHouse zp\u011btn\u011b. T. j. pokud jste m\u011bli zpr\u00e1vu o reklamn\u00edch kampan\u00edch, u\u017eivatel jednodu\u0161e zm\u011bnil reklamn\u00ed kampa\u0148 a ve v\u0161ech star\u00fdch datech, ve v\u0161ech zpr\u00e1v\u00e1ch se tato data tak\u00e9 zm\u011bnila. Kdybyste psali \u0159\u00e1dky p\u0159\u00edmo do tabulky, bylo by nemo\u017en\u00e9 je aktualizovat. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Je\u0161t\u011b jeden zp\u016fsob, kdy\u017e nev\u00edte, odkud vz\u00edt identifik\u00e1tory pro va\u0161e \u0159\u00e1dky. M\u016f\u017eete je prost\u011b zahashovat. A nejjednodu\u0161\u0161\u00ed varianta je vz\u00edt 64bitov\u00fd hash. <\/p>\n

<\/p>\n

Jedin\u00fd probl\u00e9m je, \u017ee pokud je hash 64bitov\u00fd, kolize se v\u00e1m t\u00e9m\u011b\u0159 jist\u011b nevyhnou. Proto\u017ee pokud tam je miliarda \u0159\u00e1dk\u016f, pravd\u011bpodobnost se st\u00e1v\u00e1 znatelnou. <\/p>\n

<\/p>\n

A nebylo by p\u0159\u00edli\u0161 dobr\u00e9 takto hashovat n\u00e1zvy reklamn\u00edch kampan\u00ed. Pokud by se reklamn\u00ed kampan\u011b r\u016fzn\u00fdch spole\u010dnost\u00ed zam\u00edchaly, vzniklo by n\u011bco nejasn\u00e9ho. <\/p>\n

<\/p>\n

A existuje jednoduch\u00fd trik. Pravda, pro v\u00e1\u017en\u00e1 data se tak\u00e9 p\u0159\u00edli\u0161 nehod\u00ed, ale pokud jde o n\u011bco m\u00e9n\u011b z\u00e1va\u017en\u00e9ho, sta\u010d\u00ed p\u0159idat do kl\u00ed\u010de slovn\u00edku je\u0161t\u011b identifik\u00e1tor klienta. A pak kolize budete m\u00edt, ale pouze v r\u00e1mci jednoho klienta. Tento zp\u016fsob se u n\u00e1s pou\u017e\u00edv\u00e1 pro mapu odkaz\u016f v Yandex.Metrice. M\u00e1me tam URL, uchov\u00e1v\u00e1me hash. A v\u00edme, \u017ee kolize, samoz\u0159ejm\u011b, existuj\u00ed. Ale kdy\u017e se str\u00e1nka zobrazuje, pravd\u011bpodobnost, \u017ee na jedn\u00e9 str\u00e1nce bude m\u00edt jeden u\u017eivatel n\u011bjak\u00e9 URL, kter\u00e9 se sm\u00edchaj\u00ed a je\u0161t\u011b si toho n\u011bkdo v\u0161imne, je zanedbateln\u00e1. <\/p>\n

<\/p>\n

Jako bonus - pro mnoho operac\u00ed sta\u010d\u00ed pouze hashe a samotn\u00e9 \u0159et\u011bzce nemus\u00edte nikde uchov\u00e1vat. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edklad, pokud jsou \u0159et\u011bzce kr\u00e1tk\u00e9, nap\u0159\u00edklad dom\u00e9ny webov\u00fdch str\u00e1nek. M\u016f\u017eete je uchov\u00e1vat tak, jak jsou. Nebo nap\u0159\u00edklad jazyk prohl\u00ed\u017ee\u010de ru - 2 bajty. Omlouv\u00e1m se za ty bajty, ale nebojte se, 2 bajty nestoj\u00ed za \u0159e\u010d. Pros\u00edm, uchov\u00e1vejte je tak, jak jsou, nezapom\u00ednejte na to. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Dal\u0161\u00ed p\u0159\u00edpad je, kdy\u017e existuje naopak mnoho \u0159et\u011bzc\u016f a v nich je spousta unik\u00e1tn\u00edch a mno\u017estv\u00ed je potenci\u00e1ln\u011b neomezen\u00e9. Typick\u00fd p\u0159\u00edklad - to jsou vyhled\u00e1vac\u00ed fr\u00e1ze nebo URL. Vyhled\u00e1vac\u00ed fr\u00e1ze, mezi ostatn\u00edmi kv\u016fli p\u0159eklep\u016fm. Pod\u00edv\u00e1me se, kolik unik\u00e1tn\u00edch vyhled\u00e1vac\u00edch fr\u00e1z\u00ed za den. A ukazuje se, \u017ee t\u00e9m\u011b\u0159 polovina z v\u0161ech ud\u00e1lost\u00ed. V takov\u00e9m p\u0159\u00edpad\u011b byste si mohli myslet, \u017ee je t\u0159eba data normalizovat, po\u010d\u00edtat identifik\u00e1tory, ukl\u00e1dat do samostatn\u00e9 tabulky. Ale to d\u011blat nemus\u00edte. Prost\u011b uchovejte tyto \u0159et\u011bzce tak, jak jsou. <\/p>\n

<\/p>\n

Lep\u0161\u00ed je - nic nevym\u00fd\u0161let, proto\u017ee pokud byste je uchov\u00e1vali zvl\u00e1\u0161\u0165, budete muset prov\u00e1d\u011bt join. A ten join - to je v nejlep\u0161\u00edm p\u0159\u00edpad\u011b n\u00e1hodn\u00fd p\u0159\u00edstup na pam\u011b\u0165, pokud se je\u0161t\u011b vejde do pam\u011bti. Pokud se nevejde, budou s t\u00edm v\u016fbec probl\u00e9my. <\/p>\n

<\/p>\n

A pokud jsou data uchov\u00e1v\u00e1na in-place, pak se prost\u011b vyb\u00edraj\u00ed v pot\u0159ebn\u00e9m po\u0159ad\u00ed ze souborov\u00e9ho syst\u00e9mu a v\u0161e je v po\u0159\u00e1dku.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Pokud m\u00e1te URL nebo n\u011bjak\u00fd jin\u00fd komplikovan\u00fd dlouh\u00fd \u0159et\u011bzec, stoj\u00ed za to p\u0159em\u00fd\u0161let o tom, \u017ee byste mohli n\u011bjakou sumarizaci spo\u010d\u00edtat p\u0159edem a zapsat ji do samostatn\u00e9ho sloupce. <\/p>\n

<\/p>\n

Pro URL, nap\u0159\u00edklad, m\u016f\u017eete odd\u011blen\u011b uchov\u00e1vat dom\u00e9nu. A pokud skute\u010dn\u011b pot\u0159ebujete dom\u00e9nu, jednodu\u0161e pou\u017eijte tenhle sloupec, zat\u00edmco URL budou le\u017eet, a ani se jich nedotknete. <\/p>\n

<\/p>\n

Poj\u010fme se pod\u00edvat, jak\u00fd je rozd\u00edl. V ClickHouse existuje specializovan\u00e1 funkce, kter\u00e1 vypo\u010d\u00edt\u00e1v\u00e1 dom\u00e9nu. Je velmi rychl\u00e1, optimalizovali jsme ji. A up\u0159\u00edmn\u011b, neodpov\u00edd\u00e1 RFC, p\u0159esto po\u010d\u00edt\u00e1 v\u0161echno, co pot\u0159ebujeme. <\/p>\n

<\/p>\n

V jednom p\u0159\u00edpad\u011b budeme pouze z\u00edsk\u00e1vat URL a vypo\u010d\u00edt\u00e1vat dom\u00e9nu. To trv\u00e1 166 ms. Pokud vezmeme hotovou dom\u00e9nu, trv\u00e1 to pouze 67 ms, tedy t\u00e9m\u011b\u0159 t\u0159ikr\u00e1t rychleji. A rychlej\u0161\u00ed to nen\u00ed proto, \u017ee bychom museli prov\u00e1d\u011bt n\u011bjak\u00e9 v\u00fdpo\u010dty, ale proto, \u017ee \u010dteme m\u00e9n\u011b dat. <\/p>\n

<\/p>\n

Z n\u011bjak\u00e9ho d\u016fvodu m\u00e1 jeden dotaz, kter\u00fd je pomalej\u0161\u00ed, v\u011bt\u0161\u00ed rychlost gigabajt\u016f za sekundu. Proto\u017ee \u010dte v\u00edce gigabajt\u016f. To jsou zcela zbyte\u010dn\u00e9 \u00fadaje. Dotaz se zd\u00e1 rychlej\u0161\u00ed, ale trv\u00e1 d\u00e9le na proveden\u00ed.<\/p>\n

<\/p>\n

Kdy\u017e se pod\u00edv\u00e1me na objem dat na disku, zjist\u00edme, \u017ee URL zab\u00edr\u00e1 126 MB, zat\u00edmco dom\u00e9na jen 5 MB. Je to 25kr\u00e1t m\u00e9n\u011b. P\u0159esto dotaz trv\u00e1 pouze 4kr\u00e1t rychleji. To je v\u0161ak proto, \u017ee data jsou '\u010derstv\u00e1'. Kdyby byla 'studen\u00e1', bylo by to pravd\u011bpodobn\u011b 25kr\u00e1t rychlej\u0161\u00ed kv\u016fli diskov\u00e9mu I\/O. <\/p>\n

<\/p>\n

Mimochodem, pokud posoud\u00edme, jak moc je dom\u00e9na men\u0161\u00ed ne\u017e URL, vych\u00e1z\u00ed to asi 4x. P\u0159esto na disku data zab\u00edraj\u00ed 25kr\u00e1t m\u00e9n\u011b. Pro\u010d? Kv\u016fli kompresi. Jak URL, tak dom\u00e9na se komprimuj\u00ed. Ale \u010dasto URL obsahuje spoustu zbyte\u010dn\u00fdch dat. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A samoz\u0159ejm\u011b je d\u016fle\u017eit\u00e9 pou\u017e\u00edvat spr\u00e1vn\u00e9 datov\u00e9 typy, kter\u00e9 jsou ur\u010deny speci\u00e1ln\u011b pro dan\u00e9 hodnoty nebo kter\u00e9 vyhovuj\u00ed. Pokud pou\u017e\u00edv\u00e1te IPv4, uchov\u00e1vejte UInt32*. Pokud IPv6, pak FixedString(16), proto\u017ee IPv6 adresa m\u00e1 128 bit\u016f, tedy uchov\u00e1vejte ji p\u0159\u00edmo v bin\u00e1rn\u00edm form\u00e1tu. <\/p>\n

<\/p>\n

A co d\u011blat, pokud ob\u010das m\u00e1te IPv4 adresy a ob\u010das IPv6? Ano, m\u016f\u017eete uchov\u00e1vat oboje. Jeden sloupec pro IPv4, druh\u00fd pro IPv6. Samoz\u0159ejm\u011b existuje mo\u017enost p\u0159ev\u00e9st IPv4 na IPv6. To tak\u00e9 bude fungovat, ale pokud \u010dasto pot\u0159ebujete pr\u00e1v\u011b IPv4 adresu v dotazech, bylo by dobr\u00e9 ji um\u00edstit do samostatn\u00e9ho sloupce. <\/p>\n

<\/p>\n

* nyn\u00ed m\u00e1 ClickHouse samostatn\u00e9 datov\u00e9 typy IPv4 a IPv6, kter\u00e9 ukl\u00e1daj\u00ed data stejn\u011b efektivn\u011b jako \u010d\u00edsla, ale prezentuj\u00ed je stejn\u011b pohodln\u011b jako \u0159et\u011bzce.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Je d\u016fle\u017eit\u00e9 poznamenat, \u017ee je dobr\u00e9 data p\u0159edem zpracovat. Nap\u0159\u00edklad v\u00e1m p\u0159ich\u00e1zej\u00ed n\u011bjak\u00e9 surov\u00e9 logy. A mo\u017en\u00e1 je lep\u0161\u00ed je ihned nezav\u00edrat do ClickHouse, i kdy\u017e je l\u00e1kav\u00e9 nic ned\u011blat a v\u0161echno bude fungovat. Nicm\u00e9n\u011b je lep\u0161\u00ed prov\u00e9st v\u00fdpo\u010dty, kter\u00e9 jsou mo\u017en\u00e9.<\/p>\n

<\/p>\n

Nap\u0159\u00edklad verze prohl\u00ed\u017ee\u010de. V jedn\u00e9 z vedlej\u0161\u00edch kancel\u00e1\u0159\u00ed, na kterou se mi nechce ukazovat prstem, se verze prohl\u00ed\u017ee\u010de uchov\u00e1v\u00e1 takto, t. j. jako \u0159et\u011bzec: 12.3. A pak, aby vytvo\u0159ili zpr\u00e1vu, tuto \u0159et\u011bzec vezmou a rozd\u011bl\u00ed na pole, a pak na prvn\u00ed prvek pole. Samoz\u0159ejm\u011b, v\u0161echno to zpomaluje. Pt\u00e1m se jich, pro\u010d to d\u011blaj\u00ed. Odpov\u011bd\u011bli mi, \u017ee nemaj\u00ed r\u00e1di p\u0159ed\u010dasnou optimalizaci. A j\u00e1 nem\u00e1m r\u00e1d p\u0159ed\u010dasnou pesimizaci.<\/p>\n

<\/p>\n

V tomto p\u0159\u00edpad\u011b by bylo spr\u00e1vn\u011bj\u0161\u00ed rozd\u011blit na 4 sloupce. Nebojte se toho, proto\u017ee je to ClickHouse. ClickHouse je sloupcov\u00e1 datab\u00e1ze. A \u010d\u00edm v\u00edce pe\u010dliv\u00fdch mal\u00fdch sloupc\u016f m\u00e1te, t\u00edm l\u00e9pe. M\u011bjte 5 BrowserVersion, vytvo\u0159te 5 sloupc\u016f. To je norm\u00e1ln\u00ed. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Nyn\u00ed se pod\u00edvejme, co d\u011blat, pokud m\u00e1te mnoho velmi dlouh\u00fdch \u0159et\u011bzc\u016f, velmi dlouh\u00fdch pol\u00ed. Ty nen\u00ed t\u0159eba uchov\u00e1vat v ClickHouse v\u016fbec. M\u00edsto toho m\u016f\u017eete uchov\u00e1vat v ClickHouse pouze n\u011bjak\u00fd identifik\u00e1tor. A dlouh\u00e9 \u0159et\u011bzce ulo\u017ete do n\u011bjak\u00e9ho jin\u00e9ho syst\u00e9mu. <\/p>\n

<\/p>\n

Nap\u0159\u00edklad v jednom z na\u0161ich analytick\u00fdch slu\u017eeb m\u00e1me ur\u010dit\u00e9 parametry ud\u00e1lost\u00ed. A pokud na ud\u00e1losti p\u0159ich\u00e1z\u00ed mnoho parametr\u016f, jednodu\u0161e ulo\u017e\u00edme prvn\u00edch 512. Proto\u017ee 512 je n\u00e1m l\u00edto. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A pokud si nejste jisti sv\u00fdmi typy dat, m\u016f\u017eete tak\u00e9 zapsat data do ClickHouse, ale do do\u010dasn\u00e9 tabulky typu Log, speci\u00e1ln\u00ed pro do\u010dasn\u00e1 data. Pot\u00e9 m\u016f\u017eete analyzovat, jak\u00e9 m\u00e1te rozlo\u017een\u00ed hodnot, co tam v\u016fbec je a sestavit spr\u00e1vn\u00e9 typy.<\/p>\n

<\/p>\n

* nyn\u00ed v ClickHouse existuje typ dat LowCardinality<\/a><\/noindex> kter\u00fd umo\u017e\u0148uje efektivn\u011b uchov\u00e1vat \u0159et\u011bzce s ni\u017e\u0161\u00edmi n\u00e1klady na pr\u00e1ci.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Nyn\u00ed se pod\u00edvejme na dal\u0161\u00ed zaj\u00edmav\u00fd p\u0159\u00edpad. N\u011bkdy lidem v\u0161echno n\u011bjak podivn\u011b funguje. Vstoup\u00edm a vid\u00edm tohle. A hned se mi vybav\u00ed, \u017ee to d\u011blal n\u011bjak\u00fd velmi zku\u0161en\u00fd, chytr\u00fd administr\u00e1tor, kter\u00fd m\u00e1 velk\u00e9 zku\u0161enosti se konfigurac\u00ed MySQL verze 3.23. <\/p>\n

<\/p>\n

Zde vid\u00edme tis\u00edc tabulek, z nich\u017e ka\u017ed\u00e1 obsahuje zbytek po d\u011blen\u00ed nejasn\u011b \u010deho tis\u00edcem. <\/p>\n

<\/p>\n

V z\u00e1sad\u011b respektuji zku\u0161enosti ostatn\u00edch a ch\u00e1pu, jak\u00e9 utrpen\u00ed m\u016f\u017ee vy\u017eadovat jejich z\u00edsk\u00e1n\u00ed. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A d\u016fvody jsou v\u00edcem\u00e9n\u011b jasn\u00e9. Jsou to star\u00e9 stereotypy, kter\u00e9 se mohly nahromadit p\u0159i pr\u00e1ci s jin\u00fdmi syst\u00e9my. Nap\u0159\u00edklad v tabulk\u00e1ch MyISAM neexistuje klastrov\u00fd prim\u00e1rn\u00ed kl\u00ed\u010d. A takov\u00fd zp\u016fsob rozd\u011blov\u00e1n\u00ed dat m\u016f\u017ee b\u00fdt zoufal\u00fdm pokusem z\u00edskat stejnou funkcionalitu. <\/p>\n

<\/p>\n

Dal\u0161\u00ed d\u016fvod je ten, \u017ee jak\u00e9koli operace typu alter nad velk\u00fdmi tabulkami jsou obt\u00ed\u017en\u00e9. V\u0161e bude blokov\u00e1no. A\u010dkoli v modern\u00edch verz\u00edch MySQL u\u017e tento probl\u00e9m nen\u00ed tak z\u00e1va\u017en\u00fd. <\/p>\n

<\/p>\n

Nebo nap\u0159\u00edklad mikrosharding, ale o tom pozd\u011bji.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

V ClickHouse to tak d\u011blat nemus\u00edte, proto\u017ee za prv\u00e9, prim\u00e1rn\u00ed kl\u00ed\u010d je klastrov\u00fd a data jsou uspo\u0159\u00e1d\u00e1na podle prim\u00e1rn\u00edho kl\u00ed\u010de. <\/p>\n

<\/p>\n

A ob\u010das se m\u011b ptaj\u00ed: \u201eJak se m\u011bn\u00ed v\u00fdkon dotaz\u016f na rozsah v ClickHouse podle velikosti tabulky?\u201c. \u0158\u00edk\u00e1m, \u017ee se to nijak nem\u011bn\u00ed. Nap\u0159\u00edklad pokud m\u00e1te tabulku s miliardou \u0159\u00e1dk\u016f a \u010dtete rozsah jeden milion \u0159\u00e1dk\u016f. V\u0161echno je v po\u0159\u00e1dku. Pokud m\u00e1 tabulka trilion \u0159\u00e1dk\u016f a vy \u010dtete jeden milion \u0159\u00e1dk\u016f, bude to skoro to sam\u00e9. <\/p>\n

<\/p>\n

A za druh\u00e9, nen\u00ed pot\u0159eba \u017e\u00e1dn\u00e9 v\u011bci jako ru\u010dn\u00ed partitioning. Pokud se pod\u00edv\u00e1te na souborov\u00fd syst\u00e9m, uvid\u00edte, \u017ee tabulka je pom\u011brn\u011b slo\u017eit\u00e1 z\u00e1le\u017eitost. A uvnit\u0159 je n\u011bco jako partition. Tedy ClickHouse d\u011bl\u00e1 v\u0161echno za v\u00e1s a nemus\u00edte trp\u011bt.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Alter v ClickHouse je zdarma, pokud se jedn\u00e1 o alter add\/drop column. <\/p>\n

<\/p>\n

A mal\u00e9 tabulky nen\u00ed dobr\u00e9 d\u011blat, proto\u017ee pokud m\u00e1te v tabulce 10 \u0159\u00e1dk\u016f nebo 10 000 \u0159\u00e1dk\u016f, je to \u00fapln\u011b irelevantn\u00ed. ClickHouse je syst\u00e9m, kter\u00fd optimalizuje throughput, ne latency, tak\u017ee zpracov\u00e1vat 10 \u0159\u00e1dk\u016f ned\u00e1v\u00e1 smysl. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Spr\u00e1vn\u00e9 je pou\u017e\u00edvat jednu velkou tabulku. Zbavte se star\u00fdch stereotyp\u016f, v\u0161echno bude v po\u0159\u00e1dku. <\/p>\n

<\/p>\n

A jako bonus m\u00e1me v posledn\u00ed verzi mo\u017enost vytv\u00e1\u0159et libovoln\u00fd kl\u00ed\u010d partitioningu, co\u017e umo\u017e\u0148uje prov\u00e1d\u011bt r\u016fzn\u00e9 \u00fadr\u017ebov\u00e9 operace na jednotliv\u00fdch partition. <\/p>\n

<\/p>\n

Nap\u0159\u00edklad pot\u0159ebujete mnoho mal\u00fdch tabulek, nap\u0159\u00edklad kdy\u017e je pot\u0159eba zpracov\u00e1vat n\u011bjak\u00e9 mezidatov\u00e9 informace, dostanete kusy a mus\u00edte na nich prov\u00e1d\u011bt transformaci p\u0159ed z\u00e1znamem do fin\u00e1ln\u00ed tabulky. Pro tento p\u0159\u00edpad existuje skv\u011bl\u00fd engine tabulky \u2013 StripeLog. To je n\u011bco jako TinyLog, jen lep\u0161\u00ed. <\/p>\n

<\/p>\n

* nyn\u00ed m\u00e1 ClickHouse tak\u00e9 tabulkovou funkci input<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Dal\u0161\u00ed antipattern \u2013 to je mikrozach\u00e1zen\u00ed. Nap\u0159\u00edklad, pokud pot\u0159ebujete shardovat data a m\u00e1te 5 server\u016f, ale z\u00edtra bude 6 server\u016f. A p\u0159em\u00fd\u0161l\u00edte, jak tyto \u00fadaje p\u0159ebalancovat. A m\u00edsto toho rozd\u011blujete ne na 5 shard\u016f, ale na 1 000 shard\u016f. A pak p\u0159i\u0159azujete ka\u017ed\u00fd z t\u011bchto mikroshard\u016f na samostatn\u00fd server. A ve v\u00fdsledku m\u00e1te na jednom serveru nap\u0159\u00edklad 200 ClickHouse, tedy jednotliv\u00e9 instance na r\u016fzn\u00fdch portech nebo samostatn\u00e9 datab\u00e1ze. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Ale v ClickHouse to nen\u00ed moc dobr\u00e9. Proto\u017ee i jedna instance ClickHouse se sna\u017e\u00ed vyu\u017e\u00edt v\u0161echny dostupn\u00e9 prost\u0159edky serveru pro zpracov\u00e1n\u00ed jednoho dotazu. Tedy pokud m\u00e1te n\u011bjak\u00fd server s nap\u0159\u00edklad 56 procesorov\u00fdmi j\u00e1dry. Spust\u00edte dotaz, kter\u00fd trv\u00e1 jednu sekundu, a ten vyu\u017eije 56 jader. A pokud tam m\u00e1te 200 ClickHouse na jednom serveru, vznikne 10 000 vl\u00e1ken. Celkov\u011b to n\u011bjak nebude dob\u0159e.<\/p>\n

<\/p>\n

Dal\u0161\u00ed d\u016fvod je, \u017ee rozd\u011blen\u00ed pr\u00e1ce mezi t\u011bmito instancemi bude nerovnom\u011brn\u00e9. N\u011bkter\u00e9 skon\u010d\u00ed d\u0159\u00edve, jin\u00e9 pozd\u011bji. Kdyby se to v\u0161echno d\u011blo v jedn\u00e9 instanci, ClickHouse by si s t\u00edm poradil l\u00e9pe a spr\u00e1vn\u011b rozlo\u017eil data mezi vl\u00e1kna. <\/p>\n

<\/p>\n

A je\u0161t\u011b jeden d\u016fvod je v tom, \u017ee budete m\u00edt meziprocesorovou komunikaci p\u0159es TCP. Data bude nutn\u00e9 serializovat, deserializovat a to je obrovsk\u00e9 mno\u017estv\u00ed mikroshard\u016f. Zkr\u00e1tka to bude neefektivn\u00ed.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Dal\u0161\u00ed antipattern, a\u010dkoliv je t\u011b\u017ek\u00e9 to nazvat antipatternem. To je velk\u00e9 mno\u017estv\u00ed p\u0159edagregace.<\/p>\n

<\/p>\n

Obecn\u011b, p\u0159edagregace \u2013 to je dobr\u00e9. M\u011bli jste miliardu \u0159\u00e1dk\u016f, agregovali jste a dostali jste se na 1 000 \u0159\u00e1dk\u016f, a nyn\u00ed se dotaz vykon\u00e1v\u00e1 okam\u017eit\u011b. V\u0161echno je skv\u011bl\u00e9. Tak to lze d\u011blat. A pro to existuje dokonce v ClickHouse speci\u00e1ln\u00ed typ tabulky AggregatingMergeTree, kter\u00e1 prov\u00e1d\u00ed inkrement\u00e1ln\u00ed agregaci p\u0159i vkl\u00e1d\u00e1n\u00ed dat. <\/p>\n

<\/p>\n

N\u011bkdy si mysl\u00edte, \u017ee data budeme agregovat t\u00edmto zp\u016fsobem a je\u0161t\u011b t\u00edmto zp\u016fsobem. A v n\u011bkter\u00e9m sousedn\u00edm odd\u011blen\u00ed, o kter\u00e9m se mi nechce mluvit, pou\u017e\u00edvaj\u00ed tabulky SummingMergeTree pro sou\u010dtov\u00e1n\u00ed podle prim\u00e1rn\u00edho kl\u00ed\u010de, a jako prim\u00e1rn\u00ed kl\u00ed\u010d pou\u017e\u00edvaj\u00ed zhruba 20 r\u016fzn\u00fdch sloupc\u016f. Pro jistotu jsem zm\u011bnil n\u00e1zvy n\u011bkter\u00fdch sloupc\u016f pro konspiraci, ale zhruba to tak je.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A vznikaj\u00ed takov\u00e9 probl\u00e9my. Zaprv\u00e9, objem dat se v\u00e1m nezmen\u0161\u00ed p\u0159\u00edli\u0161. Nap\u0159\u00edklad se zmen\u0161\u00ed t\u0159ikr\u00e1t. T\u0159ikr\u00e1t \u2013 to by byla dobr\u00e1 cena, abyste si mohli dovolit neomezen\u00e9 mo\u017enosti analytiky, kter\u00e9 vznikaj\u00ed, pokud data nejsou agregovan\u00e1. Pokud jsou data agregovan\u00e1, m\u00edsto analytiky dostanete jen \u017ealostnou statistiku. <\/p>\n

<\/p>\n

A co je obzvl\u00e1\u0161\u0165 frustruj\u00edc\u00ed? To, \u017ee lid\u00e9 ze sousedn\u00edho odd\u011blen\u00ed chod\u00ed a ob\u010das \u017e\u00e1daj\u00ed o p\u0159id\u00e1n\u00ed dal\u0161\u00edho sloupce do prim\u00e1rn\u00edho kl\u00ed\u010de. Tedy jsme data t\u00edmto zp\u016fsobem agregovali, a te\u010f chceme trochu v\u00edce. Ale v ClickHouse nen\u00ed mo\u017en\u00e9 m\u011bnit prim\u00e1rn\u00ed kl\u00ed\u010d. Proto je pot\u0159eba ps\u00e1t n\u011bjak\u00e9 skripty v C++. A j\u00e1 nem\u00e1m r\u00e1d skripty, ani kdy\u017e jsou v C++.<\/p>\n

<\/p>\n

A pokud se pod\u00edv\u00e1te, k \u010demu byl ClickHouse vytvo\u0159en, tak neagregovan\u00e1 data \u2013 to je p\u0159esn\u011b ten sc\u00e9n\u00e1\u0159, pro kter\u00fd byl vynalezen. Pokud pou\u017e\u00edv\u00e1te ClickHouse pro neagregovan\u00e1 data, d\u011bl\u00e1te to spr\u00e1vn\u011b. Pokud agregujete, je to n\u011bkdy odpustiteln\u00e9. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Dal\u0161\u00ed zaj\u00edmav\u00fd p\u0159\u00edpad \u2013 to jsou dotazy v nekone\u010dn\u00e9 smy\u010dce. N\u011bkdy se p\u0159ihl\u00e1s\u00edm na n\u011bjak\u00fd produk\u010dn\u00ed server a pod\u00edv\u00e1m se na show processlist. A poka\u017ed\u00e9 zjist\u00edm, \u017ee se tam d\u011bje n\u011bco hrozn\u00e9ho. <\/p>\n

<\/p>\n

Nap\u0159\u00edklad n\u011bco takov\u00e9ho. Hned je jasn\u00e9, \u017ee by to v\u0161echno \u0161lo vykonat v jednom dotazu. Sta\u010d\u00ed napsat url in a seznam.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Pro\u010d je tolik takov\u00fdch dotaz\u016f v nekone\u010dn\u00e9 smy\u010dce \u0161patn\u00fdch? Pokud se index nepou\u017e\u00edv\u00e1, budete m\u00edt hodn\u011b pr\u016fchod\u016f stejn\u00fdmi daty. Ale pokud se index pou\u017e\u00edv\u00e1, nap\u0159\u00edklad m\u00e1te prim\u00e1rn\u00ed kl\u00ed\u010d podle ru a p\u00ed\u0161ete url = n\u011b\u010demu. A mysl\u00edte si, \u017ee se bude \u010d\u00edst z tabulky konkr\u00e9tn\u00ed url, bylo by to v po\u0159\u00e1dku. Ale skute\u010dn\u011b ne. Proto\u017ee ClickHouse v\u0161echno d\u011bl\u00e1 po d\u00e1vk\u00e1ch. <\/p>\n

<\/p>\n

Kdy\u017e pot\u0159ebuje p\u0159e\u010d\u00edst n\u011bjak\u00fd rozsah dat, p\u0159e\u010dte o n\u011bco v\u00edce, proto\u017ee index v ClickHouse je \u0159\u00eddk\u00fd. Tento index neumo\u017e\u0148uje naj\u00edt v tabulce jednu jednotlivou \u0159\u00e1dku, pouze n\u011bjak\u00fd rozsah. A data se komprimuj\u00ed po bloc\u00edch. Abychom p\u0159e\u010detli jednu \u0159\u00e1dku, mus\u00edme vz\u00edt cel\u00fd blok a rozbalit ho. A pokud prov\u00e1d\u00edte spoustu dotaz\u016f, budete m\u00edt mnoho takov\u00fdch p\u0159ekryv\u016f, a spousta pr\u00e1ce se bude vykon\u00e1vat znovu a znovu.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A jako bonus lze poznamenat, \u017ee v ClickHouse se nen\u00ed t\u0159eba b\u00e1t p\u0159ed\u00e1vat i megabyty a dokonce stovky megabyt\u016f do sekce IN. Pamatuji si ze sv\u00e9 praxe, \u017ee pokud v MySQL p\u0159ed\u00e1v\u00e1me spoustu hodnot do sekce IN, nap\u0159\u00edklad p\u0159ed\u00e1v\u00e1me do n\u00ed 100 megabyt\u016f n\u011bjak\u00fdch \u010d\u00edsel, MySQL spot\u0159ebov\u00e1v\u00e1 10 gigabajt\u016f pam\u011bti a v\u00edc se s t\u00edm nic ned\u011bje, v\u0161echno funguje \u0161patn\u011b. <\/p>\n

<\/p>\n

A za druh\u00e9 \u2013 je to, \u017ee v ClickHouse, pokud va\u0161e dotazy pou\u017e\u00edvaj\u00ed index, je to v\u017edy rychlej\u0161\u00ed ne\u017e full scan, t. j. pokud je t\u0159eba p\u0159e\u010d\u00edst t\u00e9m\u011b\u0159 celou tabulku, bude to prob\u00edhat sekven\u010dn\u011b a p\u0159e\u010dte celou tabulku. Obecn\u011b se o to postar\u00e1 s\u00e1m.<\/p>\n

<\/p>\n

Nicm\u00e9n\u011b existuj\u00ed n\u011bkter\u00e9 slo\u017eitosti. Nap\u0159\u00edklad to, \u017ee IN s poddotazem index nevyu\u017e\u00edv\u00e1. Ale to je n\u00e1\u0161 probl\u00e9m a mus\u00edme to opravit. Nic z\u00e1sadn\u00edho tu nen\u00ed. Budeme opravovat. <\/p>\n

<\/p>\n

A je\u0161t\u011b jedna zaj\u00edmav\u00e1 v\u011bc \u2013 pokud m\u00e1te velmi dlouh\u00fd dotaz a prob\u00edh\u00e1 distribuovan\u00e9 zpracov\u00e1n\u00ed dotaz\u016f, tento velmi dlouh\u00fd dotaz bude odesl\u00e1n na ka\u017ed\u00fd server bez komprese. Nap\u0159\u00edklad 100 megabyt\u016f a 500 server\u016f. A samoz\u0159ejm\u011b, \u017ee se po s\u00edti p\u0159enese 50 gigabajt\u016f. Bude to p\u0159eneseno a pak se v\u0161echno \u00fasp\u011b\u0161n\u011b provede.<\/p>\n

<\/p>\n

* u\u017e pou\u017e\u00edv\u00e1; v\u0161echno je opraveno, jak bylo sl\u00edbeno.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

A docela \u010dast\u00fd p\u0159\u00edpad, kdy\u017e dotazy p\u0159ich\u00e1zej\u00ed z API. Nap\u0159\u00edklad jste vytvo\u0159ili n\u011bjakou svou slu\u017ebu. A pokud va\u0161i slu\u017ebu n\u011bkdo pot\u0159ebuje, otev\u0159eli jste API a u\u017e doslova za dva dny vid\u00edte, \u017ee se d\u011bje n\u011bco nejasn\u00e9ho. V\u0161echny p\u0159et\u00ed\u017een\u00ed a n\u011bjak\u00e9 hrozn\u00e9 dotazy p\u0159ich\u00e1zej\u00ed, kter\u00e9 nikdy nem\u011bly b\u00fdt. <\/p>\n

<\/p>\n

A \u0159e\u0161en\u00ed je jedin\u00e9. Pokud jste otev\u0159eli API, budete ho muset omezit. Nap\u0159\u00edklad zav\u00e9st n\u011bjak\u00e9 kv\u00f3ty. Jin\u00fdch norm\u00e1ln\u00edch mo\u017enost\u00ed nen\u00ed. Jinak hned nap\u00ed\u0161ou skript a budou probl\u00e9my. <\/p>\n

<\/p>\n

A v ClickHouse je speci\u00e1ln\u00ed funkce - po\u010d\u00edt\u00e1n\u00ed kv\u00f3t. M\u016f\u017eete p\u0159edat sv\u016fj kl\u00ed\u010d kv\u00f3ty, co\u017e m\u016f\u017ee b\u00fdt nap\u0159\u00edklad vnit\u0159n\u00ed identifik\u00e1tor u\u017eivatele. Kv\u00f3ty se po\u010d\u00edtaj\u00ed samostatn\u011b pro ka\u017ed\u00e9ho z nich. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Te\u010f je\u0161t\u011b jedna zaj\u00edmav\u00e1 v\u011bc. To je replikace na ru\u010dn\u00ed pohon. <\/p>\n

<\/p>\n

Zn\u00e1m mnoho p\u0159\u00edpad\u016f, kdy lid\u00e9, p\u0159esto\u017ee ClickHouse m\u00e1 vestav\u011bnou podporu replikace, replikuj\u00ed ClickHouse ru\u010dn\u011b.<\/p>\n

<\/p>\n

Jak\u00fd je princip? M\u00e1te datov\u00fd zpracovatelsk\u00fd pipeline. A ten pracuje nez\u00e1visle, nap\u0159\u00edklad v r\u016fzn\u00fdch datov\u00fdch centrech. Stejn\u00e9 \u00fadaje zapisujete stejn\u011b do ClickHouse. Pravda, praxe ukazuje, \u017ee \u00fadaje se stejn\u011b rozch\u00e1zej\u00ed kv\u016fli n\u011bjak\u00fdm zvl\u00e1\u0161tnostem ve va\u0161em k\u00f3du. Douf\u00e1m, \u017ee se to net\u00fdk\u00e1 i v\u00e1s. <\/p>\n

<\/p>\n

A ob\u010das budete muset ru\u010dn\u011b synchronizovat. Nap\u0159\u00edklad jednou za m\u011bs\u00edc administr\u00e1to\u0159i prov\u00e1d\u011bj\u00ed rsync.<\/p>\n

<\/p>\n

Ve skute\u010dnosti je mnohem snaz\u0161\u00ed pou\u017e\u00edt vestav\u011bnou replikaci v ClickHouse. Ale mohou b\u00fdt n\u011bkter\u00e9 kontraindikace, proto\u017ee k tomu je pot\u0159eba pou\u017e\u00edvat ZooKeeper. Nic \u0161patn\u00e9ho o ZooKeeper ne\u0159\u00edk\u00e1m, v podstat\u011b to funguje, ale lid\u00e9 ho n\u011bkdy nepou\u017e\u00edvaj\u00ed kv\u016fli java-fobii, proto\u017ee ClickHouse je skv\u011bl\u00fd syst\u00e9m napsan\u00fd v C++, se kter\u00fdm se d\u00e1 pracovat a v\u0161echno funguje skv\u011ble. A ZooKeeper je na java. A n\u011bjak se v\u00e1m to ani nechce zkoumat, ale pak m\u016f\u017eete pou\u017e\u00edt replikaci na ru\u010dn\u00ed pohon. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

ClickHouse je praktick\u00fd syst\u00e9m. Zohled\u0148uje va\u0161e pot\u0159eby. Pokud m\u00e1te replikaci na ru\u010dn\u00ed pohon, m\u016f\u017eete vytvo\u0159it distribuovanou tabulku, kter\u00e1 sleduje va\u0161e ru\u010dn\u00ed repliky a sama prov\u00e1d\u00ed failover mezi nimi. Existuje dokonce speci\u00e1ln\u00ed mo\u017enost, kter\u00e1 umo\u017e\u0148uje vyhnout se fluktuac\u00edm, i kdy\u017e se va\u0161e repliky systematicky rozch\u00e1zej\u00ed.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Dal\u0161\u00ed mohou vzniknout probl\u00e9my, pokud pou\u017e\u00edv\u00e1te primitivn\u00ed table engines. ClickHouse je jako stavebnice, ve kter\u00e9 je spousta r\u016fzn\u00fdch typ\u016f tabulek. Pro v\u0161echny v\u00e1\u017en\u00e9 p\u0159\u00edpady, jak je uvedeno v dokumentaci, pou\u017e\u00edvejte tabulky rodiny MergeTree. V\u0161echny ostatn\u00ed jsou sp\u00ed\u0161e pro jednotliv\u00e9 p\u0159\u00edpady nebo pro testy.<\/p>\n

<\/p>\n

V tabulce MergeTree nen\u00ed nutn\u00e9, abyste m\u011bli n\u011bjak\u00e9 datum a \u010das. M\u016f\u017eete je stejn\u011b pou\u017e\u00edvat. Pokud datum a \u010das nejsou, nastavte, \u017ee default \u2013 2000 rok. To bude fungovat a nebude to vy\u017eadovat \u017e\u00e1dn\u00e9 zdroje. <\/p>\n

<\/p>\n

A v nov\u00e9 verzi serveru m\u016f\u017eete dokonce ur\u010dit, \u017ee chcete m\u00edt vlastn\u00ed partitioning bez kl\u00ed\u010de partition. Bude to tot\u00e9\u017e. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Na druhou stranu lze pou\u017e\u00edt primitivn\u00ed tabulkov\u00e9 enginy. Nap\u0159\u00edklad nahr\u00e1t data jednou a pod\u00edvat se, oto\u010dit a odstranit. M\u016f\u017eete pou\u017e\u00edt Log.<\/p>\n

<\/p>\n

Nebo ukl\u00e1d\u00e1n\u00ed mal\u00fdch objem\u016f pro mezispracov\u00e1n\u00ed \u2013 to je StripeLog nebo TinyLog.<\/p>\n

<\/p>\n

Memory m\u016f\u017eete pou\u017e\u00edt, pokud m\u00e1te mal\u00fd objem dat a jen si chcete n\u011bco oto\u010dit v pam\u011bti. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

ClickHouse nem\u00e1 p\u0159\u00edli\u0161 r\u00e1d denormalizovan\u00e1 data. <\/p>\n

<\/p>\n

Toto je typick\u00fd p\u0159\u00edklad. Je to obrovsk\u00e9 mno\u017estv\u00ed URL. Zatla\u010dili jste je do sousedn\u00ed tabulky. A pak jste se rozhodli s nimi prov\u00e1d\u011bt JOIN, ale to bude obvykle nefungovat, proto\u017ee ClickHouse podporuje pouze Hash JOIN. Pokud nesta\u010d\u00ed pam\u011b\u0165 pro mnoho dat, se kter\u00fdmi se m\u00e1 spojit, JOIN nebude mo\u017en\u00e9 prov\u00e9st. <\/p>\n

<\/p>\n

Pokud m\u00e1te data s vysokou kardinalitou, tak se nestarejte, uchov\u00e1vejte je v denormalizovan\u00e9 podob\u011b, URL p\u0159\u00edmo inplace v hlavn\u00ed tabulce. <\/p>\n

<\/p>\n

* a nyn\u00ed m\u00e1 ClickHouse tak\u00e9 merge join, kter\u00fd funguje za podm\u00ednek, kdy mezidaty se nevejdou do pam\u011bti. Ale to nen\u00ed efektivn\u00ed a doporu\u010den\u00ed z\u016fst\u00e1v\u00e1 v platnosti.<\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Je\u0161t\u011b p\u00e1r p\u0159\u00edklad\u016f, ale u\u017e v\u00e1h\u00e1m, zda jsou antypatternov\u00e9 nebo ne. <\/p>\n

<\/p>\n

V ClickHouse je jeden zn\u00e1m\u00fd nedostatek. Neum\u00ed aktualizace. V jist\u00e9m smyslu je to dokonce dobr\u00e9. Pokud m\u00e1te n\u011bjak\u00e1 d\u016fle\u017eit\u00e1 data, nap\u0159\u00edklad \u00fa\u010detnictv\u00ed, nikdo je nebude moci zm\u011bnit, proto\u017ee aktualizace neexistuj\u00ed.<\/p>\n

<\/p>\n

* podpora aktualizace a maz\u00e1n\u00ed v d\u00e1vkov\u00e9m re\u017eimu byla p\u0159id\u00e1na u\u017e d\u00e1vno.<\/p>\n

<\/p>\n

Existuj\u00ed v\u0161ak n\u011bkter\u00e9 zvl\u00e1\u0161tn\u00ed zp\u016fsoby, kter\u00e9 umo\u017e\u0148uj\u00ed aktualizace jakoby na pozad\u00ed. Nap\u0159\u00edklad tabulky typu ReplaceMergeTree. Prov\u00e1d\u011bj\u00ed aktualizace b\u011bhem pozad\u00ed merg\u00ed. M\u016f\u017eete to urychlit pomoc\u00ed optimize table. Ale ned\u011blejte to p\u0159\u00edli\u0161 \u010dasto, proto\u017ee to \u00fapln\u011b p\u0159ep\u00ed\u0161e partition. <\/p>\n

<\/p>\n

Distribuovan\u00e9 JOIN v ClickHouse \u2013 to je tak\u00e9 \u0161patn\u011b zpracov\u00e1no pl\u00e1nova\u010dem dotaz\u016f. <\/p>\n

<\/p>\n

\u0160patn\u011b, ale n\u011bkdy OK.<\/p>\n

<\/p>\n

Pou\u017eit\u00ed ClickHouse pouze pro \u010dten\u00ed dat zp\u011bt pomoc\u00ed select.<\/p>\n

<\/p>\n

Nedoporu\u010dil bych pou\u017e\u00edvat ClickHouse pro slo\u017eit\u00e9 v\u00fdpo\u010dty. Ale nen\u00ed to \u00fapln\u011b tak, proto\u017ee u\u017e od t\u00e9to doporu\u010den\u00ed ustupujeme. A ned\u00e1vno jsme p\u0159idali mo\u017enost aplikovat modely strojov\u00e9ho u\u010den\u00ed v ClickHouse \u2013 Catboost. A to m\u011b znepokojuje, proto\u017ee si \u0159\u00edk\u00e1m: \u201eJak\u00e1 hr\u016fza. Kolik takt\u016f na byte to bude?\u201c. Je mi moc l\u00edto, \u017ee takty jdou na bajty. <\/p>\n

<\/p>\n

\"Efektivn\u00ed<\/p>\n

<\/p>\n

Ale nebojte se, nainstalujte ClickHouse, v\u0161echno bude v po\u0159\u00e1dku. Pokud n\u011bco, m\u00e1me komunitu. Mimochodem, ta komunita jste vy. A pokud m\u00e1te n\u011bjak\u00e9 probl\u00e9my, m\u016f\u017eete se alespo\u0148 p\u0159ipojit do na\u0161eho chatu, a douf\u00e1m, \u017ee v\u00e1m pomohou. <\/p>\n

<\/p>\n

Ot\u00e1zky<\/p>\n

<\/p>\n

D\u011bkuji za prezentaci! Kam si mohu st\u011b\u017eovat na p\u00e1d ClickHouse?<\/em><\/p>\n

<\/p>\n

M\u016f\u017eete si st\u011b\u017eovat m\u011b osobn\u011b pr\u00e1v\u011b te\u010f. <\/p>\n

<\/p>\n

Ned\u00e1vno jsem za\u010dal pou\u017e\u00edvat ClickHouse. Okam\u017eit\u011b jsem zkolaboval cli rozhran\u00ed.<\/em><\/p>\n

<\/p>\n

M\u011bli jste \u0161t\u011bst\u00ed. <\/p>\n

<\/p>\n

O chv\u00edli pozd\u011bji jsem zkolaboval server mal\u00fdm selectem.<\/em><\/p>\n

<\/p>\n

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

<\/p>\n

Otev\u0159el jsem bug na GitHubu, ale ignorovali ho.<\/em> <\/p>\n

<\/p>\n

Pod\u00edv\u00e1me se na to. <\/p>\n

<\/p>\n

Alexej m\u011b podvedl a dostal m\u011b na prezentaci, sl\u00edbil, \u017ee pov\u00ed, jak data uvnit\u0159 stla\u010dujete.<\/em><\/p>\n

<\/p>\n

Velmi jednodu\u0161e. <\/p>\n

<\/p>\n

To jsem pochopil u\u017e v\u010dera. V\u00edce konkr\u00e9tn\u011b.<\/em> <\/p>\n

<\/p>\n

Nen\u00ed tam \u017e\u00e1dn\u00e9 stra\u0161n\u00e9 tajemstv\u00ed. Je to prost\u011b komprese po bloc\u00edch. Standardn\u011b se pou\u017e\u00edv\u00e1 LZ4, lze aktivovat ZSTD*. Bloky jsou od 64 kilobajt\u016f do 1 megabajtu.<\/p>\n

<\/p>\n

* tak\u00e9 existuje podpora specializovan\u00fdch kompresn\u00edch kodek\u016f, kter\u00e9 lze pou\u017e\u00edt v \u0159et\u011bzci s jin\u00fdmi algoritmy.<\/p>\n

<\/p>\n

Jsou v bloc\u00edch prost\u011b syrov\u00e1 data?<\/em><\/p>\n

<\/p>\n

Ne \u00fapln\u011b syrov\u00e1. Jsou tam pole. Pokud m\u00e1te \u010d\u00edseln\u00fd sloupec, \u010d\u00edsla jsou ulo\u017eena za sebou v poli. <\/p>\n

<\/p>\n

Rozum\u00edm.<\/em> <\/p>\n

<\/p>\n

Alexej, p\u0159\u00edklad, kter\u00fd byl s uniqExact nad IP adresami, tj. to, co \u0159\u00edk\u00e1te, \u017ee uniqExact nad \u0159et\u011bzci trv\u00e1 d\u00e9le ne\u017e nad \u010d\u00edsly a tak d\u00e1le. A pokud zkus\u00edme trik a budeme typovat p\u0159i \u010dten\u00ed? Tj. vy jste jakoby \u0159ekli, \u017ee na disku se to u n\u00e1s p\u0159\u00edli\u0161 neli\u0161\u00ed. Pokud budeme \u010d\u00edst ze disku \u0159et\u011bzce a typovat, zda pak rychleji z\u00edsk\u00e1me agreg\u00e1ty, nebo ne? Nebo zde budeme m\u00edt jen nepatrn\u00fd zisk? Mysl\u00edm, \u017ee jste to testovali, ale z n\u011bjak\u00e9ho d\u016fvodu jste to neuv\u00e1d\u011bli v benchmarku.<\/em> <\/p>\n

<\/p>\n

Mysl\u00edm, \u017ee to bude pomalej\u0161\u00ed ne\u017e bez castu. V tomto p\u0159\u00edpad\u011b je t\u0159eba extrahovat IP adresu ze \u0159et\u011bzce. U n\u00e1s je samoz\u0159ejm\u011b v ClickHouse parsing IP adres optimalizovan\u00fd tak\u00e9. Ud\u011blali jsme, co jsme mohli, ale p\u0159ece jen m\u00e1te \u010d\u00edsla zapsan\u00e1 v deseti tis\u00edci form\u00e1tu. To je velmi nepohodln\u00e9. Na druhou stranu funkce uniqExact bude na \u0159et\u011bzc\u00edch fungovat pomaleji nejen proto, \u017ee se jedn\u00e1 o \u0159et\u011bzce, ale tak\u00e9 proto, \u017ee se vyb\u00edr\u00e1 jin\u00e1 specializace algoritmu. \u0158et\u011bzce se zpracov\u00e1vaj\u00ed jednodu\u0161e jinak.<\/p>\n

<\/p>\n

A co kdybychom vzali primitivn\u011bj\u0161\u00ed typ dat? Nap\u0159\u00edklad jsme zapsali user id, kter\u00e9 m\u00e1me v in, zapsali jsme ho jako \u0159et\u011bzec a pak jsme to castili, bude to z\u00e1bavn\u011bj\u0161\u00ed, nebo ne?<\/em><\/p>\n

<\/p>\n

M\u00e1m o tom pochybnosti. Mysl\u00edm, \u017ee to bude je\u0161t\u011b smutn\u011bj\u0161\u00ed, proto\u017ee parsov\u00e1n\u00ed \u010d\u00edsel je opravdu v\u00e1\u017en\u00fd probl\u00e9m. M\u00e1m pocit, \u017ee tento kolega m\u011bl dokonce p\u0159edn\u00e1\u0161ku na t\u00e9ma, jak slo\u017eit\u00e9 je parsovat \u010d\u00edsla v deseti tis\u00edci form\u00e1tu, ale mo\u017en\u00e1 ne. <\/p>\n

<\/p>\n

Alexei, moc d\u011bkuji za p\u0159edn\u00e1\u0161ku! A tak\u00e9 d\u011bkuji za ClickHouse! M\u00e1m ot\u00e1zku ohledn\u011b funkc\u00ed. Je v pl\u00e1nu funkce pro ne\u00faplnou aktualizaci slovn\u00edk\u016f?<\/em><\/p>\n

<\/p>\n

Tedy \u010d\u00e1ste\u010dn\u00e9 na\u010dten\u00ed?<\/p>\n

<\/p>\n

Ano, ano. Typu mo\u017enosti nastavit tam pole MySQL, tedy aktualizovat po, aby se na\u010d\u00edtala pouze tato data, pokud je slovn\u00edk velmi velk\u00fd.<\/em><\/p>\n

<\/p>\n

Velmi zaj\u00edmav\u00e1 funkce. A zd\u00e1 se mi, \u017ee ji n\u011bkdo navrhnul v na\u0161em chatu. Mo\u017en\u00e1 jste to byl dokonce vy. <\/p>\n

<\/p>\n

Nemysl\u00edm si, \u017ee bych to byl j\u00e1.<\/em><\/p>\n

<\/p>\n

Skv\u011bl\u00e9, nyn\u00ed m\u00e1me dva po\u017eadavky. A m\u016f\u017eeme v klidu za\u010d\u00edt pracovat. Ale hned v\u00e1s chci varovat, \u017ee tato funkce je pom\u011brn\u011b snadn\u00e1 na implementaci. Tedy v ide\u00e1ln\u00edm p\u0159\u00edpad\u011b sta\u010d\u00ed napsat do tabulky \u010d\u00edslo verze a pot\u00e9 napsat: verze je men\u0161\u00ed ne\u017e ta a ta. A to znamen\u00e1, \u017ee to pravd\u011bpodobn\u011b nab\u00eddneme nad\u0161enc\u016fm. Jste nad\u0161enec? <\/p>\n

<\/p>\n

Ano, ale bohu\u017eel ne v C++.<\/em><\/p>\n

<\/p>\n

Um\u00ed va\u0161i kolegov\u00e9 ps\u00e1t v C++? <\/p>\n

<\/p>\n

N\u011bkoho najdu.<\/em><\/p>\n

<\/p>\n

Skv\u011bl\u00e9*.<\/p>\n

<\/p>\n

* mo\u017enost byla p\u0159id\u00e1na dva m\u011bs\u00edce po p\u0159edn\u00e1\u0161ce \u2013 vyvinul ji autor ot\u00e1zky a zaslal ji pull request<\/a><\/noindex>.<\/p>\n

<\/p>\n

D\u011bkuji!<\/em><\/p>\n

<\/p>\n

Dobr\u00fd den! D\u011bkuji za prezentaci! Zm\u00ednil jste, \u017ee ClickHouse velmi efektivn\u011b vyu\u017e\u00edv\u00e1 v\u0161echny dostupn\u00e9 zdroje. A p\u0159\u00edtel z Luxoftu hovo\u0159il o sv\u00e9m \u0159e\u0161en\u00ed pro Po\u0161tu Ruska. \u0158ekl, \u017ee se mu ClickHouse velmi l\u00edbil, ale nepou\u017eili ho m\u00edsto sv\u00e9ho hlavn\u00edho konkurenta pr\u00e1v\u011b proto, \u017ee \u017eral v\u0161echny procesory. A oni ho nedok\u00e1zali zapojit do sv\u00e9 architektury, do sv\u00e9ho ZooKeeperu s kontejnery. Je n\u011bjak\u00e1 mo\u017enost, jak omezit ClickHouse, aby nespot\u0159ebov\u00e1val v\u0161e, co mu je dostupn\u00e9?<\/em><\/p>\n

<\/p>\n

Ano, to lze a velmi jednodu\u0161e. Pokud chcete, aby zab\u00edral m\u00e9n\u011b jader, sta\u010d\u00ed napsat set max_threads = 1<\/code>. A je to, dotaz bude prov\u00e1d\u011bn na jedno j\u00e1dro. P\u0159itom lze r\u016fzn\u00fdm u\u017eivatel\u016fm nastavit tuto mo\u017enost odli\u0161n\u011b. Tak\u017ee \u017e\u00e1dn\u00e9 probl\u00e9my. A koleg\u016fm z Luxoftu \u0159ekn\u011bte, \u017ee nen\u00ed v po\u0159\u00e1dku, \u017ee tuto mo\u017enost nena\u0161li v dokumentaci. <\/p>\n

<\/p>\n

Alexei, dobr\u00fd den! Cht\u011bl bych se zeptat na jednu v\u011bc. U\u017e nepoprv\u00e9 sly\u0161\u00edm, \u017ee mnoho lid\u00ed za\u010d\u00edn\u00e1 pou\u017e\u00edvat ClickHouse jako \u00falo\u017ei\u0161t\u011b log\u016f. Na prezentaci jste \u0159\u00edkal, aby se to ned\u011blalo, tj. nen\u00ed pot\u0159eba uchov\u00e1vat dlouh\u00e9 \u0159et\u011bzce. Jak na to pohl\u00ed\u017e\u00edte?<\/em><\/p>\n

<\/p>\n

Zaprv\u00e9, logy obvykle nejsou dlouh\u00e9 \u0159et\u011bzce. Samoz\u0159ejm\u011b, ob\u010das jsou v\u00fdjimky. Nap\u0159\u00edklad n\u011bjak\u00e1 slu\u017eba napsan\u00e1 v Jav\u011b vyhazuje v\u00fdjimku, ta se loguje. A tak v nekone\u010dn\u00e9 smy\u010dce, kon\u010d\u00ed m\u00edsto na pevn\u00e9m disku. \u0158e\u0161en\u00ed je velmi jednoduch\u00e9. Pokud jsou \u0159et\u011bzce p\u0159\u00edli\u0161 dlouh\u00e9, zkra\u0165te je. A co znamen\u00e1 dlouh\u00e9? Des\u00edtky kilobajt\u016f \u2013 to je \u0161patn\u011b.<\/p>\n

<\/p>\n

* V nov\u00fdch verz\u00edch ClickHouse byla zavedena \"adaptivn\u00ed granularita indexu\", co\u017e v\u011bt\u0161inou \u0159e\u0161\u00ed probl\u00e9m s ukl\u00e1d\u00e1n\u00edm dlouh\u00fdch \u0159et\u011bzc\u016f.<\/p>\n

<\/p>\n

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

<\/p>\n

Norm\u00e1ln\u00ed. <\/p>\n

<\/p>\n

Dobr\u00fd den! D\u011bkuji za prezentaci! U\u017e jsem se o tom v chatu ptal, ale nepamatuji se, jestli jsem dostal odpov\u011b\u010f. Pl\u00e1nuje se n\u011bjak roz\u0161\u00ed\u0159it sekce WITH ve stylu CTE?<\/em><\/p>\n

<\/p>\n

Zat\u00edm ne. Sekce WITH je u n\u00e1s pon\u011bkud v\u00e1\u017en\u00e1. Je to u n\u00e1s sp\u00ed\u0161e mal\u00e1 funkce.<\/p>\n

<\/p>\n

Rozum\u00edm. D\u011bkuji!<\/em><\/p>\n

<\/p>\n

D\u011bkuji za prezentaci! Velmi zaj\u00edmav\u00e9! Velk\u00e1 ot\u00e1zka. Pl\u00e1nuje se mo\u017en\u00e1 ud\u011blat n\u011bjak\u00e9 zjednodu\u0161en\u00e9 modifikace pro odstra\u0148ov\u00e1n\u00ed dat?<\/em><\/p>\n

<\/p>\n

Ur\u010dit\u011b. To je na\u0161e prvn\u00ed \u00fakol v seznamu. Aktu\u00e1ln\u011b aktivn\u011b p\u0159em\u00fd\u0161l\u00edme, jak v\u0161e ud\u011blat spr\u00e1vn\u011b. A je \u010das za\u010d\u00edt ma\u010dkat kl\u00e1vesnici.<\/p>\n

<\/p>\n

* stiskli jsme kl\u00e1vesy na kl\u00e1vesnici a v\u0161echno ud\u011blali.<\/p>\n

<\/p>\n

Ovlivn\u00ed to n\u011bjak v\u00fdkonnost syst\u00e9mu, nebo ne? Vlo\u017een\u00ed bude stejn\u011b rychl\u00e9, jako je tomu nyn\u00ed?<\/em><\/p>\n

<\/p>\n

Mo\u017en\u00e1, \u017ee samotn\u00e9 mazan\u00ed a aktualizace budou velmi n\u00e1ro\u010dn\u00e9, ale to nijak neovlivn\u00ed v\u00fdkonnost v\u00fdb\u011br\u016f a v\u00fdkonnost vkl\u00e1d\u00e1n\u00ed.<\/p>\n

<\/p>\n

A je\u0161t\u011b jeden mal\u00fd dotaz. Na prezentaci jste mluvili o prim\u00e1rn\u00edm kl\u00ed\u010di. Tedy m\u00e1me parci\u00e1ln\u00ed rozd\u011blen\u00ed, kter\u00e9 je ve v\u00fdchoz\u00edm nastaven\u00ed m\u011bs\u00ed\u010dn\u00ed, \u017ee? A kdy\u017e zad\u00e1me \u010dasov\u00fd rozsah, kter\u00fd se vejde do m\u011bs\u00edce, na\u010dte se jen tato parci\u00e1ln\u00ed \u010d\u00e1st, \u017ee?<\/em><\/p>\n

<\/p>\n

Ano.<\/p>\n

<\/p>\n

Ot\u00e1zka. Pokud nem\u016f\u017eeme vymezit \u017e\u00e1dn\u00fd prim\u00e1rn\u00ed kl\u00ed\u010d, je spr\u00e1vn\u00e9 ud\u011blat jej pr\u00e1v\u011b podle pole 'Datum', aby v pozad\u00ed byla men\u0161\u00ed reorganizace t\u011bchto dat, aby byla uspo\u0159\u00e1d\u00e1na l\u00e9pe? Pokud nem\u00e1te rozsahov\u00e9 dotazy a ani \u017e\u00e1dn\u00fd prim\u00e1rn\u00ed kl\u00ed\u010d nelze vybrat, m\u00e1 smysl vlo\u017eit datum do prim\u00e1rn\u00edho kl\u00ed\u010de?<\/em><\/p>\n

<\/p>\n

Ano.<\/p>\n

<\/p>\n

Mo\u017en\u00e1 d\u00e1v\u00e1 smysl vlo\u017eit do prim\u00e1rn\u00edho kl\u00ed\u010de takov\u00e9 pole, podle kter\u00e9ho se budou data l\u00e9pe komprimovat, pokud budou se\u0159azena podle tohoto pole. Nap\u0159\u00edklad identifik\u00e1tor u\u017eivatele. U\u017eivatel, nap\u0159\u00edklad, nav\u0161t\u011bvuje stejn\u00fd web. V takov\u00e9m p\u0159\u00edpad\u011b vlo\u017ete u\u017eivatelsk\u00e9 ID a \u010das. A pak se v\u00e1m data budou l\u00e9pe komprimovat. Pokud opravdu nem\u00e1te nikdy rozsahov\u00e9 dotazy podle dat, tak datum do prim\u00e1rn\u00edho kl\u00ed\u010de nemus\u00edte d\u00e1vat. <\/p>\n

<\/p>\n

Dob\u0159e, mnohokr\u00e1t d\u011bkuji!<\/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\udd47Efektivn\u00ed vyu\u017eit\u00ed ClickHouse. Alexej Milovidov (Yandex) | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","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\/cs\/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\/cs\/wp-json\/wp\/v2\/posts\/91438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=91438"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/91438\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media\/91439"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=91438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=91438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=91438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}