funksionin tabelar input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Nj\u00eb tjet\u00ebr antipattern \u00ebsht\u00eb mikro-shardimi. P\u00ebr shembull, n\u00ebse ju nevojitet t\u00eb shardoni t\u00eb dh\u00ebnat dhe keni 5 server\u00eb, por nes\u00ebr do t\u00eb keni 6 server\u00eb. Dhe mendoni se si t\u00eb ristrukturoni k\u00ebto t\u00eb dh\u00ebna. Dhe n\u00eb vend q\u00eb t'i ndani n\u00eb 5 sharda, i ndani n\u00eb 1,000 sharda. Pastaj \u00e7do nj\u00eb prej k\u00ebtyre mikro-shardave e lidhni me nj\u00eb server t\u00eb ve\u00e7ant\u00eb. K\u00ebshtu do t\u00eb keni p\u00ebr shembull, 200 ClickHouse n\u00eb nj\u00eb server, me instance t\u00eb ve\u00e7anta n\u00eb porta t\u00eb ve\u00e7anta ose n\u00eb baza t\u00eb dh\u00ebnash t\u00eb ve\u00e7anta. <\/p>\n
<\/p>\n
<\/p>\n
Por n\u00eb ClickHouse kjo nuk \u00ebsht\u00eb shum\u00eb mir\u00eb. Sepse edhe nj\u00eb instance ClickHouse p\u00ebrpiqet t\u00eb p\u00ebrdor\u00eb t\u00eb gjitha burimet e disponueshme t\u00eb serverit p\u00ebr t\u00eb p\u00ebrpunuar nj\u00eb k\u00ebrkes\u00eb. Dometh\u00ebn\u00eb, n\u00ebse keni nj\u00eb server dhe aty, p\u00ebr shembull, 56 b\u00ebrthama procesor\u00ebsh. Ju ekzekutoni nj\u00eb k\u00ebrkes\u00eb q\u00eb zgjat nj\u00eb sekond\u00eb, dhe do t\u00eb p\u00ebrdor\u00eb 56 b\u00ebrthama. N\u00ebse keni vendosur 200 ClickHouse n\u00eb nj\u00eb server, at\u00ebher\u00eb do t\u00eb keni 10,000 thirrje. N\u00eb p\u00ebrgjith\u00ebsi, gj\u00ebrat do t\u00eb shkojn\u00eb shum\u00eb keq.<\/p>\n
<\/p>\n
Arsyeja tjet\u00ebr \u00ebsht\u00eb se shp\u00ebrndarja e pun\u00ebs nd\u00ebrmjet k\u00ebtyre instancave do t\u00eb jet\u00eb e pabarabart\u00eb. Disa do ta p\u00ebrfundojn\u00eb m\u00eb her\u00ebt, disa m\u00eb von\u00eb. Po t\u00eb ndodhte gjith\u00e7ka n\u00eb nj\u00eb instance, ClickHouse do t\u00eb dinte si t\u00eb shp\u00ebrndaj\u00eb t\u00eb dh\u00ebnat sakt\u00ebsisht mes rrjedhave. <\/p>\n
<\/p>\n
N\u00eb nj\u00eb arsye tjet\u00ebr \u00ebsht\u00eb se do t\u00eb keni nd\u00ebrveprime nd\u00ebrmjet proceseve p\u00ebrmes TCP. T\u00eb dh\u00ebnat do t\u00eb duhet t\u00eb serializohen, deserializohen dhe do t\u00eb ket\u00eb nj\u00eb num\u00ebr t\u00eb madh mikro-shardesh. K\u00ebshtu, do t\u00eb funksionoj\u00eb thjesht n\u00eb m\u00ebnyr\u00eb joefikase.<\/p>\n
<\/p>\n
<\/p>\n
Nj\u00eb tjet\u00ebr antipattern, edhe pse \u00ebsht\u00eb e v\u00ebshtir\u00eb ta quash nj\u00eb antipattern. Kjo \u00ebsht\u00eb nj\u00eb sasi e madhe para-agregimi.<\/p>\n
<\/p>\n
N\u00eb fakt, parashtrimi \u00ebsht\u00eb shum\u00eb i mir\u00eb. N\u00ebse kishit nj\u00eb miliard rreshta, e keni agreguar at\u00eb n\u00eb 1,000 rreshta, dhe tani k\u00ebrkesa e realizohet menj\u00ebher\u00eb. E gjith\u00eb kjo \u00ebsht\u00eb n\u00eb rregull. K\u00ebshtu mund t\u00eb veprohet. Dhe p\u00ebr k\u00ebt\u00eb, madje n\u00eb ClickHouse ka nj\u00eb tip t\u00eb ve\u00e7ant\u00eb tabele AggregatingMergeTree, e cila kryen agregimin inkremental teksa futen t\u00eb dh\u00ebna. <\/p>\n
<\/p>\n
Por ndodhin raste kur mendoni se do t\u00eb agregoni t\u00eb dh\u00ebnat k\u00ebshtu dhe po ashtu. Dhe n\u00eb nj\u00eb departament fqinje, gjithashtu nuk dua t\u00eb p\u00ebrmend emrin, p\u00ebrdorin tabela SummingMergeTree p\u00ebr t\u00eb p\u00ebrmbledhur sipas \u00e7el\u00ebsit kryesor, dhe si \u00e7el\u00ebs kryesor p\u00ebrdorin rreth 20 kolona t\u00eb ndryshme. N\u00eb \u00e7do rast, e kam ndryshuar emrat e disa kolonave p\u00ebr konspiracion, por \u00ebsht\u00eb k\u00ebshtu m\u00eb pak m\u00eb shum\u00eb.<\/p>\n
<\/p>\n
<\/p>\n
Dhe ndodhin k\u00ebto probleme. S\u00eb pari, volumi i t\u00eb dh\u00ebnave nuk zvog\u00eblohet shum\u00eb. P\u00ebr shembull, zvog\u00eblohet tre her\u00eb. Tre her\u00eb \u2013 do t\u00eb ishte nj\u00eb \u00e7mim i mir\u00eb p\u00ebr t'i lejuar vetes mund\u00ebsi t\u00eb pakufizuara p\u00ebr analiz\u00eb, q\u00eb ndodhin n\u00ebse t\u00eb dh\u00ebnat jan\u00eb t\u00eb paagreguara. N\u00ebse t\u00eb dh\u00ebnat jan\u00eb t\u00eb agreguara, at\u00ebher\u00eb n\u00eb vend t\u00eb analiz\u00ebs merrni vet\u00ebm statistika t\u00eb mjerueshme. <\/p>\n
<\/p>\n
Dhe \u00e7far\u00eb \u00ebsht\u00eb ve\u00e7an\u00ebrisht frustrues? Sepse k\u00ebta njer\u00ebz nga departamenti p\u00ebrball\u00eb vijn\u00eb dhe k\u00ebrkojn\u00eb ndonj\u00ebher\u00eb t\u00eb shtohet nj\u00eb kolon\u00eb tjet\u00ebr n\u00eb \u00e7el\u00ebsin primar. Do t\u00eb thot\u00eb, ne kemi aggreguar t\u00eb dh\u00ebnat k\u00ebshtu, dhe tani duam pak m\u00eb shum\u00eb. Por n\u00eb ClickHouse nuk ka mund\u00ebsi p\u00ebr t\u00eb modifikuar \u00e7el\u00ebsin primar. Prandaj, duhet t\u00eb shkruajm\u00eb ndonj\u00eb skript n\u00eb C++. Dhe un\u00eb nuk i p\u00eblqej skriptet, madje ndonj\u00ebher\u00eb edhe n\u00eb C++.<\/p>\n
<\/p>\n
Dhe n\u00ebse e shikoni p\u00ebrse u krijua ClickHouse, t\u00eb dh\u00ebnat jo t\u00eb agreguara jan\u00eb pik\u00ebrisht skenari p\u00ebr t\u00eb cilin ai \u00ebsht\u00eb krijuar. N\u00ebse e p\u00ebrdorni ClickHouse p\u00ebr t\u00eb dh\u00ebna jo t\u00eb agreguara, at\u00ebher\u00eb po b\u00ebni gjith\u00e7ka si\u00e7 duhet. N\u00ebse po agregoni, at\u00ebher\u00eb ndonj\u00ebher\u00eb \u00ebsht\u00eb e pranueshme. <\/p>\n
<\/p>\n
<\/p>\n
Nj\u00eb rast tjet\u00ebr interesant \u00ebsht\u00eb k\u00ebrkesat n\u00eb nj\u00eb cik\u00ebl t\u00eb pafund. Ndonj\u00ebher\u00eb, hyj n\u00eb ndonj\u00eb server production dhe shikoj atje show processlist. Dhe \u00e7do her\u00eb zbulloj se po ndodhin gj\u00ebra t\u00eb tmerrshme. <\/p>\n
<\/p>\n
P\u00ebr shembull, di\u00e7ka e till\u00eb. K\u00ebtu \u00ebsht\u00eb menj\u00ebher\u00eb e qart\u00eb se t\u00eb gjitha mund t\u00eb ishin ekzekutuar n\u00eb nj\u00eb k\u00ebrkes\u00eb. Thjesht shkruani atje url in dhe list\u00ebn.<\/p>\n
<\/p>\n
<\/p>\n
Pse ka shum\u00eb k\u00ebrkesa t\u00eb tilla n\u00eb nj\u00eb cik\u00ebl t\u00eb pafund \u2013 kjo \u00ebsht\u00eb e keqe? N\u00ebse indeksi nuk p\u00ebrdoret, do t\u00eb keni shum\u00eb kalime mbi t\u00eb nj\u00ebjtat t\u00eb dh\u00ebna. Por n\u00ebse indeksi p\u00ebrdoret, p\u00ebr shembull, n\u00ebse keni nj\u00eb \u00e7el\u00ebs primar mbi ru dhe shkruani url = di\u00e7ka aty. Dhe mendoni se do t\u00eb lexoni pik\u00ebrisht nj\u00eb url nga tabela, do t\u00eb jet\u00eb gjith\u00e7ka n\u00eb rregull. Por n\u00eb fakt, jo. Sepse ClickHouse b\u00ebn gjith\u00e7ka sipas grupeve. <\/p>\n
<\/p>\n
Kur i duhet t\u00eb lexoj\u00eb nj\u00eb interval t\u00eb caktuar t\u00eb t\u00eb dh\u00ebnave, ai lexon pak m\u00eb shum\u00eb, sepse indeksi n\u00eb ClickHouse \u00ebsht\u00eb i holl\u00eb. Ky indeks nuk lejon t\u00eb gjendet nj\u00eb rresht t\u00eb ve\u00e7ant\u00eb n\u00eb tabel\u00eb, vet\u00ebm nj\u00eb interval t\u00eb caktuar. Dhe t\u00eb dh\u00ebnat kompresohen n\u00eb blloqe. P\u00ebr t\u00eb lexuar nj\u00eb rresht, duhet t\u00eb merrni nj\u00eb bllok t\u00eb t\u00ebr\u00eb dhe ta \u00e7kompresoni. Dhe n\u00ebse kryeni shum\u00eb k\u00ebrkesa, do t\u00eb keni shum\u00eb p\u00ebrputhje t\u00eb tilla dhe shum\u00eb pun\u00eb do t'ju p\u00ebrfundoj\u00eb vazhdimisht.<\/p>\n
<\/p>\n
<\/p>\n
Dhe si nj\u00eb bonus, mund t\u00eb theksoj se n\u00eb ClickHouse nuk duhet t\u00eb keni frik\u00eb t\u00eb d\u00ebrgoni madje edhe megabajt\u00eb dhe madje qindra megabajt\u00eb n\u00eb seksionin IN. E mbaj mend nga praktika jon\u00eb se n\u00ebse n\u00eb MySQL d\u00ebrgojm\u00eb nj\u00eb mori vlerash n\u00eb seksionin IN, p\u00ebr shembull, d\u00ebrgojm\u00eb aty 100 megabajt\u00eb ndonj\u00eb numri, at\u00ebher\u00eb MySQL konsumon 10 gigabajt\u00eb memorie dhe m\u00eb shum\u00eb me k\u00ebt\u00eb nuk ndodh asgj\u00eb, gjith\u00e7ka punon keq. <\/p>\n
<\/p>\n
Dhe e dyta \u2013 \u00ebsht\u00eb se n\u00eb ClickHouse, n\u00ebse k\u00ebrkimet tuaja p\u00ebrdorin indeks, at\u00ebher\u00eb kjo \u00ebsht\u00eb gjithmon\u00eb jo m\u00eb e ngadalt\u00eb se skanimi i plot\u00eb, dmth. n\u00ebse duhet t\u00eb lexoni pothuajse t\u00ebr\u00eb tabel\u00ebn, ai do t\u00eb shkoj\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb vazhdueshme dhe do t\u00eb lexoj\u00eb t\u00ebr\u00eb tabel\u00ebn. N\u00eb p\u00ebrgjith\u00ebsi, ai do t\u00eb kuptoj\u00eb vet\u00eb.<\/p>\n
<\/p>\n
Por megjithat\u00eb ka disa v\u00ebshtir\u00ebsi. P\u00ebr shembull, ajo q\u00eb IN me nj\u00eb n\u00ebnk\u00ebrkes\u00eb nuk p\u00ebrdor indeks. Por kjo \u00ebsht\u00eb problemi yn\u00eb dhe duhet ta rregullojm\u00eb. Nuk ka asgj\u00eb t\u00eb thell\u00eb k\u00ebtu. Do ta rregullojm\u00eb*. <\/p>\n
<\/p>\n
Dhe nj\u00eb gj\u00eb tjet\u00ebr interesante \u2013 \u00ebsht\u00eb se n\u00ebse keni nj\u00eb k\u00ebrkes\u00eb shum\u00eb t\u00eb gjat\u00eb dhe p\u00ebrpunimi i k\u00ebrkesave \u00ebsht\u00eb i shp\u00ebrndar\u00eb, at\u00ebher\u00eb kjo k\u00ebrkes\u00eb shum\u00eb e gjat\u00eb do t\u00eb d\u00ebrgohet n\u00eb \u00e7do server pa kompresim. P\u00ebr shembull, 100 megabajt\u00eb dhe 500 server\u00eb. Dhe, p\u00ebr rrjedhoj\u00eb, do t\u00eb d\u00ebrgohen 50 gigabajt\u00eb p\u00ebrmes rrjetit. Do t\u00eb d\u00ebrgohen dhe pastaj gjith\u00e7ka do t\u00eb ekzekutohet me sukses.<\/p>\n
<\/p>\n
* tashm\u00eb po p\u00ebrdoret; gjith\u00e7ka \u00ebsht\u00eb rregulluar, si\u00e7 u premtua.<\/p>\n
<\/p>\n
<\/p>\n
Dhe \u00ebsht\u00eb nj\u00eb rast mjaft i zakonsh\u00ebm n\u00ebse k\u00ebrkesat vijn\u00eb nga API. P\u00ebr shembull, keni krijuar ndonj\u00eb sh\u00ebrbim tuajin. Dhe n\u00ebse sh\u00ebrbimi juaj \u00ebsht\u00eb i nevojsh\u00ebm p\u00ebr dik\u00eb, at\u00ebher\u00eb e keni hapur API-n\u00eb dhe pas dy dit\u00ebsh v\u00ebreni se ndodhin gj\u00ebra t\u00eb \u00e7uditshme. T\u00eb gjitha jan\u00eb t\u00eb ngarkuara dhe po vijn\u00eb disa k\u00ebrkesa t\u00eb tmerrshme, t\u00eb cilat kurr\u00eb nuk duhej t\u00eb ishin. <\/p>\n
<\/p>\n
Dhe zgjidhja k\u00ebtu \u00ebsht\u00eb nj\u00eb. N\u00ebse keni hapur API-n\u00eb, do t'ju duhet ta kufizoni at\u00eb. P\u00ebr shembull, t\u00eb vendosni ndonj\u00eb kuot\u00eb. Nuk ka alternativa t\u00eb tjera normale. P\u00ebrndryshe, menj\u00ebher\u00eb do t\u00eb shkruajn\u00eb nj\u00eb skript dhe do t\u00eb ken\u00eb probleme. <\/p>\n
<\/p>\n
Dhe n\u00eb ClickHouse ka nj\u00eb mund\u00ebsi speciale \u2013 kjo \u00ebsht\u00eb llogaritja e kuotave. Gjithashtu, mund t\u00eb transferoni \u00e7el\u00ebsin tuaj t\u00eb kuot\u00ebs. Kjo, p\u00ebr shembull, \u00ebsht\u00eb nj\u00eb identifikues i brendsh\u00ebm i p\u00ebrdoruesit. Dhe kuotat do t\u00eb llogariten pavar\u00ebsisht p\u00ebr secilin prej tyre. <\/p>\n
<\/p>\n
<\/p>\n
Tani, ka edhe nj\u00eb gj\u00eb interesante. Kjo \u00ebsht\u00eb replikimi me dor\u00eb. <\/p>\n
<\/p>\n
Di shum\u00eb raste kur, megjith\u00ebse ClickHouse ka mb\u00ebshtetje t\u00eb integruar p\u00ebr replikimin, njer\u00ebzit e replikojn\u00eb ClickHouse me dor\u00eb.<\/p>\n
<\/p>\n
Cili \u00ebsht\u00eb principi? Ju keni nj\u00eb pipeline p\u00ebr p\u00ebrpunimin e t\u00eb dh\u00ebnave. Dhe ai funksionon n\u00eb pavar\u00ebsi, p.sh., n\u00eb qendra t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave. Ju regjistroni t\u00eb dh\u00ebna t\u00eb nj\u00ebjta n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb nj\u00ebjt\u00eb n\u00eb ClickHouse, si\u00e7 \u00ebsht\u00eb. Megjithat\u00eb, praktika tregon se t\u00eb dh\u00ebnat do t\u00eb shkojn\u00eb n\u00eb ndryshim p\u00ebr shkak t\u00eb ndonj\u00eb ve\u00e7orie n\u00eb kodin tuaj. Shpresoj se n\u00eb rastin tuaj ndodh k\u00ebshtu. <\/p>\n
<\/p>\n
Dhe periodikisht do t'ju duhet gjithsesi t\u00eb sinkronizoni me dor\u00eb. P\u00ebr shembull, nj\u00eb her\u00eb n\u00eb muaj, administrator\u00ebt b\u00ebjn\u00eb rsync.<\/p>\n
<\/p>\n
N\u00eb fakt, \u00ebsht\u00eb shum\u00eb m\u00eb e thjesht\u00eb t\u00eb p\u00ebrdorni replikimin e nd\u00ebrtuar n\u00eb ClickHouse. Por k\u00ebtu mund t\u00eb ket\u00eb disa kund\u00ebrindikacione, sepse p\u00ebr k\u00ebt\u00eb duhet t\u00eb p\u00ebrdorni ZooKeeper. Nuk do t\u00eb flas asgj\u00eb t\u00eb keqe p\u00ebr ZooKeeper, n\u00eb parim sistemi funksionon, por ndonj\u00ebher\u00eb ndodh q\u00eb njer\u00ebzit nuk e p\u00ebrdorin at\u00eb p\u00ebr shkak t\u00eb frik\u00ebs nga java, sepse ClickHouse \u00ebsht\u00eb nj\u00eb sistem i shk\u00eblqyer, i shkruar n\u00eb C++, q\u00eb mund t\u00eb p\u00ebrdoret dhe gjith\u00e7ka do t\u00eb shkoj\u00eb mir\u00eb. Nd\u00ebrsa ZooKeeper \u00ebsht\u00eb n\u00eb java. Dhe ndonj\u00ebher\u00eb nuk d\u00ebshiron as ta shoh\u00ebsh, por at\u00ebher\u00eb mund t\u00eb p\u00ebrdorni replikimin me dor\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse \u2013 \u00ebsht\u00eb nj\u00eb sistem praktik. Ai i merr parasysh nevojat tuaja. N\u00ebse keni replikim n\u00eb disqe manuale, mund t\u00eb krijoni nj\u00eb tabel\u00eb t\u00eb Distribuar, e cila shikon n\u00eb replikat tuaja manuale dhe b\u00ebn vet\u00eb kalimin midis tyre. Dhe ka madje nj\u00eb opsion t\u00eb ve\u00e7ant\u00eb, i cili lejon shmangien e problemeve, edhe n\u00ebse replikat tuaja ndahen sistematikisht.<\/p>\n
<\/p>\n
<\/p>\n
M\u00eb pas mund t\u00eb hasni probleme n\u00ebse p\u00ebrdorni motor\u00eb tabelash primitivi. ClickHouse \u00ebsht\u00eb nj\u00eb nd\u00ebrtues i till\u00eb, ku ka nj\u00eb mori motor\u00ebsh tabelash t\u00eb ndrysh\u00ebm. P\u00ebr t\u00eb gjitha rastet serioze, si\u00e7 shkruhet n\u00eb dokumentacion, p\u00ebrdorni tabelat e familjes MergeTree. T\u00eb gjitha t\u00eb tjerat jan\u00eb p\u00ebr raste t\u00eb ve\u00e7anta ose p\u00ebr teste.<\/p>\n
<\/p>\n
N\u00eb tabel\u00ebn MergeTree nuk \u00ebsht\u00eb e domosdoshme t\u00eb keni ndonj\u00eb dat\u00eb dhe koh\u00eb. Mund t\u00eb p\u00ebrdorni gjithsesi. N\u00ebse nuk ka dat\u00eb dhe koh\u00eb, shkruani q\u00eb default \u2013 viti 2000. Kjo do t\u00eb funksionoj\u00eb dhe nuk do t\u00eb k\u00ebrkoj\u00eb burime. <\/p>\n
<\/p>\n
Dhe n\u00eb versionin e ri t\u00eb serverit madje mund t\u00eb tregoni q\u00eb t\u00eb keni nj\u00eb ndarjen t\u00eb personalizuar pa \u00e7el\u00ebsin e ndarjes. Kjo do t\u00eb jet\u00eb e nj\u00ebjt\u00eb. <\/p>\n
<\/p>\n
<\/p>\n
Nga ana tjet\u00ebr, mund t\u00eb p\u00ebrdorni moteur primitive tabelash. P\u00ebr shembull, ngarkoni t\u00eb dh\u00ebnat nj\u00eb her\u00eb dhe shikoni, rrotulloni dhe fshini. Mund t\u00eb p\u00ebrdorni Log.<\/p>\n
<\/p>\n
Ose mbani sasi t\u00eb vogla p\u00ebr p\u00ebrpunim t\u00eb nd\u00ebrmjet\u00ebm - ky \u00ebsht\u00eb StripeLog ose TinyLog.<\/p>\n
<\/p>\n
Memory mund t\u00eb p\u00ebrdoret, n\u00ebse keni nj\u00eb sasi t\u00eb vog\u00ebl t\u00eb dh\u00ebnash dhe thjesht t\u00eb rrotulloni di\u00e7ka n\u00eb RAM. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse nuk i p\u00eblqen shum\u00eb t\u00eb dh\u00ebnat e tejnormizuara. <\/p>\n
<\/p>\n
Ja nj\u00eb shembull tipik. Kjo \u00ebsht\u00eb nj\u00eb sasi e madhe e URL-ve. I keni futur n\u00eb nj\u00eb tabel\u00eb fqinje. M\u00eb pas vendos\u00ebt t\u00eb b\u00ebni JOIN me to, por kjo zakonisht nuk do t\u00eb funksionoj\u00eb, sepse ClickHouse mb\u00ebshtet vet\u00ebm Hash JOIN. N\u00ebse RAM-i \u00ebsht\u00eb i pamjaftuesh\u00ebm p\u00ebr sasin\u00eb e t\u00eb dh\u00ebnave q\u00eb duhen bashkuar, at\u00ebher\u00eb JOIN nuk do t\u00eb mund t\u00eb realizohet*. <\/p>\n
<\/p>\n
N\u00ebse t\u00eb dh\u00ebnat jan\u00eb me kardinalitet t\u00eb madh, mos e shqet\u00ebsoni, ruani ato n\u00eb form\u00eb denormale, URL-t\u00eb direkt n\u00eb tabel\u00ebn kryesore. <\/p>\n
<\/p>\n
* aktualisht n\u00eb ClickHouse ekziston edhe merge join q\u00eb funksionon kur t\u00eb dh\u00ebnat nd\u00ebrmjet\u00ebse nuk i p\u00ebrshtaten RAM-it. Por kjo \u00ebsht\u00eb e pasakt\u00eb dhe rekomandimi vazhdon t\u00eb mbetet n\u00eb fuqi.<\/p>\n
<\/p>\n
<\/p>\n
Dy shembuj t\u00eb tjer\u00eb, por tashm\u00eb dyshoj n\u00ebse ata jan\u00eb antipatterns apo jo. <\/p>\n
<\/p>\n
ClickHouse ka nj\u00eb mang\u00ebsi t\u00eb njohur. Ai nuk ka p\u00ebrdit\u00ebsime*. N\u00eb nj\u00ebfar\u00eb m\u00ebnyre, kjo \u00ebsht\u00eb edhe e mir\u00eb. N\u00ebse keni ndonj\u00eb t\u00eb dh\u00ebn\u00eb t\u00eb r\u00ebnd\u00ebsishme, p\u00ebr shembull, llogarin\u00eb, askush s'do t\u00eb mund ta d\u00ebrgoj\u00eb at\u00eb, sepse nuk ka p\u00ebrdit\u00ebsime.<\/p>\n
<\/p>\n
* mb\u00ebshtetje p\u00ebr p\u00ebrdit\u00ebsime dhe fshirje \u00ebsht\u00eb shtuar prej koh\u00ebsh n\u00eb modin grup.<\/p>\n
<\/p>\n
Por ka disa m\u00ebnyra t\u00eb ve\u00e7anta, t\u00eb cilat lejojn\u00eb p\u00ebrdit\u00ebsime si p\u00ebr n\u00eb sfond. P\u00ebr shembull, tabelat e tipit ReplaceMergeTree. Ato b\u00ebjn\u00eb p\u00ebrdit\u00ebsime gjat\u00eb bashkimeve n\u00eb sfond. Mund ta forconi k\u00ebt\u00eb me optimizimin e tabel\u00ebs. Por mos e b\u00ebni k\u00ebt\u00eb shum\u00eb shpesh, sepse do t\u00eb b\u00ebhet nj\u00eb riparim i plot\u00eb i pjes\u00ebs. <\/p>\n
<\/p>\n
JOIN t\u00eb shp\u00ebrndar\u00eb n\u00eb ClickHouse \u2013 gjithashtu trajtohet keq nga planifikuesi i k\u00ebrkesave. <\/p>\n
<\/p>\n
Keq, por ndonj\u00ebher\u00eb \u00ebsht\u00eb n\u00eb rregull.<\/p>\n
<\/p>\n
P\u00ebrdorimi i ClickHouse vet\u00ebm p\u00ebr t\u00eb lexuar t\u00eb dh\u00ebnat p\u00ebrs\u00ebri me select*.<\/p>\n
<\/p>\n
Nuk do ta rekomandoja p\u00ebrdorimin e ClickHouse p\u00ebr llogaritje t\u00eb nd\u00ebrlikuara. Por nuk \u00ebsht\u00eb krejt\u00ebsisht k\u00ebshtu, sepse tashm\u00eb po largohemi nga kjo rekomandim. Dhe koh\u00ebt e fundit kemi shtuar mund\u00ebsin\u00eb e aplikimit t\u00eb modeleve t\u00eb m\u00ebsimit t\u00eb makinerive n\u00eb ClickHouse \u2013 Catboost. Dhe kjo m\u00eb shqet\u00ebson, sepse mendoj: \"Sa katastrofike. Sa cikle n\u00eb byte po na rezulton!\". M\u00eb vjen shum\u00eb keq t\u00eb harxhoj cikle p\u00ebr byte. <\/p>\n
<\/p>\n
<\/p>\n
Por mos u frik\u00ebs, vendosni ClickHouse, gjith\u00e7ka do t\u00eb shkoj\u00eb mir\u00eb. N\u00ebse keni ndonj\u00eb problem, ne kemi nj\u00eb komunitet. P\u00ebr m\u00eb tep\u00ebr, komuniteti jeni ju. N\u00ebse keni ndonj\u00eb problem, mund t\u00eb hyni n\u00eb bised\u00ebn ton\u00eb dhe shpresoj q\u00eb do t'ju ndihmojn\u00eb. <\/p>\n
<\/p>\n
Pyetje<\/p>\n
<\/p>\n
Faleminderit p\u00ebr raportin! Ku mund t\u00eb ankohesha p\u00ebr r\u00ebnien e ClickHouse?<\/em><\/p>\n<\/p>\n
Mund t\u00eb ankohem personalisht tani. <\/p>\n
<\/p>\n
K\u00ebt\u00eb koh\u00eb kam filluar t\u00eb p\u00ebrdor ClickHouse. Menj\u00ebher\u00eb e humba nd\u00ebrfaqen cli.<\/em><\/p>\n<\/p>\n
Ju keni fat. <\/p>\n
<\/p>\n
Pak m\u00eb von\u00eb e humba serverin me nj\u00eb select t\u00eb vog\u00ebl.<\/em><\/p>\n<\/p>\n
Keni talent. <\/p>\n
<\/p>\n
Kam hapur nj\u00eb defekt n\u00eb GitHub, por e injoruan.<\/em> <\/p>\n<\/p>\n
Do ta shohim. <\/p>\n
<\/p>\n
Aleksej m\u00eb mashtroi p\u00ebr t\u00eb ndar\u00eb nj\u00eb raport, duke premtuar se do t\u00eb tregonte si e ngjeshni t\u00eb dh\u00ebnat brenda.<\/em><\/p>\n<\/p>\n
Shum\u00eb thjesht\u00eb. <\/p>\n
<\/p>\n
K\u00ebt\u00eb e kuptova dje. M\u00eb shum\u00eb p\u00ebr t\u00eb sakt\u00eb.<\/em> <\/p>\n<\/p>\n
Nuk ka asnj\u00eb mashtrim t\u00eb tmerrsh\u00ebm. Thjesht \u00ebsht\u00eb ngjeshje n\u00eb blloqe. N\u00eb parazgjedhje p\u00ebrdoret LZ4, mund t\u00eb aktivizoni ZSTD*. Blloqet jan\u00eb nga 64 kilobajt deri n\u00eb 1 megabajt.<\/p>\n
<\/p>\n
* gjithashtu ka mb\u00ebshtetje p\u00ebr kodek\u00ebt e specializuar t\u00eb ngjeshjes, t\u00eb cilat mund t\u00eb p\u00ebrdoren n\u00eb zinxhir me algorithm\u00eb t\u00eb tjera.<\/p>\n
<\/p>\n
A jan\u00eb blloqet thjesht t\u00eb dh\u00ebna t\u00eb pap\u00ebrpunuara?<\/em><\/p>\n<\/p>\n
Jo krejt\u00ebsisht t\u00eb pap\u00ebrpunuara. Aty ka Arrays. N\u00ebse keni nj\u00eb kolon\u00eb numerike, atje numrat jan\u00eb radhitur n\u00eb nj\u00eb array. <\/p>\n
<\/p>\n
E kuptoj.<\/em> <\/p>\n<\/p>\n
Aleks, nj\u00eb shembull q\u00eb ishte me uniqExact mbi IP-t\u00eb, dmth ajo q\u00eb uniqExact llogaritet m\u00eb gjat\u00eb sipas vargjeve sesa sipas numrave e k\u00ebshtu me radh\u00eb. Dhe n\u00ebse ne aplikojm\u00eb nj\u00eb truk dhe do t\u00eb b\u00ebjm\u00eb casting n\u00eb momentin e leximit? Dmth, duket se keni th\u00ebn\u00eb q\u00eb n\u00eb disk nuk dallon shum\u00eb. N\u00ebse lexojm\u00eb vargjet nga disku, b\u00ebjm\u00eb casting, a do t\u00eb kemi m\u00eb shpejt agregat\u00ebt apo jo? Apo ne gjithsesi do t\u00eb fitojm\u00eb pak k\u00ebtu? M\u00eb duket se e keni testuar k\u00ebt\u00eb, por p\u00ebr nj\u00eb arsye nuk e keni treguar n\u00eb benchmark.<\/em> <\/p>\n<\/p>\n
Mendoj se do t\u00eb jet\u00eb m\u00eb ngadal\u00eb sesa pa casting. N\u00eb k\u00ebt\u00eb rast, adresa IP duhet t\u00eb parserohet nga stringu. Sigurisht, n\u00eb ClickHouse, parsing-u i adresave IP \u00ebsht\u00eb gjithashtu i optimizuar. Ne u munduam shum\u00eb, por numrat jan\u00eb shkruar n\u00eb form\u00ebn me dhjet\u00eb mij\u00eb. Shum\u00eb e pap\u00ebrshtatshme. Nga ana tjet\u00ebr, funksioni uniqExact do t\u00eb punoj\u00eb ngadal\u00eb mbi vargjet jo vet\u00ebm sepse jan\u00eb vargje, por gjithashtu sepse zgjidhet nj\u00eb specializim tjet\u00ebr i algoritmit. Vargjet thjesht trajtohen ndryshe.<\/p>\n
<\/p>\n
Po n\u00ebse marrim nj\u00eb tip m\u00eb primitiv t\u00eb dh\u00ebnash? P\u00ebr shembull, regjistrojm\u00eb user id, i cili \u00ebsht\u00eb in, e regjistrojm\u00eb at\u00eb si nj\u00eb varg, dhe m\u00eb pas e b\u00ebjm\u00eb casting, a do t\u00eb jet\u00eb m\u00eb arg\u00ebtues apo jo?<\/em><\/p>\n<\/p>\n
Kam dyshoj. Mendoj se do t\u00eb jet\u00eb edhe m\u00eb trishtues, sepse n\u00eb fund t\u00eb fundit, analizimi i numrave \u00ebsht\u00eb nj\u00eb problem serioz. M\u00eb duket se ky koleg kishte madje nj\u00eb prezantim mbi sa e v\u00ebshtir\u00eb \u00ebsht\u00eb t\u00eb analizosh numrat n\u00eb form\u00ebn e dhjet\u00eb-mij\u00eb, ose ndoshta jo. <\/p>\n
<\/p>\n
Aleksej, faleminderit shum\u00eb p\u00ebr prezantimin! Dhe faleminderit p\u00ebr ClickHouse! Kam nj\u00eb pyetje p\u00ebr planet. A ka ndonj\u00eb plan p\u00ebr nj\u00eb ve\u00e7ori p\u00ebr t\u00eb p\u00ebrdit\u00ebsuar fjalor\u00ebt jo plot\u00ebsisht?<\/em><\/p>\n<\/p>\n
Pra, nj\u00eb riciklim pjesor?<\/p>\n
<\/p>\n
Po-po. Lloji q\u00eb mund t\u00eb shkruash ndonj\u00eb fush\u00eb MySQL, pra, t\u00eb p\u00ebrdit\u00ebsosh pas, q\u00eb t\u00eb ngarkohen vet\u00ebm k\u00ebta t\u00eb dh\u00ebna, n\u00ebse fjalori \u00ebsht\u00eb shum\u00eb i madh.<\/em><\/p>\n<\/p>\n
Nj\u00eb ve\u00e7ori shum\u00eb interesante. Dhe, m\u00eb duket se ndonj\u00eb njeri e ka propozuar k\u00ebt\u00eb n\u00eb bised\u00ebn ton\u00eb. Ndoshta ky ishe ai vet\u00eb. <\/p>\n
<\/p>\n
Nuk mendoj se kam qen\u00eb un\u00eb.<\/em><\/p>\n<\/p>\n
Shum\u00eb mir\u00eb, tani duket se jan\u00eb dy k\u00ebrkesa. Dhe mund t\u00eb fillosh ngadal\u00eb ta realizosh. Por menj\u00ebher\u00eb dua t'ju paralajm\u00ebroj se kjo ve\u00e7ori \u00ebsht\u00eb mjaft e thjesht\u00eb p\u00ebr t'u realizuar. Q\u00eb do t\u00eb thot\u00eb, n\u00eb thelb duhet thjesht t\u00eb shkruajm\u00eb numrin e versionit n\u00eb tabel\u00eb dhe m\u00eb pas t\u00eb shkruajm\u00eb: versioni \u00ebsht\u00eb m\u00eb i vog\u00ebl se ky i till\u00eb. Dhe kjo do t\u00eb thot\u00eb se, shum\u00eb mund\u00ebsisht, ne do ta propozojm\u00eb k\u00ebt\u00eb p\u00ebr entuziast\u00ebt. A jeni entuziast? <\/p>\n
<\/p>\n
Po, por, p\u00ebr fat t\u00eb keq, jo n\u00eb C++.<\/em><\/p>\n<\/p>\n
A din\u00eb koleg\u00ebt tuaj t\u00eb shkruajn\u00eb n\u00eb C++? <\/p>\n
<\/p>\n
Do t\u00eb gjej dik\u00eb.<\/em><\/p>\n<\/p>\n
Shum\u00eb mir\u00eb.<\/p>\n
<\/p>\n
* mund\u00ebsia u shtua dy muaj pas raportit \u2013 krijuesi i saj e zhvilloi at\u00eb dhe e d\u00ebrgoi vet\u00eb pull request<\/a><\/noindex>.<\/p>\n<\/p>\n
Faleminderit!<\/em><\/p>\n<\/p>\n
P\u00ebrsh\u00ebndetje! Faleminderit p\u00ebr raportin! Ju p\u00ebrmend\u00ebt se ClickHouse konsumon shum\u00eb mir\u00eb t\u00eb gjitha burimet q\u00eb i jan\u00eb ofruar. Dhe fol\u00ebsi fqinj me Luxoft tregoi p\u00ebr zgjidhjen e tij p\u00ebr Post\u00ebn e Rusis\u00eb. Ai tha se ata e p\u00eblqyen shum\u00eb ClickHouse, por nuk e p\u00ebrdor\u00ebn at\u00eb n\u00eb vend t\u00eb konkurrentit t\u00eb tyre kryesor pik\u00ebrisht sepse ai konsumonte gjith\u00eb procesorin. Dhe ata nuk mund\u00ebn ta inkorporonin n\u00eb arkitektur\u00ebn e tyre, n\u00eb ZooKeeper-in e tyre me docker-at. A ka ndonj\u00eb mund\u00ebsi p\u00ebr ta kufizuar ClickHouse, q\u00eb t\u00eb mos konsumoj\u00eb gjith\u00e7ka q\u00eb i b\u00ebhet e aksesueshme?<\/em><\/p>\n<\/p>\n
Po, \u00ebsht\u00eb shum\u00eb e leht\u00eb. N\u00ebse d\u00ebshironi q\u00eb t\u00eb konsumoni m\u00eb pak b\u00ebrthama, thjesht shkruani set max_threads = 1<\/code>. Dhe k\u00ebshtu, do t\u00eb ekzekutoj\u00eb k\u00ebrkes\u00ebn n\u00eb nj\u00eb b\u00ebrtham\u00eb. Gjithashtu, mund t'i jepen konfigurime t\u00eb ndryshme p\u00ebrdoruesve t\u00eb ndrysh\u00ebm. Prandaj nuk ka asnj\u00eb problem. Dhe p\u00ebr koleg\u00ebt nga Luxoft, kaloni se nuk ishte mir\u00eb q\u00eb ata nuk e gjet\u00ebn k\u00ebt\u00eb konfigurim n\u00eb dokumentacion. <\/p>\n<\/p>\n
Alex, p\u00ebrsh\u00ebndetje! Doja t\u00eb pyesja p\u00ebr nj\u00eb \u00e7\u00ebshtje. Nuk \u00ebsht\u00eb hera e par\u00eb q\u00eb d\u00ebgjoj se shum\u00eb po fillojn\u00eb ta p\u00ebrdorin ClickHouse si nj\u00eb depo p\u00ebr log\u00ebt. N\u00eb prezantimin tuaj thoshit se nuk duhet b\u00ebr\u00eb k\u00ebshtu, pra nuk duhet t\u00eb ruajm\u00eb vargje t\u00eb gjata. Si e mendoni k\u00ebt\u00eb?<\/em><\/p>\n<\/p>\n
S\u00eb pari, log\u00ebt zakonisht nuk jan\u00eb vargje t\u00eb gjata. Sigurisht, ndodhin p\u00ebrjashtime. P.sh., ndonj\u00eb sh\u00ebrbim i shkruar n\u00eb java hedh nj\u00eb exception q\u00eb log-izohet. Dhe k\u00ebshtu n\u00eb nj\u00eb cik\u00ebl t\u00eb pafund, dhe p\u00ebrfundojm\u00eb pa hap n\u00eb hard disk. Zgjidhja \u00ebsht\u00eb shum\u00eb e thjesht\u00eb. N\u00ebse vargjet jan\u00eb shum\u00eb t\u00eb gjata, prini ato. Dhe \u00e7far\u00eb do t\u00eb thot\u00eb t\u00eb gjata? Dhjet\u00ebra kilobajt \u00ebsht\u00eb e keqe.<\/p>\n
<\/p>\n
* \u0432 \u0441\u0432\u0435\u0436\u0438\u0445 \u0432\u0435\u0440\u0441\u0438\u044f\u0445 ClickHouse, \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0430 "\u0430\u0434\u0430\u043f\u0442\u0438\u0432\u043d\u0430\u044f \u0433\u0440\u0430\u043d\u0443\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u044c \u0438\u043d\u0434\u0435\u043a\u0441\u0430", \u0447\u0442\u043e \u0441\u043d\u0438\u043c\u0430\u0435\u0442 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0434\u043b\u0438\u043d\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a \u043f\u043e \u0431\u043e\u043b\u044c\u0448\u0435\u0439 \u0447\u0430\u0441\u0442\u0438.<\/p>\n
<\/p>\n
Dhe kilobajt \u2013 a \u00ebsht\u00eb e pranueshme?<\/em><\/p>\n<\/p>\n
E pranueshme. <\/p>\n
<\/p>\n
P\u00ebrsh\u00ebndetje! Faleminderit p\u00ebr prezantimin! Un\u00eb tashm\u00eb kam pyetur p\u00ebr k\u00ebt\u00eb n\u00eb bised\u00eb, por nuk e mbaj mend n\u00ebse kam marr\u00eb p\u00ebrgjigje. A planifikohet ndonj\u00ebher\u00eb t\u00eb zgjerohet seksioni WITH, si CTE?<\/em><\/p>\n<\/p>\n
P\u00ebr momentin jo. Seksioni WITH \u00ebsht\u00eb disi jo serioz. Ai \u00ebsht\u00eb si nj\u00eb tipar i vog\u00ebl.<\/p>\n
<\/p>\n
E kuptoj. Faleminderit!<\/em><\/p>\n<\/p>\n
Faleminderit p\u00ebr raportin! Shum\u00eb interesant! Nj\u00eb pyetje globale. A po planifikohet ndonj\u00eb modifikim p\u00ebr fshirjen e t\u00eb dh\u00ebnave, ndoshta n\u00eb form\u00ebn e ndonj\u00eb skeme?<\/em><\/p>\n<\/p>\n
Sigurisht. Kjo \u00ebsht\u00eb detyra jon\u00eb e par\u00eb n\u00eb radh\u00ebn ton\u00eb. Tani kemi menduar aktivisht se si ta b\u00ebjm\u00eb gjith\u00e7ka si\u00e7 duhet. Dhe \u00ebsht\u00eb koha t\u00eb fillojm\u00eb t\u00eb shtypim butonat n\u00eb tastier\u00eb*.<\/p>\n
<\/p>\n
* e kemi shtypur \u00e7do buton n\u00eb tastier\u00eb dhe gjith\u00e7ka \u00ebsht\u00eb b\u00ebr\u00eb.<\/p>\n
<\/p>\n
A do t\u00eb ndikoj\u00eb kjo ndonj\u00ebher\u00eb n\u00eb performanc\u00ebn e sistemit apo jo? Do t\u00eb jet\u00eb i nj\u00ebjt\u00eb q\u00ebndrimi i sot\u00ebm p\u00ebr inserimin?<\/em><\/p>\n<\/p>\n
Mund t\u00eb ndodh\u00eb q\u00eb vet\u00eb deletimet, vet\u00eb azhurnimet, t\u00eb jen\u00eb shum\u00eb t\u00eb r\u00ebnda, por kjo nuk do t\u00eb ndikoj\u00eb aspak n\u00eb performanc\u00ebn e seleksioneve dhe performanc\u00ebn e inserimeve.<\/p>\n
<\/p>\n
Dhe nj\u00eb pyetje e vog\u00ebl. N\u00eb prezantim p\u00ebrmend\u00ebt \u00e7el\u00ebsin kryesor. Prandaj, ne kemi nj\u00eb ndarjen q\u00eb \u00ebsht\u00eb p\u00ebr default mujore, e sakt\u00eb? Dhe kur vendosim nj\u00eb interval datash q\u00eb p\u00ebrfshihet n\u00eb muaj, at\u00ebher\u00eb vet\u00ebm ajo ndarje do t\u00eb lexohet, e v\u00ebrtet\u00eb?<\/em><\/p>\n<\/p>\n
Po.<\/p>\n
<\/p>\n
Nj\u00eb pyetje. N\u00ebse nuk mund t\u00eb dalim me ndonj\u00eb \u00e7el\u00ebs kryesor, a \u00ebsht\u00eb e sakt\u00eb ta b\u00ebjm\u00eb at\u00eb pik\u00ebrisht sipas fush\u00ebs 'Data', p\u00ebr t\u00eb patur nj\u00eb ristrukturim m\u00eb t\u00eb vog\u00ebl t\u00eb k\u00ebtyre t\u00eb dh\u00ebnave n\u00eb sfond, n\u00eb m\u00ebnyr\u00eb q\u00eb ato t\u00eb jen\u00eb m\u00eb t\u00eb organizuara? N\u00ebse nuk keni k\u00ebrkesa diapazoni dhe madje nuk mund t\u00eb zgjidhni asnj\u00eb \u00e7el\u00ebs kryesor, a ka kuptim t\u00eb v\u00ebm\u00eb dat\u00ebn n\u00eb \u00e7el\u00ebsin kryesor?<\/em><\/p>\n<\/p>\n
Po.<\/p>\n
<\/p>\n
Ndoshta ka kuptim t\u00eb vendosni nj\u00eb fush\u00eb n\u00eb \u00e7el\u00ebsin kryesor p\u00ebr t\u00eb cil\u00ebn t\u00eb dh\u00ebnat do t\u00eb comprimohen m\u00eb mir\u00eb, n\u00ebse ato jan\u00eb t\u00eb renditura sipas asaj fushe. P\u00ebr shembull, identifikuesi i p\u00ebrdoruesit. P\u00ebrdoruesi, p\u00ebr shembull, viziton t\u00eb nj\u00ebjtin faqe. N\u00eb k\u00ebt\u00eb rast, vendosni ID-n\u00eb e p\u00ebrdoruesit dhe koh\u00ebn. K\u00ebshtu, t\u00eb dh\u00ebnat tuaja do t\u00eb comprimohen m\u00eb mir\u00eb. Sa i p\u00ebrket dat\u00ebs, n\u00ebse me t\u00eb v\u00ebrtet\u00eb nuk keni dhe kurr\u00eb nuk keni k\u00ebrkesa diapazoni p\u00ebr datat, at\u00ebher\u00eb nuk \u00ebsht\u00eb e nevojshme ta vendosni dat\u00ebn n\u00eb \u00e7el\u00ebsin kryesor. <\/p>\n
<\/p>\n
Mir\u00eb, faleminderit shum\u00eb!<\/em><\/p>\nBurimi: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"P\u00ebrdorimi](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n