{"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 edasij\u00f5udluse kasutajatele k\u00fcsimustes ja vastustes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Aprillis plaanisid Avito insenerid&nbsp;online-kohtumisi ClickHouse peaarendaja Aleksei Milovidovi ja Integrosest p\u00e4rit Golang-arendaja Kirill Shvakoviga. Arutati, kuidas me kasutame andmebaasi halduss\u00fcsteemi ja milliste probleemidega me kokku puutume. <\/p>\n<p><\/p>\n<p>Koos kohtumise teemadest v\u00e4ljapool, koostasime artikli ekspertide vastustega meie ja vaatajate k\u00fcsimustele varukoopiate, andmete reshardedimise, v\u00e4liste s\u00f5naraamatute, Golang-draiveri ja ClickHouse versioonide uuendamise kohta. See v\u00f5ib olla kasulik arendajatele, kes juba aktiivselt t\u00f6\u00f6tavad Yandexi andmebaasiga ja huvituvad selle olevikust ja tulevikust. Peamiselt on Aleksei Milovidovi vastused, kui pole m\u00e4rgitud teisiti. <\/p>\n<p><\/p>\n<p>Ole ettevaatlik, allosas on palju teksti. Loodame, et k\u00fcsimustega sisu aitab teil paremini orienteeruda.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse edasij\u00f5udluse kasutajatele k\u00fcsimustes ja vastustes\" 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\">Sisu<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse pidevalt uueneb, kuid meie andmed ei. Mida sellega teha?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Millised on praegused parimad praktikad ClickHouse andmete varundamisel?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">Kas on v\u00f5imalik korraldada replikate kontrollitud mahaj\u00e4\u00e4must ribades?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">Kuidas k\u00e4ituda, kui tabeli struktuur on muutunud?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Millised on praegu parimad praktikad andmete reshardedimisel?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">ClickHouse'is on utiliit clickhouse-copier. Kas v\u00f5iksite sellest r\u00e4\u00e4kida?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Teiega oli pilootprojekt, mis kandis nime resharding. Mis selle saatus on?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">Kas on v\u00f5imalik enne aeglastele kettale liikumist k\u00f5iki andmete osi kokku sulatada?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Kuidas liikuda uusimatele ClickHouse versioonidele, kui ei ole v\u00f5imalik eelnevalt \u00fchilduvust kontrollida?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">K\u00e4sku Kill query peaks l\u00f5petama p\u00e4ringud, kuid see ei toimi. Miks?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Kuidas arvutada vastamise aega lugemisekoormuse korral?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Mida ClickHouse'is h\u00e4\u00e4lestada, et rohkem andmeid m\u00e4lus oleks?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Kuidas kohandada storage_configuration, et andmeid hoida m\u00e4lus?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Kui palju unikaalseid v\u00e4\u00e4rtusi on Low Cardinality efektiivne?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Millised on parimad praktikad k\u00fcmne miljardi reaga tabelis t\u00e4isteksti otsimise osas?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Kuidas korraldada ClickHouse'i ligip\u00e4\u00e4s suurt hulka kasutajaid?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">Kas on v\u00f5imalik anda \u00fche p\u00e4ringu tulemused k\u00fcmnele kliendile?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Kuidas suhelda as\u00fcnkroonsete operatsioonide ja materialiseeritud vaadetega?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">ClickHouse'is on palju logisid. Kuidas saan n\u00e4ha k\u00f5ike, mis serveriga SYRK-kallakute ajal toimub?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Kuidas m\u00f5jutada liitumisi nii, et server ei kukuks OOM-i?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Kuidas toimub Golang-draiveri areng ClickHouse'i jaoks?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">V\u00e4line s\u00f5naraamat ei t\u00f5use p\u00e4rast laadimist lahti libistades lazy_load s\u00e4tted. Mida teha?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Kuidas lahendada olukord, kus system reload dictionaries ei laadi mitte \u00fchtegi paljusid s\u00f5naraamatuid, kui v\u00e4hemalt \u00fcks neist kukub veaga?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Kas on v\u00f5imalik konfigureerida ClickHouse konfiguraatoris aktsess-juhiseid, kuid mitte n\u00e4idata neid vead?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Boonus: Zoomi taustad koos kohtumistelt<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Kui teksti lugemine ei huvi, saab vaadata koosolekute salvestust <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">meie YouTube kanalis<\/a><\/noindex>. Aegkoodid on video esimeses kommentaaris.<\/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 pidevalt uueneb, kuid meie andmed ei. Mida sellega teha?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse pidevalt uueneb, kuid meie andmed, mis on optimize final protsessitud, ei uuene ja j\u00e4\u00e4vad varukoopiasse. <\/p>\n<p>Oletame, et meil oli mingi probleem ja andmed kadusid. Otsustasime taastuda ja selgus, et vanad partiid, mis on serverite varukoopias, eralduvad v\u00e4ga palju hetkel kasutatava ClickHouse versiooniga. Mida teha, kui nii juhtub ja kas see on v\u00f5imalik?<\/p><\/blockquote>\n<p>Olukord, kus olete varukoopiatest andmed taastanud vanas formaadis, ja need ei \u00fchendu uue versiooniga, on v\u00f5imatu. Me j\u00e4lgime, et andmeformaadid ClickHouse'is j\u00e4\u00e4ksid alati tagasimugavad. See on olulisem, kui funktsionaalsuse tagasimugavus, kui m\u00f5ne harva kasutatava funktsiooni k\u00e4itumine on muutunud. Uue versiooniga peaks ClickHouse alati suutma lugeda andmeid, mis asuvad kettal. See on seadus. <\/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 praegused parimad praktikad ClickHouse andmete varundamisel?<\/h2>\n<p><\/p>\n<blockquote><p>Kuidas teha varukoopiaid arvesse v\u00f5ttes, et meil on operaatorid optimize final, hiiglaslik andmebaas terabaitides ja andmed, mida v\u00e4rskendatakse, oletame, viimase kolme p\u00e4eva jooksul, ja nende \u00fcle enam ei opereerita? <\/p>\n<p>Me v\u00f5ime lihtsalt kirjutada oma lahenduse ja bash'is kirjutada: t\u00f5sta niimoodi ja niimoodi need varukoopiad. V\u00f5ib-olla pole uue ratta leiutamist ja see on juba ammu \u00fcnnes inventeeritud? <\/p><\/blockquote>\n<p>Esmalt parimate praktikate osas. Minu kolleegid kinnitavad alati, et kui esitatakse k\u00fcsimusi varukoopiate kohta, tuleks meeles pidada teenust \"Yandex.Cloud\", kus see \u00fclesanne on juba lahendatud. Nii et kasuta seda, kui v\u00f5imalus on. <\/p>\n<p><\/p>\n<p>ClickHouse'is pole t\u00e4ielikku lahendust, mis oleks sada protsenti integreeritud varukoopiate jaoks. On olemas m\u00f5ned malli, mida saab kasutada. T\u00e4ieliku lahenduse saamiseks tuleb natuke k\u00e4sitsi vaeva n\u00e4ha v\u00f5i luua skriptide kaudu \u00fcmberpakkingud.<\/p>\n<p><\/p>\n<p>Alustan k\u00f5ige lihtsamate lahendustega ja l\u00f5petan k\u00f5ige keerulisematega, s\u00f5ltuvalt andmete mahust ja klastrist. Mida suurem klaster, seda keerulisem on lahendus.<\/p>\n<p><\/p>\n<p>Kui andmetabel v\u00f5tab vaid paar gigabaiti, on varukoopia tegemine v\u00f5imalik j\u00e4rgmiselt: <\/p>\n<p><\/p>\n<ol>\n<li>Salvestada tabelite m\u00e4\u00e4ratlemise ehk metaandmed \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Tehke dump ClickHouse'i kliendi abil \u2014 <strong>select<\/strong> * <strong>from table<\/strong> faili. Vaikimisi saate faili TabSeparated formaadis. Kui soovite t\u00f5husamat varianti, siis v\u00f5ib kasutada Native formaati. <\/li>\n<\/ol>\n<p><\/p>\n<p>Kui andmete maht on suurem, siis varukoopia tegemine v\u00f5tab rohkem aega ja rohkem ruumi. Seda nimetatakse loogiliseks varukoopiaks, mis pole seotud ClickHouse'i andmeformaadiga. Kui see olemas on, siis \u00e4\u00e4rmuslikel juhtudel v\u00f5ite varukoopia v\u00f5tta ja laadida MySQL'i taastamiseks. <\/p>\n<p><\/p>\n<p>Edasij\u00f5udnumate juhtumite jaoks on ClickHouse'is v\u00e4lja t\u00f6\u00f6tatud v\u00f5imalus luua partitsioonide snapshots kohalikus failis\u00fcsteemis. See v\u00f5imalus on k\u00e4ttesaadav 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 \u00fchtlaselt \u00fche tabeli kohta \u00fchel shardil, seega ei ole v\u00f5imalik selliselt luua \u00fchtlast snapshot'i kogu klastrile. Kuid enamiku \u00fclesannete jaoks see ei ole vajalik, ja piisab, kui igal shardil p\u00e4ring t\u00e4ita ja \u00fchtlane snapshot saada. See luuakse hardlink'ide kujul ning seet\u00f5ttu ei v\u00f5ta see t\u00e4iendavat ruumi. Seej\u00e4rel kopeerite selle snapshot'i varukoopia serverisse v\u00f5i salvestusse, mida kasutate varukoopiate jaoks.<\/p>\n<p><\/p>\n<p>Sellise varukoopia taastamine on piisavalt lihtne. Esiteks \u2014 looge tabelid olemasolevate tabeli m\u00e4\u00e4ratlemiste p\u00f5hjal. Seej\u00e4rel kopeerite salvestatud partitsioonide snapshot'id Directory-Detached andmetabelite jaoks ja t\u00e4idate p\u00e4ringu <strong>attach partition<\/strong>. Selline lahendus sobib suuremahuliste andmete jaoks. <\/p>\n<p><\/p>\n<p>M\u00f5nikord on vajalik midagi veelgi \u00e4gedamat \u2014 olukordades, kus teil on k\u00fcmneid v\u00f5i isegi sadu terabait iga serveri kohta ja sadu servereid. Siin on lahendus, mille ma n\u00e4gin kolleegidelt \"Yandex.Metrikast\". Ma ei soovitaks seda k\u00f5igile \u2014 lugege ja otsustage ise, kas see sobib v\u00f5i mitte. <\/p>\n<p><\/p>\n<p>Esmalt peate looma mitu serverit suurte k\u00f5vakettamoodulitega. Edasi peate nendel serveritel k\u00e4ivitama mitu ClickHouse'i serverit ja seadistama need nii, et nad t\u00f6\u00f6taksid nagu veel \u00fcks replikatsioon sama shard'i jaoks. Seej\u00e4rel kasutage nende serverite puhul failis\u00fcsteemi v\u00f5i mingit t\u00f6\u00f6riista, mis v\u00f5imaldab luua snapshots. Siin on kaks varianti. Esimene variant on LVM snapshots, 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 mingi ruumi. Loomulikult, kui andmed muutuvad, siis aja jooksul ruum suureneb. Selle snapshot'i saab igal hetkel v\u00e4lja v\u00f5tta ja andmeid taastada, selline kummaline lahendus. Pluss tuleb veel piirata neid replikatsioone konfiguratsioonis, et nad ei prooviks liidriteks saada.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>Kas on v\u00f5imalik korraldada replikate kontrollitud mahaj\u00e4\u00e4must ribades?<\/h2>\n<p><\/p>\n<blockquote><p>Sel aastal kavatsete teha burlisse ClickHouse'is. Kas on v\u00f5imalik organiseerida kontrollitud replikatsioonide mahaj\u00e4\u00e4must? Tahaksime selle abil end kaitsta negatiivsete stsenaariumite eest alterite ja teiste muudatuste korral. <\/p>\n<p>Kas on v\u00f5imalik teostada mingisuguseid rollback'e alterite jaoks? N\u00e4iteks olemasolevas burlis v\u00f5tta ja \u00f6elda, et sealt edasi rakendage muudatusi, aga alates sellest hetkest l\u00f5petage muudatuste rakendamine?<\/p>\n<p>Kui meie klastrisse tuleb k\u00e4sk ja t\u00f5rjub selle, siis on meil olemas tingimuslik replikatsioon, mis on mahaj\u00e4\u00e4nud tunni v\u00f5rra, kus me saame \u00f6elda, et kas me kasutame selle hetke jaoks just seda, aga viimase k\u00fcmne minuti muudatusi ei rakenda? <\/p><\/blockquote>\n<p>Esiteks kontrollitud replikatsioonide mahaj\u00e4\u00e4muse kohta. Selliseid p\u00e4ringuid on kasutajatelt tulnud ning me l\u00f5ime GitHubis sellele vastava \u00fclesande, k\u00fcsides: \"Kui kellelegi see vajalik on, pange like, pange s\u00fcdamekuju\". Keegi ei seadnud nagu, ja \u00fclesanne suleti. Siiski on juba praegu v\u00f5imalik seda v\u00f5imalust saada, seadistades ClickHouse'i. T\u00f5si, ainult alates versioonist 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse teeb pidevalt taustal andmete sulandumist \u2014 merge. Kui sulandumine on tehtud, asendatakse mingi andmeplokk suurema plokiga. Samal ajal j\u00e4\u00e4vad varasemad andmeplokid diskile teatud ajaks.<\/p>\n<p><\/p>\n<p>Esiteks, nad j\u00e4\u00e4vad alles seni, kuni on olemas select p\u00e4ringud, mis neid kasutavad, et tagada mitteblokeeriv t\u00f6\u00f6. Select p\u00e4ringud saavad rahulikult lugeda vanadest plokkidest.<\/p>\n<p><\/p>\n<p>Teiseks on olemas ka ajapiirang \u2014 vanad andmeplokid asuvad kettal kaheksa minutit. Need kaheksa minutit on kohandatavad ja v\u00f5ivad ulatuda isegi \u00fche p\u00e4evani. See v\u00f5tab kettaruum, kuna s\u00f5ltuvalt andmevoost v\u00f5ivad viimase p\u00e4eva andmed mitte ainult kahekordistuda, vaid isegi kuni viiekordseks suureneda. Kuid t\u00f5sise probleemi korral v\u00f5ite ClickHouse'i serveri peatada ja k\u00f5ike korda seada.<\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd tekib k\u00fcsimus, kuidas see kaitseb alternatiivide eest. Siinkohal tasub s\u00fcvitsiminekut teha, kuna ClickHouse'i vanemates versioonides t\u00f6\u00f6tas alternatiiv nii, et see lihtsalt muutis otseplokke. On andmeplokk, millel on m\u00f5ned failid, ning teeme n\u00e4iteks <strong>alter drop column<\/strong>. Siis eemaldatakse see veerg f\u00fc\u00fcsiliselt k\u00f5igist plokkidest.<\/p>\n<p><\/p>\n<p>Kuid alates versioonist 20.3 on alternatiivide mehhanism t\u00e4ielikult muutunud, ja n\u00fc\u00fcd on andmeplokid alati \u00fchesugused. Need ei muutu \u00fcldse \u2014 alternatiivid t\u00f6\u00f6tavad n\u00fc\u00fcd umbes nii nagu \u00fchendamine. Selle asemel, et ploki kohal muuta, loome uue. Uues plokis muutumatud failid saavad k\u00f5vakettalinkideks, ja kui me oleme m\u00f5ne veeru eemaldanud, siis see lihtsalt uues plokis puudub. Vana plokk kustutatakse vaikimisi kaheksa minuti p\u00e4rast, ning siin saab seadistusi kohandada, nagu eespool mainitud. <\/p>\n<p><\/p>\n<p>Sama kehtib mutatsioonide t\u00fc\u00fcpi alterite kohta. Kui teete <strong>alter delete<\/strong> v\u00f5i <strong>alter update<\/strong>, ei muuda see t\u00fckki, vaid loob uue. Ja seej\u00e4rel 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>Kuidas k\u00e4ituda, kui tabeli struktuur on muutunud?<\/h2>\n<p><\/p>\n<blockquote><p>Kuidas taastada varukoopia, mis on loodud vana struktuuriga? Ja teine k\u00fcsimus seondub failis\u00fcsteemide ja snapshots'iga. Kas Btrfs sobib siin Linuxi LVM-i asemel ZFS-i?<\/p><\/blockquote>\n<p>Kui teete <strong>attach partition<\/strong> kui teil on teistsuguse struktuuriga partitsioonid, \u00fctleb ClickHouse, et seda ei saa teha. Lahendus on j\u00e4rgmine. Esiteks \u2014 luua ajutine MergeTree tippstruktuuri partitsioon vanema struktuuriga, kinnitada sinna andmed attach'i abil, teha alter p\u00e4ring. Siis saab kas andmed kopeerida v\u00f5i \u00fcmber viia ning attach uuesti teha, v\u00f5i kasutada p\u00e4ringut <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Teine k\u00fcsimus \u2014 kas Btrfs on lubatud. Esiteks, kui teil on LVM, siis piisab LVM snapshots'ist ja failis\u00fcsteem v\u00f5ib olla ext4, see ei oma t\u00e4htsust. Btrfs puhul s\u00f5ltub k\u00f5ik teie kogemustest selle kasutamisel. See on k\u00fcps failis\u00fcsteem, kuid siiski on m\u00f5ned kahtlused selle praktilise toimimise kohta konkreetses stsenaariumis. Ma ei soovitaks seda kasutada, kui teil ei ole Btrfs 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 reshardedimisel?<\/h2>\n<p><\/p>\n<p>K\u00fcsimus andmete \u00fcmbersharimise kohta on keeruline ja mitmekesine. Siin on mitmeid v\u00f5imalusi vastamiseks. \u00dchelt poolt v\u00f5ib \u00f6elda, et ClickHouse'il ei ole sisseehitatud v\u00f5imalust \u00fcmbersharimiseks. Kuid ma kardan, et see vastus ei rahulda kedagi. Seet\u00f5ttu v\u00f5ib teiselt poolt \u00f6elda, et ClickHouse'il on palju viise andmete \u00fcmbersharimiseks. <\/p>\n<p><\/p>\n<p>Kui klastris hakkab ruum l\u00f5ppema v\u00f5i see ei suuda koormust taluda, lisate uusi servereid. Kuid need serverid on vaikimisi t\u00fchjad, andmeid neis ei ole ja koormust ei toimu. Te peate t\u00f5stma andmed, et need jaotuksid \u00fchtlaselt uude, suurendatud klastrisse.<\/p>\n<p><\/p>\n<p>Esimene viis, kuidas seda teha, on kopeerida osa partitsioonidest uutele serveritele p\u00e4ringu abil <strong>alter table fetch partition<\/strong>. N\u00e4iteks kui teil on partitsioonid kuude kaupa, siis v\u00f5tate esimese kuu 2017. aastast ja kopeerite selle uuele serverile, seej\u00e4rel kopeerite kolmanda kuu m\u00f5nele teisele uuele serverile. Ja teete nii, kuni see muutub enam-v\u00e4hem \u00fchtlaselt jaotatuks.<\/p>\n<p><\/p>\n<p>\u00dclekande v\u00f5ib teostada ainult nende partitsioonide puhul, mis ei muutu kirjutamise ajal. Uute partitsioonide puhul tuleb kirjutamine peatada, kuna nende \u00fclekandmine ei ole aatomaarne. Vastasel juhul v\u00f5ite saada dublette v\u00f5i andmete puudumisi. Sellegipoolest on see meetod praktiline ja t\u00f6\u00f6tab \u00fcsna t\u00f5husalt. V\u00f5rgus edastatakse juba valmis kompressitud partitsioonid, st andmeid ei kompressita ega dekodeerita.<\/p>\n<p><\/p>\n<p>Sellel meetodil on \u00fcks puudus, ning see s\u00f5ltub shardimise skeemist, kas te olete sellele skeemile tuginenud, milline oli teie shardimise v\u00f5ti. Teie n\u00e4ites on metrikate puhul shardimise v\u00f5ti \u2014 see on r\u00e4nd. Kui teete select Distributed tabelis, minnakse see kohe k\u00f5ikidele klastri shardidele ja sealt v\u00f5etakse andmed. <\/p>\n<p><\/p>\n<p>See t\u00e4hendab, et tegelikult pole oluline, millised andmed on millisel shard'il. Peamine on see, et andmed satuvad \u00fche ja sama teekonna kaudu \u00fchele shard'ile ning see, millisele shard'ile need t\u00e4pselt langevad, pole oluline. Sellisel juhul sobib olemasolevate partitsioonide edasiviimine suurep\u00e4raselt, sest select-p\u00e4ringute korral saate te t\u00e4pselt samu andmeid \u2014 olenemata edasistest shard'imistest on skeem asjakohane.<\/p>\n<p><\/p>\n<p>Kuid on ka keerulisemaid juhtumeid. Kui rakenduse loogika tasandil on l\u00e4htutud spetsiaalsest shard'imisse skeemist, et see klient asub teatud shard'il ja p\u00e4ring saadetakse kohe sinna, mitte Distributed tabelisse. V\u00f5i kui kasutate piisavalt uut versiooni ClickHouse'ist ja olete aktiveerinud seadistuse <strong>optimize skip unused shards<\/strong>. Sel juhul anal\u00fc\u00fcsitakse select-p\u00e4ringu k\u00e4igus where-sektsiooni v\u00e4ljendit ning arvutatakse, millistele shard'idele on vaja minna vastavalt shard'imisse skeemile. See t\u00f6\u00f6tab juhul, kui andmed on hajutatud just selle skeemi kohaselt. Kui olete need k\u00e4sitsi \u00fcmber paigutanud, v\u00f5ib vastavus muutuda.<\/p>\n<p><\/p>\n<p>Nii et, see on esimene v\u00f5imalus. Ootan teie vastust: kas see sobib v\u00f5i liigume edasi.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, peamine s\u00fcsteemiadministraator Avitos<\/strong>: Alexei, see meetod, mille mainisite, ei ole liiga hea, kui tuleb laiali hajutada koormus, sealhulgas lugemiseks. Saame v\u00f5tta partitsiooni, mis on kuup\u00f5hine, ja viimase kuu viia teisele s\u00f5lmele, kuid kui tuleb p\u00e4ring nendele andmetele, koormame ainult selle. Samas tahaksime koormata kogu klastri, sest vastasel juhul k\u00e4ideldakse m\u00f5nda aega kogu lugemisekoormus ainult kahe shard'iga.<\/p>\n<p><\/p>\n<p><strong>Alexei Milovidov:<\/strong> Vastus on kummaline \u2014 jah, see on halb, kuid see v\u00f5ib ka toimida. Selgitan, kuidas t\u00e4pselt. Tuleb vaadata koormuse stsenaariumi, mis k\u00e4ib teie andmete taga. Kui need on j\u00e4lgimisandmed, siis peaaegu kindlasti saab \u00f6elda, et enamik p\u00e4ringutest tuleb v\u00e4rskete andmete j\u00e4rele. <\/p>\n<p><\/p>\n<p>Olete seadnud uued serverid, viinud vanad partitsioonid \u00fcle, kuid olete samuti muutnud, kuidas kirjutatakse v\u00e4rskeid andmeid. Ja v\u00e4rsked andmed hajutatakse \u00fcle kogu klastri. Nii et juba viie minuti p\u00e4rast koormavad viie minuti p\u00e4ringud klastrit \u00fchtlaselt ning p\u00e4eva p\u00e4rast on p\u00e4evade p\u00e4ringud samuti \u00fchtlaselt hajutatud. Kahjuks liiguvad eelneva kuu p\u00e4ringud vaid osa klastri serveritesse.<\/p>\n<p><\/p>\n<p>Kuid teil on sageli p\u00e4ringud, mis ei puuduta just 2019. aasta veebruari. T\u00f5en\u00e4oliselt, kui p\u00e4ringud k\u00e4ivad 2019. aastasse, siis on need kogu 2019. aasta kohta \u2014 suure aja jooksul, mitte mingis v\u00e4ga v\u00e4ikeses vahemikus. Ja sellised p\u00e4ringud suudavad samuti \u00fchtlaselt koormata klastrit. Aga kokkuv\u00f5ttes on teie m\u00e4rkused t\u00e4iesti \u00f5iged, et see on ad hoc lahendus, mis ei hajuta andmeid t\u00e4ielikult \u00fchtlaselt.<\/p>\n<p><\/p>\n<p>Mul on veel m\u00f5ned punktid, et vastata k\u00fcsimusele. \u00dcks neist on see, kuidas algselt teha shard'imise skeem nii, et \u00fcmber shard'imine oleks v\u00e4hem valulik. See ei ole alati v\u00f5imalik.<\/p>\n<p><\/p>\n<p>N\u00e4iteks, kui teil on j\u00e4lgimisandmed. J\u00e4lgimisandmed kasvavad kolmel p\u00f5hjusel. Esimene on ajalooliste andmete kogumine. Teine on liikluse kasv. Ja kolmas on j\u00e4lgimist vajavate asjade arvu suurenemine. Tekivad uued mikroteenused ja m\u00f5\u00f5dikud, mida tuleb salvestada. <\/p>\n<p><\/p>\n<p>V\u00f5imalik, et neist k\u00f5ige suurem kasv on seotud just kolmanda p\u00f5hjusega \u2014 see on j\u00e4lgimise kasutamise suurenemine. Ja sellisel juhul tasub vaadata koormuse olemust, millised on peamised select-p\u00e4ringud. Peamised select-p\u00e4ringud tulevad t\u00f5en\u00e4oliselt teatud m\u00f5\u00f5dikute alamkogumi p\u00f5hjal.<\/p>\n<p><\/p>\n<p>N\u00e4iteks, CPU kasutamine teatud serverites teatud teenuse poolt. Tulemuseks on teatud v\u00f5tmete alamkogum, mille abil te need andmed hankite. Ja selle p\u00e4ringu jaoks nende andmete hankimisel on see t\u00f5en\u00e4oliselt \u00fcsna lihtne ja toimub k\u00fcmnete millisekundite jooksul. Kasutatakse j\u00e4lgimisteenustes, juhtpaneelides. Loodan, et m\u00f5istan seda \u00f5igesti.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Asi on selles, et me sageli viitame ajaloolistele andmetele, kuna me reaalajas v\u00f5rdleme praegust seisu ajaloolisega. Ja meie jaoks on oluline, et meil oleks kiire juurdep\u00e4\u00e4s suurele andmemahtudele ning ClickHouse sellega suurep\u00e4raselt toime tuleb.<\/p>\n<p><\/p>\n<p>Te olete t\u00e4iesti \u00f5iged, enamus p\u00e4ringutest lugemise kohta on viimase p\u00e4eva jooksul, nagu igasugustes j\u00e4lgimis s\u00fcsteemides. Kuid ajaloolistele andmetele on ka suur koormus. See tuleb peamiselt h\u00e4ire s\u00fcsteemist, mis k\u00fcsib iga kolmek\u00fcmne sekundi tagant ClickHouse'lt: \u201eAnna mulle viimase kuue n\u00e4dala andmed. Ja n\u00fc\u00fcd tee neist mingi libisev keskmine, ja v\u00f5rrelgem praegust v\u00e4\u00e4rtust ajaloolisega.\u201d <\/p>\n<p><\/p>\n<p>Tahaksin \u00f6elda, et meil on selliste v\u00e4ga v\u00e4rskete p\u00e4ringute jaoks veel \u00fcks v\u00e4ike tabel, kus hoiame ainult kahe p\u00e4eva andmeid, ja peamised p\u00e4ringud l\u00e4hevad sinna. Suurte ajalooliste p\u00e4ringute jaoks saadame andmed suuresse jagatud tabelisse.<\/p>\n<p><\/p>\n<p><strong>Alexei Milovidov:<\/strong> Kahjuks ei sobi see h\u00e4sti teie stsenaariumi jaoks, kuid ma r\u00e4\u00e4gin kahest halvast ja keerulisest shardimise skeemist, mida ei tohiks kasutada, kuid mis on minu s\u00f5prade teenustes kasutuses. <\/p>\n<p><\/p>\n<p>On p\u00f5hiklastrid Yandex.Metrika s\u00fcndmustele. S\u00fcndmused on lehevaatamised, klikid ja \u00fcleminekud. Enamus p\u00e4ringutest l\u00e4heb konkreetsele veebisaidile. Te avate Yandex.Metrika teenuse, teil on veebisait - avito.ru, p\u00e4\u00e4sete aruande juurde ja l\u00e4heb p\u00e4ring teie saidile.<\/p>\n<p><\/p>\n<p>Kuid on ka teised p\u00e4ringud - anal\u00fc\u00fctilised ja globaalseted, mida teevad sisemised anal\u00fc\u00fctikud. Igaks juhuks mainin, et sisemised anal\u00fc\u00fctikud teevad p\u00e4ringud ainult Yandexi teenuste kohta. Kuid hoolimata sellest, v\u00f5tavad Yandexi teenused siiski m\u00e4rkimisv\u00e4\u00e4rse osa k\u00f5ikidest andmetest. Need on p\u00e4ringud mitte konkreetsete arvestite, vaid laiemate filtrite kohta.<\/p>\n<p><\/p>\n<p>Kuidas korraldada andmeid nii, et need t\u00f6\u00f6taksid efektiivselt ka \u00fche arvesti jaoks ja globaalsete p\u00e4ringute puhul? Keerukus seisneb veelgi selles, et ClickHouse'i p\u00e4ringute arv \u2018Metrika\u2019 klastris on mitu tuhat sekundis. Samuti ei suuda \u00fcks ClickHouse'i server mitte triviaalsete p\u00e4ringute korral, n\u00e4iteks mitu tuhat sekundis, toime tulla.<\/p>\n<p><\/p>\n<p>Klastri suurus on umbes kuus sadu serverit. Kui sellise klastriga lihtsalt jaotada ja saata mitu tuhat p\u00e4ringut, siis halveneb olukord veelgi v\u00f5rreldes \u00fchele serverile saatmisega. Teiselt poolt, idee selle kohta, et andmed on \u00fchtlaselt jaotatud ja me k\u00fcsime k\u00f5ikidelt serveritelt, on koheselt v\u00e4listatud.<\/p>\n<p><\/p>\n<p>On t\u00fckk vastupidine variant. Kujutage ette, et me shardime andmeid veebisaitide p\u00f5hjal, ja \u00fche saidi p\u00e4ring l\u00e4heb \u00fchte shard'i. N\u00fc\u00fcd suudab klaster t\u00f5mmata k\u00fcmme tuhat p\u00e4ringut sekundis, kuid \u00fche shard'i puhul t\u00f6\u00f6tleb m\u00f5ni p\u00e4ring liiga aeglaselt. See ei suuda enam ulatuslikult skaleeruda. Eriti kui tegemist on avito.ru veebisaidiga. Ma ei reeda saladust, kui \u00fctlen, et Avito on \u00fcks k\u00f5ige k\u00fclastatumaid veebisaite rubriigis. Ja selle t\u00f6\u00f6tlemine \u00fches shard'is oleks hullumeelsus.<\/p>\n<p><\/p>\n<p>Seet\u00f5ttu on shardimise skeem kavandatud keerukamal viisil. Kogu klaster on jagatud teatud arvu klastriteks, mida me nimetame kihtideks. Iga klastrite sees on k\u00fcmme kuni mituk\u00fcmmend shard'i. Ja kokku on selliseid klastri arvu kolmteist. <\/p>\n<p><\/p>\n<p>Kuidas see k\u00f5ik skaleerub? Klastrite arv ei muutu - nagu oli aastaid tagasi kolmk\u00fcmmend kolm, nii on see ka praegu. Kuid iga\u00fche sees suurendame j\u00e4rk-j\u00e4rgult shardide arvu andmete kogunemisega. Ja shardimise skeem on \u00fcldiselt selline - jagamine nendeks klastriteks toimub veebisaitide j\u00e4rgi, ja et m\u00f5ista, milline sait on millise klastri all, kasutatakse eraldi metabaasi MySQL-is. \u00dcks sait - \u00fches klastris. Ja seestpoolt toimub shardimine k\u00fclastajate identifikaatorite j\u00e4rgi.<\/p>\n<p><\/p>\n<p>Kirjutamisel jaotame nad k\u00fclastaja identifikaatori jagamise j\u00e4\u00e4 p\u00f5hjal. Kuid uue shard'i lisamisel muutub shardimise skeem, j\u00e4tkame jagamist, kuid j\u00e4\u00e4d jagame m\u00f5ne teise arvu j\u00e4rgi. See t\u00e4hendab, et \u00fcks k\u00fclastaja on ikkagi enam kui \u00fchel serveril, ja selle peale toetuda ei saa. See on tehtud eranditult selleks, et andmeid paremini kokku suruda. Ja p\u00e4ringute puhul liigume Distributed tabelisse, mis vaatab klastrisse ja p\u00f6\u00f6rdub k\u00fcmnete serverite poole. Selline loll skeem.<\/p>\n<p><\/p>\n<p>Aga mu jutt oleks puudu, kui ma ei \u00fctleks, et sellest skeemist oleme loobunud. Uues skeemis oleme k\u00f5ik muutnud ja k\u00f5ik andmed kopeeritud clickhouse-copier abil.<\/p>\n<p><\/p>\n<p>Uues skeemis jagunevad k\u00f5ik saidid kaheks kategooriaks \u2014 suured ja v\u00e4ikesed. Ma ei tea, kuidas seal piir t\u00f5mmatakse, kuid tulemuseks on see, et suured saidid registreeritakse \u00fchele klastrile, kus on 120 shard'i, igas kolme replikaga \u2014 see t\u00e4hendab 360 serverit. Ja shardimise skeem on selline, et iga p\u00e4ring l\u00e4heb kohe k\u00f5igile shard'idele. Kui te praegu avate 'Yandex.Metrica's' mis tahes aruande lehe avito.ru jaoks, siis p\u00e4ring suundub 120 serverisse. Suuri saite Venemaal on v\u00e4he. Ja p\u00e4ringute arv ei ole tuhat sekundis, vaid isegi v\u00e4hem kui sada. K\u00f5ike seda suudab rahulikult t\u00f6\u00f6delda Distributed tabel, mida iga\u00fcks neist k\u00e4sitleb 120 serveriga.<\/p>\n<p><\/p>\n<p>Teine klaster on m\u00f5eldud v\u00e4ikeste saitide jaoks. Siin on shardimise 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 utiliit clickhouse-copier. Kas v\u00f5iksite sellest r\u00e4\u00e4kida?<\/h2>\n<p><\/p>\n<p>\u00dctlema peab, et see lahendus on pisut mahukam ja m\u00f5nev\u00f5rra v\u00e4hem tootlik. Eeliseks on see, et see jaotab andmed t\u00e4ielikult vastavalt teie m\u00e4\u00e4ratud skeemile. Kuid selle t\u00f6\u00f6riista puudus seisneb selles, et see ei tee edasi shardimist. See kopeerib andmed \u00fchest klastriskeemist teise klastriskeemi.<\/p>\n<p><\/p>\n<p>See t\u00e4hendab, et selle t\u00f6\u00f6ks peab teil olema kaks klastrit. Need v\u00f5ivad olla paigutatud samadele serveritele, kuid andmed ei liigu inkrementeeritult, vaid kopeeritakse. <\/p>\n<p><\/p>\n<p>N\u00e4iteks oli neli serverit, n\u00fc\u00fcd on kaheksa. Loote k\u00f5igil serveritel uue Distributed tabeli, uued kohalikke tabelid ja k\u00e4ivitate clickhouse-copier'i, m\u00e4\u00e4rates selles t\u00f6\u00f6 skeemi, mida ta peab lugema, v\u00f5tma uue shardimise skeemi ja viima andmed sinna. Ja vanades serverites vajate ruumi poolteist korda rohkem, kui praegu on, sest vanad andmed peavad seal j\u00e4\u00e4ma, ja nende peal tuleb pool neist vanadest andmetest. Kui te olite eelnevalt m\u00f5elnud, et andmed tuleb edasi shardida ja ruumi on, sobib see meetod.<\/p>\n<p><\/p>\n<p>Kuidas clickhouse-copier sees t\u00f6\u00f6tab? See jagab kogu t\u00f6\u00f6 \u00fclesandeks \u00fche partitsiooni t\u00f6\u00f6tlemise \u00fche tabeli \u00fchel shard'il. K\u00f5iki neid \u00fclesandeid saab t\u00e4ita paralleelselt, ja clickhouse-copier v\u00f5ib t\u00f6\u00f6tada erinevates masinates mitmes eksemplaris, kuid see, mida ta teeb \u00fche partitsiooni jaoks \u2014 on \u00fcksnes insert select. Andmed loetakse, dekompresseeritakse, uuesti jagatakse, siis surutakse uuesti kokku, kirjutatakse kuhugi, ja j\u00e4rjekorda seotakse. See on raskem 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>Teiega oli pilootprojekt, mis kandis nime resharding. Mis selle saatus on?<\/h2>\n<p><\/p>\n<blockquote><p>Teie juures oli juba 2017. aastal katsetus, mis kandis nime resharding. On isegi valik ClickHouse'is. Ma saan aru, et see ei l\u00e4inud k\u00e4iku. Kas saaksite r\u00e4\u00e4kida, miks see nii l\u00e4ks? Tundub, et see on v\u00e4ga aktuaalne.<\/p><\/blockquote>\n<p>Kogu probleem seisneb selles, et andmete vajadusel edasiviimine kohtades n\u00f5uab \u00fcsna keerulist s\u00fcnkroniseerimist, et see oleks atomaarne. Kui me hakkasime vaatama, kuidas see s\u00fcnkroniseerimine on korraldatud, sai selgeks, et seal on fundamentaalsed probleemid. Ja need fundamentaalsed probleemid ei ole mitte ainult teoreetilised, vaid samuti hakkasid nad kohe praktikas ilmnema selgelt \u2014 mitte midagi ei t\u00f6\u00f6ta.<\/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 enne aeglastele kettale liikumist k\u00f5iki andmete osi kokku sulatada?<\/h2>\n<p><\/p>\n<blockquote><p>K\u00fcsimus TTL kohta koos v\u00f5imalusega liikuda aeglasele kettale konteksti hinget\u00f5mbetes. Kas on olemas viis, peale cron'i, kuidas k\u00f5ik osad \u00fchte liita enne nende \u00fcleviimist aeglastele kettale?<\/p><\/blockquote>\n<p>Vastus k\u00fcsimusele, kas on v\u00f5imalik automaatselt k\u00f5ik t\u00fckid kokku liita enne nende \u00fcleviimist \u2014 ei. Tundub, et selles ei ole vajadust. Ei pea nuputama k\u00f5iki osi kokku, vaid lihtsalt loodame, et need liiguvad aeglastele ketastele automaatselt. <\/p>\n<p><\/p>\n<p>Meil on kaks kriteeriumi \u00fclekande reeglite jaoks. Esimene \u2014 t\u00e4ituvuse j\u00e4rgi. Kui praegusel salvestustasandil on vaba ruumi v\u00e4hem kui mingi protsent, valime \u00fche t\u00fckki ja liigume selle aeglasemale salvestusele. Tegelikult mitte aeglasemale, vaid j\u00e4rgmisele \u2014 nagu seadistate.<\/p>\n<p><\/p>\n<p>Teine kriteerium \u2014 suuruse j\u00e4rgi. See on suuremate t\u00fckikeste edasiviimise kohta. Saate kohandada l\u00e4ve kiirel kettal oleva vaba ruumi osas, ja andmed liiguvad automaatselt.<\/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 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\">ClickHouse'i Telegrami vestluses<\/a><\/noindex> erinevate versioonide arvesse v\u00f5tmine, ja siiski. Kui turvaline on uuendada versioonilt 19.11 versioonile 19.16 ja n\u00e4iteks 19.16-lt versioonile 20.3? Kuidas on parem liikuda uute versioonide juurde, ilma et oleks v\u00f5imalik eelnevalt kontrollida \u00fchilduvust liivakastis?<\/p><\/blockquote>\n<p>Siin on m\u00f5ned \"kuldreeglid\". Esimene \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">lugeda changelog<\/a><\/noindex>. Ta on suur, kuid seal on eraldi punktid tagurpidi \u00fchilduvuse muudatuste kohta. \u00c4rge v\u00f5tke neid punkte punase lipuna. T\u00fc\u00fcpiliselt on need pisikesed \u00fchilduvuse probleemid, mis on seotud teatud piirifunktsioonidega, mida t\u00f5en\u00e4oliselt ei kasuta.<\/p>\n<p><\/p>\n<p>Teiseks \u2014 kui ei ole v\u00f5imalik kontrollida \u00fchilduvust liivakasti keskkonnas ja soovite kohe tootmisversioonile \u00fcle minna, on soovitus selline \u2014 \u00e4rge tehke seda. Looge esmalt liivakast ja kontrollige. Kui katsekeskkonda pole, siis t\u00f5en\u00e4oliselt ei ole teil v\u00e4ga suurt ettev\u00f5tet, mist\u00f5ttu saate osa andmeid oma s\u00fclearvutile kopeerida ja veenduda, et k\u00f5ik t\u00f6\u00f6tab korrektselt. V\u00f5ite isegi kohapeal mitmeid replikate k\u00e4ivitada. V\u00f5i saate l\u00e4hedale luua uue versiooni ja laadida sinna osa andmeid \u2014 see t\u00e4hendab, et loote improviseritud katsekeskkonna. <\/p>\n<p><\/p>\n<p>Veel \u00fcks reegel \u2014 \u00e4rge v\u00e4rskendage n\u00e4dal aega p\u00e4rast versiooni v\u00e4ljatulekut, et p\u00fc\u00fcda tootmisversioonis vigu ja j\u00e4rgnevate kiirete paranduste t\u00f5ttu. R\u00e4\u00e4gime ClickHouse'i versioonide nummerdamisest, et mitte segadusse minna. <\/p>\n<p><\/p>\n<p>On versioon 20.3.4. Number 20 t\u00e4histab v\u00e4ljaandmise aastat \u2014 2020. Seestpoolt vaadates ei oma see mingit t\u00e4htsust, seega ei pane me sellele t\u00e4helepanu. J\u00e4rgmine \u2014 20.3. Teist numbrit \u2014 sel juhul 3 \u2014 suurendame iga kord, kui vabastame v\u00e4ljaande uue funktsionaalsusega. Kui tahame ClickHouse'i lisada mingit v\u00f5imalust, peame seda numbrit suurendama. See t\u00e4hendab, et versioonis 20.4 hakkab ClickHouse t\u00f6\u00f6tama veel paremini. Kolmas number \u2014 20.3.4. Siin 4 \u2014 see on pat\u0161i v\u00e4ljaannete arv, kus me uusi v\u00f5imalusi ei lisanud, kuid parandasime m\u00f5ningaid vigu. Ja 4 t\u00e4hendab, et oleme seda teinud neli korda.<\/p>\n<p><\/p>\n<p>\u00c4rge muretsege, nagu oleks see midagi kohutavat. T\u00fc\u00fcpiliselt suudab kasutaja installida k\u00f5ige uuema versiooni, ja see t\u00f6\u00f6tab probleemideta aasta jooksul. Kuid kujutage ette, et mingis funktsioonis, mis tegeleb bitmapsidega ja mille on lisanud meie Hiina kolleegid, server crashib vale argumentide edastamisel. Me peame selle parandama. V\u00e4lja anname uue pat\u0161i versiooni, ja ClickHouse muutub stabiilsemaks.<\/p>\n<p><\/p>\n<p>Kui teil on ClickHouse tootmises ja ilmub uus ClickHouse versioon t\u00e4iendavate funktsioonidega \u2014 n\u00e4iteks 20.4.1 \u2014 siis \u00e4rge kiirustage seda kohe tootmisse paigaldama. Miks see \u00fcldse vajalik on? Kui te ei kasuta veel ClickHouse'i, saate selle installida ja t\u00f5en\u00e4oliselt l\u00e4heb k\u00f5ik h\u00e4sti. Aga kui ClickHouse juba stabiilselt t\u00f6\u00f6tab, j\u00e4lgige pat\u0161e ja v\u00e4rskendusi \u2014 milliseid probleeme me lahendame.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Soovin lisada natuke testkeskkondade kohta. K\u00f5ik kardavad testkeskkondi ja arvavad, et kui teil on v\u00e4ga suur ClickHouse klaster, peab ka testkeskkond olema mitte v\u00e4iksem v\u00f5i v\u00e4hemalt k\u00fcmme korda v\u00e4iksem. See ei ole sugugi nii.<\/p>\n<p><\/p>\n<p>V\u00f5in r\u00e4\u00e4kida oma kogemusest. Mul on projekt, kus on ClickHouse. Meie testkeskkond selle jaoks \u2014 see on v\u00e4ike virtuaalmasin Hetzneris, mille hind on kaksk\u00fcmmend eurot, kus on k\u00f5ik \u00fcles seatud. Selleks, et seda teha, on meil t\u00e4ielik automatiseerimine Ansible'is, nii et p\u00f5him\u00f5tteliselt ei ole vahet, kuhu seadistada \u2014 f\u00fc\u00fcsilistele serveritele v\u00f5i lihtsalt virtuaalmasinatele.<\/p>\n<p><\/p>\n<p>Mida saaks teha? Hea oleks, kui ClickHouse dokumentatsioonis oleks n\u00e4idis, kuidas \u00fcles seada v\u00e4ike klaster \u2014 Dockeri, LXC-s, v\u00f5ib-olla luua Ansible'i m\u00e4nguara, kuna erinevatel inimestel on erinevad juurutused. See lihtsustaks palju. Kui v\u00f5tate ja paigaldate klastrit viie minutiga, on palju lihtsam proovida midagi uurida. Nii on palju mugavam, sest t\u00f6\u00f6sse viimine versioon, mida te ei ole kontrollinud \u2014 see on tee mitte kuhugi. M\u00f5nikord see t\u00f6\u00f6tab, m\u00f5nikord mitte. Seet\u00f5ttu loota \u00f5nne \u2014 on halb.<\/p>\n<p><\/p>\n<p><strong>Maksim Kotjakov, vanem backendi insener Avitos:<\/strong> Lisaks r\u00e4\u00e4gin suurte ettev\u00f5tete testimisv\u00f5imetest. Meil on t\u00e4iesti toimiv ClickHouse'i vastuv\u00f5tuklasster, mis on andmeskeemide ja seadete poolest t\u00e4pne koopia tootmisest. See klaster on \u00fcles seatud \u00fcsna v\u00e4heste ressurssidega konteineritesse. Me suuname sinna teatud protsendi tootmisandmetest, kuna on v\u00f5imalik replitseerida voog Kafkas. K\u00f5ik on s\u00fcnkroniseeritud ja skaleeritud \u2014 nii j\u00f5udluse kui ka voogude osas ning teoorias peaks see m\u00f5\u00f5dikute j\u00e4rgi k\u00e4ituma nagu tootmisversioon. K\u00f5ik potentsiaalselt ohtlikud muudatused tehakse esmalt sellele sestandile ja seal k\u00fcpsevad need paar p\u00e4eva enne valmimist. Kuid loomulikult on see lahendus kulukas, keeruline ja n\u00f5uab pidevat hooldust. <\/p>\n<p><\/p>\n<p><strong>Alexei Milovidov:<\/strong> R\u00e4\u00e4gin, milline on meie s\u00f5prade \"Yandex.Metrica\" testkeskkond. \u00dcks klaster koosnes enam kui 600 serverist, teine 360-st, lisaks on veel kolmas ja mitu muud klastrit. \u00dche nende testkeskkond \u2014 see on lihtsalt kaks shard'i, milles on kaks replikat igas. Miks kaks shard'i? Et mitte olla ainult \u00fcks. Ja replikad on ka selleks, et neid oleks. Lihtsalt teatud minimaalne arv, mida on v\u00f5imalik endale lubada.<\/p>\n<p><\/p>\n<p>See testkeskkond v\u00f5imaldab kontrollida p\u00e4ringute t\u00f6\u00f6tamist ja kas midagi suurest plaanist ei ole katki l\u00e4inud. Kuid sageli tekivad probleemid t\u00e4iesti teistsuguseid iseloomuga, kui k\u00f5ik t\u00f6\u00f6tab, kuid koormuses on m\u00f5ned v\u00e4iksemad muutused.<\/p>\n<p><\/p>\n<p>Toon n\u00e4ite. Otsustasime paigaldada uue ClickHouse'i versiooni. See on paigaldatud testkeskkonda, automatiseeritud testid on l\u00e4bitud \"Yandex.Metrica\"-s, mis v\u00f5rreldavad andmeid vana ja uue versiooni vahel, l\u00e4bi viies kogu toru. Ja loomulikult on meie CI testid k\u00f5ik rohelised. Ilma nendeta ei oleks me isegi seda versiooni v\u00e4lja pakkunud.<\/p>\n<p><\/p>\n<p>K\u00f5ik on suurep\u00e4rane. Alustame tootmisse viimist. Saadan teate, et koormus graafikutes on mitu korda kasvanud. Tagasi uue versiooni. Vaatan graafikut ja n\u00e4en: koormus t\u00f5epoolest kasvas mitu korda versiooni v\u00e4ljalaskmisel ja t\u00f5usis hiljem tagasi, kui selle eemaldasime. Siis hakkasime versiooni tagasi viima. Ja koormus t\u00e4pselt samuti suurenes ja langes samuti tagasi. Seega on j\u00e4reldus selline \u2014 koormus t\u00f5usis seoses v\u00e4ljalaskmisega, midagi \u00fcllatavat.<\/p>\n<p><\/p>\n<p>Edasi oli raske veenda kolleege siiski installima uut versiooni. R\u00e4\u00e4gin: \"K\u00f5ik on korras, v\u00e4ljastage see. Hoidke p\u00f6idlaid, k\u00f5ik t\u00f6\u00f6tab. Praegu on koormus graafikutes t\u00f5usnud, kuid k\u00f5ik on korras. Peate vastu\". L\u00f5puks teeme nii ja k\u00f5ik \u2014 versioon on tootmises. Kuid peaaegu iga v\u00e4ljalaskmisega tekivad sarnased probleemid.<\/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>K\u00e4sku Kill query peaks l\u00f5petama p\u00e4ringud, kuid see ei toimi. Miks?<\/h2>\n<p><\/p>\n<blockquote><p>K\u00fclastas mind kasutaja, mingi anal\u00fc\u00fctik, ja koostas p\u00e4ringu, mis kukutas mu ClickHouse'i klastri. M\u00f5ni node v\u00f5i klaster tervikuna \u2014 s\u00f5ltuvalt sellest, millisesse replika v\u00f5i shard'i p\u00e4ring sattus. N\u00e4en, et k\u00f5ik ressursid CPU-l sellel serveril on t\u00e4is, k\u00f5ik punane. Samas ClickHouse vastab p\u00e4ringutele. Ja kirjutan: \"N\u00e4ita mulle palun protsesside nimekirja, milline p\u00e4ring kasutas selle segaduse tekitamiseks\".<\/p>\n<p>Leian selle p\u00e4ringu ja kirjutan kill. Ja n\u00e4en, et midagi ei juhtu. Minu server on \u00fclekoormatud, ClickHouse annab endiselt mulle mingeid k\u00e4ske, n\u00e4idates, et server on elus, ja k\u00f5ik on h\u00e4sti. Kuid mul on k\u00f5ikide kasutajap\u00e4ringute osas halvenemine, algab halvenemine andmete kirjutamisel ClickHouse'i ja minu kill p\u00e4ring ei t\u00f6\u00f6ta. Miks? Arvasin, et kill p\u00e4ring peaks p\u00e4ringud \u00e4ra tapma, kuid see ei toimu.<\/p><\/blockquote>\n<p>N\u00fc\u00fcd tuleb \u00fcsna kummaline vastus. Asi on selles, et kill p\u00e4ring ei tapa p\u00e4ringut. <\/p>\n<p><\/p>\n<p>Kill p\u00e4ring seadistab v\u00e4ikese lipu nimega \"ma tahan, et see p\u00e4ring tapetaks\". Ja ise p\u00e4ring t\u00f6\u00f6tlemise iga bloki juures vaatab selle lipu poole. Kui see on seatud, l\u00f5petab p\u00e4ring t\u00f6\u00f6tamise. Selgub, et keegi p\u00e4ringut ei tapa, see peab ise k\u00f5ik kontrollima ja peatuma. Ja see peaks t\u00f6\u00f6tama k\u00f5igis olukordades, kui p\u00e4ring on andmeplokkide t\u00f6\u00f6tlemise seisundis. See t\u00f6\u00f6tleb j\u00e4rgmise andmeploki, kontrollib lippu ja peatub.<\/p>\n<p><\/p>\n<p>See ei t\u00f6\u00f6ta olukordades, kui p\u00e4ring on kinni mingi operatsiooni peal. T\u00f5en\u00e4oliselt ei ole see teie juhtum, kuna teie s\u00f5nade kohaselt kasutab see serveri hulga ressursse. V\u00f5ib-olla ei t\u00f6\u00f6ta see v\u00e4listel sortimistel ja veel m\u00f5nedes detailides. Kuid \u00fcldiselt ei tohiks see nii olla, see on viga. Ja ainus, mida saan soovitada \u2014 v\u00e4rskendage 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 lugemisekoormuse korral?<\/h2>\n<p><\/p>\n<blockquote><p>On&nbsp;on tabel, kus hoitakse agregaatide kohta item&nbsp;\u2014 erinevad loendurid. Ridade arv&nbsp;\u2014 umbes sada miljonit. Kas on v\u00f5imalik loota arvutatavale vastusaega, kui suunata 1K&nbsp;RPS 1K&nbsp;item\u2019ile? <\/p><\/blockquote>\n<p>Konteksti p\u00f5hjal r\u00e4\u00e4gitakse lugemise koormusest, sest kirjutamise osas ei ole probleeme \u2014 v\u00f5ite sisestada kas tuhat, sada tuhat v\u00f5i vahel isegi mitu miljonit rida. <\/p>\n<p><\/p>\n<p>Lugemisestatistikad on v\u00e4ga erinevad. Select&nbsp;1 ClickHouse suudab teostada umbes k\u00fcmneid tuhandeid p\u00e4ringuid sekundis, seega isegi p\u00e4ringud \u00fchele v\u00f5tmele vajavad juba teatavaid ressursse. Sellised punktip\u00e4ringud on keerukamad kui m\u00f5nes key-value andmebaasis, sest iga lugemise jaoks on vajalik andmeploki lugemine indeksi j\u00e4rgi. Indeks suunab meid mitte iga kirje, vaid iga vahemiku juurde. See t\u00e4hendab, et tuleb lugeda kogu vahemik&nbsp;\u2014 see on vaikimisi 8192 rida. Ja tuleb dekompressida surutud andmeplokk 64&nbsp;Kb kuni 1&nbsp;Mb. Tavaliselt v\u00f5tab selliste punktip\u00e4ringud paar millisekundit. Kuid see on k\u00f5ige lihtsam variant.<\/p>\n<p><\/p>\n<p>Proovime teha lihtsat aritmeetikat. Kui korrutada paar millisekundit tuhande vastu, siis saad mitmed sekundid. Nagu oleks tuhat p\u00e4ringut sekundis keeruline hallata, kuid tegelikult on see v\u00f5imalik, sest meil on mitu protsessorituuma. Niisiis, p\u00f5him\u00f5tteliselt suudab 1000&nbsp;RPS ClickHouse m\u00f5nikord hallata, kuid l\u00fchikeste p\u00e4ringute puhul, just punktip\u00e4ringute puhul.<\/p>\n<p><\/p>\n<p>Kui on vaja ClickHouse'i klastrit skaleerida lihtsate p\u00e4ringute arvu suurendamiseks, siis soovitan k\u00f5ige lihtsamat&nbsp;\u2014 suurendada replikate arvu ja suunata p\u00e4ringud juhuslikule replikale. Kui \u00fcks replik suudab hallata viissada p\u00e4ringut sekundis, mis on t\u00e4iesti teostatav, siis kolm replikat suudavad hallata tuhat viissada.<\/p>\n<p><\/p>\n<p>M\u00f5nikord on t\u00f5epoolest v\u00f5imalik ClickHouse'i seadistada punktis\u00e4\u00e4stlike lugemiste maksimaalse arvu saavutamiseks. Mida selle jaoks on vaja? Esiteks&nbsp;\u2014 v\u00e4hendada indeksi granulaarsust. Seda tuleks v\u00e4hendada mitte \u00fchele, vaid arvestades, et indeksi kirjeid on serveris mitu miljonit v\u00f5i k\u00fcmneid miljoneid. Kui tabelis on sada miljonit rida, siis saab granulaarsuseks seada 64.<\/p>\n<p><\/p>\n<p>Surutud ploki suurust saab v\u00e4hendada. Selleks on olemas seaded. <strong>min. kompressioonibloki suurus<\/strong>, <strong>max. kompressioonibloki suurus<\/strong>Saab neid v\u00e4hendada, andmeid \u00fcmber laadida, ja siis punktip\u00e4ringud toimivad kiiremini. Kuid ClickHouse pole ikkagi key-value andmebaas. Suur hulk v\u00e4ikeseid p\u00e4ringuid on koormuse antipattern.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Annaksin n\u00f5u juhul, kui seal on tavalised loendurid. See on piisavalt tavaline olukord, kui ClickHouse'is hoitakse m\u00f5nda loendurit. Mul on kasutaja, ta on sellisest riigist, pluss veel \u00fcks kolmas v\u00e4li, ja tuleb inkrementeerida midagi. V\u00f5tke MySQL, tehke ainulaadne v\u00f5tme&nbsp;\u2014 MySQL'is on see duplicate key, PostgreSQL'is on see conflict&nbsp;\u2014 ja lisage plusspunktiga. See t\u00f6\u00f6tab palju paremini. <\/p>\n<p><\/p>\n<p>Kui teil on v\u00e4he andmeid, siis pole ClickHouse'i kasutamine eriti m\u00f5ttekas. On tavalised andmebaasid ja need teevad sellega head t\u00f6\u00f6d. <\/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 seadistada ClickHouse'is, et rohkem andmeid oleks vahem\u00e4lus?<\/h2>\n<p><\/p>\n<blockquote><p>Kujutame ette situatsiooni&nbsp;\u2014 serverites on 256&nbsp;Gbit&nbsp;RAM-i, igap\u00e4evasel kasutamisel v\u00f5tab ClickHouse umbes 60\u201380&nbsp;Gbit, tipphetkel kuni 130. Mida saab sisse l\u00fclitada ja seadistada, et rohkem andmeid oleks vahem\u00e4lus ja seega oleks v\u00e4hem ketta v\u00e4ljakutseid?<\/p><\/blockquote>\n<p>Tavaliselt teeb operatsioonis\u00fcsteemi lehek\u00fclje vahem\u00e4lu selle t\u00f6\u00f6 h\u00e4sti. Kui avate lihtsalt tipp, vaatate seal cached v\u00f5i free&nbsp;\u2014 seal on ka kirjas, kui palju on vahem\u00e4llu salvestatud&nbsp;\u2014 siis v\u00f5ib t\u00e4heldada, et kogu vaba m\u00e4lu on kasutatud vahem\u00e4lu jaoks. Ja need andmed loetakse lugemise ajal mitte kettalt, vaid operatiivm\u00e4lu. Sellegipoolest v\u00f5in \u00f6elda, et vahem\u00e4lu kasutatakse t\u00f5husalt, sest salvestatakse just seda, millele on rakendatud surumine.<\/p>\n<p><\/p>\n<p>Kuid kui soovite veelgi kiirendada m\u00f5ningaid lihtsaid p\u00e4ringuid, siis on v\u00f5imalus sisedokumentides ClickHouse'is l\u00fclitada sisse dekompressitud andmete vahem\u00e4lu. Seda nimetatakse. <strong>uncompressed cache<\/strong>. Konfiguratsioonifailis config.xml seadke uncompressed cache size soovitud v\u00e4\u00e4rtusele&nbsp;\u2014 soovitan mitte rohkem kui poole v\u00f5rra vabast m\u00e4lu, sest \u00fclej\u00e4\u00e4nud l\u00e4heb lehek\u00fclje vahem\u00e4lu. <\/p>\n<p><\/p>\n<p>Lisaks on olemas kaks p\u00e4ringutaseme seadistust. Esimene seadistus on <strong>use uncompressed cache<\/strong> \u2014 v\u00f5imaldab selle kasutamist. Soovitav on see lubada k\u00f5igi p\u00e4ringute jaoks, v\u00e4lja arvatud rasked, mis v\u00f5ivad lugeda kogu andmebaasi ja selle vahem\u00e4lu kustutada. Ja teine seadistus&nbsp;\u2014 see on midagi sellist nagu maksimaalne ridade arv vahem\u00e4lu kasutamiseks. See piirab automaatselt suuri p\u00e4ringuid, et nad ei l\u00e4heks vahem\u00e4lu kaudu.<\/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 kohandada storage_configuration, et andmeid hoida m\u00e4lus?<\/h2>\n<p><\/p>\n<blockquote><p>Uues ClickHouse dokumentatsioonis leidisin jaotis, mis oli 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 kiirest SSD-st. <\/p>\n<p>Huvitav, kuidas saab sama konfigureerida volume hot memory. Ja veel \u00fcks k\u00fcsimus. Kuidas select t\u00f6\u00f6tab sellise andmeorganisatsiooniga, kas see loeb kogu kogumi v\u00f5i ainult selle, mis on kettal, ja kas need andmed m\u00e4lus tihendatakse? Kuidas t\u00f6\u00f6tab prewhere sektsioon sellise andmeorganisatsiooniga?<\/p><\/blockquote>\n<p>See seadistus m\u00f5jutab andmeplokkide salvestamist ning nende formaat ei muutu.<br \/>\nVaadakem l\u00e4hemalt. <\/p>\n<p><\/p>\n<p>Andmete salvestamine operatiivm\u00e4lu saab seadistada. K\u00f5ik, mis on diskile konfigureeritud, on selle tee. Sa loodi tmpfs jagamise, mis on mahamonteeritud mingisugusele teele failis\u00fcsteemis. N\u00e4itad seda teed andmete salvestamise teena kuumade plokkide jaoks, kuhu hakkavad plokid andmed tulema ja kirjutama, k\u00f5ik on korras. <\/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 on see v\u00f5imalik. Kui midagi juhtub, siis andmed taastatakse. Kujutage ette, et server l\u00fclitatakse \u00e4kki v\u00e4lja ja seej\u00e4rel tagasi sisse. Jagamine monteeritakse taas, kuid seal on t\u00fchjus. ClickHouse server k\u00e4ivitumisel n\u00e4eb, et need plokid puuduvad, kuigi vastavalt ZooKeeperi metaandmetele peaksid need olemas olema. Ta vaatab, millistes koopiates need on, k\u00fcsib need v\u00e4lja ning allalaadib. Nii taastatakse andmed. <\/p>\n<p><\/p>\n<p>Selles m\u00f5ttes ei erine andmete salvestamine operatiivm\u00e4lu p\u00f5him\u00f5tteliselt nende salvestamisest kettale, kuna andmete kirjutamisel kettale l\u00e4bivad need esmalt page cache ja kirjutatakse f\u00fc\u00fcsiliselt edasil\u00fckatult. See s\u00f5ltub failis\u00fcsteemi monteerimise variandist. Kuid igaks juhuks \u00fctlen, et ClickHouse ei tee fsync'i insert'i k\u00e4igus.<\/p>\n<p><\/p>\n<p>Samal ajal salvestatakse andmed operatiivm\u00e4lu t\u00e4pselt samas formaadis nagu kettal. Select p\u00e4ring valib samuti plokid, mida tuleb lugeda, valib vajalikud andmevahemikud ning loeb need. Ja prewhere t\u00f6\u00f6tab t\u00e4pselt sama moodi, olenemata sellest, kas andmed olid operatiivm\u00e4lu 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>Kui palju unikaalseid v\u00e4\u00e4rtusi on Low Cardinality efektiivne?<\/h2>\n<p><\/p>\n<p>Low Cardinality on nutikalt \u00fcles ehitatud. See loob andmes\u00f5nastikud, kuid need on lokaalsed. Esiteks, igal plokil on oma s\u00f5nastik, teiseks, isegi \u00fche ploki sees v\u00f5ivad need olla erinevad iga vahemiku jaoks. Kui ainulaadsete v\u00e4\u00e4rtuste arv ulatub piirv\u00e4\u00e4rtuseni \u2014 minu arvates miljon \u2014, siis s\u00f5nastik lihtsalt j\u00e4etakse k\u00f5rvale ja luuakse uus.<\/p>\n<p><\/p>\n<p>\u00dcks vastus oleks \u00f6elda, et ClickHouse ei ole s\u00fcsteem t\u00e4isteksti otsimiseks. Selleks on spetsiaalsed s\u00fcsteemid, n\u00e4iteks, <\/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 k\u00fcmne miljardi reaga tabelis t\u00e4isteksti otsimise osas?<\/h2>\n<p><\/p>\n<p>. Kuid ma n\u00e4en \u00fcha rohkem inimesi, kes \u00fctlevad, et nad liiguvad Elasticsearchist ClickHouse'i. <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>Miks see nii juhtub? Nad selgitavad seda sellega, et Elasticsearch ei suuda teatud mahtude juures enam koormust taluda, alustades indeksite koostamisest. Indeksid muutuvad liiga mahukaks ja kui andmed lihtsalt viia ClickHouse'i, selgub, et need salvestatakse mitmekordselt efektiivsemalt. Samal ajal ei olnud otsingutaotlused tavaliselt sellised, et peab leidma m\u00f5ne fraasi kogu andmehulgast, vaid hoopis teised. N\u00e4iteks, leida viimase paari tunni logides mingi alamsuundadebaid.<\/p>\n<p><\/p>\n<p>Sellisel juhul loob ClickHouse indeksi, mille esimeseks v\u00e4ljaks on kuup\u00e4ev koos kellaajaga. Ja k\u00f5ige suurem andmete k\u00e4rpe ulatus on just kuup\u00e4evade vahemik. Valitud kuup\u00e4evade vahemikus saab tavaliselt teostada t\u00e4isteksti otsingut isegi bruteforce meetodiga nagu like. Otsing operator like ClickHouse'is on k\u00f5ige efektiivsem like operator, mida sa v\u00f5id leida. Kui leiad parema, siis \u00fctle mulle.<\/p>\n<p><\/p>\n<p>Kuid nagu ikka, like on full scan. Ja full scan v\u00f5ib olla aeglane mitte ainult CPU, vaid ka ketta poolest. Kui sul on n\u00e4iteks \u00fcks terabyte andmeid p\u00e4evas ja sa otsid p\u00e4eva jooksu mingit s\u00f5na, pead skaneerima terabyte. Ja see on kindlasti tavalistes k\u00f5vaketastes, mist\u00f5ttu nad on l\u00f5puks nii koormatud, et sa ei p\u00e4\u00e4se sellele serverile SSH kaudu. <\/p>\n<p><\/p>\n<p>Siiski, like&nbsp;\u2014 see on full scan. Ja full scan v\u00f5ib olla aeglane mitte ainult CPU, vaid ka ketaste puhul. Kui teil on n\u00e4iteks \u00fcks terabait andmeid p\u00e4evas ja te otsite sealt m\u00f5nd s\u00f5na, peate skaneerima terve terabaiti. Ja see on ilmselt tavalistes k\u00f5vakettastes, ning l\u00f5puks v\u00f5ivad need olla nii koormatud, et te ei p\u00e4\u00e4se selle serveri juurde SSH kaudu.<\/p>\n<p><\/p>\n<p>Sel juhul olen valmis pakkuma veel \u00fchte v\u00e4ikest nippi. See on katsetus \u2014 see v\u00f5ib t\u00f6\u00f6tada, aga v\u00f5ib ka mitte. ClickHouse'is on olemas t\u00e4isteksti indeksid trigrammi Bloom-filterite kujul. Meie kolleegid ettev\u00f5ttest Arenadata on neid indeksite katsetanud, ning tihti t\u00f6\u00f6tavad nad just nii nagu on ette n\u00e4htud.<\/p>\n<p><\/p>\n<p>Nende korrektseks kasutamiseks on oluline h\u00e4sti m\u00f5ista, kuidas nad t\u00f6\u00f6tavad: mis on trigrammi Bloom-filter ja kuidas valida selle suurust. V\u00f5in \u00f6elda, et need aitavad harva esinevate fraaside, alltekstide otsimisel, mis harva andmetes kohtuvad. Sellisel juhul valitakse indeksite kaudu alamvahemikud ja loetakse v\u00e4hem andmeid.<\/p>\n<p><\/p>\n<p>Hiljuti on ClickHouse'is ilmnenud veelgi arenenumad funktsioonid t\u00e4istekstiotsingu jaoks. Esiteks, otsing paljusid alltekste \u00fche l\u00e4bimisega, sealhulgas variante, mis arvestavad suur- ja v\u00e4iket\u00e4hti, toetavad UTF-8 v\u00f5i ainult ASCII. Valige k\u00f5ige t\u00f5husam, mida vajate. <\/p>\n<p><\/p>\n<p>Samuti on n\u00fc\u00fcd olemas mitme regulaaravalduse otsing \u00fche l\u00e4bimisega. Te ei pea kirjutama X like \u00fchte allteksti v\u00f5i X like teist allteksti. Kirjutage korraga ja k\u00f5ik toimub maksimaalse efektiivsusega.<\/p>\n<p><\/p>\n<p>Kolmandaks \u2014 n\u00fc\u00fcd on olemas ligikaudne otsing regulaaravalduse ja ligikaudne otsing alltekstide j\u00e4rgi. Kui keegi on kirjutanud s\u00f5na veaga, 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 ligip\u00e4\u00e4s suurt hulka kasutajaid?<\/h2>\n<p><\/p>\n<blockquote><p>R\u00e4\u00e4kige, kuidas korraldada ligip\u00e4\u00e4s suures koguses tarbijatele ja anal\u00fc\u00fctikutele. Kuidas koostada j\u00e4rjekorda, prioriseerida p\u00e4ringute max concurrent queries ja milliseid t\u00f6\u00f6riistu kasutada?<\/p><\/blockquote>\n<p>Kui klaster on piisavalt suur, siis on heaks lahenduseks t\u00f5sta veel kaks serverit, mis saavad olema anal\u00fc\u00fctikute sisene punkt. See t\u00e4hendab, et anal\u00fc\u00fctikud ei p\u00e4\u00e4se konkreetsesse klastrisse sharde, vaid luuakse kaks t\u00fchja serverit, ilma andmeteta, ja neile seadistatakse ligip\u00e4\u00e4s. Samal ajal edastatakse kasutajate seadeid jaotusp\u00e4ringute korral kaugserveritele. See t\u00e4hendab, et seadistate k\u00f5ik nendele kahele serverile, ja seadistustel on m\u00f5ju kogu klastrile.<\/p>\n<p><\/p>\n<p>Teisis\u00f5nu on need serverid andmeteta, kuid nende m\u00e4lumaht on p\u00e4ringute t\u00e4itmiseks v\u00e4ga oluline. Ka ketast v\u00f5ib kasutada ajutiste andmete jaoks, kui on sisse l\u00fclitatud v\u00e4line agregatsioon v\u00f5i v\u00e4line sortimine.<\/p>\n<p><\/p>\n<p>On oluline vaadata seadeid, mis on seotud k\u00f5igi v\u00f5imalike piirangutega. Kui ma praegu l\u00e4hen klastrisse \"Yandex.Metrika\" anal\u00fc\u00fctikuna ja esitan p\u00e4ringu <strong>select count from hits<\/strong>, siis antakse mulle kohe erand, et ma ei saa p\u00e4ringut teostada. Maksimaalne rida, mida ma saan skaneerida, on sada miljardit, aga kogu klastris on neid viisk\u00fcmmend triljonit \u00fches tabelis. See on esimene piirang. <\/p>\n<p><\/p>\n<p>Oletame, et ma eemaldan rea piirangu ja t\u00e4idan p\u00e4ringu uuesti. Siis n\u00e4en j\u00e4rgmist erandit \u2014 seadistus on sisse l\u00fclitatud <strong>kaudne indekseerimine kuup\u00e4eva j\u00e4rgi<\/strong>. Ma ei saa p\u00e4ringut teostada, kui ma ei m\u00e4\u00e4ra kuup\u00e4evavahemikku. Pole vaja loota, et anal\u00fc\u00fctikud m\u00e4\u00e4ravad selle k\u00e4sitsi. T\u00fc\u00fcpiline juhtum \u2014 m\u00e4\u00e4ramine kuup\u00e4evavahemikku where event date between n\u00e4dal. Ja siis lihtsalt m\u00e4\u00e4rati sulg vale kohta, ja and = or \u2014 or URL match. Kui piiranguid pole, skaneerib see URL-i veeru ja raiskab lihtsalt tohutult ressursse.<\/p>\n<p><\/p>\n<p>Lisaks on ClickHouse'is kaks prioriteedi seadistust. Kahjuks on need v\u00e4ga primitiivsed. \u00dcks neist on lihtsalt nimetatud <strong>prioriteet<\/strong>. Kui priority \u2260 0 ja teostatakse p\u00e4ringud mingi prioriteediga, kuid samal ajal teostatakse p\u00e4ring prioriteediga, mille v\u00e4\u00e4rtus on v\u00e4iksem, mis t\u00e4hendab k\u00f5rgemat prioriteeti, siis p\u00e4ring, mille prioriteedi v\u00e4\u00e4rtus on suurem, mis t\u00e4histab madalamat prioriteeti, lihtsalt peatatakse ja ei toimi \u00fcldse selle aja jooksul.<\/p>\n<p><\/p>\n<p>See on v\u00e4ga j\u00e4me seadistus ja ei sobi nende juhtumite jaoks, kus klastris on pidev koormus. Kuid kui teil on l\u00fchikesed, impulsiivsed olulised p\u00e4ringud, ja klaster enamasti seisab, sobib see seadistus.<\/p>\n<p><\/p>\n<p>J\u00e4rgmine prioriteetide seadistus on <strong>OS thread priority<\/strong>. See lihtsalt seab k\u00f5ikide p\u00e4ringute t\u00e4itmise l\u00f5imude jaoks nice v\u00e4\u00e4rtuse Linuxi ajakava jaoks. See t\u00f6\u00f6tab k\u00fcllaltki h\u00e4sti, kuid siiski t\u00f6\u00f6tab. Kui seadistada v\u00e4ikseim nice v\u00e4\u00e4rtus \u2014 see on suurim, mis t\u00e4hendab madalamat prioriteeti \u2014 ning k\u00f5rge prioriteediga p\u00e4ringutele seadistada -19, siis CPU tarbib madala prioriteedi p\u00e4ringuid ligikaudu neli korda v\u00e4hem kui k\u00f5rge prioriteedi p\u00e4ringuid. <\/p>\n<p><\/p>\n<p>Samuti tuleb seadistada maksimaalne p\u00e4ringu t\u00e4itmise aeg&nbsp;\u2014 \u00fctleme, viis minutit. Miinimump\u00e4ringu t\u00e4itmise kiirus on see, mis on k\u00f5ige olulisem. See seade on juba pikka aega olemas ning on vajalik mitte ainult selleks, et kinnitada, et ClickHouse ei j\u00e4\u00e4 seisma, vaid ka selle tagamiseks.<\/p>\n<p><\/p>\n<p>Kujutage ette, et seadistate: kui m\u00f5ni p\u00e4ring t\u00f6\u00f6tleb v\u00e4hem kui miljonit rida sekundis&nbsp;\u2014 seda ei tohi lubada. See kahjustab meie head nime, meie head andmebaasi. Laseme selle lihtsalt keelatud. Tegelikult on seal kaks seadet. \u00dcks on nimetatud <strong>min execution speed<\/strong> \u2014 ridade kaupa sekundis ja teine on nimelt timeout before checking min execution speed&nbsp;\u2014 vaikimisi viisteist sekundit. See t\u00e4hendab, et viisteist sekundit on okei ja siis, kui on liiga aeglane, viskab lihtsalt erandi \u2014 katkestab p\u00e4ringu.<\/p>\n<p><\/p>\n<p>Samuti tuleb seadistada kvoodid. ClickHouse'is on sisseehitatud kvoodide funktsioon, mis arvestab ressursikasutust. Kuid kahjuks mitte f\u00fc\u00fcsiliste ressursside, nagu CPU, kett, vaid loogiliste&nbsp;\u2014 t\u00f6\u00f6deldud p\u00e4ringute, ridade ja loetud baitide arvu. Nii et saate seadistada n\u00e4iteks maksimaalselt sada p\u00e4ringut viie minuti jooksul ja tuhat p\u00e4ringut tunni jooksul.<\/p>\n<p><\/p>\n<p>Miks see oluline on? Sest osa anal\u00fc\u00fcsi p\u00e4ringutest tehakse k\u00e4sitsi otse ClickHouse'i kliendist. Ja k\u00f5ik on h\u00e4sti. Kuid kui teie ettev\u00f5ttes on edasij\u00f5udnud anal\u00fc\u00fctikud, kirjutavad nad skripti, ja skriptis v\u00f5ib olla viga. See viga toob kaasa selle, et p\u00e4ring t\u00e4idetakse l\u00f5putus 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 anda \u00fche p\u00e4ringu tulemused k\u00fcmnele kliendile?<\/h2>\n<p><\/p>\n<blockquote><p>Meil on mitu kasutajat, kes armastavad tulla v\u00e4ga suurte p\u00e4ringutega samal ajal. P\u00e4ring on suur, tegelikult t\u00e4idetakse see kiiresti, kuid kuna selliseid p\u00e4ringuid on korraga palju, muutub see t\u00f5eliselt valusaks. Kas on v\u00f5imalik sama p\u00e4ringut, mis saadeti k\u00fcmme korda j\u00e4rjest, t\u00e4ita ainult \u00fcks kord ja tagasi anda selle tulemuse k\u00fcmnele kliendile?<\/p><\/blockquote>\n<p>Probleem on selles, et meil ei ole tulemuste vahem\u00e4lu ega vahem\u00e4lu vahedata aruandeid. On olemas operatsioonis\u00fcsteemi page cache, mis v\u00f5imaldab andmeid uuesti kettalt lugemata j\u00e4tta, kuid kahjuks andmed peavad ikkagi dekompresseerima, deserialiseerima ja uuesti t\u00f6\u00f6tlema. <\/p>\n<p><\/p>\n<p>Tahaksime seda kuidagi v\u00e4ltida, kas siis vaheandmete salvestamise v\u00f5i sarnaste p\u00e4ringute paigutamise kaudu j\u00e4rjekorda ja tulemuste vahem\u00e4lu lisamisega. Praegu on meil arenduses \u00fcks pull request, mis lisab p\u00e4ringute vahem\u00e4lu, kuid ainult alamp\u00e4ringutele in ja join sektsioonides - seega lahendus pole t\u00e4ielik.<\/p>\n<p><\/p>\n<p>Kuid ka meil tekib selline olukord. Eriti klassikaline n\u00e4ide&nbsp;\u2014 need on p\u00e4ringud lehtede kaupa. On aruanne, milles on mitu lehte ja p\u00e4ring on limit 10. Siis sama asi, aga limit 10,10. Siis veel j\u00e4rgmine leht. Ja k\u00fcsitakse, miks me seda iga kord arvutame? Kuid praegu pole lahendust, ja seda ei saa v\u00e4ltida.<\/p>\n<p><\/p>\n<p>On alternatiivne lahendus, mis paigaldatakse ClickHouse'i k\u00f5rvale&nbsp;\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'l on sisse ehitatud kiiruspiiraja ja tulemuste vahem\u00e4lu. Seal on palju seadeid, kuna lahendati sarnane probleem. Proxy v\u00f5imaldab piirata p\u00e4ringute arvu, j\u00e4rjekorda seades ja seadistada, kui kaua p\u00e4ringu vahem\u00e4lu kehtib. Kui p\u00e4ringud on t\u00f5eliselt sarnased, annab Proxy need mitu korda, kuid l\u00e4heb ClickHouse'i vaid korra.<\/p>\n<p><\/p>\n<p>Nginxil on samuti tasuta versioonis vahem\u00e4lu, ja see t\u00f6\u00f6tab. Nginx'il on isegi seaded, et kui p\u00e4ringud saabusid samal ajal, siis ta viivitab teistega, kuni \u00fcks on t\u00e4idetud. Kuid ClickHouse Proxy seadistus on palju parem. See on tehtud just ClickHouse'i jaoks, just nende p\u00e4ringute jaoks, seega on see paremini sobiv. Ja seda on lihtne paigaldada. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Kuidas suhelda as\u00fcnkroonsete operatsioonide ja materialiseeritud vaadetega?<\/h2>\n<p><\/p>\n<blockquote><p>On selline probleem, et replikaatoriga toimingud on as\u00fcnkroonilised&nbsp;\u2014 algul salvestatakse andmed, seej\u00e4rel toimub nende kokkukuulamine. Kui tabeli all elab m\u00f5ni materialiseeritud tabel mingite agregaatidega, siis dubli sinna salvestatakse. Ja kui puudub m\u00f5ni keeruline loogika, siis andmed dubleeritakse. Mida sellega teha?<\/p>\n<p>On ilmne lahendus&nbsp;\u2014 rakendada triggerit teatud klassi materjalivaatlusele as\u00fcnkroonilise kokkukildumise toimingu puhul. Kas on mingeid \u201eh\u00f5bedasi kuulip\u00fcsse\u201d, plaane selliste funktsionaalsuste rakendamiseks?<\/p><\/blockquote>\n<p>Tuleb aru saada, kuidas t\u00f6\u00f6tab deduplikeerimine. See, millest ma praegu r\u00e4\u00e4gin, ei kuulu k\u00fcsimuse alla, kuid igaks juhuks tasub seda meeles pidada.<\/p>\n<p><\/p>\n<p>Replikatiivses tabelis sisestamisel toimub t\u00e4ielike sisestusblokke de-duplitseerimine. Kui olete uuesti sisestanud sama ploki, mis sisaldab sama arvu samu ridu samas j\u00e4rjekorras, de-duplitseeritakse andmed. Te saate \u201eOk\u201d vastuseks insert'ile, kuid tegelikult salvestatakse ainult \u00fcks andmepartii, ja see ei ole topelt.<\/p>\n<p><\/p>\n<p>See on vajalik m\u00e4\u00e4ratlemise jaoks. Kui sisestamisel saad \u201eOk\u201d, siis t\u00e4hendab, et teie andmed on sisestatud. Kui saite viga ClickHouse'ilt, siis need ei ole sisestatud ja tuleb sisestamine uuesti teha. Kuid kui \u00fchendus katkes sisestamise ajal, siis te ei tea, kas andmed on sisestatud v\u00f5i mitte. Ainus variant on uuesti sisestada. Kui andmed t\u00f5epoolest olid sisestatud ja sisestate need uuesti, toimub plokkide de-duplitseerimine. See on vajalik dubleerimise v\u00e4ltimiseks. <\/p>\n<p><\/p>\n<p>Ja on oluline, kuidas see t\u00f6\u00f6tab materialiseeritud vaadete jaoks. Kui andmed on peamise tabeli sisestamise ajal de-duplitseeritud, siis materialiseeritud vaatesse need ei l\u00e4he samuti.<\/p>\n<p><\/p>\n<p>N\u00fc\u00fcd k\u00fcsimuse juurde. Teil on keerulisem olukord, sest te salvestate konkreetsete ridade dubleerimist. See t\u00e4hendab, et mitte \u00fckski plokk ei ole t\u00e4ielikult topelt, vaid need on konkreetsed read, ja need \u201elangeb kokku\u201d tagaplaanil. T\u00f5epoolest, andmed kokku langevad peamises tabelis, kuid materialiseeritud vaatesse l\u00e4hevad mitte kokku langenud andmed, ja liitmiste k\u00e4igus ei juhtu materialiseeritud vaadetega midagi. Sest materialiseeritud vaade on mitte midagi muud kui insert'i k\u00e4ivitaja. Teiste operatsioonide k\u00e4igus ei toimu sellega midagi lisaks.<\/p>\n<p><\/p>\n<p>Ja ma siit mingil viisil ei suuda r\u00f5\u00f5mu tuua. Tuleb ainult otsida konkreetset lahendust selle juhtumi jaoks. N\u00e4iteks, kas on v\u00f5imalik teha materialiseeritud vaates ka replaacering ja v\u00f5ib-olla t\u00f6\u00f6tab de-duplitseerimise meetod samuti. Kuid kahjuks ei ole see alati v\u00f5imalik. Kui see on agregaatvaade, siis ei \u00f5nnestu. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Meil oli ka oma ajal omajagu \u201ekruvide\u201d ehitamist. Oli probleem, et on reklaamiedastused, ja on teatud andmed, mida me saame reaalajas n\u00e4idata \u2013 need on lihtsalt n\u00e4itamised. Need harva dubleeritakse, kuid kui see juhtub, siis me kokku langetame need ikkagi hiljem. Ja oli asju, mida ei tohtinud dubleerida \u2013 klikke ja kogu seda lugu. Kuid neid tahtis ka praktiliselt kohe n\u00e4idata.<\/p>\n<p><\/p>\n<p>Kuidas nii materialiseeritud vaateid tehtud oli? Oli vaateid, kuhu kirjutatakse otse \u2013 salvestatakse toore andmed, ja kirjutatakse vaadetesse. Seal mingil hetkel ei ole andmed v\u00e4ga \u00f5iged, need dubleeritakse ja nii edasi. Ja on teine osa tabelist, kus need n\u00e4evad v\u00e4lja t\u00e4pselt samasugustena nagu materialiseeritud vaated, st struktuurilt on need t\u00e4iesti identsed. Iga m\u00f5ne aja tagant me arvutame andmeid \u00fcmber, loeme andmeid ilma dubleerimisteta ja kirjutame nendesse tabelitesse. <\/p>\n<p><\/p>\n<p>K\u00e4isime l\u00e4bi API \u2013 ClickHouse'is k\u00e4sitsi see ei t\u00f6\u00f6ta. Ja API vaatab: kui mul on viimane lisamise kuup\u00e4ev tabelis, kus on garantiiga \u00f5iged andmed, arvutatud, ja ta teeb p\u00e4ringu \u00fchte tabelisse ja teise tabelisse. \u00dchest k\u00fcsib ta teatud ajavahemikus ja teisest lisab seda, mis veel pole arvutatud. Ja see t\u00f6\u00f6tab, kuid mitte \u00fche ClickHouse'i vahenditega.<\/p>\n<p><\/p>\n<p>Kui teil on mingi API \u2013 anal\u00fc\u00fctikutele, kasutajatele \u2013 siis p\u00f5him\u00f5tteliselt on see variant. Te alati arvutate, alati loete. Seda v\u00f5ib teha kord p\u00e4evas v\u00f5i veel m\u00f5nel muul ajal. Te ise valite vahemiku, mis teile ei ole vajalik ja 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 toimub, hetkel?<\/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 v\u00e4rskendamisel sisse l\u00fclitada. Sellegipoolest, neid tuleb aina rohkem ja rohkem. Tahaksin l\u00f5puks n\u00e4ha, mis toimub minu serveriga, v\u00f5ib-olla mingil kokkuv\u00f5tete armatuurlaud. <\/p>\n<p>Kas teil ei ole ClickHouse'i meeskonnas v\u00f5i teie s\u00f5prade meeskondades, kes toetavad mingit funktsionaalsust valmis armatuurlauad, mis need logid juba valmis toote kujul kuvavad? L\u00f5ppkokkuv\u00f5ttes on lihtsalt logide vaatamine ClickHouse'is \u2013 see on hea. Kuid oleks v\u00e4ga \u00e4ge, kui see oleks juba armatuurlaud kujul ette valmistatud. Ma naudiks seda. <\/p><\/blockquote>\n<p>Dashboardid on olemas, kuigi need ei ole standardiseeritud. Meie ettev\u00f5ttes kasutab ClickHouse'i umbes 60 meeskonda ja k\u00f5ige veidram on see, et paljudel neist on enda loodud dashboards, mis on veidi erinevad. M\u00f5ned meeskonnad kasutavad Yandex.Cloudi sisemist installatsiooni. Seal on m\u00f5ned valmis aruanded, kuid mitte k\u00f5ik vajalikud. Teistel on oma. <\/p>\n<p><\/p>\n<p>Minu kolleegidel Metricas on oma dashboard Grafanas, ja mul on oma nende klastris. Ma j\u00e4lgin seal selliseid asju nagu vahem\u00e4lu hits vahem\u00e4lu m\u00f5\u00f5tmistes. Ja veel keerulisem on see, et me kasutame erinevaid t\u00f6\u00f6riistu. Oma dashboard'i l\u00f5in ma v\u00e4ga vanas t\u00f6\u00f6riistas, mida nimetatakse Graphite-web. See on t\u00e4iesti kole. Ja ma kasutan seda siiani, kuigi Grafana oleks t\u00f5en\u00e4oliselt mugavam ja ilusam. <\/p>\n<p><\/p>\n<p>Dashboard'ide p\u00f5hiline sisu on sama. Need on s\u00fcsteemi m\u00f5\u00f5dikud klastri kohta: CPU, m\u00e4lu, kettaruumi, v\u00f5rk. Teised \u2013 samaaegsete p\u00e4ringute arv, samaaegsete \u00fchinemiste arv, sekundis tehtud p\u00e4ringute arv, maksimaalne partitsioonide t\u00fckkide arv MergeTree tabelites, replikaatsiooni viivitus, replikaatsiooni j\u00e4rjekorra suurus, sekundis sisestatud ridade arv, sekundis sisestatud plokkide arv. Need k\u00f5ik on m\u00f5\u00f5dikud, mis ei p\u00e4rine logidest.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Aleksei, ma sooviksin seda natuke t\u00e4psustada. On olemas Grafana. Grafanal on andmeallikas, mis 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. Ma tahaksin, et Grafanas suudaksin selle logide tabeli kaudu n\u00e4ha neid p\u00e4ringuid, mida minu server esitab. Sellise dashboard'i omamine oleks suurep\u00e4rane.<\/p>\n<p><\/p>\n<p>Ma tegin selle ise. Kuid mul on k\u00fcsimus \u2014 kui k\u00f5ik on standardiseeritud ja Grafanat kasutatakse igal pool, miks ei ole Yandexis sellist ametlikku dashboard'i?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Tegelikult toetab ClickHouse'i andmeallikat praegu Altinity. Ja ma tahan lihtsalt suunata, kuhu kaevata ja keda suruda. Neilt v\u00f5iks k\u00fcsida, sest Yandex teeb ClickHouse'i, mitte selle \u00fcmber olevat ajalugu. Altinity on peamine ettev\u00f5te, mis praegu ClickHouse'i edendab. Nad ei j\u00e4ta seda, vaid toetavad seda. Sest p\u00f5him\u00f5tteliselt, et laadida dashboard'i Grafana saidile, piisab ainult registreerimisest ja selle \u00fcleslaadimisest \u2014 erilisi probleeme ei ole. <\/p>\n<p><\/p>\n<p><strong>Alexei Milovidov:<\/strong> Viimase aasta jooksul on ClickHouse'i lisatud palju v\u00f5imalusi p\u00e4ringute profileerimiseks. Iga p\u00e4ringu ressursside kasutamise kohta on olemas m\u00f5\u00f5dikud. Ja hiljuti lisati veel madalama tasandi p\u00e4ringu profilaator, et n\u00e4ha, kus p\u00e4ring kulutab iga millisekundi. Kuid selle funktsionaalsuse kasutamiseks pean avama konsooli klienti ja sisestama p\u00e4ringu, mida ma pidevalt unustan. Ma olen selle kuhugi salvestanud ja pidevalt unustan, kuhu t\u00e4pselt. <\/p>\n<p><\/p>\n<p>Sooviksin, et oleks olemas t\u00f6\u00f6riist, mis lihtsalt \u00fctleb - siin on teie rasked p\u00e4ringud, r\u00fchmitatuna p\u00e4ringute klasside j\u00e4rgi. Kl\u00f5psasin m\u00f5nel ja mulle \u00f6eldakse, et see on raske, sest sellep\u00e4rast. Praegu sellist lahendust ei ole. Ja t\u00f5epoolest on \u00fcsna kummaline, et kui inimesed minult k\u00fcsivad: \"Kas on mingeid valmis dashboard'e Grafana jaoks?\", r\u00e4\u00e4gin: \"Mine Grafana saidile, seal on kogukonna 'Dashboard'id', ja seal on dashboard Dima poolt, seal on dashboard Kostya poolt. Mis see 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 \u00fchinemisi, et server ei kukuks OOM-i?<\/h2>\n<p><\/p>\n<blockquote><p>Mul on tabel, milles on ainult \u00fcks partitsioon, see on ReplacingMergeTree. Olen sinna andmeid kirjutanud juba neli aastat. Mul tuli teha seal alter ja kustutada m\u00f5ned andmed.<\/p>\n<p>Ma tegin selle ning selle p\u00e4ringu t\u00f6\u00f6tlemise k\u00e4igus tarviti kogu m\u00e4lumaht k\u00f5igil klastri serveritel, ja k\u00f5ik klastri serverid kukkusid \u00fcheaegselt OOM-i. Seej\u00e4rel t\u00f5usid k\u00f5ik koos \u00fcles, hakkasid seda sama operatsiooni ja andmeplokki \u00fchinema ja kukkusid j\u00e4lle OOM-i. Siis t\u00f5usid nad taas ja kukkusid j\u00e4lle. Ja see p\u00f5him\u00f5tteliselt ei l\u00f5ppenud.<\/p>\n<p>Siis selgus, et see oligi tegelikult bug, mille poisid parandasid. See on v\u00e4ga tore, suur t\u00e4nu. Kuid negatiivne tunne j\u00e4i alles. Ja n\u00fc\u00fcd, kui ma m\u00f5tlen, et peaksin tegema mingit \u00fchinemist tabelis, tekib mul k\u00fcsimus \u2014 miks ma ei saa mingil viisil neid \u00fchinemisi m\u00f5jutada? N\u00e4iteks piirata neid vajaliku m\u00e4lumahtude j\u00e4rgi v\u00f5i \u00fcldse nende arvu j\u00e4rgi, mida konkreetne tabel t\u00f6\u00f6tleb.<\/p>\n<p>Mul on tabel, mis kannab nime \u201eMetrika\u201d, palun t\u00f6\u00f6tle see kahes voos. \u00c4rge paluge mul toota k\u00fcmmet v\u00f5i viit mergit paralleelselt, tehke kahes. Ma arvan, et kahes on minu m\u00e4lu piisav, aga k\u00fcmne t\u00f6\u00f6tlemiseks ei pruugi piisata. Miks hirm j\u00e4\u00e4b? Sest tabel kasvab ja kunagi satuvad nad sellisesse olukorda, et see ei ole enam veast, vaid andmed muutuvad nii suures koguses, et mul ei j\u00e4\u00e4 lihtsalt serveris m\u00e4lu j\u00e4rele. Ja siis server kukub OOM-iks mergimisel. Mutaation ma saan tagasi v\u00f5tta, kuid mergid mitte.<\/p><\/blockquote>\n<p>Teate, mergimisel ei kuku server OOM-i, sest mergimise k\u00e4igus kasutatakse m\u00e4lu vaid v\u00e4ikese andmete ulatuse jaoks. Nii et k\u00f5ik l\u00e4heb h\u00e4sti, s\u00f5ltumata andmete mahust.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> K\u00f5ik. Siin on see hetk, et p\u00e4rast vea parandamist laadisin endale uue versiooni ja teises, v\u00e4iksemas tabelis, kus on palju partitsioone, tegin sarnase toimingu. Ja mergimise k\u00e4igus kulus serveris umbes 100 GB RAM-i. Mul oli 150 kasutuses, 100 v\u00f5ttis \u00e4ra ja j\u00e4\u00e4nud oli 50 GB, seega ma ei kukkunud OOM-i.<\/p>\n<p><\/p>\n<p>Mis mind praegu kaitseb OOM-i kukkumise eest, kui see t\u00f5eliselt tarbib 100 GB RAM-i? Kuidas k\u00e4ituda olukorras, kui n\u00e4iteks mergimiseks ei j\u00e4tku RAM-i?<\/p>\n<p><\/p>\n<p><strong>Alexei Milovidov:<\/strong> On selline probleem, et RAM-i tarbimine merges ei piirdu ainult sellega. Ja teine probleem on see, et kui mingit mergimist on m\u00e4\u00e4ratud, tuleb see t\u00e4ita, sest see on salvestatud replikatsiooni logisse. Replikatsiooni logi on tegevused, mis on vajalikud, et viia replikatsioon j\u00e4rjepidevasse olekusse. Kui ei tehta k\u00e4sitsi toiminguid, mis selle replikatsiooni logi tagasi v\u00f5tavad, tuleb mergimine igal juhul teostada.<\/p>\n<p><\/p>\n<p>Loomulikult oleks kasulik piirata RAM-i kasutamist, mis \u201eigaks juhuks\u201d kaitseb just OOM-i ees. See ei aita m\u00fcrgimisel toimetada, see hakkab uuesti algama, saavutab mingisuguse piiri, viskab erandi ja siis hakkab j\u00e4lle alates \u2014 sellest ei tule midagi head. Aga p\u00f5him\u00f5tteliselt oleks see piiramine sisse viia siiski kasulik.<\/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 Golangi draiveri arendamine ClickHouse'i jaoks?<\/h2>\n<p><\/p>\n<blockquote><p>Golang draiver, mille on kirjutanud Kirill Shvakov, n\u00e4ib n\u00fc\u00fcd olema ametlikult toetatud ClickHouse'i meeskonna poolt. Ta <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">on ClickHouse'i hoidlas<\/a><\/noindex>, ta on n\u00fc\u00fcd suur ja t\u00f5eline.<\/p>\n<p>V\u00e4ike m\u00e4rk. On olemas suurep\u00e4rane ja k\u00f5igile armastusv\u00e4\u00e4rne normaalsete l\u00f5pmatute j\u00e4rjestuste hoidla \u2014 Vertica. Neil on ka oma ametlik Python-draiver, mida toetavad Vertica arendajad. On olnud kordi, kui hoidla ja draiveri versioonid erinevad \u00fcksteisest oluliselt ning draiver lakkab mingil hetkel t\u00f6\u00f6tamast. Teine asi. Selle ametliku draiveri tugi, nagu mulle tundub, p\u00f5hineb s\u00fcsteemil \"nipel\" \u2014 kirjutad neile probleemist, ja see j\u00e4\u00e4b igaveseks ootele.<\/p>\n<p>Mul on kaks k\u00fcsimust. Praegu on Kirilli Golang-draiver peaaegu vaikimisi viis kommunikatsiooniks Golangi ja ClickHouse'i vahel. Olgu, et keegi suhtleb endiselt HTTP liidese kaudu, kuna talle see sobib. Kuidas toimub selle draiveri arendamine? Kas see s\u00fcnkroniseeritakse hoidlas toimuvate breaking changes'idega? Ja kuidas toimub probleemide arutamine? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> Esiteks \u2014 kuidas k\u00f5ik on b\u00fcrokraatlikult \u00fcles ehitatud. Seda hetke ei arutatud, seega ei oska ma vastata.<\/p>\n<p><\/p>\n<p>Et vastata k\u00fcsimusele seoses probleemiga, on vajalik v\u00e4ike ajalugu draiverist. Ma t\u00f6\u00f6tasin firmas, kus oli palju andmeid. See oli reklaamimootor tohutu hulga s\u00fcndmustega, mida oli kusagil vaja salvestada. Ja mingil hetkel tuli ClickHouse. Me laadisime sinna andmed ja alguses l\u00e4ks k\u00f5ik h\u00e4sti, aga siis kukkus ClickHouse. Sel ajal otsustasime, et see ei ole meie jaoks vajalik. <\/p>\n<p><\/p>\n<p>Aasta p\u00e4rast tulime tagasi ideele kasutada ClickHouse\u2019i ja meil oli kuidagi sinna andmeid kirjutada. Sissejuhatus oli selline \u2014 riistvara oli v\u00e4ga n\u00f5rk, ressursse oli v\u00e4he. Aga me oleme alati nii t\u00f6\u00f6tanud ja seega vaatasime kohaliku protokolli poole.<\/p>\n<p><\/p>\n<p>Kuna me t\u00f6\u00f6tasime Go keeles, oli selge, et vajalik on Go draiver. Ma tegin seda praktiliselt t\u00e4iskohaga \u2014 see oli minu t\u00f6\u00f6\u00fclesanne. Kuni mingisuguse hetkeni viimistlesime seda ja p\u00f5him\u00f5tteliselt ei osanud keegi arvata, et keegi peale meie hakkab seda kasutama. Siis tuli CloudFlare sama probleemiga ja mingil hetkel t\u00f6\u00f6tasime nendega v\u00e4ga sujuvalt, sest nende \u00fclesanded olid samad. Tegime seda nii ClickHouse\u2019is kui ka draiveris. <\/p>\n<p><\/p>\n<p>Mingil hetkel l\u00f5petasin selle tegevuse, sest minu aktiivsus ClickHouse\u2019i osas ja t\u00f6\u00f6 osas muutus veidi. Seet\u00f5ttu ei suudeta probleeme lahendada. Aeg-ajalt kommitavad inimesed ladustamise, kellel endal on midagi vajalikku. Siis ma vaatan pull request\u2019e ja vahel isegi ise midagi muutma, kuid see juhtub harva.<\/p>\n<p><\/p>\n<p>Draiverisse tahaks tagasi p\u00f6\u00f6rduda. Mitmeid aastaid tagasi, kui see k\u00f5ik algas, oli ClickHouse ka erinev ning muud v\u00f5imalused. N\u00fc\u00fcd on aga aru saadud, kuidas draiverit uuendada, et see oleks hea. Kui see juhtub, siis versioon 2 on igal juhul \u00fchilduv, kuna on akumuleeritud palju kohandusi. <\/p>\n<p><\/p>\n<p>Kuidas seda korraldada, ma ei tea. Mul endal ei ole v\u00e4ga palju aega. Kui m\u00f5ni inimene hakkab draiverit t\u00e4iustama, saan neile aidata ja r\u00e4\u00e4kida, mida teha. Kuid Yandex\u2019i aktiivne osalus projekti arendamisel ei ole veel kuidagi arutatud. <\/p>\n<p><\/p>\n<p><strong>Alexei Milovidov:<\/strong> Tegelikult ei ole nende draiverite osas veel mingit b\u00fcrokraatiat. Ainult see, et nad on viidatud ametlikule organisatsioonile, see t\u00e4hendab, et see draiver on Go vaikimisi ametlik lahendus. On olemas teisi draivereid, kuid need on eraldi. <\/p>\n<p><\/p>\n<p>Meil ei ole nende draiverite jaoks siseprojekti. K\u00fcsimus on, kas suudame palgata eraldi inimesi, mitte just selle draiveri jaoks, vaid k\u00f5igi kogukonna draiverite arendamiseks, v\u00f5i suudame leida 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, kui lazy_load seadistus on sisse l\u00fclitatud. Mida teha?<\/h2>\n<p><\/p>\n<blockquote><p>Meil on lazy_load seadistus sisse l\u00fclitatud, ja p\u00e4rast serveri taask\u00e4ivitamist s\u00f5nastik ei t\u00f5use ise. See t\u00f5useb ainult p\u00e4rast seda, kui kasutaja p\u00f6\u00f6rdub selle s\u00f5nastiku poole. Ja esimesel p\u00f6\u00f6rdumisel annab see vea. Kas ClickHouse'i abil on v\u00f5imalik s\u00f5nastikke automaatselt laadida, v\u00f5i peame alati j\u00e4lgima, et need oleksid valmis, et kasutajad ei saaks vigu?<\/p>\n<p>V\u00f5ib-olla on meil vana versioon ClickHouse'ist, mist\u00f5ttu s\u00f5nastik ei laaditud automaatselt. Kas see v\u00f5ib olla nii?<\/p><\/blockquote>\n<p>Esiteks, s\u00f5nastikke saab sundida laadima p\u00e4ringu kaudu <strong>s\u00fcsteemi s\u00f5nastike uuendamine<\/strong>. Teiseks, vea kohta \u2014 kui s\u00f5nastik on juba laaditud, siis p\u00e4ringud t\u00f6\u00f6tavad nende andmete p\u00f5hjal, mis on laaditud. Kui s\u00f5nastik ei ole veel laaditud, siis see laaditakse otse p\u00e4ringu k\u00e4igus.<\/p>\n<p><\/p>\n<p>Raskete s\u00f5nastike puhul ei ole see eriti mugav. N\u00e4iteks tuleb MySQL-ist t\u00f5mmata miljon rida. Keegi teeb lihtsa select'i, aga see select ootab seda miljonit rida. Siin on kaks lahendust. Esimene \u2014 l\u00fclitame lazy_load v\u00e4lja. Teine \u2014 kui server t\u00f5useb, enne kui sellele koormust rakendada, teeme <strong>s\u00fcsteemi s\u00f5nastiku uuendamine<\/strong> v\u00f5i lihtsalt t\u00e4idame p\u00e4ringu, mis kasutab s\u00f5nastikku. Siis s\u00f5nastik laaditakse. Peame ise j\u00e4lgima s\u00f5nastike k\u00e4ttesaadavust, kui lazy_load on sisse l\u00fclitatud, sest ClickHouse ei too neid automaatselt.<\/p>\n<p><\/p>\n<p>Viimasele k\u00fcsimusele vastus \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 lahendada olukord, kus system reload dictionaries ei laadi mitte \u00fchtegi paljusid s\u00f5naraamatuid, kui v\u00e4hemalt \u00fcks neist kukub veaga?<\/h2>\n<p><\/p>\n<blockquote><p>On veel k\u00fcsimus system reload dictionaries kohta. Meil on kaks s\u00f5nastikku \u2014 \u00fcks ei lae, teine laeb. System reload dictionaries sellisel juhul ei Lae \u00fchtki s\u00f5nastikku, ja tuleb konkreetselt laadida konkreetne selle nime abil system reload dictionary kaudu. Kas see on ka seotud ClickHouse'i versiooniga?<\/p><\/blockquote>\n<p>Tahaksin teile head uudist. See k\u00e4itumine on muutunud. Seega, kui te uuendate ClickHouse'i, siis see muutub ka. Kui teile praegune k\u00e4itumine ei meeldi, <strong>s\u00fcsteemi s\u00f5nastike uuendamine<\/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 konfiguraatoris aktsess-juhiseid, kuid mitte n\u00e4idata neid vead?<\/h2>\n<p><\/p>\n<blockquote><p>J\u00e4rgmine k\u00fcsimus on s\u00f5nastikuga seotud vigade osas, nimelt tunnusandmed. Me oleme m\u00e4\u00e4ranud \u00fchenduse tunnusandmed ClickHouse'i konfigureerimisse s\u00f5nastiku jaoks, ja vea korral saame need tunnusandmed ja parooli vastuses. <\/p>\n<p>Oleme lahendanud selle vea, viies tunnusandmed ODBC draiveri konfi. Kas on mingi v\u00f5imalus konfigureerida tunnusandmed ClickHouse'i konfigureerimisse, aga mitte neid kuvada vigade korral?<\/p><\/blockquote>\n<p>Siin on lahendus \u2014 m\u00e4rkida need t\u00e4hised odbc.ini, ja ClickHouse'is m\u00e4rkida ainult ODBC Data Source Name. Muude s\u00f5nastike allikate puhul ei tohiks seda juhtuda \u2014 ei MySQL-i s\u00f5nastiku ega teiste puhul ei tohiks parooli n\u00e4ha vale korral. ODBC puhul vaatan ka \u2014 kui selline asi on, tuleks 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: Zoomi taustad koos kohtumistelt<\/h2>\n<p><\/p>\n<p>Pildile kl\u00f5psates avanevad k\u00f5ige vastupidavamatele lugejatele boonusfondid istumisteks. Kustutame tule koos Avito tehnoloogiate maskottidega, arutame kolleegidega s\u00fcsteemiadministraatori ruumist v\u00f5i vanakooli arvutiklubist ja korraldame igap\u00e4evase koosoleku silla all grafiti taustal.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse edasij\u00f5udluse kasutajatele k\u00fcsimustes ja vastustes\" 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.0.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.0.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 edas kasutajatele k\u00fcsimustes ja vastustes | ProHoster","description":"Aprillis plaanis Avito insenerid veebikoosolekul osaleda ClickHouse'i pea\u00e4rendaja Aleksei Milovidovi ja Golang-arendaja Kirill Shvakovi, kes on ettev\u00f5ttes Integros.","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}]}}