{"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\/ro\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse pentru utilizatori avansa\u021bi \u00een \u00eentreb\u0103ri \u0219i r\u0103spunsuri","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>\u00cen aprilie, inginerii Avito s-au \u00eent\u00e2lnit la o sesiune online cu principalul dezvoltator ClickHouse, Alexei Milovidov \u0219i Kirill Shvakov, dezvoltator Golang de la compania Integros. Au discutat despre cum folosim sistemul de gestionare a bazelor de date \u0219i ce dificult\u0103\u021bi \u00eent\u00e2mpin\u0103m. <\/p>\n<p><\/p>\n<p>Pe baza \u00eent\u00e2lnirii, am adunat un articol cu r\u0103spunsuri de la exper\u021bi la \u00eentreb\u0103rile noastre \u0219i ale spectatorilor despre backup-uri, resharding de date, dic\u021bionare externe, driver Golang \u0219i actualizarea versiunilor ClickHouse. Acesta poate fi util dezvoltatorilor care lucreaz\u0103 deja activ cu SGBD-ul \u201eYandex\u201d \u0219i sunt interesa\u021bi de prezentul \u0219i viitorul s\u0103u. R\u0103spunsurile lui Alexei Milovidov sunt, prin default, dac\u0103 nu se specific\u0103 altceva. <\/p>\n<p><\/p>\n<p>Aten\u021bie, sub capac exist\u0103 mult text. Sper\u0103m c\u0103 con\u021binutul cu \u00eentreb\u0103rile v\u0103 va ajuta s\u0103 v\u0103 orienta\u021bi.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse pentru utilizatori avansa\u021bi \u00een \u00eentreb\u0103ri \u0219i r\u0103spunsuri\" 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\">Cuprins<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse se actualizeaz\u0103 constant, iar datele noastre \u2014 nu. Ce s\u0103 facem cu asta?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Care sunt cele mai bune practici de p\u00e2n\u0103 acum pentru backup-ul datelor din ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">Se va putea organiza o \u00eent\u00e2rzieri controlat\u0103 a replicilor \u00een valuri?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">Ce facem dac\u0103 structura tabelului s-a schimbat?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Care sunt cele mai bune practici actuale \u00een reshardingul de date?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">\u00cen ClickHouse exist\u0103 o utilitate numit\u0103 clickhouse-copier. Pute\u021bi s\u0103 ne vorbi\u021bi despre aceasta?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">A\u021bi avut un pilot numit resharding. Ce s-a \u00eent\u00e2mplat cu el?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">Se pot combina toate p\u0103r\u021bile datelor \u00eenainte de a fi mutate pe discuri lente?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Cum s\u0103 trec la versiuni noi ClickHouse, dac\u0103 nu am posibilitatea de a verifica dinainte compatibilitatea?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">Kill query ar trebui s\u0103 opreasc\u0103 interog\u0103rile, dar nu o face. De ce?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Cum se calculeaz\u0103 timpul de r\u0103spuns \u00een condi\u021bii de \u00eenc\u0103rcare la citire?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Ce trebuie s\u0103 ajustez \u00een ClickHouse astfel \u00eenc\u00e2t mai multe date s\u0103 fie \u00een cache?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Cum putem configura storage_configuration pentru stocare \u00een memorie?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">P\u00e2n\u0103 la ce num\u0103r de valori unice este eficient Low Cardinality?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Care sunt cele mai bune practici pentru c\u0103utarea complet\u0103 \u00eentr-un tabel cu cinci miliarde de r\u00e2nduri?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Cum s\u0103 organizez accesul \u00een ClickHouse pentru un num\u0103r mare de utilizatori?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">Este posibil s\u0103 trimitem rezultatele unei interog\u0103ri la zece clien\u021bi?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Cum gestion\u0103m opera\u021biunile asincrone \u0219i vederile materializate?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">\u00cen ClickHouse sunt multe jurnale. Cum pot vedea tot ce se \u00eent\u00e2mpl\u0103 cu serverul \u00een acel moment?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Cum pot influen\u021ba fuziunile astfel \u00eenc\u00e2t serverul s\u0103 nu cedeze \u00een OOM?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Cum va decurge dezvoltarea driver-ului Golang pentru ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">Dic\u021bionarul extern nu se \u00eencarc\u0103 dup\u0103 repornire cu setarea lazy_load activat\u0103. Ce s\u0103 fac?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Cum s\u0103 procedez c\u00e2nd system reload dictionaries nu \u00eencarc\u0103 niciunul dintre numeroasele dic\u021bionare, dac\u0103 m\u0103car unul dintre ele e\u0219ueaz\u0103 cu o eroare?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Exist\u0103 vreo metod\u0103 de a configura datele \u00een config-ul ClickHouse, dar s\u0103 nu le expunem \u00een caz de erori?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus: fundaluri pentru Zoom de la petreceri<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Dac\u0103 nu dori\u021bi s\u0103 citi\u021bi textul, pute\u021bi viziona \u00eenregistrarea \u00eent\u00e2lnirilor <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">pe canalul nostru de YouTube<\/a><\/noindex>. Timpurile sunt \u00een primul comentariu de sub videoclip.<\/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 actualizeaz\u0103 constant, \u00eens\u0103 datele noastre nu. Ce ar trebui s\u0103 facem \u00een aceast\u0103 situa\u021bie?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse se actualizeaz\u0103 constant, dar datele noastre, care au fost procesate cu optimize final, nu se actualizeaz\u0103 \u0219i sunt p\u0103strate \u00een backup. <\/p>\n<p>S\u0103 presupunem c\u0103 am avut vreo problem\u0103 \u0219i datele au fost pierdute. Am decis s\u0103 ne recuper\u0103m \u0219i s-a dovedit c\u0103 vechile parti\u021bii, care sunt p\u0103strate pe serverele de backup, difer\u0103 foarte mult de versiunea ClickHouse utilizat\u0103 \u00een prezent. Ce ar trebui s\u0103 facem \u00een aceast\u0103 situa\u021bie \u0219i este aceasta posibil\u0103?<\/p><\/blockquote>\n<p>Situa\u021bia \u00een care a\u021bi recuperat date dintr-un backup \u00een format vechi, iar pe noua versiune acestea nu se conecteaz\u0103, nu este posibil\u0103. Ne asigur\u0103m c\u0103 formatul datelor \u00een ClickHouse r\u0103m\u00e2ne \u00eentotdeauna compatibil \u00eenapoi. Acest lucru este mult mai important dec\u00e2t compatibilitatea \u00eenapoi pe func\u021bionalitate, dac\u0103 comportamentul unei func\u021bii rare a fost modificat. Datele stocate pe disc trebuie s\u0103 fie citite \u00eentotdeauna de noua versiune ClickHouse. Aceasta este legea. <\/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>Care sunt cele mai bune practici de p\u00e2n\u0103 acum pentru backup-ul datelor din ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Cum s\u0103 facem backup-uri av\u00e2nd \u00een vedere c\u0103 avem opera\u021biuni optimize finale, o baz\u0103 de date enorm\u0103 de terabytes \u0219i datele care se actualizeaz\u0103, presupun\u00e2nd, \u00een ultimele trei zile, iar apoi nu se \u00eent\u00e2mpl\u0103 alte proceduri cu ele? <\/p>\n<p>Putem scrie o solu\u021bie personalizat\u0103 \u0219i \u00een bash s\u0103 specific\u0103m: adun\u0103 astfel \u0219i astfel aceste backup-uri. Poate c\u0103 nu este nevoie s\u0103 facem nimic complicat, poate c\u0103 bicicleta a fost deja inventat\u0103? <\/p><\/blockquote>\n<p>Pentru \u00eenceput, cu privire la cele mai bune practici. Colegii mei \u00eentotdeauna recomand\u0103, \u00een r\u0103spunsul la \u00eentreb\u0103rile despre backup-uri, s\u0103 men\u021bioneze serviciul \u201eYandex.Cloud\u201d, unde aceast\u0103 problem\u0103 este deja rezolvat\u0103. A\u0219adar, folosi\u021bi-l, dac\u0103 ave\u021bi aceast\u0103 op\u021biune. <\/p>\n<p><\/p>\n<p>Nu exist\u0103 o solu\u021bie complet\u0103, 100% integrat\u0103 \u00een ClickHouse, pentru backup-uri. Exist\u0103 c\u00e2teva \u0219abloane care pot fi utilizate. Pentru a ob\u021bine o solu\u021bie complet\u0103, va trebui fie s\u0103 ne ocup\u0103m un pic manual, fie s\u0103 facem wrapper-uri sub form\u0103 de scripturi.<\/p>\n<p><\/p>\n<p>Voi \u00eencepe cu cele mai simple solu\u021bii \u0219i voi \u00eencheia cu cele mai complexe, \u00een func\u021bie de volumul de date \u0219i dimensiunea cluster-ului. Cu c\u00e2t cluster-ul este mai mare, cu at\u00e2t solu\u021bia devine mai complicat\u0103.<\/p>\n<p><\/p>\n<p>Dac\u0103 tabela cu date ocup\u0103 doar c\u00e2\u021biva gigaocte\u021bi, backup-ul se poate face astfel: <\/p>\n<p><\/p>\n<ol>\n<li>Salva\u021bi defini\u021bia tabelelor, adic\u0103 metadata \u2014 <strong>show create table<\/strong>.<\/li>\n<li>F\u0103 un dump folosind clientul ClickHouse \u2014 <strong>select<\/strong> * <strong>from table<\/strong> \u00eentr-un fi\u0219ier. \u00cen mod implicit, vei ob\u021bine un fi\u0219ier \u00een format TabSeparated. Dac\u0103 dore\u0219ti ceva mai eficient, po\u021bi alege formatul Native. <\/li>\n<\/ol>\n<p><\/p>\n<p>Dac\u0103 volumul de date este mai mare, backup-ul va dura mai mult \u0219i va ocupa mult spa\u021biu. Acesta se nume\u0219te backup logic, care nu este legat de formatul de date ClickHouse. Dac\u0103 exist\u0103, \u00een caz extrem, po\u021bi lua backup-ul \u0219i s\u0103 \u00eel \u00eencarci \u00een MySQL pentru recuperare. <\/p>\n<p><\/p>\n<p>Pentru cazuri mai avansate, ClickHouse ofer\u0103 posibilitatea de a crea un snapshot al parti\u021biilor \u00een sistemul de fi\u0219iere local. Aceast\u0103 func\u021bionalitate este disponibil\u0103 sub form\u0103 de interogare. <strong>alter table freeze partition<\/strong>. Sau simplu <strong>alter table freeze<\/strong> \u2014 acesta este un snapshot al \u00eentregului tabel. <\/p>\n<p><\/p>\n<p>Snapshot-ul va fi creat consistent pentru o singur\u0103 tabel\u0103 pe un singur shard, adic\u0103 nu este posibil s\u0103 creezi un snapshot consistent pentru \u00eentregul cluster \u00een acest mod. Dar pentru majoritatea sarcinilor, aceast\u0103 necesitate nu exist\u0103, iar este suficient s\u0103 execu\u021bi interogarea pe fiecare shard \u0219i s\u0103 ob\u021bii un snapshot consistent. Acesta este creat sub form\u0103 de hardlink-uri \u0219i, prin urmare, nu ocup\u0103 spa\u021biu suplimentar. Apoi, acest snapshot \u00eel copiezi pe serverul de backup sau \u00een depozitul pe care \u00eel folose\u0219ti pentru backup-uri.<\/p>\n<p><\/p>\n<p>Restaurarea unui astfel de backup este destul de u\u0219oar\u0103. \u00cen primul r\u00e2nd, creezi tabelele pe baza defini\u021biilor tabelului existente. Apoi, copiezi snapshot-urile salvate ale parti\u021biilor \u00een Directory-Detached pentru tabelele respective \u0219i execu\u021bi interogarea. <strong>attach partition<\/strong>Aceast\u0103 solu\u021bie este perfect potrivit\u0103 pentru volume foarte mari de date. <\/p>\n<p><\/p>\n<p>Uneori, este nevoie de ceva \u0219i mai avansat \u2014 \u00een cazul \u00een care ave\u021bi zeci sau chiar sute de terabi\u021bi pe fiecare server \u0219i sute de servere. Exist\u0103 o solu\u021bie pe care am observat-o la colegii mei de la \u201eYandex.Metrica\u201d. Nu a\u0219 recomanda-o tuturor \u2014 citi\u021bi \u0219i decide\u021bi singuri dac\u0103 este potrivit\u0103 sau nu. <\/p>\n<p><\/p>\n<p>Primul pas este s\u0103 crea\u021bi mai multe servere cu stoc\u0103ri mari de discuri. Apoi, pe aceste servere, s\u0103 ridica\u021bi mai multe servere ClickHouse \u0219i s\u0103 le configura\u021bi astfel \u00eenc\u00e2t s\u0103 func\u021bioneze ca o alt\u0103 replic\u0103 pentru acelea\u0219i sharduri. Apoi, folosi\u021bi pe aceste servere un sistem de fi\u0219iere sau un instrument care permite crearea de snapshot-uri. Exist\u0103 dou\u0103 op\u021biuni. Prima op\u021biune este snapshot-uri LVM, a doua op\u021biune este ZFS pe Linux. <\/p>\n<p><\/p>\n<p>Dup\u0103 aceea, trebuie s\u0103 crea\u021bi un snapshot \u00een fiecare zi, acesta va ocupa un loc. Evident, dac\u0103 datele se schimb\u0103, \u00een timp volumul de spa\u021biu va cre\u0219te. Acest snapshot poate fi accesat \u00een orice moment pentru a restaura datele, o solu\u021bie destul de ciudat\u0103. De asemenea, trebuie s\u0103 limit\u0103m aceste replici \u00een configura\u021bie, astfel \u00eenc\u00e2t s\u0103 nu \u00eencerce s\u0103 devin\u0103 lideri.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>Se va putea organiza o \u00eent\u00e2rzieri controlat\u0103 a replicilor \u00een valuri?<\/h2>\n<p><\/p>\n<blockquote><p>Anul acesta pl\u0103nui\u021bi s\u0103 face\u021bi valuri \u00een ClickHouse. Va fi posibil s\u0103 organiza\u021bi o \u00eent\u00e2rziere controlat\u0103 a replicilor \u00een acestea? Am dori s\u0103 ne protej\u0103m de scenarii negative cu alteri \u0219i alte modific\u0103ri. <\/p>\n<p>Se pot face roll back-uri pentru alteri? De exemplu, \u00een valul existent s\u0103 spunem c\u0103 p\u00e2n\u0103 la acest moment s\u0103 aplici modific\u0103rile, iar de la acest moment s\u0103 nu mai aplici modific\u0103rile?<\/p>\n<p>Dac\u0103 \u00een clusterul nostru a venit o echip\u0103 \u0219i l-a distrus, avem o replic\u0103 condi\u021bionat\u0103 cu o \u00eent\u00e2rziere de o or\u0103, unde putem spune: haide\u021bi s\u0103 folosim exact aceasta \u00een acest moment, dar s\u0103 nu aplic\u0103m ultimele zece minute de modific\u0103ri \u00een ea? <\/p><\/blockquote>\n<p>Mai \u00eent\u00e2i despre \u00eent\u00e2rzierea controlat\u0103 a replicilor. A fost o astfel de cerere din partea utilizatorilor \u0219i am creat un issue pe GitHub cu rug\u0103mintea: \u201eDac\u0103 cineva are nevoie, da\u021bi un like, da\u021bi o inimioar\u0103\u201d. Nimeni nu a dat, iar issue-ul a fost \u00eenchis. Cu toate acestea, deja acum este posibil s\u0103 ob\u021bine\u021bi aceast\u0103 func\u021bionalitate, configur\u00e2nd ClickHouse. Adev\u0103rat, doar \u00eencep\u00e2nd cu versiunea 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse efectueaz\u0103 constant fuziuni de date \u00een fundal. C\u00e2nd fuziunea este efectuat\u0103, un set de fragmente de date este \u00eenlocuit cu un fragment mai mare. \u00cen acest timp, fragmentele de date anterioare continu\u0103 s\u0103 r\u0103m\u00e2n\u0103 pe disc pentru o perioad\u0103 de timp.<\/p>\n<p><\/p>\n<p>\u00cen primul r\u00e2nd, acestea continu\u0103 s\u0103 fie stocate p\u00e2n\u0103 c\u00e2nd exist\u0103 interog\u0103ri select care le utilizeaz\u0103, pentru a asigura func\u021bionarea non-blocant\u0103. Interog\u0103rile select citesc f\u0103r\u0103 probleme din buc\u0103\u021bi vechi.<\/p>\n<p><\/p>\n<p>\u00cen al doilea r\u00e2nd, exist\u0103 \u0219i un prag de timp \u2014 buc\u0103\u021bile vechi de date stau pe disc timp de opt minute. Aceste opt minute pot fi configurate \u0219i transformate chiar \u0219i \u00een o zi. Aceasta va ocupa spa\u021biu pe disc: \u00een func\u021bie de fluxul de date, se poate \u00eent\u00e2mpla ca \u00een ultima zi datele s\u0103 nu se dubleze, ci s\u0103 fie de p\u00e2n\u0103 la cinci ori mai multe. Dar ve\u021bi putea, \u00een cazul unei probleme serioase, s\u0103 opri\u021bi serverul ClickHouse \u0219i s\u0103 rezolva\u021bi tot.<\/p>\n<p><\/p>\n<p>Acum apare \u00eentrebarea, cum protejeaz\u0103 asta \u00eempotriva alter\u0103rilor. Aici merit\u0103 s\u0103 ne uit\u0103m mai \u00een profunzime, pentru c\u0103 \u00een versiunile vechi de ClickHouse, alterarea func\u021biona astfel \u00eenc\u00e2t schimba direct buc\u0103\u021bile. Exist\u0103 o bucat\u0103 de date cu anumite fi\u0219iere, \u0219i facem, de exemplu, <strong>alter drop column<\/strong>. Atunci aceast\u0103 coloan\u0103 este eliminat\u0103 fizic din toate buc\u0103\u021bile.<\/p>\n<p><\/p>\n<p>Dar \u00eencep\u00e2nd cu versiunea 20.3, mecanismul de alterare a fost complet schimbat, iar acum buc\u0103\u021bile de date sunt \u00eentotdeauna imutabile. Ele nu se schimb\u0103 deloc \u2014 alter\u0103rile func\u021bioneaz\u0103 acum aproximativ la fel ca \u0219i fuzion\u0103rile. \u00cen loc s\u0103 modific\u0103m bucata pe loc, cre\u0103m una nou\u0103. \u00cen noua bucat\u0103, fi\u0219ierele care nu s-au schimbat devin link-uri dure, iar dac\u0103 am \u0219ters o coloan\u0103, ea va fi pur \u0219i simplu absent\u0103 \u00een noua bucat\u0103. Bucata veche va fi \u0219ters\u0103 implicit dup\u0103 opt minute, iar aici se pot ajusta set\u0103rile de care s-a vorbit mai sus. <\/p>\n<p><\/p>\n<p>Acela\u0219i lucru se aplic\u0103 \u0219i alter\u0103rilor de tip muta\u021bii. C\u00e2nd face\u021bi <strong>alter delete<\/strong> sau <strong>alter update<\/strong>, acesta nu modific\u0103 partea, ci creeaz\u0103 una nou\u0103. Apoi \u0219terge partea veche.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>Ce facem dac\u0103 structura tabelului s-a schimbat?<\/h2>\n<p><\/p>\n<blockquote><p>Cum putem ridica un backup care a fost realizat cu vechea schem\u0103? \u0218i a doua \u00eentrebare este despre cazul cu instantanee \u0219i instrumentele sistemului de fi\u0219iere. Este Btrfs o alternativ\u0103 adecvat\u0103 la ZFS pe Linux LVM?<\/p><\/blockquote>\n<p>Dac\u0103 face\u021bi <strong>attach partition<\/strong> parti\u021bii cu o alt\u0103 structur\u0103, atunci ClickHouse v\u0103 va spune c\u0103 nu este permis. Solu\u021bia este aceasta. \u00cen primul r\u00e2nd \u2014 crea\u021bi o tabel\u0103 temporar\u0103 de tip MergeTree cu vechea structur\u0103, ata\u0219a\u021bi datele acolo folosind attach, face\u021bi o interogare alter. Apoi pute\u021bi fie s\u0103 copia\u021bi sau s\u0103 muta\u021bi aceste date \u0219i s\u0103 face\u021bi din nou attach, fie s\u0103 folosi\u021bi interogarea <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Acum, s\u0103 vedem a doua \u00eentrebare \u2014 este posibil s\u0103 folose\u0219ti Btrfs? \u00cen primul r\u00e2nd, dac\u0103 ai LVM, atunci suficient sunt instantaneele LVM, iar sistemul de fi\u0219iere poate fi \u0219i ext4, nu are importan\u021b\u0103. Cu Btrfs, totul depinde de experien\u021ba ta \u00een utilizarea sa. Este un sistem de fi\u0219iere matur, dar exist\u0103 totu\u0219i unele suspiciuni cu privire la c\u00e2t de bine va func\u021biona \u00een practic\u0103 \u00eentr-un scenariu specific. Nu a\u0219 recomanda s\u0103 \u00eel folose\u0219ti dac\u0103 nu ai Btrfs \u00een produc\u021bie.<\/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>Care sunt cele mai bune practici actuale \u00een reshardingul de date?<\/h2>\n<p><\/p>\n<p>\u00centrebarea despre re\u00eemp\u0103r\u021birea datelor este complex\u0103 \u0219i multidimensional\u0103. Aici po\u021bi r\u0103spunde din mai multe perspective. Po\u021bi \u00eencepe \u0219i s\u0103 spui c\u0103 \u2014 ClickHouse nu are o func\u021bionalitate \u00eencorporat\u0103 pentru re\u00eemp\u0103r\u021birea datelor. Dar m\u0103 tem c\u0103 acest r\u0103spuns nu va mul\u021bumi pe nimeni. Prin urmare, putem aborda problema dintr-o alt\u0103 latur\u0103 \u0219i s\u0103 spunem c\u0103 \u00een ClickHouse exist\u0103 multe modalit\u0103\u021bi de re\u00eemp\u0103r\u021bire a datelor. <\/p>\n<p><\/p>\n<p>Dac\u0103 se termin\u0103 spa\u021biul pe cluster sau nu face fa\u021b\u0103 sarcinii, adaugi servere noi. Dar aceste servere sunt, prin defini\u021bie, goale, nu au date, iar sarcina nu curge. Trebuie s\u0103 redistribui datele pentru a le face s\u0103 fie distribuite uniform pe noul cluster, care a fost extins.<\/p>\n<p><\/p>\n<p>Prima metod\u0103 prin care po\u021bi face acest lucru este s\u0103 copiezi o parte a parti\u021biilor pe servere noi folosind o interogare. <strong>alter table fetch partition<\/strong>De exemplu, dac\u0103 aveai parti\u021bii pe luni, iei prima lun\u0103 din 2017 \u0219i o copiezi pe un nou server, apoi \u2014 a treia lun\u0103 o copiezi pe un alt server nou. \u0218i continui a\u0219a p\u00e2n\u0103 devine mai mult sau mai pu\u021bin uniform.<\/p>\n<p><\/p>\n<p>Transferul poate fi efectuat doar pentru acele parti\u021bii care nu se schimb\u0103 \u00een timpul scrierii. Pentru parti\u021biile recente, va trebui s\u0103 dezactivezi scrierea, deoarece transferul lor nu este atomic. Altfel, vei ob\u021bine duplicate sau declara\u021bii lips\u0103 \u00een date. Cu toate acestea, aceast\u0103 metod\u0103 este practic\u0103 \u0219i func\u021bioneaz\u0103 destul de eficient. Parti\u021biile comprimate sunt transmise prin re\u021bea, adic\u0103 datele nu sunt recompresate \u0219i nu sunt recodificate.<\/p>\n<p><\/p>\n<p>Aceast\u0103 metod\u0103 are un dezavantaj, care depinde de schema de sharding, dac\u0103 a\u021bi fost proiectat pentru aceast\u0103 schem\u0103 de sharding, ce cheie de sharding a\u021bi avut. \u00cen exemplul dumneavoastr\u0103 pentru cazul cu metrici, cheia de sharding este hash-ul c\u0103ii. Atunci c\u00e2nd efectua\u021bi un select \u00een tabelul Distributed, acesta se duce imediat la toate shard-urile clusterei \u0219i ia datele de acolo. <\/p>\n<p><\/p>\n<p>Acest lucru \u00eenseamn\u0103 c\u0103, \u00een esen\u021b\u0103, nu conteaz\u0103 pentru dumneavoastr\u0103 ce date se afl\u0103 pe fiecare shard. Important este c\u0103 datele pentru o anumit\u0103 cale se afl\u0103 pe un singur shard, iar care anume nu este esen\u021bial. \u00cen acest caz, mutarea partitiilor gata se potrive\u0219te foarte bine, deoarece la cererile select, fie c\u0103 este vorba despre \u00eenainte de resharding sau dup\u0103, schema nu are o importan\u021b\u0103 deosebit\u0103 - ve\u021bi ob\u021bine date complete.<\/p>\n<p><\/p>\n<p>Dar exist\u0103 \u0219i cazuri mai complicate. Dac\u0103 la nivelul logicii aplica\u021biei te bazezi pe o schem\u0103 de sharding special\u0103, unde acest client se afl\u0103 pe un anumit shard, iar cererea poate fi trimis\u0103 direct acolo, nu \u00een tabelul Distributed. Sau folose\u0219ti o versiune suficient de recent\u0103 a ClickHouse \u0219i ai activat configura\u021bia <strong>optimize skip unused shards<\/strong>. \u00cen acest caz, \u00een timpul cererii select, expresia din sec\u021biunea where va fi analizat\u0103, iar cil acele shard-uri la care este necesar s\u0103 se mearg\u0103 conform schemei de sharding va fi calculat\u0103. Aceasta func\u021bioneaz\u0103 cu condi\u021bia ca datele s\u0103 fie distribuite exact conform acestei scheme de sharding. Dac\u0103 le-ai rearanjat manual, coresponden\u021ba se poate schimba.<\/p>\n<p><\/p>\n<p>A\u0219adar, aceasta este prima metod\u0103. A\u0219tept r\u0103spunsul dumneavoastr\u0103, dac\u0103 metoda se potrive\u0219te sau dac\u0103 mergem mai departe.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, administrator de sistem principal la Avito<\/strong>: Alexei, metoda pe care ai men\u021bionat-o nu se potrive\u0219te foarte bine atunci c\u00e2nd trebuie s\u0103 distribuim \u00eenc\u0103rc\u0103tura \u0219i pe citire. Putem lua o parti\u021bie lunar\u0103 \u0219i putem muta luna precedent\u0103 pe o alt\u0103 nod\u0103, dar c\u00e2nd va veni cererea pentru ace\u0219ti date, vom \u00eenc\u0103rca doar aceasta. Ar fi de dorit s\u0103 \u00eenc\u0103rc\u0103m \u00eentregul cluster, pentru c\u0103, \u00een caz contrar, o vreme \u00eentreaga \u00eenc\u0103rc\u0103tur\u0103 de citire va fi procesat\u0103 de dou\u0103 shard-uri.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> R\u0103spunsul este ciudat \u2013 da, este r\u0103u, dar ar putea func\u021biona. O s\u0103 explic cum. Merit\u0103 s\u0103 arunci o privire asupra scenariului de \u00eenc\u0103rcare care urm\u0103re\u0219te datele tale. Dac\u0103 sunt date de monitorizare, atunci aproape cu certitudine putem spune c\u0103 majoritatea cererilor sunt pentru date proaspete. <\/p>\n<p><\/p>\n<p>A\u021bi instalat servere noi, a\u021bi mutat parti\u021biile vechi, dar a\u021bi schimbat \u0219i modul \u00een care se \u00eenregistreaz\u0103 datele noi. Astfel, datele noi vor fi distribuite pe \u00eentregul cluster. Astfel, chiar \u0219i dup\u0103 cinci minute, cererile pentru ultimele cinci minute vor \u00eenc\u0103rca uniform clusterul, iar dup\u0103 o zi, cererile pentru 24 de ore vor \u00eenc\u0103rca, de asemenea, uniform clusterul. Din p\u0103cate, cererile pentru luna anterioar\u0103 vor merge doar c\u0103tre o parte din serverele clusterului.<\/p>\n<p><\/p>\n<p>Dar, de multe ori, nu ve\u021bi avea cereri specific pentru februarie 2019. Cel mai probabil, dac\u0103 cererile au loc \u00een anul 2019, ele vor fi pentru \u00eentreg anul 2019 \u2014 pe un interval mare de timp, nu pe o perioad\u0103 mic\u0103. \u0218i astfel de cereri vor putea, de asemenea, s\u0103 \u00eencarce uniform clusterul. Dar, \u00een general, observa\u021bia dumneavoastr\u0103 este perfect corect\u0103, c\u0103 aceasta este o solu\u021bie ad hoc, care nu distribuie complet uniform datele.<\/p>\n<p><\/p>\n<p>Am c\u00e2teva puncte suplimentare pentru a r\u0103spunde la \u00eentrebare. Unul dintre ele se refer\u0103 la cum s\u0103 configura\u021bi ini\u021bial schema de sharding astfel \u00eenc\u00e2t s\u0103 fie mai pu\u021bin dureros \u00een urma re-sharding-ului. Acest lucru nu este \u00eentotdeauna posibil.<\/p>\n<p><\/p>\n<p>De exemplu, ave\u021bi date de monitorizare. Datele de monitorizare cresc din trei motive. Primul \u2014 acumularea de date istorice. Al doilea \u2014 cre\u0219terea traficului. Iar al treilea \u2014 cre\u0219terea num\u0103rului de lucruri care sunt supuse monitoriz\u0103rii. Apar noi microservicii \u0219i metrici care trebuie salvate. <\/p>\n<p><\/p>\n<p>Este posibil ca cea mai mare cre\u0219tere s\u0103 fie asociat\u0103 tocmai cu a treia cauz\u0103 \u2014 utilizarea sporit\u0103 a monitoriz\u0103rii. \u0218i \u00een acest caz, merit\u0103 s\u0103 ne uit\u0103m la natura \u00eenc\u0103rc\u0103rii, pentru a vedea care sunt cererile principale pentru select. Cererile principale pentru select vor merge \u00een mod probabil printr-un anumit subset de metrici.<\/p>\n<p><\/p>\n<p>De exemplu, utilizarea CPU pe anumite servere de c\u0103tre un anumit serviciu. A\u0219adar, exist\u0103 un anumit subset de chei pe care extrage\u021bi aceste date. \u0218i cererea pentru aceste date este, probabil, destul de simpl\u0103 \u0219i se execut\u0103 \u00een c\u00e2teva zeci de milisecunde. Este utilizat\u0103 pentru servicii de monitorizare, pentru tablouri de bord. Sper c\u0103 am \u00een\u021beles corect.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Problema este c\u0103 apel\u0103m foarte des la datele istorice, deoarece compar\u0103m \u00een timp real situa\u021bia curent\u0103 cu cea istoric\u0103. \u0218i pentru noi este important s\u0103 avem acces rapid la un volum mare de date, iar ClickHouse gestioneaz\u0103 excelent aceast\u0103 nevoie.<\/p>\n<p><\/p>\n<p>Ave\u021bi perfect\u0103 dreptate, majoritatea cererilor de citire pe care le primim sunt \u00een ultimele 24 de ore, ca \u00een orice sistem de monitorizare. Totu\u0219i, \u0219i pe datele istorice exist\u0103 o \u00eenc\u0103rcare destul de mare. Aceasta provine \u00een principal din sistemul de alertare, care la fiecare treizeci de secunde face cereri c\u0103tre ClickHouse: \u201e\u00cemi da\u021bi datele din ultimele \u0219ase s\u0103pt\u0103m\u00e2ni. Acum s\u0103 construim o medie mobil\u0103 din acestea \u0219i s\u0103 compar\u0103m valoarea curent\u0103 cu cea istoric\u0103.\u201d <\/p>\n<p><\/p>\n<p>A\u0219 dori s\u0103 men\u021bionez c\u0103 pentru astfel de cereri foarte recente avem o mic\u0103 tabel\u0103 separat\u0103, \u00een care p\u0103str\u0103m doar dou\u0103 zile de date, iar cererile principale merg c\u0103tre ea. Cererile de mari dimensiuni merg doar c\u0103tre tabelul mare, shardat.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Din p\u0103cate, solu\u021bia pentru scenariul dumneavoastr\u0103 nu se aplic\u0103 bine, dar voi descrie dou\u0103 scheme proaste \u0219i complicate de shardare care nu ar trebui utilizate, dar care sunt folosite \u00een serviciul prietenilor mei. <\/p>\n<p><\/p>\n<p>Exist\u0103 un cluster principal cu evenimentele \u201eYandex.Metrica\u201d. Evenimentele sunt vizitele de pagin\u0103, clicurile \u0219i tranzi\u021biile. Majoritatea cererilor se \u00eendreapt\u0103 c\u0103tre un anumit site web. Deschide\u021bi serviciul \u201eYandex.Metrica\u201d, ave\u021bi un site \u2014 avito.ru, accesa\u021bi raportul \u0219i face\u021bi o cerere pentru site-ul dumneavoastr\u0103.<\/p>\n<p><\/p>\n<p>Dar exist\u0103 \u0219i alte cereri \u2014 analitice \u0219i globale, pe care le efectueaz\u0103 anali\u0219tii interni. Observa\u021bi c\u0103 anali\u0219tii interni fac cereri doar pentru serviciile \u201eYandex\u201d. Totu\u0219i, chiar \u0219i serviciile \u201eYandex\u201d reprezint\u0103 o parte semnificativ\u0103 din toate datele. Acestea sunt cereri nu pentru contoare specifice, ci pentru o filtrare mai larg\u0103.<\/p>\n<p><\/p>\n<p>Cum s\u0103 organiza\u021bi datele astfel \u00eenc\u00e2t at\u00e2t pentru un singur contor s\u0103 func\u021bioneze eficient, c\u00e2t \u0219i pentru cereri globale? Complexitatea const\u0103 \u0219i \u00een faptul c\u0103 num\u0103rul cererilor \u00een ClickHouse pe clusterul \u201eMetrica\u201d este de c\u00e2teva mii pe secund\u0103. \u00cen plus, cererile non-triviale, de exemplu, c\u00e2teva mii pe secund\u0103, nu pot fi gestionate de un singur server ClickHouse.<\/p>\n<p><\/p>\n<p>Dimensiunea clusterului este de aproximativ \u0219ase sute de servere. Dac\u0103 peste acest cluster a\u0219ez\u0103m simplu o tabel\u0103 distribuit\u0103 \u0219i trimitem acolo c\u00e2teva mii de cereri, va fi \u0219i mai r\u0103u dec\u00e2t s\u0103 le trimitem c\u0103tre un singur server. Pe de alt\u0103 parte, op\u021biunea cu datele distribuite uniform, iar noi mergem \u0219i cerem de la toate serverele, este exclus\u0103 imediat.<\/p>\n<p><\/p>\n<p>Exist\u0103 o op\u021biune diametral opus\u0103. Imagina\u021bi-v\u0103 c\u0103 vom sharda datele pe site-uri, \u0219i cererea pentru un singur site va merge pe un singur shard. Acum clusterul va putea gestiona zece mii de cereri pe secund\u0103, dar pe un shard, o anumit\u0103 cerere va func\u021biona prea \u00eencet. Aceasta nu va mai scala \u00een func\u021bie de capacitate. \u00cen special dac\u0103 acest site este avito.ru. Nu voi dezv\u0103lui un secret dac\u0103 spun c\u0103 Avito este unul dintre cele mai vizitate site-uri din .ru. \u0218i a-l procesa pe un singur shard ar fi o nebunie.<\/p>\n<p><\/p>\n<p>De aceea, schema de sharding este conceput\u0103 \u00eentr-un mod mai inteligent. \u00centregul cluster este \u00eemp\u0103r\u021bit \u00een c\u00e2teva grupuri numite straturi. \u00cen interiorul fiec\u0103rui grup exist\u0103 de la zece la c\u00e2teva zeci de sharduri. Iar \u00een total sunt treizeci \u0219i nou\u0103 de astfel de grupuri. <\/p>\n<p><\/p>\n<p>Cum se scaleaz\u0103 totul? Num\u0103rul grupurilor nu se schimb\u0103 \u2013 cum erau \u00een urm\u0103 cu c\u00e2\u021biva ani treizeci \u0219i nou\u0103, a\u0219a a r\u0103mas. Dar \u00een interiorul fiec\u0103ruia dintre ele, cre\u0219tem treptat num\u0103rul de sharduri pe m\u0103sur\u0103 ce acumul\u0103m date. Schema de sharding, \u00een general, este astfel \u2013 \u00eemp\u0103r\u021birea \u00een aceste grupuri se face pe baz\u0103 de site-uri web, iar pentru a \u00een\u021belege care site este pe care cluster, se folose\u0219te o baz\u0103 de date separat\u0103 \u00een MySQL. Un site \u2013 \u00eentr-un singur grup. Iar \u00een interiorul lui, sharding-ul se face pe identificatorii vizitatorilor.<\/p>\n<p><\/p>\n<p>At the time of recording, we partition them based on the remainder of dividing the visitor ID. However, when adding a new shard, the sharding scheme changes; we continue to partition, but based on the remainder of division by a different number. This means that a single visitor is actually located on several servers, and we cannot rely on this. This is done solely to ensure better data compression. During queries, we query the Distributed table, which looks at the cluster and accesses dozens of servers. Such a convoluted scheme.<\/p>\n<p><\/p>\n<p>But my story wouldn't be complete if I didn't mention that we've abandoned this scheme. In the new scheme, we've changed everything and copied all the data using clickhouse-copier.<\/p>\n<p><\/p>\n<p>In the new scheme, all websites are divided into two categories \u2014 large and small. I don't know how the threshold was chosen, but the result is that large sites are recorded on one cluster, which has 120 shards with three replicas each \u2014 totaling 360 servers. The sharding scheme is such that any request goes to all shards simultaneously. If you now open any report page in 'Yandex.Metrica' for avito.ru, the request will go to 120 servers. There are few large sites in the Russian internet. Thus, the requests amount to not a thousand per second, but even less than a hundred. The Distributed table handles all this comfortably, providing service through those 120 servers.<\/p>\n<p><\/p>\n<p>The second cluster is for small websites. Here, the sharding scheme is based on the site ID, and each request goes to exactly one 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>\u00cen ClickHouse exist\u0103 o utilitate numit\u0103 clickhouse-copier. Pute\u021bi s\u0103 ne vorbi\u021bi despre aceasta?<\/h2>\n<p><\/p>\n<p>I will say right away that this solution is bulkier and somewhat less efficient. The advantage is that it distributes data completely according to the scheme you specify. However, the drawback of the utility is that it does not perform resharding. It copies data from one cluster schema to another.<\/p>\n<p><\/p>\n<p>This means that for it to work, you must have two clusters. They can be located on the same servers, but, nevertheless, the data will not be moved incrementally; instead, it will be copied. <\/p>\n<p><\/p>\n<p>De exemplu, erau patru servere, iar acum sunt opt. Creezi o nou\u0103 tabel\u0103 Distributed pe toate serverele, noi tabele locale, \u0219i porne\u0219ti clickhouse-copier, specific\u00e2nd schema de lucru, care trebuie s\u0103 citeasc\u0103 de acolo, s\u0103 accepte noua schem\u0103 de sharding \u0219i s\u0103 mute datele acolo. Iar pe serverele vechi vei avea nevoie de un spa\u021biu cu o jum\u0103tate mai mult dec\u00e2t ai acum, deoarece vechile date trebuie s\u0103 r\u0103m\u00e2n\u0103 pe ele, \u0219i deasupra lor va veni jum\u0103tate din acelea\u0219i date vechi. Dac\u0103 ai g\u00e2ndit din timp c\u0103 datele trebuie resharduite \u0219i ai spa\u021biu disponibil, atunci aceast\u0103 metod\u0103 se potrive\u0219te.<\/p>\n<p><\/p>\n<p>Cum func\u021bioneaz\u0103 clickhouse-copier? Acesta \u00eemparte \u00eentreaga munc\u0103 \u00een seturi de sarcini pentru procesarea unei parti\u021bii dintr-un tabel pe un shard. Toate aceste sarcini pot fi executate \u00een paralel, iar clickhouse-copier poate fi pornit pe diferite ma\u0219ini \u00een mai multe instan\u021be, dar ceea ce face pentru o parti\u021bie este, de fapt, un insert select. Datele sunt citite, decomprimate, resharduite, apoi din nou comprimate, scrise undeva, reordonate. Aceasta este o solu\u021bie mai grea.<\/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>A\u021bi avut un pilot numit resharding. Ce s-a \u00eent\u00e2mplat cu el?<\/h2>\n<p><\/p>\n<blockquote><p>Avea\u021bi \u00eenc\u0103 din 2017 o solu\u021bie pilot, numit\u0103 resharding. Chiar exist\u0103 o op\u021biune \u00een ClickHouse. \u00cen\u021beleg c\u0103 aceasta nu a avut succes. Pute\u021bi s\u0103 ne spune\u021bi de ce a fost a\u0219a? Suna foarte pertinent.<\/p><\/blockquote>\n<p>Toat\u0103 problema este c\u0103, atunci c\u00e2nd este necesar s\u0103 resharduim datele, este nevoie de o sincronizare foarte complex\u0103 pentru a face acest lucru atomic. C\u00e2nd am \u00eenceput s\u0103 ne uit\u0103m la modul \u00een care func\u021bioneaz\u0103 aceast\u0103 sincronizare, a devenit clar c\u0103 exist\u0103 probleme fundamentale. \u0218i aceste probleme fundamentale nu sunt doar teoretice, ci au \u00eenceput s\u0103 se manifeste \u00een practic\u0103 sub forma a ceva foarte simplu de explicat \u2014 nimic nu func\u021bioneaz\u0103.<\/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>Se pot combina toate p\u0103r\u021bile datelor \u00eenainte de a fi mutate pe discuri lente?<\/h2>\n<p><\/p>\n<blockquote><p>O \u00eentrebare despre TTL cu op\u021biunea move to slow disk \u00een contextul fuziunilor. Exist\u0103 vreo modalitate, \u00een afar\u0103 de cron, de a combina toate p\u0103r\u021bile \u00eentr-una singur\u0103 \u00eenainte de a le muta pe discuri lente?<\/p><\/blockquote>\n<p>R\u0103spunsul la \u00eentrebarea dac\u0103 se poate automatiza combinarea tuturor bucatelor \u00eentr-una singur\u0103 \u00eenainte de transfer este \u2014 nu. Mi se pare c\u0103 nu este nevoie de acest lucru. Nu este necesar s\u0103 se combine toate p\u0103r\u021bile \u00eentr-una, ci s\u0103 se contureze ideea c\u0103 acestea vor fi mutate pe discuri lente automat. <\/p>\n<p><\/p>\n<p>Avem dou\u0103 criterii pentru regulile de transfer. Primul&nbsp;\u2014 \u00een func\u021bie de umplere. Dac\u0103 la nivelul actual de stocare exist\u0103 mai pu\u021bin de un anumit procent de spa\u021biu liber, alegem o parte \u0219i o transfer\u0103m pe un stocare mai lent\u0103. De fapt, nu mai lent\u0103, ci urm\u0103toarea&nbsp;\u2014 a\u0219a cum o configurezi.<\/p>\n<p><\/p>\n<p>Al doilea criteriu&nbsp;\u2014 dup\u0103 dimensiune. Se refer\u0103 la transferul de buc\u0103\u021bi mari. Po\u021bi ajusta pragul de spa\u021biu liber pe discul rapid, iar datele vor fi transferate automat.<\/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>Cum s\u0103 trec la versiuni noi ClickHouse, dac\u0103 nu am posibilitatea de a verifica dinainte compatibilitatea?<\/h2>\n<p><\/p>\n<blockquote><p>Aceasta tem\u0103 este discutat\u0103 regulat <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">\u00een&nbsp;chatul Telegram ClickHouse<\/a><\/noindex> \u021bin\u00e2nd cont de versiunile diferite, \u0219i totu\u0219i. C\u00e2t de sigur este s\u0103 faci upgrade de la versiunea 19.11 la 19.16 \u0219i, de exemplu, de la 19.16 la 20.3. Cum e mai bine s\u0103 migrezi la noile versiuni, f\u0103r\u0103 a avea posibilitatea de a verifica compatibilitatea \u00een prealabil \u00eentr-un sandbox?<\/p><\/blockquote>\n<p>Aici sunt c\u00e2teva reguli \"aurii\". Prima&nbsp;\u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">s\u0103 citi\u021bi changelog-ul<\/a><\/noindex>. Este mare, dar exist\u0103 puncte separate referitoare la schimb\u0103rile incompatibile. Nu ar trebui s\u0103 prive\u0219ti aceste puncte ca pe un semnal de alarm\u0103. De obicei, acestea sunt incompatibilit\u0103\u021bi minore legate de unele func\u021bionalit\u0103\u021bi marginale, care, foarte probabil, nu le folose\u0219ti.<\/p>\n<p><\/p>\n<p>A doua&nbsp;\u2014 dac\u0103 nu ai posibilitatea s\u0103 verifici compatibilitatea \u00eentr-un sandbox, \u0219i vrei s\u0103 faci upgrade direct \u00een produc\u021bie, recomandarea este&nbsp;\u2014 nu o face. \u00cencepe prin a crea un sandbox \u0219i verific\u0103. Dac\u0103 nu ai un mediu de testare, atunci, cel mai probabil, compania ta nu este foarte mare, a\u0219a c\u0103 po\u021bi copia o parte din date pe laptopul t\u0103u \u0219i s\u0103 te asiguri c\u0103 totul func\u021bioneaz\u0103 corect. Po\u021bi chiar s\u0103 ridici c\u00e2teva replici local pe ma\u0219ina ta. Sau po\u021bi instala o nou\u0103 versiune undeva \u00een apropiere \u0219i s\u0103 \u00eencarci acolo o parte din date&nbsp;\u2014 adic\u0103 s\u0103 faci un mediu de testare improvizat. <\/p>\n<p><\/p>\n<p>\u00cenc\u0103 o regul\u0103&nbsp;\u2014 nu face upgrade \u00een decurs de o s\u0103pt\u0103m\u00e2n\u0103 dup\u0103 lansarea versiunii din cauza depist\u0103rii bug-urilor \u00een produc\u021bie \u0219i a ulterioarelor fixuri rapide. S\u0103 ne \u00een\u021belegem bine cu numerotarea versiunilor ClickHouse, pentru a nu ne confunda. <\/p>\n<p><\/p>\n<p>Exist\u0103 o versiune 20.3.4. Num\u0103rul 20&nbsp;indic\u0103 anul de lansare&nbsp;\u2014 2020. Din perspectiva a ceea ce este \u00een interior, acest lucru nu are nicio importan\u021b\u0103, a\u0219a c\u0103 nu ne vom concentra pe&nbsp;asta. Urm\u0103torul num\u0103r&nbsp;\u2014 20.3. A doua cifr\u0103&nbsp;\u2014 \u00een acest caz 3 \u2014 o cre\u0219tem de fiecare dat\u0103 c\u00e2nd lans\u0103m o versiune cu o nou\u0103 func\u021bionalitate. Dac\u0103 dorim s\u0103 ad\u0103ug\u0103m o capacitate \u00een&nbsp;ClickHouse, suntem obliga\u021bi s\u0103 cre\u0219tem acest num\u0103r. A\u0219adar, \u00een versiunea 20.4, ClickHouse va func\u021biona \u0219i mai bine. A treia cifr\u0103&nbsp;\u2014 20.3.4. Aici&nbsp;4 reprezint\u0103 num\u0103rul de patch-uri \u00een care nu am ad\u0103ugat noi capacit\u0103\u021bi, dar am corectat unele erori. \u0218i 4&nbsp;\u00eenseamn\u0103 c\u0103 am f\u0103cut asta de patru ori.<\/p>\n<p><\/p>\n<p>Nu trebuie s\u0103 credem c\u0103 este ceva teribil. De obicei, utilizatorul poate instala cea mai recent\u0103 versiune, iar aceasta va func\u021biona f\u0103r\u0103&nbsp;probleme \u00een ceea ce prive\u0219te timpul de activitate timp de un an. Dar imagina\u021bi-v\u0103 c\u0103, \u00een vreo func\u021bie pentru prelucrarea bitmap-urilor, care a fost ad\u0103ugat\u0103 de colegii no\u0219tri chinezi, serverul se pr\u0103bu\u0219e\u0219te atunci c\u00e2nd se transmit argumente gre\u0219ite. Suntem obliga\u021bi s\u0103 corect\u0103m acest lucru. Vom lansa o nou\u0103 versiune de patch, iar ClickHouse va deveni mai stabil.<\/p>\n<p><\/p>\n<p>Dac\u0103 ave\u021bi ClickHouse care func\u021bioneaz\u0103 \u00een produc\u021bie \u0219i iese o nou\u0103 versiune ClickHouse cu func\u021bionalit\u0103\u021bi suplimentare \u2014 de exemplu, 20.4.1 \u2014 la \u00eenceput, nu v\u0103 gr\u0103bi\u021bi s\u0103 o instala\u021bi \u00een produc\u021bie \u00een prima zi. De ce este necesar\u0103? Dac\u0103 nu utiliza\u021bi \u00eenc\u0103 ClickHouse, \u00eel pute\u021bi instala, \u0219i, cel mai probabil, totul va fi bine. Dar dac\u0103 ClickHouse func\u021bioneaz\u0103 deja stabil, atunci urm\u0103ri\u021bi patch-urile \u0219i actualiz\u0103rile&nbsp;\u2014 ce probleme corect\u0103m.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Vreau s\u0103 adaug pu\u021bin despre medii de testare. Toat\u0103 lumea se teme de mediile de testare \u0219i, dintr-un motiv oarecare, consider\u0103 c\u0103, dac\u0103 ave\u021bi un cluster ClickHouse foarte mare, atunci \u0219i mediul de testare ar trebui s\u0103 fie cel pu\u021bin la fel de mare sau cel pu\u021bin de zece ori mai mic. Chiar nu este a\u0219a.<\/p>\n<p><\/p>\n<p>Pot s\u0103 spun din experien\u021ba mea. Am un proiect \u0219i acolo este ClickHouse. Mediul nostru de testare pentru acest proiect&nbsp;\u2014 este o mic\u0103 virtual\u0103 \u00een&nbsp;Hetzner care cost\u0103 dou\u0103zeci de euro, unde totul este desf\u0103\u0219urat. Pentru a face asta, avem o automatizare complet\u0103 \u00een&nbsp;Ansible, a\u0219a c\u0103, \u00een principiu, nu conteaz\u0103 unde se desf\u0103\u0219oar\u0103 \u2014 pe servere fizice sau doar s\u0103 fie desf\u0103\u0219urat \u00een virtuale.<\/p>\n<p><\/p>\n<p>Ce po\u021bi face? Ar fi util s\u0103 fie inclus un exemplu \u00een documenta\u021bia ClickHouse privind cum s\u0103 desf\u0103\u0219ori un mic cluster - \u00een Docker, \u00een LXC, poate s\u0103 creezi un playbook Ansible, pentru c\u0103 oamenii au diverse metode de desf\u0103\u0219urare. Acest lucru ar simplifica mult. Atunci c\u00e2nd po\u021bi desf\u0103\u0219ura un cluster \u00een cinci minute, devine mult mai u\u0219or s\u0103 \u00eencerci s\u0103 \u00een\u021belegi ceva. A\u0219a este mult mai convenabil, pentru c\u0103 a merge \u00een produc\u021bie cu o versiune pe care nu ai testat-o - este un parcurs gre\u0219it. Uneori func\u021bioneaz\u0103, iar alteori nu. A\u0219a c\u0103 a te baza pe succes - este o idee proast\u0103.<\/p>\n<p><\/p>\n<p><strong>Maxim Kotiakov, inginer backend senior la Avito:<\/strong> O s\u0103 adaug c\u00e2teva informa\u021bii despre medii de testare din seria problemelor companiilor mari. Avem un cluster ClickHouse complet, cu scheme de date \u0219i configura\u021bii care sunt o copie exact\u0103 a ceea ce exist\u0103 \u00een produc\u021bie. Acest cluster este desf\u0103\u0219urat \u00een containere cu resurse minime. Scriem acolo un anumit procent din datele de produc\u021bie, pentru c\u0103 avem posibilitatea de a replica fluxul \u00een Kafka. Totul este sincronizat \u0219i scalat - at\u00e2t din punct de vedere al capacit\u0103\u021bii, c\u00e2t \u0219i al fluxului, iar, \u00een teorie, \u00een condi\u021bii egale ar trebui s\u0103 se comporte ca \u00een produc\u021bie. Tot ce este poten\u021bial riscant este desf\u0103\u0219urat mai \u00eent\u00e2i pe aceast\u0103 platform\u0103 \u0219i a\u0219teapt\u0103 c\u00e2teva zile p\u00e2n\u0103 la preg\u0103tire. Dar, desigur, aceasta este o solu\u021bie costisitoare, grea \u0219i cu cheltuieli semnificative pentru \u00eentre\u021binere. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Voi descrie ce reprezint\u0103 mediu de testare al prietenilor no\u0219tri de la \u201eYandex.Metrica\u201d. Un cluster avea peste 600 de servere, altul 360, \u0219i mai este \u0219i un al treilea \u0219i c\u00e2teva clustere suplimentare. Mediu de testare pentru unul dintre ele - este pur \u0219i simplu dou\u0103 sharduri cu dou\u0103 replici \u00een fiecare. De ce dou\u0103 sharduri? Ca s\u0103 nu fie unul singur. \u0218i replicile s\u0103 existe de asemenea. Este pur \u0219i simplu o cantitate minim\u0103 pe care \u021bi-o po\u021bi permite.<\/p>\n<p><\/p>\n<p>Acest mediu de testare permite verificarea func\u021bionalit\u0103\u021bii interog\u0103rilor \u0219i dac\u0103 ceva major s-a defectat. Dar adesea, problemele apar dintr-un alt tip de motiv, c\u00e2nd totul func\u021bioneaz\u0103, dar exist\u0103 unele mici modific\u0103ri \u00een \u00eenc\u0103rcare.<\/p>\n<p><\/p>\n<p>Voi da un exemplu. Am decis s\u0103 instal\u0103m o nou\u0103 versiune a ClickHouse. Aceasta a fost disponibil\u0103 \u00een mediu de testare, au fost efectuate teste automatizate \u00een cadrul \u201eYandex.Metrica\u201d, care compar\u0103 datele din versiunea veche cu cele din versiunea nou\u0103, trec\u00e2nd prin tot fluxul de lucru. \u0218i, desigur, testele verzi ale CI-ului nostru. Altfel, nu am fi propus niciodat\u0103 aceast\u0103 versiune.<\/p>\n<p><\/p>\n<p>Totul este perfect. \u00cencepem s\u0103 lans\u0103m \u00een produc\u021bie. Primesc un mesaj c\u0103 pe grafice \u00eenc\u0103rc\u0103tura a crescut de c\u00e2teva ori. Revenim la versiunea anterioar\u0103. M\u0103 uit la grafic \u0219i v\u0103d: \u00eenc\u0103rc\u0103tura a crescut cu adev\u0103rat de c\u00e2teva ori \u00een timpul lans\u0103rii \u0219i a sc\u0103zut din nou c\u00e2nd am revenit. Apoi am \u00eenceput s\u0103 revenim la versiunea anterioar\u0103. \u0218i \u00eenc\u0103rc\u0103tura a crescut la fel de mult \u0219i a sc\u0103zut exact la fel. A\u0219a c\u0103 concluzia este c\u0103 \u00eenc\u0103rc\u0103tura a crescut din cauza lans\u0103rii, nu este nimic surprinz\u0103tor.<\/p>\n<p><\/p>\n<p>A fost greu s\u0103-i conving pe colegi s\u0103 instaleze totu\u0219i noua versiune. Le spun: \u201eTotul este \u00een regul\u0103, lansa\u021bi. \u021aine\u021bi pumnii, totul va func\u021biona. Acum \u00eenc\u0103rc\u0103tura a crescut pe grafice, dar totul este bine. \u021aine\u021bi-v\u0103 bine\u201d. \u00cen general, a\u0219a am procedat \u0219i toat\u0103 lumea - versiunea a fost lansat\u0103 \u00een produc\u021bie. Dar aproape la fiecare lansare apar probleme similare.<\/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 ar trebui s\u0103 opreasc\u0103 interog\u0103rile, dar nu o face. De ce?<\/h2>\n<p><\/p>\n<blockquote><p>La mine a venit un utilizator, un anumit analist, \u0219i a creat o cerere care a pr\u0103bu\u0219it clusterul meu ClickHouse. O anumit\u0103 nod\u0103 sau \u00eentregul cluster - \u00een func\u021bie de replica sau shard-ul \u00een care a ajuns cererea. V\u0103d c\u0103 toate resursele CPU de pe acest server sunt la maximum, totul este ro\u0219u. Cu toate acestea, ClickHouse r\u0103spunde la cereri. \u0218i \u00eei scriu: \u201eTe rog, arat\u0103-mi lista proceselor, ce cerere a generat aceast\u0103 nebunie\u201d.<\/p>\n<p>G\u0103sesc aceast\u0103 cerere \u0219i \u00eei scriu kill. \u0218i v\u0103d c\u0103 nimic nu se \u00eent\u00e2mpl\u0103. Serverul meu este la maximum, ClickHouse continu\u0103 s\u0103-mi returneze comenzi, arat\u0103 c\u0103 serverul este activ \u0219i totul este \u00een regul\u0103. Dar am degradare \u00een toate cererile utilizatorilor, \u00eencepe degradarea la scrierea \u00een ClickHouse, iar comanda mea kill query nu func\u021bioneaz\u0103. De ce? Am crezut c\u0103 kill query ar trebui s\u0103 opreasc\u0103 cererile, dar asta nu se \u00eent\u00e2mpl\u0103.<\/p><\/blockquote>\n<p>Acum va fi un r\u0103spuns destul de ciudat. Problema este c\u0103 kill query nu opre\u0219te cererile. <\/p>\n<p><\/p>\n<p>Func\u021bia Kill query seteaz\u0103 un mic semn sub denumirea \u201evreau ca aceast\u0103 interogare s\u0103 fie oprit\u0103\u201d. Iar interogarea, \u00een timpul proces\u0103rii fiec\u0103rui bloc, verific\u0103 acest semn. Dac\u0103 este activat, interogarea se opre\u0219te. Deci, nimeni nu opre\u0219te interogarea, ea trebuie s\u0103 verifice totul \u0219i s\u0103 se opreasc\u0103 singur\u0103. Acest mecanism ar trebui s\u0103 func\u021bioneze \u00een toate cazurile c\u00e2nd interogarea se afl\u0103 \u00een procesul de procesare a blocurilor de date. Interogarea va procesa urm\u0103torul bloc de date, va verifica semnul \u0219i se va opri.<\/p>\n<p><\/p>\n<p>Aceasta nu func\u021bioneaz\u0103 \u00een cazurile \u00een care interogarea este blocat\u0103 pe o anumit\u0103 opera\u021biune. Totu\u0219i, cel mai probabil, aceasta nu este cazul dumneavoastr\u0103, deoarece, conform spuselor dumneavoastr\u0103, interogarea utilizeaz\u0103 o mul\u021bime de resurse ale serverului. Este posibil ca acest lucru s\u0103 nu func\u021bioneze \u00een cazul sorteaz\u0103rilor externe \u0219i \u00een alte c\u00e2teva detalii. \u00cen general, a\u0219a ceva nu ar trebui s\u0103 se \u00eent\u00e2mple; este un bug. \u0218i singurul lucru pe care \u00eel pot recomanda este s\u0103 actualiza\u021bi 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>Cum se calculeaz\u0103 timpul de r\u0103spuns pentru o sarcin\u0103 de citire?<\/h2>\n<p><\/p>\n<blockquote><p>Exist\u0103 un tabel \u00een care se p\u0103streaz\u0103 agregatele pentru item \u2014 diferite contoriz\u0103ri. Num\u0103rul de r\u00e2nduri este de aproximativ o sut\u0103 de milioane. Se poate conta pe un timp de r\u0103spuns previzibil dac\u0103 se trimit 1K RPS pentru 1K iteme? <\/p><\/blockquote>\n<p>Judec\u00e2nd dup\u0103 context, se refer\u0103 la sarcina de citire, deoarece nu sunt probleme la scriere \u2014 se pot insera fie o mie, fie o sut\u0103 de mii, \u0219i uneori chiar c\u00e2teva milioane de r\u00e2nduri. <\/p>\n<p><\/p>\n<p>Interog\u0103rile de lectur\u0103 sunt foarte variate. \u00cen select 1, ClickHouse poate efectua \u00een jur de zeci de mii de interog\u0103ri pe secund\u0103, a\u0219a c\u0103 chiar \u0219i interog\u0103rile pe o singur\u0103 cheie vor necesita ceva resurse. \u0218i aceste interog\u0103ri punctuale vor fi mai complicate dec\u00e2t \u00een orice baz\u0103 de date de tip key-value, deoarece pentru fiecare citire trebuie citit un bloc de date dup\u0103 index. Indexul nostru nu se axeaz\u0103 pe fiecare \u00eenregistrare, ci pe fiecare interval. Asta \u00eenseamn\u0103 c\u0103 va trebui s\u0103 citim \u00eentregul interval \u2014 acesta fiind 8192 de r\u00e2nduri \u00een mod prestabilit. \u0218i va trebui s\u0103 decompress\u0103m blocul de date comprimat de 64 Kb p\u00e2n\u0103 la 1 Mb. De obicei, interog\u0103rile punctuale dureaz\u0103 c\u00e2teva milisecunde. Dar aceasta este cea mai simpl\u0103 variant\u0103.<\/p>\n<p><\/p>\n<p>Hai s\u0103 \u00eencerc\u0103m s\u0103 facem o simpl\u0103 aritmetic\u0103. Dac\u0103 \u00eenmul\u021bim c\u00e2teva milisecunde cu o mie, ob\u021binem c\u00e2teva secunde. Ca \u0219i cum n-ar putea exista o mie de cereri pe secund\u0103, dar de fapt este posibil, deoarece avem mai multe nuclee de procesor. A\u0219adar, \u00een principiu, ClickHouse poate sus\u021bine uneori 1000 RPS, dar la cereri scurte, exact precise.<\/p>\n<p><\/p>\n<p>Dac\u0103 trebuie s\u0103 scalezi clusterul ClickHouse \u00een func\u021bie de num\u0103rul de cereri simple, \u00ee\u021bi recomand cel mai simplu lucru \u2013 s\u0103 creasc\u0103 num\u0103rul de replici \u0219i s\u0103 trimite\u021bi cereri la o replic\u0103 aleatorie. Dac\u0103 o replic\u0103 poate sus\u021bine cinci sute de cereri pe secund\u0103, ceea ce este complet posibil, atunci trei replici vor sus\u021bine o mie \u0219i jum\u0103tate.<\/p>\n<p><\/p>\n<p>Uneori, desigur, se poate \u0219i configura ClickHouse pentru a maximiza num\u0103rul de citiri punctuale. Ce este necesar pentru asta? \u00cen primul r\u00e2nd \u2013 s\u0103 reducem granularitatea indexului. Totu\u0219i, aceasta nu ar trebui s\u0103 fie redus\u0103 la unitate, ci av\u00e2nd \u00een vedere c\u0103 num\u0103rul de \u00eenregistr\u0103ri din index va fi de c\u00e2teva milioane sau zeci de milioane pe server. Dac\u0103 tabela are o sut\u0103 de milioane de r\u00e2nduri, atunci granularitatea poate fi setat\u0103 la 64.<\/p>\n<p><\/p>\n<p>Se poate reduce dimensiunea blocului comprimat. Exist\u0103 set\u0103ri pentru aceasta. <strong>min compress block size<\/strong>, <strong>max compress block size<\/strong>Acestea pot fi reduse, datele pot fi re\u00eenc\u0103rcate, iar cererile punctuale vor fi mai rapide. \u00cens\u0103 ClickHouse nu este o baz\u0103 de date key-value. Un num\u0103r mare de cereri mici reprezint\u0103 un antipatern de \u00eenc\u0103rcare.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> \u00ce\u021bi voi da un sfat \u00een cazul \u00een care sunt acolo conturi obi\u0219nuite. Este o situa\u021bie destul de standard c\u00e2nd \u00een ClickHouse se stocheaz\u0103 un anumit contor. Am un utilizator, dintr-o anumit\u0103 \u021bar\u0103, plus un alt c\u00e2mp \u0219i trebuie s\u0103 incrementez ceva. Ia MySQL, creeaz\u0103 o cheie unic\u0103 \u2013 \u00een MySQL este cheie duplicat\u0103, iar \u00een PostgreSQL este conflict \u2013 \u0219i adaug\u0103 cu un plus. Acesta va func\u021biona mult mai bine. <\/p>\n<p><\/p>\n<p>C\u00e2nd ai pu\u021bine date, nu are sens s\u0103 folose\u0219ti ClickHouse. Exist\u0103 baze de date obi\u0219nuite, care se descurc\u0103 bine cu acesta. <\/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>Ce s\u0103 ajustezi \u00een ClickHouse pentru a avea mai multe date \u00een cache?<\/h2>\n<p><\/p>\n<blockquote><p>S\u0103 presupunem o situa\u021bie \u2013 serverele au 256 GB RAM, iar \u00een rutina zilnic\u0103 ClickHouse utilizeaz\u0103 aproximativ 60\u201380 GB, la v\u00e2rf \u2013 p\u00e2n\u0103 la 130. Ce se poate activa \u0219i ajusta pentru a avea mai multe date \u00een cache \u0219i, \u00een consecin\u021b\u0103, pentru a reduce acces\u0103rile pe disk?<\/p><\/blockquote>\n<p>\u00cen general, cache-ul paginilor sistemului de operare \u00ee\u0219i \u00eendepline\u0219te bine aceast\u0103 sarcin\u0103. Dac\u0103 deschide\u021bi pur \u0219i simplu topul, verifica\u021bi dac\u0103 acolo este cached sau free \u2014 se poate observa c\u0103 toat\u0103 memoria liber\u0103 este utilizat\u0103 pentru cache. \u0218i aceste date, la citire, vor fi accesate nu de pe disc, ci din memorie. De asemenea, pot spune c\u0103 cache-ul este utilizat eficient, deoarece sunt cache-uite exact datele comprimate.<\/p>\n<p><\/p>\n<p>Totu\u0219i, dac\u0103 dori\u021bi s\u0103 accelera\u021bi \u0219i mai mult unele interog\u0103ri simple, exist\u0103 op\u021biunea de a activa \u00een ClickHouse cache-ul pentru datele desf\u0103cute. Acesta se nume\u0219te <strong>uncompressed cache<\/strong>. \u00cen fi\u0219ierul de configurare config.xml, seta\u021bi uncompressed cache size la valoarea dorit\u0103 \u2014 recomand s\u0103 nu dep\u0103\u0219easc\u0103 jum\u0103tate din memoria liber\u0103, deoarece restul va fi utilizat pentru cache-ul paginilor. <\/p>\n<p><\/p>\n<p>\u00cen plus, exist\u0103 dou\u0103 set\u0103ri la nivel de interogare. Prima setare este <strong>utilizarea cache-ului necomprimat<\/strong> \u2014 activeaz\u0103 utilizarea sa. Se recomand\u0103 activarea acesteia pentru toate interog\u0103rile, cu excep\u021bia celor grele, care pot citi toate datele \u0219i pot cur\u0103\u021ba acest cache. Iar a doua setare este ca un fel de num\u0103r maxim de r\u00e2nduri pentru utilizarea cache-ului. Aceasta limiteaz\u0103 automat interog\u0103rile mari, astfel \u00eenc\u00e2t s\u0103 fie ocolite cache-ul.<\/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>Cum putem configura storage_configuration pentru stocare \u00een memorie?<\/h2>\n<p><\/p>\n<blockquote><p>\u00cen noua documenta\u021bie ClickHouse, am citit o sec\u021biune legat\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">cu data storage<\/a><\/noindex>. \u00cen descriere exist\u0103 un exemplu cu SSD-uri rapide. <\/p>\n<p>Este interesant cum se poate configura acela\u0219i lucru cu memoria hot a volumului. \u0218i o alt\u0103 \u00eentrebare. Cum func\u021bioneaz\u0103 select cu o astfel de organizare a datelor, va citi \u00eentreaga set de date sau doar cele care se afl\u0103 pe disc, \u0219i sunt datele acestea comprimate \u00een memorie? \u0218i cum func\u021bioneaz\u0103 sec\u021biunea prewhere cu o astfel de organizare a datelor?<\/p><\/blockquote>\n<p>Aceast\u0103 setare afecteaz\u0103 stocarea buc\u0103\u021bilor de date, iar formatul lor nu se schimb\u0103.<br \/>\nHai s\u0103 examin\u0103m mai \u00een detaliu. <\/p>\n<p><\/p>\n<p>Se poate configura stocarea datelor \u00een memorie. Tot ceea ce este configurat pentru disc \u2014 acesta este calea sa. Creaz\u0103 un partition tmpfs, care este montat pe o anumit\u0103 cale \u00een sistemul de fi\u0219iere. Specifici aceast\u0103 cale ca fiind calea pentru stocarea datelor pentru cea mai fierbinte parti\u021bie, acolo \u00eencep s\u0103 vin\u0103 \u0219i s\u0103 fie scrise buc\u0103\u021bi de date, totul este bine. <\/p>\n<p><\/p>\n<p>Dar nu recomand s\u0103 se fac\u0103 asta din cauza fiabilit\u0103\u021bii sc\u0103zute, de\u0219i, dac\u0103 ave\u021bi cel pu\u021bin trei replici \u00een diferite centre de date, este posibil. \u00cen caz de nevoie, datele vor fi recuperate. S\u0103 presupunem c\u0103 serverul s-a oprit brusc \u0219i a fost repornit. Sec\u021biunea s-a montat din nou, dar acolo este gol. Serverul ClickHouse, la pornire, observ\u0103 c\u0103 aceste buc\u0103\u021bi lipsesc, de\u0219i, conform metadatelor din ZooKeeper, ar trebui s\u0103 fie acolo. Acesta verific\u0103 pe ce replici sunt \u0219i le solicit\u0103, desc\u0103rc\u00e2ndu-le. Astfel, datele vor fi restabilite. <\/p>\n<p><\/p>\n<p>\u00cen acest sens, stocarea datelor \u00een memorie nu se deosebe\u0219te fundamental de stocarea acestora pe disc, deoarece la scrierea datelor pe disc, acestea intr\u0103 mai \u00eent\u00e2i \u00een cache-ul de pagini \u0219i sunt scrise fizic cu \u00eent\u00e2rziere. Acest lucru depinde de varianta de montare a sistemului de fi\u0219iere. Dar, pentru siguran\u021b\u0103, voi men\u021biona c\u0103 ClickHouse nu face fsync la insert.<\/p>\n<p><\/p>\n<p>\u00cen acest proces, datele din memorie sunt stocate \u00een acela\u0219i format ca pe disc. Comanda select func\u021bioneaz\u0103 la fel, aleg\u00e2nd buc\u0103\u021bile care trebuie citite, select\u00e2nd intervalele necesare de date din acele buc\u0103\u021bi \u0219i citindu-le. \u0218i prewhere func\u021bioneaz\u0103 exact la fel, indiferent dac\u0103 datele erau \u00een memorie sau pe disc.<\/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>P\u00e2n\u0103 la ce num\u0103r de valori unice este eficient Low Cardinality?<\/h2>\n<p><\/p>\n<p>Low Cardinality este organizat ingenios. Creaz\u0103 dic\u021bionare de date, dar acestea sunt locale. Pe de o parte, dic\u021bionarele sunt proprii fiec\u0103rei buc\u0103\u021bi, iar pe de alt\u0103 parte, chiar \u0219i \u00een cadrul unei singure buc\u0103\u021bi, acestea pot fi diferite pentru fiecare interval. C\u00e2nd num\u0103rul valorilor unice atinge o limit\u0103 \u2014 cred c\u0103 un milion \u2014 dic\u021bionarul este pur \u0219i simplu am\u00e2nat, iar unul nou este creat.<\/p>\n<p><\/p>\n<p>R\u0103spunsul, \u00een general, este c\u0103 pentru fiecare interval local \u2014 s\u0103 zicem, pentru fiecare zi \u2014 unde sunt p\u00e2n\u0103 la un milion de valori unice, Low Cardinality este eficient. Dup\u0103 aceea, va exista pur \u0219i simplu un fallback, \u00een care vor fi utilizate multe dic\u021bionare diferite, nu doar unul. Va func\u021biona aproximativ ca un coloan\u0103 de tip string, poate pu\u021bin mai pu\u021bin eficient, dar nu va exista o degradare serioas\u0103 a performan\u021bei. <\/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>Care sunt cele mai bune practici pentru c\u0103utarea complet\u0103 \u00eentr-un tabel cu cinci miliarde de r\u00e2nduri?<\/h2>\n<p><\/p>\n<p>Exist\u0103 diferite variante de r\u0103spuns. Prima ar fi s\u0103 spunem c\u0103 ClickHouse nu este un sistem pentru c\u0103utarea textului complet. Pentru aceasta, exist\u0103 sisteme speciale, de exemplu, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> \u0219i <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Cu toate acestea, \u00eent\u00e2lnesc tot mai des oameni care spun c\u0103 trec de la Elasticsearch la ClickHouse.<\/p>\n<p><\/p>\n<p>De ce se \u00eent\u00e2mpl\u0103 asta? Ei explic\u0103 c\u0103 Elasticsearch nu mai face fa\u021b\u0103 sarcinilor la anumite volume, \u00eencep\u00e2nd cu ceea ce prive\u0219te construirea indicilor. Indicii devin prea volumino\u0219i \u0219i, dac\u0103 doar transfera\u021bi datele \u00een ClickHouse, rezultatul va fi c\u0103 stocarea lor este de c\u00e2teva ori mai eficient\u0103. \u00cen plus, interog\u0103rile de c\u0103utare nu erau \u00eentotdeauna despre g\u0103sirea unei fraze \u00een \u00eentreg volumul de date, ci despre ceva complet diferit. De exemplu, c\u0103utarea \u00een loguri pentru o subsecven\u021b\u0103 de octe\u021bi \u00een ultimele c\u00e2teva ore.<\/p>\n<p><\/p>\n<p>\u00cen acest caz, \u00een ClickHouse crea\u021bi un index, primul c\u00e2mp fiind data \u0219i ora. Iar cea mai mare restric\u021bie a datelor va fi pe baza intervalului de date. \u00cen interiorul intervalului de date selectat, de obicei, se poate efectua o c\u0103utare text complet, chiar \u0219i prin metoda brut\u0103, folosind operatorul like. Operatorul like din ClickHouse este cel mai eficient operator de acest tip pe care \u00eel pute\u021bi g\u0103si. Dac\u0103 g\u0103si\u021bi unul mai bun, spune\u021bi-mi. <\/p>\n<p><\/p>\n<p>Dar oricum, like este un full scan. \u0218i un full scan poate fi lent nu doar din punct de vedere al CPU-ului, ci \u0219i al hard disk-ului. Dac\u0103, de exemplu, ave\u021bi un terabyte de date pe zi \u0219i c\u0103uta\u021bi un cuv\u00e2nt \u00eentr-o zi, va trebui s\u0103 scana\u021bi un terabyte. Iar acesta este probabil stocat pe discuri dur normale, \u0219i \u00een cele din urm\u0103 vor fi at\u00e2t de \u00eenc\u0103rcate \u00eenc\u00e2t nu ve\u021bi putea accesa serverul prin SSH.<\/p>\n<p><\/p>\n<p>\u00cen acest caz, sunt preg\u0103tit s\u0103 propun \u00eenc\u0103 un truc mic. Este din categoria experimental\u0103 \u2014 poate func\u021biona, poate nu. \u00cen ClickHouse exist\u0103 indicii de c\u0103utare complet\u0103 sub form\u0103 de filtre Bloom trigram. Colegii no\u0219tri de la Arenadata au testat deja aceste indicii \u0219i, de multe ori, ele func\u021bioneaz\u0103 exact a\u0219a cum sunt destinate.<\/p>\n<p><\/p>\n<p>Pentru a le folosi corect, trebuie s\u0103 \u00een\u021belege\u021bi bine cum func\u021bioneaz\u0103: ce reprezint\u0103 un filtru Bloom trigram \u0219i cum s\u0103 alege\u021bi dimensiunea acestuia. Pot spune c\u0103 ele vor ajuta la interog\u0103rile pentru fraze rare, sub\u0219iruri care \u00eent\u00e2lnesc rar \u00een date. \u00cen acest caz, indicii vor selecta subintervale, \u0219i vor fi citite mai pu\u021bine date.<\/p>\n<p><\/p>\n<p>Recent updates in ClickHouse have brought even more advanced features for full-text search. Firstly, there\u2019s the ability to search for multiple substrings in one pass, including options for case sensitivity, without case sensitivity, support for UTF-8, or ASCII-only. Choose the most effective one that you need. <\/p>\n<p><\/p>\n<p>There\u2019s also the capability to search for multiple regular expressions in one pass. You don\u2019t need to write X like one substring or X like another substring. Just write it all at once, and everything is executed as efficiently as possible.<\/p>\n<p><\/p>\n<p>Thirdly, there is now approximate regex searching and approximate substring searching. If someone writes a word with a typo, it will be searched for maximum match.<\/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>Cum s\u0103 organizez accesul \u00een ClickHouse pentru un num\u0103r mare de utilizatori?<\/h2>\n<p><\/p>\n<blockquote><p>Please share how to better organize access for a large number of consumers and analysts. How to form a queue, prioritize max concurrent queries, and what tools to use?<\/p><\/blockquote>\n<p>If the cluster is large enough, a good solution would be to spin up two more servers that serve as the entry point for analysts. This means not granting analysts access to specific shards of the cluster, but rather creating two empty servers, without data, and setting access rights on those. In this case, user settings for distributed queries are passed to remote servers. That is, you configure everything on these two servers, and the settings take effect across the entire cluster.<\/p>\n<p><\/p>\n<p>In principle, these servers are without data, but the amount of RAM on them is quite important for executing queries. The disk can also be used for temporary data if external aggregation or external sorting is enabled.<\/p>\n<p><\/p>\n<p>It is important to review settings related to all potential limits. If I currently access the 'Yandex.Metrics' cluster as an analyst and make a query <strong>select count from hits<\/strong>, I will immediately receive an exception that I cannot execute the query. The maximum number of rows I am allowed to scan is one hundred billion, whereas in total there are fifty trillion in one table. This is the first limitation. <\/p>\n<p><\/p>\n<p>Suppose I remove the row limit and execute the query again. Then I will see the following exception \u2014 the setting is enabled. <strong>force index by date<\/strong>. Nu pot realiza cererea dac\u0103 nu am specificat intervalul de date. Nu ar trebui s\u0103 ne baz\u0103m pe faptul c\u0103 anali\u0219tii vor indica manual acest lucru. Un caz tipic&nbsp;\u2014 a fost scris un interval de date unde data evenimentului este \u00eentre o s\u0103pt\u0103m\u00e2n\u0103. \u0218i apoi pur \u0219i simplu nu s-a pus paranteza corect, iar \u00een loc de and s-a ob\u021binut or \u2014 or URL match. Dac\u0103 nu exist\u0103 restric\u021bii, va \u00eencepe s\u0103 scaneze coloana URL \u0219i va consuma pur \u0219i simplu o ton\u0103 de resurse.<\/p>\n<p><\/p>\n<p>\u00cen plus, ClickHouse are dou\u0103 set\u0103ri de prioritate. Din p\u0103cate, acestea sunt foarte primitive. Una se nume\u0219te pur \u0219i simplu <strong>priority<\/strong>. Dac\u0103 priority&nbsp;\u2260&nbsp;0, iar cererile sunt efectuate cu&nbsp;o anumit\u0103 prioritate, dar \u00een acela\u0219i timp este efectuat\u0103 o cerere cu&nbsp;o prioritate care are o valoare mai mic\u0103, ceea ce \u00eenseamn\u0103 o prioritate mai mare, atunci cererea cu&nbsp;valoarea prioritar\u0103 mai mare, care indic\u0103 o prioritate mai mic\u0103, pur \u0219i simplu este suspendat\u0103 \u0219i nu va func\u021biona deloc \u00een acea perioad\u0103.<\/p>\n<p><\/p>\n<p>Aceasta este o setare foarte brut\u0103 \u0219i nu se potrive\u0219te pentru cazurile \u00een care pe cluster exist\u0103 o \u00eenc\u0103rcare constant\u0103. Dar dac\u0103 ave\u021bi cereri scurte, impulsive, iar \u00een principal clusterul st\u0103 degeaba, aceast\u0103 setare va fi util\u0103.<\/p>\n<p><\/p>\n<p>Urm\u0103toarea configurare a prioritatilor se nume\u0219te <strong>prioritatea firului OS<\/strong>. Aceasta pur \u0219i simplu seteaz\u0103 pentru toate firele de execu\u021bie a cererii valoarea nice pentru schedulerul Linux. Func\u021bioneaz\u0103 mai mult sau mai pu\u021bin, dar totu\u0219i func\u021bioneaz\u0103. Dac\u0103 se stabile\u0219te cea mai mic\u0103 valoare nice \u2014 cea mai mare ca valoare, ceea ce \u00eenseamn\u0103 cea mai mic\u0103 prioritate \u2014 iar cererile cu prioritate \u00eenalt\u0103 sunt setate la -19, atunci CPU va consuma cererile cu prioritate mic\u0103 aproximativ de patru ori mai pu\u021bin dec\u00e2t cererile cu prioritate \u00eenalt\u0103. <\/p>\n<p><\/p>\n<p>De asemenea, trebuie s\u0103 seta\u021bi timpul maxim de execu\u021bie a cererii&nbsp;\u2014 s\u0103 spunem, cinci minute. Viteza minim\u0103 de execu\u021bie a cererii&nbsp;\u2014 aceasta este cea mai grozav\u0103. Aceast\u0103 setare exist\u0103 de mult timp \u0219i este necesar\u0103, nu doar pentru a afirma c\u0103 ClickHouse nu se blocheaz\u0103, ci pentru a for\u021ba acest lucru.<\/p>\n<p><\/p>\n<p>Imagina\u021bi-v\u0103 c\u0103 seta\u021bi: dac\u0103 vreo cerere proceseaz\u0103 mai pu\u021bin de un milion de r\u00e2nduri pe secund\u0103&nbsp;\u2014 a\u0219a ceva nu ar trebui s\u0103 se permit\u0103. Aceasta ne p\u0103teaz\u0103 numele bun, bazele noastre de date bune. S\u0103 interzicem pur \u0219i simplu acest lucru. De fapt, exist\u0103 dou\u0103 set\u0103ri. Una se nume\u0219te <strong>viteza minim\u0103 de execu\u021bie<\/strong> \u2014 \u00een&nbsp;linie pe secund\u0103, iar al doilea se nume\u0219te timeout \u00eenainte de verificarea vitezei minime de execu\u021bie&nbsp;\u2014 \u00een mod implicit cincisprezece secunde. Asta \u00eenseamn\u0103 c\u0103 cincisprezece secunde sunt acceptabile, iar apoi, dac\u0103 este lent, se poate pur \u0219i simplu lansa o excep\u021bie&nbsp;\u2014 \u00eentrerupe cererea.<\/p>\n<p><\/p>\n<p>De asemenea, trebuie s\u0103 configur\u0103m cotele. \u00cen&nbsp;ClickHouse exist\u0103 o func\u021bionalitate \u00eencorporat\u0103 de cote, care contabilizeaz\u0103 consumul de resurse. Dar, din p\u0103cate, nu resursele hardware precum CPU, discuri, ci cele logice&nbsp;\u2014 num\u0103rul de cereri procesate, linii \u0219i bytes citi\u021bi. \u0218i se pot configura, de exemplu, un maxim de o sut\u0103 de cereri \u00een&nbsp;cinci minute \u0219i o mie de cereri pe or\u0103.<\/p>\n<p><\/p>\n<p>De ce este important acest lucru? Pentru c\u0103 o parte din cererile de analiz\u0103 vor fi efectuate manual direct din clientul ClickHouse. \u0218i totul va merge bine. Dar dac\u0103 ave\u021bi \u00een companie anali\u0219ti avansa\u021bi, ace\u0219tia vor scrie un script \u0219i \u00een script ar putea exista o eroare. Iar aceast\u0103 eroare va duce la executarea cererii \u00eentr-un ciclu infinit. De aceea trebuie s\u0103 ne protej\u0103m.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>Este posibil s\u0103 trimitem rezultatele unei interog\u0103ri la zece clien\u021bi?<\/h2>\n<p><\/p>\n<blockquote><p>Avem c\u00e2\u021biva utilizatori care iubesc s\u0103 vin\u0103 cu cereri foarte mari \u00een&nbsp;acela\u0219i moment. Cererea este mare, se execut\u0103 rapid \u00een principiu, dar din cauza c\u0103 sunt multe cereri simultan, devine foarte solicitant. Se poate executa aceea\u0219i cerere, care a venit de zece ori la r\u00e2nd, o dat\u0103 \u0219i s\u0103 return\u0103m rezultatul celor zece clien\u021bi?<\/p><\/blockquote>\n<p>Problema este c\u0103 nu avem rezultatele cache-ului sau ale cache-ului de date intermediare. Exist\u0103 cache-ul paginilor al sistemului de operare, care va permite s\u0103 nu citim datele de pe disc din nou, dar, din p\u0103cate, datele vor trebui totu\u0219i s\u0103 fie decompressate, deserializate \u0219i procesate din nou. <\/p>\n<p><\/p>\n<p>Ne-am dori s\u0103 evit\u0103m acest lucru \u00eentr-un fel, fie cache-uind datele intermediare, fie structur\u00e2nd cereri similare \u00eentr-o anumit\u0103 coad\u0103 \u0219i ad\u0103ug\u00e2nd un cache pentru rezultate. \u00cen prezent avem \u00een dezvoltare un pull request, care adaug\u0103 un cache pentru cereri, dar doar pentru subcereri \u00een sec\u021biunile in \u0219i join&nbsp;\u2014 adic\u0103 solu\u021bia nu este complet\u0103.<\/p>\n<p><\/p>\n<p>Cu toate acestea, avem \u0219i noi o astfel de situa\u021bie. Un exemplu clasic este reprezentat de cererile cu paginare. Exist\u0103 un raport care are mai multe pagini, \u0219i se face o cerere cu limit\u0103 10. Apoi este acela\u0219i lucru, dar cu limit\u0103 10,10. Apoi apare o alt\u0103 pagin\u0103. \u0218i se ridic\u0103 \u00eentrebarea, de ce num\u0103r\u0103m tot asta de fiecare dat\u0103? Dar \u00een prezent nu exist\u0103 nicio solu\u021bie, \u0219i nu se poate evita acest lucru.<\/p>\n<p><\/p>\n<p>Exist\u0103 o solu\u021bie alternativ\u0103 care se instaleaz\u0103 ca sidecar l\u00e2ng\u0103 ClickHouse \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> \u00cen ClickHouse Proxy exist\u0103 un limitator de rat\u0103 \u00eencorporat \u0219i un cache al rezultatelor. Acolo sunt implementate foarte multe configur\u0103ri, deoarece s-a rezolvat o sarcin\u0103 similar\u0103. Proxy permite limitarea cererilor, organiz\u00e2ndu-le \u00een coad\u0103, \u0219i se poate seta c\u00e2t timp tr\u0103ie\u0219te cache-ul cererilor. Dac\u0103 cererile au fost realmente identice, Proxy le va returna de mai multe ori, dar va accesa ClickHouse doar o singur\u0103 dat\u0103.<\/p>\n<p><\/p>\n<p>\u0218i \u00een Nginx exist\u0103 un cache \u00een versiunea gratuit\u0103, iar aceasta va func\u021biona de asemenea. Nginx are chiar set\u0103ri care, dac\u0103 cererile au sosit simultan, va \u00eent\u00e2rzia altele p\u00e2n\u0103 c\u00e2nd una va fi executat\u0103. Dar \u00een ClickHouse Proxy configurarea este mult mai bun\u0103. A fost realizat\u0103 specific pentru ClickHouse, pentru aceste cereri, centrat pe ele, deci se potrive\u0219te mai bine. \u0218i se instaleaz\u0103 foarte u\u0219or. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Cum gestion\u0103m opera\u021biunile asincrone \u0219i vederile materializate?<\/h2>\n<p><\/p>\n<blockquote><p>Exist\u0103 o problem\u0103, c\u0103 opera\u021biile cu motorul de \u00eenlocuire sunt asincrone \u2014 mai \u00eent\u00e2i sunt \u00eenregistrate datele, apoi se realizeaz\u0103 compresia acestora. Dac\u0103 sub tabel este o tabel\u0103 materializat\u0103 cu anumite agregate, atunci duplicatele vor fi \u00eenregistrate acolo. \u0218i dac\u0103 nu exist\u0103 o logic\u0103 complex\u0103, datele vor fi duplicate. Ce se poate face \u00een acest sens?<\/p>\n<p>Exist\u0103 o solu\u021bie evident\u0103 \u2014 implementarea unui trigger pe un anumit tip de materializ\u0103ri \u00een cadrul opera\u021biei asincrone de compresie. Exist\u0103 vreo \u00abbule ale argintului\u00bb, planuri de implementare a unor func\u021bionalit\u0103\u021bi similare?<\/p><\/blockquote>\n<p>Este bine s\u0103 ne ocup\u0103m de modul \u00een care func\u021bioneaz\u0103 deduplicarea. Ceea ce voi povesti acum nu se leag\u0103 de \u00eentrebare, dar pentru orice eventualitate, este bine s\u0103 ne amintim despre asta.<\/p>\n<p><\/p>\n<p>At insertion into a replicated table, there is deduplication of entirely inserted blocks. If you reinsert the same block containing the same number of identical rows in the same order, the data will be deduplicated. You will receive an 'Ok' in response to the insert, but in reality, only one batch of data will be written, and it will not be duplicated.<\/p>\n<p><\/p>\n<p>This is necessary for certainty. If during the insertion you received 'Ok', it means your data was inserted. If you received an error from ClickHouse, it means they were not inserted, and the insertion needs to be repeated. But if the connection was broken during the insertion, you do not know if the data was inserted or not. The only option is to repeat the insertion again. If the data was indeed inserted and you inserted it again, block deduplication occurs. This is needed to avoid duplicates. <\/p>\n<p><\/p>\n<p>It is also important how it works for materialized views. If the data was deduplicated when inserted into the main table, they will also not go into the materialized view.<\/p>\n<p><\/p>\n<p>Now regarding your question. You have a more complex situation because you are inserting duplicates of individual rows. That is, a block is not fully duplicated, but rather specific rows which are collapsing in the background. Indeed, the data will collapse in the main table, while the non-collapsed rows will go into the materialized view, and nothing will happen to the materialized views during merges. This is because a materialized view is nothing more than a trigger on insert. During other operations, nothing additional happens to it.<\/p>\n<p><\/p>\n<p>And I cannot bring you any joy here. It is only necessary to look for a specific solution for this case. For example, whether it is possible to also perform replacing in the materialized view, and the deduplication method may work similarly. But unfortunately, this does not always happen. If it is aggregating, then it won't work. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> \u0218i la noi, construc\u021bia de suport a fost o adev\u0103rat\u0103 provocare la vremea respectiv\u0103. Era o problem\u0103 c\u0103 exist\u0103 afi\u0219\u0103ri publicitare \u0219i exist\u0103 anumite date pe care le putem ar\u0103ta \u00een timp real \u2014 acestea sunt doar afi\u0219\u0103ri. Rareori se dublau, dar, dac\u0103 se \u00eent\u00e2mpl\u0103, le vom consolid\u0103m ulterior. \u0218i erau lucruri care nu puteau fi duplicate \u2014 clicurile \u0219i \u00eentreaga istorie. Dar ne-ar fi pl\u0103cut s\u0103 le ar\u0103t\u0103m aproape imediat.<\/p>\n<p><\/p>\n<p>Cum au fost realizate vederile materializate? Au fost vederi \u00een care se scrie direct \u2014 se face o \u00eenregistrare \u00een datele brute \u0219i se scrie \u00een vederi. La un moment dat, datele nu erau foarte corecte, se duplicau \u0219i a\u0219a mai departe. \u0218i exist\u0103 o a doua parte a tabelului, unde ele arat\u0103 absolut la fel ca \u0219i vederile materializate, adic\u0103, din punct de vedere al structurii, sunt complet identice. O dat\u0103 la un timp, recalcul\u0103m datele, complet\u0103m datele f\u0103r\u0103 duplicaturi \u0219i le scriem \u00een acele tabele. <\/p>\n<p><\/p>\n<p>Am trecut prin API \u2014 \u00een ClickHouse nu va func\u021biona manual. API-ul verific\u0103: c\u00e2nd am data ultimei ad\u0103ug\u0103ri \u00een tabel, unde datele sunt deja corecte, calculate, \u0219i face o cerere la un tabel \u0219i la cel\u0103lalt. Dintr-un tabel selecteaz\u0103 date p\u00e2n\u0103 la un anumit moment, iar din cel\u0103lalt completeaz\u0103 ceea ce nu a fost \u00eenc\u0103 calculat. \u0218i func\u021bioneaz\u0103, dar nu cu resursele unui singur ClickHouse.<\/p>\n<p><\/p>\n<p>Dac\u0103 ave\u021bi un API \u2014 pentru anali\u0219ti, pentru utilizatori \u2014 este o op\u021biune, \u00een principiu. \u00centotdeauna recalcula\u021bi, \u00eentotdeauna face\u021bi recalcul\u0103ri. Acest lucru poate fi f\u0103cut o dat\u0103 pe zi sau la un alt interval. Voi alegi intervalul care nu este important \u0219i nu este critic pentru voi.<\/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>Exist\u0103 multe loguri \u00een ClickHouse. Cum pot vedea tot ce se \u00eent\u00e2mpl\u0103 cu serverul, \u00een momentul respectiv?<\/h2>\n<p><\/p>\n<blockquote><p>\u00cen ClickHouse exist\u0103 o cantitate foarte mare de diferite loguri, iar aceast\u0103 cantitate cre\u0219te. \u00cen versiunile noi, unele dintre ele sunt activate implicit, iar \u00een versiunile mai vechi, trebuie activate la actualizare. Cu toate acestea, num\u0103rul lor cre\u0219te tot mai mult. Mi-ar pl\u0103cea s\u0103 v\u0103d, \u00een final, ce se \u00eent\u00e2mpl\u0103 \u00een prezent cu serverul meu, poate pe un tablou de bord centralizat. <\/p>\n<p>Nu ave\u021bi cumva \u00een echipa dumneavoastr\u0103 ClickHouse, sau \u00een echipele prietenilor dumneavoastr\u0103, care s\u0103 sus\u021bin\u0103 un anumit tip de func\u021bionalitate a dashboard-urilor gata preg\u0103tite, care s\u0103 afi\u0219eze aceste loguri sub form\u0103 de produs final? \u00cen cele din urm\u0103, este minunat s\u0103 vizualizezi logurile \u00een ClickHouse \u2014 dar ar fi \u0219i mai grozav dac\u0103 ar fi deja preg\u0103tite sub forma unui dashboard. A\u0219 fi \u00eenc\u00e2ntat de asta. <\/p><\/blockquote>\n<p>Exist\u0103 dashboard-uri, de\u0219i ele nu sunt standardizate. La noi \u00een companie, aproximativ 60 de echipe folosesc ClickHouse, \u0219i cel mai ciudat este c\u0103 multe dintre ele au dashboard-uri pe care \u0219i le-au creat singure, fiecare pu\u021bin diferite. Unele echipe utilizeaz\u0103 o instalare intern\u0103 a \u201eYandex.Cloud\u201d. Acolo sunt anumite rapoarte gata f\u0103cute, de\u0219i nu toate cele necesare. Alte echipe au propriile lor solu\u021bii. <\/p>\n<p><\/p>\n<p>Colegul meu de la \u201eMetrix\u201d are propriul dashboard \u00een Grafana, iar eu am unul bazat pe clusterul lor. Acolo verific lucruri precum cache hit pentru cache-ul de inscrip\u021bii. \u0218i este \u0219i mai complicat, deoarece folosim instrumente diferite. Dashboard-ul meu l-am creat pe un instrument foarte vechi numit Graphite-web. Este complet ur\u00e2t. \u0218i \u00eenc\u0103 \u00eel folosesc, de\u0219i Grafana ar fi fost probabil mai convenabil\u0103 \u0219i mai atr\u0103g\u0103toare. <\/p>\n<p><\/p>\n<p>Elementul de baz\u0103 din dashboard-uri este acela\u0219i. Acesta include metrici de sistem pentru cluster: CPU, memorie, disc, re\u021bea. Altele includ num\u0103rul de interog\u0103ri simultane, num\u0103rul de fuzion\u0103ri simultane, num\u0103rul de interog\u0103ri pe secund\u0103, num\u0103rul maxim de p\u0103r\u021bi pentru part\u021biile tabelelor MergeTree, \u00eent\u00e2rzierea replic\u0103rii, dimensiunea cozii de replicare, num\u0103rul de r\u00e2nduri inserate pe secund\u0103, num\u0103rul de blocuri inserate pe secund\u0103. Aceasta este tot ce ob\u021binem din metrici, nu din loguri.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Alexei, a\u0219 dori s\u0103 corectez pu\u021bin. Exist\u0103 Grafana. Grafana are un datasource, care este ClickHouse. Deci pot face interog\u0103ri direct \u00een ClickHouse din Grafana. \u00cen ClickHouse exist\u0103 o tabel\u0103 cu loguri, care este aceea\u0219i pentru toat\u0103 lumea. Vreau ca, \u00een rezultatul din Grafana, s\u0103 accesez aceast\u0103 tabel\u0103 de loguri \u0219i s\u0103 v\u0103d acele interog\u0103ri pe care serverul meu le genereaz\u0103. Ar fi grozav s\u0103 am un astfel de dashboard.<\/p>\n<p><\/p>\n<p>L-am creat eu singur. Dar am o \u00eentrebare \u2014 dac\u0103 totul este standardizat \u0219i Grafana este folosit\u0103 de toat\u0103 lumea, de ce nu exist\u0103 un astfel de dashboard oficial \u00een \u201eYandex\u201d?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> \u00cen realitate, sursa de date pentru ClickHouse este acum sus\u021binut\u0103 de Altinity. Vreau doar s\u0103 ofer o direc\u021bie, unde ar trebui s\u0103 c\u0103ut\u0103m informa\u021bii \u0219i pe cine s\u0103 pres\u0103m. Poate c\u0103 putem \u00eentreba pe ei, deoarece \u201eYandex\u201d este cel care dezvolt\u0103 ClickHouse, nu povestea din jurul acestuia. Altinity este compania principal\u0103 care promoveaz\u0103 acum ClickHouse. Nu \u00eel vor p\u0103r\u0103si, ci \u00eel vor sus\u021bine. Deoarece, \u00een principiu, pentru a \u00eenc\u0103rca un dashboard pe site-ul Grafana, trebuie doar s\u0103 te \u00eenregistrezi \u0219i s\u0103-l \u00eencarci \u2014 nu sunt probleme mari. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> \u00cen ultimul an, ClickHouse a ad\u0103ugat multe func\u021bionalit\u0103\u021bi pentru profilarea interog\u0103rilor. Exist\u0103 metrici pentru fiecare interogare legate de utilizarea resurselor. Iar recent a fost ad\u0103ugat un profiler de interog\u0103ri \u0219i mai detaliat, pentru a vedea unde petrece fiecare milisecund\u0103. Dar pentru a putea folosi aceste func\u021bionalit\u0103\u021bi, trebuie s\u0103 deschid clientul din linia de comand\u0103 \u0219i s\u0103 tastez interogarea pe care o uit constant. Am salvat-o undeva, dar tot uit unde. <\/p>\n<p><\/p>\n<p>Mi-ar pl\u0103cea s\u0103 existe un instrument \u00een care s\u0103 fie clar \u2014 acestea sunt interog\u0103rile tale grele, grupate dup\u0103 clase de interog\u0103ri. Am ap\u0103sat pe una \u0219i mi s-ar spune c\u0103 este grea din cauza asta. Acum nu exist\u0103 o astfel de solu\u021bie. \u0218i este cu adev\u0103rat destul de ciudat, c\u0103 atunci c\u00e2nd oamenii m\u0103 \u00eentreab\u0103: \u201eSpune\u021bi, exist\u0103 vreo tabl\u0103 de bord gata pentru Grafana?\u201d, le spun: \u201eAccesa\u021bi site-ul Grafana, acolo este comunitatea \u201eDashboards\u201d \u0219i exist\u0103 un dashboard de la Dimka, exist\u0103 un dashboard de la Kostyan. Ce este, nu \u0219tiu, eu personal nu am folosit.\u201d<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>Cum s\u0103 influen\u021bez fuziunile astfel \u00eenc\u00e2t serverul s\u0103 nu cad\u0103 \u00een OOM?<\/h2>\n<p><\/p>\n<blockquote><p>Am o tabel\u0103, care are o singur\u0103 parti\u021bie, este ReplacingMergeTree. Am scris date \u00een ea timp de patru ani. A trebuit s\u0103 fac un alter \u0219i s\u0103 \u0219terg unele date.<\/p>\n<p>Am f\u0103cut acest lucru, iar \u00een timpul proces\u0103rii acestei interog\u0103ri, toat\u0103 memoria de pe toate serverele clusterului a fost consumat\u0103, iar toate serverele clusterului au c\u0103zut dr\u0103g\u0103stoase \u00een OOM. Apoi, s-au ridicat toate \u00eempreun\u0103, au \u00eenceput s\u0103 execute fuziunea acelea\u0219i opera\u021bii, a acelui bloc de date \u0219i au c\u0103zut din nou \u00een OOM. Apoi, s-au ridicat din nou \u0219i au c\u0103zut din nou. Aceast\u0103 situa\u021bie nu s-a oprit.<\/p>\n<p>Apoi s-a dovedit c\u0103 este, de fapt, un bug pe care b\u0103ie\u021bii l-au corectat. E foarte bine, mul\u021bumesc mult. Dar a r\u0103mas o nepl\u0103cere. \u0218i acum, c\u00e2nd m\u0103 g\u00e2ndesc c\u0103 trebuie s\u0103 fac un merge \u00een tabel, apare \u00eentrebarea - de ce nu pot s\u0103 influen\u021bez cumva aceste merge-uri? De exemplu, s\u0103 le limitez dup\u0103 cantitatea de memorie RAM necesar\u0103 sau, \u00een principiu, dup\u0103 num\u0103rul acestora care va procesa acest tabel.<\/p>\n<p>Am un tabel care se nume\u0219te \u201eMetrici\u201d, te rog s\u0103-l procesezi \u00een dou\u0103 fire. Nu trebuie s\u0103 creezi zece sau cinci merge-uri \u00een paralel, f\u0103-le \u00een dou\u0103. Cred c\u0103 \u00een dou\u0103 am suficient\u0103 memorie, dar poate c\u0103 pentru zece nu va fi suficient. De ce mai r\u0103m\u00e2ne frica? Pentru c\u0103 tabelul cre\u0219te \u0219i, \u00eentr-o zi, m\u0103 voi confrunta cu situa\u021bia \u00een care, \u00een principiu, nu din cauza unui bug, ci pentru c\u0103 datele se vor schimba \u00eentr-un volum at\u00e2t de mare \u00eenc\u00e2t nu voi avea suficient\u0103 memorie pe server. \u0218i atunci serverul va c\u0103dea \u00een OOM la merge. \u00cen plus, pot anula muta\u021bia, dar merge-urile nu.<\/p><\/blockquote>\n<p>\u0218ti\u021bi, la merge-uri serverul nu va c\u0103dea \u00een OOM, deoarece la merge se folose\u0219te doar cantitatea de memorie operativ\u0103 pentru un mic interval de date. A\u0219a c\u0103 totul va fi bine, indiferent de volumul de date.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Bine. Aici e un aspect: dup\u0103 ce am realizat bug fix-ul, mi-am desc\u0103rcat noua versiune \u0219i pe un alt tabel, mai mic, unde sunt multe parti\u021bii, am efectuat o opera\u021bie similar\u0103. \u0218i \u00een timpul merge-ului, serverul a consumat \u00een jur de 100 GB de memorie RAM. Aveam 150 ocupate, 100 au fost consumate, \u0219i am r\u0103mas cu un spa\u021biu de 50 GB, a\u0219a c\u0103 nu am c\u0103zut \u00een OOM.<\/p>\n<p><\/p>\n<p>Ce m\u0103 protejeaz\u0103 \u00een acest moment de a nu c\u0103dea \u00een OOM dac\u0103 \u00eentr-adev\u0103r consum\u0103 vreo 100 GB de memorie RAM? Ce fac \u00een situa\u021bia \u00een care, brusc, memoria RAM la merge-uri se termin\u0103?<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Exist\u0103 o problem\u0103 \u00een care consumul de memorie RAM nu se limiteaz\u0103 doar la fuziuni. A doua problem\u0103 este c\u0103, dac\u0103 o fuziune a fost programat\u0103, aceasta trebuie s\u0103 fie executat\u0103, deoarece este \u00eenregistrat\u0103 \u00een jurnalul de replicare. Jurnalul de replicare const\u0103 \u00een acele ac\u021biuni necesare pentru a aduce replica \u00eentr-o stare consistent\u0103. Dac\u0103 nu se fac manipul\u0103ri manuale care s\u0103 anuleze acest jurnal de replicare, fuziunea va trebui, \u00eentr-un fel sau altul, s\u0103 fie executat\u0103.<\/p>\n<p><\/p>\n<p>Desigur, ar fi bine s\u0103 existe o limitare a memoriei RAM care s\u0103 protejeze, \u201epentru orice eventualitate\u201d, \u00eempotriva OOM. Aceasta nu va ajuta fuziunea s\u0103 fie realizat\u0103, ea va \u00eencepe din nou, va ajunge la un anumit prag, va arunca o excep\u021bie \u0219i apoi va \u00eencepe din nou - nimic bun nu va ie\u0219i din asta. Dar, \u00een principiu, introducerea acestei limit\u0103ri ar fi util\u0103.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Cum va decurge dezvoltarea driverului Golang pentru ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>Driverul Golang, pe care l-a scris Kirill Shvakov, este acum oficial sus\u021binut de echipa ClickHouse. El <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">se afl\u0103 \u00een depozitul ClickHouse<\/a><\/noindex>, acum este mare \u0219i adev\u0103rat.<\/p>\n<p>O mic\u0103 remarc\u0103. Exist\u0103 un depozit minunat, apreciat de toat\u0103 lumea, de forme normale de ordini infinite \u2014 acesta este Vertica. De asemenea, au un driver oficial pentru python, care este sus\u021binut de dezvoltatorii Vertica. Au fost de mai multe ori situa\u021bii \u00een care versiunile depozitului \u0219i versiunile driverului s-au desincronizat destul de mult, iar driverul a ajuns \u00een acel moment s\u0103 nu mai func\u021bioneze. \u0218i un alt aspect. Suportul pentru acest driver oficial, mi se pare, se desf\u0103\u0219oar\u0103 prin sistemul \u201eniplu\u201d \u2014 scrii o problem\u0103 \u0219i aceasta r\u0103m\u00e2ne suspendat\u0103 pentru totdeauna.<\/p>\n<p>Am dou\u0103 \u00eentreb\u0103ri. Acum, driverul lui Kiril pentru Golang este aproape modul standard de comunicare din Golang cu ClickHouse. Doar c\u0103 cineva comunic\u0103 \u00een continuare prin interfa\u021ba http, pentru c\u0103 a\u0219a \u00eei place. Cum va decurge dezvoltarea acestui driver? Se va sincroniza cu unii schimb\u0103ri majore \u00een depozit? \u0218i care este procedura de examinare a problemelor? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> Primul aspect este cum este organizat\u0103 birocratic. Acest moment nu a fost discutat, a\u0219a c\u0103 nu am ce s\u0103 r\u0103spund.<\/p>\n<p><\/p>\n<p>Pentru a r\u0103spunde la \u00eentrebare despre problem\u0103, este nevoie de o mic\u0103 poveste a driverului. Am lucrat \u00eentr-o companie care avea multe date. Era un sistem de publicitate cu un num\u0103r uria\u0219 de evenimente care trebuiau stocate undeva. \u0218i la un moment dat a ap\u0103rut ClickHouse. Am \u00eenc\u0103rcat datele acolo \u0219i \u00een prima faz\u0103 totul a fost bine, dar apoi ClickHouse s-a pr\u0103bu\u0219it. La acel moment, am decis c\u0103 nu avem nevoie de el. <\/p>\n<p><\/p>\n<p>Dup\u0103 un an, ne-am \u00eentors la ideea de a folosi ClickHouse \u0219i trebuia s\u0103 g\u0103sim o metod\u0103 de a scrie date acolo. Condi\u021bia era c\u0103 hardware-ul era foarte slab, resursele erau pu\u021bine. Dar a\u0219a am lucrat mereu, a\u0219a c\u0103 ne-am \u00eendreptat spre protocolul nativ.<\/p>\n<p><\/p>\n<p>Fiindc\u0103 lucram pe Go, era clar c\u0103 avem nevoie de un driver pe Go. Am lucrat practic full-time la el \u2013 aceasta era sarcina mea de lucru. P\u00e2n\u0103 la un moment dat, l-am adus la un nivel func\u021bional, iar \u00een principiu nimeni nu se a\u0219tepta ca altcineva \u00een afar\u0103 de noi s\u0103-l foloseasc\u0103. Apoi a venit CloudFlare cu exact aceea\u0219i problem\u0103, iar pentru o vreme am colaborat cu ei foarte bine, deoarece aveau acelea\u0219i sarcini. \u0218i am f\u0103cut asta at\u00e2t \u00een ClickHouse, c\u00e2t \u0219i \u00een driver. <\/p>\n<p><\/p>\n<p>La un moment dat, pur \u0219i simplu am renun\u021bat s\u0103 m\u0103 ocup de ele, pentru c\u0103 activitatea mea \u00een ceea ce prive\u0219te ClickHouse \u0219i munca s-a schimbat pu\u021bin. De aceea problemele nu sunt \u00eenchise. Din c\u00e2nd \u00een c\u00e2nd, \u00een depozit contribuie oameni care au nevoie de ceva. Atunci privesc pull request-uri \u0219i uneori chiar corectez ceva eu \u00eensumi, dar se \u00eent\u00e2mpl\u0103 rar.<\/p>\n<p><\/p>\n<p>Vreau s\u0103 revin la driver. Cu c\u00e2\u021biva ani \u00een urm\u0103, c\u00e2nd a \u00eenceput totul, ClickHouse era diferit \u0219i avea alte capacit\u0103\u021bi. Acum, am \u00een\u021belegerea de a rescrie driverul pentru a fi mai bine. Dac\u0103 se va \u00eent\u00e2mpla asta, versiunea 2 va fi, \u00een orice caz, incompatibil\u0103 din cauza workaround-urilor acumulate. <\/p>\n<p><\/p>\n<p>Nu \u0219tiu cum s\u0103 organizez acest lucru. Eu \u00eensumi nu am prea mult timp. Dac\u0103 va fi cineva care va \u00eembun\u0103t\u0103\u021bi driverul, \u00eei pot ajuta \u0219i le pot explica ce s\u0103 fac\u0103. Dar participarea activ\u0103 a \u00abYandex\u00bb \u00een dezvoltarea proiectului nu a fost discutat\u0103 \u00eenc\u0103. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> De fapt, momentan nu exist\u0103 nicio birocra\u021bie cu privire la ace\u0219ti drivere. Singurul lucru este c\u0103 au fost oficializate, adic\u0103 acest driver este recunoscut ca solu\u021bie oficial\u0103 implicit\u0103 pentru Go. Exist\u0103 \u0219i alte drivere, dar acestea sunt separate. <\/p>\n<p><\/p>\n<p>Intern, nu avem nicio dezvoltare pentru ace\u0219ti drivere. \u00centrebarea este dac\u0103 vom putea angaja o persoan\u0103 separat\u0103, nu doar pentru acest driver, ci pentru dezvoltarea tuturor driverelor comunit\u0103\u021bii, sau dac\u0103 vom putea g\u0103si pe cineva din exterior. <\/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>Dic\u021bionarul extern nu se ridic\u0103 dup\u0103 repornire cu setarea lazy_load activat\u0103. Ce ar trebui s\u0103 facem?<\/h2>\n<p><\/p>\n<blockquote><p>Avem activat\u0103 setarea lazy_load \u0219i dup\u0103 repornirea serverului, dic\u021bionarul nu se ridic\u0103 de la sine. Se ridic\u0103 doar dup\u0103 ce utilizatorul acceseaz\u0103 acest dic\u021bionar. Iar la prima accesare, d\u0103 o eroare. Exist\u0103 vreo modalitate de a \u00eenc\u0103rca automat dic\u021bionarele prin ClickHouse, sau trebuie s\u0103 control\u0103m mereu disponibilitatea lor, pentru ca utilizatorii s\u0103 nu primeasc\u0103 erori?<\/p>\n<p>Poate c\u0103 avem o versiune veche de ClickHouse, de aceea dic\u021bionarul nu s-a \u00eenc\u0103rcat automat. Poate fi a\u0219a?<\/p><\/blockquote>\n<p>\u00cen primul r\u00e2nd, dic\u021bionarele pot fi for\u021bat \u00eenc\u0103rcate printr-o interogare. <strong>system reload dictionaries<\/strong>. \u00cen al doilea r\u00e2nd, cu privire la eroare \u2014 dac\u0103 dic\u021bionarul a fost deja \u00eenc\u0103rcat, atunci cererile vor func\u021biona pe datele care au fost \u00eenc\u0103rcate. Dac\u0103 dic\u021bionarul nu a fost \u00eenc\u0103 \u00eenc\u0103rcat, acesta va fi \u00eenc\u0103rcat chiar \u00een timpul cererii.<\/p>\n<p><\/p>\n<p>Pentru dic\u021bionarele mari, acest lucru nu este foarte convenabil. De exemplu, trebuie s\u0103 extragi un milion de r\u00e2nduri din MySQL. Cineva face un select simplu, dar acest select va a\u0219tepta acel milion de r\u00e2nduri. Exist\u0103 dou\u0103 solu\u021bii. Prima \u2014 dezactivarea lazy_load. A doua \u2014 atunci c\u00e2nd serverul porne\u0219te, \u00eenainte de a-l supune unei sarcini, s\u0103 faci <strong>system reload dictionary<\/strong> sau pur \u0219i simplu s\u0103 efectuezi o cerere care folose\u0219te dic\u021bionarul. Atunci dic\u021bionarul va fi \u00eenc\u0103rcat. Este necesar s\u0103 controlezi disponibilitatea dic\u021bionarelor cu setarea lazy_load activat\u0103, deoarece ClickHouse nu le aduce automat.<\/p>\n<p><\/p>\n<p>R\u0103spunsul la ultima \u00eentrebare este \u2014 fie versiunea este veche, fie trebuie s\u0103 depanezi. <\/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>Cum s\u0103 procedez c\u00e2nd system reload dictionaries nu \u00eencarc\u0103 niciunul dintre numeroasele dic\u021bionare, dac\u0103 m\u0103car unul dintre ele e\u0219ueaz\u0103 cu o eroare?<\/h2>\n<p><\/p>\n<blockquote><p>Mai exist\u0103 o \u00eentrebare cu privire la system reload dictionaries. Avem dou\u0103 dic\u021bionare \u2014 unul nu se \u00eencarc\u0103, cel\u0103lalt se \u00eencarc\u0103. System reload dictionaries \u00een acest caz nu va \u00eenc\u0103rca niciun dic\u021bionar, \u0219i este necesar s\u0103 \u00eenc\u0103rc\u0103m specific dic\u021bionarul dup\u0103 numele s\u0103u prin system reload dictionary. Este aceasta legat\u0103 tot de versiunea ClickHouse?<\/p><\/blockquote>\n<p>Vreau s\u0103 te bucur. Acest comportament s-a schimbat. A\u0219adar, dac\u0103 actualizezi ClickHouse, acesta se va schimba \u0219i el. Dac\u0103 nu e\u0219ti mul\u021bumit de comportamentul actual <strong>system reload dictionaries<\/strong>, actualiza\u021bi, \u0219i s\u0103 sper\u0103m c\u0103 se va schimba \u00een bine.<\/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>Exist\u0103 vreo metod\u0103 de a configura datele \u00een config-ul ClickHouse, dar s\u0103 nu le expunem \u00een caz de erori?<\/h2>\n<p><\/p>\n<blockquote><p>Urm\u0103toarea \u00eentrebare este despre erorile legate de dic\u021bionar, \u0219i anume despre acreditive. Am definit acreditivele de conectare \u00een configura\u021bia ClickHouse pentru dic\u021bionar, iar \u00een caz de eroare ob\u021binem aceste acreditive \u0219i parola \u00een r\u0103spuns. <\/p>\n<p>Am rezolvat aceast\u0103 eroare mut\u00e2nd acreditivele \u00een configura\u021bia driverului ODBC. Exist\u0103 vreo modalitate de a configura acreditivele \u00een configura\u021bia ClickHouse, dar f\u0103r\u0103 a expune aceste acreditive \u00een caz de erori?<\/p><\/blockquote>\n<p>Aici solu\u021bia este \u00eentr-adev\u0103r \u2014 s\u0103 specifici aceste acreditive \u00een odbc.ini, iar \u00een ClickHouse s\u0103 specifici doar numele sursei de date ODBC. Pentru celelalte surse de dic\u021bionare nu va fi a\u0219a \u2014 nici pentru dic\u021bionarul cu MySQL, nici pentru celelalte nu ar trebui s\u0103 vezi parola \u00een mesajul de eroare. Voi verifica \u0219i pentru ODBC \u2014 dac\u0103 exist\u0103 a\u0219a ceva, trebuie pur \u0219i simplu eliminat.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Bonus: fundaluri pentru Zoom de la petreceri<\/h2>\n<p><\/p>\n<p>C\u00e2nd dai click pe&nbsp;imagine, cititorii cei mai dedica\u021bi vor avea acces la fundaluri bonus din&nbsp;\u00eent\u00e2lniri. Stingem incendiul al\u0103turi de&nbsp;mascotele tehnologiilor Avito, discut\u0103m cu&nbsp;colegii din&nbsp;camera administratorului de sistem sau dintr-un club de computere old-school \u0219i desf\u0103\u0219ur\u0103m \u00eent\u00e2lniri sub&nbsp;pod pe&nbsp;fundalul graffiti-ului.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse pentru utilizatori avansa\u021bi \u00een \u00eentreb\u0103ri \u0219i r\u0103spunsuri\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Sursa: <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.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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 pentru utilizatori avansa\u021bi \u00een \u00eentreb\u0103ri \u0219i r\u0103spunsuri | ProHoster","description":"\u00cen aprilie, inginerii de la Avito s-au adunat pentru \u00eent\u00e2lniri online cu principalul dezvoltator ClickHouse, Alexei Milovidov, \u0219i Kirill Shvakov, dezvoltator Golang de la compania Integros.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/80775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}