{"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":"Strings optimisation in ClickHouse. Yandex report","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Anal\u00fc\u00fctiline andmebaas ClickHouse t\u00f6\u00f6tleb erinevaid stringe, tarbides ressursse. S\u00fcsteemi t\u00f6\u00f6 kiirus on pidevalt paranenud t\u00e4nu uutele optimeerimistele. ClickHouse arendaja Nikolai Ko\u010detov r\u00e4\u00e4gib andmet\u00fc\u00fcbist string, sealhulgas uuest t\u00fc\u00fcbist LowCardinality, ja selgitab, kuidas kiirendada t\u00f6\u00f6d stringidega. <\/p>\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 Alustame sellest, kuidas stringe salvestada.
\n<\/a><\/noindex>
\n\"Strings
\n
\nMeil on stringi andmet\u00fc\u00fcbid. String sobib vaikimisi v\u00e4ga h\u00e4sti ja seda tuleks kasutada peaaegu alati. Sellel on v\u00e4ike overhead \u2014 9 baiti \u00fche stringi kohta. Kui soovime, et stringide suurus oleks fikseeritud ja eelnevalt teada, on parem kasutada FixedString. Sellesse saab m\u00e4\u00e4rata vajaliku bitti arvu, see sobib IP-aadresside v\u00f5i hash-funktsioonide jaoks. <\/p>\n

\"Strings
\n
\nLoomulikult v\u00f5ib m\u00f5nikord miski pidurdada. Oletame, et teete p\u00e4ringu tabelisse. ClickHouse loeb \u00fcsna suurt andmemassi, \u00fctleme kiirusel 100 GB\/s, samas stringe t\u00f6\u00f6deldakse v\u00e4he. Meil on kaks tabelit, mis sisaldavad peaaegu samu andmeid. Teisest tabelist loeb ClickHouse andmeid suurema kiirusel, kuid stringide arvu loetakse kolm korda v\u00e4hem sekundis. <\/p>\n

\"Strings
\n
\nKui vaatame kokku surutud andmete suurust, selgub, et see on peaaegu sama. Tegelikult on tabelites salvestatud samad andmed \u2014 esimesed miljard numbrit \u2014 lihtsalt esimeses veerus on nad salvestatud UInt64 kujul, teises aga String. Sel p\u00f5hjusel loetakse teises p\u00e4ringus andmed ketas pikemalt ja neid dekompressitakse. <\/p>\n

\"Strings
\n
\nSiin on teine n\u00e4ide. Oletame, et on eelnevalt teadaolev hulk stringe, mis on piiratud konstantsusega 1000 v\u00f5i 10 000 ning praktiliselt kunagi ei muutu. Selle juhtumi jaoks sobib meile andmet\u00fc\u00fcp Enum, ClickHouse'is on neid kaks \u2014 Enum8 ja Enum16. Enum'st hoidmise t\u00f5ttu t\u00f6\u00f6tleme p\u00e4ringuid kiiresti. <\/p>\n

ClickHouse'is on kiirus t\u00e4iustused GROUP BY, IN, DISTINCT ja optimeerimised teatud funktsioonide jaoks, n\u00e4iteks fikseeritud stringiga v\u00f5rdlemiseks. Loomulikult ei muundata stringi numbreid, vaid vastupidi, fikseeritud string muudetakse Enum v\u00e4\u00e4rtuseks. P\u00e4rast seda v\u00f5rreldakse k\u00f5ike kiiresti. <\/p>\n

Kuid on ka miinuseid. Isegi kui me teame stringide t\u00e4pset hulka, peab see m\u00f5nikord t\u00e4iendama. Kui uus string tuleb, peame tegema ALTER. <\/p>\n

\"Strings
\n
\nALTER Enumi ClickHouse on optimaalne. Me ei kirjutame andmeid ketasse, kuid ALTER v\u00f5ib aeglustuda, kuna Enum struktuurid on salvestatud tabeli endasse. Seet\u00f5ttu peame ootama lugemis \u0437\u0430\u043f\u0440\u043e\u0441\u044b tabelist, n\u00e4iteks. <\/p>\n

K\u00fcsimus on, kas seda saab paremaks teha? T\u00f5en\u00e4oliselt jah. Enum struktuuri v\u00f5ib salvestada mitte tabeli skeemi, vaid ZooKeeperisse. Kuid v\u00f5ivad tekkida s\u00fcnkroniseerimisega seotud probleemid. N\u00e4iteks v\u00f5ib \u00fcks replik saada andmed, teine mitte, ja kui sellel on vana Enum, siis midagi l\u00e4heb katki. (ClickHouse'is oleme peaaegu l\u00f5petanud blokeerimata ALTER p\u00e4ringud. Kui saame need t\u00e4ielikult valmis, ei pea ootama lugemis \u0437\u0430\u043f\u0440\u043e\u0441\u044b.)<\/p>\n

\"Strings
\n
\nALTER Enumiga vaevlemise v\u00e4ltimiseks saab kasutada ClickHouse'i v\u00e4liseid s\u00f5nastikke. Tuletan meelde, et see on key-value andmestruktuur ClickHouse'is, mille abil saab andmeid v\u00e4lisest allikast, n\u00e4iteks MySQL tabelitest. <\/p>\n

ClickHouse'i s\u00f5nastikus hoiame mitmeid erinevaid stringe, ja tabelis on nende identifikaatorid numbrite kujul. Kui peame saama stringi, kutsume v\u00e4lja dictGet funktsiooni ja t\u00f6\u00f6tame sellega. Seej\u00e4rel ei pea me tegema ALTER't. Kui midagi on Enumisse lisada, siis sisestame selle samasse MySQL tabelisse. <\/p>\n

Kuid siin kerkivad esile teised probleemid. Esiteks, ebamugav s\u00fcntaks. Kui soovime saada stringi, peame kutsuma dictGet'i. Teiseks, teatud optimeerimiste puudumine. Konstantse stringiga v\u00f5rdlemine s\u00f5nastikes ei ole nii kiire. <\/p>\n

Samuti v\u00f5ivad esineda probleemid v\u00e4rskendamisega. Oletame, et k\u00fcsisime stringi vahek\u00e4es\u00f5nastikust, kuid see ei j\u00f5udnud vahek\u00e4esse. Siis peame ootama, kuni andmed v\u00e4lisest allikast laaditakse. <\/p>\n

\"Strings
\n
\nM\u00f5lema meetodi \u00fcldine puudus on see, et hoiame k\u00f5ik v\u00f5tmed \u00fches kohas ja s\u00fcnkroniseerime neid. Nii et miks mitte hoida s\u00f5nastikke kohalikult? Pole s\u00fcnkroniseerimist \u2014 pole probleeme. S\u00f5nastikku saab hoida lokaalselt ketta t\u00fckis. See t\u00e4hendab, et tegime Insert, salvestasime s\u00f5nastiku. Kui t\u00f6\u00f6tame andmetega m\u00e4lus, v\u00f5ime salvestada s\u00f5nastiku kas andmeplokki, veeru t\u00fcki v\u00f5i m\u00f5nda muu vahem\u00e4lu, et arvutusi kiirendada.<\/p>\n

Stringide s\u00f5nastikukood <\/h3>\n

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

\"Strings
\n
\nSlaidil on kaks veergu. Paremal pool hoitakse read standardses vormingus, String t\u00fc\u00fcpi. Selgelt on n\u00e4ha, et need on teatud mobiiltelefonide mudelid. Vasakul on t\u00e4pselt sama veerg, kuid LowCardinality t\u00fc\u00fcbis. See koosneb s\u00f5nastikust, kus on palju erinevaid stringe (paremal pool olevate veergude stringid) ja positsioonide nimekirjast (rea numbrid). <\/p>\n

Nende kahe struktuuri abil on v\u00f5imalik taastada algne veerg. Samuti on olemas tagurpidi indeks \u2014 hash-tabel, mis aitab leida rea positsiooni s\u00f5nastikus. See on vajalik teatud p\u00e4ringute kiirendamiseks. N\u00e4iteks, kui tahame 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, string v\u00f5i nende Nullable variant. <\/p>\n

\"Strings
\n
\nLowCardinality erip\u00e4ra on see, et see v\u00f5ib m\u00f5nedes funktsioonides salvestuda. Slaidil on n\u00e4ha p\u00e4ringu n\u00e4ide. Esimeses reas l\u00f5in LowCardinality String t\u00fc\u00fcbiga veeru ja nimetasime selle S-ks. Seej\u00e4rel k\u00fcsisin selle nime \u2014 ClickHouse \u00fctles, et see on LowCardinality String. K\u00f5ik on \u00f5ige.<\/p>\n

Kolmas rida on peaaegu sama, aga oleme kutsunud v\u00e4lja length funktsiooni. ClickHouse'is tagastab length funktsioon andmet\u00fc\u00fcbi UInt64. Kuid meil on saanud LowCardinality UInt64. Mis on selle m\u00f5te?<\/p>\n

\"Strings
\n
\nS\u00f5nastikus olid mobiiltelefonide nimed, rakendasime length funktsiooni. N\u00fc\u00fcd on meil sarnane s\u00f5nastik, mis koosneb ainult numbritest \u2014 need on stringide pikkused. Positsioonide veerg ei ole muutunud. L\u00f5ppkokkuv\u00f5ttes t\u00f6\u00f6tlesime v\u00e4hem andmeid, s\u00e4\u00e4stsime p\u00e4ringu aega. <\/p>\n

V\u00f5ivad olla ka teised optimeerimised, n\u00e4iteks lihtsa vahem\u00e4lu lisamine. Funktsiooni v\u00e4\u00e4rtuse arvutamisel on v\u00f5imalik see meelde j\u00e4tta ja luua sarnane, mitte arvutada uuesti. <\/p>\n

Samuti v\u00f5ib olla tehtud GROUP BY optimeerimine, sest meie s\u00f5nastiku veerg on juba osaliselt agreggeeritud \u2014 h\u00e4shefunktsiooni v\u00e4\u00e4rtuste arvutamine ja sobiva bucket'i leidmine j\u00e4rgmise rea jaoks on kiirem. Samuti saab spetsialiseerida m\u00f5ningaid agregaatfunktsioone, n\u00e4iteks uniq, kuna sellesse saab saata ainult s\u00f5nastiku, samas kui positsioonid j\u00e4\u00e4vad puutumatuks \u2014 siis t\u00f6\u00f6tab k\u00f5ik kiiremini. Esimesed kaks optimeerimist oleme juba ClickHouse'i lisanud.<\/p>\n

\"Strings
\n
\nEnt\u00e4, jos luomme sarakkeen omalle datatyypillemme ja sy\u00f6t\u00e4mme siihen paljon erilaisia huonoja merkkijonoja? Eik\u00f6 meid\u00e4n muistimme lopu? Ei, ClickHouse:ssa on t\u00e4h\u00e4n kaksi erityist\u00e4 asetusta. Ensimm\u00e4inen on low_cardinality_max_dictionary_size. T\u00e4m\u00e4 on sanakirjan maksimikoko, joka voidaan tallentaa levylle. Tietojen sy\u00f6tt\u00e4minen tapahtuu n\u00e4in: kun sy\u00f6t\u00e4mme tietoja, saamme virran merkkijonoja, joista muodostamme suuren yhteisen sanakirjan. Jos sanakirja kasvaa suuremmaksi kuin asetuksen arvo, tallennamme nykyisen sanakirjan levylle ja muut merkkijonot johonkin 'sivulle', indeksien viereen. T\u00e4ten emme koskaan laske suurta sanakirjaa uudelleen emmek\u00e4 kohtaa muistiongelmia. <\/p>\n

Toinen asetus on nimelt\u00e4\u00e4n low_cardinality_use_single_dictionary_for_part. Kuvittele, ett\u00e4 edellisess\u00e4 schema:ssa, kun sy\u00f6timme tietoja, sanakirjamme t\u00e4yttyi ja tallensimme sen levylle. Her\u00e4\u00e4 kysymys, miksi emme nyt voisi luoda viel\u00e4 yht\u00e4 samanlaista sanakirjaa? <\/p>\n

Kun se t\u00e4yttyy, tallennamme sen taas levylle ja aloitamme kolmannen sanakirjan muodostamisen. T\u00e4m\u00e4 asetus est\u00e4\u00e4 juuri t\u00e4m\u00e4n mahdollisuuden oletusarvoisesti. <\/p>\n

Itse asiassa monet sanakirjat voivat olla hy\u00f6dyllisi\u00e4, jos haluamme sy\u00f6tt\u00e4\u00e4 tietyn m\u00e4\u00e4r\u00e4n merkkijonoja, mutta vahingossa sy\u00f6timme 'roskaa'. Sanotaan, ett\u00e4 ensin sy\u00f6timme huonoja merkkijonoja ja sitten hyvi\u00e4. T\u00e4ll\u00f6in sanakirja jakautuu moneen pieneen sanakirjaan. Osa niist\u00e4 sis\u00e4lt\u00e4\u00e4 'roskaa', mutta viimeiset sis\u00e4lt\u00e4v\u00e4t hyvi\u00e4 merkkijonoja. Ja jos luemme vain viimeist\u00e4 fragmenttia, kaikki toimii nopeasti. <\/p>\n

\"Strings
\n
\nEnnen kuin puhumme LowCardinality:n eduista, sanon heti, ett\u00e4 tuskin saamme aikaan v\u00e4hennyst\u00e4 tiedoissa levyll\u00e4 (vaikka se voi tapahtua), koska ClickHouse pakkaa tiedot. On oletusvaihtoehto \u2014 LZ4. Voimme my\u00f6s pakata ZSTD:n avulla. Mutta molemmat algoritmit toteuttavat jo sanakirjapakkausta, joten ulkoinen sanakirjamme ClickHouse:ssa ei ole kovin hy\u00f6dyllinen. <\/p>\n

Kuna ei taha olla s\u00f5naline, t\u00f5in m\u00f5ned andmed metrikast \u2014 String, LowCardinality(String) ja Enum \u2014 ning salvestasin need erinevatesse andmet\u00fc\u00fcpidesse. Saime kolm veergu, kus on kirjas miljard rida. Esimeses veerus, CodePage, on kokku 62 v\u00e4\u00e4rtust. On n\u00e4ha, et LowCardinality(String) komprimeeris need paremini. Stringi tulemus on veidi kehvem, kuid see on t\u00f5en\u00e4oliselt tingitud l\u00fchikestest ridadest; me salvestame nende pikkusi ja need v\u00f5tavad palju ruumi, seega komprimeeruvad halvasti. <\/p>\n

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

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

\n\"Strings
\nLink slaidilt<\/a><\/noindex><\/b><\/p>\n

N\u00fc\u00fcd hindame t\u00f6\u00f6kiirus. Selle hindamiseks kasutasin taksireiside andmestikku New Yorgis. See saadaval<\/a><\/noindex> on GitHubis. Andmestikus on veidi \u00fcle miljardi reisi. Seal on kajastatud asukoht, s\u00f5iduki algus- ja l\u00f5ppaeg, makseviis, reisijate arv ja isegi taksot\u00fc\u00fcp \u2014 roheline, kollane ja Uber. <\/p>\n

\"Strings
\n
\nTegin esimese p\u00e4ringu \u00fcsna lihtsaks \u2014 k\u00fcsisin, kust tellitakse k\u00f5ige rohkem taksosid. Selleks oli vaja v\u00f5tta asukoht, kust taksot telliti, teha selle p\u00f5hjal GROUP BY ja lugeda count-funktsiooni. Siin on ClickHouse midagi v\u00e4lja andnud. <\/p>\n

\"Strings
\n
\nK\u00fcsimise t\u00f6\u00f6tlemise kiirusest m\u00f5\u00f5tmiseks l\u00f5in kolm tabelit, kus on samad andmed, kuid kasutasin meie algasukoha jaoks kolme erinevat andmet\u00fc\u00fcpi \u2014 String, LowCardinality ja Enum. LowCardinality ja Enum osutusid viis korda kiiremateks kui String. Enum on kiire, kuna t\u00f6\u00f6tab numbritega. LowCardinality on kiire, kuna realizatsioon on optimeeritud GROUP BY jaoks. <\/p>\n

\"Strings
\n
\nKomplektime p\u00e4ringut veelgi keerulisemaks \u2014 k\u00fcsime, kus asub New Yorgi k\u00f5ige populaarsem park. Taaskord m\u00f5\u00f5dame seda selle p\u00f5hjal, kust taksosid k\u00f5ige sagedamini tellitakse, kuid filtrime ainult need asukohad, kus on s\u00f5na \"park\". Samuti lisame funktsiooni like. <\/p>\n

\"Strings
\n
\nVaadates aega \u2014 n\u00e4eme, et Enum hakkas ootamatult aeglustuma. T\u00f5si, see t\u00f6\u00f6tab isegi aeglasemalt kui tavaline andmet\u00fc\u00fcp String. See juhtub seet\u00f5ttu, et funktsioon like ei ole Enum'i jaoks \u00fcldse optimeeritud. Peame muundama meie Enum'i stringid tavalisteks stringideks \u2014 teeme rohkem t\u00f6\u00f6d. LowCardinality(String) ei ole ka vaikimisi optimeeritud, kuid seal t\u00f6\u00f6tab like s\u00f5naraamatute kallal, seet\u00f5ttu kiireneb p\u00e4ring v\u00f5rreldes Stringiga. <\/p>\n

Enumiga t\u00f6\u00f6tamisel on \u00fcks suurem probleem. Kui me soovime seda optimeerida, peame seda tegema igas koodikohtas. Oletame, et oleme kirjutanud uue funktsiooni \u2014 peame kindlasti v\u00e4lja m\u00f5tlema Enum'i optimeerimise. Madala kardinaalsusega on k\u00f5ik vaikimisi optimeeritud.<\/p>\n

\"Strings
\n
\nVaatame viimast p\u00e4ringut, mis on rohkem kunstlik. Me lihtsalt arvutame meie asukoha hash-funktsiooni. Hash-funktsioon on \u00fcsna aeglane p\u00e4ring, see v\u00f5tab kaua aega, seega k\u00f5ik aeglustub kolm korda.<\/p>\n

\"Strings
\n
\nMadala kardinaalsusega t\u00f6\u00f6tab endiselt kiiremini, kuigi siin ei ole filtreerimist. See juhtub seet\u00f5ttu, et meie funktsioonid t\u00f6\u00f6tavad ainult s\u00f5nastiku \u00fcle. Hash-funktsiooni arvutamise funktsioonil on \u00fcks argument \u2014 see saab t\u00f6\u00f6delda v\u00e4hem andmeid ja v\u00f5ib samuti tagastada madala kardinaalsuse. <\/p>\n

\"Strings
\n
\nMeie globaalne plaan on saavutada kiirus, mis pole madalam kui String igas olukorras, ja s\u00e4ilitada kiirus. Ja v\u00f5ib-olla asendame mingi p\u00e4ev String'i madala kardinaalsusega, v\u00e4rskendate ClickHouse'i ja k\u00f5ik t\u00f6\u00f6tab natuke kiiremini.
\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. Yandexi ettekande esitamine | ProHoster","description":"Anal\u00fc\u00fctiline andmebaas ClickHouse k\u00e4sitleb palju erinevaid stringe, tarbides ressursse. S\u00fcsteemi t\u00f6\u00f6 kiirusel suurendamiseks lisatakse pidevalt uusi optimeerimise v\u00f5imalusi.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}