{"id":74737,"date":"2020-03-20T08:43:14","date_gmt":"2020-03-20T05:43:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa"},"modified":"2020-03-20T08:43:14","modified_gmt":"2020-03-20T05:43:14","slug":"optimizacziya-strok-v-clickhouse-doklad-yandeksa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"A ClickHouse sorainak optimaliz\u00e1l\u00e1sa. El\u0151ad\u00e1s a Yandex-t\u0151l","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A ClickHouse analitikai DBMS k\u00fcl\u00f6nb\u00f6z\u0151 sz\u00f6vegeket dolgoz fel, fogyasztva az er\u0151forr\u00e1sokat. A rendszer teljes\u00edtm\u00e9ny\u00e9nek jav\u00edt\u00e1sa \u00e9rdek\u00e9ben folyamatosan \u00faj optimaliz\u00e1l\u00e1sok ker\u00fclnek bevezet\u00e9sre. A ClickHouse fejleszt\u0151je, Nikolai Kochetov besz\u00e9l az \u00faj sz\u00f6veg adatt\u00edpusr\u00f3l, a LowCardinality-r\u00f3l, \u00e9s elmagyar\u00e1zza, hogyan lehet gyors\u00edtani a sz\u00f6vegekkel val\u00f3 munk\u00e1t. <\/p>\n

\r\n \"Vide\u00f3\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 El\u0151sz\u00f6r n\u00e9zz\u00fck meg, hogyan lehet sz\u00f6vegeket t\u00e1rolni.
\n<\/a><\/noindex>
\n\"A
\n
\nVan n\u00e9h\u00e1ny sz\u00f6veg adatt\u00edpusunk. A String alap\u00e9rtelmez\u00e9s szerint j\u00f3l haszn\u00e1lhat\u00f3, \u00e9rdemes szinte mindig ezt v\u00e1lasztani. Kis Overhead-dal rendelkezik \u2014 9 byte egy sz\u00f6vegre. Ha szeretn\u00e9nk, hogy a sz\u00f6vegek m\u00e9rete fix \u00e9s el\u0151re ismert legyen, akkor a FixedString haszn\u00e1lata a legjobb. Itt megadhatjuk a k\u00edv\u00e1nt byte sz\u00e1mot, ami k\u00e9nyelmes az IP-c\u00edmek vagy hash-funkci\u00f3k eset\u00e9n. <\/p>\n

\"A
\n
\nTerm\u00e9szetesen n\u00e9ha valami lass\u00edt. Tegy\u00fck fel, hogy lek\u00e9rdez\u00e9st v\u00e9gz\u00fcnk egy t\u00e1bl\u00e1zatra. A ClickHouse meglehet\u0151sen nagy mennyis\u00e9g\u0171 adatot olvas, p\u00e9ld\u00e1ul 100 GB\/s sebess\u00e9ggel, de a feldolgozott sorok sz\u00e1ma alacsony. K\u00e9t t\u00e1bl\u00e1nk van, amelyek szinte azonos adatokat t\u00e1rolnak. A ClickHouse a m\u00e1sodik t\u00e1bl\u00e1b\u00f3l gyorsabban olvas adatokat, de m\u00e1sodpercenk\u00e9nt h\u00e1romszor kevesebb sort olvas. <\/p>\n

\"A
\n
\nHa megn\u00e9zz\u00fck a t\u00f6m\u00f6r\u00edtett adatok m\u00e9ret\u00e9t, majdnem egyenl\u0151nek tal\u00e1ljuk. Val\u00f3j\u00e1ban a t\u00e1bl\u00e1kban ugyanazok az adatok vannak r\u00f6gz\u00edtve - az els\u0151 egy milli\u00e1rd sz\u00e1m - csup\u00e1n az els\u0151 oszlopban UInt64-k\u00e9nt, a m\u00e1sodikban pedig String-k\u00e9nt. Ez\u00e9rt a m\u00e1sodik lek\u00e9rdez\u00e9s lassabban olvassa az adatokat a lemezr\u0151l \u00e9s t\u00f6m\u00f6r\u00edti \u0151ket. <\/p>\n

\"A
\n
\nItt van egy m\u00e1sik p\u00e9lda. Tegy\u00fck fel, hogy el\u0151re ismert sz\u00f6vegek halmaz\u00e1val van dolgunk, amelyet egy 1000 vagy 10 000-es konstans hat\u00e1roz meg, \u00e9s gyakorlatilag soha nem v\u00e1ltozik. Ebben az esetben az Enum adatt\u00edpus megfelel\u0151 sz\u00e1munkra, a ClickHouse-ban k\u00e9t fajt\u00e1ja van \u2014 Enum8 \u00e9s Enum16. Az Enum t\u00e1rol\u00e1s\u00e1nak k\u00f6sz\u00f6nhet\u0151en gyorsan dolgozzuk fel a lek\u00e9rdez\u00e9seket. <\/p>\n

A ClickHouse-ban vannak gyors\u00edt\u00e1sok a GROUP BY, IN, DISTINCT parancsokhoz, \u00e9s optimaliz\u00e1l\u00e1sok n\u00e9h\u00e1ny funkci\u00f3hoz, p\u00e9ld\u00e1ul a konstans sz\u00f6vegek \u00f6sszehasonl\u00edt\u00e1s\u00e1hoz. Term\u00e9szetesen a sz\u00e1mokat a sz\u00f6vegben nem alak\u00edtj\u00e1k \u00e1t, hanem \u00e9ppen ellenkez\u0151leg, a konstans sz\u00f6veget Enum \u00e9rt\u00e9kre alak\u00edtj\u00e1k. Ezut\u00e1n minden gyorsan \u00f6sszehasonl\u00edt\u00e1sra ker\u00fcl. <\/p>\n

De h\u00e1tr\u00e1nyok is vannak. M\u00e9g ha tudjuk is a pontos sz\u00f6vegek halmaz\u00e1t, n\u00e9ha azt b\u0151v\u00edteni kell. Ha egy \u00faj sz\u00f6veg \u00e9rkezik \u2014 ALTER-t kell v\u00e9gezn\u00fcnk. <\/p>\n

\"A
\n
\nAz ALTER az Enum eset\u00e9ben a ClickHouse-ban optim\u00e1lisan van megval\u00f3s\u00edtva. Nem \u00edrjuk fel\u00fcl az adatokat a lemezen, de az ALTER lelassulhat, mivel az Enum strukt\u00far\u00e1k a t\u00e1bla s\u00e9m\u00e1j\u00e1ban tal\u00e1lhat\u00f3k. Ez\u00e9rt meg kell v\u00e1rnunk a t\u00e1bla olvas\u00e1si lek\u00e9rdez\u00e9seit, p\u00e9ld\u00e1ul. <\/p>\n

Felmer\u00fcl a k\u00e9rd\u00e9s, lehet-e ezt jobban csin\u00e1lni? Val\u00f3sz\u00edn\u0171leg igen. Az Enum strukt\u00far\u00e1t nem lehetne a t\u00e1bla s\u00e9m\u00e1j\u00e1ban t\u00e1rolni, hanem a ZooKeeper-ben. Azonban szinkroniz\u00e1l\u00e1si probl\u00e9m\u00e1k ad\u00f3dhatnak. P\u00e9ld\u00e1ul, ha az egyik replik megkapta az adatokat, a m\u00e1sik nem, \u00e9s ha annak r\u00e9gi Enum-ja van, akkor valami elromlik. (A ClickHouse-n\u00e1l k\u00f6zel vagyunk a nem blokkol\u00f3 ALTER lek\u00e9rdez\u00e9sek befejez\u00e9s\u00e9hez. Amikor ez teljesen k\u00e9sz van, nem kell majd v\u00e1rni az olvas\u00e1si lek\u00e9rdez\u00e9sekre.)<\/p>\n

\"A
\n
\nAz ALTER Enum kezel\u00e9s\u00e9nek megk\u00f6nny\u00edt\u00e9se \u00e9rdek\u00e9ben haszn\u00e1lhatjuk a ClickHouse k\u00fcls\u0151 sz\u00f3t\u00e1rakat. Eml\u00e9keztetn\u00e9k, hogy ez egy kulcs-\u00e9rt\u00e9k adatszerkezet a ClickHouse-ban, amely lehet\u0151v\u00e9 teszi, hogy adatokat nyerj\u00fcnk ki k\u00fcls\u0151 forr\u00e1sokb\u00f3l, p\u00e9ld\u00e1ul MySQL t\u00e1bl\u00e1kb\u00f3l. <\/p>\n

A ClickHouse sz\u00f3t\u00e1rban sok k\u00fcl\u00f6nb\u00f6z\u0151 karakterl\u00e1ncot t\u00e1rolunk, m\u00edg a t\u00e1bl\u00e1zatban azonos\u00edt\u00f3ikat sz\u00e1mok form\u00e1j\u00e1ban tartjuk. Ha karakterl\u00e1ncot kell kapnunk, a dictGet funkci\u00f3t h\u00edvjuk \u00e9s ezzel dolgozunk. Ezut\u00e1n nem kell ALTER-t v\u00e9grehajtanunk. Ha valamit hozz\u00e1 akarunk adni az Enumhoz, azt ugyanabba a MySQL t\u00e1bl\u00e1ba illesztj\u00fck be. <\/p>\n

De itt m\u00e1s probl\u00e9m\u00e1k mer\u00fclnek fel. El\u0151sz\u00f6r is, a szintaxis nem k\u00e9nyelmes. Ha karakterl\u00e1ncot akarunk kapni, a dictGet-et kell h\u00edvnunk. M\u00e1sodszor, bizonyos optimaliz\u00e1l\u00e1sok hi\u00e1nya. A sz\u00f3t\u00e1rakkal val\u00f3 konstans karakterl\u00e1nccal val\u00f3 \u00f6sszehasonl\u00edt\u00e1s nem olyan gyorsan elv\u00e9gezhet\u0151. <\/p>\n

Friss\u00edt\u00e9si probl\u00e9m\u00e1k is felmer\u00fclhetnek. Tegy\u00fck fel, hogy k\u00e9rj\u00fck a karakterl\u00e1ncot a gyors\u00edt\u00f3t\u00e1razott sz\u00f3t\u00e1rban, de nem ker\u00fclt be a gyors\u00edt\u00f3t\u00e1rba. Akkor v\u00e1rnunk kell, am\u00edg az adatok bet\u00f6lt\u0151dnek a k\u00fcls\u0151 forr\u00e1sb\u00f3l. <\/p>\n

\"A
\n
\nMindk\u00e9t m\u00f3dszer k\u00f6z\u00f6s h\u00e1tr\u00e1nya, hogy minden kulcsot egy helyen t\u00e1rolunk, \u00e9s ezeket szinkroniz\u00e1ljuk. Teh\u00e1t mi\u00e9rt ne t\u00e1roln\u00e1nk a sz\u00f3t\u00e1rakat helyben? Nincs szinkroniz\u00e1l\u00e1s \u2014 nincsenek probl\u00e9m\u00e1k. A sz\u00f3t\u00e1rat helyben lehet t\u00e1rolni egy lemezdarabban. Teh\u00e1t v\u00e9grehajtottuk az Insert parancsot, \u00e9s le\u00edrtuk a sz\u00f3t\u00e1rat. Ha az adatokkal a mem\u00f3ri\u00e1ban dolgozunk, akkor a sz\u00f3t\u00e1rat a blokkokban, a t\u00e1rol\u00f3k egy darabj\u00e1ban, vagy valamilyen gyors\u00edt\u00f3t\u00e1rban is r\u00f6gz\u00edthetj\u00fck, hogy felgyors\u00edtsuk a sz\u00e1m\u00edt\u00e1sokat.<\/p>\n

Karakterl\u00e1ncok k\u00f3dol\u00e1sa sz\u00f3t\u00e1ri form\u00e1ban <\/h3>\n

\n\u00cdgy jutottunk el a ClickHouse \u00faj adatt\u00edpus\u00e1nak megalkot\u00e1s\u00e1hoz \u2014 LowCardinality. Ez az adatok t\u00e1rol\u00e1si form\u00e1tuma: hogyan \u00edrj\u00e1k \u0151ket a lemezre \u00e9s hogyan olvass\u00e1k, hogy mi\u00e9rt vannak a mem\u00f3ri\u00e1ban \u00e9s hogyan t\u00f6rt\u00e9nik a feldolgoz\u00e1suk. <\/p>\n

\"A
\n
\nA di\u00e1n k\u00e9t oszlopot tartalmaz. Jobbra a sorok \u00e1lland\u00f3an String t\u00edpusban t\u00e1rol\u00f3dnak. L\u00e1that\u00f3, hogy ezek mobiltelefon modellek. Balra pontosan ugyanaz az oszlop tal\u00e1lhat\u00f3, csak LowCardinality t\u00edpusban. Ez egy sz\u00f3t\u00e1rb\u00f3l \u00e1ll, amely sok k\u00fcl\u00f6nb\u00f6z\u0151 sort tartalmaz (a jobb oldali oszlop sorai) \u00e9s egy poz\u00edci\u00f3s list\u00e1b\u00f3l (a sorok sz\u00e1ma). <\/p>\n

Ezekkel a k\u00e9t strukt\u00far\u00e1val vissza lehet \u00e1ll\u00edtani az eredeti oszlopot. Van egy visszafel\u00e9 index \u2014 egy hash-t\u00e1bla, amely seg\u00edt a sz\u00f3t\u00e1rban megtal\u00e1lni a poz\u00edci\u00f3t egy sor alapj\u00e1n. Ez a n\u00e9h\u00e1ny lek\u00e9rdez\u00e9s gyors\u00edt\u00e1s\u00e1hoz sz\u00fcks\u00e9ges. P\u00e9ld\u00e1ul, ha \u00f6ssze szeretn\u00e9nk hasonl\u00edtani, keresni szeretn\u00e9nk egy sort a mi oszlopunkban, vagy \u00f6ssze szeretn\u00e9nk vonni \u0151ket. <\/p>\n

A LowCardinality egy param\u00e9terezett adatt\u00edpus. Ez lehet ak\u00e1r sz\u00e1m, ak\u00e1r valami, ami sz\u00e1mk\u00e9nt van t\u00e1rolva, ak\u00e1r sz\u00f6veg, ak\u00e1r Nullable ezekb\u0151l. <\/p>\n

\"A
\n
\nA LowCardinality saj\u00e1toss\u00e1ga, hogy egyes f\u00fcggv\u00e9nyek sz\u00e1m\u00e1ra meg lehet tartani. A di\u00e1n l\u00e1that\u00f3 egy lek\u00e9rdez\u00e9s p\u00e9ld\u00e1ja. Az els\u0151 sorban l\u00e9trehoztam egy LowCardinality t\u00edpust a String-b\u0151l, elneveztem S-nek. Ezut\u00e1n megk\u00e9rdeztem a nev\u00e9t \u2014 a ClickHouse azt mondta, hogy ez LowCardinality a String-b\u0151l. Minden rendben van.<\/p>\n

A harmadik sor szinte ugyanolyan, csak a length f\u00fcggv\u00e9nyt h\u00edvtuk meg. A ClickHouse-ban a length f\u00fcggv\u00e9ny UInt64 adatt\u00edpust ad vissza. De n\u00e1lunk LowCardinality lett az UInt64-b\u0151l. Mi ennek a jelent\u0151s\u00e9ge?<\/p>\n

\"A
\n
\nA sz\u00f3t\u00e1rban mobiltelefonok nevei voltak, alkalmaztuk a length f\u00fcggv\u00e9nyt. Most egy anal\u00f3g sz\u00f3t\u00e1runk lett, amely csak sz\u00e1mokb\u00f3l \u00e1ll \u2014 ezek a sztringek hossza. A poz\u00edci\u00f3s oszlop nem v\u00e1ltozott. V\u00e9g\u00fcl kevesebb adatot dolgoztunk fel, \u00edgy id\u0151t takar\u00edtottunk meg a lek\u00e9rdez\u00e9s sor\u00e1n. <\/p>\n

Lehetnek m\u00e1s optimaliz\u00e1l\u00e1sok is, p\u00e9ld\u00e1ul egy egyszer\u0171 gyors\u00edt\u00f3t\u00e1r hozz\u00e1ad\u00e1sa. A f\u00fcggv\u00e9ny \u00e9rt\u00e9k\u00e9nek kisz\u00e1m\u00edt\u00e1sa sor\u00e1n el lehet rakt\u00e1rozni, \u00e9s egy hasonl\u00f3t \u00f6ssze\u00e1ll\u00edtani an\u00e9lk\u00fcl, hogy \u00fajra kisz\u00e1m\u00edtan\u00e1nk. <\/p>\n

Tov\u00e1bb\u00e1 lehet optimaliz\u00e1lni a GROUP BY-t is, mert a sz\u00f3t\u00e1ros oszlopunk m\u00e1r r\u00e9szlegesen aggreg\u00e1lt \u2014 gyorsabban lehet kisz\u00e1m\u00edtani a hash-f\u00fcggv\u00e9nyek \u00e9rt\u00e9keit, \u00e9s k\u00f6r\u00fclbel\u00fcl meghat\u00e1rozni, hova helyezz\u00fck az \u00faj sort. Tov\u00e1bb\u00e1 n\u00e9h\u00e1ny aggreg\u00e1l\u00f3 f\u00fcggv\u00e9nyt is specializ\u00e1lhatunk, p\u00e9ld\u00e1ul a uniq-ot, mivel csak a sz\u00f3t\u00e1rt lehet elk\u00fcldeni, m\u00edg a poz\u00edci\u00f3k \u00e9rintetlen\u00fcl maradnak \u2014 \u00edgy minden gyorsabban m\u0171k\u00f6dik. Az els\u0151 k\u00e9t optimaliz\u00e1l\u00e1st m\u00e1r hozz\u00e1adtuk a ClickHouse-hoz.<\/p>\n

\"A
\n
\nMi t\u00f6rt\u00e9nik, ha l\u00e9trehozunk egy oszlopot a saj\u00e1t adatt\u00edpusunkkal, \u00e9s sok rossz k\u00fcl\u00f6nb\u00f6z\u0151 sort illeszt\u00fcnk be? Nem fogja t\u00falcsordulni a mem\u00f3ri\u00e1nkat? Nem, erre a ClickHouse-ban k\u00e9t speci\u00e1lis be\u00e1ll\u00edt\u00e1s van. Az els\u0151 a low_cardinality_max_dictionary_size. Ez a diz\u00e1jn maxim\u00e1lis m\u00e9rete, amelyet le lehet \u00edrni a lemezre. Az illeszt\u00e9s a k\u00f6vetkez\u0151k\u00e9ppen t\u00f6rt\u00e9nik: amikor adatokat illeszt\u00fcnk be, egy nagy k\u00f6z\u00f6s sz\u00f3t\u00e1rat alak\u00edtunk ki az \u00e9rkez\u0151 sorokb\u00f3l. Ha a sz\u00f3t\u00e1r m\u00e9rete meghaladja a be\u00e1ll\u00edt\u00e1s \u00e9rt\u00e9k\u00e9t, a jelenlegi sz\u00f3t\u00e1rt le\u00edrjuk a lemezre, m\u00edg a t\u00f6bbi sort valahol \u201eoldalt\u201d t\u00e1roljuk az indexek k\u00f6zel\u00e9ben. V\u00e9g\u00fcl soha nem sz\u00e1moljuk \u00fajra a nagy sz\u00f3t\u00e1rt, teh\u00e1t nem lesznek mem\u00f3ria probl\u00e9m\u00e1ink. <\/p>\n

A m\u00e1sodik be\u00e1ll\u00edt\u00e1st low_cardinality_use_single_dictionary_for_part-nak h\u00edvj\u00e1k. K\u00e9pzelje el, hogy a kor\u00e1bbi s\u00e9m\u00e1ban, amikor adatokat illesztett\u00fcnk be, a sz\u00f3t\u00e1runk t\u00falcsordult, \u00e9s azt le\u00edrtuk a lemezre. Felmer\u00fcl a k\u00e9rd\u00e9s, mi\u00e9rt ne alak\u00edtan\u00e1nk most egy \u00fajabb pontosan olyan sz\u00f3t\u00e1rt? <\/p>\n

Amikor az \u00fajabb t\u00falcsordul, azt ism\u00e9t le\u00edrjuk a lemezre, \u00e9s elkezdj\u00fck a harmadikat kialak\u00edtani. Ez a be\u00e1ll\u00edt\u00e1s alap\u00e9rtelmezetten \u00e9ppen ezt a lehet\u0151s\u00e9get kapcsolja ki. <\/p>\n

Val\u00f3j\u00e1ban sok sz\u00f3t\u00e1r hasznos lehet, ha t\u00f6megesen szeretn\u00e9nk adatokat illeszteni, de v\u00e9letlen\u00fcl \"szem\u00e9t\" adatok ker\u00fclnek be. Mondjuk, el\u0151sz\u00f6r rossz sorokat illesztett\u00fcnk be, majd j\u00f3t. Ekkor a sz\u00f3t\u00e1r sok kis sz\u00f3t\u00e1rra fog oszlani. N\u00e9h\u00e1ny k\u00f6z\u00fcl\u00fck \"szem\u00e9t\" lesz, de az utols\u00f3k j\u00f3 sorokat tartalmaznak. Ha p\u00e9ld\u00e1ul csak az utols\u00f3 granul\u00e1t olvassuk el, akkor minden gyorsan fog m\u0171k\u00f6dni. <\/p>\n

\"A
\n
\nMiel\u0151tt a LowCardinality el\u0151nyeir\u0151l besz\u00e9ln\u00e9nk, azonnal elmondom, hogy val\u00f3sz\u00edn\u0171leg nem fogunk el\u00e9rni lemezter\u00fclet-cs\u00f6kken\u00e9st (b\u00e1r ez megt\u00f6rt\u00e9nhet), mivel a ClickHouse t\u00f6m\u00f6r\u00edti az adatokat. Van egy alap\u00e9rtelmezett opci\u00f3 \u2014 LZ4. Tov\u00e1bb\u00e1 lehets\u00e9ges ZSTD t\u00f6m\u00f6r\u00edt\u00e9st is alkalmazni. De mindk\u00e9t algoritmus m\u00e1r megval\u00f3s\u00edt sz\u00f3t\u00e1ri t\u00f6m\u00f6r\u00edt\u00e9st, teh\u00e1t a mi k\u00fcls\u0151 sz\u00f3t\u00e1runk a ClickHouse-n\u00e1l nem lesz nagy seg\u00edts\u00e9g. <\/p>\n

Annak \u00e9rdek\u00e9ben, hogy ne csak a szavakat haszn\u00e1ljam, n\u00e9h\u00e1ny adatot vettem a metrik\u00e1b\u00f3l - String, LowCardinality(String) \u00e9s Enum - \u00e9s elt\u00e9r\u0151 adatt\u00edpusokba mentettem \u0151ket. H\u00e1rom oszlopot kaptunk, amelyek egy milli\u00e1rd sort tartalmaznak. Az els\u0151 oszlopban, a CodePage-en, mind\u00f6ssze 62 \u00e9rt\u00e9k tal\u00e1lhat\u00f3. L\u00e1that\u00f3, hogy a LowCardinality(String) jobban t\u00f6m\u00f6r\u00edtett. A String kicsit gyeng\u00e9bben, de val\u00f3sz\u00edn\u0171leg az\u00e9rt, mert a karakterl\u00e1ncok r\u00f6videk, t\u00e1roljuk a hossz\u00fas\u00e1gukat, ami sok helyet foglal el, \u00e9s rosszul t\u00f6m\u00f6r\u00fcl. <\/p>\n

Ha megn\u00e9zz\u00fck a PhoneModel-t, azok 48 ezer - m\u00e1r t\u00f6bb, \u00e9s a k\u00fcl\u00f6nbs\u00e9g a String \u00e9s LowCardinality(String) k\u00f6z\u00f6tt szinte \u00e9szrevehetetlen. Az URL eset\u00e9ben is mind\u00f6ssze 2 GB-ot takar\u00edtottunk meg - \u00fagy gondolom, erre nem \u00e9rdemes t\u00e1maszkodni. <\/p>\n

A teljes\u00edtm\u00e9ny\u00e9rt\u00e9kel\u00e9s<\/h3>\n

\n\"A
\nHivatkoz\u00e1s a di\u00e1r\u00f3l<\/a><\/noindex><\/b><\/p>\n

Most \u00e9rt\u00e9kelj\u00fck a teljes\u00edtm\u00e9nyt. Az \u00e9rt\u00e9kel\u00e9shez egy New York-i taxi\u00fatadatb\u00e1zist haszn\u00e1ltam. Ez el\u00e9rhet\u0151<\/a><\/noindex> a GitHub-on tal\u00e1lhat\u00f3. T\u00f6bb mint egy milli\u00e1rd utaz\u00e1st tartalmaz. Mindenben t\u00fckr\u00f6z\u0151dik a helysz\u00edn, az utaz\u00e1s kezd\u00e9si \u00e9s befejez\u00e9si ideje, a fizet\u00e9si m\u00f3d, az utasok sz\u00e1ma, s\u0151t m\u00e9g a taxi t\u00edpusa is - z\u00f6ld, s\u00e1rga \u00e9s Uber. <\/p>\n

\"A
\n
\nAz els\u0151 lek\u00e9rdez\u00e9st meglehet\u0151sen egyszer\u0171re k\u00e9sz\u00edtettem - azt k\u00e9rdeztem, hol rendelik a legt\u00f6bbsz\u00f6r a taxit. Ehhez sz\u00fcks\u00e9ges a helysz\u00edn, ahonnan rendeltek, GROUP BY-t kell v\u00e9gezni, \u00e9s megsz\u00e1molni a count f\u00fcggv\u00e9nyt. Ezzel a ClickHouse valami kiad. <\/p>\n

\"A
\n
\nA lek\u00e9rdez\u00e9s feldolgoz\u00e1si sebess\u00e9g\u00e9nek m\u00e9r\u00e9s\u00e9re h\u00e1rom t\u00e1bl\u00e1t k\u00e9sz\u00edtettem azonos adatokkal, de h\u00e1rom k\u00fcl\u00f6nb\u00f6z\u0151 adatt\u00edpust haszn\u00e1ltam a kiindul\u00e1si helysz\u00edn\u00fcnkh\u00f6z - String, LowCardinality \u00e9s Enum. A LowCardinality \u00e9s az Enum \u00f6tsz\u00f6r gyorsabbnak bizonyult a Stringn\u00e9l. Az Enum gyorsabb, mert sz\u00e1mokkal dolgozik. A LowCardinality pedig az\u00e9rt, mert megval\u00f3s\u00edtott\u00e1k a GROUP BY optimaliz\u00e1l\u00e1st. <\/p>\n

\"A
\n
\nN\u00e9zz\u00fck meg, hogyan bonyol\u00edthatn\u00e1nk a lek\u00e9rdez\u00e9st - k\u00e9rdezz\u00fck meg, hol tal\u00e1lhat\u00f3 a legn\u00e9pszer\u0171bb park New Yorkban. Ism\u00e9t azt m\u00e9rj\u00fck, hol rendelik a legt\u00f6bbet a taxit, de sz\u0171rj\u00fck azokat a helysz\u00edneket, ahol szerepel a \u201epark\u201d sz\u00f3. Ezen k\u00edv\u00fcl hozz\u00e1adunk egy like f\u00fcggv\u00e9nyt. <\/p>\n

\"A
\n
\nMegn\u00e9zz\u00fck az id\u0151t - l\u00e1tjuk, hogy az Enum hirtelen elkezdett lelassulni. R\u00e1ad\u00e1sul m\u00e9g lassabban is m\u0171k\u00f6dik, mint a standard String adatt\u00edpus. Ennek oka, hogy a like f\u00fcggv\u00e9ny egy\u00e1ltal\u00e1n nem optimaliz\u00e1lt az Enum eset\u00e9n. \u00c1talak\u00edtanunk kell a Stringjeinket Enum-b\u00f3l norm\u00e1l String-ekk\u00e9 - t\u00f6bb munk\u00e1t v\u00e9gz\u00fcnk. A LowCardinality(String) alap\u00e9rtelmez\u00e9s szerint szint\u00e9n nem optimaliz\u00e1lt, de ott a like a sz\u00f3t\u00e1ron m\u0171k\u00f6dik, \u00edgy a lek\u00e9rdez\u00e9s felgyorsul a Stringhez k\u00e9pest. <\/p>\n

Az Enum haszn\u00e1latakor egy komolyabb probl\u00e9ma mer\u00fcl fel. Ha optimaliz\u00e1lni akarjuk, azt a k\u00f3d minden hely\u00e9n meg kell tenn\u00fcnk. Tegy\u00fck fel, hogy \u00edrtunk egy \u00faj funkci\u00f3t - felt\u00e9tlen\u00fcl ki kell tal\u00e1lnunk az Enum optimaliz\u00e1l\u00e1s\u00e1t. Ezzel szemben a LowCardinality alap\u00e9rtelmezetten optimaliz\u00e1lva van.<\/p>\n

\"A
\n
\nN\u00e9zz\u00fck meg az utols\u00f3, mesters\u00e9ges p\u00e9ld\u00e1t. Egyszer\u0171en csak kisz\u00e1m\u00edtjuk a hely\u00fcnk hash-funkci\u00f3j\u00e1t. A hash-funkci\u00f3 el\u00e9g lass\u00fa lek\u00e9rdez\u00e9s, sok\u00e1ig tart, ez\u00e9rt minden k\u00f6r\u00fclbel\u00fcl h\u00e1romszor lassabb lesz.<\/p>\n

\"A
\n
\nA LowCardinality m\u00e9g mindig gyorsabb, b\u00e1r itt nincs sz\u0171r\u00e9s. Ez az\u00e9rt van, mert a funkci\u00f3ink csak a sz\u00f3t\u00e1ron dolgoznak. A hash sz\u00e1m\u00edt\u00e1s\u00e1ra vonatkoz\u00f3 funkci\u00f3nak egy argumentuma van - kevesebb adatot tud kezelni, \u00e9s szint\u00e9n vissza tud adni LowCardinality-t. <\/p>\n

\"A
\n
\nGlob\u00e1lis terv\u00fcnk az, hogy a teljes\u00edtm\u00e9ny\u00fcnk b\u00e1rmilyen esetben ne legyen alacsonyabb, mint a String-\u00e9, \u00e9s meg\u0151rizz\u00fck az optimaliz\u00e1l\u00e1sokat. Lehet, hogy egyszer majd a String-et LowCardinality-ra cser\u00e9lj\u00fck, friss\u00edti a ClickHouse-t, \u00e9s minden egy kicsit gyorsabban fog m\u0171k\u00f6dni.
\n
Forr\u00e1s: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438. \u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a ClickHouse \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u041a\u043e\u0447\u0435\u0442\u043e\u0432 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u043e \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043e \u043d\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435, LowCardinality, \u0438 \u043e\u0431\u044a\u044f\u0441\u043d\u044f\u0435\u0442, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043a\u043e\u0440\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043e \u0441\u0442\u0440\u043e\u043a\u0430\u043c\u0438. \u2014 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u0434\u0430\u0432\u0430\u0439\u0442\u0435 \u0440\u0430\u0437\u0431\u0435\u0440\u0435\u043c\u0441\u044f, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u0438. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u044b\u0435 \u0442\u0438\u043f\u044b \u0434\u0430\u043d\u043d\u044b\u0445. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":74738,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-74737","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\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\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47A sz\u00f6vegek optimaliz\u00e1l\u00e1sa a ClickHouse-ban. Yandex el\u0151ad\u00e1s | ProHoster","description":"A ClickHouse analitikai DBMS sz\u00e1mos k\u00fcl\u00f6nb\u00f6z\u0151 sz\u00f6veget dolgoz fel, felhaszn\u00e1lva az er\u0151forr\u00e1sokat. A rendszer teljes\u00edtm\u00e9ny\u00e9nek n\u00f6vel\u00e9se \u00e9rdek\u00e9ben folyamatosan \u00faj optimaliz\u00e1l\u00e1sokat adnak hozz\u00e1.","canonical_url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hu_HU","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\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0442\u0440\u043e\u043a \u0432 ClickHouse. \u0414\u043e\u043a\u043b\u0430\u0434 \u042f\u043d\u0434\u0435\u043a\u0441\u0430 | ProHoster","og:description":"\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","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-03-20T05:43:14+00:00","article:modified_time":"2020-03-20T05:43:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"74737","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 17:23:10","updated":"2022-09-27 14:48:44","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/74737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/comments?post=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hu\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}