ProHoster > Blogs > Administrācija > ClickHouse pieredzējuÅ”iem lietotājiem jautājumos un atbildēs

ClickHouse pieredzējuÅ”iem lietotājiem jautājumos un atbildēs

AprÄ«lÄ« Avito inženieri pulcējās uz tieÅ”saistes tikÅ”anos ar galveno ClickHouse izstrādātāju Alekseju Milovidovu un Kirilu Å vakovu, Golang izstrādātāju no Integros. Pārrunājām, kā lietojam datu bāzes pārvaldÄ«bas sistēmu un ar kādām grÅ«tÄ«bām saskaramies.

Pamatojoties uz tikÅ”anos, esam izveidojuÅ”i rakstu ar ekspertu atbildēm uz mÅ«su un auditorijas jautājumiem par dublÄ“Å”anu, datu atkārtotu sadalÄ«Å”anu, ārējām vārdnÄ«cām, Golang draiveri un ClickHouse versiju atjaunināŔanu. Tas var bÅ«t noderÄ«gi izstrādātājiem, kuri jau aktÄ«vi strādā ar Yandex DBVS un interesējas par tās tagadni un nākotni. Pēc noklusējuma atbildes sniedz Aleksejs Milovidovs, ja vien nav rakstÄ«ts citādi.

Esiet uzmanīgi, zem griezuma ir daudz teksta. Mēs ceram, ka saturs ar jautājumiem palīdzēs jums orientēties.

ClickHouse pieredzējuÅ”iem lietotājiem jautājumos un atbildēs

saturs

Ja nevēlaties lasīt tekstu, varat noskatīties sanāksmju ierakstu mūsu YouTube kanālā. Laika kodi ir pirmajā komentārā zem video.

ClickHouse tiek pastāvīgi atjaunināts, bet mūsu dati netiek atjaunināti. Ko darīt ar to?

ClickHouse tiek pastāvīgi atjaunināts, un mūsu dati, kas tika optimizēti galīgi apstrādāti, netiek atjaunināti un atrodas rezerves kopijā.

Pieņemsim, ka radās problēma un dati tika zaudēti. Mēs nolēmām atjaunot, un izrādÄ«jās, ka vecie nodalÄ«jumi, kas tiek glabāti rezerves serveros, ļoti atŔķiras no paÅ”laik izmantotās ClickHouse versijas. Ko darÄ«t Ŕādā situācijā, un vai tas ir iespējams?

Situācija, kurā jūs atjaunojāt datus no dublējuma vecā formātā, bet tas nesavienojas ar jauno versiju, nav iespējama. Mēs pārliecināmies, ka ClickHouse datu formāts vienmēr ir atpakaļsaderīgs. Tas ir daudz svarīgāk nekā funkcionalitātes atgriezeniskā savietojamība, ja ir mainījusies kādas reti izmantotas funkcijas darbība. Jaunajai ClickHouse versijai vienmēr jābūt iespējai nolasīt datus, kas tiek glabāti diskā. Tas ir likums.

Kāda ir paÅ”reizējā paraugprakse datu dublÄ“Å”anai no ClickHouse?

Kā izveidot dublējumus, ņemot vērā, ka mums ir optimizētas gala darbības, milzīga terabaitu datubāze un dati, kas tiek atjaunināti, teiksim, pēdējās trīs dienas, un tad ar to nenotiek nekādas procedūras?

Mēs varam izveidot savu risinājumu un rakstÄ«t uz bash: savākt Ŕīs rezerves kopijas Ŕādā un tādā veidā. VarbÅ«t nevajag neko vilkt kruÄ·us, un velosipēds ir izgudrots jau sen?

Sāksim ar labāko praksi. Mani kolēģi vienmēr iesaka, atbildot uz jautājumiem par dublÄ“Å”anu, atgādināt par pakalpojumu Yandex.Cloud, kur Ŕī problēma jau ir atrisināta. Tāpēc izmantojiet to, ja iespējams.

Nav pilnÄ«ga risinājuma dublÄ“Å”anai, kas ir simtprocentÄ«gi iebÅ«vēts ClickHouse. Ir dažas sagataves, kuras var izmantot. Lai iegÅ«tu pilnÄ«gu risinājumu, jums bÅ«s vai nu nedaudz jāpielāgojas manuāli, vai arÄ« jāizveido iesaiņojumi skriptu veidā.

SākŔu ar vienkārŔākajiem risinājumiem un beigŔu ar vissarežģītākajiem atkarībā no datu apjoma un klastera lieluma. Jo lielāks ir klasteris, jo sarežģītāks kļūst risinājums.

Ja tabula ar datiem aizņem tikai dažus gigabaitus, dublÄ“Å”anu var veikt Ŕādi:

  1. Saglabājiet tabulas definīciju, t.i., metadatus parādīt izveidot tabulu.
  2. Izveidojiet izgāztuvi, izmantojot ClickHouse klientu - atlasīt * no galda uz failu. Pēc noklusējuma jūs saņemsit failu TabSeparated formātā. Ja vēlaties strādāt efektīvāk, varat to izdarīt vietējā formātā.

Ja datu apjoms ir lielāks, tad dublÄ“Å”ana prasÄ«s vairāk laika un daudz vietas. To sauc par loÄ£isko dublējumu; tas nav saistÄ«ts ar ClickHouse datu formātu. Ja tā ir, kā pēdējo lÄ«dzekli varat izveidot dublējumu un augÅ”upielādēt to MySQL atkopÅ”anai.

Izvērstākiem gadÄ«jumiem ClickHouse ir iebÅ«vēta iespēja izveidot nodalÄ«jumu momentuzņēmumu vietējā failu sistēmā. Å Ä« funkcija ir pieejama pēc pieprasÄ«juma mainÄ«t galda iesaldÄ“Å”anas nodalÄ«jumu. Vai vienkārÅ”i mainÄ«t galda iesaldÄ“Å”anu - Å”is ir visas tabulas momentuzņēmums.

Momentuzņēmums tiks izveidots konsekventi vienai tabulai vienā shardā, tas ir, Ŕādā veidā nav iespējams izveidot konsekventu visa klastera momentuzņēmumu. Bet lielākajai daļai uzdevumu Ŕādas vajadzÄ«bas nav, un pietiek ar katras sharda pieprasÄ«juma izpildi un konsekventa momentuzņēmuma iegÅ«Å”anu. Tas ir izveidots cieto saiÅ”u veidā un tāpēc neaizņem papildu vietu. Pēc tam nokopējiet Å”o momentuzņēmumu uz dublējuma serveri vai krātuvi, ko izmantojat dublÄ“Å”anai.

Šādas dublējuma atjaunoÅ”ana ir diezgan vienkārÅ”a. Vispirms izveidojiet tabulas, izmantojot esoŔās tabulu definÄ«cijas. Pēc tam nokopējiet saglabātos nodalÄ«jumu momentuzņēmumus Ŕīm tabulām uz Directory-Detached un palaidiet vaicājumu pievienojiet nodalÄ«jumu. Å is risinājums ir diezgan piemērots visnopietnākajiem datu apjomiem.

Dažkārt vajag kaut ko vēl forŔāku ā€“ gadÄ«jumos, kad uz katra servera ir desmitiem vai pat simtiem terabaitu un simtiem serveru. Å eit ir risinājums, ko es paņēmu no saviem kolēģiem no Yandex.Metrica. Es to neieteiktu visiem - izlasiet un izlemiet paÅ”i, vai tas ir piemērots vai nē.

Vispirms jums ir jāizveido vairāki serveri ar lieliem disku plauktiem. Pēc tam Å”ajos serveros izveidojiet vairākus ClickHouse serverus un konfigurējiet tos tā, lai tie darbotos kā cita kopija tām paŔām Ŕķembām. Un pēc tam Å”ajos serveros izmantojiet failu sistēmu vai kādu rÄ«ku, kas ļauj izveidot momentuzņēmumus. Å eit ir divas iespējas. Pirmā opcija ir LVM momentuzņēmumi, otrā iespēja ir ZFS operētājsistēmā Linux.

Pēc tam katru dienu ir jāizveido momentuzņēmums, tas melos un aizņems kādu vietu. Dabiski, ja dati mainās, laika gaitā vietas apjoms palielināsies. Å o momentuzņēmumu var jebkurā brÄ«dÄ« izņemt un datus atjaunot, tāds dÄ«vains risinājums. Turklāt mums arÄ« jāierobežo Ŕīs kopijas konfigurācijā, lai tās nemēģinātu kļūt par lÄ«deriem.

Vai Å”ahtās varēs organizēt kontrolētu repliku nobÄ«di?

Šogad jūs plānojat izgatavot vārpstas ClickHouse. Vai tajās varēs organizēt kontrolētu repliku nobīdi? Mēs vēlētos to izmantot, lai pasargātu sevi no negatīviem scenārijiem ar izmaiņām un citām izmaiņām.

Vai ir iespējams veikt kādu atcelÅ”anu alteriem? Piemēram, esoÅ”ajā Å”ahtā ņemiet un sakiet, ka lÄ«dz Å”im brÄ«dim jÅ«s piemērojat izmaiņas un no Ŕī brīža pārtraucat lietot izmaiņas?

Ja komanda nonāca mÅ«su klasterÄ« un to sabojāja, tad mums ir nosacÄ«ta replika ar stundas nobÄ«di, kur mēs varam teikt, ka izmantosim to Å”obrÄ«d, bet mēs tai nepiemērosim izmaiņas pēdējās desmit minÅ«tēs?

Pirmkārt, par kontrolēto repliku aizkavÄ“Å”anos. Bija Ŕāds lietotāju pieprasÄ«jums, un mēs izveidojām problēmu vietnē Github ar pieprasÄ«jumu: "Ja kādam tas ir vajadzÄ«gs, lÅ«dzu, ielieciet sirdi." Neviens nepiegādāja, un problēma tika slēgta. Taču Å”o iespēju jau var iegÅ«t, iestatot ClickHouse. Tiesa, tikai sākot ar versiju 20.3.

ClickHouse pastāvīgi veic datu apvienoŔanu fonā. Kad sapludināŔana ir pabeigta, noteikta datu kopa tiek aizstāta ar lielāku daļu. Tajā paŔā laikā datu daļas, kas tur bija iepriekŔ, kādu laiku turpina palikt diskā.

Pirmkārt, tie tiek saglabāti tik ilgi, kamēr ir atlasÄ«ti vaicājumi, kas tos izmanto, lai nodroÅ”inātu nebloķējoÅ”u darbÄ«bu. AtlasÄ«tie vaicājumi ir viegli nolasāmi no veciem gabaliem.

Otrkārt, ir arī laika slieksnis - veci datu gabali astoņas minūtes guļ diskā. Šīs astoņas minūtes var pielāgot un pat pārvērst par vienu dienu. Tas maksās vietu diskā: atkarībā no datu plūsmas izrādās, ka pēdējā dienā dati ne tikai dubultosies, bet var kļūt piecas reizes vairāk. Bet, ja ir nopietna problēma, varat apturēt ClickHouse serveri un visu sakārtot.

Tagad rodas jautājums, kā tas aizsargā pret izmaiņām. Å eit ir vērts paskatÄ«ties dziļāk, jo vecākajās ClickHouse versijās alter darbojās tā, ka tas vienkārÅ”i mainÄ«ja gabalus tieÅ”i. Dažos failos ir daļa datu, un mēs, piemēram, mainÄ«t pilienu kolonnu. Pēc tam Ŕī kolonna tiek fiziski noņemta no visiem gabaliem.

Taču, sākot ar versiju 20.3, mainÄ«Å”anas mehānisms ir pilnÄ«bā mainÄ«ts, un tagad dati vienmēr ir nemainÄ«gi. Tie nemaz nemainās ā€” izmaiņas tagad darbojas tāpat kā sapludināŔanas. Tā vietā, lai nomainÄ«tu gabalu uz vietas, mēs izveidojam jaunu. Jaunajā daļā faili, kas nav mainÄ«ti, kļūst par cietajām saitēm, un, ja mēs izdzēsÄ«sim kolonnu, jaunajā daļā tās vienkārÅ”i trÅ«ks. Vecais gabals pēc noklusējuma tiks izdzēsts pēc astoņām minÅ«tēm, un Å”eit jÅ«s varat pielāgot iepriekÅ” minētos iestatÄ«jumus.

Tas pats attiecas uz izmaiņām, piemēram, mutācijām. Kad jÅ«s to darāt mainÄ«t dzēst vai mainÄ«t atjauninājumu, tas nemaina gabalu, bet rada jaunu. Un pēc tam izdzÄ“Å” veco.

Ko darīt, ja tabulas struktūra ir mainījusies?

Kā atjaunot dublējumu, kas tika izveidots, izmantojot veco shēmu? Un otrs jautājums ir par gadÄ«jumu ar momentuzņēmumiem un failu sistēmas rÄ«kiem. Vai Å”eit ir labs Btrfs, nevis ZFS uz Linux LVM?

Ja jÅ«s to darāt pievienojiet nodalÄ«jumu starpsienas ar atŔķirÄ«gu struktÅ«ru, tad ClickHouse pateiks, ka tas nav iespējams. Å is ir risinājums. Pirmais ir izveidot MergeTree tipa pagaidu tabulu ar veco struktÅ«ru, pievienot tai datus, izmantojot pielikumu, un veikt izmaiņas vaicājumu. Pēc tam varat kopēt vai pārsÅ«tÄ«t Å”os datus un pievienot vēlreiz, vai arÄ« izmantot pieprasÄ«jumu mainÄ«t tabulas pārvietoÅ”anas nodalÄ«jumu.

Tagad otrais jautājums ir, vai Btrfs var izmantot. Sākumā, ja jums ir LVM, tad pietiek ar LVM momentuzņēmumiem, un failu sistēma var bÅ«t ext4, tas nav svarÄ«gi. Izmantojot Btrts, viss ir atkarÄ«gs no jÅ«su pieredzes tā lietoÅ”anā. Å Ä« ir nobriedusi failu sistēma, taču joprojām pastāv zināmas aizdomas par to, kā viss izdosies praksē konkrētajā scenārijā. Es neieteiktu to izmantot, ja vien jums nav Btrfs ražoÅ”anā.

Kāda ir paÅ”reizējā datu atkārtotas sadalÄ«Å”anas paraugprakse?

Jautājums par sadalÄ«Å”anu ir sarežģīts un daudzpusÄ«gs. Å eit ir vairākas iespējamās atbildes. JÅ«s varat iet no vienas puses un teikt: ClickHouse nav iebÅ«vēta pārdalÄ«Å”anas funkcija. Bet baidos, ka Ŕī atbilde nevienam nederēs. Tāpēc varat pāriet no otras puses un teikt, ka ClickHouse ir daudz veidu, kā atkārtoti sadalÄ«t datus.

Ja klasterÄ« pietrÅ«kst vietas vai tas nevar apstrādāt slodzi, jÅ«s pievienojat jaunus serverus. Bet Å”ie serveri pēc noklusējuma ir tukÅ”i, par tiem nav datu, nav slodzes. Dati ir jāpārkārto tā, lai tie bÅ«tu vienmērÄ«gi sadalÄ«ti jaunajā, lielākā klasterÄ«.

Pirmais veids, kā to var izdarÄ«t, ir kopēt daļu nodalÄ«jumu uz jauniem serveriem, izmantojot pieprasÄ«jumu mainÄ«t tabulas ielādes nodalÄ«jumu. Piemēram, jums bija nodalÄ«jumi pa mēneÅ”iem, un jÅ«s lietojat 2017. gada pirmo mēnesi un kopējat to uz jaunu serveri, pēc tam treÅ”o mēnesi kopējat uz kādu citu jaunu serveri. Un jÅ«s to darāt, lÄ«dz tas kļūst vairāk vai mazāk vienmērÄ«gs.

PārsÅ«tÄ«Å”anu var veikt tikai tiem nodalÄ«jumiem, kas ierakstÄ«Å”anas laikā nemainās. Jauniem nodalÄ«jumiem ierakstÄ«Å”ana bÅ«s jāatspējo, jo to pārsÅ«tÄ«Å”ana nav atomāra. Pretējā gadÄ«jumā jÅ«s iegÅ«sit datu dublikātus vai nepilnÄ«bas. Tomēr Ŕī metode ir praktiska un darbojas diezgan efektÄ«vi. Gatavās saspiestās starpsienas tiek pārsÅ«tÄ«tas pa tÄ«klu, tas ir, dati netiek saspiesti vai atkārtoti kodēti.

Å ai metodei ir viens trÅ«kums, un tas ir atkarÄ«gs no sadalÄ«Å”anas shēmas, no tā, vai jÅ«s piekritāt Å”ai sadalÄ«Å”anas shēmai, kāda jums bija sadalÄ«Å”anas atslēga. JÅ«su piemērā gadÄ«jumam ar metriku sadalÄ«Å”anas atslēga ir ceļa hash. Atlasot izkliedēto tabulu, tā vienlaikus tiek novirzÄ«ta uz visām klastera daļām un no turienes tiek ņemti dati.

Tas nozÄ«mē, ka jums faktiski nav nozÄ«mes tam, kādi dati tika iegÅ«ti uz kura lauskas. Galvenais, lai dati pa vienu ceļu nonāktu uz vienas Ŕķembas, bet kuram nav nozÄ«mes. Å ajā gadÄ«jumā gatavu nodalÄ«jumu pārsÅ«tÄ«Å”ana ir ideāla, jo ar atlasÄ«tajiem vaicājumiem jÅ«s saņemsit arÄ« pilnÄ«gus datus - vai pirms atkārtotas sadalÄ«Å”anas vai pēc tam, shēmai nav Ä«sti nozÄ«mes.

Bet ir gadÄ«jumi, kas ir sarežģītāki. Ja lietojumprogrammas loÄ£ikas lÄ«menÄ« paļaujaties uz Ä«paÅ”u sadalÄ«Å”anas shēmu, ka Å”is klients atrodas uz tādas un tādas sharda un pieprasÄ«jumu var nosÅ«tÄ«t tieÅ”i tur, nevis uz tabulu Distributed. Vai arÄ« jÅ«s izmantojat diezgan jaunāku ClickHouse versiju un esat iespējojis Å”o iestatÄ«jumu optimizēt izlaist neizmantotās shards. Å ajā gadÄ«jumā atlases vaicājuma laikā tiks analizēta izteiksme sadaļā kur un tiks aprēķināts, kuras shards ir jāizmanto saskaņā ar sadalÄ«Å”anas shēmu. Tas darbojas, ja dati tiek sadalÄ«ti precÄ«zi saskaņā ar Å”o sadalÄ«Å”anas shēmu. Ja tos pārkārtojāt manuāli, sarakste var mainÄ«ties.

Tātad Ŕī ir metode numur viens. Un es gaidu jÅ«su atbildi, vai metode ir piemērota, vai arÄ« turpināsim.

Vladimirs Kolobajevs, uzņēmuma Avito vadoÅ”ais sistēmas administrators: Aleksej, jÅ«su pieminētā metode nedarbojas Ä«paÅ”i labi, ja jums ir nepiecieÅ”ams sadalÄ«t slodzi, ieskaitot lasÄ«Å”anu. Mēs varam pārņemt ikmēneÅ”a nodalÄ«jumu un iepriekŔējo mēnesi var pārcelt uz citu mezglu, taču, kad tiks saņemts pieprasÄ«jums pēc Å”iem datiem, mēs tos tikai ielādēsim. Bet mēs vēlētos ielādēt visu klasteru, jo pretējā gadÄ«jumā kādu laiku visu lasÄ«Å”anas slodzi apstrādās divas lauskas.

Aleksejs Milovidovs: Atbilde Å”eit ir dÄ«vaina - jā, tas ir slikti, bet tas varētu darboties. Es paskaidroÅ”u, kā tieÅ”i. Ir vērts apskatÄ«t ielādes scenāriju, kas ir aiz jÅ«su datiem. Ja tie ir pārraudzÄ«bas dati, tad gandrÄ«z droÅ”i varam teikt, ka lielākā daļa pieprasÄ«jumu attiecas uz jauniem datiem.

JÅ«s instalējāt jaunus serverus, migrējāt vecos nodalÄ«jumus, kā arÄ« mainÄ«jāt jaunu datu ierakstÄ«Å”anas veidu. Un svaigi dati tiks izplatÄ«ti visā klasterÄ«. Tādējādi jau pēc piecām minÅ«tēm pieprasÄ«jumi par pēdējām piecām minÅ«tēm vienmērÄ«gi ielādēs klasteru; pēc dienas XNUMX stundu pieprasÄ«jumi vienmērÄ«gi ielādēs kopu. Un pieprasÄ«jumi par iepriekŔējo mēnesi, diemžēl, nonāks tikai daļā klasteru serveru.

Taču bieži vien jums nebÅ«s pieprasÄ«jumu tieÅ”i 2019. gada februārim. Visticamāk, ja pieprasÄ«jumi nonāks 2019. gadā, tad tie bÅ«s uz visu 2019. gadu - uz lielu laika periodu, nevis uz kādu mazu diapazonu. Un Ŕādi pieprasÄ«jumi arÄ« varēs vienmērÄ«gi ielādēt klasteru. Bet kopumā jÅ«su piezÄ«me ir pilnÄ«gi pareiza, ka tas ir ad hoc risinājums, kas neizplata datus pilnÄ«gi vienmērÄ«gi.

Man ir vēl daži punkti, lai atbildētu uz jautājumu. Viens no tiem ir par to, kā sākotnēji izveidot sadalÄ«Å”anas shēmu, lai atkārtota sadalÄ«Å”ana radÄ«tu mazāk sāpju. Tas ne vienmēr ir iespējams.

Piemēram, jums ir uzraudzÄ«bas dati. UzraudzÄ«bas dati pieaug trÄ«s iemeslu dēļ. Pirmais ir vēsturisko datu uzkrāŔana. Otrais ir satiksmes pieaugums. Un treÅ”ais ir pārraudzÄ«bai pakļauto lietu skaita pieaugums. Ir jauni mikropakalpojumi un metrika, kas ir jāsaglabā.

Iespējams, ka no tiem lielākais pieaugums saistÄ«ts ar treÅ”o iemeslu - monitoringa izmantoÅ”anas pieaugumu. Un Å”ajā gadÄ«jumā ir vērts aplÅ«kot slodzes raksturu, kādi ir galvenie atlases vaicājumi. Pamata atlases vaicājumi, visticamāk, bÅ«s balstÄ«ti uz kādu metrikas apakÅ”kopu.

Piemēram, kāda pakalpojuma CPU lietojums dažos serveros. Izrādās, ka ir noteikta atslēgu apakÅ”kopa, ar kuras palÄ«dzÄ«bu jÅ«s iegÅ«stat Å”os datus. Un pats pieprasÄ«jums pēc Å”iem datiem, visticamāk, ir diezgan vienkārÅ”s un tiek izpildÄ«ts desmitos milisekundēs. Izmanto uzraudzÄ«bas pakalpojumiem un informācijas paneļiem. Es ceru, ka es to pareizi sapratu.

Vladimirs Kolobajevs: Fakts ir tāds, ka mēs ļoti bieži apelējam pie vēsturiskiem datiem, jo ā€‹ā€‹mēs salÄ«dzinām paÅ”reizējo situāciju ar vēsturisko reāllaikā. Un mums ir svarÄ«gi ātri piekļūt lielam datu apjomam, un ClickHouse ar to paveic lielisku darbu.

Jums ir pilnÄ«ga taisnÄ«ba, mēs piedzÄ«vojam lielāko daļu lasÄ«Å”anas pieprasÄ«jumu pēdējā dienā, tāpat kā jebkura uzraudzÄ«bas sistēma. Bet tajā paŔā laikā arÄ« vēsturisko datu slodze ir diezgan liela. Tas bÅ«tÄ«bā ir no brÄ«dināŔanas sistēmas, kas iet apkārt ik pēc trÄ«sdesmit sekundēm un saka ClickHouse: ā€œSniedziet man datus par pēdējām seŔām nedēļām. Tagad izveidojiet man no tiem kaut kādu mainÄ«go vidējo vērtÄ«bu un salÄ«dzināsim paÅ”reizējo vērtÄ«bu ar vēsturisko.

Es gribētu teikt, ka Ŕādiem ļoti neseniem pieprasÄ«jumiem mums ir vēl viena maza tabula, kurā mēs glabājam tikai divu dienu datus, un tajā ieplÅ«st galvenie pieprasÄ«jumi. Mēs nosÅ«tām tikai lielus vēsturiskus vaicājumus uz lielo Ŕķelto tabulu.

Aleksejs Milovidovs: Diemžēl tas izrādās slikti piemērojams jÅ«su scenārijam, bet es jums pastāstÄ«Å”u par divām sliktām un sarežģītām sadalÄ«Å”anas shēmām, kuras nav jāizmanto, bet kuras tiek izmantotas manu draugu servisā.

Ir galvenā kopa ar Yandex.Metrica notikumiem. Notikumi ir lapu skatījumi, klikŔķi un reklāmguvumi. Lielākā daļa pieprasījumu tiek nosūtīti uz noteiktu vietni. Jūs atverat pakalpojumu Yandex.Metrica, jums ir vietne - avito.ru, dodieties uz pārskatu, un tiek veikts pieprasījums jūsu vietnei.

Taču ir arÄ« citi pieprasÄ«jumi ā€” analÄ«tiski un globāli ā€”, ko izsaka iekŔējie analÄ«tiÄ·i. Katram gadÄ«jumam es atzÄ«mēju, ka iekŔējie analÄ«tiÄ·i pieprasa tikai Yandex pakalpojumus. Tomēr pat Yandex pakalpojumi aizņem ievērojamu daļu no visiem datiem. Tie ir pieprasÄ«jumi nevis konkrētiem skaitÄ«tājiem, bet gan plaŔākai filtrÄ“Å”anai.

Kā sakārtot datus tā, lai viss darbotos efektÄ«vi vienam skaitÄ«tājam un arÄ« globālajiem vaicājumiem? Vēl viena grÅ«tÄ«ba ir tāda, ka ClickHouse pieprasÄ«jumu skaits metrikas klasterim ir vairāki tÅ«kstoÅ”i sekundē. Tajā paŔā laikā viens ClickHouse serveris nevar apstrādāt netriviālus pieprasÄ«jumus, piemēram, vairākus tÅ«kstoÅ”us sekundē.

Klastera lielums ir seÅ”i simti serveru. Ja jÅ«s vienkārÅ”i pārvelkat Distributed tabulu virs Ŕī klastera un nosÅ«tāt tur vairākus tÅ«kstoÅ”us pieprasÄ«jumu, tas kļūs vēl sliktāk nekā nosÅ«tÄ«t tos vienam serverim. No otras puses, uzreiz tiek noraidÄ«ta iespēja, ka dati tiek sadalÄ«ti vienmērÄ«gi, un mēs ejam un pieprasām no visiem serveriem.

Ir variants, kas ir diametrāli pretējs. Iedomājieties, ja mēs sadalām datus dažādās vietnēs un vienas vietnes pieprasÄ«jums tiek nosÅ«tÄ«ts uz vienu fragmentu. Tagad klasteris spēs apstrādāt desmit tÅ«kstoÅ”us pieprasÄ«jumu sekundē, bet uz vienas skaidas jebkurÅ” pieprasÄ«jums darbosies pārāk lēni. Tas vairs netiks mērogots caurlaidspējas ziņā. It Ä«paÅ”i, ja Ŕī ir vietne avito.ru. Es neatklāŔu noslēpumu, ja teikÅ”u, ka Avito ir viena no visvairāk apmeklētajām vietnēm RuNet. Un apstrādāt to uz vienas Ŕķembas bÅ«tu neprāts.

Tāpēc sadalÄ«Å”anas shēma ir izstrādāta viltÄ«gākā veidā. Viss klasteris ir sadalÄ«ts vairākos klasteros, kurus mēs saucam par slāņiem. Katrs klasteris satur no desmitiem lÄ«dz vairākiem desmitiem lauskas. Kopumā ir trÄ«sdesmit deviņas Ŕādas kopas.

Kā tas viss mērogos? Klasteru skaits nemainās ā€“ kāds pirms dažiem gadiem bija trÄ«sdesmit deviņi, tāds arÄ« paliek. Bet katrā no tiem mēs pakāpeniski palielinām lauskas skaitu, uzkrājot datus. Un sadalÄ«Å”anas shēma kopumā ir Ŕāda: Å”ie klasteri ir sadalÄ«ti vietnēs, un, lai saprastu, kura vietne atrodas kurā klasterÄ«, tiek izmantota atseviŔķa MySQL metabāze. Viena vietne - vienā klasterÄ«. Un tajā notiek sadalÄ«Å”ana saskaņā ar apmeklētāju ID.

Ierakstot mēs tos sadalām ar apmeklētāja ID dalÄ«juma atlikumu. Bet, pievienojot jaunu fragmentu, sadalÄ«Å”anas shēma mainās; mēs turpinām dalÄ«t, bet ar atlikuÅ”o dalÄ«jumu ar citu skaitli. Tas nozÄ«mē, ka viens apmeklētājs jau atrodas vairākos serveros, un jÅ«s nevarat uz to paļauties. Tas tiek darÄ«ts tikai tāpēc, lai nodroÅ”inātu labāku datu saspieÅ”anu. Un, veicot pieprasÄ«jumus, mēs pārejam uz tabulu Distributed, kurā tiek apskatÄ«ts klasteris un piekļūst desmitiem serveru. Tā ir tik stulba shēma.

Bet mans stāsts bÅ«s nepilnÄ«gs, ja es neteikÅ”u, ka mēs atteicāmies no Ŕīs shēmas. Jaunajā shēmā mēs visu mainÄ«jām un visus datus nokopējām, izmantojot clickhouse-copier.

Jaunajā shēmā visas vietnes ir sadalÄ«tas divās kategorijās - lielajās un mazajās. Es nezinu, kā tika izvēlēts slieksnis, bet rezultāts bija tāds, ka lielas vietnes tiek ierakstÄ«tas vienā klasterÄ«, kur ir 120 lauskas ar trim replikām katrā - tas ir, 360 serveri. Un sadalÄ«Å”anas shēma ir tāda, ka jebkurÅ” pieprasÄ«jums tiek uzreiz uz visām Ŕķembām. Ja tagad vietnē Yandex.Metrica atverat jebkuru avito.ru pārskata lapu, pieprasÄ«jums tiks nosÅ«tÄ«ts uz 120 serveriem. RuNet ir dažas lielas vietnes. Un pieprasÄ«jumu ir nevis tÅ«kstotis sekundē, bet pat mazāk par simtu. To visu klusi sakoŔļā Distributed tabula, kuru katrs apstrādā ar 120 serveriem.

Un otrais klasteris ir paredzēts mazām vietnēm. Å eit ir sadalÄ«Å”anas shēma, kuras pamatā ir vietnes ID, un katrs pieprasÄ«jums tiek nosÅ«tÄ«ts tieÅ”i uz vienu fragmentu.

ClickHouse ir Clickhouse kopētāja utilīta. Vai varat pastāstīt par viņu?

Uzreiz teikÅ”u, ka Å”is risinājums ir apgrÅ«tinoŔāks un nedaudz mazāk produktÄ«vs. PriekÅ”rocÄ«ba ir tāda, ka tas pilnÄ«bā izsmērē datus atbilstoÅ”i jÅ«su norādÄ«tajam modelim. Bet utilÄ«tas trÅ«kums ir tāds, ka tā vispār nesadalās. Tas kopē datus no vienas klastera shēmas uz citu klastera shēmu.

Tas nozÄ«mē, ka, lai tas darbotos, jums ir jābÅ«t diviem klasteriem. Tie var atrasties tajos paÅ”os serveros, taču, neskatoties uz to, dati netiks pakāpeniski pārvietoti, bet gan tiks kopēti.

Piemēram, bija četri serveri, tagad ir astoņi. JÅ«s izveidojat jaunu Distributed tabulu uz visiem serveriem, jaunas lokālās tabulas un palaižat clickhouse-copier, norādot tajā darba shēmu, kas tai jānolasa no turienes, akceptējiet jauno sadalÄ«Å”anas shēmu un pārsÅ«tiet uz turieni datus. Un vecajos serveros jums vajadzēs pusotru reizi vairāk vietas nekā tagad, jo tajos jāpaliek vecajiem datiem, un puse no tiem paÅ”iem vecajiem datiem nonāks virsÅ«. Ja iepriekÅ” domājāt, ka dati ir jāsadala atkārtoti un ir vieta, tad Ŕī metode ir piemērota.

Kā Clickhouse kopētājs darbojas iekÅ”pusē? Tas sadala visu darbu uzdevumu komplektā, lai apstrādātu vienu tabulas nodalÄ«jumu vienā shardā. Visus Å”os uzdevumus var izpildÄ«t paralēli, un Clickhouse-copier var palaist dažādās iekārtās vairākos gadÄ«jumos, taču tas, ko tas dara vienam nodalÄ«jumam, ir nekas vairāk kā ievietoÅ”anas atlase. Dati tiek nolasÄ«ti, atspiesti, atkārtoti sadalÄ«ti, pēc tam atkal saspiesti, kaut kur ierakstÄ«ti un pārkārtoti. Tas ir stingrāks lēmums.

Jums bija izmēģinājuma lieta, ko sauc par atkārtotu sadalÄ«Å”anu. Kas ar viņu?

2017. gadā jums bija izmēģinājuma lieta, ko sauca par atkārtotu sadalÄ«Å”anu. ClickHouse ir pat iespēja. Kā es saprotu, tas nepacēlās. Vai varat man pateikt, kāpēc tas notika? Å Ä·iet, ka tas ir ļoti aktuāli.

Visa problēma ir tāda, ka, ja ir nepiecieÅ”ams atkārtoti sadalÄ«t datus vietā, ir nepiecieÅ”ama ļoti sarežģīta sinhronizācija, lai to izdarÄ«tu atomiski. Kad mēs sākām skatÄ«ties, kā Ŕī sinhronizācija darbojas, kļuva skaidrs, ka ir bÅ«tiskas problēmas. Un Ŕīs fundamentālās problēmas ir ne tikai teorētiskas, bet uzreiz sāka parādÄ«ties praksē tādā veidā, ko var izskaidrot ļoti vienkārÅ”i - nekas nedarbojas.

Vai ir iespējams sapludināt visus datus pirms pārvietoÅ”anas uz lēnajiem diskiem?

Jautājums par TTL ar pāreju uz lēnu disku apvienoÅ”anas kontekstā. Vai ir kāds veids, kā, izņemot, izmantojot cron, apvienot visas daļas vienā pirms pārvietoÅ”anas uz lēnajiem diskiem?

Atbilde uz jautājumu ir iespējams kaut kā automātiski salÄ«mēt visus gabalus vienā pirms to pārvietoÅ”anas - nē. Es domāju, ka tas nav nepiecieÅ”ams. Jums nav jāapvieno visas daļas vienā, bet vienkārÅ”i jārēķinās ar to, ka tās automātiski tiks pārsÅ«tÄ«tas uz lēnajiem diskiem.

Mums ir divi pārejas noteikumu kritēriji. Pirmais ir tāds, kāds tas ir piepildÄ«ts. Ja paÅ”reizējā krātuves lÄ«menÄ« ir mazāk par noteiktu brÄ«vas vietas procentuālo daļu, mēs atlasām vienu gabalu un pārvietojam to uz lēnāku krātuvi. Pareizāk sakot, nevis lēnāk, bet nākamais - kā jÅ«s konfigurējat.

Otrais kritērijs ir izmērs. Tas ir par lielu gabalu pārvietoÅ”anu. Varat pielāgot slieksni atbilstoÅ”i brÄ«vajai vietai ātrajā diskā, un dati tiks pārsÅ«tÄ«ti automātiski.

Kā pāriet uz jaunām ClickHouse versijām, ja nav iespējas iepriekÅ” pārbaudÄ«t saderÄ«bu?

Å Ä« tēma tiek regulāri apspriesta ClickHouse telegrammas tērzÄ“Å”anā ņemot vērā dažādas versijas, un tomēr. Cik droÅ”i ir jaunināt no versijas 19.11 uz 19.16 un, piemēram, no 19.16 uz 20.3. Kāds ir labākais veids, kā migrēt uz jaunām versijām, iepriekÅ” nepārbaudot saderÄ«bu smilÅ”u kastē?

Å eit ir vairāki "zelta" noteikumi. Pirmkārt - izlasi izmaiņu žurnālu. Tas ir liels, taču ir atseviŔķas rindkopas par atpakaļejoŔām nesaderÄ«gām izmaiņām. Neuztveriet Å”os punktus kā sarkano karogu. Tās parasti ir nelielas nesaderÄ«bas, kas ietver dažas malas funkcijas, kuras jÅ«s, visticamāk, neizmantojat.

Otrkārt, ja nav iespējas pārbaudÄ«t saderÄ«bu smilÅ”u kastē un vēlaties to nekavējoties atjaunināt ražoÅ”anā, ieteicams to darÄ«t. Vispirms izveidojiet smilÅ”u kasti un pārbaudiet. Ja nav testa vides, visticamāk, jums nav ļoti liela uzņēmuma, kas nozÄ«mē, ka varat kopēt dažus datus savā klēpjdatorā un pārliecināties, ka viss tajā darbojas pareizi. JÅ«s pat varat izveidot vairākas kopijas lokāli savā datorā. Vai arÄ« varat paņemt jaunu versiju kaut kur tuvumā un augÅ”upielādēt tur dažus datus - tas ir, izveidot improvizētu testa vidi.

Vēl viens noteikums ir neatjaunināt nedēļu pēc versijas izlaiÅ”anas, jo tiek konstatētas kļūdas ražoÅ”anā un turpmākie ātrie labojumi. Izdomāsim ClickHouse versiju numerāciju, lai neapjuktu.

Ir versija 20.3.4. Cipars 20 norāda izgatavoÅ”anas gadu - 2020. No iekÅ”puses viedokļa tam nav nozÄ«mes, tāpēc mēs tam nepievērsÄ«sim uzmanÄ«bu. Nākamais - 20.3. Mēs palielinām otro skaitli ā€” Å”ajā gadÄ«jumā 3 ā€” katru reizi, kad izlaižam laidienu ar kādu jaunu funkcionalitāti. Ja mēs vēlamies ClickHouse pievienot kādu funkciju, mums Å”is skaitlis ir jāpalielina. Tas ir, versijā 20.4 ClickHouse darbosies vēl labāk. TreÅ”ais cipars ir 20.3.4. Å eit ir norādÄ«ts 4 ielāpu izlaidumu skaits, kuros mēs nepievienojām jaunas funkcijas, bet izlabojām dažas kļūdas. Un 4 nozÄ«mē, ka mēs to izdarÄ«jām četras reizes.

Nedomājiet, ka tas ir kaut kas briesmÄ«gs. Parasti lietotājs var instalēt jaunāko versiju, un tā darbosies bez problēmām ar darbÄ«bas laiku gadā. Bet iedomājieties, ka kādā bitkartes apstrādes funkcijā, ko pievienoja mÅ«su Ä·Ä«nieÅ”u biedri, serveris avarē, nododot nepareizus argumentus. Mums ir pienākums to novērst. Mēs izlaidÄ«sim jaunu ielāpu versiju, un ClickHouse kļūs stabilāks.

Ja jums ir ClickHouse, kas darbojas ražoÅ”anā, un iznāk jauna ClickHouse versija ar papildu funkcijām - piemēram, 20.4.1 ir pati pirmā, nesteidzieties to laist ražoÅ”anā jau pirmajā dienā. Kāpēc tas vispār ir vajadzÄ«gs? Ja vēl nelieto ClickHouse, tad vari to instalēt, un visticamāk viss bÅ«s kārtÄ«bā. Bet, ja ClickHouse jau darbojas stabili, sekojiet lÄ«dzi ielāpiem un atjauninājumiem, lai redzētu, kādas problēmas mēs novērÅ”am.

Kirils Švakovs: Vēlos nedaudz piebilst par testa vidēm. Visi ļoti baidās no testa vidēm un nez kāpēc uzskata, ka ja tev ir ļoti liels ClickHouse klasteris, tad testa videi jābūt ne mazākai vai vismaz desmit reizes mazākai. Tā nemaz nav.

Es varu pateikt pēc sava piemēra. Man ir projekts, un ir ClickHouse. MÅ«su testa vide ir tieÅ”i viņam - Ŕī ir neliela virtuālā maŔīna Hetznerā par divdesmit eiro, kurā ir izvietots pilnÄ«gi viss. Lai to izdarÄ«tu, mums Ansible ir pilna automatizācija, un tāpēc principā nav nozÄ«mes, kur doties - uz aparatÅ«ras serveriem vai vienkārÅ”i izvietot virtuālajās maŔīnās.

Ko var darÄ«t? BÅ«tu jauki ClickHouse dokumentācijā sniegt piemēru par to, kā izvietot nelielu kopu savās mājās - Docker, LXC, iespējams, izveidojiet Ansible rokasgrāmatu, jo dažādiem cilvēkiem ir dažādas izvietoÅ”anas. Tas daudz ko vienkārÅ”os. Ja piecās minÅ«tēs paņemat un izvietojat kopu, ir daudz vieglāk mēģināt kaut ko izdomāt. Tas ir daudz ērtāk, jo, pārejot uz ražoÅ”anas versiju, kuru neesat pārbaudÄ«jis, ir ceļŔ uz nekurieni. Dažreiz tas izdodas un dažreiz ne. Un tāpēc cerēt uz panākumiem ir slikti.

Maksims Kotjakovs, vecākais aizmugures inženieris Avito: Es pievienoÅ”u nedaudz par testa vidēm no virknes problēmu, ar kurām saskaras lieli uzņēmumi. Mums ir pilnvērtÄ«gs ClickHouse pieņemÅ”anas klasteris, datu shēmu un iestatÄ«jumu ziņā tā ir precÄ«za ražoÅ”anā esoŔā kopija. Å is klasteris ir izvietots diezgan nolietotos konteineros ar minimāliem resursiem. Mēs tur rakstām noteiktu procentuālo daļu no ražoÅ”anas datiem, par laimi ir iespējams atkārtot straumi Kafkā. Tur viss ir sinhronizēts un mērogots - gan jaudas, gan plÅ«smas ziņā, gan teorētiski, ja visas pārējās lietas ir vienādas, metriku ziņā tam vajadzētu uzvesties kā ražoÅ”anai. Viss potenciāli sprādzienbÄ«stamais vispirms tiek uzvilkts uz Ŕī stenda un atstāts tur vairākas dienas, lÄ«dz tas ir gatavs. Taču, protams, Å”is risinājums ir dārgs, sarežģīts un atbalsta izmaksas nav vienādas.

Aleksejs Milovidovs: Es jums pastāstÄ«Å”u, kāda ir mÅ«su Yandex.Metrica draugu testa vide. Vienā klasterÄ« bija 600 nepāra serveru, citā bija 360, un ir treÅ”ais un vairāki klasteri. Testa vide vienam no tiem ir vienkārÅ”i divas shards ar divām replikām katrā. Kāpēc divas lauskas? Lai tu nebÅ«tu viens. Un vajadzētu bÅ«t arÄ« replikām. Tikai noteikta minimālā summa, ko varat atļauties.

Š­Ń‚Š° тŠµŃŃ‚Š¾Š²Š°Ń срŠµŠ“Š° ŠæŠ¾Š·Š²Š¾Š»ŃŠµŃ‚ ŠæрŠ¾Š²ŠµŃ€Šøть рŠ°Š±Š¾Ń‚Š¾ŃŠæŠ¾ŃŠ¾Š±Š½Š¾ŃŃ‚ŃŒ Š·Š°ŠæрŠ¾ŃŠ¾Š² Šø Š½Šµ сŠ»Š¾Š¼Š°Š»Š¾ŃŃŒ Š»Šø чтŠ¾-тŠ¾ ŠæŠ¾-ŠŗруŠæŠ½Š¾Š¼Ńƒ. ŠŠ¾ чŠ°ŃŃ‚Š¾ ŠæрŠ¾Š±Š»ŠµŠ¼Ń‹ Š²Š¾Š·Š½ŠøŠŗŠ°ŃŽŃ‚ сŠ¾Š²ŠµŃ€ŃˆŠµŠ½Š½Š¾ Š“руŠ³Š¾Š³Š¾ хŠ°Ń€Š°ŠŗтŠµŃ€Š°, ŠŗŠ¾Š³Š“Š° Š²ŃŃ‘ рŠ°Š±Š¾Ń‚Š°ŠµŃ‚, Š½Š¾ ŠµŃŃ‚ŃŒ Š½ŠµŠŗŠ¾Ń‚Š¾Ń€Ń‹Šµ Š½ŠµŠ±Š¾Š»ŃŒŃˆŠøŠµ ŠøŠ·Š¼ŠµŠ½ŠµŠ½Šøя с Š½Š°Š³Ń€ŃƒŠ·ŠŗŠ¾Š¹.

Ä»aujiet man sniegt jums piemēru. Mēs nolēmām instalēt jaunu ClickHouse versiju. Tas ir ievietots testa vidē, paŔā Yandex.Metrica ir pabeigti automatizēti testi, kas salÄ«dzina datus par veco un jauno versiju, kas darbojas visā konveijerā. Un, protams, mÅ«su CI zaļie testi. Citādi mēs pat nebÅ«tu piedāvājuÅ”i Å”o variantu.

Viss ir kārtÄ«bā. Mēs sākam pāriet uz ražoÅ”anu. Saņemu ziņu, ka grafiku slodze ir palielinājusies vairākas reizes. Mēs atgriežam versiju. Es paskatos uz diagrammu un redzu: slodze faktiski palielinājās vairākas reizes izlaiÅ”anas laikā un samazinājās atpakaļ, kad tās tika izlaistas. Tad mēs sākām atgriezt versiju. Un slodze tāpat pieauga un tāpat atkrita. Tātad secinājums ir Ŕāds: slodze ir palielinājusies izkārtojuma dēļ, nekas pārsteidzoÅ”s.

Tad bija grÅ«ti pārliecināt kolēģus instalēt jauno versiju. Es saku: "Tas ir labi, izvelciet. Turiet Ä«kŔķus, viss izdosies. Tagad slodze uz grafikiem ir palielinājusies, bet viss kārtÄ«bā. Turies." Kopumā mēs to izdarÄ«jām, un tas arÄ« viss - versija tika izlaista ražoÅ”anai. Bet gandrÄ«z ar katru izkārtojumu rodas lÄ«dzÄ«gas problēmas.

Iznīcināt vaicājumu ir paredzēts iznīcināt vaicājumus, bet tas nenotiek. Kāpēc?

Lietotājs, kaut kāds analītiķis, pienāca pie manis un izveidoja pieprasījumu, kas ievietoja manu ClickHouse klasteru. Daži mezgli vai viss klasteris atkarībā no tā, uz kuru repliku vai fragmentu tika nosūtīts pieprasījums. Skatos, ka Ŕajā serverī visi CPU resursi atrodas plauktā, viss sarkans. Tajā paŔā laikā ClickHouse pati atbild uz pieprasījumiem. Un es rakstu: "Lūdzu, parādiet man, procesu sarakstu, kāds pieprasījums radīja Ŕo neprātu."

Es atrodu Å”o pieprasÄ«jumu un uzrakstu tam kill. Un es redzu, ka nekas nenotiek. Mans serveris atrodas plauktā, ClickHouse pēc tam dod man dažas komandas, parāda, ka serveris ir dzÄ«vs, un viss ir lieliski. Bet man ir degradācija visos lietotāju pieprasÄ«jumos, degradācija sākas ar ierakstiem pakalpojumā ClickHouse, un mans nogalināŔanas vaicājums nedarbojas. Kāpēc? Es domāju, ka nogalināŔanas vaicājumam vajadzēja iznÄ«cināt vaicājumus, bet tas nenotiek.

Tagad būs diezgan dīvaina atbilde. Lieta ir tāda, ka nogalināŔanas vaicājums neiznīcina vaicājumus.

NogalināŔanas vaicājums atzÄ«mē nelielu lodziņu ar nosaukumu ā€œEs gribu, lai Å”is vaicājums tiktu iznÄ«cinātsā€. Un pats pieprasÄ«jums aplÅ«ko Å”o karogu, apstrādājot katru bloku. Ja tas ir iestatÄ«ts, pieprasÄ«jums pārstāj darboties. Izrādās, ka neviens lÅ«gumu nenogalina, viņam paÅ”am viss jāpārbauda un jāpārtrauc. Un tam vajadzētu darboties visos gadÄ«jumos, kad pieprasÄ«jums atrodas datu bloku apstrādes stāvoklÄ«. Tas apstrādās nākamo datu bloku, pārbaudÄ«s karogu un apstāsies.

Tas nedarbojas gadÄ«jumos, kad pieprasÄ«jums ir bloķēts kādā darbÄ«bā. Tiesa, visdrÄ«zāk tas nav tavs gadÄ«jums, jo, pēc tevis teiktā, tas izmanto ļoti daudz servera resursu. Iespējams, ka tas nedarbojas ārējās ŔķiroÅ”anas gadÄ«jumā un dažās citās detaļās. Bet kopumā tam nevajadzētu notikt, tā ir kļūda. Un vienÄ«gais, ko varu ieteikt, ir ClickHouse atjaunināŔana.

Kā aprēķināt reakcijas laiku lasÄ«Å”anas slodzes laikā?

Ir tabula, kurā tiek glabāti preču agregāti - dažādi skaitÄ«tāji. LÄ«niju skaits ir aptuveni simts miljoni. Vai ir iespējams paļauties uz paredzamu reakcijas laiku, ja 1 precēm pievienojat 1 XNUMX RPS?

Spriežot pēc konteksta, runa ir par lasÄ«Å”anas slodzi, jo ar rakstÄ«Å”anu nav nekādu problēmu - var ielikt pat tÅ«kstoti, pat simt tÅ«kstoÅ”us un dažkārt vairākus miljonus rindu.

LasÄ«Å”anas pieprasÄ«jumi ir ļoti dažādi. 1. izvēlē ClickHouse var izpildÄ«t aptuveni desmitiem tÅ«kstoÅ”u pieprasÄ«jumu sekundē, tāpēc pat vienas atslēgas pieprasÄ«jumiem jau bÅ«s nepiecieÅ”ami daži resursi. Un Ŕādi punktu vaicājumi bÅ«s grÅ«tāki nekā dažās atslēgu vērtÄ«bu datubāzēs, jo katram nolasÄ«jumam ir nepiecieÅ”ams nolasÄ«t datu bloku pēc indeksa. MÅ«su rādÄ«tājs attiecas nevis uz katru ierakstu, bet uz katru diapazonu. Tas ir, jums bÅ«s jāizlasa viss diapazons - pēc noklusējuma tas ir 8192 rindas. Un jums bÅ«s jāatspiež saspiestais datu bloks no 64 KB lÄ«dz 1 MB. Parasti Ŕādu mērÄ·vaicājumu izpilde aizņem dažas milisekundes. Bet Ŕī ir vienkārŔākā iespēja.

Izmēģināsim vienkārÅ”u aritmētiku. Ja jÅ«s reizinat dažas milisekundes ar tÅ«kstoti, jÅ«s iegÅ«sit dažas sekundes. It kā nav iespējams sekot lÄ«dzi tÅ«kstoÅ” pieprasÄ«jumu sekundē, bet patiesÄ«bā tas ir iespējams, jo mums ir vairāki procesora kodoli. Tātad principā ClickHouse dažkārt var saturēt 1000 RPS, bet Ä«siem pieprasÄ«jumiem, Ä«paÅ”i mērÄ·tiecÄ«giem.

Ja jums ir jāmēro ClickHouse klasteris pēc vienkārÅ”u pieprasÄ«jumu skaita, tad es iesaku visvienkārŔāko lietu - palielināt kopiju skaitu un nosÅ«tÄ«t pieprasÄ«jumus nejauÅ”ai kopijai. Ja vienā reprodukcijā ir pieci simti pieprasÄ«jumu sekundē, kas ir pilnÄ«gi reāli, tad trÄ«s replikas apstrādās pusotru tÅ«kstoti.

Dažreiz, protams, jūs varat konfigurēt ClickHouse maksimālajam punktu nolasījumu skaitam. Kas tam vajadzīgs? Pirmais ir samazināt indeksa precizitāti. Šajā gadījumā to nevajadzētu samazināt līdz vienam, bet gan pamatojoties uz to, ka ierakstu skaits indeksā būs vairāki miljoni vai desmitiem miljonu uz vienu serveri. Ja tabulā ir simts miljonu rindu, tad granularitāti var iestatīt uz 64.

Jūs varat samazināt saspiestā bloka izmēru. Tam ir iestatījumi min kompresijas bloka izmērs, maksimālais kompresijas bloka izmērs. Tos var samazināt, papildināt ar datiem, un tad mērķtiecīgi vaicājumi būs ātrāki. Tomēr ClickHouse nav atslēgu vērtību datubāze. Liels skaits mazu pieprasījumu ir slodzes antiraksts.

Kirils Å vakovs: Es sniegÅ”u padomu, ja tur ir parastie konti. Å Ä« ir diezgan standarta situācija, kad ClickHouse glabā kaut kādus skaitÄ«tājus. Man ir lietotājs, viņŔ ir no tādas un tādas valsts un kaut kādas treŔās jomas, un man kaut kas pakāpeniski jāpalielina. Paņemiet MySQL, izveidojiet unikālu atslēgu - MySQL tā ir dublikāta atslēga, un PostgreSQL tas ir konflikts - un pievienojiet plus zÄ«mi. Tas darbosies daudz labāk.

Ja jums nav daudz datu, nav lielas jēgas izmantot ClickHouse. Pastāv regulāras datu bāzes, un tās to dara labi.

Ko es varu izmainÄ«t ClickHouse, lai keÅ”atmiņā bÅ«tu vairāk datu?

Iedomāsimies situāciju - serveriem ir 256 GB RAM, ikdienas režīmā ClickHouse aizņem apmēram 60-80 GB, maksimumā - lÄ«dz 130. Ko var iespējot un pielabot, lai keÅ”atmiņā bÅ«tu vairāk datu un attiecÄ«gi ir mazāk braucienu uz disku?

Parasti operētājsistēmas lapas keÅ”atmiņa veic labu darbu. Ja vienkārÅ”i atver augÅ”daļu, paskaties tur cached vai free ā€“ tur arÄ« ir rakstÄ«ts, cik daudz ir keÅ”atmiņā ā€“ tad pamanÄ«si, ka visa brÄ«vā atmiņa tiek izmantota keÅ”atmiņai. Un lasot Å”os datus, tie tiks nolasÄ«ti nevis no diska, bet gan no RAM. Tajā paŔā laikā varu teikt, ka keÅ”atmiņa tiek izmantota efektÄ«vi, jo keÅ”atmiņā tiek saglabāti saspiestie dati.

Tomēr, ja vēlaties vēl vairāk paātrināt dažus vienkārÅ”us vaicājumus, ClickHouse atspiestajos datos ir iespējams iespējot keÅ”atmiņu. Tas tiek saukts nesaspiesta keÅ”atmiņa. Konfig.xml konfigurācijas failā iestatiet nesaspiestās keÅ”atmiņas lielumu uz vajadzÄ«go vērtÄ«bu - iesaku ne vairāk kā pusi no brÄ«vās RAM, jo pārējais nonāks zem lapas keÅ”atmiņas.

Turklāt ir divi pieprasÄ«juma lÄ«meņa iestatÄ«jumi. Pirmais iestatÄ«jums - izmantot nesaspiestu keÅ”atmiņu - ietver tā izmantoÅ”anu. Ieteicams to iespējot visiem pieprasÄ«jumiem, izņemot smagus, kas var nolasÄ«t visus datus un iztÄ«rÄ«t keÅ”atmiņu. Un otrais iestatÄ«jums ir kaut kas lÄ«dzÄ«gs maksimālajam rindiņu skaitam, lai izmantotu keÅ”atmiņu. Tas automātiski ierobežo lielus vaicājumus, lai tie apietu keÅ”atmiņu.

Kā es varu konfigurēt storage_configuration glabāŔanai RAM?

Jaunajā ClickHouse dokumentācijā es izlasÄ«ju sadaļu, kas ir saistÄ«ta ar datu glabāŔanu. Aprakstā ir piemērs ar ātru SSD.

Interesanti, kā to paÅ”u var konfigurēt ar skaļuma karsto atmiņu. Un vēl viens jautājums. Kā Select darbojas ar Å”o datu organizāciju, vai tas nolasÄ«s visu komplektu vai tikai to, kas atrodas diskā, un vai Å”ie dati tiek saspiesti atmiņā? Un kā prewhere sadaļa darbojas ar Ŕādu datu organizāciju?

Å is iestatÄ«jums ietekmē datu gabalu uzglabāŔanu, un to formāts nekādā veidā nemainās.
Apskatīsim tuvāk.

Varat konfigurēt datu glabāŔanu RAM. Viss, kas ir konfigurēts diskam, ir tā ceļŔ. JÅ«s izveidojat tmpfs nodalÄ«jumu, kas ir pievienots kādam faila sistēmas ceļam. JÅ«s norādāt Å”o ceļu kā karstākā nodalÄ«juma datu glabāŔanas ceļu, sāk ienākt un tur ierakstÄ«ties datu gabali, viss ir kārtÄ«bā.

Bet es neiesaku to darÄ«t zemās uzticamÄ«bas dēļ, lai gan, ja jums ir vismaz trÄ«s kopijas dažādos datu centros, tas ir iespējams. Ja kaut kas notiks, dati tiks atjaunoti. Iedomāsimies, ka serveris pēkŔņi tika izslēgts un atkal ieslēgts. Atkal tika uzstādÄ«ts nodalÄ«jums, bet tur nekā nebija. Kad ClickHouse serveris startē, tas redz, ka tam nav Å”o gabalu, lai gan saskaņā ar ZooKeeper metadatiem tiem tur vajadzētu bÅ«t. ViņŔ apskata, kurām replikām tās ir, tās pieprasa un lejupielādē. Tādā veidā dati tiks atjaunoti.

Å ajā ziņā datu glabāŔana RAM neatŔķiras no to uzglabāŔanas diskā, jo, ierakstot datus diskā, tie arÄ« vispirms nonāk lapas keÅ”atmiņā un fiziski tiek ierakstÄ«ti vēlāk. Tas ir atkarÄ«gs no failu sistēmas montāžas opcijas. Bet katram gadÄ«jumam teikÅ”u, ka ClickHouse ievietoÅ”anas laikā nesinhronizējas.

Šajā gadījumā RAM dati tiek saglabāti tieŔi tādā paŔā formātā kā diskā. Atlases vaicājums tādā paŔā veidā atlasa nolasāmās daļas, atlasa nepiecieŔamos datu diapazonus daļās un nolasa tos. Un prewhere darbojas tieŔi tāpat, neatkarīgi no tā, vai dati bija RAM vai diskā.

Līdz kādam unikālo vērtību skaitam ir efektīva zema kardinalitāte?

Low Cardinality ir gudri izstrādāta. Tas apkopo datu vārdnÄ«cas, taču tās ir lokālas. Pirmkārt, katram gabalam ir dažādas vārdnÄ«cas, otrkārt, pat viena gabala ietvaros tās var atŔķirties katram diapazonam. Kad unikālo vērtÄ«bu skaits sasniedz sliekŔņa skaitli ā€” manuprāt, vienu miljonu ā€” vārdnÄ«ca tiek vienkārÅ”i nolikta plauktā un tiek izveidota jauna.

Atbilde ir vispārÄ«ga: katram lokālajam diapazonam - teiksim, katrai dienai - kaut kur lÄ«dz miljonam unikālu vērtÄ«bu zema kardinalitāte ir efektÄ«va. Pēc tam bÅ«s vienkārÅ”i atkāpÅ”anās, kurā tiks izmantotas daudzas dažādas vārdnÄ«cas, nevis tikai viena. Tas darbosies aptuveni tāpat kā parastā virknes kolonna, varbÅ«t nedaudz mazāk efektÄ«va, taču nebÅ«s nopietnas veiktspējas pasliktināŔanās.

Kāda ir labākā prakse pilna teksta meklÄ“Å”anai tabulā ar pieciem miljardiem rindu?

Ir dažādas atbildes. Pirmais ir teikt, ka ClickHouse nav pilna teksta meklētājprogramma. Tam ir Ä«paÅ”as sistēmas, piemēram, Elastikas meklÄ“Å”ana Šø Sfinksa. Tomēr es arvien biežāk redzu cilvēkus, kuri saka, ka pāriet no Elasticsearch uz ClickHouse.

Kāpēc tas notiek? Viņi to skaidro ar faktu, ka Elasticsearch dažos apjomos pārstāj tikt galā ar slodzi, sākot ar indeksu veidoÅ”anu. Indeksi kļūst pārāk apgrÅ«tinoÅ”i, un, vienkārÅ”i pārsÅ«tot datus uz ClickHouse, izrādās, ka tie tiek uzglabāti vairākas reizes efektÄ«vāk apjoma ziņā. Tajā paŔā laikā meklÄ“Å”anas vaicājumi bieži nebija tādi, lai visā datu apjomā, ņemot vērā morfoloÄ£iju, bÅ«tu jāatrod kāda frāze, bet gan pavisam citas. Piemēram, atrodiet dažas baitu apakÅ”secÄ«bas žurnālos pēdējo stundu laikā.

Å ajā gadÄ«jumā jÅ«s izveidojat indeksu ClickHouse, kura pirmais lauks bÅ«s datums un laiks. Un lielākais datu ierobežojums bÅ«s balstÄ«ts uz datumu diapazonu. Izvēlētajā datumu diapazonā, kā likums, jau ir iespējams veikt pilna teksta meklÄ“Å”anu, pat izmantojot brutālā spēka metodi, izmantojot lÄ«dzÄ«gu. LÄ«dzÄ«gais operators pakalpojumā ClickHouse ir visefektÄ«vākais lÄ«dzÄ«gais operators, ko varat atrast. Ja atrodat ko labāku, pastāstiet man.

Bet tomēr, piemēram, ir pilna skenÄ“Å”ana. Un pilna skenÄ“Å”ana var bÅ«t lēna ne tikai CPU, bet arÄ« diskā. Ja pēkŔņi jums ir viens terabaits datu dienā un dienas laikā meklējat vārdu, jums bÅ«s jāskenē terabaits. Un tas, iespējams, ir parastajos cietajos diskos, un galu galā tie tiks ielādēti tā, ka jÅ«s nevarēsit piekļūt Å”im serverim, izmantojot SSH.

Å ajā gadÄ«jumā esmu gatavs piedāvāt vēl vienu mazu triku. Tas ir eksperimentāls ā€” tas var darboties, var nē. ClickHouse ir pilna teksta indeksi trigrammu Bloom filtru veidā. MÅ«su kolēģi Arenadatā jau ir izmēģinājuÅ”i Å”os indeksus, un tie bieži darbojas tieÅ”i tā, kā paredzēts.

Lai tos pareizi lietotu, jums ir labi jāsaprot, kā tie darbojas: kas ir trigrammas BlÅ«ma filtrs un kā izvēlēties tā izmēru. Varu teikt, ka tie palÄ«dzēs vaicājumos par dažām retām frāzēm, apakÅ”virknēm, kas datos reti sastopamas. Å ajā gadÄ«jumā apakÅ”diapazoni tiks atlasÄ«ti pēc indeksiem un tiks nolasÄ«ts mazāk datu.

Nesen ClickHouse ir pievienojis vēl vairāk uzlabotas funkcijas pilna teksta meklÄ“Å”anai. Pirmkārt, tā ir vairāku apakÅ”virkņu meklÄ“Å”ana vienā piegājienā, tostarp opcijas, kas ir reÄ£istrjutÄ«gas, reÄ£istrjutÄ«gas, atbalsta UTF-8 vai tikai ASCII. Izvēlieties visefektÄ«vāko, kas jums nepiecieÅ”ams.

Ir parādÄ«jusies arÄ« vairāku regulāro izteiksmju meklÄ“Å”ana vienā piegājienā. Jums nav jāraksta X kā viena apakÅ”virkne vai X kā cita apakÅ”virkne. JÅ«s rakstāt uzreiz, un viss tiek darÄ«ts pēc iespējas efektÄ«vāk.

TreÅ”kārt, tagad tiek veikta aptuvenā regexps meklÄ“Å”ana un aptuvenā apakÅ”virkņu meklÄ“Å”ana. Ja kāds ir nepareizi uzrakstÄ«jis vārdu, tas tiks meklēts, lai atrastu maksimālo atbilstÄ«bu.

Kāds ir labākais veids, kā organizēt piekļuvi ClickHouse lielam lietotāju skaitam?

Pastāstiet mums, kā vislabāk organizēt piekļuvi lielam skaitam patērētāju un analītiķu. Kā izveidot rindu, noteikt prioritāti maksimāli vienlaicīgiem vaicājumiem un ar kādiem rīkiem?

Ja klasteris ir pietiekami liels, tad labs risinājums bÅ«tu paaugstināt vēl divus serverus, kas kļūs par ieejas punktu analÄ«tiÄ·iem. Tas ir, neļaujiet analÄ«tiÄ·iem piekļūt noteiktām klastera fragmentiem, bet vienkārÅ”i izveidojiet divus tukÅ”us serverus bez datiem un konfigurējiet tiem piekļuves tiesÄ«bas. Å ajā gadÄ«jumā lietotāja iestatÄ«jumi izplatÄ«tajiem pieprasÄ«jumiem tiek pārsÅ«tÄ«ti uz attālajiem serveriem. Tas ir, jÅ«s konfigurējat visu Å”ajos divos serveros, un iestatÄ«jumi ietekmē visu klasteru.

Principā Å”iem serveriem nav datu, bet RAM apjoms tajos ir ļoti svarÄ«gs pieprasÄ«jumu izpildei. Disku var izmantot arÄ« pagaidu datiem, ja ir iespējota ārēja apkopoÅ”ana vai ārēja kārtoÅ”ana.

Ir svarÄ«gi aplÅ«kot iestatÄ«jumus, kas ir saistÄ«ti ar visiem iespējamiem ierobežojumiem. Ja es tagad doÅ”os uz Yandex.Metrica klasteru kā analÄ«tiÄ·is un uzdodu pieprasÄ«jumu atlasiet trāpÄ«jumu skaitu, tad man uzreiz tiks pieŔķirts izņēmums, ka nevaru izpildÄ«t pieprasÄ«jumu. Maksimālais rindu skaits, ko es drÄ«kstu skenēt, ir simts miljardi, un kopā vienā klastera tabulā tās ir piecdesmit triljoni. Å is ir pirmais ierobežojums.

Pieņemsim, ka es noņemu rindu ierobežojumu un izpildu vaicājumu vēlreiz. Tad es redzÄ“Å”u Ŕādu izņēmumu - iestatÄ«jums ir iespējots spēka indekss pēc datuma. Es nevaru pabeigt vaicājumu, ja neesmu norādÄ«jis datumu diapazonu. Jums nav jāpaļaujas uz analÄ«tiÄ·iem, lai to norādÄ«tu manuāli. Tipisks gadÄ«jums ir tad, kad datumu diapazons tiek rakstÄ«ts, kur notikuma datums starp nedēļu. Un tad viņi vienkārÅ”i norādÄ«ja iekava nepareizajā vietā, un tā vietā izrādÄ«jās vai - vai URL atbilstÄ«ba. Ja nav ierobežojumu, tas pārmeklēs URL kolonnu un vienkārÅ”i iztērēs daudz resursu.

Turklāt ClickHouse ir divi prioritāri iestatÄ«jumi. Diemžēl tie ir ļoti primitÄ«vi. Vienu vienkārÅ”i sauc prioritāte. Ja prioritāte ā‰  0 un tiek izpildÄ«ti pieprasÄ«jumi ar kādu prioritāti, bet tiek izpildÄ«ts pieprasÄ«jums ar prioritātes vērtÄ«bu mazāku par, kas nozÄ«mē augstāku prioritāti, tad pieprasÄ«jums ar prioritātes vērtÄ«bu lielāku, kas nozÄ«mē zemāku prioritāti , ir vienkārÅ”i apturēta un Å”ajā laikā nedarbosies vispār.

Å is ir ļoti neapstrādāts iestatÄ«jums un nav piemērots gadÄ«jumiem, kad klasterim ir pastāvÄ«ga slodze. Bet, ja jums ir svarÄ«gi Ä«si, apjomÄ«gi pieprasÄ«jumi un klasteris lielākoties ir dÄ«kstāvē, Ŕī iestatÄ«Å”ana ir piemērota.

Tiek izsaukts nākamais prioritātes iestatÄ«jums OS pavediena prioritāte. Tas vienkārÅ”i nosaka jauku vērtÄ«bu visiem Linux plānotāja pieprasÄ«juma izpildes pavedieniem. Tas darbojas tik un tā, bet tas joprojām darbojas. Ja iestatāt minimālo jauku vērtÄ«bu ā€” tā ir vislielākā vērtÄ«ba un lÄ«dz ar to arÄ« zemākā prioritāte ā€” un iestatāt -19 pieprasÄ«jumiem ar augstu prioritāti, tad CPU patērēs zemas prioritātes pieprasÄ«jumus apmēram četras reizes mazāk nekā augstas prioritātes pieprasÄ«jumus.

Jums arÄ« jākonfigurē maksimālais pieprasÄ«juma izpildes laiks - teiksim, piecas minÅ«tes. Minimālais vaicājuma izpildes ātrums ir stilÄ«gākais. Å is iestatÄ«jums pastāv jau ilgu laiku, un tas ir nepiecieÅ”ams ne tikai, lai apliecinātu, ka ClickHouse nepalēninās, bet arÄ« jāpiespiež.

Iedomājieties, jÅ«s iestatāt: ja kāds vaicājums apstrādā mazāk nekā vienu miljonu rindu sekundē, jÅ«s to nevarat izdarÄ«t. Tas apkauno mÅ«su labo vārdu, mÅ«su labo datubāzi. VienkārÅ”i aizliegsim Å”o. PatiesÄ«bā ir divi iestatÄ«jumi. Vienu sauc Minimālais izpildes ātrums - rindās sekundē, un otro sauc par taimautu pirms minimālā izpildes ātruma pārbaudes - pēc noklusējuma piecpadsmit sekundes. Tas ir, ir iespējamas piecpadsmit sekundes, un tad, ja tas notiek lēni, vienkārÅ”i izmetiet izņēmumu un pārtrauciet pieprasÄ«jumu.

Jums arÄ« jāiestata kvotas. ClickHouse ir iebÅ«vēta kvotu funkcija, kas uzskaita resursu patēriņu. Bet diemžēl ne aparatÅ«ras resursi, piemēram, CPU, diski, bet loÄ£iskie - apstrādāto pieprasÄ«jumu skaits, lasÄ«tās rindas un baiti. Un jÅ«s varat konfigurēt, piemēram, ne vairāk kā simts pieprasÄ«jumu piecu minÅ«Å”u laikā un tÅ«kstoÅ” pieprasÄ«jumu stundā.

Kāpēc tas ir svarÄ«gi? Tā kā daži analÄ«tikas vaicājumi tiks veikti manuāli tieÅ”i no ClickHouse klienta. Un viss bÅ«s labi. Bet, ja jÅ«su uzņēmumā ir pieredzējuÅ”i analÄ«tiÄ·i, viņi uzrakstÄ«s skriptu, un skriptā var bÅ«t kļūda. Un Ŕīs kļūdas dēļ pieprasÄ«jums tiks izpildÄ«ts bezgalÄ«gā ciklā. Tas ir tas, no kā mums sevi jāpasargā.

Vai ir iespējams viena vaicājuma rezultātus nodot desmit klientiem?

Mums ir vairāki lietotāji, kuriem patÄ«k vienā un tajā paŔā brÄ«dÄ« iesniegt ļoti lielus pieprasÄ«jumus. PieprasÄ«jums ir liels un principā tiek izpildÄ«ts ātri, bet sakarā ar to, ka Ŕādu pieprasÄ«jumu ir daudz vienlaikus, tas kļūst ļoti sāpÄ«gi. Vai ir iespējams vienu un to paÅ”u pieprasÄ«jumu, kas pienāca desmit reizes pēc kārtas, izpildÄ«t vienu reizi un rezultātu nodot desmit klientiem?

Problēma ir tā, ka mums nav keÅ”atmiņas vai starpposma datu keÅ”atmiņas rezultātu. Ir operētājsistēmas lappuÅ”u keÅ”atmiņa, kas neļaus atkārtoti nolasÄ«t datus no diska, taču diemžēl dati joprojām tiks atspiesti, deserializēti un atkārtoti apstrādāti.

Es vēlētos kaut kā no tā izvairÄ«ties, vai nu keÅ”atmiņā saglabājot starpposma datus, vai sakārtojot lÄ«dzÄ«gus vaicājumus kaut kādā rindā un pievienojot rezultātu keÅ”atmiņu. PaÅ”laik tiek izstrādāts viens izvilkÅ”anas pieprasÄ«jums, kas pievieno pieprasÄ«juma keÅ”atmiņu, bet tikai apakÅ”vaicājumiem sadaļās ievadÄ«Å”ana un pievienoÅ”anās ā€” tas ir, risinājums ir nepilnÄ«gs.

Taču arÄ« mēs saskaramies ar Ŕādu situāciju. ÄŖpaÅ”i kanonisks piemērs ir vaicājumi ar lappusēm. Ir atskaite, tajā ir vairākas lapas, un ir pieprasÄ«jums pēc limita 10. Tad tas pats, bet limits 10,10. Tad vēl viena nākamā lapa. Un jautājums ir, kāpēc mēs to visu katru reizi uzskaitām? Bet tagad risinājuma nav, un nav arÄ« iespējas no tā izvairÄ«ties.

Ir alternatīvs risinājums, kas tiek novietots kā blakusvāģis blakus ClickHouse - ClickHouse starpniekserveris.

Kirils Å vakovs: ClickHouse Proxy ir iebÅ«vēts ātruma ierobežotājs un iebÅ«vēta rezultātu keÅ”atmiņa. Tur tika veikti daudzi iestatÄ«jumi, jo tika atrisināta lÄ«dzÄ«ga problēma. Starpniekserveris ļauj ierobežot pieprasÄ«jumus, ievietojot tos rindā, un konfigurēt, cik ilgi pieprasÄ«juma keÅ”atmiņa darbojas. Ja pieprasÄ«jumi patieŔām bija vienādi, Proxy tos nosÅ«tÄ«s daudzas reizes, bet uz ClickHouse nonāks tikai vienu reizi.

Nginx ir arÄ« keÅ”atmiņa bezmaksas versijā, un tas arÄ« darbosies. Nginx pat ir iestatÄ«jumi, ka, ja pieprasÄ«jumi tiek saņemti vienlaikus, tas palēninās citus, lÄ«dz viens tiks pabeigts. Bet tas ir ClickHouse Proxy, ka iestatÄ«Å”ana tiek veikta daudz labāk. Tas tika izveidots Ä«paÅ”i ClickHouse, tieÅ”i Å”iem pieprasÄ«jumiem, tāpēc tas ir vairāk piemērots. Nu, to ir viegli uzstādÄ«t.

Kā ar asinhronajām operācijām un materializētajiem skatiem?

Ir problēma, ka darbÄ«bas ar atkārtoÅ”anas dzinēju ir asinhronas - vispirms tiek ierakstÄ«ti dati, pēc tam tie sabrÅ«k. Ja zem zÄ«mes atrodas materializēta planÅ”ete ar dažiem agregātiem, tad tai tiks ierakstÄ«ti dublikāti. Un, ja nav sarežģītas loÄ£ikas, tad dati tiks dublēti. Ko jÅ«s varat darÄ«t lietas labā?

Ir acīmredzams risinājums - ieviest trigeri noteiktai matviews klasei asinhronas sabrukŔanas darbības laikā. Vai ir kādas sudraba lodes vai plāni ieviest līdzīgu funkcionalitāti?

Ir vērts saprast, kā darbojas deduplikācija. Tas, ko es jums pateikÅ”u tagad, neattiecas uz jautājumu, bet tikai gadÄ«jumā, ja to ir vērts atcerēties.

Ievietojot replicētā tabulā, tiek noņemta visu ievietoto bloku dublÄ“Å”ana. Ja atkārtoti ievietojat to paÅ”u bloku, kurā ir vienāds skaits to paÅ”u rindu tādā paŔā secÄ«bā, dati tiek dedublēti. Atbildot uz ievietoÅ”anu, jÅ«s saņemsit ā€œOkā€, taču faktiski tiks ierakstÄ«ta viena datu pakete, un tā netiks dublēta.

Tas ir nepiecieÅ”ams noteiktÄ«bas labad. Ja ievietoÅ”anas laikā saņemat ā€œOkā€, jÅ«su dati ir ievietoti. Ja saņemat kļūdu no ClickHouse, tas nozÄ«mē, ka tie nav ievietoti un jums ir jāatkārto ievietoÅ”ana. Bet, ja savienojums tiek pārtraukts ievietoÅ”anas laikā, tad jÅ«s nezināt, vai dati tika ievietoti vai nē. VienÄ«gā iespēja ir atkārtot ievietoÅ”anu vēlreiz. Ja dati faktiski tika ievietoti un jÅ«s tos ievietojāt atkārtoti, notiek bloÄ·Ä“Å”anas atcelÅ”ana. Tas ir nepiecieÅ”ams, lai izvairÄ«tos no dublikātiem.

Un ir svarīgi arī, kā tas darbojas materializētiem skatiem. Ja dati tika dedublēti, ievietojot tos galvenajā tabulā, tad tie nenonāks arī materializētajā skatā.

Tagad par jautājumu. JÅ«su situācija ir sarežģītāka, jo jÅ«s ierakstāt atseviŔķu rindu dublikātus. Tas ir, tiek dublēta nevis visa pakotne, bet gan noteiktas lÄ«nijas, un tās sabrÅ«k fonā. PatieŔām, dati tiks sakļauti galvenajā tabulā, bet nesakļautie dati nonāks materializētajā skatā, un sapludināŔanas laikā ar materializētajiem skatiem nekas nenotiks. Jo materializēts skats ir nekas vairāk kā ievietoÅ”anas sprÅ«da. Citu operāciju laikā ar to nekas papildus nenotiek.

Un es nevaru jÅ«s Å”eit iepriecināt. Jums tikai jāmeklē konkrēts risinājums Å”im gadÄ«jumam. Piemēram, vai ir iespējams to atkārtoti atskaņot materializētā skatā, un dublÄ“Å”anas metode varētu darboties tāpat. Bet diemžēl ne vienmēr. Ja tas tiek apkopots, tas nedarbosies.

Kirils Å vakovs: Mums savulaik bija arÄ« kruÄ·u celtniecÄ«ba. Bija problēma, ka ir reklāmas seansi, un ir daži dati, kurus mēs varam parādÄ«t reāllaikā - tie ir tikai seansi. Tie tiek dublēti reti, taču, ja tas notiks, mēs tos vēlāk jebkurā gadÄ«jumā sakļausim. Un bija lietas, kuras nevarēja dublēt ā€“ klikŔķi un viss Å”is stāsts. Bet es arÄ« gribēju tos parādÄ«t gandrÄ«z uzreiz.

Kā tapa materializētie skati? Bija skati, kur tas tika rakstÄ«ts tieÅ”i - tas tika rakstÄ«ts uz neapstrādātiem datiem un rakstÄ«ts uz skatiem. Tur kaut kad dati nav Ä«sti pareizi, dublējas utt. Un ir tabulas otrā daļa, kur tie izskatās tieÅ”i tāpat kā materializētie skati, tas ir, tie ir absolÅ«ti identiski pēc struktÅ«ras. Reizēm mēs pārrēķinām datus, saskaitām datus bez dublikātiem, rakstām uz tām tabulām.

Mēs izmantojām API ā€” tas nedarbosies ClickHouse manuāli. Un API izskatās: kad man ir tabulas pēdējā papildinājuma datums, kur tiek garantēts, ka pareizi dati jau ir aprēķināti, un tas izdara pieprasÄ«jumu vienai tabulai un citai tabulai. No viena pieprasÄ«jums atlasa lÄ«dz noteiktam laika periodam, bet no otra iegÅ«st to, kas vēl nav aprēķināts. Un tas darbojas, bet ne tikai ar ClickHouse.

Ja jums ir sava veida API - analÄ«tiÄ·iem, lietotājiem -, tad principā Ŕī ir iespēja. Tu vienmēr skaita, vienmēr skaita. To var izdarÄ«t vienu reizi dienā vai citā laikā. JÅ«s izvēlaties sev sortimentu, kas jums nav vajadzÄ«gs un nav kritisks.

ClickHouse ir daudz žurnālu. Kā es varu īsumā redzēt visu, kas notiek ar serveri?

ClickHouse ir ļoti daudz dažādu žurnālu, un Å”is skaits pieaug. Jaunajās versijās dažas no tām ir iespējotas pat pēc noklusējuma; vecākās versijās tās ir jāiespējo atjaunināŔanas laikā. Tomēr viņu kļūst arvien vairāk. Galu galā es vēlētos redzēt, kas tagad notiek ar manu serveri, varbÅ«t kādā kopsavilkuma informācijas panelÄ«.

Vai jums ir ClickHouse komanda vai jÅ«su draugu komandas, kas atbalsta kādu gatavu informācijas paneļu funkcionalitāti, kas Å”os žurnālus parādÄ«tu kā gatavu produktu? Galu galā vienkārÅ”i aplÅ«kot žurnālus pakalpojumā ClickHouse ir lieliski. Bet bÅ«tu ļoti forÅ”i, ja tas bÅ«tu jau sagatavots informācijas paneļa formā. Es no tā saņemtu sitienu.

Ir informācijas paneļi, lai gan tie nav standartizēti. MÅ«su uzņēmumā ClickHouse izmanto apmēram 60 komandas, un dÄ«vainākais ir tas, ka daudzām no tām ir informācijas paneļi, ko viņi paÅ”i ir izgatavojuÅ”i un nedaudz atŔķirÄ«gi. Dažas komandas izmanto iekŔēju Yandex.Cloud instalāciju. Ir dažas gatavas atskaites, lai gan ne visas nepiecieÅ”amās. Citiem ir savs.

Maniem kolēģiem no Metrica ir savs informācijas panelis Grafānā, un man ir savs viņu klasterim. Es meklēju tādas lietas kā keÅ”atmiņas trāpÄ«jums serif keÅ”atmiņai. Un vēl grÅ«tāk ir tas, ka mēs izmantojam dažādus rÄ«kus. Es izveidoju savu informācijas paneli, izmantojot ļoti vecu rÄ«ku Graphite-web. ViņŔ ir pilnÄ«gi neglÄ«ts. Un joprojām lietoju tā, lai gan Grafana droÅ”i vien bÅ«tu ērtāka un skaistāka.

Informācijas paneļu pamatlieta ir tāda pati. Tie ir klastera sistēmas rādÄ«tāji: CPU, atmiņa, disks, tÄ«kls. Citi - vienlaicÄ«gu pieprasÄ«jumu skaits, vienlaicÄ«gu sapludināŔanu skaits, pieprasÄ«jumu skaits sekundē, MergeTree tabulas nodalÄ«jumu maksimālais gabalu skaits, replikācijas nobÄ«de, replikācijas rindas lielums, ievietoto rindu skaits sekundē, ievietoto bloku skaits sekundē. Tas ir viss, ko iegÅ«st nevis no žurnāliem, bet no metrikām.

Vladimirs Kolobajevs: Aleksej, es gribētu to nedaudz izlabot. Ir Grafana. Grafana ir datu avots, kas ir ClickHouse. Tas ir, es varu iesniegt pieprasÄ«jumus no Grafana tieÅ”i ClickHouse. ClickHouse ir tabula ar žurnāliem, tā visiem ir vienāda. Rezultātā es vēlos piekļūt Å”ai žurnāla tabulai programmā Grafana un redzēt mana servera veiktos pieprasÄ«jumus. BÅ«tu lieliski, ja bÅ«tu Ŕāds informācijas panelis.

Pats braucu ar velosipēdu. Bet man ir jautājums - ja tas viss ir standartizēts un Grafana izmanto visi, kāpēc Yandex nav tik oficiāla informācijas paneļa?

Kirils Å vakovs: Faktiski datu avots, kas tiek izmantots ClickHouse, tagad atbalsta Altinity. Un es tikai gribu dot vektoru, kur rakt un kam stumt. Varat jautāt viņiem, jo ā€‹ā€‹Yandex joprojām ražo ClickHouse, nevis stāstu par to. Altinity ir galvenais uzņēmums, kas paÅ”laik reklamē ClickHouse. Viņi viņu nepametÄ«s, bet atbalstÄ«s. Tā kā principā, lai Grafana vietnē augÅ”upielādētu informācijas paneli, ir tikai jāreÄ£istrējas un jāaugÅ”upielādē - nav Ä«paÅ”u problēmu.

Aleksejs Milovidovs: Pēdējā gada laikā ClickHouse ir pievienojis daudzas vaicājumu profilÄ“Å”anas iespējas. Katram pieprasÄ«jumam par resursu izmantoÅ”anu ir metrika. Un pavisam nesen mēs pievienojām vēl zemāka lÄ«meņa vaicājumu profilētāju, lai redzētu, kur vaicājums tērē katru milisekundi. Bet, lai izmantotu Å”o funkcionalitāti, man ir jāatver konsoles klients un jāievada pieprasÄ«jums, ko es vienmēr aizmirstu. Es to kaut kur saglabāju un aizmirstu, kur tieÅ”i.

Es vēlos, lai bÅ«tu rÄ«ks, kas tikko teica: Å”eit ir jÅ«su smagie vaicājumi, kas sagrupēti pēc vaicājumu klases. Es nospiedu vienu, un viņi man teica, ka tāpēc tas ir smags. Tagad tāda risinājuma nav. Un tieŔām ir diezgan dÄ«vaini, ka, kad cilvēki man jautā: ā€œSakiet man, vai ir kādi gatavi Grafana informācijas paneļi?ā€, es saku: ā€œDodieties uz Grafana vietni, tur ir ā€œDashboardsā€ kopiena un tur ir informācijas panelis. no Dimka, ir informācijas panelis no Kostjana. Es nezinu, kas tas ir, es pats to neesmu lietojis.

Kā ietekmēt sapludināŔanu, lai serveris neiekristu OOM?

Man ir tabula, tabulā ir tikai viens nodalījums, tas ir ReplaceingMergeTree. Es tajā rakstu datus četrus gadus. Man vajadzēja tajā veikt izmaiņas un dzēst dažus datus.

Es to izdarÄ«ju, un Ŕī pieprasÄ«juma apstrādes laikā tika patērēta visa atmiņa visos klastera serveros, un visi klastera serveri tika iekļauti OOM. Tad viņi visi kopā piecēlās, sāka apvienot Å”o paÅ”u darbÄ«bu, Å”o datu bloku un atkal iekrita OOM. Tad viņi atkal piecēlās un atkal krita. Un Ŕī lieta neapstājās.

Tad izrādÄ«jās, ka Ŕī patiesÄ«bā bija kļūda, ko puiÅ”i izlaboja. Tas ir ļoti forÅ”i, liels paldies. Bet atlikums palika. Un tagad, kad es domāju par kaut kāda veida sapludināŔanu tabulā, man rodas jautājums - kāpēc es nevaru kaut kā ietekmēt Ŕīs sapludināŔanas? Piemēram, ierobežojiet tos ar nepiecieÅ”amo RAM apjomu vai principā ar apjomu, kas apstrādās Å”o konkrēto tabulu.

Man ir tabula ar nosaukumu ā€œMetrikaā€, lÅ«dzu, apstrādājiet to divos pavedienos. Nav nepiecieÅ”ams paralēli veidot desmit vai piecus sapludinājumus, dariet to divatā. Es domāju, ka man pietiek atmiņas diviem, bet ar to var nepietikt, lai apstrādātu desmit. Kāpēc bailes paliek? Jo tabula aug, un kādreiz es saskarÅ”os ar situāciju, kas principā vairs nav kļūdas dēļ, bet gan tāpēc, ka dati mainÄ«sies tik lielā daudzumā, ka man vienkārÅ”i nepietiks atmiņas serveris. Un tad serveris sapludināŔanas laikā avarē OOM. Turklāt es varu atcelt mutāciju, bet Merdži vairs nav.

Ziniet, apvienojot serveris neiekļūs OOM, jo apvienojot, RAM apjoms tiek izmantots tikai vienam nelielam datu diapazonam. Tātad viss būs kārtībā neatkarīgi no datu apjoma.

Vladimirs Kolobajevs: Labi. Å eit moments ir tāds, ka pēc kļūdas izlaboÅ”anas es lejupielādēju sev jaunu versiju un uz citas tabulas, mazākas, kur ir daudz nodalÄ«jumu, es veicu lÄ«dzÄ«gu darbÄ«bu. Un apvienoÅ”anas laikā serverÄ« tika sadedzināta aptuveni 100 GB RAM. Man bija 150 aizņemti, 100 apēsti un atlicis 50 GB logs, tāpēc es neiekritu OOM.

Kas Å”obrÄ«d mani pasargā no iekriÅ”anas OOM, ja tas faktiski patērē 100 GB RAM? Ko darÄ«t, ja pēkŔņi beidzas sapludināto RAM?

Aleksejs Milovidovs: Ir tāda problēma, ka RAM patēriņŔ speciāli apvienoÅ”anai nav ierobežots. Un otra problēma ir tāda, ka ja ir pieŔķirts kaut kāds sapludinājums, tad tas ir jāizpilda, jo tas tiek ierakstÄ«ts replikācijas žurnālā. Replikācijas žurnāls ir darbÄ«bas, kas nepiecieÅ”amas, lai replikā nonāktu konsekventā stāvoklÄ«. Ja neveiksit manuālas manipulācijas, kas atcels Å”o replikācijas žurnālu, sapludināŔana bÅ«s jāveic vienā vai otrā veidā.

Protams, nebÅ«tu lieki RAM ierobežojums, kas ā€œkatram gadÄ«jumamā€ aizsargā pret OOM. Tas nepalÄ«dzēs sapludināŔanai pabeigt, tā sāksies no jauna, sasniegs kādu slieksni, liks izņēmumu un tad sāks no jauna ā€” nekas labs no tā neiznāks. Bet principā bÅ«tu lietderÄ«gi Å”o ierobežojumu ieviest.

Kā tiks izstrādāts ClickHouse Golang draiveris?

Golang draiveri, kuru uzrakstÄ«ja Kirils Å vakovs, tagad oficiāli atbalsta ClickHouse komanda. ViņŔ ClickHouse repozitorijā, viņŔ tagad ir liels un Ä«sts.

Maza piezÄ«me. Ir brÄ«niŔķīga un iemīļota bezgalÄ«gas kārtÄ«bas normālu formu krātuve - tā ir Vertica. Viņiem ir arÄ« savs oficiālais python draiveris, ko atbalsta Vertica izstrādātāji. Un vairākas reizes gadÄ«jās, ka atmiņas versijas un draivera versijas diezgan krasi atŔķīrās, un draiveris kādā brÄ«dÄ« pārstāja darboties. Un otrais punkts. Atbalstu Å”im oficiālajam draiverim, manuprāt, nodroÅ”ina ā€œnipeļaā€ sistēma - jÅ«s uzrakstāt viņiem problēmu, un tas uzkaras uz visiem laikiem.

Man ir divi jautājumi. Tagad Kirila Golang draiveris ir gandrÄ«z noklusējuma veids, kā sazināties no Golang ar ClickHouse. Ja vien kāds joprojām nesazinās caur http saskarni, jo viņam tā patÄ«k. Kā turpināsies Ŕī draivera attÄ«stÄ«ba? Vai tas tiks sinhronizēts ar jebkādām pārkāpjoŔām izmaiņām paŔā repozitorijā? Un kāda ir jautājuma izskatÄ«Å”anas procedÅ«ra?

Kirils Švakovs: Pirmais ir tas, kā viss tiek organizēts birokrātiski. Šis punkts netika apspriests, tāpēc man nav ko atbildēt.

Lai atbildētu uz jautājumu par problēmu, mums ir nepiecieÅ”ama neliela vadÄ«tāja vēsture. Es strādāju uzņēmumā, kurā bija daudz datu. Tas bija reklāmas vērpējs ar milzÄ«gu skaitu notikumu, kas kaut kur jāsaglabā. Un kādā brÄ«dÄ« parādÄ«jās ClickHouse. Mēs to aizpildÄ«jām ar datiem, un sākumā viss bija kārtÄ«bā, bet pēc tam ClickHouse avarēja. Tajā brÄ«dÄ« mēs nolēmām, ka mums tas nav vajadzÄ«gs.

Gadu vēlāk mēs atgriezāmies pie idejas izmantot ClickHouse, un mums vajadzēja kaut kā tur ierakstÄ«t datus. Ievadziņa bija Ŕāda: aparatÅ«ra ir ļoti vāja, ir maz resursu. Bet mēs vienmēr esam strādājuÅ”i Ŕādā veidā, un tāpēc mēs skatÄ«jāmies uz dzimto protokolu.

Tā kā strādājām Go, tad bija skaidrs, ka vajag Go Å”oferi. Es to darÄ«ju gandrÄ«z uz pilnu slodzi ā€“ tas bija mans darba uzdevums. Mēs to novedām lÄ«dz noteiktam brÄ«dim, un principā neviens neuzskatÄ«ja, ka kāds cits, izņemot mÅ«s, to izmantos. Tad CloudFlare nāca ar tieÅ”i tādu paÅ”u problēmu, un kādu laiku mēs ar viņiem strādājām ļoti gludi, jo viņiem bija vienādi uzdevumi. Turklāt mēs to darÄ«jām gan ClickHouse, gan draiverÄ«.

Kādā brÄ«dÄ« es to vienkārÅ”i pārtraucu darÄ«t, jo mana aktivitāte ClickHouse un darba ziņā nedaudz mainÄ«jās. Tāpēc jautājumi nav slēgti. Periodiski cilvēki, kuriem kaut kas ir vajadzÄ«gs, paÅ”i iesaistās krātuvē. Tad skatos pull pieprasÄ«jumu un dažreiz pat pats kaut ko rediģēju, bet tas notiek reti.

Es gribu atgriezties pie vadÄ«tāja. Pirms vairākiem gadiem, kad visa Ŕī lieta sākās, ClickHouse arÄ« bija atŔķirÄ«gs un ar dažādām iespējām. Tagad mums ir izpratne par to, kā pārveidot draiveri, lai tas labi darbotos. Ja tas notiks, tad 2. versija jebkurā gadÄ«jumā bÅ«s nesavienojama sakrājuÅ”os kruÄ·u dēļ.

Es nezinu, kā organizēt Å”o lietu. Man paÅ”am nav daudz laika. Ja daži cilvēki piebeigs Å”oferi, es varu viņiem palÄ«dzēt un pastāstÄ«t, kā rÄ«koties. Bet Yandex aktÄ«vā lÄ«dzdalÄ«ba projekta izstrādē vēl nav apspriesta.

Aleksejs Milovidovs: PatiesÄ«bā par Å”iem braucējiem vēl nav nekādas birokrātijas. VienÄ«gais ir tas, ka tie tiek iesniegti oficiālai organizācijai, tas ir, Å”is draiveris tiek atzÄ«ts par Go oficiālo noklusējuma risinājumu. Ir daži citi vadÄ«tāji, bet tie nāk atseviŔķi.

Mums nav iekŔējas attÄ«stÄ«bas Å”iem draiveriem. Jautājums ir par to, vai mēs varam pieņemt darbā atseviŔķu cilvēku nevis Å”im konkrētajam autovadÄ«tājam, bet gan visu kopienas autovadÄ«tāju attÄ«stÄ«bai, vai arÄ« mēs varam atrast kādu no malas.

Ārējā vārdnÄ«ca netiek ielādēta pēc atsāknÄ“Å”anas ar iespējotu iestatÄ«jumu lazy_load. Ko darÄ«t?

Mums ir iespējots iestatÄ«jums lazy_load, un pēc servera pārstartÄ“Å”anas vārdnÄ«ca netiek ielādēta pati. Tas tiek parādÄ«ts tikai pēc tam, kad lietotājs piekļūst Å”ai vārdnÄ«cai. Un pirmo reizi piekļūstot tam, tiek parādÄ«ta kļūda. Vai ir iespējams kaut kā automātiski ielādēt vārdnÄ«cas, izmantojot ClickHouse, vai arÄ« jums vienmēr ir jākontrolē to gatavÄ«ba, lai lietotāji nesaņemtu kļūdas?

Iespējams, mums ir veca ClickHouse versija, tāpēc vārdnīca netika ielādēta automātiski. Vai tas tā varētu būt?

Pirmkārt, vārdnÄ«cas var piespiedu kārtā ielādēt, izmantojot vaicājumu sistēmas pārlādÄ“Å”anas vārdnÄ«cas. Otrkārt, par kļūdu - ja vārdnÄ«ca jau ir ielādēta, tad vaicājumi darbosies, pamatojoties uz datiem, kas tika ielādēti. Ja vārdnÄ«ca vēl nav ielādēta, tā tiks ielādēta tieÅ”i pieprasÄ«juma laikā.

Tas nav Ä«paÅ”i ērti smagām vārdnÄ«cām. Piemēram, jums ir jāizvelk miljons rindu no MySQL. Kāds veic vienkārÅ”u atlasi, taču Ŕī atlase gaidÄ«s to paÅ”u miljonu rindu. Å eit ir divi risinājumi. Pirmais ir izslēgt lazy_load. Otrkārt, kad serveris ir atvērts, pirms tā noslodzes dariet sistēmas pārlādÄ“Å”anas vārdnÄ«ca vai vienkārÅ”i veiciet vaicājumu, kas izmanto vārdnÄ«cu. Pēc tam vārdnÄ«ca tiks ielādēta. Jums jākontrolē vārdnÄ«cu pieejamÄ«ba ar iespējotu iestatÄ«jumu lazy_load, jo ClickHouse tās neielādē automātiski.

Atbilde uz pēdējo jautājumu ir vai nu versija, kas ir veca, vai arī tā ir jāatkļūdo.

Ko darÄ«t ar to, ka sistēmas pārlādÄ“Å”anas vārdnÄ«cas neielādē nevienu no daudzajām vārdnÄ«cām, ja vismaz viena no tām avarē ar kļūdu?

Ir vēl viens jautājums par sistēmas pārlādÄ“Å”anas vārdnÄ«cām. Mums ir divas vārdnÄ«cas ā€“ viena netiek ielādēta, otra ir ielādēta. Å ajā gadÄ«jumā sistēmas atkārtotas ielādes vārdnÄ«cas neielādē nevienu vārdnÄ«cu, un jums ir jāielādē noteikta vārdnÄ«ca pēc tās nosaukuma, izmantojot sistēmas atkārtotas ielādes vārdnÄ«cu. Vai tas ir saistÄ«ts arÄ« ar ClickHouse versiju?

ES gribu padarÄ«t Tevi laimÄ«gu. Å Ä« uzvedÄ«ba mainÄ«jās. Tas nozÄ«mē, ka, atjauninot ClickHouse, tas arÄ« mainÄ«sies. Ja neesat apmierināts ar savu paÅ”reizējo uzvedÄ«bu sistēmas pārlādÄ“Å”anas vārdnÄ«cas, atjauniniet, un cerēsim, ka tas mainÄ«sies uz labo pusi.

Vai ir kāds veids, kā ClickHouse konfigurācijā konfigurēt informāciju, bet nerādīt to kļūdu gadījumā?

Nākamais jautājums ir par kļūdām saistÄ«bā ar vārdnÄ«cu, proti, detaļām. Mēs esam norādÄ«juÅ”i savienojuma detaļas vārdnÄ«cas ClickHouse konfigurācijā, un, ja ir kļūda, mēs saņemam Å”o informāciju un paroli kā atbildi.

Mēs atrisinājām Å”o kļūdu, pievienojot informāciju ODBC draivera konfigurācijai. Vai ir kāds veids, kā konfigurēt informāciju ClickHouse konfigurācijā, bet nerādÄ«t Å”o informāciju kļūdu gadÄ«jumā?

Patiesais risinājums Å”eit ir norādÄ«t Å”os akreditācijas datus odbc.ini un paŔā ClickHouse norādÄ«t tikai ODBC datu avota nosaukumu. Tas nenotiks citiem vārdnÄ«cu avotiem - ne vārdnÄ«cai ar MySQL, ne citiem, jums nevajadzētu redzēt paroli, kad saņemat kļūdas ziņojumu. Es meklÄ“Å”u arÄ« ODBC ā€” ja tas pastāv, jums tas vienkārÅ”i jānoņem.

Bonuss: tālummaiņas foni no sapulcēm

NoklikŔķinot uz attēla, neatlaidÄ«gākajiem lasÄ«tājiem atvērsies bonusa foni no salidojumiem. DzÄ“Å”am uguni kopā ar Avito tehnoloÄ£iju talismaniem, apspriežamies ar kolēģiem no sistēmas administratora istabas vai vecās skolas datorkluba, kā arÄ« ikdienā vadām tikÅ”anās zem tilta uz grafiti fona.

ClickHouse pieredzējuÅ”iem lietotājiem jautājumos un atbildēs

Avots: www.habr.com

Pievieno komentāru