{"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\/hr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse za napredne korisnike kroz pitanja i odgovore","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>U travnju su in\u017eenjeri Avita planirali online sastanak s glavnim programerom ClickHouseom Aleksejem Milovidovim i Kirilom Shvakovim, Golang programerom iz tvrtke Integros. Raspravljali su o tome kako koristimo sustav upravljanja bazama podataka i koje se pote\u0161ko\u0107e javljaju. <\/p>\n<p><\/p>\n<p>Na temelju sastanka sastavili smo \u010dlanak s odgovorima stru\u010dnjaka na na\u0161a i pitanja gledatelja o backupima, reshrodingu podataka, vanjskim rje\u010dnicima, Golang voza\u010du i a\u017euriranju verzija ClickHouse. Mo\u017ee biti koristan programerima koji ve\u0107 aktivno rade s DB-om \"Yandex\" i zanimaju ih njezina sada\u0161njost i budu\u0107nost. Po defaultu, odgovori Alekseja Milovidova, osim ako nije druga\u010dije navedeno. <\/p>\n<p><\/p>\n<p>Pa\u017eljivo, ispod je mnogo teksta. Nadamo se da \u0107e sadr\u017eaj s pitanjima pomo\u0107i da se orijentirate.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse za napredne korisnike kroz pitanja i odgovore\" 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\">Sadr\u017eaj<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse se stalno a\u017eurira, a na\u0161i podaci - ne. \u0160to u\u010diniti s tim?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Koje su trenutno najbolje prakse za rezervno kopiranje podataka iz ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">Ho\u0107e li biti mogu\u0107e organizirati kontrolirani odmak replikacija u valovima?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">\u0160to u\u010diniti ako se struktura tablice promijenila?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Koje su sada najbolje prakse u reshrodingu podataka?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">U ClickHouse postoji alat clickhouse-copier. Mo\u017eete li o tome re\u0107i ne\u0161to?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Imali ste pilot-projekt koji se zvao reshroding. \u0160to se s njim dogodilo?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">Mo\u017ee li se sve dijelove podataka spojiti zajedno prije premje\u0161tanja na spore diskove?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Kako se mo\u017ee pre\u0107i na nove verzije ClickHouse ako ne postoji mogu\u0107nost prethodnog provjeravanja kompatibilnosti?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">Kill query bi trebao ubijati upite, ali to ne radi. Za\u0161to?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Kako izra\u010dunati vrijeme odgovora pri \u010ditaju\u0107em optere\u0107enju?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">\u0160to optimizirati u ClickHouseu kako bi vi\u0161e podataka bilo u \u043a\u0435\u0448\u0443?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Kako se mo\u017ee podesiti storage_configuration za pohranu u radnoj memoriji?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Do koje je koli\u010dine jedinstvenih vrijednosti Low Cardinality u\u010dinkovit?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Koje su najbolje prakse za pretra\u017eivanje po cjelovitom tekstu na tablici s pet milijardi redaka?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Kako najbolje organizirati pristup u ClickHouse za veliki broj korisnika?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">Mo\u017ee li se dati rezultati jednog upita deset klijentima?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">\u0160to u\u010diniti s asinkronim operacijama i materializiranim prikazima?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">U ClickHouseu ima mnogo logova. Kako mogu vidjeti sve \u0161to se doga\u0111a sa serverom u trenutku?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Kako utjecati na merge-ove kako server ne bi pao zbog OOM-a?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Kako \u0107e se razvijati Golang voza\u010d za ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">Vanjski rje\u010dnik se ne u\u010ditava nakon ponovnog pokretanja s uklju\u010denim postavkom lazy_load. \u0160to u\u010diniti?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">\u0160to u\u010diniti s tim da system reload dictionaries ne u\u010ditava niti jedan od mnogih rje\u010dnika ako barem jedan od njih ne uspije s gre\u0161kom?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Postoji li na\u010din da se konfiguri\u0161u podaci u&nbsp;ClickHouse konfiguraciji, ali da se ne prika\u017eu u slu\u010daju gre\u0161ke?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus: pozadine za Zoom s&nbsp;dru\u017eenja<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Ako ne \u017eelite \u010ditati tekst, mo\u017eete pogledati snimku okupljanja <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">na&nbsp;na\u0161em YouTube kanalu<\/a><\/noindex>. Vremenski kodovi \u2014 u&nbsp;prvom komentaru ispod&nbsp;vide\u0430.<\/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 se stalno a\u017eurira, dok se na\u0161i podaci&nbsp;ne a\u017euriraju. \u0160to u\u010diniti u vezi s&nbsp;tim?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse se stalno a\u017eurira, a na\u0161i podaci koji su bili optimizirani finalno, se ne a\u017euriraju i le\u017ee u&nbsp;rezervnoj kopiji. <\/p>\n<p>Pretpostavimo da smo imali neku vrstu problema i da su podaci izgubljeni. Odlu\u010dili smo se vratiti, i ispostavilo se da se stari particije, koje su na&nbsp;sadr\u017eaju u&nbsp;rezervnim serverima, vrlo jako razlikuju od trenutne verzije ClickHouse. \u0160to u\u010diniti u toj situaciji, i je li to mogu\u0107e?<\/p><\/blockquote>\n<p>Situacija u kojoj ste obnovili podatke iz&nbsp;rezervne kopije u&nbsp;stari format, a u&nbsp;novoj verziji se ne u\u010ditavaju, nije mogu\u0107a. Mi pazimo da format podataka u&nbsp;ClickHouse uvijek bude backward compatible. To je mnogo va\u017enije nego povratna kompatibilnost funkcionalnosti, ako se promeni pona\u0161anje neke retko kori\u0161\u0107ene funkcije. Podaci koji se \u010duvaju na&nbsp;disku, nova verzija ClickHouse uvijek mora umeti pro\u010ditati. To je zakon. <\/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>Koje su trenutno najbolje prakse za rezervno kopiranje podataka iz ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Kako praviti rezervne kopije uzimaju\u0107i u obzir da imamo operacije optimize final, ogromnu bazu podataka od&nbsp;terabajta, i podatke koji se a\u017euriraju, recimo, poslednja tri dana, a dalje se s&nbsp;nim ne de\u0161ava ni\u0161ta? <\/p>\n<p>Mo\u017eemo napraviti na\u0161e vlastito re\u0161enje i napisati u&nbsp;shellu: sakupljaj ovako i onako te rezervne kopije. Mo\u017eda ni\u0161ta ne treba da\u201ekostruktujemo\u201c, i bicikl je ve\u0107 izmi\u0161ljen? <\/p><\/blockquote>\n<p>Za&nbsp;po\u010detak o najboljim praksama. Moji kolege uvek savetuju u&nbsp;odgovoru na&nbsp;pitanja o&nbsp;rezervnim kopijama da se podseti na&nbsp;uslugu \u201eYandex.\u041e\u0431\u043b\u0430\u043a\u043e\u201c, gde je ovaj problem ve\u0107 re\u0161en. Dakle, koristite to ako imate tu mogu\u0107nost. <\/p>\n<p><\/p>\n<p>Potpuno re\u0161enje, koje je sto posto ugra\u0111eno u&nbsp;ClickHouse za rezervne kopije, ne postoji. Postoje neka re\u0161enja koja se mogu koristiti. Da biste dobili potpuno re\u0161enje, bi\u0107e potrebno ili malo ru\u010dno da se obavi, ili napraviti omotnice u&nbsp;formi skripti.<\/p>\n<p><\/p>\n<p>Po\u010det \u0107u od najjednostavnijih rje\u0161enja i zavr\u0161iti s najnaprednijima, ovisno o koli\u010dini podataka i veli\u010dini klastera. \u0160to je klaster ve\u0107i, to je rje\u0161enje slo\u017eenije.<\/p>\n<p><\/p>\n<p>Ako tablica s podacima zauzima samo nekoliko gigabajta, backup se mo\u017ee napraviti na sljede\u0107i na\u010din: <\/p>\n<p><\/p>\n<ol>\n<li>Spremite definiciju tablica, odnosno metapodatke \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Napravite dump pomo\u0107u ClickHouse klijenta \u2014 <strong>select<\/strong> * <strong>from table<\/strong> u datoteku. Po defaultu dobit \u0107ete datoteku u TabSeparated formatu. Ako \u017eelite u\u010dinkovitije, mo\u017eete u Native formatu. <\/li>\n<\/ol>\n<p><\/p>\n<p>Ako je koli\u010dina podataka ve\u0107a, backup \u0107e potrajati du\u017ee i zauzeti mnogo prostora. Ovo se naziva logi\u010dki backup, nije vezan uz format podataka ClickHouse. Ako ga imate, u ekstremnom slu\u010daju mo\u017eete uzeti backup i u\u010ditati ga u MySQL za obnovu. <\/p>\n<p><\/p>\n<p>Za naprednije slu\u010dajeve, ClickHouse ima mogu\u0107nost stvaranja snimaka particija u lokalnom datote\u010dnom sustavu. Ova mogu\u0107nost je dostupna kao upit <strong>alter table freeze partition<\/strong>. Ili jednostavno <strong>alter table freeze<\/strong> \u2014 to je snapshot cijele tablice. <\/p>\n<p><\/p>\n<p>Snimak \u0107e biti konzistentan za jednu tablicu na jednom shardu, to jest stvoriti konzistentan snimak cijelog klastera na taj na\u010din nije mogu\u0107e. No, za ve\u0107inu zadataka takva potreba ne postoji, i dovoljno je na svakom shardu izvr\u0161iti upit i dobiti konzistentan snimak. Stvara se kao hardlinkovi i stoga ne zauzima dodatni prostor. Zatim ovaj snimak kopirate na backup server ili u skladi\u0161te koje koristite za backup.<\/p>\n<p><\/p>\n<p>Obnoviti takav backup je prili\u010dno lako. Prvo \u2014 kreirate tablice prema postoje\u0107im definicijama tablica. Zatim kopirate pohranjene snimke particija u Directory-Detached za podatke tablica i izvr\u0161avate upit <strong>attach partition<\/strong>. Ovo rje\u0161enje je sasvim prikladno za najsrda\u010dnije koli\u010dine podataka. <\/p>\n<p><\/p>\n<p>Ponekad je potrebno ne\u0161to jo\u0161 naprednije \u2014 u slu\u010dajevima kada imate desetke ili \u010dak stotine terabajta na svakom serveru i stotine servera. Ovdje postoji rje\u0161enje koje sam primijetio kod kolega iz 'Yandex.Metrica'. Ne bih ga preporu\u010dio svima \u2014 pro\u010ditajte i sami odlu\u010dite da li vam odgovara. <\/p>\n<p><\/p>\n<p>Prvo je potrebno stvoriti nekoliko poslu\u017eitelja s&nbsp;velikim skladi\u0161tima podataka. Zatim na&nbsp;tim poslu\u017eiteljima pokrenuti nekoliko ClickHouse poslu\u017eitelja i konfigurirati ih tako da rade kao jo\u0161 jedna replika za iste shardove. Nakon toga koristiti na&nbsp;tim poslu\u017eiteljima datote\u010dni sustav ili neki alat koji omogu\u0107ava izradu snimaka. Ovdje postoje dvije opcije. Prva opcija je LVM snimke, druga opcija je ZFS na&nbsp;Linuxu. <\/p>\n<p><\/p>\n<p>Nakon toga svaki dan treba stvarati snimku, ona \u0107e zauzimati odre\u0111eno mjesto. Naravno, ako se podaci mijenjaju, vremenom \u0107e prostor postajati ve\u0107i. Ovu snimku mo\u017eemo dohvatiti u&nbsp;bilo kojem trenutku i obnoviti podatke, to je pomalo neobi\u010dno rje\u0161enje. Osim toga, trebamo ograni\u010diti te replike u&nbsp;konfiguraciji, kako ne bi poku\u0161avale postati vo\u0111e.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>Ho\u0107e li biti mogu\u0107e organizirati kontrolirani odmak replikacija u valovima?<\/h2>\n<p><\/p>\n<blockquote><p>Planirate li ove godine raditi valove u&nbsp;ClickHouseu? Ho\u0107e li se mo\u0107i organizirati kontrolirano ka\u0161njenje replika u&nbsp;njima? \u017deljeli bismo se za\u0161tititi od negativnih scenarija s&nbsp;alternativama i drugim promjenama. <\/p>\n<p>Mo\u017ee li se napraviti neki rollback za alternative? Na primjer, u&nbsp;postoje\u0107em valu mo\u017eemo re\u0107i da do&nbsp;tog trenutka primjenjujemo promjene, a od&nbsp;tog trenutka prestanemo primjenjivati promjene?<\/p>\n<p>Ako je u&nbsp;na\u0161 klaster do\u0161la ekipa i o\u0161tetila ga, imamo uvjetnu repliku s&nbsp;ka\u0161njenjem od jednog sata, gdje mo\u017eemo re\u0107i dajmo da koristimo tu repliku u&nbsp;ovom trenutku, ali posljednjih deset minuta promjena u&nbsp;njemu ne\u0107emo primijeniti? <\/p><\/blockquote>\n<p>Prvo o&nbsp;kontroliranom ka\u0161njenju replika. Takav zahtjev od&nbsp;korisnika je postojao, i stvorili smo problem na&nbsp;Githubu s&nbsp;zahtjevom: \"Ako nekome to treba, lajkajte, stavite srce\". Nitko nije lajkao, i problem je zatvoren. Ipak, ve\u0107 sada je mogu\u0107e dobiti tu mogu\u0107nost, postavljanjem ClickHousea. Istina, samo od&nbsp;verzije&nbsp;20.3.<\/p>\n<p><\/p>\n<p>ClickHouse neprekidno u&nbsp;pozadini vr\u0161i spajanje podataka&nbsp;\u2014 merge. Kada je merge izvr\u0161en, odre\u0111eni skup dijelova podataka zamjenjuje se ve\u0107im dijelom. U&nbsp;isto vrijeme, dijelovi podataka koji su bili ranije, nastavljaju ostati na&nbsp;disku odre\u0111eno vrijeme.<\/p>\n<p><\/p>\n<p>Prvo, oni se i dalje \u010duvaju dokle god postoje select upiti koji ih koriste, kako bi se omogu\u0107io rad bez blokiranja. Select upiti mirno \u010ditaju iz starih delova.<\/p>\n<p><\/p>\n<p>Drugo, postoji i vremenski prag \u2014 stari delovi podataka se \u010duvaju na disku osam minuta. Ove osam minuta se mo\u017ee prilagoditi i \u010dak pretvoriti u jedan dan. To \u0107e zauzeti prostor na disku: u zavisnosti od protoka podataka, mo\u017ee se desiti da se tokom poslednjeg dana podaci ne samo udvostru\u010de, ve\u0107 da ih bude pet puta vi\u0161e. Ali mo\u0107i \u0107ete, u slu\u010daju ozbiljnog problema, da zaustavite ClickHouse server i sve re\u0161ite.<\/p>\n<p><\/p>\n<p>Sada se postavlja pitanje, kako ovo \u0161titi od alteracija. Ovde treba dublje pogledati, jer su u starijim verzijama ClickHouse alteracije radile na na\u010din da su direktno menjale delove. Postoji deo podataka s nekim fajlovima, i mi radimo, na primer, <strong>alter drop column<\/strong>. Tada se ova kolona fizi\u010dki bri\u0161e iz svih delova.<\/p>\n<p><\/p>\n<p>Ali po\u010dev\u0161i od verzije 20.3, mehanizam alteracija je potpuno promenjen, i sada su delovi podataka uvek nepromenjivi. Oni se uop\u0161te ne menjaju \u2014 alteracije sada funkcioni\u0161u otprilike kao merge. Umesto da menjamo deo na licu mesta, kreiramo novi. U novom delu fajlovi koji se nisu promenili postaju hardlinkovi, i, ako smo izbrisali neku kolonu, ona jednostavno ne\u0107e biti prisutna u novom delu. Stari deo \u0107e se po defaultu izbrisati posle osam minuta, a ovde se mogu podesiti postavke o kojima je re\u010deno ranije. <\/p>\n<p><\/p>\n<p>Isto va\u017ei i za altere tipa mutacija. Kada radite <strong>alter delete<\/strong> ili <strong>alter update<\/strong>, on ne mijenja dio, ve\u0107 stvara novi. A potom uklanja stari.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>\u0160to u\u010diniti ako se struktura tablice promijenila?<\/h2>\n<p><\/p>\n<blockquote><p>Kako podi\u0107i backup koji je napravljen sa starom shemom? I drugo pitanje o slu\u010daju sa snapshotima i sredstvima datote\u010dnog sistema. Da li je ovde Btrfs umesto ZFS na Linux LVM odgovaraju\u0107i?<\/p><\/blockquote>\n<p>Ako radite <strong>attach partition<\/strong> Particije s drugom strukturom \u0107e vam re\u0107i da to nije dozvoljeno. Re\u0161enje je slede\u0107e. Prvo \u2014 kreirati privremenu tabelu tipa MergeTree sa starom strukturom, prika\u010diti podatke pomo\u0107u attach, napraviti upit alter. Zatim mo\u017eete ili kopirati ili premestiti te podatke i ponovo ih prika\u010diti, ili koristiti upit. <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Drugi pitanje je&nbsp;\u2014 mo\u017ee li se koristiti Btrfs. Za po\u010detak, ako imate LVM, dovoljno su LVM snimci, a datote\u010dni sustav mo\u017ee biti i ext4, to nije bitno. \u0160to se ti\u010de Btrfs, sve ovisi o va\u0161em iskustvu s njom. To je zrela datote\u010dna \u0441\u0438\u0441\u0442\u0435\u043c\u0430, ali postoje sumnje o tome kako \u0107e sve funkcionirati u praksi u konkretnom scenariju. Ne bih to preporu\u010dio ako nemate Btrfs u upotrebi.<\/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>Koje su sada najbolje prakse u reshrodingu podataka?<\/h2>\n<p><\/p>\n<p>Pitanje o pre\u0161ardiranju je slo\u017eeno i vi\u0161ezna\u010dno. Ovdje se mo\u017ee odmah odgovoriti na nekoliko na\u010dina. Mo\u017eete pristupiti s jedne strane i re\u0107i da u ClickHouseu nema ugra\u0111ene mogu\u0107nosti pre\u0161ardiranja. Ali bojim se da ovaj odgovor nikoga ne\u0107e zadovoljiti. Stoga se mo\u017ee pristupiti s druge strane i re\u0107i da ClickHouse ima mnogo na\u010dina za pre\u0161ardiranje podataka. <\/p>\n<p><\/p>\n<p>Ako ponestane prostora u klasteru ili se ne mo\u017ee nositi s optere\u0107enjem, dodajete nove servere. No, ovi serveri su prazni po defaultu, nemaju podataka, optere\u0107enja nema. Morate prebaciti podatke kako bi se ravnomjerno rasporedili po novom, pove\u0107anom klasteru.<\/p>\n<p><\/p>\n<p>Prvi na\u010din na koji se to mo\u017ee u\u010diniti je kopiranje dijela particija na nove servere pomo\u0107u upita. <strong>alter table fetch partition<\/strong>Na primjer, ako ste imali particije po mjesecima, uzimate prvi mjesec 2017. godine i kopirate na novi server, a zatim tre\u0107i mjesec kopirate na neki drugi novi server. I tako radite dok ne postane vi\u0161e-manje ravnomjerno.<\/p>\n<p><\/p>\n<p>Premje\u0161tanje se mo\u017ee provesti samo za one particije koje se ne mijenjaju prilikom pisanja. Za nove particije zapis \u0107e morati biti isklju\u010den, jer njihov premje\u0161taj nije atomski. Ina\u010de \u0107ete dobiti duplikate ili propu\u0161tene podatke. Ipak, ovaj na\u010din je prakti\u010dan i radi dovoljno u\u010dinkovito. Putem mre\u017ee se \u0161alju ve\u0107 pripremljene komprimirane particije, \u0161to zna\u010di da se podaci ne komprimiraju i ne kodiraju ponovo.<\/p>\n<p><\/p>\n<p>Ova metoda ima jedan nedostatak, a to ovisi o shemi shardiranja, koju ste postavili, kakav je va\u0161 klju\u010d shardiranja. U va\u0161em primjeru za slu\u010daj s metrike, klju\u010d shardiranja je hash od puta. Kada izvodite select u Distributed tablicu, on ide odmah na sve shardove klastera i preuzima podatke odatle. <\/p>\n<p><\/p>\n<p>To zna\u010di da vam zapravo nije va\u017eno koji su podaci na kojem shardu. Bitno je to da su podaci po jednom putu na jednom shardu, a koji to\u010dno, nije presudno. U ovom slu\u010daju, premje\u0161tanje gotovih particija izvrsno odgovara, jer prilikom select zahtjeva tako\u0111er \u2013 bilo prije ili nakon premje\u0161tanja, shema podataka nije bitna \u2013 dobit \u0107ete potpune podatke.<\/p>\n<p><\/p>\n<p>No, postoje slu\u010dajevi koji su slo\u017eeniji. Ako na razini logike aplikacije planirate posebnu shemu shardiranja, da je ovaj klijent smje\u0161ten na odre\u0111enom shardu, i da zahtjev mo\u017ee biti odmah poslan tamo, a ne u Distributed tablicu. Ili koristite dovoljno novu verziju ClickHouse-a i uklju\u010dili ste postavku <strong>optimize skip unused shards<\/strong>. U tom slu\u010daju prilikom select zahtjeva izraz u sekciji where \u0107e se analizirati, i bit \u0107e izra\u010dunato na koje shardove je potrebno i\u0107i prema shemi shardiranja. To funkcionira pod uvjetom da su podaci raspore\u0111eni prema toj shemi shardiranja. Ako ste ih ru\u010dno premjestili, podudarnost se mo\u017ee promijeniti.<\/p>\n<p><\/p>\n<p>Dakle, ovo je prva metoda. \u010cekam va\u0161 odgovor, da li vam odgovara ova metoda, ili idemo dalje.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobajev, vode\u0107i sistemski administratori u Avitu<\/strong>: Aleksej, na\u010din koji ste spomenuli nije ba\u0161 najbolje odgovara kada je potrebno rasporediti optere\u0107enje, uklju\u010duju\u0107i i \u010ditanje. Mo\u017eemo uzeti mjese\u010dnu particiju i prethodni mjesec premjestiti na drugu nodu, ali kada stigne zahtjev za tim podacima, optere\u0107ivati \u0107emo samo nju. A voljeli bismo optere\u0107ivati cijeli klaster, jer u protivnom, neko vrijeme \u0107e sav teret na \u010ditanje obra\u0111ivati samo dva shard-a.<\/p>\n<p><\/p>\n<p><strong>Aleksej Milovidov:<\/strong> Odgovor ovdje je \u010dudan \u2013 da, lo\u0161e je, ali mo\u017ee pro\u0107i. Objasnit \u0107u kako to\u010dno. Trebalo bi pogledati scenarij optere\u0107enja koji ide za va\u0161im podacima. Ako su to podaci o pra\u0107enju, gotovo sigurno se mo\u017ee re\u0107i da ve\u0107ina zahtjeva ide za svje\u017eim podacima. <\/p>\n<p><\/p>\n<p>Postavili ste nove poslu\u017eitelje, premjestili stare particije, ali ste tako\u0111er promijenili na\u010din na koji se bilje\u017ee svje\u017ei podaci. Svje\u017ei podaci \u0107e se raspr\u0161iti po cijelom klasteru. Tako \u0107e, ve\u0107 nakon pet minuta, zahtjevi za posljednjih pet minuta ravnomjerno optere\u0107ivati klaster, a nakon dana, zahtjevi za 24 sata \u0107e ravnomjerno optere\u0107ivati klaster. Na\u017ealost, zahtjevi za prethodni mjesec \u0107e i\u0107i samo na dio poslu\u017eitelja klastera.<\/p>\n<p><\/p>\n<p>No, \u010desto ne\u0107ete imati zahtjeve upravo za velja\u010du 2019. godine. Vjerojatno \u0107e, ako zahtjevi idu u 2019. godinu, biti za cijelu 2019. godinu \u2014 za veliki vremenski interval, a ne za neki mali raspon. Takvi zahtjevi tako\u0111er mogu ravnomjerno opteretiti klaster. Ali u cjelini, va\u0161a opaska je potpuno to\u010dna, da je to takvo ad hoc rje\u0161enje koje ne raspore\u0111uje podatke potpuno ravnomjerno.<\/p>\n<p><\/p>\n<p>Imam jo\u0161 nekoliko to\u010daka za odgovor na pitanje. Jedna od njih se odnosi na to kako ispravno napraviti shemu shardinga tako da bude manje bolna prilikom resharda. To nije uvijek mogu\u0107e.<\/p>\n<p><\/p>\n<p>Na primjer, imate podatke o nadzoru. Podaci o nadzoru rastu iz tri razloga. Prvi \u2014 akumulacija povijesnih podataka. Drugi \u2014 rast prometa. I tre\u0107i \u2014 pove\u0107anje broja stavki koje podlije\u017eu nadzoru. Pojavljuju se nove mikroservisi i metrike koje treba pohranjivati. <\/p>\n<p><\/p>\n<p>Mogu\u0107e je da je najve\u0107i rast povezan upravo s tre\u0107im razlogom \u2014 to je pove\u0107ano kori\u0161tenje nadzora. U tom slu\u010daju, vrijedi obratiti pozornost na karakter optere\u0107enja, koja su glavna pitanja za select. Glavni zahtjevi za select, vjerojatno \u0107e i\u0107i prema nekim podskupinama metrika.<\/p>\n<p><\/p>\n<p>Na primjer, kori\u0161tenje CPU-a na nekim poslu\u017eiteljima od strane nekog servisa. Ispada da postoji odre\u0111eni podskup klju\u010deva putem kojih dobivate te podatke. A sam zahtjev za tim podacima, vjerojatno je dovoljno jednostavan i izvr\u0161ava se u desetinama milisekundi. Koristi se za servise nadzora, za nadzorne plo\u010de. Nadam se da to ispravno razumijem.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Stvar je u tome \u0161to vrlo \u010desto apeliramo na povijesne podatke, jer u stvarnom vremenu uspore\u0111ujemo trenutnu situaciju s povijesnom. Za nas je va\u017eno imati brz pristup velikom volumenu podataka, a ClickHouse se s tim odli\u010dno nosi.<\/p>\n<p><\/p>\n<p>Apsolutno ste u pravu, ve\u0107ina zahtjeva za \u010ditanjem imamo tijekom posljednjeg dana, kao i svaki sustav za pra\u0107enje. No pritom je i optere\u0107enje na povijesne podatke tako\u0111er prili\u010dno veliko. Uglavnom dolazi iz sustava za upozoravanje, koji svake tri desetine sekunde \u0161alje ClickHouseu: 'Daj mi podatke za posljednjih \u0161est tjedana. A sada mi napravi neku pomi\u010dnu srednju vrijednost od njih, i usporedimo trenutnu vrijednost s povijesnom.' <\/p>\n<p><\/p>\n<p>\u017delio bih re\u0107i da imamo jo\u0161 jedan mali tablicu za takve vrlo svje\u017ee zahtjeve, u kojoj \u010duvamo samo dva dana podataka, a glavni zahtjevi idu u nju. U veliku shardiranu tablicu \u0161aljemo samo velike povijesne zahtjeve.<\/p>\n<p><\/p>\n<p><strong>Aleksej Milovidov:<\/strong> Na\u017ealost, za va\u0161 scenarij se pokazuje slabo primjenjivo, ali \u0107u opisati dva lo\u0161a i slo\u017eena sustava shardiranja koja ne treba koristiti, ali se koriste u servisu mojih prijatelja. <\/p>\n<p><\/p>\n<p>Postoji glavni klaster s doga\u0111ajima 'Yandex.Metrike'. Doga\u0111aji \u2014 to su pregledi stranica, klikovi i prijelazi. Ve\u0107ina zahtjeva ide za odre\u0111enu web-stranicu. Otvorite servis 'Yandex.Metrika', imate stranicu \u2014 avito.ru, ulazite u izvje\u0161taj, i ide zahtjev za va\u0161u stranicu.<\/p>\n<p><\/p>\n<p>Ali postoje i drugi zahtjevi \u2014 analiti\u010dki i globalni, koje provode unutarnji analiti\u010dari. Za svaki slu\u010daj, napominjem da unutarnji analiti\u010dari upu\u0107uju zahtjeve samo za 'Yandexove' servise. Ipak, \u010dak i 'Yandexovi' servisi \u010dine zna\u010dajan postotak svih podataka. To su zahtjevi ne za konkretne broja\u010de, nego za \u0161iru filtraciju.<\/p>\n<p><\/p>\n<p>Kako organizirati podatke na na\u010din da i jedan broja\u010d dobro funkcionira i globalni zahtjevi tako\u0111er? Slo\u017eenost je tako\u0111er u tome \u0161to je broj zahtjeva u ClickHouse klasteru 'Metrike' \u2014 nekoliko tisu\u0107a u sekundi. Pritom, nelako izvedivi zahtjevi, na primjer, nekoliko tisu\u0107a u sekundi jedan server ClickHouse ne mo\u017ee podnijeti.<\/p>\n<p><\/p>\n<p>Veli\u010dina klastera&nbsp;\u2014 \u0161eststo i ne\u0161to poslu\u017eitelja. Ako jednostavno stavimo razdistributed tablicu na&nbsp;ovaj klaster i \u0161aljemo nekoliko tisu\u0107a upita, situacija \u0107e biti jo\u0161 gora nego slati ih na&nbsp;jedan poslu\u017eitelj. S&nbsp;druge strane, opcija gdje su podaci ravnomjerno raspr\u0161eni, a mi \u0161aljemo upite sa&nbsp;svi poslu\u017eitelja, odmah otpada.<\/p>\n<p><\/p>\n<p>Postoji posve suprotna opcija. Zamislite da \u0107emo podatke shardirati po&nbsp;web-lokacijama, a upit za&nbsp;jednu web-lokaciju i\u0107i \u0107e na&nbsp;jedan shard. Sada klaster mo\u017ee podnijeti deset tisu\u0107a upita u&nbsp;sekundi, ali na&nbsp;jednom shardu neki jedan upit radit \u0107e presporo. On vi\u0161e ne\u0107e mo\u0107i skalirati po&nbsp;propusnosti. Pogotovo ako je to stranica avito.ru. Ne\u0107u otkriti tajnu ako ka\u017eem da je Avito&nbsp;\u2014 jedna od&nbsp;najposje\u0107enijih stranica na&nbsp;ruskom internetu. Obra\u0111ivati je na&nbsp;jednom shardu bilo bi suludo.<\/p>\n<p><\/p>\n<p>Stoga je shema shardiranja osmi\u0161ljena na&nbsp;mudriji na\u010din. Cijeli klaster je podijeljen na&nbsp;odre\u0111eni broj manjih klastera, koje nazivamo slojevima. Unutar svakog klastera ima od&nbsp;deset do nekoliko desetaka shardova. A ukupno takvih klastera je trideset devet. <\/p>\n<p><\/p>\n<p>Kako se sve to skalira? Broj klastera se ne mijenja&nbsp;\u2014 ostalo je trideset devet kao prije nekoliko godina. Ali unutar svakog od&nbsp;njih postupno pove\u0107avamo broj shardova s&nbsp;rastom podataka. A shema shardiranja u&nbsp;ukupnom je takva&nbsp;\u2014 okidanje ovih klastera ide po&nbsp;web-lokacijama, a da bismo razumjeli koja web-lokacija je na&nbsp;kojem klasteru, koristi se posebna metabaza u&nbsp;MySQL-u. Jedna web-lokacija&nbsp;\u2014 na&nbsp;jednom klasteru. A unutar njega shardiranje ide po&nbsp;identifikatorima posjetitelja.<\/p>\n<p><\/p>\n<p>Prilikom zapisivanja dijelimo ih prema ostatku od dijeljenja identifikatora posjetitelja. No prilikom dodavanja novog shard-a shema sharding-a se mijenja, nastavljamo dijeliti, ali prema ostatku od dijeljenja s drugim brojem. To zna\u010di da jedan posjetitelj mo\u017ee biti smje\u0161ten na nekoliko servera, i na to se ne mo\u017ee ra\u010dunati. Ovo je u\u010dinjeno isklju\u010divo kako bi se podaci bolje komprimirali. A prilikom upita idemo u Distributed tablicu, koja gleda na klaster i obra\u0107a se desecima servera. Tako izgleda ova blesava shema.<\/p>\n<p><\/p>\n<p>No moja pri\u010da ne\u0107e biti potpuna ako ne ka\u017eem da smo od ove sheme odustali. U novoj shemi sve smo promijenili i sve podatke kopirali uz pomo\u0107 clickhouse-copier.<\/p>\n<p><\/p>\n<p>U novoj shemi svi sajtovi dijele se u dvije kategorije \u2014 velike i male. Ne znam kako je tamo odabran prag, ali rezultat je takav da se veliki sajtovi zapisuje u jedan klaster, gdje je 120 shard-ova s tri replike u svakom \u2014 dakle 360 servera. A shema shard-inga je takva da svaki upit ide odmah na sve shard-ove. Ako sada u 'Yandex.Metri\u010dkoj' otvorite bilo koju stranicu izvje\u0161taja za avito.ru, upit \u0107e oti\u0107i na 120 servera. Velikih sajtova u ruskom internetu ima malo. I upita ispadne ne tisu\u0107u u sekundi, nego \u010dak manje od stotinu. Sve to mirno obra\u0111uje Distributed tablica, koju svaki od njih obra\u0111uje 120 servera.<\/p>\n<p><\/p>\n<p>A drugi klaster \u2014 za male sajtove. Ovdje je shema shard-inga prema identifikatoru sajta, i svaki upit ide to\u010dno na jedan shard.<\/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>U ClickHouse postoji alat clickhouse-copier. Mo\u017eete li o tome re\u0107i ne\u0161to?<\/h2>\n<p><\/p>\n<p>Odmah \u0107u re\u0107i da je ovo rje\u0161enje glomaznije i ne\u0161to manje u\u010dinkovito. Prednost je u tome \u0161to potpuno raspore\u0111uje podatke prema shemi koju navedete. No nedostatak alata je u tome \u0161to ne provodi resharding. Kopira podatke iz jedne sheme klastera u drugu shemu klastera.<\/p>\n<p><\/p>\n<p>To zna\u010di da za njen rad morate imati dva klastera. Mogu biti smje\u0161teni na istim serverima, ali, unato\u010d tome, podaci se ne\u0107e premje\u0161tati inkrementalno, nego \u0107e biti kopirani. <\/p>\n<p><\/p>\n<p>Na primjer, bilo je \u010detiri servera, a sada ih je osam. Na svim serverima kreirate novu Distributed tabelu, nove lokalne tabele i pokre\u0107ete clickhouse-copier, navode\u0107i u njemu \u0161emu rada, da treba da \u010dita odatle, prihvati novu \u0161emu deljenja i prebacuje podatke tamo. A potrebna vam je na starim serverima mesto u petnaest puta ve\u0107em obimu nego \u0161to ga sada imate, jer stari podaci moraju ostati na njima, a iznad njih \u0107e do\u0107i pola od tih starih podataka. Ako ste unapred razmislili o tome da je potrebna ponovna alokacija podataka i imate prostora, tada je ovakav na\u010din dobar.<\/p>\n<p><\/p>\n<p>Kako je unutra organizovan clickhouse-copier? On deli sav rad na set zadataka za obradu jedne particije jedne tabele na jednom shardu. Svi ovi zadaci mogu se izvoditi paralelno, a clickhouse-copier mo\u017ee biti pokrenut na razli\u010ditim ma\u0161inama u nekoliko instanci, ali ono \u0161to radi za jednu particiju je ni\u0161ta drugo nego insert select. Podaci se \u010ditaju, dekomprimiraju, ponovo raspodeljuju, zatim se ponovo kompresuju, zapisuju nekuda, i ponovo sortiraju. Ovo je te\u017ee re\u0161enje.<\/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>Imali ste pilot-projekt koji se zvao reshroding. \u0160to se s njim dogodilo?<\/h2>\n<p><\/p>\n<blockquote><p>Imali ste jo\u0161 2017. godine pilotski projekat koji se zvao re-sharding. \u010cak postoji opcija u ClickHouse. Razumem da to nije uspelo. Mo\u017eete li mi re\u0107i za\u0161to je to tako? \u010cini se da je to veoma aktuelno.<\/p><\/blockquote>\n<p>Celi problem je u tome \u0161to, kada je potrebna ponovna alokacija podataka, zahteva se veoma slo\u017eena sinhronizacija da bi se to uradilo atomarno. Kada smo po\u010deli da gledamo kako je ta sinhronizacija organizovana, postalo je jasno da postoje fundamentalni problemi. I ti fundamentalni problemi nisu samo teoretski, ve\u0107 su se odmah pokazali u praksi u vidu onoga \u0161to se mo\u017ee objasniti veoma jednostavno \u2014 ni\u0161ta ne funkcioni\u0161e.<\/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>Mo\u017ee li se sve dijelove podataka spojiti zajedno prije premje\u0161tanja na spore diskove?<\/h2>\n<p><\/p>\n<blockquote><p>Pitanje o TTL sa opcijom premestiti na spori disk u kontekstu spajanja. Postoji li na\u010din, osim preko cron-a, da se spoje svi delovi u jedan pre nego \u0161to se premeste na spore diskove?<\/p><\/blockquote>\n<p>Odgovor na pitanje, da li se mo\u017ee automatski spojiti svi delovi u jedan pre nego \u0161to ih premestite \u2014 ne. \u010cini mi se da u tome nema potrebe. Ne mora se spu\u0161tati svi delovi u jedan, ve\u0107 se mo\u017ee ra\u010dunati na to da \u0107e se automatski prenositi na spore diskove. <\/p>\n<p><\/p>\n<p>Imamo dva kriterija pravila za prijenos. Prvi \u2014 prema popunjenosti. Ako na trenutnoj razini pohrane ima manje od odre\u0111enog postotka slobodnog prostora, biramo jedan segment i premje\u0161tamo ga na sporiju pohranu. To\u010dnije, ne sporiju, nego sljede\u0107u \u2014 kako ste to podesili.<\/p>\n<p><\/p>\n<p>Drugi kriterij \u2014 prema veli\u010dini. Odnosi se na premje\u0161taj velikih dijelova. Mo\u017eete prilagoditi prag slobodnog prostora na brzom disku, a podaci \u0107e se automatski premje\u0161tati.<\/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>Kako se mo\u017ee pre\u0107i na nove verzije ClickHouse ako ne postoji mogu\u0107nost prethodnog provjeravanja kompatibilnosti?<\/h2>\n<p><\/p>\n<blockquote><p>Ova tema se redovito raspravlja <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">u Telegram chatu ClickHouse<\/a><\/noindex> uzimaju\u0107i u obzir razli\u010dite verzije, ipak. Koliko je sigurno nadograditi se s verzije 19.11 na 19.16 i, primjerice, s 19.16 na 20.3. Kako se najbolje preseliti na nove verzije, a da nije mogu\u0107e unaprijed provjeriti kompatibilnost u sandboxu?<\/p><\/blockquote>\n<p>Evo nekoliko \"zlatnih\" pravila. Prvo \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">\u010ditajte changelog<\/a><\/noindex>. Velika je, ali ima odvojene stavke o unatrag nekompatibilnim promjenama. Ne treba se prema tim stavkama odnositi kao prema crvenoj zastavi. Obi\u010dno su to sitne nekompatibilnosti koje su povezane s odre\u0111enom rubnom funkcionalno\u0161\u0107u, koja vjerojatno nije u uporabi.<\/p>\n<p><\/p>\n<p>Drugo \u2014 ako ne postoji mogu\u0107nost provjere kompatibilnosti u sandboxu, a \u017eelite se odmah nadograditi u produkciji, preporuka je \u2014 nemojte to raditi. Prvo stvorite sandbox i provjerite. Ako nemate testno okru\u017eenje, najvjerojatnije niste vrlo velika tvrtka, pa se mo\u017ee kopirati dio podataka na prijenosno ra\u010dunalo i uvjeriti se da sve ispravno radi. Mo\u017eete \u010dak podi\u0107i nekoliko replika lokalno na svom ra\u010dunalu. Ili mo\u017eete negdje u blizini postaviti novu verziju i prenijeti dio podataka \u2014 dakle, izraditi improvizirano testno okru\u017eenje. <\/p>\n<p><\/p>\n<p>Jo\u0161 jedno pravilo \u2014 nemojte se nadogra\u0111ivati tijekom tjedna nakon izlaska verzije zbog pronala\u017eenja gre\u0161aka u produkciji i naknadnih brzih ispravaka. Poglejmo numeraciju verzija ClickHouse-a kako bismo se bolje sna\u0161li. <\/p>\n<p><\/p>\n<p>Postoji verzija 20.3.4. Broj 20 ozna\u010dava godinu izdavanja \u2014 2020. S obzirom na to \u0161to je unutra, to nema nikakvog zna\u010denja, tako da se na to ne\u0107emo obazirati. Dalje \u2014 20.3. Drugi broj \u2014 u ovom slu\u010daju 3 \u2014 pove\u0107avamo svaki put kada izdajemo verziju s nekom novom funkcionalno\u0161\u0107u. Ako \u017eelimo dodati neku mogu\u0107nost u ClickHouse, moramo pove\u0107ati taj broj. Zna\u010di, u verziji 20.4 ClickHouse \u0107e raditi jo\u0161 bolje. Tre\u0107i broj \u2014 20.3.4. Ovdje 4 ozna\u010dava broj patch verzija u kojima nismo dodali nove mogu\u0107nosti, ali smo ispravili neke gre\u0161ke. I 4 zna\u010di da smo to u\u010dinili \u010detiri puta.<\/p>\n<p><\/p>\n<p>Ne treba misliti da je to ne\u0161to stra\u0161no. Obi\u010dno korisnik mo\u017ee instalirati najnoviju verziju, i ona \u0107e raditi bez ikakvih problema s dostupno\u0161\u0107u tokom godine. No, zamislite da neka funkcija za obradu bitmapa, koju su dodali na\u0161i kineski kolege, sru\u0161i server kada se proslijede pogre\u0161ni argumenti. Moramo to ispraviti. Izdavat \u0107emo novu patch verziju, a ClickHouse \u0107e postati stabilniji.<\/p>\n<p><\/p>\n<p>Ako vam ClickHouse radi u produkciji, i izlazi nova verzija ClickHouse-a s dodatnim funkcijama \u2014 na primjer, 20.4.1 \u2014 nemojte po\u017euriti s njenim stavljanjem u produkciju prvog dana. Za\u0161to vam to zapravo treba? Ako jo\u0161 ne koristite ClickHouse, mo\u017eete ga instalirati, i vjerojatno \u0107e sve biti u redu. No, ako ClickHouse ve\u0107 stabilno radi, pratite patch-eve i a\u017euriranja \u2014 koje probleme ispravljamo.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> \u017delim dodati ne\u0161to o testnim okru\u017eenjima. Svi se vrlo boje testnih okru\u017eenja i nekako smatraju da, ako imate vrlo veliki klaster ClickHouse-a, da i testno okru\u017eenje mora biti jednako veliko ili barem deset puta manje. To uop\u0107e nije tako.<\/p>\n<p><\/p>\n<p>Mogu re\u0107i na svom primjeru. Imam projekt u kojem je ClickHouse. Na\u0161e testno okru\u017eenje upravo za njega \u2014 to je mala virtualka u Hetzner-u za dvadeset eura, gdje je apsolutno sve postavljeno. Da bismo to u\u010dinili, imamo potpunu automatizaciju u Ansible-u, tako da u na\u010delu nema razlike kamo se prebaciti \u2014 na fizi\u010dke servere ili se jednostavno postaviti u virtualke.<\/p>\n<p><\/p>\n<p>\u0160to se mo\u017ee u\u010diniti? Bilo bi dobro u dokumentaciji ClickHouse napraviti primjer kako postaviti mali klaster kod sebe \u2014 u Dockeru, u LXC, mo\u017eda stvoriti Ansible playbook, jer razli\u010diti ljudi imaju razli\u010dite na\u010dine implementacije. To bi znatno olak\u0161alo. Kada uzimate i za pet minuta postavljate klaster, puno je lak\u0161e poku\u0161ati razumjeti stvari. Tako je daleko prikladnije, jer gurnuti u produkciju verziju koju niste testirali \u2014 to je put u neuspjeh. Ponekad to radi, a ponekad ne. Tako da se oslanjati na uspjeh \u2014 nije dobra ideja.<\/p>\n<p><\/p>\n<p><strong>Maksim Kotiakov, senior backend in\u017eenjer u Avitu:<\/strong> Malo \u0107u dopuniti o testnim okru\u017eenjima iz serije problema velikih kompanija. Imamo potpuno opremljen prihvatni klaster ClickHouse, u smislu podataka i postavki to\u010dna kopija onoga \u0161to imamo u produkciji. Ovaj klaster je postavljen u prili\u010dno slaba\u0161nim kontejnerima s minimalnim resursima. Pisamo odre\u0111eni postotak od produkcijskih podataka, sre\u0107om imamo mogu\u0107nost replikacije u Kafki. Tamo je sve sinkronizirano i skalirano \u2014 i prema kapacitetima, i prema protoku, i, teoretski, pod ostalim jednakim uvjetima, trebali bi se po metrima pona\u0161ati kao produkcija. Sve potencijalno eksplozivno prvo ide na ovu platformu i nekoliko dana se ondje odlu\u010duje do spremnosti. No, naravno, to je skupo rje\u0161enje, te\u0161ko i sa zna\u010dajnim tro\u0161kovima odr\u017eavanja. <\/p>\n<p><\/p>\n<p><strong>Aleksej Milovidov:<\/strong> Ispri\u010dat \u0107u vam \u0161to predstavlja testno okru\u017eenje na\u0161ih prijatelja iz \u201eYandex.Metrica\u201d. Jedan klaster imao je 600 i ne\u0161to servera, drugi 360, a tu je jo\u0161 tre\u0107i i nekoliko klastera. Testno okru\u017eenje za jedan od njih \u2014 to su jednostavno dva \u0161arda s dvije replike u svakom. Za\u0161to dva \u0161arda? Da ne bi bio jedan. I replike tako\u0111er da postoje. Jednostavno minimalna koli\u010dina koja si mo\u017eete priu\u0161titi.<\/p>\n<p><\/p>\n<p>Ovo testno okru\u017eenje omogu\u0107uje provjeru funkcionalnosti upita i da li je ne\u0161to ozbiljno pokvareno. No, problemi \u010desto nastaju potpuno druga\u010dijeg karaktera, kada sve funkcionira, ali postoje neka manja odstupanja u optere\u0107enju.<\/p>\n<p><\/p>\n<p>Dati \u0107u primjer. Odlu\u010dili smo instalirati novu verziju ClickHouse-a. Ona je postavljena na&nbsp;testno okru\u017eenje, pro\u0161li su automatizirani testovi u&nbsp;samoj \u201eYandex.Metrici\u201d, koji uspore\u0111uju podatke na&nbsp;staroj verziji i na&nbsp;novoj, prolaze\u0107i cijeli proces. I naravno, zeleni testovi na\u0161eg CI-ja. Ina\u010de ne bismo ni ponudili ovu verziju.<\/p>\n<p><\/p>\n<p>Sve je savr\u0161eno. Po\u010dinjemo s&nbsp;proizvodnjom. Dolazi mi poruka da su optere\u0107enja na&nbsp;grafovima porasla nekoliko puta. Vra\u0107amo verziju. Gledam graf i vidim: optere\u0107enje se zaista pove\u0107alo nekoliko puta tijekom pu\u0161tanja, a zatim se smanjilo kada je verzija pu\u0161tena. Zatim smo po\u010deli vra\u0107ati verziju. I optere\u0107enje se tako\u0111er pove\u0107alo i ponovno palo. Tako da je zaklju\u010dak da se optere\u0107enje pove\u0107alo zbog pu\u0161tanja, ni\u0161ta neobi\u010dno.<\/p>\n<p><\/p>\n<p>Dalje je bilo te\u0161ko uvjeriti kolege da ipak instaliraju novu verziju. Ka\u017eem: \u201eSve je u redu, pustite. Dr\u017eite pal\u010deve, sve \u0107e raditi. Sada se optere\u0107enje pove\u0107alo na&nbsp;grafovima, ali sve je u redu. Dr\u017eite se.\u201d Uglavnom, tako smo u\u010dinili, i svi \u2014 verzija je pu\u0161tena u&nbsp;proizvodnju. No gotovo svaki put pri&nbsp;pu\u0161tanju javljaju se sli\u010dni problemi.<\/p>\n<p><\/p>\n<h2 id=\"anchorkill-queryanchorkill-query-dolzhen-ubivat-zaprosy-no-on-etogo-ne-delaet-pochemu\"><noindex><a rel=\"nofollow\" name=\"kill-query\"><\/a><\/noindex>Kill query bi trebao ubijati upite, ali to ne radi. Za\u0161to?<\/h2>\n<p><\/p>\n<blockquote><p>Do\u0161ao mi je korisnik, neki analiti\u010dar, i stvorio je odre\u0111eni upit koji je sru\u0161io moj ClickHouse klaster. Neko \u010dvor ili cijeli klaster \u2014 ovisno o tome u koju replicu ili shard je upit do\u0161ao. Vidim da su svi resursi po&nbsp;CPU-u na&nbsp;ovom serveru u&nbsp;crvenom, sve je crveno. I sam ClickHouse odgovara na&nbsp;upite. I pi\u0161em: \u201ePoka\u017ei mi, molim te, popis procesa, koji je upit izazvao ovu ludost.\u201d<\/p>\n<p>Prona\u0161ao sam taj upit i pi\u0161em mu kill. I vidim da se ni\u0161ta ne doga\u0111a. Moj server je u&nbsp;crvenom, ClickHouse i dalje daje neke komande, pokazuje da je server \u017eiv, i sve je super. Ali imam degradaciju u&nbsp;svim korisni\u010dkim upitima, po\u010dinje degradacija pri&nbsp;upisu u&nbsp;ClickHouse, a moj kill upit ne funkcionira. Za\u0161to? Mislio sam da kill upit treba ubijati upite, a to se ne doga\u0111a.<\/p><\/blockquote>\n<p>Sada \u0107e biti prili\u010dno \u010dudan odgovor. Radi se o tome da kill upit ne ubija upite. <\/p>\n<p><\/p>\n<p>Kill query postavlja mali indikator s nazivom \"\u017eelimo da se ovaj upit prekine\". Sam upit prilikom obrade svakog bloka provjerava taj indikator. Ako je postavljen, upit prestaje raditi. Ispostavlja se da niko ne ubija upit, on sam treba sve provjeriti i zaustaviti se. I to bi trebalo raditi u svim slu\u010dajevima kada se upit nalazi u stanju obrade podataka. Obradit \u0107e sljede\u0107i blok podataka, provjeriti indikator i stati.<\/p>\n<p><\/p>\n<p>To ne funkcionira u slu\u010dajevima kada je upit blokiran na nekoj operaciji. Istina, vjerojatno ovo nije va\u0161 slu\u010daj jer, prema va\u0161im rije\u010dima, koristi puno resursa servera. Mogu\u0107e je da to ne radi u slu\u010daju vanjske sortiranja i jo\u0161 nekih detalja. No, uglavnom to ne bi smjelo biti slu\u010daj, to je gre\u0161ka. I jedino \u0161to mogu preporu\u010diti je da a\u017eurirate ClickHouse.<\/p>\n<p><\/p>\n<h2 id=\"anchorreading-timeanchorkak-rasschitat-vremya-otveta-pri-chitayuschey-nagruzke\"><noindex><a rel=\"nofollow\" name=\"reading-time\"><\/a><\/noindex>Kako izra\u010dunati vrijeme odgovora pri \u010ditanoj optere\u0107enosti?<\/h2>\n<p><\/p>\n<blockquote><p>Postoji tabla u kojoj se pohranjuju agregati po item \u2013 razli\u010dite brojke. Broj redaka \u2013 otprilike stotinu milijuna. Mo\u017ee li se ra\u010dunati na predvidivo vrijeme odgovora ako se pusti 1K RPS po 1K itema? <\/p><\/blockquote>\n<p>Sude\u0107i prema kontekstu, rije\u010d je o \u010ditaju\u0107em optere\u0107enju, jer na upisivanje nema problema \u2013 mo\u017ee se umetnuti tisu\u0107u, sto tisu\u0107a, a ponekad i nekoliko milijuna redaka. <\/p>\n<p><\/p>\n<p>\u010citaju\u0107e upite ima raznih vrsta. U select 1 ClickHouse mo\u017ee obavljati oko desetaka tisu\u0107a upita u sekundi, tako da \u010dak i upiti po jednom klju\u010du ve\u0107 zahtijevaju odre\u0111ene resurse. I takvi to\u010dni upiti bit \u0107e slo\u017eeniji nego u nekim key-value bazama podataka, jer za svako \u010ditanje treba pro\u010ditati blok podataka po indeksom. Indeks kod nas ne adresira svaku stavku, ve\u0107 svaki raspon. Zna\u010di, treba pro\u010ditati cijeli raspon \u2013 to je 8192 reda po defaultu. I potrebno je dekomprimirati komprimirani blok podataka s 64 KB na 1 MB. Obi\u010dno takvi to\u010dni upiti traju od nekoliko milisekundi. Ali ovo je najjednostavnija varijanta.<\/p>\n<p><\/p>\n<p>Poku\u0161ajmo napraviti jednostavnu aritmetiku. Ako pomno\u017eimo nekoliko milisekundi s&nbsp;tisu\u0107om, dobit \u0107emo nekoliko sekundi. Kao da je nemogu\u0107e zadr\u017eati tisu\u0107u zahtjeva u&nbsp;sekundi, ali zapravo je to mogu\u0107e jer imamo nekoliko procesorskih jezgri. Tako da u na\u010delu 1000&nbsp;RPS ClickHouse ponekad mo\u017ee izdr\u017eati, ali na&nbsp;kratkim upitima, odnosno konkretnim upitima.<\/p>\n<p><\/p>\n<p>Ako trebate skalirati ClickHouse klaster po broju jednostavnih upita, preporu\u010dujem najjednostavnije rje\u0161enje \u2014 pove\u0107ati broj replikacija i slati upite na&nbsp;slu\u010dajnu replikaciju. Ako jedna replikacija zadr\u017ei petsto upita u&nbsp;sekundi, \u0161to je potpuno realno, tri&nbsp;replikacije \u0107e izdr\u017eati tisu\u0107u i pol.<\/p>\n<p><\/p>\n<p>Ponekad, naravno, mo\u017ee se i ClickHouse prilagoditi za maksimalni broj specifi\u010dnih \u010ditanja. \u0160to je potrebno za to? Prvo&nbsp;\u2014 smanjiti granularity indeksa. Pri tome, granularity ne bi trebala biti svedena na&nbsp;jedinu, nego treba izra\u010dunati tako da se broj zapisa u&nbsp;indeksu kretati u nekoliko milijuna ili desetke milijuna po&nbsp;serveru. Ako u&nbsp;tablici postoji stotinu milijuna redaka, granularity mo\u017ee biti postavljena na 64.<\/p>\n<p><\/p>\n<p>Mo\u017eete smanjiti veli\u010dinu komprimiranog bloka. Za to postoje postavke <strong>min compress block size<\/strong>, <strong>max compress block size<\/strong>. Njih mo\u017eete smanjiti, ponovno prenijeti podatke i tada \u0107e to\u010dni upiti biti br\u017ei. No i dalje, ClickHouse nije key-value baza podataka. Veliki broj malih upita je antipattern optere\u0107enja.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Dajem savjet u slu\u010daju da postoje uobi\u010dajeni encounteri. To je prili\u010dno standardna situacija kada ClickHouse pohranjuje neki broja\u010d. Imam korisnika, on je iz odre\u0111ene zemlje, postoji jo\u0161 jedno tre\u0107e polje i potrebno je inkrementalno ne\u0161to pove\u0107avati. Uzimate MySQL, radite jedinstveni klju\u010d \u2014 u MySQL-u je to duplicate key, a u PostgreSQL-u conflict \u2014 i dodajete s plusom. To \u0107e raditi daleko bolje. <\/p>\n<p><\/p>\n<p>Kada imate malo podataka, zapravo nema smisla koristiti ClickHouse. Postoje uobi\u010dajene baze podataka, i one se s time dobro nose. <\/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>\u0160to podesiti u ClickHouseu kako bi vi\u0161e podataka bilo u cacheu?<\/h2>\n<p><\/p>\n<blockquote><p>Zamislimo situaciju \u2014 na serverima je 256&nbsp;GB RAM-a, u&nbsp;svakodnevnoj rutini ClickHouse uzima otprilike 60\u201480&nbsp;GB, a na vrhuncu \u2014 do 130. \u0160to se mo\u017ee uklju\u010diti i podesiti kako bi vi\u0161e podataka bilo u cacheu i, sukladno tome, bilo manje odlazaka na disk?<\/p><\/blockquote>\n<p>Obi\u010dno, page cache operativnog sustava dobro se nosi s ovom zada\u0107om. Kada jednostavno otvorite top, pogledajte postoji li cached ili free \u2014 tako\u0111er je navedeno koliko je toga spremljeno u cache. Mo\u017ee se primijetiti da je cijela slobodna memorija iskori\u0161tena za cache. Pri \u010ditanju, te \u0107e se podatke \u010ditati ne s diska, ve\u0107 iz RAM-a. Mogu re\u0107i da se cache u\u010dinkovito koristi, jer se ke\u0161iraju komprimirani podaci.<\/p>\n<p><\/p>\n<p>Ipak, ako \u017eelite jo\u0161 vi\u0161e ubrzati neke jednostavne upite, postoji mogu\u0107nost uklju\u010divanja cachea u ClickHouse-u s dekomprimiranim podacima. To se naziva <strong>uncompressed cache<\/strong>. U konfiguracijskoj datoteci config.xml postavite veli\u010dinu uncompressed cache na \u017eeljenu vrijednost \u2014 preporu\u010dujem ne vi\u0161e od polovice slobodnog RAM-a, jer \u0107e ostatak oti\u0107i za page cache. <\/p>\n<p><\/p>\n<p>Osim toga, postoje dvije postavke na razini upita. Prva postavka \u2014 <strong>use uncompressed cache<\/strong> \u2014 uklju\u010duje njegovo kori\u0161tenje. Preporu\u010duje se uklju\u010diti za sve upite, osim za te\u0161ke, koji mogu pro\u010ditati sve podatke i isprazniti ovaj cache. Druga postavka je ne\u0161to poput maksimalnog broja redaka za kori\u0161tenje cachea. Ona automatski ograni\u010dava velike upite kako bi pro\u0161li mimo cachea.<\/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>Kako se mo\u017ee podesiti storage_configuration za pohranu u radnoj memoriji?<\/h2>\n<p><\/p>\n<blockquote><p>U novoj dokumentaciji ClickHouse-a pro\u010ditao sam odjeljak koji se odnosi <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">s data storage<\/a><\/noindex>. U opisu je primjer s fast SSD. <\/p>\n<p>Zanimljivo je kako se mo\u017ee konfigurirati isto s volume hot memory. Imam jo\u0161 jedno pitanje. Kako select radi s takvom organizacijom podataka? Ho\u0107e li \u010ditati cijeli skup ili samo ono \u0161to je na disku i jesu li ti podaci komprimirani u memoriji? Kako radi prewhere sekcija na takvoj organizaciji podataka?<\/p><\/blockquote>\n<p>Ova postavka utje\u010de na skladi\u0161tenje dijelova podataka, a njihov format se nikako ne mijenja.<br \/>\nPogledajmo detaljnije. <\/p>\n<p><\/p>\n<p>Mo\u017ee se konfigurirati skladi\u0161tenje podataka u RAM-u. Sve \u0161to se konfigurira za disk \u2014 to je njegov put. Stvarate tmpfs particiju koja je montirana na neki put u datote\u010dnom sustavu. Taj put navodite kao put za skladi\u0161tenje podataka za najsvje\u017eiju particiju, a dijelovi podataka po\u010dinju stizati i zapisivati se, sve je u redu. <\/p>\n<p><\/p>\n<p>Ali ne preporu\u010dujem to raditi zbog niske pouzdanosti, iako, ako imate barem tri replike u razli\u010ditim podatkovnim centrima, mo\u017ee pro\u0107i. Ako se dogodi ne\u0161to, podaci \u0107e biti obnovljeni. Zamislite da se server iznenada isklju\u010dio i ponovo uklju\u010dio. Odjeljak se ponovno montirao, ali tamo je prazno. ClickHouse server pri pokretanju vidi da su mu ti dijelovi odsutni, iako prema metapodacima ZooKeeper-a oni bi trebali biti prisutni. Prou\u010dava na kojim replikama ih ima, tra\u017ei ih i preuzima. Na taj na\u010din \u0107e podaci biti obnovljeni. <\/p>\n<p><\/p>\n<p>U tom smislu, pohrana podataka u radnoj memoriji bitno se ne razlikuje od njihove pohrane na disku, jer pri pisanju podataka na disk oni prvo odlaze u page cache i fizi\u010dki se zapisivanje odga\u0111a. To ovisi o na\u010dinu monta\u017ee datote\u010dnog sustava. No, u svakom slu\u010daju, re\u0107i \u0107u da ClickHouse ne radi fsync pri insertu.<\/p>\n<p><\/p>\n<p>Pri tome se podaci u radnoj memoriji pohranjuju u istom formatu kao i na disku. Upit select tako\u0111er odabire dijelove koje treba \u010ditati, bira potrebne raspone podataka u dijelovima i \u010dita ih. I prewhere funkcionira potpuno isto, bez obzira na to jesu li podaci bili u radnoj memoriji ili na disku.<\/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>Do koje je koli\u010dine jedinstvenih vrijednosti Low Cardinality u\u010dinkovit?<\/h2>\n<p><\/p>\n<p>Low Cardinality je genijalno osmi\u0161ljen. On sastavlja rje\u010dnike podataka, ali su oni lokalni. Prvo, rje\u010dnici su specifi\u010dni za svaki dio, a drugo, \u010dak i unutar jednog dijela mogu biti razli\u010diti za svaki raspon. Kada broj jedinstvenih vrijednosti dostigne prag \u2014 mislim da je to jedan milijun \u2014 rje\u010dnik se jednostavno odla\u017ee i stvara se novi.<\/p>\n<p><\/p>\n<p>Odgovor u cjelini: za svaki lokalni raspon \u2014 recimo, za svaki dan \u2014 negdje do milijun jedinstvenih vrijednosti Low Cardinality je u\u010dinkovit. Nakon toga \u0107e jednostavno do\u0107i do fallback-a, pri \u010demu \u0107e se koristiti mnogo razli\u010ditih rje\u010dnika umjesto jednog. Radit \u0107e otprilike kao obi\u010dni stupac tipa string, mo\u017eda malo manje u\u010dinkovito, ali zna\u010dajno pogor\u0161anje performansi se ne\u0107e dogoditi. <\/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>Koje su najbolje prakse za pretra\u017eivanje po cjelovitom tekstu na tablici s pet milijardi redaka?<\/h2>\n<p><\/p>\n<p>Postoje razli\u010diti mogu\u0107i odgovori. Prvi je re\u0107i da ClickHouse nije sustav za pretra\u017eivanje punog teksta. Za to postoji posebni sustavi kao \u0161to su, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> i <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Ipak, sve \u010de\u0161\u0107e sre\u0107em ljude koji govore da prelaze s Elasticsearch-a na ClickHouse.<\/p>\n<p><\/p>\n<p>Za\u0161to se to doga\u0111a? Obja\u0161njavaju to time da Elasticsearch prestaje zadovoljavati optere\u0107enje na nekim volumenima, po\u010dev\u0161i od izrade indeksa. Indeksi postaju preveliki, a ako se samo prebace podaci u ClickHouse, oni \u0107e se po volumenu pohraniti nekoliko puta u\u010dinkovitije. Osim toga, pretra\u017eiva\u010dki upiti \u010desto nisu bili takvi da je potrebno prona\u0107i neku frazu u svim podacima s obzirom na morfologiju, ve\u0107 posve druga\u010diji. Na primjer, prona\u0107i u logovima za posljednjih nekoliko sati neku podsekvencu bajtova.<\/p>\n<p><\/p>\n<p>U ovom slu\u010daju u ClickHouseu kreirate indeks, \u010dije \u0107e prvo polje biti datum s vremenom. Najve\u0107e odrezivanje podataka bit \u0107e upravo po rasponu datuma. Unutar odabranog raspona datuma obi\u010dno se mo\u017ee provesti pretra\u017eivanje punog teksta \u010dak i brute force metodom uz pomo\u0107 like. Operator like u ClickHouseu je naju\u010dinkovitiji operator koji mo\u017eete prona\u0107i. Ako prona\u0111ete bolji \u2014 javite mi. <\/p>\n<p><\/p>\n<p>Me\u0111utim, like ipak predstavlja punu pretragu. Puna pretraga mo\u017ee biti spora ne samo po CPU-u, ve\u0107 i po disku. Ako slu\u010dajno imate jedan terabajt podataka dnevno i tra\u017eite neku rije\u010d tijekom jednog dana, morat \u0107ete skenirati taj terabajt. A on \u0107e sigurno biti na obi\u010dnim tvrdom diskovima, i na kraju \u0107e biti optere\u0107eni tako da ne\u0107ete mo\u0107i pristupiti tom serveru putem SSH-a.<\/p>\n<p><\/p>\n<p>U tom slu\u010daju spreman sam ponuditi jo\u0161 jedan mali trik. On je iz eksperimentalne sfere \u2014 mo\u017eda \u0107e funkcionirati, a mo\u017eda i ne\u0107e. U ClickHouseu postoje indeksi punog teksta u obliku trigramnih Bloom filtara. Na\u0161i kolege iz tvrtke Arenadata ve\u0107 su testirali te indekse i \u010desto djeluju to\u010dno onako kako je zami\u0161ljeno.<\/p>\n<p><\/p>\n<p>Da biste ih pravilno koristili, va\u017eno je dobro razumjeti kako zapravo funkcioniraju: \u0161to je trigramni Bloom filtar i kako odabrati njegovu veli\u010dinu. Mogu re\u0107i da \u0107e pomo\u0107i za upite s nekim rijetkim frazama, podstringovima koji se rijetko nalaze u podacima. U tom slu\u010daju, prema indeksima \u0107e se odabrati podrasponi, a bit \u0107e pro\u010ditano manje podataka.<\/p>\n<p><\/p>\n<p>Nedavno su u ClickHouse-u uvedene naprednije funkcije za pretra\u017eivanje punog teksta. Prvo, pretra\u017eivanje vi\u0161e podstringova u jednom prolazu, uklju\u010duju\u0107i varijante s obzirom na mala i velika slova, bez obzira na velika slova, s podr\u0161kom za UTF-8 ili samo za ASCII. Odaberite naju\u010dinkovitiji koji vam treba. <\/p>\n<p><\/p>\n<p>Tako\u0111er se pojavilo pretra\u017eivanje vi\u0161e regularnih izraza u jednom prolazu. Ne morate pisati X like jedan podstring or X like drugi podstring. Jednostavno ih upi\u0161ite, i sve se izvr\u0161ava maksimalno u\u010dinkovito.<\/p>\n<p><\/p>\n<p>Tre\u0107e, sada postoji pribli\u017eno pretra\u017eivanje regex-a i pribli\u017eno pretra\u017eivanje podstringova. Ako netko napi\u0161e rije\u010d s gre\u0161kom, ona \u0107e se pretra\u017eivati prema maksimalnom podudaranju.<\/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>Kako najbolje organizirati pristup u ClickHouse za veliki broj korisnika?<\/h2>\n<p><\/p>\n<blockquote><p>Recite mi kako najbolje organizirati pristup za veliku koli\u010dinu potro\u0161a\u010da i analiti\u010dara. Kako formirati red, prioritetizirati zahtjeve za max concurrent queries, i kojim alatima?<\/p><\/blockquote>\n<p>Ako je klaster dovoljno velik, dobro rje\u0161enje bi bilo podi\u0107i jo\u0161 dva servera, koji \u0107e postati ulazna to\u010dka za analiti\u010dare. To jest, ne pu\u0161tati analiti\u010dare na konkretne shardove klastera, ve\u0107 jednostavno stvoriti dva prazna servera, bez podataka, i na njima postaviti prava pristupa. Pri tome se postavke korisnika pri distribuiranim zahtjevima prenose na udaljene servere. To jest, sve postavljate na ova dva servera, a postavke imaju efekte na cijeli klaster.<\/p>\n<p><\/p>\n<p>U principu, ovi serveri nemaju podatke, ali koli\u010dina RAM-a na njima je vrlo va\u017ena za izvr\u0161avanje zahtjeva. Disk se tako\u0111er mo\u017ee koristiti za privremene podatke, ako je uklju\u010dena vanjska agregacija ili vanjsko sortiranje.<\/p>\n<p><\/p>\n<p>Va\u017eno je pogledati postavke koje se odnose na sve mogu\u0107e limitacije. Ako sada u\u0111em u klaster 'Yandex.Metrica' kao analiti\u010dar i postavim zahtjev <strong>select count from hits<\/strong>, odmah \u0107u dobiti izuzetak da ne mogu izvr\u0161iti zahtjev. Maksimalan broj redaka koje mogu pregledati \u2014 to je sto milijardi, a ukupno ih je na klasteru pedeset trilijuna u jednoj tablici. To je prvo ograni\u010denje. <\/p>\n<p><\/p>\n<p>Pretpostavimo da \u0107u ukloniti ograni\u010denje po broju redaka, i izvr\u0161iti zahtjev ponovno. Tada \u0107u vidjeti sljede\u0107i izuzetak \u2014 uklju\u010dena je postavka <strong>force index by date<\/strong>. Ne mogu izvr\u0161iti zahtjev ako ne navedem raspon datuma. Ne treba ra\u010dunati na to da \u0107e analiti\u010dari to ru\u010dno unositi. Tipi\u010dan slu\u010daj&nbsp;\u2014 napisa\u043e raspon datuma gdje je datum doga\u0111aja izme\u0111u tjedna. A onda se jednostavno nije dobro stavila zagrada, i umjesto and ispalo je or \u2014 or URL match. Ako ograni\u010denja nema, pro\u0107i \u0107e skenirati stupac URL-a i potro\u0161it \u0107e jednostavno tonove resursa.<\/p>\n<p><\/p>\n<p>Osim toga, u ClickHouse-u postoje dvije postavke prioriteta. Na\u017ealost, vrlo su primitivne. Jedna se zove jednostavno <strong>priority<\/strong>. Ako priority&nbsp;\u2260&nbsp;0, i izvr\u0161avaju se zahtjevi s&nbsp;nekim prioritetom, ali se pritom izvr\u0161ava zahtjev s&nbsp;prioritetom koji ima manju vrijednost, \u0161to zna\u010di vi\u0161i prioritet, tada se zahtjev s&nbsp;vrijedno\u0161\u0107u prioriteta ve\u0107om, \u0161to ozna\u010dava ni\u017ei prioritet, jednostavno obustavlja i ne\u0107e raditi uop\u0107e tijekom tog vremena.<\/p>\n<p><\/p>\n<p>To je vrlo gruba postavka, i ne odgovara slu\u010dajevima kada je u&nbsp;klasteru stalno optere\u0107enje. No, ako imate kratke, impulzivne zahtjeve koji su va\u017eni, a uglavnom klaster miruje, takva postavka bi bila pogodna.<\/p>\n<p><\/p>\n<p>Sljede\u0107a postavka prioriteta zove se <strong>OS thread priority<\/strong>. Samo postavlja za&nbsp;sve niti izvr\u0161avanja zahtjeva veli\u010dinu nice za&nbsp;Linux scheduler. Funkcionira tako-tako, ali ipak radi. Ako se postavi najni\u017ea vrijednost nice&nbsp;\u2014 to je najve\u0107a vrijednost, i zna\u010di najni\u017ei prioritet&nbsp;\u2014 a za&nbsp;zahtjeve s&nbsp;visokim prioritetom postavi -19, tada \u0107e CPU tro\u0161iti niskoprioritetne zahtjeve otprilike \u010detiri puta manje nego visokoprioritetne. <\/p>\n<p><\/p>\n<p>Tako\u0111er je potrebno postaviti maksimalno vrijeme izvr\u0161avanja zahtjeva&nbsp;\u2014 recimo, pet minuta. Minimalna brzina izvr\u0161avanja zahtjeva&nbsp;\u2014 to je najva\u017enije. Ova postavka postoji ve\u0107 dugo, a potrebna je da se ne samo tvrdi da ClickHouse ne usporava, nego da to i osiguramo.<\/p>\n<p><\/p>\n<p>Zamislite, postavljate: ako neki zahtjev obra\u0111uje manje od milijun redaka u&nbsp;sekundi&nbsp;\u2014 to se ne mo\u017ee raditi. To sramoti na\u0161e dobro ime, na\u0161u dobru bazu podataka. Hajde da to jednostavno zabranimo. Zapravo postoje dvije postavke. Jedna se zove <strong>min execution speed<\/strong> \u2014 u redoslijedu upita u sekundi, a druga se zove timeout prije provjere minimalne brzine izvr\u0161enja \u2014 prema zadanim postavkama petnaest sekundi. Dakle, petnaest sekundi mo\u017ee pro\u0107i, a zatim, ako je sporo, jednostavno baciti iznimku \u2014 prekinuti zahtjev.<\/p>\n<p><\/p>\n<p>Tako\u0111er je potrebno postaviti kvote. U ClickHouse-u postoji ugra\u0111ena mogu\u0107nost kvota koja broji potro\u0161nju resursa. No, na\u017ealost, ne fizi\u010dkih resursa poput CPU-a, diskova, nego logi\u010dkih \u2014 broj obra\u0111enih zahtjeva, redaka i pro\u010ditanych bajta. Mo\u017ee se postaviti, na primjer, maksimum od sto zahtjeva u roku od pet minuta i tisu\u0107u zahtjeva na sat.<\/p>\n<p><\/p>\n<p>Za\u0161to je to va\u017eno? Zato \u0161to \u0107e dio analiti\u010dkih zahtjeva biti izvr\u0161en ru\u010dno iz ClickHouse klijenta. I sve \u0107e biti u redu. No, ako imate napredne analiti\u010dare u va\u0161oj tvrtki, oni \u0107e napisati skriptu, a u skripti mo\u017ee biti pogre\u0161ka. I ta gre\u0161ka \u0107e dovesti do toga da se zahtjev izvr\u0161i u beskona\u010dnoj petlji. Od toga se treba za\u0161tititi.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>Mo\u017ee li se dati rezultati jednog upita deset klijentima?<\/h2>\n<p><\/p>\n<blockquote><p>Imamo nekoliko korisnika koji vole dolaziti s vrlo velikim zahtjevima u isto vrijeme. Zahtjev je velik, izvr\u0161ava se u principu brzo, ali zbog toga \u0161to je takvih zahtjeva mnogo istovremeno, postaje vrlo bolno. Mo\u017ee li se isti zahtjev, koji dolazi deset puta zaredom, izvr\u0161iti jedanput, a rezultat predati deset klijenata?<\/p><\/blockquote>\n<p>Problem je u tome \u0161to nemamo rezultata ke\u0161a ili ke\u0161a privremenih podataka. Postoji page cache operativnog sustava, koji omogu\u0107ava da se podaci ne \u010ditaju ponovno s diska, ali, na\u017ealost, podaci \u0107e se i dalje dekomprimirati, deserializirati i ponovno obra\u0111ivati. <\/p>\n<p><\/p>\n<p>\u017deljeli bismo na neki na\u010din izbje\u0107i ovo, bilo ke\u0161iranjem privremenih podataka, bilo organiziranjem sli\u010dnih zahtjeva u neku vrstu reda i dodavanjem ke\u0161a rezultata. Trenutno imamo u razvoju jedan pull request koji dodaje ke\u0161 zahtjeva, ali samo za podzahtjeve u sekciji in i join \u2014 dakle, rje\u0161enje nije potpuno.<\/p>\n<p><\/p>\n<p>Ipak, imamo i mi takvu situaciju. Klasi\u010dan primjer su zahtjevi s paginacijom. Postoji izvje\u0161taj, u njemu je nekoliko stranica, a dolazi zahtjev limit 10. Zatim isto, ali limit 10,10. Nakon toga, nova stranica. I postavlja se pitanje, za\u0161to sve to ponovno ra\u010dunamo? Trenutno nemamo rje\u0161enje i nije mogu\u0107e izbje\u0107i ovo.<\/p>\n<p><\/p>\n<p>Postoji alternativno rje\u0161enje koje se postavlja kao sidokar pored ClickHousea \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> U ClickHouse Proxy-u postoji ugra\u0111eni limiter brzine i ugra\u0111eni cache rezultata. Tu su napravljene mnoge postavke jer je bilo potrebno rije\u0161iti sli\u010dan problem. Proxy omogu\u0107ava limitiranje zahtjeva tako \u0161to ih redoslijedno obra\u0111uje i postavlja koliko dugo \u0107e cache zahtjeva \u017eivjeti. Ako su zahtjevi zaista isti, Proxy \u0107e ih isporu\u010diti vi\u0161e puta, dok \u0107e u ClickHouse oti\u0107i samo jednom.<\/p>\n<p><\/p>\n<p>U Nginxu tako\u0111er postoji cache u besplatnoj verziji, i to \u0107e tako\u0111er raditi. U Nginxu postoje \u010dak i postavke koje, ako su zahtjevi stigli istovremeno, usporavaju druge dok jedan ne bude izvr\u0161en. No, upravo u ClickHouse Proxy-u je postavka mnogo bolja. On je izra\u0111en posebno za ClickHouse i za ove zahtjeve, pa je stoga pogodniji. I instalira se jednostavno. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>\u0160to u\u010diniti s asinkronim operacijama i materializiranim prikazima?<\/h2>\n<p><\/p>\n<blockquote><p>Postoji problem da su operacije s replice-enginom asinkrone \u2014 prvo se podaci zapisuju, a zatim se odvija njihovo sabijanje. Ako ispod tablice postoji materializirana tablica s nekim agregatima, duplicirani podaci \u0107e biti zapisani u nju. Ako ne postoji neka slo\u017eena logika, podaci \u0107e biti duplicirani. \u0160to se mo\u017ee u\u010diniti povodom toga?<\/p>\n<p>Postoji o\u010digledno rje\u0161enje \u2014 implementirati okida\u010d na odre\u0111enu klasu matvjuha tijekom asinkrone operacije sabijanja. Postoje li neke \"srebrne sa\u010dmice\", planovi za implementaciju sli\u010dnih funkcionalnosti?<\/p><\/blockquote>\n<p>Treba se pozabaviti tim kako radi deduplikacija. Ono o \u010demu \u0107u sada govoriti ne odnosi se na pitanje, ali za svaki slu\u010daj, dobro je to imati na umu.<\/p>\n<p><\/p>\n<p>Prilikom umetanja u&nbsp;repliciranu tablicu dolazi do deduplifikacije cijelih umetnutih blokova. Ako ponovno umetnete isti blok, koji sadr\u017ei isto toliko istih redaka u&nbsp;istom redoslijedu, podaci se deduplificiraju. Dobit \u0107ete \u201cOk\u201d kao odgovor na&nbsp;insert, ali zapravo \u0107e biti zapisana samo jedna serija podataka, a ona ne\u0107e biti duplicirana.<\/p>\n<p><\/p>\n<p>To je potrebno za&nbsp;odre\u0111enost. Ako ste tijekom umetanja dobili \u201cOk\u201d, to zna\u010di da su va\u0161i podaci umetnuti. Ako ste dobili gre\u0161ku od&nbsp;ClickHouse-a, to zna\u010di da nisu umetnuti i potrebno je ponoviti umetanje. No, ako se tijekom umetanja prekinula veza, ne znate jesu li podaci umetnuti ili ne. Jedina opcija je ponovno ponoviti umetanje. Ako su podaci zaista bili umetnuti, a vi ih ponovno umetnete, postoji deduplifikacija blokova. To je potrebno kako bi se izbjegli duplicirani podaci. <\/p>\n<p><\/p>\n<p>Va\u017eno je tako\u0111er kako ona funkcionira za&nbsp;materializirane prikaze. Ako su podaci deduplificirani prilikom umetanja u&nbsp;glavnu tablicu, tada u&nbsp;materializirani prikaz oni ne\u0107e biti poslan.<\/p>\n<p><\/p>\n<p>Sada, povodom pitanja. Imate slo\u017eeniju situaciju, jer zapisujete duplikate pojedina\u010dnih redaka. Dakle, cijeli blok nije dupliciran, ve\u0107 su to upravo specifi\u010dni redci, i oni se u&nbsp;pozadini skupljaju. Doista, podaci \u0107e se skupljati u&nbsp;glavnoj tablici, dok \u0107e u&nbsp;materializirani prikaz i\u0107i neskupljeni, i tijekom merge-ova ne\u0107e do\u0107i do ikakvih promjena s&nbsp;materializiranim prikazima. Jer materializirani prikaz je ni\u0161ta drugo nego okida\u010d na&nbsp;insert. Tijekom drugih operacija ni\u0161ta dodatno se ne doga\u0111a s&nbsp;njim.<\/p>\n<p><\/p>\n<p>Na\u017ealost, ovdje vas ne mogu obradovati. Morate tra\u017eiti konkretno rje\u0161enje za&nbsp;ovu situaciju. Na primjer, mo\u017ee li se u&nbsp;materializiranom prikazu tako\u0111er napraviti njegov replacement, i na\u010din deduplifikacije mo\u017eda \u0107e tako\u0111er funkcionirati. No, na\u017ealost, to ne uspijeva uvijek. Ako je agregiraju\u0107i, onda to ne\u0107e funkcionirati. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> I mi smo u svoje vreme imali problema s kostylestvo. Bilo je problema sa prikazima reklama i nekim podacima koje mo\u017eemo prikazivati u realnom vremenu \u2014 to su samo prikazi. Rijetko se ponavljaju, ali ako se to dogodi, ionako \u0107emo ih spojiti. A postojale su stvari koje se ne mogu duplicirati \u2014 klikovi i cijela ta pri\u010da. No, \u017eeleli smo ih pokazati gotovo odmah.<\/p>\n<p><\/p>\n<p>Kako su napravljene materializovane predstave? Postojale su predstave gde se direktno pi\u0161e \u2014 ide zapis u sirove podatke, i pi\u0161u se u vi\u017eenja. U nekom trenutku podaci nisu bili ba\u0161 ta\u010dni, duplicirali su se, i tako dalje. I postoji druga \u010d\u00e1st tabele, gde izgledaju apsolutno identi\u010dno kao materializovane predstave, dakle strukturama su potpuno iste. Svako toliko ponovo izra\u010dunavamo podatke, bez dupliciranja, pi\u0161emo u te tabele. <\/p>\n<p><\/p>\n<p>Mi smo i\u0161li kroz API \u2014 u ClickHouse rukama to ne\u0107e biti mogu\u0107e. API gleda: kada imam datum poslednjeg dodavanja u tabelu, gde su zagarantovano ve\u0107 ta\u010dni podaci, izra\u010dunati, i pravi upit na jednu i drugu tabelu. Iz jedne upit bira do odre\u0111enog vremenskog perioda, a iz druge dodaje ono \u0161to jo\u0161 nije izra\u010dunato. I to funkcioni\u0161e, ali ne sredstvima jednog ClickHouse-a.<\/p>\n<p><\/p>\n<p>Ako imate neki API \u2014 za analiti\u010dare, za korisnike \u2014 to je, u principu, opcija. Uvek se ponovo izra\u010dunava, uvek se ponovo prera\u010dunava. To se mo\u017ee raditi jednom dnevno ili u nekom drugom vremenu. Sami birate opseg koji vam nije potreban i nije kriti\u010dan.<\/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>U ClickHouse-u ima mnogo logova. Kako mogu vidjeti sve \u0161to se de\u0161ava sa serverom u tom trenutku?<\/h2>\n<p><\/p>\n<blockquote><p>U ClickHouse-u postoji vrlo velika koli\u010dina raznih logova, a ta se koli\u010dina pove\u0107ava. U novim verzijama neki od njih su \u010dak po zadatku uklju\u010deni, dok ih u starim verzijama treba aktivirati prilikom nadogradnje. I dalje, ih je sve vi\u0161e i vi\u0161e. Volio bih na kraju vidjeti \u0161to se trenutno de\u0161ava sa mnim serverom, mo\u017eda na nekom sa\u017eetom nadzornom panelu. <\/p>\n<p>Imate li u svojoj ekipi ClickHouse ili me\u0111u prijateljima timova koji podr\u017eavaju neku funkcionalnost gotovih nadzornih plo\u010da koje bi te logove prikazivale kao ve\u0107 gotov proizvod? Na kraju krajeva, gledati logove u ClickHouse-u je sjajno. Ali bilo bi sjajno da to ve\u0107 bude pripremljeno u vidu nadzorne plo\u010de. U\u017eivio bih se u to. <\/p><\/blockquote>\n<p>Nadzorne plo\u010de postoje, ali nisu standardizirane. U na\u0161oj kompaniji oko 60 timova koristi ClickHouse, i \u0161to je naj\u010dudnije, mnogi od njih imaju nadzorne plo\u010de koje su sami napravili, a koje se malo razlikuju. Neki timovi koriste internu instalaciju 'Yandex.Cloud'. Tamo postoje neki gotovi izve\u0161taji, iako ne svi potrebni. Drugi imaju svoje. <\/p>\n<p><\/p>\n<p>Moji kolege iz 'Metri\u010dke' imaju svoju nadzornu plo\u010du u Grafani, a ja imam svoju po njihovom klasteru. Tamo gledam stvari poput hitova ke\u0161a za ke\u0161 zahteva. A jo\u0161 je komplikovanije to \u0161to koristimo razli\u010dite alate. Svoju nadzornu plo\u010du sam napravio na jako starom alatu koji se zove Graphite-web. Potpuno je neprivla\u010dna. I dalje je koristim, iako bi Grafana verovatno bila pogodnija i lep\u0161a. <\/p>\n<p><\/p>\n<p>Osnovna stvar u nadzornim plo\u010dama je ista. To su sistemske metrike po klasteru: CPU, memorija, disk, mre\u017ea. Drugo \u2014 broj istovremenih zahteva, broj istovremenih spajanja, broj zahteva u sekundi, maksimalan broj delova za particije tabela MergeTree, ka\u0161njenje replikacije, veli\u010dina reda replikacije, broj umetnutih redova u sekundi, broj umetnutih blokova u sekundi. To je sve \u0161to dolazi ne iz logova, ve\u0107 iz metrika.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Aleksandre, \u017eelim malo da korigujem. Postoji Grafana. Grafana ima izvor podataka, kojim je ClickHouse. Dakle, mogu iz Grafane slati zahteve direktno ClickHouse-u. U ClickHouse-u postoji tabela sa logovima, to je svima isto. \u017delim da u Grafani pristupim toj tabeli logova i vidim one upite koje moj server \u0161alje. Bilo bi sjajno imati takvu nadzornu plo\u010du.<\/p>\n<p><\/p>\n<p>Sam sam je sklopio. Ali se postavlja pitanje \u2014 ako je sve to standardizovano, i Grafana se koristi svuda, za\u0161to u 'Yandex-u' ne postoji takva zvani\u010dna nadzorna plo\u010da?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> U stvarnosti, datasource koji je trenutno podr\u017ean s ClickHouse, sada je Altinity. Samo \u017eelim dati smjer kuda kopati i koga pritisnuti. Mogu ih pitati jer \"Yandex\" ipak radi ClickHouse, a ne pri\u010du oko njega. Altinity je glavna tvrtka koja trenutno promovira ClickHouse. Ne\u0107e ga napustiti, ve\u0107 \u0107e ga podr\u017eavati. Zato \u0161to zapravo, da se u\u010dita nadzorna plo\u010da na web stranicu Grafana, potrebno je samo registrirati se i u\u010ditati je \u2013 nema posebnih problema. <\/p>\n<p><\/p>\n<p><strong>Aleksej Milovidov:<\/strong> Tijekom posljednje godine, ClickHouse je dobio mnogo mogu\u0107nosti za profiliranje upita. Postoje metri\u010dki podaci za svaki upit po kori\u0161tenju resursa. A nedavno je dodat jo\u0161 detaljniji profajler upita koji omogu\u0107ava pra\u0107enje gdje upit provodi svaku milisekundu. No, da bih iskoristio tu funkcionalnost, moram otvoriti konzolnog klijenta i upisati upit koji stalno zaboravljam. Negdje sam ga pohranio, ali stalno zaboravljam gdje to\u010dno. <\/p>\n<p><\/p>\n<p>\u017delio bih imati alat koji jednostavno prikazuje \u2013 ovo su va\u0161i te\u0161ki upiti, grupirani po klasama upita. Kliknem na neki, i onda bih dobio informaciju za\u0161to je te\u017eak. Trenutno takvo rje\u0161enje ne postoji. I stvarno je prili\u010dno \u010dudno \u0161to, kada me ljudi pitaju: \"Recite, postoje li neki gotovi nadzorne plo\u010de za Grafana?\", ja ka\u017eem: \"Posjetite web stranicu Grafana, tamo je zajednica 'Nadzorne plo\u010de', i tamo je nadzorna plo\u010da od Dime, postoji nadzorna plo\u010da od Kostyana. \u0160to je to, ne znam, nisam ih sam koristio.\"<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>Kako utjecati na merge-ove da server ne padne u OOM?<\/h2>\n<p><\/p>\n<blockquote><p>Imam tablicu, u tablici je samo jedna particija, ona je ReplacingMergeTree. U nju upisujem podatke tijekom \u010detiri godine. Trebao sam napraviti alter i obrisati neke podatke.<\/p>\n<p>To sam napravio, i tijekom obrade tog upita cijela memorija na svim serverima klastera je potro\u0161ena, i svi serveri klastera su se simultano sru\u0161ili u OOM. Nakon toga su se svi zajedno podigli, po\u010deli izvr\u0161avati merge te iste operacije, tog bloka podataka, i ponovno pali u OOM. Onda su se opet digli i ponovno pali. I to se nije prekidalo.<\/p>\n<p>Kasnije se ispostavilo da je to zapravo gre\u0161ka koju su momci ispravili. To je sjajno, hvala puno. No, utisak je ostao. I sada, kada razmi\u0161ljam o tome da treba napraviti neki merge u tablici, postavljam pitanje \u2014 za\u0161to ne mogu nekako uticati na te merge? Na primjer, ograni\u010diti ih po koli\u010dini potrebne RAM memorije, ili u principu po njihovom broju, koji \u0107e obra\u0111ivati konkretno ovu tablicu.<\/p>\n<p>Imam tablicu koja se zove \u201eMetri\u010dke\u201d, obradite je, molim vas, u dva toka. Ne treba stvarati deset ili pet mergeva paralelno, u\u010dinite to u dva. Mislim da \u0107e mi u dva biti dovoljno memorije, dok mo\u017eda ne\u0107u imati dovoljno za obradu deset. Za\u0161to strah ostaje? Zato \u0161to tablica raste, i jednog dana \u0107u se suo\u010diti s situacijom da ne zbog gre\u0161ke, ve\u0107 zbog toga \u0161to \u0107e se podaci mijenjati u tako velikim koli\u010dinama da mi jednostavno ne\u0107e biti dovoljno memorije na serveru. I tada \u0107e server pasti u OOM prilikom mergea. Osim toga, mutaciju mogu opozvati, ali mergevi ve\u0107 ne.<\/p><\/blockquote>\n<p>Znate, prilikom mergeva server ne\u0107e pasti u OOM, jer se prilikom mergea koristi koli\u010dina RAM-a samo za jedan mali raspon podataka. Tako da \u0107e sve biti u redu bez obzira na obim podataka.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Dobro. Tu je situacija takva da, nakon \u0161to je napravljen popravak gre\u0161ke, preuzeo sam novu verziju i na drugoj, manjoj tablici, gdje ima puno particija, izvr\u0161io sli\u010dnu operaciju. I tokom mergea na serveru je potro\u0161eno oko 100 GB RAM-a. Imao sam 150 zauzetih, 100 je zauzelo, i ostalo je jo\u0161 50 GB slobodnog prostora, pa nisam pao u OOM.<\/p>\n<p><\/p>\n<p>\u0160to me trenutno \u0161titi od pada u OOM, ako zaista tro\u0161i 100 GB RAM-a? \u0160to u\u010diniti u situaciji ako iznenada RAM na mergevima ponestane?<\/p>\n<p><\/p>\n<p><strong>Aleksej Milovidov:<\/strong> Postoji problem \u0161to potro\u0161nja RAM-a na&nbsp;merd\u017eanju nije ograni\u010dena. Drugi problem je \u0161to, ako je neki merd\u017e bio zakazan, mora se izvr\u0161iti, jer je zabilje\u017een u&nbsp;logu replikacije. Log replikacije&nbsp;su radnje potrebne da se replikacija dovede u&nbsp;dosljedno stanje. Ako se ne izvr\u0161e ru\u010dne manipulacije koje ovaj log replikacije vra\u0107a, merd\u017e \u0107e se morati, na ovaj ili onaj na\u010din, izvr\u0161iti.<\/p>\n<p><\/p>\n<p>Naravno, bilo bi korisno imati ograni\u010denje na&nbsp;RAM-u koje 'za svaki slu\u010daj' \u0161titi od&nbsp;OOM-a. Ne\u0107e pomo\u0107i merd\u017eanju da se izvr\u0161i, on \u0107e ponovno po\u010deti, dose\u0107i neki prag, odbaciti iznimku, a zatim opet po\u010deti&nbsp;\u2014 iz toga ne\u0107e proiza\u0107i ni\u0161ta dobro. Ali, na\u010delno, bilo bi korisno uvesti takvo ograni\u010denje.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Kako \u0107e se odvijati razvoj Golang drajvera za ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Golang drajver koji je napisao Kirill Shvakov sada slu\u017ebeno podr\u017eava tim ClickHousea. On <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">je u repo ClickHousea<\/a><\/noindex>, sada je velik i stvaran.<\/p>\n<p>Mala napomena. Postoji divno i svima omiljeno skladi\u0161te normalnih formi beskona\u010dnog reda \u2013 to je Vertica. Oni imaju i svoj slu\u017ebeni python drajver koji podr\u017eavaju programeri Vertice. Nekoliko puta se desilo da su se verzije skladi\u0161ta i verzije drajvera zna\u010dajno razdvojile, a drajver je u nekom trenutku prestao raditi. A druga stvar. Podr\u0161ka ovom slu\u017ebenom drajveru, \u010dini mi se, vodi se prema sistemu \u201enippl\u201d \u2013 pi\u0161e\u0161 im issue, i on vje\u010dno visi.<\/p>\n<p>Imam dva pitanja. Trenutno je Golang drajver Kirila \u2013 skoro podrazumijevani na\u010din komunikacije iz Golanga sa ClickHouse-om. Osim toga, neko jo\u0161 uvijek komunicira putem http interfejsa, jer mu se tako vi\u0161e svi\u0111a. Kako \u0107e se odvijati razvoj ovog drajvera? Ho\u0107e li se sinhronizirati sa nekim breaking changes u samom skladi\u0161tu? I koji je redoslijed razmatranja issue-a? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> Prvo&nbsp;\u2014 kako je sve organizirano birokratski. Ovaj trenutak nije raspravljen, tako da nemam na to odgovor.<\/p>\n<p><\/p>\n<p>Da bih odgovorio na&nbsp;pitanje o&nbsp;issue, trebam malu povijest drajvera. Radio sam u&nbsp;tvrtki koja je imala mnogo podataka. Bilo je to ogla\u0161avanje s&nbsp;ogromnim brojem doga\u0111aja koji su se morali negdje pohraniti. I u&nbsp;nekom trenutku se pojavio ClickHouse. Stavili smo tamo podatke, i u&nbsp;po\u010detku je sve bilo dobro, ali kasnije je ClickHouse pao. U tom trenutku odlu\u010dili smo da nam to nije potrebno. <\/p>\n<p><\/p>\n<p>Nakon godine vratili smo se ideji kori\u0161tenja ClickHouse-a, i trebali smo nekako pisati podatke. Ulazna informacija je bila takva&nbsp;\u2014 hardver je bio vrlo slab, resursa je bilo malo. No, uvijek smo tako radili, pa smo se okrenuli prema nativnom protokolu.<\/p>\n<p><\/p>\n<p>S obzirom da smo radili u&nbsp;Go-u, bilo je jasno da je potreban drajver na&nbsp;Go-u. Radio sam na njemu gotovo full-time&nbsp;\u2014 to je bio moj radni zadatak. Do nekog trenutka doveli smo ga do kraja, i u principu nitko nije pretpostavljao da \u0107e ga netko osim nas koristiti. Onda je do\u0161ao CloudFlare s&nbsp;isto takvim problemom, i neko vrijeme radili smo s&nbsp;njima vrlo glatko, jer su imali iste zadatke. Osim toga, radili smo to i u&nbsp;samom ClickHouse-u, i u&nbsp;drajveru. <\/p>\n<p><\/p>\n<p>U jednom trenutku jednostavno sam prestao s tim, jer se moja aktivnost u vezi s ClickHouse-om i radom malo promijenila. Zbog toga se problemi ne zatvaraju. Povremeno u repozitorij commitaju ljudi kojima ne\u0161to treba. Tada pogledam pull request i ponekad \u010dak ne\u0161to i sam ispravim, ali to se doga\u0111a rijetko.<\/p>\n<p><\/p>\n<p>\u017delim se vratiti voza\u010du. Prije nekoliko godina, kada je sve to po\u010delo, ClickHouse je bio druga\u010diji i s drugim mogu\u0107nostima. Sada postoji razumijevanje kako prepraviti voza\u010d da bi bilo dobro. Ako do toga do\u0111e, verzija 2 \u0107e u svakom slu\u010daju biti nekompatibilna zbog nagomilanih 'hackova'. <\/p>\n<p><\/p>\n<p>Kako to organizirati, ne znam. Nemam puno vremena. Ako neki ljudi budu dopunili voza\u010d, mo\u0107i \u0107u im pomo\u0107i i re\u0107i im \u0161to da rade. No aktivno sudjelovanje 'Yandexa' u razvoju projekta trenutno nije bilo raspravljano. <\/p>\n<p><\/p>\n<p><strong>Aleksej Milovidov:<\/strong> Zapravo, trenutno nema nikakve birokracije u vezi s tim voza\u010dima. Jedino je to \u0161to su premje\u0161teni u slu\u017ebenu organizaciju, tj. taj voza\u010d je priznato slu\u017ebeno rje\u0161enje prema zadanim postavkama za Go. Postoje neki drugi voza\u010di, ali oni su odvojeni. <\/p>\n<p><\/p>\n<p>Unutra nemamo nikakvog razvoja za te voza\u010de. Pitanje je ho\u0107emo li mo\u0107i zaposliti posebnu osobu, ne specifi\u010dno za taj voza\u010d, ve\u0107 za razvoj svih voza\u010da zajednice, ili \u0107emo prona\u0107i nekoga izvana. <\/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>Vanjski rje\u010dnik se ne podi\u017ee nakon ponovnog pokretanja s uklju\u010denim postavkom lazy_load. \u0160to u\u010diniti?<\/h2>\n<p><\/p>\n<blockquote><p>Imamo uklju\u010denu postavku lazy_load, i nakon ponovnog pokretanja poslu\u017eitelja, rje\u010dnik se sam ne podi\u017ee. Podi\u017ee se samo nakon \u0161to korisnik pozove taj rje\u010dnik. I prilikom prvog poziva vra\u0107a pogre\u0161ku. Mo\u017ee li se na neki na\u010din automatski putem ClickHouse-a u\u010ditati rje\u010dnike, ili ih moramo uvijek sami kontrolirati kako korisnici ne bi dobili pogre\u0161ke?<\/p>\n<p>Mo\u017eda imamo staru verziju ClickHouse-a, pa se rje\u010dnik automatski nije u\u010ditao. Mo\u017ee li to biti?<\/p><\/blockquote>\n<p>Prvo, rje\u010dnike se mo\u017ee prisilno u\u010ditati pomo\u0107u upita. <strong>system reload dictionaries<\/strong>. Drugo, \u0161to se ti\u010de gre\u0161ke \u2014 ako je rje\u010dnik ve\u0107 u\u010ditan, zahtjevi \u0107e raditi s podacima koji su u\u010ditani. Ako rje\u010dnik jo\u0161 nije u\u010ditan, bit \u0107e u\u010ditan direktno u trenutku zahtjeva.<\/p>\n<p><\/p>\n<p>Za te\u0161ke rje\u010dnike to nije ba\u0161 zgodno. Na primjer, treba izvu\u0107i milijun redaka iz MySQL-a. Netko napravi jednostavni select, ali taj select \u0107e \u010dekati onih milijun redaka. Ovdje postoje dva rje\u0161enja. Prvo \u2014 isklju\u010diti lazy_load. Drugo \u2014 kada se server podi\u017ee, prije nego \u0161to se na njega stavi optere\u0107enje, napraviti <strong>system reload dictionary<\/strong> ili samo izvr\u0161iti upit koji koristi rje\u010dnik. Tada \u0107e rje\u010dnik biti u\u010ditan. Potrebno je samostalno kontrolirati dostupnost rje\u010dnika s uklju\u010denim lazy_load, jer ClickHouse automatski ih ne povla\u010di.<\/p>\n<p><\/p>\n<p>Na posljednje pitanje odgovor je \u2014 ili je verzija stara, ili treba debagirati. <\/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>\u0160to u\u010diniti s tim da system reload dictionaries ne u\u010ditava niti jedan od mnogih rje\u010dnika ako barem jedan od njih ne uspije s gre\u0161kom?<\/h2>\n<p><\/p>\n<blockquote><p>Postoji jo\u0161 pitanje u vezi s reloaded dictionaries. Imamo dva rje\u010dnika \u2014 jedan se ne u\u010ditava, drugi se u\u010ditava. System reload dictionaries u tom slu\u010daju ne u\u010ditava ni jedan rje\u010dnik, i potrebno je precizno u\u010ditavati odre\u0111eni prema njegovom nazivu pomo\u0107u system reload dictionary. Da li to tako\u0111er ima veze s verzijom ClickHouse?<\/p><\/blockquote>\n<p>\u017delim vas obradovati. Ovo pona\u0161anje se promijenilo. Zna\u010di, ako a\u017eurirate ClickHouse, to \u0107e se tako\u0111er promijeniti. Ako vam trenutno pona\u0161anje ne odgovara <strong>system reload dictionaries<\/strong>, a\u017eurirajte se, i nadamo se da \u0107e se to promijeniti na bolje.<\/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>Postoji li na\u010din da se konfiguri\u0161u podaci u&nbsp;ClickHouse konfiguraciji, ali da se ne prika\u017eu u slu\u010daju gre\u0161ke?<\/h2>\n<p><\/p>\n<blockquote><p>Sljede\u0107e pitanje o gre\u0161kama vezanim uz rje\u010dnik, a konkretno o parametrima. Definirali smo parametre povezivanja u konfiguraciji ClickHouse za rje\u010dnik, i prilikom gre\u0161ke primamo te parametre i lozinku u odgovoru. <\/p>\n<p>Rije\u0161ili smo ovu gre\u0161ku izdvojenjem parametara u konfiguraciju ODBC drajvera. Postoji li neki na\u010din da se parametri konfiguri\u0161u u konfiguraciji ClickHouse, ali da se ti parametri ne prikazuju prilikom gre\u0161aka?<\/p><\/blockquote>\n<p>Ovde je rje\u0161enje zaista \u2014 navesti te credentials u odbc.ini, a u samom ClickHouse navesti samo ODBC Data Source Name. Za ostale izvore rje\u010dnika ovoga ne\u0107e biti \u2014 ni za rje\u010dnik s MySQL, ni za ostale ne smijete vidjeti lozinku prilikom poruke o gre\u0161ci. Za ODBC \u0107u tako\u0111er provjeriti \u2014 ako to postoji, treba to jednostavno ukloniti.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Bonus: pozadine za Zoom s&nbsp;dru\u017eenja<\/h2>\n<p><\/p>\n<p>Klikom na sliku za najupornije \u010ditatelje otvaraju se bonusi pozadine s okupljanja. Gasimo po\u017ear zajedno s maskotama tehnologije Avito, sastajemo se s kolegama iz sobe sistem administratora ili oldschool ra\u010dunalnog kluba i odr\u017eavamo dnevne sastanke ispod mosta uz grafite u pozadini.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse za napredne korisnike kroz pitanja i odgovore\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Izvor: <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.4 - 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\/hr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\/hr\/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 za napredne korisnike u pitanjima i odgovorima | ProHoster","description":"U travnju su se in\u017eenjeri Avita okupili na online dru\u017eenju s glavnim programerom ClickHouse-a Aleksejem Milovidovim i Kirilom Shvakovim, Golang programerom iz tvrtke Integros.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/80775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}