func\u021bia de tabel input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
O alt\u0103 antipattern este microsharding. De exemplu, trebuie s\u0103 shard-ui\u021bi datele \u0219i ave\u021bi 5 servere, iar m\u00e2ine vor fi 6 servere. \u0218i v\u0103 g\u00e2ndi\u021bi cum s\u0103 reechilibra\u021bi aceste date. \u0218i \u00een loc s\u0103 le \u00eemp\u0103r\u021bi\u021bi \u00een 5 sharding-uri, le \u00eemp\u0103r\u021bi\u021bi \u00een 1 000 sharding-uri. Apoi, fiecare dintre aceste microsharding-uri este mapat pe un server separat. \u0218i, de exemplu, pe un singur server ve\u021bi avea 200 ClickHouse, fiecare instan\u021b\u0103 pe porturi separate sau baze de date separate. <\/p>\n
<\/p>\n
<\/p>\n
Dar \u00een ClickHouse, acest lucru nu este foarte bine. Deoarece chiar \u0219i o singur\u0103 instan\u021b\u0103 ClickHouse \u00eencearc\u0103 s\u0103 utilizeze toate resursele disponibile ale serverului pentru a procesa o singur\u0103 interogare. Adic\u0103, ave\u021bi un server care, de exemplu, dispune de 56 de nuclee de procesor. Rula\u021bi o interogare care dureaz\u0103 o secund\u0103 \u0219i va utiliza cele 56 de nuclee. Iar dac\u0103 a\u021bi plasat 200 ClickHouse pe un singur server, atunci vor fi lansate 10 000 de fire. \u00cen concluzie, totul va decurge foarte prost.<\/p>\n
<\/p>\n
O alt\u0103 cauz\u0103 este c\u0103 distribu\u021bia muncii \u00eentre aceste instan\u021be va fi inegal\u0103. Unele vor termina mai devreme, altele mai t\u00e2rziu. Dac\u0103 totul ar avea loc \u00eentr-o singur\u0103 instan\u021b\u0103, ClickHouse ar \u0219ti cum s\u0103 distribuie corect datele \u00eentre fire. <\/p>\n
<\/p>\n
\u0218i \u00eenc\u0103 o cauz\u0103 este c\u0103 va exista interac\u021biune \u00eentre procesoare prin TCP. Datele vor trebui s\u0103 fie serializate, deserializate \u0219i acest num\u0103r mare de microsharding-uri este pur \u0219i simplu ineficient.<\/p>\n
<\/p>\n
<\/p>\n
O alt\u0103 antipattern, de\u0219i este greu de numit a\u0219a. Este un num\u0103r mare de pre-agregare.<\/p>\n
<\/p>\n
\u00cen general, pre-agregarea este o idee bun\u0103. A\u021bi avut un miliard de r\u00e2nduri, le-a\u021bi agregat \u0219i au devenit 1 000 de r\u00e2nduri, iar acum interogarea se execut\u0103 instantaneu. Totul este minunat. A\u0219a se poate face. \u0218i pentru asta, chiar \u0219i \u00een ClickHouse exist\u0103 un tip special de tabel AggregatingMergeTree, care face agregare incremental\u0103 pe m\u0103sur\u0103 ce datele sunt inserate. <\/p>\n
<\/p>\n
Dar exist\u0103 cazuri \u00een care crede\u021bi c\u0103 vom agrega datele astfel \u0219i \u00eenc\u0103 astfel. \u0218i \u00eentr-un departament vecin, nu vreau s\u0103 spun care, folosesc tabelele SummingMergeTree pentru a suma dup\u0103 cheia primar\u0103, iar ca cheie primar\u0103 utilizeaz\u0103 vreo 20 de coloane. Am schimbat numele unor coloane pentru a p\u0103stra confiden\u021bialitatea, dar cam a\u0219a este.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i apar astfel de probleme. \u00cen primul r\u00e2nd, volumul de date nu se reduce prea mult. De exemplu, se reduce de trei ori. De trei ori \u2013 ar fi fost un pre\u021b bun pentru a avea posibilit\u0103\u021bi nelimitate pentru analiz\u0103, care apar atunci c\u00e2nd datele nu sunt agregate. Dac\u0103 datele sunt agregate, atunci \u00een loc de analiz\u0103 ob\u021bine\u021bi doar o statistic\u0103 lamentabil\u0103. <\/p>\n
<\/p>\n
\u0218i ce deranjeaz\u0103 \u00een special? C\u0103 ace\u0219ti oameni din departamentul vecin vin \u0219i cer uneori s\u0103 adauge \u00eenc\u0103 o coloan\u0103 \u00een cheia primar\u0103. Adic\u0103, am agregat datele astfel, iar acum vrem pu\u021bin mai mult. Dar \u00een ClickHouse nu exist\u0103 alterare a cheii primare. A\u0219a c\u0103 trebuie s\u0103 scriem diverse scripturi \u00een C++. \u0218i nu \u00eemi plac scripturile, nici m\u0103car cele \u00een C++.<\/p>\n
<\/p>\n
\u0218i dac\u0103 ne uit\u0103m pentru ce a fost creat ClickHouse, datele neagregate sunt exact scenariul pentru care a fost conceput. Dac\u0103 folosi\u021bi ClickHouse pentru date neagregate, face\u021bi totul corect. Dac\u0103 agrega\u021bi, atunci este uneori iertabil. <\/p>\n
<\/p>\n
<\/p>\n
O alt\u0103 situa\u021bie interesant\u0103 este cererile \u00eentr-un ciclu infinit. Uneori intru pe un server de produc\u021bie \u0219i m\u0103 uit la show processlist. \u0218i de fiecare dat\u0103 descop\u0103r c\u0103 se \u00eent\u00e2mpl\u0103 ceva teribil. <\/p>\n
<\/p>\n
De exemplu, a\u0219a. Aici este clar c\u0103 totul putea fi executat \u00eentr-o singur\u0103 cerere. Pur \u0219i simplu scrie\u021bi acolo url in \u0219i lista.<\/p>\n
<\/p>\n
<\/p>\n
De ce sunt at\u00e2t de multe cereri \u00eentr-un ciclu infinit \u2013 este r\u0103u? Dac\u0103 indexul nu este folosit, ve\u021bi avea multe treceri prin acelea\u0219i date. Dar dac\u0103 indexul este folosit, de exemplu, ave\u021bi o cheie primar\u0103 pe ru \u0219i scrie\u021bi url = ceva anume. \u0218i crede\u021bi c\u0103 va fi citit din tabel un singur url, va fi totul \u00een regul\u0103. Dar de fapt nu este a\u0219a. Pentru c\u0103 ClickHouse face totul pe grupuri. <\/p>\n
<\/p>\n
C\u00e2nd trebuie s\u0103 citeasc\u0103 un anumit interval de date, cite\u0219te pu\u021bin mai mult, deoarece indexul \u00een ClickHouse este sparse. Acest index nu permite g\u0103sirea unei singure linii \u00een tabel, ci doar a unui anumit interval. Iar datele sunt comprimate pe blocuri. Pentru a citi o linie, trebuie s\u0103 iei \u00eentregul bloc \u0219i s\u0103-l decomprimi. \u0218i dac\u0103 face\u021bi o mul\u021bime de interog\u0103ri, ve\u021bi avea multe suprapuneri \u0219i o mul\u021bime de munc\u0103 va fi efectuat\u0103 din nou \u0219i din nou.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i ca bonus, se poate observa c\u0103 \u00een ClickHouse nu trebuie s\u0103 v\u0103 fie fric\u0103 s\u0103 transmite\u021bi chiar \u0219i megabyte \u0219i sute de megabyte \u00een sec\u021biunea IN. \u00cemi amintesc din practica noastr\u0103 c\u0103, dac\u0103 \u00een MySQL transmitem o mul\u021bime de valori \u00een sec\u021biunea IN, de exemplu, 100 de megabytes de numere, MySQL consum\u0103 10 gigabytes de memorie \u0219i nimic mai mult nu se \u00eent\u00e2mpl\u0103, totul func\u021bioneaz\u0103 prost. <\/p>\n
<\/p>\n
Iar al doilea aspect este c\u0103, \u00een ClickHouse, dac\u0103 interog\u0103rile dvs. folosesc indexul, atunci aceasta nu este niciodat\u0103 mai lent dec\u00e2t o scanare complet\u0103, adic\u0103, dac\u0103 trebuie s\u0103 citi\u021bi aproape \u00eentregul tabel, acesta va merge secven\u021bial \u0219i va citi \u00eentregul tabel. \u00cen general, se va descurca singur.<\/p>\n
<\/p>\n
Dar totu\u0219i exist\u0103 unele dificult\u0103\u021bi. De exemplu, faptul c\u0103 IN cu subinterogarea nu folose\u0219te indexul. Dar aceasta este problema noastr\u0103 \u0219i trebuie s\u0103 o corect\u0103m. Nu este nimic fundamental aici. O s\u0103 repar\u0103m. <\/p>\n
<\/p>\n
Iar o alt\u0103 chestiune interesant\u0103 este c\u0103, dac\u0103 ave\u021bi o interogare foarte lung\u0103 \u0219i procesarea distribuit\u0103 a interog\u0103rilor are loc, atunci aceast\u0103 interogare foarte lung\u0103 va fi trimis\u0103 pe fiecare server f\u0103r\u0103 compresie. De exemplu, 100 de megabytes \u0219i 500 de servere. \u0218i, \u00een consecin\u021b\u0103, 50 de gigabytes vor fi transmise prin re\u021bea. Va fi transmis \u0219i apoi totul se va finaliza cu succes.<\/p>\n
<\/p>\n
* deja folose\u0219te; totul a fost reparat, a\u0219a cum am promis.<\/p>\n
<\/p>\n
<\/p>\n
\u0218i este un caz destul de frecvent ca interog\u0103rile s\u0103 vin\u0103 din API. De exemplu, a\u021bi creat un serviciu propriu. \u0218i dac\u0103 serviciul dvs. este necesar cuiva, a\u021bi deschis API-ul \u0219i, aproape imediat, dup\u0103 dou\u0103 zile vede\u021bi c\u0103 se \u00eent\u00e2mpl\u0103 ceva neclar. Totul este supra\u00eenc\u0103rcat \u0219i vin unele interog\u0103ri teribile care nu ar fi trebuit s\u0103 existe niciodat\u0103. <\/p>\n
<\/p>\n
\u0218i solu\u021bia aici este una. Dac\u0103 a\u021bi deschis API-ul, va trebui s\u0103-l restric\u021biona\u021bi. De exemplu, s\u0103 introduce\u021bi ni\u0219te cote. Nu exist\u0103 alte op\u021biuni normale. Altfel, imediat vor scrie un script \u0219i vor ap\u0103rea probleme. <\/p>\n
<\/p>\n
\u0218i ClickHouse are o capacitate special\u0103 \u2013 calcularea cotelor. De asemenea, po\u021bi transmite cheia ta de cot\u0103. De exemplu, un identificator intern al utilizatorului. \u0218i cotele vor fi calculate independent pentru fiecare dintre ele. <\/p>\n
<\/p>\n
<\/p>\n
Acum, un alt lucru interesant. Este replicarea manual\u0103. <\/p>\n
<\/p>\n
\u0218tiu multe cazuri \u00een care, de\u0219i ClickHouse are suport \u00eencorporat pentru replicare, oamenii replic\u0103 ClickHouse manual.<\/p>\n
<\/p>\n
Care este principiul? Ai un pipeline de procesare a datelor. \u0218i func\u021bioneaz\u0103 independent, de exemplu, \u00een centre de date diferite. Scrii acelea\u0219i date \u00een acela\u0219i mod \u00een ClickHouse. Totu\u0219i, practica arat\u0103 c\u0103 datele tot vor diverge din cauza anumitor particularit\u0103\u021bi din codul t\u0103u. Sper c\u0103 nu \u00eei ai. <\/p>\n
<\/p>\n
\u0218i periodic va trebui s\u0103 sincronizezi manual. De exemplu, o dat\u0103 pe lun\u0103, administratorii fac rsync.<\/p>\n
<\/p>\n
De fapt, este mult mai simplu s\u0103 folose\u0219ti replicarea \u00eencorporat\u0103 \u00een ClickHouse. Dar aici pot exista unele contraindica\u021bii, deoarece pentru asta trebuie s\u0103 folose\u0219ti ZooKeeper. Nu am nimic r\u0103u de spus despre ZooKeeper; \u00een principiu, sistemul func\u021bioneaz\u0103, dar uneori oamenii nu \u00eel folosesc din cauza fobiei de Java, deoarece ClickHouse este un sistem bun, scris \u00een C++, care poate fi utilizat \u0219i va func\u021biona excelent. Iar ZooKeeper este pe Java. \u0218i cumva, nici nu vrei s\u0103 te ui\u021bi, dar po\u021bi folosi replicarea manual\u0103. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse este un sistem practic. Ia \u00een considerare nevoile tale. Dac\u0103 ai replicare manual\u0103, po\u021bi crea o tabel\u0103 Distribuit\u0103 care se uit\u0103 la replicile tale manuale \u0219i face failover \u00eentre ele. Exist\u0103 chiar \u0219i o op\u021biune special\u0103 care permite evitarea flapping-urilor, chiar dac\u0103 replicile tale deviaz\u0103 sistematic.<\/p>\n
<\/p>\n
<\/p>\n
Apoi pot ap\u0103rea probleme dac\u0103 folose\u0219ti motoare de tabel primitive. ClickHouse este un constructor care are o mul\u021bime de motoare de tabele diferite. Pentru toate cazurile serioase, a\u0219a cum este scris \u00een documenta\u021bie, folose\u0219te tabele din familia MergeTree. Iar celelalte sunt doar pentru cazuri specifice sau pentru teste.<\/p>\n
<\/p>\n
\u00cen tabelul MergeTree nu este obligatoriu s\u0103 ai o dat\u0103 \u0219i o or\u0103. Po\u021bi folosi oricum. Dac\u0103 nu ai dat\u0103 \u0219i or\u0103, scrie c\u0103 default \u2013 2000. Aceasta va func\u021biona \u0219i nu va necesita resurse. <\/p>\n
<\/p>\n
\u00cen noua versiune a serverului, po\u021bi chiar s\u0103 specifici c\u0103 vrei o particionare personalizat\u0103 f\u0103r\u0103 o cheie de parti\u021bie. Va fi la fel. <\/p>\n
<\/p>\n
<\/p>\n
Pe de alt\u0103 parte, po\u021bi folosi motoare de tabele primitiv. De exemplu, po\u021bi \u00eenc\u0103rca datele o dat\u0103 \u0219i apoi s\u0103 le vizualizezi, s\u0103 le manipulezi \u0219i s\u0103 le \u0219tergi. Po\u021bi folosi Log.<\/p>\n
<\/p>\n
Sau stocarea unor cantit\u0103\u021bi mici pentru procesare intermediar\u0103 \u2013 este StripeLog sau TinyLog.<\/p>\n
<\/p>\n
Memory poate fi utilizat dac\u0103 ai o cantitate mic\u0103 de date \u0219i vrei doar s\u0103 manipulezi ceva \u00een RAM. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse nu prea-i place datele supranormalizate. <\/p>\n
<\/p>\n
Iat\u0103 un exemplu tipic. Este un num\u0103r uria\u0219 de URL-uri. Le-ai pus \u00eentr-un tabel adiacent. Apoi ai decis s\u0103 faci JOIN cu ele, dar nu va func\u021biona, de obicei, pentru c\u0103 ClickHouse suport\u0103 doar Hash JOIN. Dac\u0103 nu ai suficient\u0103 RAM pentru cantitatea de date cu care trebuie s\u0103 faci conexiuni, nu vei putea realiza JOIN-ul*. <\/p>\n
<\/p>\n
Dac\u0103 datele au o cardinalitate mare, nu te stresa, stocheaz\u0103-le \u00een form\u0103 denormalizat\u0103, URL-urile direct \u00een tabelul principal. <\/p>\n
<\/p>\n
* De acum, ClickHouse are \u0219i merge join, care func\u021bioneaz\u0103 \u00een condi\u021bii c\u00e2nd datele intermediare nu \u00eencap \u00een RAM. Dar aceasta este ineficient \u0219i recomandarea r\u0103m\u00e2ne valabil\u0103.<\/p>\n
<\/p>\n
<\/p>\n
\u00cenc\u0103 c\u00e2teva exemple, dar m\u0103 \u00eendoiesc dac\u0103 sunt anti-modele sau nu. <\/p>\n
<\/p>\n
\u00cen ClickHouse exist\u0103 un dezavantaj cunoscut. Nu suport\u0103 actualiz\u0103ri*. \u00centr-un fel, acesta este un lucru bun. Dac\u0103 ai date importante, de exemplu, contabilitate, nimeni nu le poate modifica, deoarece nu exist\u0103 actualiz\u0103ri.<\/p>\n
<\/p>\n
* suportul pentru update \u0219i delete \u00een mod batch este deja disponibil de mult timp.<\/p>\n
<\/p>\n
Dar exist\u0103 unele modalit\u0103\u021bi speciale care permit actualiz\u0103rile s\u0103 fie f\u0103cute ca \u0219i cum ar fi \u00een fundal. De exemplu, tabelele de tip ReplaceMergeTree. Ele fac actualiz\u0103ri \u00een timpul fuziunilor de fundal. Po\u021bi for\u021ba acest proces folosind optimize table. Dar nu face asta prea des, pentru c\u0103 va fi o rescriere complet\u0103 a parti\u021biei. <\/p>\n
<\/p>\n
JOIN-urile distribuite \u00een ClickHouse sunt, de asemenea, slab gestionate de planificatorul de interog\u0103ri. <\/p>\n
<\/p>\n
Slab, dar uneori acceptabil.<\/p>\n
<\/p>\n
Folosirea ClickHouse numai pentru a citi datele \u00eenapoi cu ajutorul select*.<\/p>\n
<\/p>\n
Nu a\u0219 recomanda utilizarea ClickHouse pentru calcule complexe. Totu\u0219i, lucrurile s-au schimbat pu\u021bin, deoarece ne \u00eendep\u0103rt\u0103m de aceast\u0103 recomandare. Recent, am ad\u0103ugat posibilitatea de a aplica modele de \u00eenv\u0103\u021bare automat\u0103 \u00een ClickHouse \u2013 Catboost. Acest lucru m\u0103 \u00eengrijoreaz\u0103, pentru c\u0103 m\u0103 g\u00e2ndesc: \u201eCe groaznic. C\u00e2te cicluri pe octet facem aici!\u201d. \u00cemi pare foarte r\u0103u s\u0103 risipesc cicluri pe octe\u021bi. <\/p>\n
<\/p>\n
<\/p>\n
Dar nu v\u0103 teme\u021bi, instala\u021bi ClickHouse, totul va fi bine. \u0218i dac\u0103 ave\u021bi probleme, ave\u021bi comunitatea noastr\u0103. Apropo, comunitatea sunte\u021bi voi. Dac\u0103 ave\u021bi vreo problem\u0103, pute\u021bi s\u0103 intra\u021bi \u00een chatul nostru \u0219i, sper, s\u0103 primi\u021bi ajutor. <\/p>\n
<\/p>\n
\u00centreb\u0103ri<\/p>\n
<\/p>\n
Mul\u021bumesc pentru prezentare! Unde pot face pl\u00e2ngere pentru c\u0103derea ClickHouse?<\/em><\/p>\n<\/p>\n
Pute\u021bi s\u0103 v\u0103 pl\u00e2nge\u021bi direct mie chiar acum. <\/p>\n
<\/p>\n
Recent am \u00eenceput s\u0103 folosesc ClickHouse. Imediat am c\u0103zut cli-ul.<\/em><\/p>\n<\/p>\n
A\u021bi avut noroc. <\/p>\n
<\/p>\n
Pu\u021bin mai t\u00e2rziu, am c\u0103zut serverul cu un select mic.<\/em><\/p>\n<\/p>\n
Ave\u021bi talent. <\/p>\n
<\/p>\n
Am deschis un bug pe GitHub, dar a fost ignorat.<\/em> <\/p>\n<\/p>\n
S\u0103 vedem. <\/p>\n
<\/p>\n
Alexey m-a adus cu viclenie la prezentare, promi\u021b\u00e2nd c\u0103 va vorbi despre cum \u00eenghesui\u021bi datele.<\/em><\/p>\n<\/p>\n
Foarte simplu. <\/p>\n
<\/p>\n
Asta am realizat \u00eenc\u0103 de ieri. Mai multe detalii.<\/em> <\/p>\n<\/p>\n
Nu sunt trucuri groaznice. Este pur \u0219i simplu o comprimare pe blocuri. Din default se folose\u0219te LZ4; se poate activa ZSTD*. Blocurile variaz\u0103 de la 64 de kilobyte la 1 megabyte.<\/p>\n
<\/p>\n
* exist\u0103 suport pentru codecuri specializate de comprimare care pot fi utilizate \u00een lan\u021b cu alte algoritmi.<\/p>\n
<\/p>\n
\u00cen blocuri sunt doar date brute?<\/em><\/p>\n<\/p>\n
Nu tocmai brute. Acolo sunt array-uri. Dac\u0103 ave\u021bi o coloan\u0103 numeric\u0103, numerele sunt stocate \u00eentr-un array unul dup\u0103 altul. <\/p>\n
<\/p>\n
\u00cen\u021beles.<\/em> <\/p>\n<\/p>\n
Alexey, exemplul pe care l-a\u021bi avut cu uniqExact pe adrese IP, adic\u0103 ceea ce a\u021bi spus c\u0103 uniqExact pe \u0219iruri se calculeaz\u0103 mai lent dec\u00e2t pe numere etc. \u0218i dac\u0103 aplic\u0103m un truc \u0219i facem conversia \u00een timpul citirii? Adic\u0103, a\u021bi spus c\u0103 pe disc nu se deosebe\u0219te prea mult. Dac\u0103 citim \u0219irurile de pe disc, facem conversia, atunci agregatele noastre vor fi mai rapide sau nu? Sau totu\u0219i nu vom c\u00e2\u0219tiga semnificativ aici? Mi se pare c\u0103 a\u021bi testat asta, dar dintr-un motiv oarecare nu a\u021bi men\u021bionat \u00een benchmark.<\/em> <\/p>\n<\/p>\n
Cred c\u0103 va fi mai lent dec\u00e2t f\u0103r\u0103 cast. \u00cen acest caz, adresa IP trebuie s\u0103 fie extras\u0103 din \u0219ir. Desigur, \u00een ClickHouse, parsarea adreselor IP este optimizat\u0103. Am \u00eencercat foarte mult, dar acolo ave\u021bi numerele scrise \u00een forma zecimal\u0103. Foarte incomod. Pe de alt\u0103 parte, func\u021bia uniqExact va func\u021biona mai lent pe \u0219iruri nu doar pentru c\u0103 sunt \u0219iruri, ci \u0219i pentru c\u0103 se alege o alt\u0103 specializare a algoritmului. \u0218irurile sunt procesate complet diferit.<\/p>\n
<\/p>\n
Dar dac\u0103 lu\u0103m un tip de date mai primitiv? De exemplu, am scris user id-ul, care este \u00een, l-am scris ca pe un \u0219ir \u0219i apoi l-am convertit, va fi mai distractiv sau nu?<\/em><\/p>\n<\/p>\n
M\u0103 \u00eendoiesc. Cred c\u0103 va fi chiar mai trist, pentru c\u0103, totu\u0219i, parsarea numerelor este o problem\u0103 serioas\u0103. Mi se pare c\u0103 acest coleg a avut chiar o prezentare despre c\u00e2t de greu este s\u0103 parsem numere \u00een forma zecimal\u0103, dar poate c\u0103 nu. <\/p>\n
<\/p>\n
Alexey, mul\u021bumesc foarte mult pentru prezentare! \u0218i, de asemenea, mul\u021bumesc pentru ClickHouse! Am o \u00eentrebare legat\u0103 de planuri. Exist\u0103 planuri pentru o func\u021bionalitate de actualizare a dic\u021bionarelor par\u021bial?<\/em><\/p>\n<\/p>\n
Adic\u0103, re\u00eenc\u0103rcare par\u021bial\u0103?<\/p>\n
<\/p>\n
Da-da. O posibilitate de a specifica acolo un c\u00e2mp MySQL, adic\u0103 de a actualiza dup\u0103, pentru a \u00eenc\u0103rca doar acele date, dac\u0103 dic\u021bionarul este foarte mare.<\/em><\/p>\n<\/p>\n
O caracteristic\u0103 foarte interesant\u0103. \u0218i, mi se pare, cineva a propus-o \u00een chat-ul nostru. Poate chiar a\u021bi fost dumneavoastr\u0103. <\/p>\n
<\/p>\n
Nu cred c\u0103 eu.<\/em><\/p>\n<\/p>\n
Excelent, acum se dovede\u0219te c\u0103 sunt dou\u0103 cereri. \u0218i putem \u00eencepe cu calm. Dar vreau s\u0103 v\u0103 avertizez imediat c\u0103 aceast\u0103 caracteristic\u0103 este destul de simpl\u0103 de implementat. Adic\u0103, \u00een principiu, trebuie doar s\u0103 scrie\u021bi un num\u0103r de versiune \u00een tabel \u0219i apoi s\u0103 scrie\u021bi: versiunea este mai mic\u0103 dec\u00e2t asta. \u0218i asta \u00eenseamn\u0103 c\u0103, cel mai probabil, vom propune s\u0103 facem asta entuzia\u0219tilor. Sunte\u021bi entuziast? <\/p>\n
<\/p>\n
Da, dar, din p\u0103cate, nu \u00een C++.<\/em><\/p>\n<\/p>\n
Colegul vostru \u0219tie s\u0103 scrie \u00een C++? <\/p>\n
<\/p>\n
O s\u0103 g\u0103sesc pe cineva.<\/em><\/p>\n<\/p>\n
Excelent*.<\/p>\n
<\/p>\n
* posibilitatea a fost ad\u0103ugat\u0103 la dou\u0103 luni dup\u0103 prezentare \u2013 a fost dezvoltat\u0103 de autorul \u00eentreb\u0103rii \u0219i trimis\u0103. pull request<\/a><\/noindex>.<\/p>\n<\/p>\n
Mul\u021bumesc!<\/em><\/p>\n<\/p>\n
Bun\u0103 ziua! V\u0103 mul\u021bumesc pentru prezentare! A\u021bi men\u021bionat c\u0103 ClickHouse consum\u0103 foarte bine toate resursele disponibile. Iar prezentatorul de l\u00e2ng\u0103 Luxoft a vorbit despre solu\u021bia sa pentru Po\u0219ta Rus\u0103. El a spus c\u0103 le-a pl\u0103cut foarte mult ClickHouse, dar nu l-au folosit \u00een locul principalului lor competitor tocmai pentru c\u0103 consuma tot procesorul. \u0218i nu au putut s\u0103-l integreze \u00een arhitectura lor, \u00een ZooKeeper-ul lor cu containere. Exist\u0103 vreo posibilitate de a limita somehow ClickHouse, astfel \u00eenc\u00e2t s\u0103 nu consume tot ce \u00eei devine disponibil?<\/em><\/p>\n<\/p>\n
Da, se poate \u0219i foarte u\u0219or. Dac\u0103 dori\u021bi s\u0103 consume mai pu\u021bine nuclee, pur \u0219i simplu scrie\u021bi set max_threads = 1<\/code>. \u0218i gata, va executa cererea pe un singur nucleu. De altfel, pute\u021bi specifica utilizatori diferi\u021bi pentru aceast\u0103 setare. A\u0219a c\u0103 nu sunt probleme. \u0218i colegilor de la Luxoft transmite\u021bi c\u0103 nu e bine c\u0103 nu au g\u0103sit aceast\u0103 setare \u00een documenta\u021bie. <\/p>\n<\/p>\n
Alexey, bun\u0103 ziua! A\u0219 dori s\u0103 \u00eentreb un astfel de lucru. Nu pentru prima dat\u0103 aud c\u0103 mul\u021bi \u00eencep s\u0103 foloseasc\u0103 ClickHouse ca depozit pentru loguri. La prezentare a\u021bi spus c\u0103 nu trebuie s\u0103 facem asta, adic\u0103 nu trebuie s\u0103 stoc\u0103m \u0219iruri lungi. Ce p\u0103rere ave\u021bi despre asta?<\/em><\/p>\n<\/p>\n
\u00cen primul r\u00e2nd, logurile nu sunt, de obicei, \u0219iruri lungi. Exist\u0103, desigur, excep\u021bii. De exemplu, un serviciu scris \u00een Java arunc\u0103 excep\u021bii, care sunt \u00eenregistrate. \u0218i a\u0219a \u00eentr-un ciclu infinit, termin\u00e2nd spa\u021biul pe discul dur. Solu\u021bia este foarte simpl\u0103. Dac\u0103 \u0219irurile sunt foarte lungi, atunci t\u0103ia\u021bi-le. Ce \u00eenseamn\u0103 lungi? Zecile de kilobi\u021bi \u2013 aceasta este o problem\u0103.*<\/p>\n
<\/p>\n
* \u00een versiunile recente ale ClickHouse, a fost inclus\u0103 "granularitatea adaptiv\u0103 a indexului", ceea ce rezolv\u0103 problema stoc\u0103rii \u0219irurilor lungi \u00een cea mai mare parte.<\/p>\n
<\/p>\n
Dar un kilobit este ok?<\/em><\/p>\n<\/p>\n
Ok. <\/p>\n
<\/p>\n
Bun\u0103 ziua! V\u0103 mul\u021bumesc pentru prezentare! Am \u00eentrebat deja despre asta \u00een chat, dar nu-mi amintesc dac\u0103 am primit un r\u0103spuns. Se planific\u0103 extinderea sec\u021biunii WITH \u00een stil CTE?<\/em><\/p>\n<\/p>\n
Deocamdat\u0103 nu. Sec\u021biunea WITH este oarecum neserioas\u0103. Este o caracteristic\u0103 mic\u0103.<\/p>\n
<\/p>\n
Am \u00een\u021beles. Mul\u021bumesc!<\/em><\/p>\n<\/p>\n
V\u0103 mul\u021bumesc pentru prezentare! Foarte interesant! O \u00eentrebare global\u0103. Se planific\u0103 s\u0103 facem, poate, o modificare a elimin\u0103rii datelor sub form\u0103 de anumite stub-uri?<\/em><\/p>\n<\/p>\n
Cu siguran\u021b\u0103. Aceasta este prima noastr\u0103 sarcin\u0103 pe lista noastr\u0103. Acum ne g\u00e2ndim activ la cum s\u0103 facem totul corect. \u0218i ar trebui s\u0103 \u00eencepem s\u0103 ap\u0103s\u0103m pe tastatur\u0103*.<\/p>\n
<\/p>\n
* am ap\u0103sat taste pe tastatur\u0103 \u0219i am f\u0103cut totul.<\/p>\n
<\/p>\n
Va afecta asta cumva performan\u021ba sistemului sau nu? Inserarea va fi la fel de rapid\u0103 ca acum?<\/em><\/p>\n<\/p>\n
Poate c\u0103 delete-urile \u0219i update-urile \u00een sine vor fi foarte grele, dar asta nu va afecta performan\u021ba select-urilor \u0219i performan\u021ba insert-urilor.<\/p>\n
<\/p>\n
\u0218i \u00eenc\u0103 o \u00eentrebare mic\u0103. La prezentare a\u021bi vorbit despre cheia primar\u0103. Deci, avem parti\u021bionare care, implicit, sunt lunare, corect? \u0218i c\u00e2nd definim un interval de date care se \u00eencadreaz\u0103 \u00eentr-o lun\u0103, atunci se cite\u0219te doar aceast\u0103 parti\u021bie, nu-i a\u0219a?<\/em><\/p>\n<\/p>\n
Da.<\/p>\n
<\/p>\n
Am o \u00eentrebare. Dac\u0103 nu putem identifica o cheie primar\u0103, este corect s\u0103 o facem pe baza c\u00e2mpului \u201eDat\u0103\u201d pentru a reduce reorganizarea acestor date \u00een fundal, astfel \u00eenc\u00e2t s\u0103 fie mai ordonate? Dac\u0103 nu ave\u021bi cereri pe baze de interval \u0219i niciun fel de cheie primar\u0103, merit\u0103 s\u0103 includem data \u00een cheia primar\u0103?<\/em><\/p>\n<\/p>\n
Da.<\/p>\n
<\/p>\n
Poate c\u0103 are sens s\u0103 incluzi \u00een cheia primar\u0103 un c\u00e2mp pe baza c\u0103ruia datele se vor comprima mai bine, dac\u0103 acestea sunt sortate dup\u0103 acest c\u00e2mp. De exemplu, identificatorul utilizatorului. Utilizatorul, de exemplu, acceseaz\u0103 acela\u0219i site. \u00cen acest caz, incluzi id-ul utilizatorului \u0219i timpul. Astfel, datele tale se vor comprima mai bine. \u00cen ceea ce prive\u0219te data, dac\u0103 nu ave\u021bi \u0219i nu ve\u021bi avea niciodat\u0103 cereri pe interval de date, nu este nevoie s\u0103 include\u021bi data \u00een cheia primar\u0103. <\/p>\n
<\/p>\n
Bine, mul\u021bumesc mult!<\/em><\/p>\nSursa: 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
![\"Utilizarea](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n