{"id":80775,"date":"2020-05-08T13:42:47","date_gmt":"2020-05-08T11:42:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah"},"modified":"2020-05-08T13:42:47","modified_gmt":"2020-05-08T11:42:47","slug":"clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse for advanced users in questions and answers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Aprillis kavatsevad Avito insenerid korraldada veebikohtumised ClickHouse'i peaarendaja Aleksei Milovidovi ja Golangi arendaja Kirill Shvakoviga ettev\u00f5ttest Integros. Arutatakse, kuidas me andmebaasi halduss\u00fcsteemi kasutame ja millised raskused meil tekivad. <\/p>\n<p><\/p>\n<p>Kuna kohtumise teemade p\u00f5hjal koondasime artikli ekspertide vastustega meie ja vaatajate k\u00fcsimustele varukoopiate, andmete reshardingu, v\u00e4liste s\u00f5nastike, Golangi draiveri ja ClickHouse'i versioonide uuendamise kohta. See v\u00f5ib olla kasulik arendajatele, kes juba aktiivselt t\u00f6\u00f6tavad Yandexi andmebaasiga ja huvituvad selle olevikust ja tulevikust. Alati on Aleksei Milovidovi vastused, kui ei ole m\u00e4rgitud teisiti. <\/p>\n<p><\/p>\n<p>Olge ettevaatlik, allpool on palju teksti. Loodame, et k\u00fcsimustega sisu aitab teil orienteeruda.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse for advanced users in questions and answers\" src=\"\/wp-content\/uploads\/2020\/05\/242b1d8d002fe115614435c242297fd2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"soderzhanie\">Sisukord<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse pidevalt uuendatakse, aga meie andmed ei ole. Mida sellega teha?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Millised on hetkel parimad praktikad ClickHouse'i andmete varundamiseks?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">Kas replikate kontrollitud mahaj\u00e4\u00e4must on v\u00f5imalik korraldada repliikides?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">Mida teha, kui tabeli struktuur on muutunud?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Millised on praegu parimad praktikad andmete reshardingu osas?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">ClickHouse'is on t\u00f6\u00f6riist clickhouse-copier. Kas saaksite sellest r\u00e4\u00e4kida?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Teie k\u00e4es oli katseprojekt, mis kandis nime resharding. Kuidas on selle k\u00e4ek\u00e4ik?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">Kas on v\u00f5imalik k\u00f5ik andmeosad enne aeglastele ketastele liikumist kokku sulatada?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Kuidas liikuda uusimatele ClickHouse'i versioonidele, kui ei ole v\u00f5imalik eelnevalt \u00fchilduvust kontrollida?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">Kill query peab tapma p\u00e4ringuid, kuid see ei toimi. Miks?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Kuidas arvutada vastamise aega lugemise koormuse korral?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Mida peab ClickHouse'is timmima, et rohkem andmeid oleks vahemikus?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Kuidas saab seadistada storage_configuration t\u00f6\u00f6tamise eesm\u00e4rgil?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Kuni millise unikaalsete v\u00e4\u00e4rtuste arvuni on Low Cardinality efektiivne?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Millised on parimad praktikad t\u00e4isteksti otsimise korral, kui tabelis on viis miljardit rida?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Kuidas korraldada ClickHouse'i juurdep\u00e4\u00e4s suurele kasutajate arvule?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">Kas on v\u00f5imalik edastada \u00fche p\u00e4ringu tulemused k\u00fcmnele kliendile?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Kuidas k\u00e4ituda as\u00fcnkroonsete operatsioonide ja materialiseeritud vaadete puhul?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">ClickHouse'is on palju logisid. Kuidas n\u00e4ha k\u00f5ike, mis serveris hetkel toimub?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Kuidas m\u00f5jutada merge protsesse, et server ei kukuks v\u00e4lja OOM-i t\u00f5ttu?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Kuidas toimub Golangi draiveri arendamine ClickHouse'i jaoks?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">V\u00e4line s\u00f5nastik ei t\u00f5use p\u00e4rast taask\u00e4ivitamist ja lazy_load seade on sisse l\u00fclitatud. Mida teha?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Kuidas k\u00e4ituda olukorras, kus system reload dictionaries ei lae \u00fchtki paljusid s\u00f5nastikke, kui v\u00e4hemalt \u00fcks neist kukub error'iga?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Kas on v\u00f5imalik konfigureerida ClickHouse'i s\u00e4tteid, kuid mitte n\u00e4idata neid vigu korral?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Boonus: taustad Zoomi koosolekute jaoks<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Kui te ei soovi teksti lugeda, v\u00f5ite vaadata koosolekute salvestust <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">meie YouTube'i kanalis<\/a><\/noindex>. Aegkoodid - esimeses kommentaaris video all.<\/p><\/blockquote>\n<p><\/p>\n<h2 id=\"anchorold-dataanchorclickhouse-postoyanno-obnovlyaetsya-a-nashi-dannyenbsp-net-chto-snbspetim-delat\"><noindex><a rel=\"nofollow\" name=\"old-data\"><\/a><\/noindex>ClickHouse uuendab pidevalt, kuid meie andmed ei uuene. Mida sellega teha?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse uuendab pidevalt, kuid meie andmed, mis olid optimeeritud, ei uuene ja j\u00e4\u00e4vad varukoopia peale. <\/p>\n<p>Eeldame, et meil on tekkinud mingi probleem ja andmed on kadunud. Otsustasime taastuda ja selgus, et vanad partiid, mis on salvestatud varundusse, divergeerivad v\u00e4ga tugevalt selle ClickHouse'i versiooniga, mida praegu kasutame. Mida sellises olukorras teha, ja kas see on v\u00f5imalik?<\/p><\/blockquote>\n<p>Situatsioon, kus olete andmed varukoopiast taastanud vanas formaadis, kuid uuel versioonil need ei \u00fchendu, ei ole v\u00f5imalik. Me j\u00e4lgime, et andmeformaat ClickHouse'is j\u00e4\u00e4ks alati tagasip\u00f6\u00f6rdumisv\u00f5imetuks. See on palju olulisem kui tagasip\u00f6\u00f6rdumisv\u00f5ime funktsionaalsuse osas, kui mingis harva kasutatavas funktsioonis on k\u00e4itumine muutunud. Uus ClickHouse'i versioon peab alati suutma lugeda plaadil hoidvaid andmeid. See on reegel. <\/p>\n<p><\/p>\n<h2 id=\"anchorbackup-best-practiciesanchorkakie-luchshie-praktiki-est-nanbspdannyy-moment-ponbsprezervnomu-kopirovaniyu-dannyh-iznbspclickhouse\"><noindex><a rel=\"nofollow\" name=\"backup-best-practicies\"><\/a><\/noindex>Millised on hetkel parimad praktikad ClickHouse'i andmete varundamiseks?<\/h2>\n<p><\/p>\n<blockquote><p>Kuidas teha varukoopiaid, arvestades, et meil on optimeerimise l\u00f5ppoperatsioone, tohutu andmebaas terabaitides ning andmed, mis uuenevad, eeldame, et viimase kolme p\u00e4eva jooksul, ja edaspidi nende \u00fcle ei toimu \u00fchtegi protseduuri? <\/p>\n<p>Me v\u00f5ime luua oma lahenduse ja skriptides kirjutada: kogu need varukoopiad kokku. V\u00f5ib-olla ei ole vaja midagi skriptida ja jalgratas on juba leiutatud? <\/p><\/blockquote>\n<p>Esiteks parimate praktikate osas. Minu kolleegid soovitavad alati vastuseks varukoopiate k\u00fcsimusele meenutada teenust \u201eYandex.Cloud\u201d, kus see \u00fclesanne on juba lahendatud. Nii et kasutage seda, kui on selline v\u00f5imalus. <\/p>\n<p><\/p>\n<p>T\u00e4ielikku lahendust, mis on 100% sisse ehitatud ClickHouse'i, varukoopiate jaoks ei ole. On m\u00f5ned malli, mida saab kasutada. T\u00e4ieliku lahenduse saamiseks tuleb kas natuke k\u00e4sitsi vaeva n\u00e4ha v\u00f5i luua skriptide kujul \u00fcmbrised.<\/p>\n<p><\/p>\n<p>Alustan k\u00f5ige lihtsamate lahendustega ja l\u00f5petan k\u00f5ige keerulisematega, s\u00f5ltuvalt andmete mahust ja klusteri suurusest. Mida suurem klaster, seda keerulisemaks lahendus muutub.<\/p>\n<p><\/p>\n<p>Kui andmetabel v\u00f5tab vaid m\u00f5ned gigabait, saab varukoopia teha j\u00e4rgmiselt: <\/p>\n<p><\/p>\n<ol>\n<li>Salvesta tabelite m\u00e4\u00e4ratlemine, st metaandmed \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Tehke dump ClickHouse kliendi abil \u2014 <strong>select<\/strong> * <strong>from table<\/strong> faili. Vaikimisi saate faili TabSeparated formaadis. Kui soovite t\u00f5husamat lahendust, siis v\u00f5ite valida Native formaadi. <\/li>\n<\/ol>\n<p><\/p>\n<p>Kui andmemahu suurus on suurem, siis varukoopia tegemine kestab kauem ja v\u00f5tab rohkem ruumi. Seda nimetatakse loogiliseks varukoopiaks, see ei ole seotud ClickHouse andmeformaatidega. Kui see on olemas, saate \u00e4\u00e4rmisel juhul varukoopia v\u00f5tta ja laadida selle MySQL-i taastamiseks. <\/p>\n<p><\/p>\n<p>Kuna ClickHouse'is on olemas keerukamate juhtumite jaoks v\u00f5imalus luua partitsioonide snapshot kohalikku faili s\u00fcsteemi. See v\u00f5imalus on saadaval p\u00e4ringuna <strong>alter table freeze partition<\/strong>. V\u00f5i lihtsalt <strong>alter table freeze<\/strong> \u2014 see on kogu tabeli snapshot. <\/p>\n<p><\/p>\n<p>Snapshot luuakse \u00fchel shard'il \u00fche tabeli jaoks koosk\u00f5las, seega on sellisel viisil kogu klustri konsistentse snapshot'i loomine v\u00f5imatu. Kuid enamikuks \u00fclesannetest ei ole selline vajadus ja piisab, kui iga shard'i jaoks p\u00e4ring teha ja saada konsistentne snapshot. See luuakse k\u00f5vaketashalduse kaudu ja seet\u00f5ttu ei v\u00f5ta see t\u00e4iendavat ruumi. Seej\u00e4rel kopeerite selle snapshot'i varukoopia serverisse v\u00f5i ladustamisse, mida kasutate varukoopiate tegemiseks.<\/p>\n<p><\/p>\n<p>Sellise varukoopia taastamine on \u00fcsna lihtne. Esimene samm \u2014 looge tabelid olemasolevate tabeli m\u00e4\u00e4ratlustega. Seej\u00e4rel koopiate salvestatud partitsioonide snapshot'id Directory-Detached andmete jaoks ja sooritate p\u00e4ringu <strong>attach partition<\/strong>. Selline lahendus sobib t\u00e4iesti suuremates andmemahudes. <\/p>\n<p><\/p>\n<p>M\u00f5nikord on vaja midagi veelgi \u00e4gedamat \u2014 sellistel juhtudel, kui teil on k\u00fcmneid v\u00f5i isegi sadu terabaite igal serveril ja sadu servereid. Siin on lahendus, mille ma m\u00e4rkasin kolleegidelt \u00abYandex.Metrika\u00bb juurest. Ma ei soovitaks seda iga\u00fchele \u2014 lugege ja otsustage ise, kas see sobib v\u00f5i mitte. <\/p>\n<p><\/p>\n<p>Esiteks peate looma mitu serverit suurte ketta riiulitega. Seej\u00e4rel peate nendel serveritel k\u00e4ivitama mitu ClickHouse serverit ja seadistama need nii, et need t\u00f6\u00f6taksid nagu veel \u00fcks koopiate jaoks samade shardide puhul. Edasi, kasutage nendel serveritel failis\u00fcsteemi v\u00f5i m\u00f5nda t\u00f6\u00f6riista, mis v\u00f5imaldab luua snapshots. Siin on kaks varianti. Esimene variant on LVM snapshotid, teine variant on ZFS Linuxis. <\/p>\n<p><\/p>\n<p>P\u00e4rast seda tuleb iga p\u00e4ev luua snapshot, mis j\u00e4\u00e4b ja v\u00f5tab mingit ruumi. Loomulikult, kui andmed muutuvad, siis aja jooksul ruumi maht suureneb. Seda snapshot'i saab igal ajal v\u00e4lja v\u00f5tta ja andmeid taastada, selline kummaline lahendus. Pluss on veel see, et tuleb piirata neid koopiaid konfiguratsioonis, et nad ei p\u00fc\u00fcaks saada liidriteks.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>Kas replikate kontrollitud mahaj\u00e4\u00e4must on v\u00f5imalik korraldada repliikides?<\/h2>\n<p><\/p>\n<blockquote><p>Sel aastal plaanite teha vallo ClickHouse'is. Kas on v\u00f5imalik selles korraldada kontrollitud koopiate mahaj\u00e4\u00e4mus? Soovime selle abil end kaitsta negatiivsete stsenaariumite eest alternatiivide ja muude muudatuste osas. <\/p>\n<p>Kas on v\u00f5imalik teha mingeid tagasiviimise v\u00f5imalusi alternatiivide jaoks? N\u00e4iteks v\u00f5tta olemasolevas vallas ja \u00f6elda, et kuni selle hetkeni rakendage muudatusi, ja sellest hetkest alates l\u00f5petage muudatuste rakendamine?<\/p>\n<p>Kui meie klastrisse tuleb r\u00fchm ja rikub selle, siis meil on tingimuslik koopiate mahaj\u00e4\u00e4mus tunni v\u00f5rra, kus me saame \u00f6elda, et kasutame hetkel just seda, kuid viimase k\u00fcmne minuti muudatusi ei rakenda? <\/p><\/blockquote>\n<p>Alustuseks kontrollitud koopiate mahaj\u00e4\u00e4musest. Selline p\u00e4ring kasutajatelt oli, ja me l\u00f5ime GitHubis teema palvega: 'Kui kellelegi see vajalik, palun pange like, pange s\u00fcda'. Keegi ei pannud, ja teema suleti. Sellegipoolest, juba praegu on v\u00f5imalik saada selline v\u00f5imalus, seadistades ClickHouse'i. T\u00f5si, ainult alates versioonist 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse teeb pidevalt taustal andmete \u00fchinemist\u2014mergi. Kui sulandumine on toimunud, asendatakse teatud andmeosade komplekt suurema t\u00fckkiga. Sellega seoses j\u00e4\u00e4vad varem olnud andmeosad kettale teatud ajaks alles.<\/p>\n<p><\/p>\n<p>Esiteks, need j\u00e4\u00e4vad alles seni, kuni on olemas select p\u00e4ringud, mis neid kasutavad, et tagada mitteblokeeriv t\u00f6\u00f6. Select p\u00e4ringud loevad rahulikult vanadest t\u00fckkidest.<\/p>\n<p><\/p>\n<p>Teiseks, on olemas ka ajapiirang - vanad andmeosad on ketas kaheksa minutit. Need kaheksa minutit on seadistatavad ja neid saab isegi \u00fcheks p\u00e4evaks muuta. See maksab koht ketas: andmevoo s\u00f5ltuvalt v\u00f5ib juhtuda, et viimase p\u00e4eva andmed mitte ainult ei kahekordistu, vaid neid v\u00f5ib olla viis korda rohkem. Kuid t\u00f5sise probleemi korral saate ClickHouse serveri peatada ja k\u00f5igega tegeleda.<\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd tekib k\u00fcsimus, kuidas see kaitseb altrite eest. Siin tasub s\u00fcveneda, sest vanemates ClickHouse versioonides t\u00f6\u00f6tas alter nii, et see lihtsalt vahetas osi. On olemas andmeosa koos failidega, ja me teeme n\u00e4iteks, <strong>alter drop column<\/strong>. Siis see veerg eemaldatakse f\u00fc\u00fcsiliselt k\u00f5ikidest osadest.<\/p>\n<p><\/p>\n<p>Kuid alates versioonist 20.3 on alterite mehhanism t\u00e4ielikult muutunud ning n\u00fc\u00fcd on andmeosad alatiimmutablid. Need ei muutu \u00fcldse - alterid toimivad n\u00fc\u00fcd umbes nagu merge'id. Selle asemel, et muuta osa kohapeal, loome uue. Uues osas, mis ei ole muutunud, muutuvad failid k\u00f5vaks lingiks ja kui me oleme eemaldanud m\u00f5ne veeru, siis see lihtsalt ei ole uues osas. Vana osa eemaldatakse vaikimisi kaheksa minuti p\u00e4rast ning siin saab seadeid \u00fclaltoodud seadistuste j\u00e4rgi kohandada. <\/p>\n<p><\/p>\n<p>Sama kehtib ka alterite kohta, mis on seotud mutatsioonidega. Kui teete <strong>alter delete<\/strong> v\u00f5i <strong>alter update<\/strong>, siis see ei muuda plokki, vaid loob uue. Ja siis eemaldab vana.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>Mida teha, kui tabeli struktuur on muutunud?<\/h2>\n<p><\/p>\n<blockquote><p>Kuidas taastada varukoopia, mis tehti vana skeemiga? Ja teine k\u00fcsimus puudutab juhtumit, kus on snapshots ja failis\u00fcsteemi t\u00f6\u00f6riistad. Kas Btrfs sobib siin ZFS asemel Linuxi LVM-iga?<\/p><\/blockquote>\n<p>Kui teete <strong>attach partition<\/strong> erineva struktuuriga partitsioonid \u00fctlevad teile, et seda ei saa teha. Lahendus on j\u00e4rgmine. Esiteks - luua ajutine MergeTree t\u00fc\u00fcp tabel vana struktuuriga, siduda sinna andmed attach abil, teha alter p\u00e4ring. Siis saab kas kopeerida v\u00f5i need andmed \u00fcle kanda ja taas attach teha, v\u00f5i kasutada p\u00e4ringut. <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd on teine k\u00fcsimus \u2014 kas Btrfs-i on v\u00f5imalik kasutada. Esiteks, kui teil on LVM, siis piisab LVM-i snapshot'itest ja failis\u00fcsteemiks v\u00f5ib olla ext4, see ei oma t\u00e4htsust. Btrfs-i puhul s\u00f5ltub k\u00f5ik teie kogemusest selle kasutamisel. See on k\u00fcps failis\u00fcsteem, kuid siiski on teatud kahtlused selle toimivuses praktikas konkreetses stsenaariumis. Ma ei soovitaks seda kasutada, kui teil ei ole Btrfs-i tootmises.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-best-practicesanchorkakie-seychas-luchshie-praktiki-vnbspreshardinge-dannyh\"><noindex><a rel=\"nofollow\" name=\"resharding-best-practices\"><\/a><\/noindex>Millised on praegu parimad praktikad andmete reshardingu osas?<\/h2>\n<p><\/p>\n<p>K\u00fcsimus \u00fcmbershardimisest on keeruline ja mitmekesine. Siin saab vastata mitmeti. \u00dchest k\u00fcljest v\u00f5ib \u00f6elda, et ClickHouse'is ei ole sisseehitatud v\u00f5imalust \u00fcmbershardimiseks. Kuid ma kardan, et see vastus ei rahulda kedagi. Seet\u00f5ttu saab teiselt poolt \u00f6elda, et ClickHouse'is on palju v\u00f5imalusi andmete \u00fcmbershardimiseks. <\/p>\n<p><\/p>\n<p>Kui klastris hakkab koht otsa saama v\u00f5i see ei suuda koormusega toime tulla, lisate uusi servereid. Kuid need serverid on vaikimisi t\u00fchjad, andmeid neil ei ole, koormust ei ole. Teil tuleb andmed \u00fcmber jagada, et need saaksid uues, suuremas klastris \u00fchtlaselt jaotatud.<\/p>\n<p><\/p>\n<p>Esimene viis, kuidas seda saab teha, on kopeerida osa partiidest uutele serveritele p\u00e4ringute abil. <strong>alter table fetch partition<\/strong>N\u00e4iteks, kui teil olid partiid kuude kaupa, siis v\u00f5tate esimese kuu 2017. aastast ja kopeerite selle uuele serverile, seej\u00e4rel kopeerite kolmanda kuu m\u00f5nda muusse uude serverisse. Ja teete seda, kuni see muutub enam-v\u00e4hem \u00fchtlaseks.<\/p>\n<p><\/p>\n<p>\u00dcmberpaigutamine on v\u00f5imalik ainult nende partiide puhul, mis ei muutu kirjutamisel. Uute partiide jaoks tuleb kirjutamine peatada, kuna nende teisaldamine ei ole aatomaarne. Vastasel juhul saate andmetes dubleerimise v\u00f5i puuduvad andmed. Siiski on see meetod praktiline ja t\u00f6\u00f6tab piisavalt t\u00f5husalt. V\u00f5rgus edastatakse juba valmis kokku surutud partiid, st andmeid ei suruta kokku ega kodeerita uuesti.<\/p>\n<p><\/p>\n<p>Selle meetodil on \u00fcks puudus, mis s\u00f5ltub shardimisest, kas te olete selle sharding'i skeemi peale panustanud ja milline oli teie shardimisv\u00f5ti. Teie n\u00e4ites on selle juhtumi jaoks sharding'i v\u00f5ti tee hash. Kui teete select Distributed tabelisse, siis l\u00e4heb see kohe k\u00f5igile klastrite shardidele ja toob sealt andmed. <\/p>\n<p><\/p>\n<p>See t\u00e4hendab, et tegelikult pole teil t\u00e4htis, millised andmed millisel shardil asuvad. Peamine on see, et andmed \u00fche tee j\u00e4rgi asuvad \u00fchel shardil, kuid millisel t\u00e4pselt, pole oluline. Sellisel juhul sobib valmis partitsioonide edasiviimine suurep\u00e4raselt, kuna select p\u00e4ringute korral saate te ka enne sharding'ut kui p\u00e4rast, skeem v\u00e4\u00e4rtused ei oma erilist t\u00e4htsust \u2014 t\u00e4ielikud andmed.<\/p>\n<p><\/p>\n<p>Siiski on ka keerulisemaid juhtumeid. Kui rakenduse loogika tasemel on teil eriline shardimise skeem, et see klient asub teatud shardil ja p\u00e4ring saab saata kohe sinna, mitte Distributed tabelisse. V\u00f5i kasutate te piisavalt uut versiooni ClickHouse'ist ja olete lubanud seade. <strong>optimize skip unused shards<\/strong>. Sellisel juhul anal\u00fc\u00fcsitakse p\u00e4ringu select ajal where sektsioonis avaldist ning arvutatakse v\u00e4lja, millised shardid tuleb minna vastavalt shardimis skeemile. See t\u00f6\u00f6tab eeldusel, et andmed on jaotatud just selle shardimis skeemi kohaselt. Kui olete need k\u00e4sitsi \u00fcmber pannud, v\u00f5ib vastavus muutuda.<\/p>\n<p><\/p>\n<p>Nii et see on esimene meetod. Ootan teie vastust, kas see sobib, v\u00f5i liigume edasi.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, juhtiv s\u00fcsteemiadministraator Avitos<\/strong>: Aleksei, see meetod, mille te mainisite, ei sobi eriti h\u00e4sti koormuse hajutamiseks, sealhulgas lugemise osas. Saame v\u00f5tta kuupartitsiooni ja saame eelmist kuud viia teisele s\u00f5lmele, kuid kui p\u00e4ring tuleb nende andmete j\u00e4rele, koormame ainult seda. Aga tahaksime koormata kogu klastrit, sest vastasel juhul on m\u00f5nda aega kogu lugemise koormus kahest shardist.<\/p>\n<p><\/p>\n<p><strong>Aleksei Milovidov:<\/strong> Vastus siin on kummaline \u2014 jah, see on halb, kuid v\u00f5ib ka toimida. Selgitan, kuidas t\u00e4pselt. Tuleb vaadata koormuse stsenaariumi, mis toimub teie andmete taga. Kui need on j\u00e4lgimisandmed, siis peaaegu kindlasti saab \u00f6elda, et \u00fclekaalukalt enamiku p\u00e4ringutest langetatakse v\u00e4rskete andmete j\u00e4rgi. <\/p>\n<p><\/p>\n<p>Te olete seadnud uued serverid, migreenud vanad partitsioonid, kuid olete ka muutnud seda, kuidas v\u00e4rskeid andmeid salvestatakse. V\u00e4rsked andmed jaotatakse kogu klastrisse. Nii et juba viie minutiga koormavad p\u00e4ringud viimase viie minuti kohta \u00fchtlaselt klastrit, p\u00e4evaga koormavad p\u00e4ringud p\u00e4eva kohta \u00fchtlaselt klastrit. Kahjuks l\u00e4hevad aga eelneva kuu p\u00e4ringud ainult osa klastriserveritest.<\/p>\n<p><\/p>\n<p>Kuid tihti ei pruugi teil olla p\u00e4ringuid just 2019. aasta veebruari kohta. T\u00f5en\u00e4oliselt, kui p\u00e4ringud toimuvad 2019. aastal, siis need on kogu 2019. aasta kohta \u2014 pika ajavahemiku kohta, mitte mingi v\u00e4ikese vahemiku kohta. Sellised p\u00e4ringud suudavad samuti klastrit \u00fchtlaselt koormata. Kuid \u00fcldiselt on teie m\u00e4rkus t\u00e4iesti \u00f5ige, et see on ad hoc lahendus, mis ei jaota andmeid t\u00e4iesti \u00fchtlaselt.<\/p>\n<p><\/p>\n<p>Mul on veel m\u00f5ned punktid, millega vastata k\u00fcsimusele. \u00dcks neist on see, kuidas algselt luua shardimise skeem, et \u00fcleminek tagasi-shardimisele oleks v\u00e4hem valus. See ei ole alati v\u00f5imalik.<\/p>\n<p><\/p>\n<p>N\u00e4iteks, teil on j\u00e4lgimisandmed. J\u00e4lgimisandmed kasvavad kolmel p\u00f5hjusel. Esiteks \u2014 ajalooliste andmete kogunemine. Teiseks \u2014 liikluse kasv. Ja kolmandaks \u2014 j\u00e4lgimise alla kuuluvate asjade arvu suurenemine. Tekivad uued mikroteenused ja m\u00f5\u00f5dikud, mida tuleb salvestada. <\/p>\n<p><\/p>\n<p>V\u00f5ib-olla on nende seas suurim kasv seotud just kolmanda p\u00f5hjusega \u2014 see on j\u00e4lgimise kasutamise suurenemine. Ja sel juhul tasub uurida koormuse iseloomu, millised on peamised p\u00e4ringud select. Peamised p\u00e4ringud select, t\u00f5en\u00e4oliselt, l\u00e4hevad m\u00f5nele alamkogumile m\u00f5\u00f5dikutest.<\/p>\n<p><\/p>\n<p>N\u00e4iteks, CPU kasutamine teatud serverites teatud teenuse poolt. Tulemuseks on teatud alamkogum v\u00f5tmeid, mille kaudu te need andmed k\u00e4tte saate. Ja p\u00e4ring nende andmete jaoks on t\u00f5en\u00e4oliselt piisavalt lihtne ja t\u00e4idetakse k\u00fcmnete millisekundite jooksul. Kasutatakse j\u00e4lgimisteenustes, armatuurlaudades. Loodan, et ma m\u00f5istan seda \u00f5igesti.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> As a matter of fact, we frequently refer to historical data, as we compare the current situation in real-time with historical data. It is important for us to have quick access to a large volume of data, and ClickHouse handles this excellently.<\/p>\n<p><\/p>\n<p>You are absolutely right; we experience most read requests in the last day, just like any monitoring system. However, there is also a significant load on the historical data. This mainly comes from the alerting system, which queries ClickHouse every thirty seconds, asking, 'Give me data for the last six weeks. Now build me some kind of moving average from it, and let\u2019s compare the current value with the historical one.' <\/p>\n<p><\/p>\n<p>I would like to mention that we have a smaller table for such very recent queries, where we store only two days of data, and the main requests are directed to it. We only send large historical queries to the big sharded table.<\/p>\n<p><\/p>\n<p><strong>Aleksei Milovidov:<\/strong> Unfortunately, it is not applicable for your scenario, but I will describe two bad and complex sharding schemes that should not be used but are used in my friends' service. <\/p>\n<p><\/p>\n<p>There is a main cluster with events from 'Yandex.Metrica'. Events include page views, clicks, and transitions. Most of the requests are directed to a specific website. You open the 'Yandex.Metrica' service, you have a site \u2014 avito.ru, go to the report, and the request is made for your site.<\/p>\n<p><\/p>\n<p>But there are also other requests \u2014 analytical and global, which are made by internal analysts. Just for the record, internal analysts only make requests for 'Yandex' services. However, even 'Yandex' services account for a significant share of all data. These are not requests for specific counters, but for broader filtering.<\/p>\n<p><\/p>\n<p>How to organize the data in such a way that it works efficiently for a single counter as well as for global requests? The complexity also lies in the fact that the number of requests in ClickHouse for the 'Metrics' cluster is several thousand per second. At the same time, non-trivial queries, for example, several thousand per second, cannot be handled by one ClickHouse server.<\/p>\n<p><\/p>\n<p>Klastri suurus on umbes kuussada serverit. Kui sellele klastrile lihtsalt rakendada jaotatud tabelit ja suunata sinna mitu tuhat p\u00e4ringut, siis oleks see isegi halvem kui nende saatmine \u00fchele serverile. Teisest k\u00fcljest, kui andmed on \u00fchtlaselt jaotatud ja me k\u00fclastame ning p\u00e4rime k\u00f5igilt serveritelt, siis see variant langeb kohe v\u00e4lja.<\/p>\n<p><\/p>\n<p>On ka t\u00e4iesti vastupidine variant. Kujutage ette, kui me jaotame andmed saitide kaupa, ja \u00fche saidi p\u00e4ring suundub \u00fchele shardile. N\u00fc\u00fcd suudab klaster t\u00f5epoolest taluda k\u00fcmme tuhat p\u00e4ringut sekundis, kuid \u00fchel shardil v\u00f5ib m\u00f5ni p\u00e4ring t\u00f6\u00f6tada liiga aeglaselt. See ei saa enam skaleeruda l\u00e4bilaskev\u00f5ime osas. Eriti kui tegemist on saidiga avito.ru. Ma ei avalda saladust, kui \u00fctlen, et Avito on \u00fcks k\u00f5ige k\u00fclastatumaid saite Venemaal. Ja selle t\u00f6\u00f6tlemine \u00fchel shardil oleks pigem hullus.<\/p>\n<p><\/p>\n<p>Seet\u00f5ttu on shardimise skeem kavandatud nutikamalt. Kogu klaster on jagatud mitmeks v\u00e4iksemaks klastriks, mida me nimetame kihtideks. Iga klastrikihi sees on tosin kuni mituk\u00fcmmend shard'i. Klastrike on kokku kolmk\u00fcmmend \u00fcheksa. <\/p>\n<p><\/p>\n<p>Kuidas see k\u00f5ik skaleerub? Klastrite arv ei muutu \u2014 nagu see oli paar aastat tagasi kolmk\u00fcmmend \u00fcheksa, on see endiselt sama. Kuid iga\u00fches neist suurendame j\u00e4rk-j\u00e4rgult shard'ide arvu andmete kogunemise k\u00e4igus. Ja shardimise skeem on selline \u2014 jagamine nende klastrite vahel toimub veebisaitide alusel ning selleks, et aru saada, milline sait kuulub millisele klastrile, kasutatakse t\u00e4iesti eraldi metabaasi MySQL-is. \u00dcks sait \u2014 \u00fches klastris. Ja selle sees toimub shardimine k\u00fclastajate identifikaatorite alusel.<\/p>\n<p><\/p>\n<p>Salvestamisel jagame neid k\u00fclastaja identifikaatori j\u00e4\u00e4gi j\u00e4rgi. Kuid kui lisame uue shard'i, muutub sharding'i skeem, me j\u00e4tkame jagamist, kuid j\u00e4\u00e4gi j\u00e4rgi teise numbri j\u00e4rgi. See t\u00e4hendab, et \u00fcks k\u00fclastaja on siiski jaotatud mitmele serverile, ja sellesse ei saa lootma j\u00e4\u00e4da. See on tehtud ainult selleks, et andmed paremini kokku suruda. P\u00e4ringute korral l\u00e4heme Distributed tabelisse, mis vaatab klastrit ja p\u00f6\u00f6rdub k\u00fcmnete serverite poole. Selline naljakas skeem.<\/p>\n<p><\/p>\n<p>Kuid minu jutt j\u00e4\u00e4b poolikuks, kui ma ei \u00fctle, et sellest skeemist oleme loobunud. Uues skeemis oleme k\u00f5ik muutnud ja k\u00f5ik andmed kopeeritud clickhouse-copier'i abil.<\/p>\n<p><\/p>\n<p>Uues skeemis jagunevad k\u00f5ik saidid kaheks kategooriaks \u2013 suurteks ja v\u00e4ikesteks. Ma ei tea, kuidas seal piiri valitakse, kuid tulemuseks on see, et suured saidid kirjutatakse \u00fchte klastrisse, kus on 120 shard'i, igas kolm koopiat \u2013 see t\u00e4hendab 360 serverit. Ja sharding'i skeem on selline, et iga p\u00e4ring l\u00e4heb kohe k\u00f5ikidele shard'idele. Kui te n\u00fc\u00fcd avate \"Yandex.Metrika\" mis tahes aruande lehe avito.ru jaoks, siis p\u00e4ring l\u00e4heb 120 serverile. Suureid saite on runet'is v\u00e4he. Ja p\u00e4ringute arv ei ole tuhat sekundis, vaid isegi v\u00e4hem kui sada. K\u00f5ik see t\u00f6\u00f6tleb rahulikult Distributed tabel, mida iga\u00fcks neist 120 serveriga k\u00e4sitleb.<\/p>\n<p><\/p>\n<p>Teine klaster \u2013 v\u00e4ikeete jaoks. Siin on sharding'i skeem saidi identifikaatori j\u00e4rgi, ja iga p\u00e4ring l\u00e4heb t\u00e4pselt \u00fchele shard'ile.<\/p>\n<p><\/p>\n<h2 id=\"anchorclickhouse-copieranchorv-clickhouse-est-utilita-clickhouse-copier-mozhete-pronbspneyo-rasskazat\"><noindex><a rel=\"nofollow\" name=\"clickhouse-copier\"><\/a><\/noindex>ClickHouse'is on t\u00f6\u00f6riist clickhouse-copier. Kas saaksite sellest r\u00e4\u00e4kida?<\/h2>\n<p><\/p>\n<p>\u00dctlen kohe, et see lahendus on mahukam ja veidi v\u00e4hem t\u00f5hus. Eelis on see, et see jaotab andmed t\u00e4ielikult vastavalt skeemile, mille te n\u00e4itate. Kuid utiliidi puudus on see, et see ei tee \u00fcmber-shardimist. See kopeerib andmed \u00fchest klastriskeemist teise klastriskeemi.<\/p>\n<p><\/p>\n<p>See t\u00e4hendab, et selle t\u00f6\u00f6ks peavad teil olema kaks klastrit. Need v\u00f5ivad asuda samadel serveritel, kuid sellegipoolest ei liigu andmed j\u00e4rk-j\u00e4rgult, vaid need kopeeritakse. <\/p>\n<p><\/p>\n<p>N\u00e4iteks, kui serverite arv suureneb neljast kaheksani. Loote uue jaotatud tabeli k\u00f5igil serveritel, uued lokaalsed tabelid ja k\u00e4ivitate clickhouse-copier, m\u00e4\u00e4rates selle t\u00f6\u00f6re\u017eiimi, et see peaks lugema sealt, v\u00f5tma vastu uue jaotuse skeemi ja paigutama andmed sinna. Vana serverite jaoks on vajalik ruumi poolteist korda rohkem kui praegu, sest vanad andmed peavad j\u00e4\u00e4ma, ja nende peale tuleb veel pool vanadest andmetest. Kui te olete eelnevalt m\u00f5elnud, et andmed tuleb \u00fcmber jaotada ja ruumi on, siis sobib selline meetod.<\/p>\n<p><\/p>\n<p>Kuidas clickhouse-copier t\u00f6\u00f6tab? See jagab kogu t\u00f6\u00f6 \u00fclesanne komplektiks, et t\u00f6\u00f6delda \u00fchte partitsiooni \u00fche tabeli peal \u00fchel shardil. K\u00f5iki neid \u00fclesandeid saab t\u00e4ita paralleelselt, ja clickhouse-copierit saab k\u00e4ivitada erinevates masinates mitmes eksemplaris, kuid see, mida ta teeb \u00fche partitsiooni jaoks, on midagi muud, kui insert select. Andmed loetakse, dekompresseeritakse, \u00fcmber jagatakse, seej\u00e4rel kompresseeritakse uuesti, kirjutatakse kuskile, \u00fcmber sorteeritakse. See on keerulisem lahendus.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-toolanchoru-vas-byla-pilotnaya-shtuka-kotoraya-nazyvalas-resharding-chto-snbspney\"><noindex><a rel=\"nofollow\" name=\"resharding-tool\"><\/a><\/noindex>Teie k\u00e4es oli katseprojekt, mis kandis nime resharding. Kuidas on selle k\u00e4ek\u00e4ik?<\/h2>\n<p><\/p>\n<blockquote><p>Teil oli juba 2017. aastal pilootproject, mida nimetati reshardinguks. Isegi ClickHouse'is on selleks valik. Aru saades, et see ei toimi. Kas saaksite r\u00e4\u00e4kida, miks see nii l\u00e4ks? See tundub ju t\u00f5eliselt asjakohane.<\/p><\/blockquote>\n<p>Kogu probleem seisneb selles, et andmete uuesti jaotamine kohapeal n\u00f5uab \u00fcsna keerukat s\u00fcnkroniseerimist selleks, et seda teha atomaarselt. Kui me hakkasime vaatama, kuidas see s\u00fcnkroniseerimine on korraldatud, selgus, et seal on fundamentaalsed probleemid. Ja need fundamentaalsed probleemid pole mitte ainult teoreetilised, vaid hakkasid kohe ilmnema ka praktikas, mille v\u00f5iks lihtsasti selgitada \u2014 mitte miski ei toimi.<\/p>\n<p><\/p>\n<h2 id=\"anchormove-to-slow-diskanchormozhno-li-slivat-vse-chasti-dannyh-voedino-perednbspperemescheniem-nanbspmedlennye-diski\"><noindex><a rel=\"nofollow\" name=\"move-to-slow-disk\"><\/a><\/noindex>Kas on v\u00f5imalik k\u00f5ik andmeosad enne aeglastele ketastele liikumist kokku sulatada?<\/h2>\n<p><\/p>\n<blockquote><p>K\u00fcsimus TTL-i kohta, millel on liikumise valik aeglasele kettale seoses sulatustega. Kas on olemas mingit moodust, peale cron'i, et sulatada k\u00f5ik osad \u00fcheks enne aeglastele ketastele liikumist?<\/p><\/blockquote>\n<p>K\u00fcsimusele, kas on v\u00f5imalik automaatselt liita k\u00f5ik t\u00fckid \u00fcheks enne nende \u00fcleviimist, vastus on \u2013 ei. Minu arvates pole selles vajadust. Pole h\u00e4davajalik k\u00f5iki osi \u00fcheks liita, vaid piisab, kui lootame, et need liiguvad automaatselt aeglastele ketastele. <\/p>\n<p><\/p>\n<p>Meil on kaks kriteeriumi andmete \u00fcleviimise reeglite jaoks. Esimene&nbsp;\u2014 ruumi t\u00e4itmise protsendi alusel. Kui praegusel salvestustasandil on vaba ruumi v\u00e4hem kui teatud protsent, valime \u00fche mahuosa ja viime selle aeglasemasse salvestusse. T\u00e4psemalt mitte aeglasemasse, vaid j\u00e4rgmisse&nbsp;\u2014 nagu seadistate.<\/p>\n<p><\/p>\n<p>Teine kriteerium&nbsp;\u2014 suuruse alusel. See puudutab suurte osade \u00fcleviimist. V\u00f5ite reguleerida vaba ruumi piiri kiirel kettal, ja andmed viiakse automaatselt \u00fcle.<\/p>\n<p><\/p>\n<h2 id=\"anchorup-to-dateanchorkak-pereezzhat-nanbspnovye-versii-clickhouse-esli-net-vozmozhnosti-zaranee-proverit-sovmestimost\"><noindex><a rel=\"nofollow\" name=\"up-to-date\"><\/a><\/noindex>Kuidas liikuda uusimatele ClickHouse'i versioonidele, kui ei ole v\u00f5imalik eelnevalt \u00fchilduvust kontrollida?<\/h2>\n<p><\/p>\n<blockquote><p>Seda teemat arutatakse regulaarselt <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">Telegrami vestluses ClickHouse<\/a><\/noindex> arvestades erinevaid versioone, ja ometi. Kui ohutu on uuendada versioonilt 19.11 versioonile 19.16 ja n\u00e4iteks versioonilt 19.16 versioonile 20.3. Kuidas on parem liikuda uutele versioonidele, kui pole v\u00f5imalik eelnevalt testida \u00fchilduvust liivakastis?<\/p><\/blockquote>\n<p>Siin on m\u00f5ned \"kuldreeglid\". Esimene&nbsp;\u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">looge changelog<\/a><\/noindex>. See on suur, aga seal on eraldi punktid tagasip\u00f6\u00f6rdumatute muudatuste kohta. Nendele punktidele ei tasu suhtuda kui punasesse lippu. \u00dcldiselt on need v\u00e4ikesed \u00fchilduvuse probleemid, mis on seotud m\u00f5ne \u00e4\u00e4reline funktsionaalsusega, mis t\u00f5en\u00e4oliselt ei ole teil kasutuses.<\/p>\n<p><\/p>\n<p>Teine&nbsp;\u2014 kui ei ole v\u00f5imalik \u00fchilduvust liivakastis kontrollida ja soovite kohe tootmisse uuendada, on soovitus j\u00e4rgmine&nbsp;\u2014 \u00e4rge tehke seda. Looge k\u00f5igepealt liivakast ja kontrollige. Kui testkeskkonda pole, siis t\u00f5en\u00e4oliselt ei ole teil v\u00e4ga suurt ettev\u00f5tet, seega on v\u00f5imalik kopeerida osa andmetest oma s\u00fclearvutisse ja seal veenduda, et k\u00f5ik t\u00f6\u00f6tab \u00f5igesti. V\u00f5ite isegi k\u00e4ivitada m\u00f5ned koopiad kohalikult oma masinas. V\u00f5i v\u00f5ite kuskil near t\u00f5sta uue versiooni ja laadida sinna osa andmeid&nbsp;\u2014 ehk siis luua improviseeritud testkeskkond. <\/p>\n<p><\/p>\n<p>Veel \u00fcks reegel&nbsp;\u2014 \u00e4rge uuendage esimesel n\u00e4dalal p\u00e4rast versiooni ilmunud, kuna selles perioodis p\u00fc\u00fctakse p\u00fc\u00fcda tootmises esinevaid vigu ning tehakse kiireid parandusi. Vaatame \u00fcle ClickHouse'i versioonide nummerdamise, et mitte segadusse minna. <\/p>\n<p><\/p>\n<p>On olemas versioon 20.3.4. Number 20&nbsp;t\u00e4histab v\u00e4ljaandmise aastat&nbsp;\u2014 2020. Selle sisu osas pole see mingit t\u00e4hendust, nii et me ei hakka sellele t\u00e4helepanu p\u00f6\u00f6rama. Edasi&nbsp;\u2014 20.3. Teist numbrit&nbsp;\u2014 antud juhul 3 \u2014 suurendame iga kord, kui vabastame v\u00e4ljaande, kus on uus funktsionaalsus. Kui soovime ClickHouse'i lisada m\u00f5ne v\u00f5imaluse, peame seda numbri suurendama. See t\u00e4hendab, et versioonis 20.4 hakkab ClickHouse toimima veel paremini. Kolmas number&nbsp;\u2014 20.3.4. Siin on 4 \u2013 see on pat\u0161ide arvu, kus me uusi v\u00f5imalusi ei lisanud, kuid parandasime m\u00f5ned vead. Ja 4&nbsp;t\u00e4hendab, et me oleme seda teinud neli korda.<\/p>\n<p><\/p>\n<p>\u00c4rge arvake, et see on midagi hirmsat. \u00dcldiselt suudab kasutaja installida k\u00f5ige v\u00e4rskema versiooni ja see t\u00f6\u00f6tab probleemideta aastas. Kuid kujutage ette, et m\u00f5nes bitmapi t\u00f6\u00f6tlemise funktsioonis, mille meie hiina kolleegid lisasid, kukub server vale argumentide edastamise korral kokku. Me peame selle parandama. Vabastame uue pat\u0161iversiooni, ja ClickHouse muutub stabiilsemaks.<\/p>\n<p><\/p>\n<p>Kui teil on ClickHouse tootmises ja ilmub ClickHouse uus versioon koos lisafunktsioonidega \u2014 n\u00e4iteks 20.4.1 \u2014 \u00e4rge kiirustage seda tootmisse paigaldama esimesel p\u00e4eval. Miks seda \u00fcldse vajate? Kui te veel ClickHouse'i ei kasuta, siis v\u00f5ite selle installida ja t\u00f5en\u00e4oliselt on k\u00f5ik h\u00e4sti. Kuid kui ClickHouse t\u00f6\u00f6tab juba stabiilselt, siis j\u00e4lgige pat\u0161e ja uuendusi&nbsp;\u2014 milliseid probleeme me lahendame.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Soovin natuke lisada testimise keskkondade kohta. K\u00f5ik kardavad testkeskkondi ja arvavad, et kui teil on v\u00e4ga suur ClickHouse'i klaster, siis peab ka testkeskkond olema sama suur v\u00f5i v\u00e4hemalt k\u00fcmme korda v\u00e4iksem. See ei ole sugugi t\u00f5si.<\/p>\n<p><\/p>\n<p>V\u00f5in r\u00e4\u00e4kida enda kogemusest. Mul on projekt, kus on ClickHouse. Meie testkeskkond selle jaoks&nbsp;\u2014 see on v\u00e4ike virtuaalmasin Hetzneris 20 euro eest, kus on k\u00f5ik paigaldatud. Selleks on meil t\u00e4ielik automatiseerimine Ansible'is, seega ei ole p\u00f5him\u00f5tteliselt vahet, kuhu minna \u2014 kas f\u00fc\u00fcsilistele serveritele v\u00f5i lihtsalt virtuaalmasinatesse.<\/p>\n<p><\/p>\n<p>Mida saab teha? Oleks hea, kui ClickHouse'i dokumentatsioonis oleks n\u00e4ide, kuidas \u00fcles seada v\u00e4ike klaster \u2013 Dockeris, LXC-s, v\u00f5ib-olla luua Ansible playbook, sest erinevatel inimestel on erinevad rakendused. See lihtsustaks palju. Kui sa v\u00f5tad ja paigaldad klaster viie minutiga, on palju lihtsam millegagi toime tulla. See on palju mugavam, sest minna tootmisversiooniga, mida sa ei ole testinud \u2013 see on tee mitte kuhugi. M\u00f5nikord t\u00f6\u00f6tab, m\u00f5nikord mitte. Seet\u00f5ttu ei tohi lootma j\u00e4\u00e4da, see on halb.<\/p>\n<p><\/p>\n<p><strong>Maksim Kotjakov, senior backend engineer Avito:<\/strong> Lisaks r\u00e4\u00e4gin testimisest suurte ettev\u00f5tete seas. Meil on t\u00e4ielik ClickHouse'i vastuv\u00f5tuklaster, mis on andmeskeemide ja seadistuste osas t\u00e4pne koopia tootmisest. See klaster on \u00fcles seatud \u00fcsna vanadesse konteineritesse minimaalse ressurssidega. Me kirjutame sinna teatud protsendi tootmisandmetest, \u00f5nneks on meil v\u00f5imalus Kafkas voogu replitseerida. Seal on k\u00f5ik s\u00fcnkroonitud ja skaleeritud \u2013 nii v\u00f5imsuse kui ka voolu osas, ja teoorias, kui k\u00f5ik muu on v\u00f5rdsed, peaks see k\u00e4ituma nagu tootmine. K\u00f5ik potentsiaalselt plahvatusohtlikud asjad rulluvad esmalt sellele platvormile ja p\u00e4evade kaupa seal k\u00fcpsevad. Kuid loomulikult on see lahendus kallis, keeruline ja sellega kaasnevad mitte-nullkulud. <\/p>\n<p><\/p>\n<p><strong>Aleksei Milovidov:<\/strong> R\u00e4\u00e4gin, milline testimiskeskkond on meie s\u00f5pradel Yandex.Metrikas. \u00dcks klaster oli \u00fcle 600 serveri, teine 360, ja on veel kolmas ja mitu klastrit. \u00dche nende testimiskeskkond on lihtsalt kaks shard'i, igas kahte replikat. Miks kaks shard'i? Et ei oleks ainult \u00fchte. Ja et replikad ka olemas oleksid. Lihtsalt minimaalne arv, mida endale lubada.<\/p>\n<p><\/p>\n<p>See testimiskeskkond v\u00f5imaldab kontrollida p\u00e4ringute toimimist ja ei ole t\u00f5siseid t\u00f5rkeid. Kuid sageli tekivad probleemid t\u00e4iesti erineva loomuga, kui k\u00f5ik t\u00f6\u00f6tab, aga koormuses on tehtud m\u00f5ned v\u00e4ikesed muutused.<\/p>\n<p><\/p>\n<p>Took an example. We decided to install a new version of ClickHouse. It was deployed to a test environment, and automated tests were conducted in Yandex.Metrica, comparing data between the old version and the new one, running the entire pipeline. Naturally, the CI tests passed as well. Otherwise, we wouldn\u2019t even have proposed this version.<\/p>\n<p><\/p>\n<p>Everything is great. We start rolling it out to production. I receive a message that the load on the graphs has increased several times. We roll back the version. I look at the graph and see: the load indeed increased several times during the rollout, and then decreased again after we rolled it out. Then we started to roll back the version. And the load increased just the same and then dropped back as well. So the conclusion is that the load increased due to the deployment, nothing surprising.<\/p>\n<p><\/p>\n<p>It was difficult to convince my colleagues to actually install the new version. I said: \"It's fine, go ahead and deploy. Keep your fingers crossed, everything will work. The load has increased on the graphs, but it's all okay. Hold on.\" So we did that, and the version was deployed to production. But almost with every deployment, similar problems arise.<\/p>\n<p><\/p>\n<h2 id=\"anchorkill-queryanchorkill-query-dolzhen-ubivat-zaprosy-no-on-etogo-ne-delaet-pochemu\"><noindex><a rel=\"nofollow\" name=\"kill-query\"><\/a><\/noindex>Kill query peab tapma p\u00e4ringuid, kuid see ei toimi. Miks?<\/h2>\n<p><\/p>\n<blockquote><p>A user approached me, some analyst, and created a query that crashed my ClickHouse cluster. A node or the whole cluster\u2014depending on which replica or shard the query hit. I see that all CPU resources on this server are maxed out, everything is red. Meanwhile, ClickHouse itself is still responding to requests. I write: \"Please show me the process list, which query caused this madness.\"<\/p>\n<p>I find this query and write kill. And I see that nothing happens. My server is maxed out, ClickHouse continues to provide me with some commands, showing that the server is alive, and everything is great. But I am experiencing degradation on all user requests, and degradation in writing to ClickHouse starts, and my kill query isn't working. Why? I thought that kill query should terminate queries, but it doesn't happen.<\/p><\/blockquote>\n<p>Now I'm going to give you a rather strange answer. The thing is that kill query does not terminate queries. <\/p>\n<p><\/p>\n<p>Kill query seabard v\u00e4ikese m\u00e4rgise nimetusega \u201ema tahan, et see p\u00e4ring tapetakse\u201c. Ja p\u00e4ring vaatab iga andmeploki t\u00f6\u00f6tlemisel seda m\u00e4rgist. Kui see on seatud, l\u00f5petab p\u00e4ring t\u00f6\u00f6tamise. Selgub, et keegi ei tappa p\u00e4ringut, see peab ise k\u00f5ik kontrollima ja peatuma. See peaks t\u00f6\u00f6tama k\u00f5igis juhtudel, kui p\u00e4ring on andmeplokkide t\u00f6\u00f6tlemise olekus. See t\u00f6\u00f6tleb j\u00e4rgmise andmeploki, kontrollib m\u00e4rgist ja peatub.<\/p>\n<p><\/p>\n<p>See ei t\u00f6\u00f6ta juhtudel, kui p\u00e4ring on mingis operatsioonis blokeeritud. T\u00f5si, see ei pruugi olla teie juhtum, kuna teie s\u00f5nul kasutab see palju serveri ressursse. V\u00f5ib-olla ei t\u00f6\u00f6ta see v\u00e4list sorteeringu puhul ja veel m\u00f5nedes detailides. Aga \u00fcldiselt ei tohiks see nii olla, see on bug. Ja ainus, mida saan soovitada, on uuendada ClickHouse'i.<\/p>\n<p><\/p>\n<h2 id=\"anchorreading-timeanchorkak-rasschitat-vremya-otveta-pri-chitayuschey-nagruzke\"><noindex><a rel=\"nofollow\" name=\"reading-time\"><\/a><\/noindex>Kuidas arvutada vastuse aega lugemise koormuse korral?<\/h2>\n<p><\/p>\n<blockquote><p>On tabel, kus hoitakse agregaatide kohta item - erinevad loendurid. Ridade arv on umbes sada miljonit. Kas on v\u00f5imalik loota j\u00e4rjepidevusele vastamise ajal, kui laadida 1K RPS 1K item'i kohta? <\/p><\/blockquote>\n<p>Kohtu kaudu, tundub, et on tegemist lugemisekoormusega, sest kirjutamise osas ei ole probleeme - v\u00f5ite sisestada kas tuhat, sada tuhat v\u00f5i vahel isegi mitmeid miljoneid ridu. <\/p>\n<p><\/p>\n<p>Lugemisettepanekud on v\u00e4ga erinevad. Select 1 ClickHouse suudab sooritada umbes k\u00fcmneid tuhandeid p\u00e4ringuid sekundis, seega isegi \u00fche v\u00f5tmega p\u00e4ringud n\u00f5uavad juba teatud ressursse. Ja sellised punktp\u00e4ringud on keerulisemad kui m\u00f5nes key-value andmebaasis, sest iga lugemise jaoks tuleb lugeda andmeblokk indeksile. Meie indeks suunab mitte iga kirje, vaid iga vahemiku. See t\u00e4hendab, et tuleb lugeda kogu vahemik - see on vaikimisi 8192 rida. Ja tuleb dekompresseerida 64 Kb suurune surutud andmeblokk 1 Mb-ks. \u00dcldiselt v\u00f5tavad sellised punktp\u00e4ringud aega paaris millisekundis. Kuid see on k\u00f5ige lihtsam variant.<\/p>\n<p><\/p>\n<p>Proovime teha lihtsat aritmeetikat. Kui mitme millisekundi jagame tuhandega, saame mitu sekundit. Tundub, et tuhandet p\u00e4ringut sekundis pole v\u00f5imalik t\u00f6\u00f6delda, kuid tegelikult on see v\u00f5imalik, kuna meil on mitu protsessorit. Seega suudab ClickHouse m\u00f5nikord taluda 1000 RPS, kuid ainult l\u00fchikeste, spetsiifiliste p\u00e4ringute puhul.<\/p>\n<p><\/p>\n<p>Kui peate Scale`ima ClickHouse klastrit lihtsate p\u00e4ringute arvu osas, siis soovitan k\u00f5ige lihtsamat \u2014 suurendada replikate arvu ja saata p\u00e4ringud juhuslikule replikale. Kui \u00fcks replik suudab taluda viissada p\u00e4ringut sekundis, mis on t\u00e4iesti reaalne, siis kolm replikat suudavad taluda poolteist tuhat.<\/p>\n<p><\/p>\n<p>M\u00f5nikord on v\u00f5imalik ka ClickHouse'i seadistada maksimaalse arvu spetsiifiliste lugemiste jaoks. Mida selleks on vaja? Esmalt \u2014 v\u00e4hendada indeksi granulaarsust. Seda tuleks v\u00e4hendada mitte kuni \u00fchikuni, vaid arvestades, et indeksis on mitu miljonit v\u00f5i k\u00fcmneid miljoneid kirjeid serveri kohta. Kui tabelis on sada miljonit rida, siis granulaarsuse kuvamiseks v\u00f5ib seada 64.<\/p>\n<p><\/p>\n<p>V\u00f5ite v\u00e4hendada tihendatud ploki suurust. Selle jaoks on olemas seade. <strong>min compress block size<\/strong>, <strong>max compress block size<\/strong>Nende suurust v\u00f5ib v\u00e4hendada, andmed uuesti laadida, ja siis on spetsiifilised p\u00e4ringud kiirem. Sellegipoolest ei ole ClickHouse key-value andmebaas. Suur hulk v\u00e4ikeseid p\u00e4ringuid on koormuse antimuster.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Annan n\u00f5u, juhul kui seal on tavalised kohtumised. See on \u00fcsna tavaline olukord, kui ClickHouse'is hoitakse mingi arvesti. Mul on kasutaja, ta on p\u00e4rit konkreetsest riigist, mingi kolmas v\u00e4li ja midagi tuleb inkremendina suurendada. V\u00f5tate MySQL, teete unikaalse v\u00f5tme \u2014 MySQLis on see duplicate key, PostgreSQL\u2019is on see conflict \u2014 ja lisate plussiga. See toimib oluliselt paremini. <\/p>\n<p><\/p>\n<p>Kui teil on v\u00e4he andmeid, ei ole ClickHouse'i kasutamisel eriti m\u00f5tet. On olemas tavalised andmebaasid, ja need suudavad sellega h\u00e4sti toime tulla. <\/p>\n<p><\/p>\n<h2 id=\"anchorpimp-my-clickhouseanchorchto-podtyunit-v-clickhouse-chtoby-bolshe-dannyh-bylo-vnbspkeshe\"><noindex><a rel=\"nofollow\" name=\"pimp-my-clickhouse\"><\/a><\/noindex>Mida ClickHouse'is h\u00e4\u00e4lestada, et rohkem andmeid oleks vahemikus?<\/h2>\n<p><\/p>\n<blockquote><p>Kujutame ette olukorda \u2014 serverites on 256 GB RAM-i, igap\u00e4evases rutiinis v\u00f5tab ClickHouse umbes 60\u201480 GB, tipptasemel \u2014 kuni 130. Mida saaks sisse l\u00fclitada ja h\u00e4\u00e4lestada, et rohkem andmeid oleks vahemikus ja seega oleks v\u00e4hem diskile minemise aegu?<\/p><\/blockquote>\n<p>Tavaliselt suudab operatsioonis\u00fcsteemi lehevahem\u00e4lu suurep\u00e4raselt selle \u00fclesandega hakkama saada. Kui avate lihtsalt tipu, vaadake seal cached v\u00f5i free \u2014 seal on samuti kirjas, kui palju on vahem\u00e4lu salvestatud \u2014 siis v\u00f5ite m\u00e4rgata, et kogu vabam\u00e4lu on kasutatud vahem\u00e4lu jaoks. Ja need andmed loetakse lugemisel mitte kettalt, vaid m\u00e4lust. Sellega v\u00f5in \u00f6elda, et vahem\u00e4lu kasutatakse t\u00f5husalt, kuna vahem\u00e4llu salvestatakse just kompressitud andmed.<\/p>\n<p><\/p>\n<p>Siiski, kui soovite veelgi kiirendada m\u00f5ningaid lihtsaid p\u00e4ringuid, on v\u00f5imalus lubada ClickHouse'is vahem\u00e4lu dekompressitud andmete jaoks. Seda nimetatakse <strong>uncompressed cache<\/strong>. Konfiguratsioonifailis config.xml seadke uncompressed cache size soovitud v\u00e4\u00e4rtuseks \u2014 soovitan mitte rohkem kui pooled vabast m\u00e4lust, kuna \u00fclej\u00e4\u00e4nud l\u00e4heb lehevahem\u00e4lu alla. <\/p>\n<p><\/p>\n<p>Lisaks on olemas kaks p\u00e4ringutaseme seadet. Esimene seadistus - <strong>kasutada uncompressed cache<\/strong> \u2014 aktiveerib selle kasutamise. Soovitatav on see lubada k\u00f5ikide p\u00e4ringute puhul, v\u00e4lja arvatud rasked p\u00e4ringud, mis v\u00f5ivad k\u00f5ik andmed l\u00e4bi lugeda ja selle vahem\u00e4lu t\u00fchjendada. Ja teine seadistus \u2014 see on midagi sellist nagu maksimaalne ridade arv vahem\u00e4lu kasutamiseks. See piirab automaatselt suuri p\u00e4ringuid, et need j\u00e4\u00e4ksid vahem\u00e4lust m\u00f6\u00f6da.<\/p>\n<p><\/p>\n<h2 id=\"anchorstorage-configurationanchorkak-mozhno-nastroit-storage_configuration-dlya-hraneniya-v-operativke\"><noindex><a rel=\"nofollow\" name=\"storage-configuration\"><\/a><\/noindex>Kuidas saab seadistada storage_configuration t\u00f6\u00f6tamise eesm\u00e4rgil?<\/h2>\n<p><\/p>\n<blockquote><p>Uues ClickHouse dokumentatsioonis lugesin l\u00f5iku, mis on seotud <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">andmete salvestamine<\/a><\/noindex>. Kirjelduses on n\u00e4ide kiire SSD kohta. <\/p>\n<p>On huvitav, kuidas saab sama konfigureerida mahukale kuumale m\u00e4lule. Ja veel \u00fcks k\u00fcsimus. Kuidas t\u00f6\u00f6tab select sellise andmestruktuuriga, kas see loeb kogu komplekti v\u00f5i ainult selle, mis on kettal, ja kas need andmed komprimeeritakse m\u00e4lus? Ja kuidas toimib prewhere sektsioon sellise andmestruktuuriga?<\/p><\/blockquote>\n<p>See seadistus m\u00f5jutab andmepartsikate salvestamist ja nende formaat ei muutu kuidagi.<br \/>\nVaatame l\u00e4hemalt. <\/p>\n<p><\/p>\n<p>Andmete salvestamine m\u00e4lus on v\u00f5imalik seadistada. K\u00f5ik, mis on konfigureeritud ketta jaoks \u2014 see on tema tee. Loote tmpfs partitsiooni, mis on monteeritud mingi tee alla failis\u00fcsteemis. M\u00e4\u00e4rate selle tee andmete salvestamise teena k\u00f5ige kuumemale partitsioonile, kuhu hakkavad j\u00f5udma ja salvestuma andmepartsikad, k\u00f5ik on h\u00e4sti. <\/p>\n<p><\/p>\n<p>Kuid ma ei soovita seda teha madala usaldusv\u00e4\u00e4rsuse t\u00f5ttu, kuigi, kui sul on v\u00e4hemalt kolm koopiat erinevates andmekeskustes, siis v\u00f5ib. Kui midagi juhtub, saavad andmed taastatud. Kujutame ette, et server l\u00fclitati j\u00e4rsku v\u00e4lja ja seej\u00e4rel tagasi sisse. Jaotise mountitakse taas, kuid seal on t\u00fchjus. ClickHouse server k\u00e4ivitamisel n\u00e4eb, et tal puuduvad need t\u00fckid, kuigi vastavalt ZooKeeperi metaandmetele peaksid need olema. Ta vaatab, millistes koopiates need on, k\u00fcsib neid ja allalaadib. Nii saavad andmed taastatud. <\/p>\n<p><\/p>\n<p>Selles m\u00f5ttes ei erine andmete hoidmine m\u00e4lus p\u00f5him\u00f5tteliselt nende hoidmisest kettal, kuna andmete kirjutamisel kettale satuvad need esmalt page cache'i ja f\u00fc\u00fcsiliselt kirjutatakse need edasi l\u00fckatult. See s\u00f5ltub failis\u00fcsteemi mountimise variandist. Kuid igaks juhuks mainin, et ClickHouse ei tee fsync operatsiooni inserti ajal.<\/p>\n<p><\/p>\n<p>Sellegipoolest hoitakse andmeid m\u00e4lus t\u00e4pselt samas formaadis kui kettal. Select p\u00e4ring valib t\u00e4pselt samamoodi t\u00fckid, mida tuleb lugeda, valib vajalikud andmevahemikud ja loeb need. Ja prewhere t\u00f6\u00f6tab t\u00e4pselt samamoodi, olgu andmed m\u00e4lus v\u00f5i kettal.<\/p>\n<p><\/p>\n<h2 id=\"anchorlow-cardinalityanchordo-kakogo-kolichestva-unikalnyh-znacheniy-effektiven-low-cardinality\"><noindex><a rel=\"nofollow\" name=\"low-cardinality\"><\/a><\/noindex>Kuni millise unikaalsete v\u00e4\u00e4rtuste arvuni on Low Cardinality efektiivne?<\/h2>\n<p><\/p>\n<p>Low Cardinality on nutikalt \u00fcles ehitatud. See koostab andmes\u00f5nastikke, kuid need on kohalikud. Esiteks, iga t\u00fcki jaoks on oma s\u00f5nastik, ja teiseks, isegi \u00fche t\u00fcki sees v\u00f5ivad need iga vahemiku jaoks erineda. Kui ainulaadsete v\u00e4\u00e4rtuste arv saavutab k\u00fcnnise \u2014 minu arvates \u00fcks miljon \u2014 s\u00f5nastik lihtsalt l\u00fckatakse tagasi ja luuakse uus.<\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes on vastus: iga kohaliku vahemiku jaoks \u2014 \u00fctleme, iga p\u00e4eva jaoks \u2014 on Low Cardinality efektiivne kuskil kuni miljoni ainulaadse v\u00e4\u00e4rtuseni. P\u00e4rast seda toimub lihtsalt fallback, kus kasutatakse mitmeid erinevaid s\u00f5nastikke, mitte \u00fchte. See t\u00f6\u00f6tab umbes samamoodi nagu tavap\u00e4rane string t\u00fc\u00fcpi veerg, v\u00f5ib-olla veidi v\u00e4hem efektiivselt, kuid t\u00f5sist j\u00f5udluse langust ei toimu. <\/p>\n<p><\/p>\n<h2 id=\"anchorfulltext-searchanchorkakie-luchshie-praktiki-ponbsppolnotekstovomu-poisku-ponbsptablice-snbsppyatyu-milliardami-strok\"><noindex><a rel=\"nofollow\" name=\"fulltext-search\"><\/a><\/noindex>Millised on parimad praktikad t\u00e4isteksti otsimise korral, kui tabelis on viis miljardit rida?<\/h2>\n<p><\/p>\n<p>On erinevaid vastusevariante. Esiteks v\u00f5ib \u00f6elda, et ClickHouse ei ole t\u00e4isteksti otsingu s\u00fcsteem. Selle jaoks on spetsiaalsed s\u00fcsteemid, n\u00e4iteks <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> ja <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Sellegipoolest kohtan \u00fcha enam inimesi, kes \u00fctlevad, et nad liiguvad Elasticsearchilt ClickHouse'ile.<\/p>\n<p><\/p>\n<p>Miks see nii juhtub? Nad selgitavad, et Elasticsearch kaotab teatud mahtude korral koormusega toimetuleku, alustades indeksite loomisega. Indeksid muutuvad liiga mahukaks ja kui andmed lihtsalt ClickHouse'i \u00fcle kanda, osutub nende salvestamine oluliselt efektiivsemaks. Samas olid otsingup\u00e4ringud sageli sellised, et ei pidanud leidma mingit fraasi kogu andmehulgas morfoloogia arvesse v\u00f5tmisega, vaid hoopis teised. N\u00e4iteks otsida logidest viimase paarik\u00fcmne tunni jooksul mingit alams\u00fcsteemi baitides.<\/p>\n<p><\/p>\n<p>Selle puhul loobite ClickHouse'is indeksi, mille esimene v\u00e4li on kuup\u00e4ev koos ajaga. Ja andmete suurim filtreerimine toimub just kuup\u00e4evade vahemiku j\u00e4rgi. Valitud kuup\u00e4eva vahemikus saab tavaliselt teha t\u00e4ielikku tekstip\u00f5hist otsingut isegi brute-force meetodi abil, kasutades like operaatort. ClickHouse'i like operaator on k\u00f5ige t\u00f5husam like operaator, mida te leiate. Kui leiate parema, andke mulle teada. <\/p>\n<p><\/p>\n<p>Kuid like on ikkagi full scan. Ja full scan v\u00f5ib olla aeglane mitte ainult CPU p\u00e4rast, vaid ka ketaste t\u00f5ttu. Kui teil on \u00e4kki \u00fcks terabait andmeid p\u00e4evas ja otsite mingi s\u00f5na, tuleb teil skannida \u00fcks terabait. Ja see on t\u00f5en\u00e4oliselt tavalistel k\u00f5vaketastel, mis t\u00e4hendab, et nad on nii koormatud, et te ei p\u00e4\u00e4se selle serveri SSH-sse.<\/p>\n<p><\/p>\n<p>Sellisel juhul olen valmis pakkuma veel \u00fchte v\u00e4ikest trikki. See on katsetus \u2014 v\u00f5ib t\u00f6\u00f6tada, aga v\u00f5ib ka mitte. ClickHouse'is on t\u00e4ielikud tekstindeksid trigramm Bloom-filtrite kujul. Meie kolleegid ettev\u00f5ttest Arenadata on neid indekse juba testinud ja tihti t\u00f6\u00f6tavad nad just nii, nagu on ette n\u00e4htud.<\/p>\n<p><\/p>\n<p>Kuidas neid \u00f5igesti kasutada, tuleb h\u00e4sti aru saada, kuidas nad just t\u00f6\u00f6tavad: mis on trigramm Bloom-filter ja kuidas valida selle suurust. V\u00f5in \u00f6elda, et need aitavad haruldaste fraaside ja osade p\u00e4ringute puhul, mis andmetes harva esinevad. Sel juhul valitakse indeksite kaudu alamvahemikud ja loetakse v\u00e4hem andmeid.<\/p>\n<p><\/p>\n<p>Hiljuti lisandus ClickHouse'ile veelgi arenenud funktsioone t\u00e4isteksti otsingus. Esiteks, saab teha otsingut mitme alamstringi j\u00e4rgi \u00fches l\u00e4bimises, sealhulgas variandid, mis arvestavad registreid, ilma registrita, UTF-8 toe v\u00f5i ainult ASCII jaoks. Valige k\u00f5ige t\u00f5husam variant, mis teile sobib. <\/p>\n<p><\/p>\n<p>Ilmnes ka mitme regulaaravaldi otsingu v\u00f5imalus \u00fches l\u00e4bimises. Te ei pea kirjutama X like \u00fcks alamstring v\u00f5i X like teine alamstring. Kirjutage lihtsalt ja k\u00f5ik toimub maksimaalselt efektiivselt.<\/p>\n<p><\/p>\n<p>Kolmandaks - n\u00fc\u00fcd on olemas l\u00e4hedane regulaaravaldi otsing ja l\u00e4hedane alamstringi otsing. Kui keegi teeb tr\u00fckivea, otsitakse seda maksimaalse vastavuse j\u00e4rgi.<\/p>\n<p><\/p>\n<h2 id=\"anchorhello-and-welcomeanchorkak-luchshe-organizovat-dostup-vnbspclickhouse-dlyanbspbolshogo-kolichestva-polzovateley\"><noindex><a rel=\"nofollow\" name=\"hello-and-welcome\"><\/a><\/noindex>Kuidas korraldada ClickHouse'i juurdep\u00e4\u00e4s suurele kasutajate arvule?<\/h2>\n<p><\/p>\n<blockquote><p>R\u00e4\u00e4kige, kuidas korraldada juurdep\u00e4\u00e4s suurele hulgale tarbijatele ja anal\u00fc\u00fctikutele. Kuidas moodustada j\u00e4rjekord, prioriseerida p\u00e4ringud max concurrently queries ja milliseid t\u00f6\u00f6riistu kasutada?<\/p><\/blockquote>\n<p>Kui klaster on piisavalt suur, v\u00f5ib hea lahendus olla lisada kaks serverit, mis saavad anal\u00fc\u00fctikutele sissep\u00e4\u00e4suks. See t\u00e4hendab, et anal\u00fc\u00fctikud ei p\u00e4\u00e4se konkreetsetele klastrite shard'idele, vaid luuakse lihtsalt kaks t\u00fchja serverit, ilma andmeteta, ja neile seatakse juurdep\u00e4\u00e4su\u00f5igused. Samuti edastatakse kasutajaseaded jaotatud p\u00e4ringute korral eemalserveritesse. Nii et te seadistate k\u00f5ik nendele kahele serverile ning seaded m\u00f5jutavad kogu klastrit.<\/p>\n<p><\/p>\n<p>P\u00f5him\u00f5tteliselt on need serverid andmeteta, kuid nende m\u00e4lumaht on p\u00e4ringute t\u00e4itmiseks v\u00e4ga oluline. Ka kettaruumi saab kasutada ajutiste andmete jaoks, kui on lubatud v\u00e4line agregatsioon v\u00f5i v\u00e4line sortimine.<\/p>\n<p><\/p>\n<p>Oluline on vaadata seadeid, mis on seotud k\u00f5ikide v\u00f5imalike piirangutega. Kui ma n\u00fc\u00fcd sisenen \"Yandex.Metrika\" klastrisse anal\u00fc\u00fctikuna ja esitan p\u00e4ringu <strong>select count from hits<\/strong>, siis antakse mulle kohe v\u00e4lja erand, et ma ei saa p\u00e4ringut t\u00e4ita. Max lubatud ridade arv, mida ma saan skaneerida, on sada miljardit, kuid klastris on neid kokku viisk\u00fcmmend trillionit \u00fches tabelis. See on esimene piirang. <\/p>\n<p><\/p>\n<p>Oletame, et eemaldan ridade arvu piirangud ja t\u00e4idan p\u00e4ringu uuesti. Siis n\u00e4en j\u00e4rgmist erandit - seaded on lubatud. <strong>force index by date<\/strong>. Ma ei saa p\u00e4ringut t\u00e4ita, kui ma ei ole m\u00e4\u00e4ranud kuup\u00e4evade vahemikku. Ei ole m\u00f5tet loota, et anal\u00fc\u00fctikud m\u00e4\u00e4ravad selle k\u00e4sitsi. T\u00fc\u00fcpiline olukord on see, et kuup\u00e4evade vahemik on kirjutatud, kus s\u00fcndmuse kuup\u00e4ev on vahemikus n\u00e4dal. Ja siis lihtsalt ei pandud sulgus \u00f5igesse kohta, ning 'and' asemel saame 'or' \u2014 v\u00f5i URL-i vastavus. Kui piiranguid ei ole, hakkab see skaneerima URL-i veergu ja kulutab lihtsalt tohutult ressursse.<\/p>\n<p><\/p>\n<p>Lisaks on ClickHouse'is kaks seadistust prioriteetide jaoks. Kahjuks on need v\u00e4ga primitiivsed. \u00dcks neist nimetatakse lihtsalt <strong>priority<\/strong>. Kui prioriteet \u2260 0 ja k\u00e4ivitatakse p\u00e4ringud mingisuguste prioriteetidega, kuid samal ajal k\u00e4ivitatakse p\u00e4ring prioriteediga, mille v\u00e4\u00e4rtus on madalam, mis t\u00e4hendab k\u00f5rgemat prioriteeti, siis p\u00e4ring, mille prioriteedi v\u00e4\u00e4rtus on suurem, mis t\u00e4histab madalamat prioriteeti, lihtsalt peatatakse ega toimi selle aja jooksul.<\/p>\n<p><\/p>\n<p>See on v\u00e4ga j\u00e4ik seadistus, ja see ei sobi olukordadesse, kus klastri koormus on pidev. Kuid kui teil on l\u00fchikesed, impulsi p\u00e4ringud olulised, ja enamikul juhtudel puhkab klaster, siis see seadistus sobib.<\/p>\n<p><\/p>\n<p>J\u00e4rgmine prioriteetide seadistus nimetatakse <strong>OS teema prioriteet<\/strong>. See lihtsalt m\u00e4\u00e4rab k\u00f5igi p\u00e4ringu t\u00e4itmise l\u00f5imede jaoks Linuxi ajakava 'nice' v\u00e4\u00e4rtuse. See t\u00f6\u00f6tab k\u00fcll mitte v\u00e4ga h\u00e4sti, aga siiski t\u00f6\u00f6tab. Kui m\u00e4\u00e4rata k\u00f5ige madalam 'nice' v\u00e4\u00e4rtus \u2014 see on k\u00f5ige suurem v\u00e4\u00e4rtus ja seega madalaim prioriteet \u2014 ja k\u00f5rgprioriteediga p\u00e4ringutele m\u00e4\u00e4rata -19, siis CPU tarbib madalprioriteediga p\u00e4ringute jaoks umbes neli korda v\u00e4hem ressursse kui k\u00f5rgeprioriteediga p\u00e4ringute jaoks. <\/p>\n<p><\/p>\n<p>Samuti tuleb seada maksimaalne p\u00e4ringu t\u00e4itmise aeg \u2014 \u00fctleme viis minutit. P\u00e4ringu minimaalne t\u00e4itmise kiirus \u2014 see on k\u00f5ige lahedam. See seadistus on juba pikka aega olemas ja see on vajalik, et mitte lihtsalt kinnitada, et ClickHouse ei pidurda, vaid et see sundida.<\/p>\n<p><\/p>\n<p>Kujutage ette, et seadistate: kui mingi p\u00e4ring t\u00f6\u00f6tleb v\u00e4hem kui miljonit rida sekundis \u2014 nii ei tohi teha. See h\u00e4bistab meie head nime, meie head andmebaasi. Laseme selle lihtsalt keelata. Seal on tegelikult kaks seadistust. \u00dcks neist nimetatakse <strong>min execution speed<\/strong> \u2014 sekundis query'de ja, teise nimetusega timeout before checking min execution speed \u2014 vaikimisi viisteist sekundit. See t\u00e4hendab, et viisteist sekundit on lubatud, kuid kui see aeglane, visake lihtsalt erand \u2014 katkestage p\u00e4ring.<\/p>\n<p><\/p>\n<p>Peate seadistama ka kvoodid. ClickHouse'is on sisseehitatud kvoodiv\u00f5ime, mis arvestab ressursikasutust. Kahjuks ei h\u00f5lma see f\u00fc\u00fcsilisi ressursse nagu CPU, kettad, vaid loogilisi \u2014 t\u00f6\u00f6deldud p\u00e4ringute, ridade ja loetud baitide arvu. N\u00e4iteks on v\u00f5imalik seadistada maksimaalselt sada p\u00e4ringut viie minuti jooksul ja tuhat p\u00e4ringut tunni kohta.<\/p>\n<p><\/p>\n<p>Miks see oluline on? Sest osa anal\u00fc\u00fctilisi p\u00e4ringuid hakkab tegema k\u00e4sitsi otse ClickHouse'i kliendist. See on okei. Kuid kui teil on oma ettev\u00f5ttes edasij\u00f5udnud anal\u00fc\u00fctikud, kirjutavad nad skripti, ja skripti sees v\u00f5ib olla viga. Ja see viga p\u00f5hjustab p\u00e4ringu t\u00e4itmist l\u00f5pmatus ts\u00fcklis. Selle eest tuleb end kaitsta.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>Kas on v\u00f5imalik edastada \u00fche p\u00e4ringu tulemused k\u00fcmnele kliendile?<\/h2>\n<p><\/p>\n<blockquote><p>Meil on mitmeid kasutajaid, kes armastavad tulla v\u00e4ga suurte p\u00e4ringutega samal ajal. P\u00e4ring on suur, t\u00e4idetakse \u00fcldiselt kiiresti, kuid samas kui selliseid p\u00e4ringuid on korraga palju, muutub see v\u00e4ga valusaks. Kas on v\u00f5imalik sama p\u00e4ring, mis tuli k\u00fcmme korda j\u00e4rjest, t\u00e4ita \u00fcks kord ja anda selle tulemus k\u00fcmnele kliendile?<\/p><\/blockquote>\n<p>Probleem on selles, et meil ei ole t\u00e4pselt tulemusi vahem\u00e4lust v\u00f5i vaheandmete vahem\u00e4lust. On olemas operatsioonis\u00fcsteemi page cache, mis v\u00f5imaldab andmeid uuesti kettalt mitte lugeda, kuid kahjuks peavad andmed ikkagi lahti pakkima, deserialiseerima ja uuesti t\u00f6\u00f6tlema. <\/p>\n<p><\/p>\n<p>Sooviksime mingil viisil seda v\u00e4ltida, kas vaheandmete vahem\u00e4luga, v\u00f5i koondades sarnaseid p\u00e4ringuid mingisse j\u00e4rjekorda ja lisades tulemuste vahem\u00e4lu. Praegu on meil arenduses \u00fcks pull request, mis lisab p\u00e4ringute vahem\u00e4lu, kuid ainult alam-p\u00e4ringute puhul in ja join sektsioonis \u2014 seega lahendus ei ole t\u00e4ielik.<\/p>\n<p><\/p>\n<p>Kuid ka meil tekib sarnane olukord. Eriti on klassikaline n\u00e4ide p\u00e4ringud, millel on lehevahetus. On raport, kus on mitmeid lehti ja p\u00e4ring l\u00e4heb limit 10. Siis sama asi, aga limit 10,10. Seej\u00e4rel j\u00e4rgmine leht. Ja tuleb k\u00fcsida, miks me seda iga kord arvutame? Praegu ei ole lahendust ja seda ei saa v\u00e4ltida.<\/p>\n<p><\/p>\n<p>On olemas alternatiivne lahendus, mis paigaldatakse ClickHouse'i k\u00f5rvale nagu sidur \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Vertamedia\/chproxy\">ClickHouse Proxy<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> ClickHouse Proxy's on sisseehitatud rate limiter ja sisseehitatud tulemuste vahem\u00e4lu. Seal on palju seadeid, sest lahendati sarnane probleem. Proxy v\u00f5imaldab p\u00e4ringute limiitimist, korraldades need j\u00e4rjekorda, ja seadistada, kui kaua p\u00e4ringute vahem\u00e4lu kehtib. Kui p\u00e4ringud on t\u00f5eliselt \u00fchesugused, annab Proxy need mitu korda, kuid l\u00e4heb ClickHouse'i ainult \u00fcks kord.<\/p>\n<p><\/p>\n<p>Nginxis on ka tasuta versioonis vahem\u00e4lu, ja see t\u00f6\u00f6tab samuti. Nginxis on isegi seaded, et kui p\u00e4ringud tulevad samal ajal, siis ta viibib teistega, kuni \u00fcks on l\u00f5pule viidud. Kuid ClickHouse Proxy seadistus on tehtud palju paremini. See on loodud spetsiaalselt ClickHouse'i jaoks, just nende p\u00e4ringute jaoks, seega sobib see paremini. Ja selle paigaldamine on lihtne. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Kuidas k\u00e4ituda as\u00fcnkroonsete operatsioonide ja materialiseeritud vaadete puhul?<\/h2>\n<p><\/p>\n<blockquote><p>On probleem, et operatsioonid asendustegevusena on as\u00fcnkroonilised \u2014 k\u00f5igepealt salvestatakse andmed ja seej\u00e4rel toimub nende kokkut\u00f5mbamine. Kui tabeli all elab materialiseeritud tabel mingite kogumitega, siis kopeeritakse sellele dubleerimised. Kui mingit keerulist loogikat ei ole, siis andmed dubleeritakse. Mida sellega teha saab?<\/p>\n<p>On ilmne lahendus \u2014 rakendada triggereid teatud klassi materjalivaatamise jaoks as\u00fcnkroonilise kokkut\u00f5mbamise operatsiooni korral. Kas on olemas mingeid 'h\u00f5bedasi kuule', plaane selliste funktsioonide rakendamiseks?<\/p><\/blockquote>\n<p>Tasub aru saada, kuidas toimub dubleerimise v\u00e4ltimine. See, millest ma n\u00fc\u00fcd r\u00e4\u00e4gin, ei kuulu k\u00fcsimuse alla, kuid igaks juhuks tasub sellest meeles pidada.<\/p>\n<p><\/p>\n<p>Replitseeritavates tabelites liitmisel toimub kogu sisestatud blokkide dedupeerimine. Kui te uuesti sisestate sama bloki, mis sisaldab sama arvu samu ridu samas j\u00e4rjekorras, siis andmed dedupeeritakse. Te saate vastuseks \"Ok\" insert'i kohta, kuid tegelikult salvestatakse ainult \u00fcks andmepakk, ja see ei dubleeru.<\/p>\n<p><\/p>\n<p>See on vajalik selguse huvides. Kui sisestamisel saate \"Ok\", t\u00e4hendab see, et teie andmed on sisestatud. Kui saite vea ClickHouse'lt, siis andmed ei ole sisestatud ja sisestamine tuleb korrata. Kuid kui sisestamise ajal \u00fchendus katkeb, ei tea te, kas andmed on sisse viidud v\u00f5i mitte. Ainus v\u00f5imalus on sisestamine uuesti korrata. Kui andmed olid t\u00f5eliselt sisestatud ja te sisestate need uuesti, toimub blokkide dedupeerimine. See on vajalik dubleeritud andmete v\u00e4ltimiseks. <\/p>\n<p><\/p>\n<p>Ja on oluline, kuidas see t\u00f6\u00f6tab materialiseeritud vaadete jaoks. Kui andmed on lisanud p\u00f5hitausta sisestamisel dedupeerimise, siis materialiseeritud vaates ei l\u00e4he need samuti l\u00e4bi.<\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd k\u00fcsimuse juurde. Teie olukord on keerulisem, kuna te salvestate individuaalsete ridade dubleeringuid. See t\u00e4hendab, et mitte kogu blokk on dubleeritud, vaid just konkreetsed read, ja need taustal kokku t\u00f5mbuvad. T\u00f5epoolest, andmed kokku t\u00f5mbuvad p\u00f5hitaustas, kuid materialiseeritud vaates l\u00e4hevad need mitte kokku t\u00f5mbunud ja sulandumisel ei juhtu materialiseeritud vaadetega midagi. Kuna materialiseeritud vaade on mitte midagi muud kui insert'i k\u00e4ivitaja. Muude operatsioonide puhul ei juhtu sellega midagi lisaks.<\/p>\n<p><\/p>\n<p>Ja ma ei saa siin kuidagi r\u00f5\u00f5mu pakkuda. Ainult tuleb otsida konkreetset lahendust selle juhtumi jaoks. N\u00e4iteks, kas materialiseeritud vaates on v\u00f5imalik samuti teostada selle asendamine, ja v\u00f5ib-olla t\u00f6\u00f6tab ka dedupeerimise meetod samamoodi. Kuid kahjuks ei ole see alati v\u00f5imalik. Kui see on agregatiivne, siis ei saa. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Meil oli samuti omaaegne keeruline s\u00fcsteem. Oli probleem, et oli reklaamiedastusi ja teatud andmeid, mida saame reaalajas n\u00e4idata \u2013 need on lihtsalt n\u00e4itamised. Need harva korduvad, aga kui see juhtub, siis me l\u00f5puks ikkagi sulgeme need. Ja oli asju, mida ei tohtinud dubleerida \u2013 klikkimised ja kogu see lugu. Ent oli soov neid ka peaaegu kohe n\u00e4idata.<\/p>\n<p><\/p>\n<p>Kuidas materjaliseeritud vaateid loodi? Oli vaateid, kuhu kirjutati otse \u2013 suundus katkematutest andmetest ja kirjutati vaadetes. Seal mingil hetkel andmed ei olnud eriti \u00f5iged, nad dubleerusid ja nii edasi. Ja on teine tabel, kus nad n\u00e4evad t\u00e4pselt samasugused v\u00e4lja nagu materjaliseeritud vaated, mis t\u00e4hendab, et struktuurilt on nad t\u00e4iesti v\u00f5rdsed. Aeg-ajalt arvutame andmed \u00fcmber, loeme andmeid ilma dubleeringuteta ja kirjutame nendesse tabelitesse. <\/p>\n<p><\/p>\n<p>K\u00e4isime API kaudu \u2013 ClickHouse'i k\u00e4sitsi see ei t\u00f6\u00f6ta. Ja API vaatab: kui mul on tabelis viimase lisamise kuup\u00e4ev, kus on garanteeritult \u00f5iged, arvestusega andmed, siis teeb ta p\u00e4ringu \u00fchte tabelisse ja teise tabelisse. \u00dchest tabelist valib ta andmed teatud aja piires ja teisest t\u00e4idab puuduvad, mida pole veel arvestatud. Ja see t\u00f6\u00f6tab, aga mitte \u00fche ClickHouse'i vahenditega.<\/p>\n<p><\/p>\n<p>Kui teil on mingi API \u2013 anal\u00fc\u00fctikutele, kasutajatele \u2013 siis see on p\u00f5him\u00f5tteliselt variant. Te alati m\u00e4\u00e4rate, arvutate \u00fcmber. Seda saab teha kord \u00f6\u00f6p\u00e4evas v\u00f5i mingil muul ajal. Te ise valite ajavahemiku, mida te ei vaja ja mis ei ole kriitiline.<\/p>\n<p><\/p>\n<h2 id=\"anchordashboardanchorv-clickhouse-mnogo-logov-kak-ya-mogu-videt-vsyo-chto-proishodit-s-serverom-vnbspmomente\"><noindex><a rel=\"nofollow\" name=\"dashboard\"><\/a><\/noindex>ClickHouse'is on palju logisid. Kuidas ma saan n\u00e4ha k\u00f5ike, mis serveriga minutis juhtub?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse'is on v\u00e4ga suur hulk erinevaid logisid, ja see hulk suureneb. Uutes versioonides on m\u00f5ned neist isegi vaikimisi sisse l\u00fclitatud, vanades versioonides tuleb need uuendamise ajal sisse l\u00fclitada. Sellegipoolest neid tuleb aina rohkem ja rohkem. Sooviksin n\u00e4ha l\u00f5puks, mis mul serveriga praegu toimub, v\u00f5ib-olla mingil \u00fclevaatelehelt. <\/p>\n<p>Kas teil ei ole ClickHouse meeskonnas v\u00f5i teie s\u00f5prade meeskondades kedagi, kes toetaks valmis armatuurlaudade funktsionaalsust, mis kuvab neid logisid juba valmistoote kujul? L\u00f5ppkokkuv\u00f5ttes on logisid vaadata ClickHouse'is tore. Kuid oleks tore, kui see oleks juba armatuurlaua vormis valmis. Ma naudiks seda. <\/p><\/blockquote>\n<p>Armatuurlaud on olemas, t\u00f5si, need ei ole standardiseeritud. Meie ettev\u00f5ttes kasutab ClickHouse'i umbes 60 meeskonda ja k\u00f5ige kummalisem on see, et paljudel neist on armatuurlaud, mille nad ise tegid, ja need on pisut erinevad. M\u00f5ned meeskonnad kasutavad Yandex.Cloudi sisemist installatsiooni. Seal on m\u00f5ned valmis raportid, kuigi mitte k\u00f5ik vajalikud. Teistel on oma lahendused. <\/p>\n<p><\/p>\n<p>Minu kolleegidel 'Metriikast' on oma armatuurlaud Grafanas, mul on omakorda oma nende klastris. Ma vaatan seal asju nagu vahem\u00e4lu hit rate. Ja veelgi keerulisem on see, et me kasutame erinevaid t\u00f6\u00f6riistu. Omake armatuurlaud ma l\u00f5in v\u00e4ga vanal t\u00f6\u00f6riista peal, mis kannab nime Graphite-web. See on t\u00e4iesti inetu. Ja ma kasutan seda siiani, kuigi Grafana oleks ilmselt mugavam ja ilusam. <\/p>\n<p><\/p>\n<p>Armatuurlauad p\u00f5hiasjad on \u00fchesugused. Need on s\u00fcsteemi m\u00f5\u00f5dikud klastri kohta: CPU, m\u00e4lu, ketas, v\u00f5rk. Teised \u2014 samaaegsete p\u00e4ringute arv, samaaegsete merge'ide arv, p\u00e4ringute arv sekundis, maksimaalne t\u00fckkide arv MergeTree tabelite partitsioonide jaoks, replikatsiooni viivitus, replikatsiooni j\u00e4rjekorra suurus, sekundis sisestatud ridade arv, sekundis sisestatud plokkide arv. See k\u00f5ik tuleb mitte logidest, vaid m\u00f5\u00f5dikutest.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Aleksei, soovin veidi t\u00e4psustada. On Grafana. Grafanal on andmeallikas, milleks on ClickHouse. See t\u00e4hendab, et ma saan Grafanast teha p\u00e4ringuid otse ClickHouse'i. ClickHouse'is on logide tabel, mis on k\u00f5igil sama. Tahan Grafanas p\u00f6\u00f6rduda sellele logide tabelile ja n\u00e4ha neid p\u00e4ringuid, mida minu server esitab. Oleks suurep\u00e4rane, kui selline armatuurlaud olemas oleks.<\/p>\n<p><\/p>\n<p>Olen selle ise kokku pannud. Kuid mul on k\u00fcsimus \u2014 kui see k\u00f5ik on standardiseeritud ja Grafanat kasutab k\u00f5ikjal, siis miks ei ole Yandexis sellist ametlikku armatuurlauda?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Tegelikult toetab ClickHouse'i andmeallikat praegu Altinity. Ja ma tahan lihtsalt anda suuniseid, kuhu kaevata ja kelle poole p\u00f6\u00f6rduda. Neilt v\u00f5ib k\u00fcsida, sest \"Yandex\" teeb ClickHouse'i, mitte selle \u00fcmber toimuvat. Altinity on peamine ettev\u00f5te, mis praegu ClickHouse'i edendab. Nad ei j\u00e4ta seda lihtsalt niisama, vaid toetavad seda. Sest p\u00f5him\u00f5tteliselt, et laadida armatuurlaud Grafana veebilehele, on vaja lihtsalt registreeruda ja see \u00fcles laadida - erilisi probleeme ei ole. <\/p>\n<p><\/p>\n<p><strong>Aleksei Milovidov:<\/strong> Viimase aasta jooksul on ClickHouse'i juurde lisandunud palju uusi v\u00f5imalusi p\u00e4ringute profileerimiseks. Iga p\u00e4ringu ressursside kasutamise kohta on olemas meetrikad. Ja hiljuti lisati veelgi madalama taseme p\u00e4ringu profileerija, et n\u00e4ha, kus p\u00e4ring kulutab iga millisekundi. Kuid selle funktsionaalsuse kasutamiseks pean avanema konsooli klient ja sisestama p\u00e4ringu, mille ma pidevalt unustan. Olen selle kuhugi salvestanud ja unustan pidevalt, kuhu t\u00e4pselt. <\/p>\n<p><\/p>\n<p>Sooviksin, et oleks t\u00f6\u00f6riist, kus on lihtsalt kirjas - siin on teie rasked p\u00e4ringud, r\u00fchmitatud p\u00e4ringute klasside j\u00e4rgi. Vajutasin m\u00f5nele neist ja mulle \u00f6eldakse, et see on raske, sest see p\u00f5hjus. Praegu sellist lahendust ei ole. Ja t\u00f5eliselt kummaline on, et kui inimesed k\u00fcsivad minult: \"Kas on olemas valmis armatuurlauad Grafana jaoks?\", \u00fctlen ma: \"Minge Grafana veebilehele, seal on kogukond 'Armatuurlaud', ja seal on armatuurlaud Dima poolt, armatuurlaud Kostjani poolt. Mis need on, ma ei tea, ma ise ei ole kasutanud.\"<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>Kuidas m\u00f5jutada sulandumisi, et server ei kukuks OOM-i?<\/h2>\n<p><\/p>\n<blockquote><p>Mul on tabel, millel on vaid \u00fcks partitsioon, see on ReplacingMergeTree. Olen sinna andmeid kirjutanud juba neli aastat. Mul oli vaja teha seal alter ja eemaldada m\u00f5ned andmed.<\/p>\n<p>Tehtud, ja selle p\u00e4ringu t\u00f6\u00f6tlemise k\u00e4igus h\u00e4vis kogu m\u00e4lu k\u00f5igil klastrite serveritel, ja k\u00f5ik klastrite serverid kukkusid korraga OOM-i. Siis t\u00f5usid nad k\u00f5ik koos \u00fcles, hakkasid seda sama operatsiooni, selle andmepaketi sulandumist, t\u00e4itma ja kukkusid taas OOM-i. Siis t\u00f5usid nad j\u00e4lle ja kukkusid uuesti. Ja see asi ei l\u00f5petanud.<\/p>\n<p>Hiljem selgus, et see oli tegelikult viga, mille nad parandasid. See on v\u00e4ga tore, suured t\u00e4nud. Kuid paha tunne j\u00e4i. Ja n\u00fc\u00fcd, kui ma m\u00f5tlen sellele, et pean mingit \u00fchinemist tabelis tegema, tekib mul k\u00fcsimus - miks ma ei saa nende \u00fchinete peale mingil moel m\u00f5juda? N\u00e4iteks piirata neid vajaliku m\u00e4luhulga j\u00e4rgi v\u00f5i lihtsalt nende arvu osas, mis konkreetset seda tabelit t\u00f6\u00f6tleb.<\/p>\n<p>Mul on tabel, mis nimetatakse \"M\u00f5\u00f5dikud\", palun t\u00f6\u00f6tle seda kahes voos. \u00c4ra tee k\u00fcmmet v\u00f5i viit \u00fchinemist paralleelselt, tee kahes. Ma arvan, et kahes on mul m\u00e4lu piisavalt, aga k\u00fcmne t\u00f6\u00f6tlemiseks v\u00f5ibolla ei piisa. Miks hirm j\u00e4\u00e4b? Sest tabel kasvab ja kunagi satun olukorda, et mitte lihtsalt vea t\u00f5ttu, vaid seet\u00f5ttu, et andmed hakkavad muutuma nii suurtes kogustes, et mul lihtsalt serveris m\u00e4lu ei piisa. Ja siis server kukub OOM-i, kui toimub \u00fchinemine. Lisaks saan ma mutatsiooni t\u00fchistada, aga \u00fchinemisi mitte.<\/p><\/blockquote>\n<p>Teate, \u00fchinemiste ajal ei kukku server OOM-i, sest \u00fchinemisel kasutatakse m\u00e4lu ainult \u00fche v\u00e4ikese andmealase jaoks. Nii et k\u00f5ik on h\u00e4sti s\u00f5ltumata andmete mahust.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Hea. Siin on selline n\u00fcanss, et p\u00e4rast seda, kui veaviga parandus tehti, laadisin endale uue versiooni ja tegin teisel, v\u00e4iksemal tabelil, kus on palju partitsioone, sarnase toimingu. Ja \u00fchinemise k\u00e4igus p\u00f5letati serveris umbes 100 GB m\u00e4lu. Mul oli 150 GB h\u00f5ivatud, 100 GB v\u00f5eti, ja j\u00e4i 50 GB, seega ei langenud ma OOM-i.<\/p>\n<p><\/p>\n<p>Mis mind praegu kaitseb selle eest, et ma ei langeks OOM-i, kui see t\u00f5epoolest tarbib 100 GB m\u00e4lu? Kuidas olla olukorras, kui \u00e4kki j\u00e4\u00e4b m\u00e4lu \u00fchinemiste ajal otsa?<\/p>\n<p><\/p>\n<p><strong>Aleksei Milovidov:<\/strong> On the one hand, there is the issue that memory consumption during merges is not limited. On the other hand, if a merge has been scheduled, it needs to be executed since it is recorded in the replication log. The replication log contains the actions necessary to bring the replica into a consistent state. If we do not perform manual actions that would revert this replication log, the merge will have to be executed one way or another.<\/p>\n<p><\/p>\n<p>Of course, it would be beneficial to have a memory limit that protects against OOM just in case. It wouldn\u2019t help the merge to complete; it would start again, reach a certain threshold, throw an exception, and then start over \u2014 nothing good would come from this. However, implementing such a limit would be useful in principle.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Kuidas toimub Golang-i draiveri arendus ClickHouse jaoks?<\/h2>\n<p><\/p>\n<blockquote><p>Golang-i draiver, mille kirjutas Kirill Shvakov, n\u00e4ib n\u00fc\u00fcd olevat ametlikult ClickHouse meeskonna poolt toetatud. See <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">asub ClickHouse repozitooriumis<\/a><\/noindex>, see on n\u00fc\u00fcd suures ja t\u00f5elises vormis.<\/p>\n<p>V\u00e4ike m\u00e4rkus. On olemas suurep\u00e4rane ja k\u00f5igile meeldiv l\u00f5pmatute j\u00e4rkj\u00e4rguliste vormide ladustamine - see on Vertica. Nendel on ka oma ametlik Python draiver, mida toetavad Vertica arendajad. On olnud mitmeid kordi, kus ladustamise ja draiveri versioonid on t\u00f5eliselt kaugele l\u00e4inud ning draiver on mingi hetk l\u00f5petanud t\u00f6\u00f6tamise. Ja teine asi. Selle ametliku draiveri tugi, tundub mulle, toimib s\u00fcsteemiga \"nippli\" - sa kirjutad neile probleemist ja see j\u00e4\u00e4b igaveseks rippuma.<\/p>\n<p>Mul on kaks k\u00fcsimust. Praegu on Kirilli Golang draiver peaaegu vaikimisi viis, kuidas Golang suhelda ClickHouse'iga. Ainult, et keegi suhtleb endiselt http liidese kaudu, sest talle meeldib nii. Kuidas seda draiverit arendatakse? Kas see s\u00fcnkroniseeritakse m\u00f5nede ladustamise oluliste muudatustega? Ja milline on probleemide arutamise kord? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> First of all, it\u2019s about how everything works bureaucratically. This issue has not been discussed, so I have nothing to answer.<\/p>\n<p><\/p>\n<p>To answer the question about the issue, a brief history of the driver is needed. I worked in a company that dealt with a lot of data. It was an advertising engine with a massive amount of events that needed to be stored somewhere. At some point, ClickHouse appeared. We flushed data into it, and for a while, everything was fine until ClickHouse crashed. At that time, we decided that we didn\u2019t need it. <\/p>\n<p><\/p>\n<p>A year later, we returned to the idea of using ClickHouse, and we needed to find a way to write data into it. The premise was that the hardware was very weak, and there were limited resources. But we always worked this way, so we looked towards the native protocol.<\/p>\n<p><\/p>\n<p>Since we were working in Go, it was clear that we needed a driver in Go. I worked on it almost full-time \u2014 it was my job task. We managed to get it to a certain point where it was understood that no one besides us would use it. Then CloudFlare came along with exactly the same problem, and for a while, we collaborated very closely because they had the same tasks. We addressed this both in ClickHouse itself and in the driver. <\/p>\n<p><\/p>\n<p>Mingil hetkel l\u00f5petasin ma nende asjadega tegelemise, kuna mu tegevus ClickHouse'i osas ja t\u00f6\u00f6ga on natuke muutunud. Seet\u00f5ttu ei sulgu probleemid. Vahel commitivad repo'sse inimesed, kellel endal on midagi tarvis. Siis vaatan ma pull request'e ja vahel isegi midagi ise parandan, kuid see juhtub harva.<\/p>\n<p><\/p>\n<p>Soovin tagasi p\u00f6\u00f6rduda draiveri juurde. M\u00f5ni aasta tagasi, kui see k\u00f5ik algas, oli ClickHouse ka teistsugune ja erinevate v\u00f5imalustega. Praegu on selgus, kuidas draiverit paremini \u00fcmber teha. Kui see juhtub, siis versioon 2 on igal juhul \u00fchilduv, arvestades juba tekkivaid probleeme. <\/p>\n<p><\/p>\n<p>Kuidas seda korraldada, ma ei tea. Mul endal ei ole palju aega. Kui m\u00f5ni inimene hakkab draiverit t\u00e4iustama, saan neid aidata ja r\u00e4\u00e4kida, mida teha. Kuid Yandexi aktiivne osalus projekti arendamisel pole seni kuidagi arutatud. <\/p>\n<p><\/p>\n<p><strong>Aleksei Milovidov:<\/strong> Tegelikult ei ole praegu selle draiverite osas mingit b\u00fcrokraatiat. Ainus asi on see, et need on viidud ametlikku organisatsiooni, st see draiver on tunnustatud ametlikuks lahenduseks Go jaoks. On ka teisi draivereid, kuid need on eraldi. <\/p>\n<p><\/p>\n<p>Meil ei ole nende draiverite jaoks sees mingit arendust. K\u00fcsimus on selles, kas me saame palgata eraldi isiku, mitte spetsiaalselt selle draiveri jaoks, vaid k\u00f5igi kogukonna draiverite arendamiseks v\u00f5i leidme kedagi v\u00e4ljastpoolt. <\/p>\n<p><\/p>\n<h2 id=\"anchorlazy-loadanchorvneshniy-slovar-ne-podnimaetsya-posle-perezagruzki-snbspvklyuchennoy-nastroykoy-lazy_load-chto-delat\"><noindex><a rel=\"nofollow\" name=\"lazy-load\"><\/a><\/noindex>V\u00e4line s\u00f5nastik ei t\u00f5use p\u00e4rast taask\u00e4ivitamist koos lazy_load seadistuse aktiveerimisega. Mida teha?<\/h2>\n<p><\/p>\n<blockquote><p>Meil on lazy_load seadistus aktiveeritud ja p\u00e4rast serveri taask\u00e4ivitamist s\u00f5nastik ei t\u00f5use ise. See t\u00f5useb \u00fcles ainult siis, kui kasutaja p\u00f6\u00f6rdub selle s\u00f5nastiku poole. Ja esimese p\u00f6\u00f6rdumise korral annab see vea. Kas on v\u00f5imalik ClickHouse'i vahenditega s\u00f5nastikke automaatselt laadida v\u00f5i peame alati j\u00e4lgima nende valmidust, et kasutajad ei saaks vigu?<\/p>\n<p>V\u00f5ib-olla on meil vana versioon ClickHouse'ist, seega ei laaditud s\u00f5nastikku automaatselt. Kas see on v\u00f5imalik?<\/p><\/blockquote>\n<p>Esiteks, s\u00f5nastikke saab sundida laadima p\u00e4ringu abil. <strong>system reload dictionaries<\/strong>. Teiseks, mis puudutab viga \u2014 kui s\u00f5nastik on juba laaditud, siis p\u00e4ringud t\u00f6\u00f6tavad nende andmete alusel, mis on juba laaditud. Kui s\u00f5nastik ei ole veel laaditud, siis see laaditakse kohe p\u00e4ringu ajal.<\/p>\n<p><\/p>\n<p>Raskete s\u00f5nastike jaoks ei ole see eriti mugav. N\u00e4iteks, kui on vaja tuua miljon rida MySQL-ist. Keegi teeb lihtsa selecti, kuid see select ootab seda miljonit rida. Siin on kaks lahendust. Esimene \u2014 v\u00e4lja l\u00fclitada lazy_load. Teine \u2014 kui server t\u00f5stetakse \u00fcles, enne koormuse peale panemist teha <strong>s\u00fcsteem laadib s\u00f5nastikku uuesti<\/strong> v\u00f5i lihtsalt esitada p\u00e4ring, mis kasutab s\u00f5nastikku. Siis s\u00f5nastik laaditakse. Peate ise j\u00e4lgima s\u00f5nastike k\u00e4ttesaadavust, kui lazy_load seade on sisse l\u00fclitatud, sest ClickHouse ei t\u00f5mba neid automaatselt.<\/p>\n<p><\/p>\n<p>Viimasele k\u00fcsimusele vastus on \u2014 kas versioon on vana v\u00f5i tuleb seda siluda. <\/p>\n<p><\/p>\n<h2 id=\"anchorreload-dictionariesanchorkak-byt-snbsptem-chto-system-reload-dictionaries-ne-podgruzhaet-ni-odin-iznbspmnozhestva-slovarey-esli-hotya-by-odin-iznbspnih-padaet-snbsposhibkoy\"><noindex><a rel=\"nofollow\" name=\"reload-dictionaries\"><\/a><\/noindex>Kuidas k\u00e4ituda olukorras, kus system reload dictionaries ei lae \u00fchtki paljusid s\u00f5nastikke, kui v\u00e4hemalt \u00fcks neist kukub error'iga?<\/h2>\n<p><\/p>\n<blockquote><p>On veel k\u00fcsimus, mis puudutab system reload dictionaries. Meil on kaks s\u00f5nastikku \u2014 \u00fcks ei laeku, teine laekub. System reload dictionaries sellisel juhul ei lae \u00fchtegi s\u00f5nastikku ja tuleb spetsiifiliselt laadida konkreetne selle nime j\u00e4rgi system reload dictionary abil. Kas see on samuti seotud ClickHouse versiooniga?<\/p><\/blockquote>\n<p>Soovin r\u00f5\u00f5mustada. See k\u00e4itumine on muutunud. Kui uuendate ClickHouse'i, siis muudab see ka. Kui te ei ole rahul praeguse k\u00e4itumisega <strong>system reload dictionaries<\/strong>, uuendage, ja loodame, et see muutub paremaks.<\/p>\n<p><\/p>\n<h2 id=\"anchorconnectionanchorest-li-sposob-konfigurirovat-rekvizity-vnbspkonfige-clickhouse-no-ne-svetit-ih-prinbsposhibkah\"><noindex><a rel=\"nofollow\" name=\"connection\"><\/a><\/noindex>Kas on v\u00f5imalik konfigureerida ClickHouse'i s\u00e4tteid, kuid mitte n\u00e4idata neid vigu korral?<\/h2>\n<p><\/p>\n<blockquote><p>J\u00e4rgmine k\u00fcsimus puudutab vigu, mis on seotud s\u00f5nastikuga, nimelt andmete \u00fchendusrekvisiidid. Oleme m\u00e4\u00e4ranud \u00fchenduse rekvisiidid ClickHouse konfiguratsioonis s\u00f5nastiku jaoks ja vigade korral saame neid rekvisiiide ja parooli vastuses. <\/p>\n<p>Oleme lahendanud selle vea, viies rekvisiidid ODBC draiveri konfi. Kas on mingi v\u00f5imalus konfigureerida rekvisiidid ClickHouse konfis, ilma et need rekvisiidid vigade korral n\u00e4htavaks muutuks?<\/p><\/blockquote>\n<p>Siin on t\u00f5epoolest lahendus \u2014 m\u00e4rkida need credentials odbc.ini failis, ning ClickHouse-is m\u00e4rkida ainult ODBC Data Source Name. Muude s\u00f5nastike allikate puhul seda ei esine \u2014 ei MySQL s\u00f5nastiku ega muude, te ei tohiks parooli n\u00e4ha vea teadetes. ODBC puhul vaatan ka \u2014 kui see on olemas, tuleb see lihtsalt eemaldada.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Boonus: taustad Zoomi koosolekute jaoks<\/h2>\n<p><\/p>\n<p>Pildile klikkides avanevad k\u00f5ige visamate lugejate jaoks boonuste taustad koos Avito tehnoloogiate maskottidega. L\u00e4htume tulekahju kustutamisest koos IT-osakonna kolleegidega, v\u00f5i vanakooli arvutiklubi \u00f5hkkonnas ja peame igap\u00e4evast koosolekut silla all graffitide taustal.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse for advanced users in questions and answers\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/500678\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430&nbsp;\u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437&nbsp;\u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros. \u041e\u0431\u0441\u0443\u0436\u0434\u0430\u043b\u0438, \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438 \u043a\u0430\u043a\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0443&nbsp;\u043d\u0430\u0441 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442. \u041f\u043e&nbsp;\u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0432\u0441\u0442\u0440\u0435\u0447\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u0441&nbsp;\u043e\u0442\u0432\u0435\u0442\u0430\u043c\u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432 \u043d\u0430&nbsp;\u043d\u0430\u0448\u0438 \u0438 \u0437\u0440\u0438\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u043f\u0440\u043e&nbsp;\u0431\u044d\u043a\u0430\u043f\u044b, \u0440\u0435\u0448\u0430\u0440\u0434\u0438\u043d\u0433 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0441\u043b\u043e\u0432\u0430\u0440\u0438, Golang-\u0434\u0440\u0430\u0439\u0432\u0435\u0440 \u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u0435\u0440\u0441\u0438\u0439 ClickHouse. \u041e\u043d\u0430 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80776,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80775","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47ClickHouse edasij\u00f5udnud kasutajatele k\u00fcsimustes ja vastustes | ProHoster","description":"Aprillis plaanis Avito insenerid korraldada veebikohtumised ClickHouse peaarendaja Alexey Milovidovi ja Integrosest p\u00e4rit Golang-arendaja Kirill Shvakoviga.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","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\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster","og:description":"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","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-05-08T11:42:47+00:00","article:modified_time":"2020-05-08T11:42:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80775","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 16:11:22","updated":"2022-09-28 05:48:13","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\/80775","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=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}