{"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\/et\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"Stringide optimeerimine ClickHouse'is. Yandexi ettekandja","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anal\u00fc\u00fctiline andmebaas ClickHouse t\u00f6\u00f6tleb mitmesuguseid stringe, tarbides ressursse. S\u00fcsteemi t\u00f6\u00f6 kiirendamiseks lisatakse pidevalt uusi optimeerimisi. ClickHouse arendaja Nikolai Ko\u010detov r\u00e4\u00e4gib stringi andmet\u00fc\u00fcbist, sealhulgas uuest t\u00fc\u00fcbist LowCardinality, ja selgitab, kuidas stringide t\u00f6\u00f6tlemist kiirendada. <\/p>\n

\r\n \"Vaata\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 Esiteks laskem m\u00f5ista, kuidas stringe salvestada.
\n<\/a><\/noindex>
\n\"Stringide
\n
\nMeil on stringi andmet\u00fc\u00fcbid. String on vaikimisi h\u00e4sti sobiv, seda tasub kasutada peaaegu alati. Sellel on v\u00e4ike Overhead \u2014 9 baiti \u00fche stringi kohta. Kui soovime, et stringide suurus oleks fikseeritud ja eelnevalt teada, tasub kasutada FixedStringi. Sellesse saab m\u00e4\u00e4rata soovitud byte'ide arvu, see on mugav n\u00e4iteks IP-aadresside v\u00f5i hash-funktsioonide jaoks. <\/p>\n

\"Stringide
\n
\nMuidugi aeg-ajalt midagi peatud. Oletame, et teete p\u00e4ringut tabelisse. ClickHouse loeb \u00fcsna suurt hulka andmeid, \u00fctleme kiirusel 100 GB\/s, samas t\u00f6\u00f6tleb see v\u00e4he stringe. Meil on kaks tabelit, mis hoiavad peaaegu sama andmestikku. Teisest tabelist loeb ClickHouse andmeid suurema kiirusena, kuid stringe loetakse kolmandiku v\u00f5rra v\u00e4hem sekundis. <\/p>\n

\"Stringide
\n
\nKui vaatame tihendatud andmete suurust, siis selgub, et see on peaaegu sama. Tegelikult on tabelites kirjas samad andmed \u2014 esimene miljard numbrit \u2014 ainult et esimeses veerus on need kirjutatud vormis UInt64, samas kui teises veerus on need Stringina. Seet\u00f5ttu loetakse teise p\u00e4ringu andmed kettalt kauem ja need dekomprimeeritakse. <\/p>\n

\"Stringide
\n
\nSiin on veel \u00fcks n\u00e4ide. Oletame, et meil on ette teada kindel rida stringe, mis on piiratud konstantsiga 1000 v\u00f5i 10 000 ja peaaegu kunagi ei muutu. Selleks sobib meile andmet\u00fc\u00fcp Enum, ClickHouse'is on neid kaks \u2014 Enum8 ja Enum16. Enum'i salvestamine kiirendab p\u00e4ringute t\u00f6\u00f6tlemist. <\/p>\n

ClickHouse'is on kiirus t\u00e4iendavatele GROUP BY, IN, DISTINCT-le ja optimeerimine teatud funktsioonide jaoks, n\u00e4iteks konstantse stringiga v\u00f5rreldes. Loomulikult ei muundata numbreid stringiks, vaid vastupidi, konstantne string muudetakse Enum'i v\u00e4\u00e4rtuseks. P\u00e4rast seda v\u00f5rdlemine toimub kiiresti. <\/p>\n

Aga on ka miinuseid. Isegi kui me teame t\u00e4pselt rida stringe, peab see m\u00f5nikord t\u00e4iendama. Kui uus string saabus \u2014 peame tegema ALTER. <\/p>\n

\"Stringide
\n
\nALTER Enum ClickHouse'is on optimaalselt rakendatud. Me ei kirjuta andmeid kettale \u00fcmber, kuid ALTER v\u00f5ib veidi venida, kuna Enum'i struktuurid salvestatakse tabeli enda skeemi. Seet\u00f5ttu peame ootama lugemisotsuseid tabelist, n\u00e4iteks. <\/p>\n

Tekkib k\u00fcsimus, kas on v\u00f5imalik paremini teha? T\u00f5en\u00e4oliselt jah. Enum'i struktuuri v\u00f5iks s\u00e4ilitada mitte tabeli skeemis, vaid ZooKeeper'is. Siiski v\u00f5ivad tekkida s\u00fcnkroonimisprobleemid. N\u00e4iteks, kui \u00fcks replika sai andmed, siis teine ei saanud, ja kui tal on vana Enum, siis midagi puruneb. (ClickHouse'is oleme peaaegu l\u00f5petanud mitteblokeerivad ALTER-p\u00e4ringud. Kui me need t\u00e4ielikult l\u00f5petame, ei ole enam vaja oodata lugemisp\u00e4ringuid.)<\/p>\n

\"Stringide
\n
\nKui te ei soovi ALTER Enum'iga tegelda, v\u00f5ite kasutada ClickHouse'i v\u00e4liseid s\u00f5nastikke. Kordan, et see on key-value andmestruktuur ClickHouse'is, mille kaudu saab andmeid v\u00e4liseidest allikatest, n\u00e4iteks MySQL tabelitest. <\/p>\n

ClickHouse'i s\u00f5nastikus hoiame me palju erinevaid ridu, ja tabelis on nende identifikaatorid numbrite kujul. Kui me peame saama rea, kutsume v\u00e4lja funktsiooni dictGet ja t\u00f6\u00f6tame sellega. P\u00e4rast seda ei tohiks me teha ALTERi. Kui soovime Enumisse midagi lisada, sisestame selle samasse MySQL tabelisse. <\/p>\n

Kuid siin tekivad teised probleemid. Esiteks, ebamugav s\u00fcntaks. Kui soovime saada rida, peame kutsuma v\u00e4lja dictGet. Teiseks, teatud optimeerimiste puudumine. Muudatust konstandistringiga s\u00f5nastike jaoks ei saa teha sama kiiresti. <\/p>\n

Samuti v\u00f5ivad tekkida probleemid v\u00e4rskendamisega. Oletame, et k\u00fcsisime rida vahem\u00e4lu s\u00f5nastikus, aga see ei j\u00f5udnud vahem\u00e4llu. Siis peame ootama, kuni andmed v\u00e4lisest allikast laaditakse. <\/p>\n

\"Stringide
\n
\nM\u00f5lema meetodi \u00fcldine puudus on see, et hoiame k\u00f5ik v\u00f5tmed \u00fches kohas ja s\u00fcnkroniseerime need. Miks mitte hoida s\u00f5nastikke kohalikult? Pole s\u00fcnkroniseerimist \u2014 pole probleeme. S\u00f5nastikku saab hoida kohalikult plaadi t\u00fckkide kaupa. Seega teeme Inserti, kirjutame s\u00f5nastiku. Kui t\u00f6\u00f6tame andmetega m\u00e4lu sees, saame s\u00f5nastiku kirja panna kas andmeplokki, veerut\u00fckkidesse v\u00f5i m\u00f5nda vahem\u00e4lu, et arvutusi kiirendada.<\/p>\n

S\u00f5naraamatute kodeerimine <\/h3>\n

\nNii j\u00f5udsime ClickHouse'is uue andmet\u00fc\u00fcbi \u2013 LowCardinality \u2013 loomiseni. See on andmete salvestamise formaat: kuidas need kirjutatakse kettale ja kuidas neid loetakse, kuidas need on m\u00e4lus esindatud ja nende t\u00f6\u00f6tlemise skeem. <\/p>\n

\"Stringide
\n
\nSlaidil on kaks veergu. Paremal on read salvestatud tavalisel viisil, t\u00fc\u00fcbis String. N\u00e4ha on, et need on mingid mobiiltelefonide mudelid. Vasakul on t\u00e4pselt sama veerg, ainult t\u00fc\u00fcbiga LowCardinality. See koosneb s\u00f5nastikust, kus on palju erinevaid reasse (parema veeru read), ja positsioonide loendist (rea numbrid). <\/p>\n

Nende kahe struktuuriga saab taastada algse veeru. Samuti on olemas vastupidine indeks \u2013 rippmen\u00fc\u00fc, mis aitab leida rea positsiooni s\u00f5nastikus. Seda vajatakse m\u00f5nede p\u00e4ringute kiirendamiseks. N\u00e4iteks, kui soovime v\u00f5rrelda, otsida rida meie veerus v\u00f5i neid omavahel \u00fchendada. <\/p>\n

LowCardinality on parameetriline andmet\u00fc\u00fcp. See v\u00f5ib olla kas number, midagi, mis salvestatakse numbrina, rida v\u00f5i nende Nullable variant. <\/p>\n

\"Stringide
\n
\nLowCardinality'i eelis on see, et see v\u00f5ib salvestuda teatud funktsioonide jaoks. Slidil on n\u00e4ide p\u00e4ringust. Esimeses reas l\u00f5in LowCardinality t\u00fc\u00fcpi veeru String'ist, nimetasime selle S-ks. Siis k\u00fcsisin selle nime \u2014 ClickHouse \u00fctles, et see on LowCardinality String'ist. K\u00f5ik on korras.<\/p>\n

Kolmas rida on peaaegu sama, lihtsalt kutsusime v\u00e4lja length funktsiooni. ClickHouse'is tagastab length funktsioon andmet\u00fc\u00fcbi UInt64. Kuid n\u00fc\u00fcd saime LowCardinality UInt64. Mis selle t\u00e4hendus on?<\/p>\n

\"Stringide
\n
\nS\u00f5nastikus olid mobiiltelefonide nimed, rakendasime length funktsiooni. N\u00fc\u00fcd on meil sarnane s\u00f5naraamat, mis koosneb ainult numbritest \u2014 need on stringide pikkused. Positsioonide veerg ei ole muutunud. L\u00f5ppkokkuv\u00f5ttes t\u00f6\u00f6tasime v\u00e4hemate andmetega, s\u00e4\u00e4stsime p\u00e4ringu ajas. <\/p>\n

V\u00f5ivad olla ka teised optimeerimised, n\u00e4iteks lihtsa vahem\u00e4lu lisamine. Funktsiooni v\u00e4\u00e4rtuse arvutamisel saab selle m\u00e4letada ja koostada sama, mitte arvutada uuesti. <\/p>\n

Samuti saab GROUP BY optimeerida, kuna meie s\u00f5nastiku veerg on juba osaliselt koondatud \u2014 h\u00e4shtfunktsioonide v\u00e4\u00e4rtusi saab kiiremini arvutada ja umbkaudu leida bucket, kuhu j\u00e4rgmine rida paigutada. Samuti on v\u00f5imalik spetsialiseerida m\u00f5ningaid agregaatfunktsioone, n\u00e4iteks uniq, sest sellesse saab saata ainult s\u00f5nastiku, j\u00e4ttes positsioonid puutumatuks \u2014 nii t\u00f6\u00f6tab k\u00f5ik kiiremini. Need kaks optimeerimist on me juba ClickHouse'i lisanud.<\/p>\n

\"Stringide
\n
\nEnt mis saab siis, kui loome veeru meie andmet\u00fc\u00fcbiga ja sisestame sellesse palju halbu erinevaid ridu? Kas meie m\u00e4lu ei \u00fcletata? Ei, ClickHouse'is on selleks kaks spetsiaalset seadet. Esimene on low_cardinality_max_dictionary_size. See on maksimaalne s\u00f5nastiku suurus, mis saab kettale salvestada. Sisestamine toimub j\u00e4rgmiselt: kui me andmeid sisestame, tuleb meile ridade voog, millest me kujundame suure \u00fchis s\u00f5nastiku. Kui s\u00f5nastik muutub suuremaks kui seadistuse v\u00e4\u00e4rtus, salvestame praeguse s\u00f5nastiku kettale, samal ajal kui \u00fclej\u00e4\u00e4nud read \u2014 j\u00e4\u00e4vad kuhugi \u201ek\u00f5rvale\u201c, indeksite k\u00f5rvale. L\u00f5pptulemusena ei arvuta me kunagi suurt s\u00f5nastikku uuesti ja ei saa m\u00e4lu probleemidega kokku. <\/p>\n

Teine seadistus kannab nime low_cardinality_use_single_dictionary_for_part. Kujutage ette, et eelmisel skeemil, kui me andmeid sisestasime, meie s\u00f5nastik \u00fcletas piiri ja me salvestasime selle kettale. K\u00fcsimus on, miks mitte luua n\u00fc\u00fcd veel \u00fcks t\u00e4iesti sama s\u00f5nastik? <\/p>\n

Kui see j\u00e4lle \u00fcle voolab, salvestame selle uuesti kettale ja hakkame kolmandat looma. See seadistus l\u00fclitab selle v\u00f5imaluse vaikeolekus v\u00e4lja. <\/p>\n

Tegelikult v\u00f5ivad palju s\u00f5nastikke olla kasulikud, kui me tahame sisestada mingit rida, kuid juhuslikult sisestame \"pr\u00fcgi\". \u00dctleme, et k\u00f5igepealt sisestasime halvad read ja siis head. Siis jaguneb s\u00f5nastik paljudeks v\u00e4ikesteks s\u00f5nastikeks. Osad neist sisaldavad \"pr\u00fcgi\", kuid viimased sisaldavad h\u00e4id ridu. Ja kui me lugedes, \u00fctleme, ainult viimast granulaati, t\u00f6\u00f6tab k\u00f5ik ka kiiresti. <\/p>\n

\"Stringide
\n
\nEnne kui r\u00e4\u00e4gime LowCardinality eeliste kohta, \u00fctlen kohe, et t\u00f5en\u00e4oliselt ei suuda me andmeid ketast v\u00e4hendada (kuigi see v\u00f5ib juhtuda), sest ClickHouse tihendab andmeid. Vaikimisi on olemas variant \u2014 LZ4. Samuti saab kasutada ZSTD tihendust. Kuid m\u00f5lemad algoritmid rakendavad juba s\u00f5naraamiga tihendust, seega meie v\u00e4line s\u00f5naraamat ClickHouse'is ei aita eriti. <\/p>\n

Kuna ma ei soovi olla p\u00f5hjendamatu, v\u00f5tsin m\u00f5ned andmed metrikast \u2014 String, LowCardinality(String) ja Enum \u2014 ning salvestasin need erinevatesse andmet\u00fc\u00fcpidesse. Saime kolm veergu, kus on \u00fcks miljard rida. Esimeses veerus, CodePage, on kokku 62 v\u00e4\u00e4rtust. Ja on n\u00e4ha, et LowCardinality(String) tihendas neid paremini. String on veidi halvem, kuid see on t\u00f5en\u00e4oliselt tingitud sellest, et read on l\u00fchikesed, me hoiame nende pikkusi ja need v\u00f5tavad palju ruumi, halvemini tihendatud. <\/p>\n

Kui v\u00f5tta PhoneModel, siis neid on 48 tuhat \u2014 juba rohkem, ja erinevused String ja LowCardinality(String) vahel on peaaegu olematud. URL-ide puhul s\u00e4\u00e4stsime samuti vaid 2 GB \u2014 arvan, et sellele ei tohiks toetuda. <\/p>\n

T\u00f6\u00f6kiirus hindamine<\/h3>\n

\n\"Stringide
\nViide slaidilt<\/a><\/noindex><\/b><\/p>\n

N\u00fc\u00fcd hindame t\u00f6\u00f6kiirust. Selle hindamiseks kasutasin New Yorgi taksireiside andmestikku. saadaval<\/a><\/noindex> GitHubis. Seal on veidi \u00fcle miljardi s\u00f5idu. Seal on n\u00e4idatud asukoht, s\u00f5idu algus- ja l\u00f5ppaeg, makseviis, reisijate arv ja isegi takso t\u00fc\u00fcp \u2014 roheline, kollane ja Uber. <\/p>\n

\"Stringide
\n
\nEsimene p\u00e4ring, mille ma tegin, oli \u00fcsna lihtne \u2014 k\u00fcsisin, kust sagedamini taksot tellitakse. Selleks tuleb v\u00f5tta asukoht, kust takso telliti, kasutada GROUP BY-d ja lugeda funktsiooni count. ClickHouse annab midagi. <\/p>\n

\"Stringide
\n
\nK\u00fcsimuse t\u00f6\u00f6tlemise kiirusest m\u00f5\u00f5tmiseks l\u00f5in kolm tabelit \u00fchesuguste andmetega, kuid kasutasin meie algasukoha jaoks kolme erinevat andmet\u00fc\u00fcpi \u2014 String, LowCardinality ja Enum. LowCardinality ja Enum osutusid viiekordselt kiiremaks kui String. Enum on kiirem, sest t\u00f6\u00f6tab numbritega. LowCardinality on samuti efektiivne, kuna on rakendatud GROUP BY optimeerimist. <\/p>\n

\"Stringide
\n
\nTeeme p\u00e4ringu veel keerulisemaks \u2014 k\u00fcsime, kus asub k\u00f5ige populaarsem park New Yorgis. J\u00e4llegi m\u00f5\u00f5dame seda selle j\u00e4rgi, kus sagedamini taksosid tellitakse, kuid filtreerime v\u00e4lja ainult need asukohad, kus on s\u00f5na \u201epark\u201c. Lisame ka funktsiooni like. <\/p>\n

\"Stringide
\n
\nVaadates aega, n\u00e4eme, et Enum on \u00e4kitselt hakanud aeglustuma. Tegelikult t\u00f6\u00f6tab see isegi aeglasemalt kui tavaline String andmet\u00fc\u00fcp. See juhtub, kuna funktsioon like ei ole Enum-i jaoks \u00fcldse optimeeritud. Peame meie enum stringid tavalistesse stringidesse konverteerima \u2014 see t\u00e4hendab, et teeme rohkem t\u00f6\u00f6d. LowCardinality(String) ei ole ka vaikimisi optimeeritud, kuid seal toimub like s\u00f5nastiku peal, seega kiireneb p\u00e4ring v\u00f5rreldes Stringiga. <\/p>\n

Enumiga t\u00f6\u00f6tamisel on veelgi globaalne probleem. Kui me tahame seda optimeerida, peame seda tegema igas koodikohas. Oletame, et oleme kirjutanud uue funktsiooni \u2014 peame kindlasti leidma optimeerimise Enum-i jaoks. LowCardinality on aga k\u00f5ik vaikimisi optimeeritud.<\/p>\n

\"Stringide
\n
\nVaadakem viimast p\u00e4ringut, mis on kunstlikum. Arvutame lihtsalt meie asukoha hash-funktsiooni. Hash-funktsioon \u2014 \u00fcsna aeglane p\u00e4ring, seda arvutatakse pikka aega, seega k\u00f5ik aeglustub umbes kolm korda.<\/p>\n

\"Stringide
\n
\nLowCardinality t\u00f6\u00f6tab endiselt kiiremini, kuigi siin ei ole filtreerimist. See juhtub, kuna meie funktsioonid t\u00f6\u00f6tavad ainult s\u00f5nastiku peal. Hash-funktsioonil on \u00fcks argument \u2014 see saab t\u00f6\u00f6delda v\u00e4hem andmeid ja samuti v\u00f5ib tagastada LowCardinality. <\/p>\n

\"Stringide
\n
\nMeie globaalne plaan on saavutada t\u00f6\u00f6kiirus, mis ei oleks madalam kui String igas olukorras, ja s\u00e4ilitada kiirus. Ja v\u00f5ib-olla asendame kunagi Stringi LowCardinality'ga, te uuendate ClickHouse'i ja teil hakkab k\u00f5ik natuke kiiremini toimima.
\n
Allikas: 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\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\udd47Stringide optimeerimine ClickHouse'is. \u042f\u043d\u0434\u0435\u043a\u0441\u0430 ettekande | ProHoster","description":"Anal\u00fc\u00fctiline andmebaas ClickHouse t\u00f6\u00f6tleb palju erinevaid stringe, tarbides ressursse. S\u00fcsteemi t\u00f6\u00f6 kiirus on pidevalt optimeerimisega paranenud. ClickHouse'i arendaja Nikolai Kochetov r\u00e4\u00e4gib stringi andmetest, sealhulgas uuest t\u00fc\u00fcbist, LowCardinality, ning selgitab, kuidas saab stringide t\u00f6\u00f6tlemist kiirendada. \u2014 Esiteks m\u00f5istame, kuidas saame stringe salvestada. Meil on stringi andmet\u00fc\u00fcbid.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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. \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.","og:url":"https:\/\/prohoster.info\/et\/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"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/74737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}