Në prill, inxhinierët e Avito po organizonin një takim online me zhvilluesin kryesor të ClickHouse, Aleksej Milovidov dhe Kirill Shvakov, një zhvillues Golang nga kompania Integros. Diskutuan se si ne përdorim sistemin e menaxhimit të bazave të të dhënave dhe çfarë vështirësish kemi.
Duke u nisur nga takimi, ne përgatitëm një artikull me përgjigjet e ekspertëve për pyetjet tona dhe ato të shikuesve në lidhje me backup-in, resharding-un e të dhënave, fjalorët e jashtëm, driverin Golang dhe përditësimin e versioneve të ClickHouse. Kjo mund të jetë e dobishme për zhvilluesit që tashmë po punojnë aktivisht me DB-në e "Yandex" dhe interesohen për të tashmen dhe të ardhmen e saj. Nëse nuk është thënë ndryshe, përgjigjet janë nga Aleksej Milovidov.
Kujdes, nën kat ka shumë tekst. Shpresojmë se përmbajta me pyetjet do t'ju ndihmojë të orientoheni.
Përmbajtja
Nëse nuk dëshironi të lexoni tekstin, mund të shikoni regjistrimin e mbledhjeve . Koha e regjistrimit - në komentarin e parë nën video.
ClickHouse vazhdon të përmirësohet, ndërsa të dhënat tona nuk përditësohen. Çfarë duhet bërë për këtë?
ClickHouse vazhdon të përmirësohet, ndërsa të dhënat tona, të cilat ishin përpunuar me optimize final, nuk përditësohen dhe qëndrojnë në kopjen rezervë.
Supozoni se na ndodhi ndonjë problem dhe të dhënat u humbën. Ne vendosëm të rikuperohemi, dhe rezultoi se partitë e vjetra, të cilat janë ruajtur në serverët e kopjimeve rezervë, kanë shumë dallime me versionin aktual të ClickHouse. Çfarë duhet të bëjmë në një situatë të tillë, dhe a është kjo e mundur?
Situata, kur rikuperoni të dhënat nga një kopje rezervë në formatin e vjetër, ndërsa në versionin e ri ato nuk lidheshin, nuk është e mundur. Ne ndjekim që formati i të dhënave në ClickHouse të mbetet gjithmonë prapë i përshtatshëm. Kjo është shumë më e rëndësishme se prapë përshtatshmëria në funksionalitet, nëse është ndryshuar sjellja e ndonjë funksioni të përdorur rrallë. Të dhënat që ruhen në disk, versioni i ri i ClickHouse duhet të jetë gjithmonë në gjendje t’i lexojë. Kjo është një ligj.
Cilat janë praktikat më të mira aktualisht për backup-in e të dhënave nga ClickHouse?
Si të bëjmë kopje rezervë duke pasur parasysh se kemi operacione optimize final, një bazë të dhënash të madhe në terabajtë, dhe të dhëna që përditësohen, le të themi, për tri ditët e fundit, dhe më pas nuk ndodhin më procedura me to?
Ne mund të zhvillojmë një zgjidhje të vetëfinancuar dhe në bash përdorim: mbledh këto kopje rezervë siç është e nevojshme. Ndoshta nuk ka nevojë përra, dhe biçikleta është shpikur prej kohësh?
Për fillim rreth praktikave më të mira. Kolegët e mi gjithmonë këshillojnë që në përgjigje të pyetjeve për kopjet rezervë të kujtojmë shërbimin 'Yandex.Cloud', ku kjo detyrë është tashmë zgjidhur. Prandaj, shfrytëzoni atë nëse keni mundësinë.
Nuk ka zgjidhje të plotë, të integruar 100% në ClickHouse për backup. Ekzistojnë disa modele që mund të përdoren. Për të marrë një zgjidhje të plotë, do t'ju duhet ose të vishni pak dorë manualisht, ose të bëni mbështjellje në formën e skenarëve.
Do ta filloj me zgjidhjet më të thjeshta dhe do të mbyll me ato më të avancuara në varësi të volumit të të dhënave dhe madhësisë së klasterit. Sa më i madh të jetë klasteri, aq më e komplikuar bëhet zgjidhja.
Nëse tabela me të dhëna zë vetëm disa gigabajt, backup mund të bëhet kështu:
- Ruani definicionet e tabelave, pra metadata — show create table.
- Bëni një dump me ndihmën e klientit ClickHouse — select * from table në skedarin. Nëse është në formë tabulare, do të merrni një skedar në formatin TabSeparated. Nëse dëshironi më efektivisht — mund të jetë në formatin Native.
Nëse volumi i të dhënave është më i madh, backup do të marrë më shumë kohë dhe hapësirë. Ky quhet backup logjik, nuk është i lidhur me formatin e të dhënave ClickHouse. Nëse e keni, atëherë në rastin ekstrem do të mund të merrni backup dhe ta ngarkoni në MySQL për rikthim.
Për raste më të avancuara, ClickHouse ka ndërtuar mundësinë për të krijuar snapshot të partitive në sistemin lokal të skedarëve. Kjo mundësi është e disponueshme në formën e një pyetjeje alter table freeze partition. Ose thjesht alter table freeze — kjo është një snapshot i të gjithë tabelës.
Snapshot do të krijohet tërësisht për një tabelë në një shard, domethënë nuk është e mundur të krijoni një snapshot të qëndrueshëm për të gjithë klasterin në këtë mënyrë. Por për shumicën e detyrave nuk ka nevojë për një të tillë dhe mjafton të ekzekutoni kërkesën në secilin shard për të marrë një snapshot të qëndrueshëm. Ai krijohet në formën e hardlinkeve dhe për këtë arsye nuk zënë hapësirë të tepruar. Më pas, këtë snapshot e kopjoni në serverin e backup-it ose në depozitat që përdorni për backup.
Rikthimi i një backup-i të tillë është mjaft i lehtë. E para — krijoni tabelat sipas përkufizimeve ekzistuese të tabelave. Më pas kopjoni snapshot-et e ruajtura të partitive në Directory-Detached për këto tabela dhe ekzekutoni kërkesën attach partition. Kjo zgjidhje është mjaft e përshtatshme për volumet më të ndërlikuara të të dhënave.
Ndonjëherë, nevojitet diçka edhe më të avancuar — në ato raste kur keni dhjetëra ose madje qindra terabajt në çdo server dhe qindra serverë. Këtu ka një zgjidhje që e kam parë nga kolegët tanë në “Yandex.Metrika”. Nuk do ta rekomandoja për të gjithë — lexoni dhe vendosni vetë nëse i përshtatet ose jo.
Fillimisht, duhet të krijoni disa serverë me raftet e mëdha të disqeve. Më pas, në këta serverë të ngrini disa serverë ClickHouse dhe t’i konfiguroni që të punojnë si një replikë tjetër për të njëjtat sharde. Dhe më pas, të përdorni në këta serverë sistemin e skedarëve ose ndonjë mjet që lejon krijimin e snapshot-eve. Ka dy mundësi. Mundësia e parë është snapshot-et LVM, mundësia e dytë është ZFS në Linux.
Pas kësaj, çdo ditë duhet të krijoni një snapshot, ai do të ekzistojë dhe do të marrë disa hapësirë. Natyrisht, nëse të dhënat ndryshojnë, me kalimin e kohës hapësira do të rritet. Ky snapshot mund të përfitohet në çdo moment dhe të rikuperoni të dhënat, një zgjidhje e tillë është disi e çuditshme. Gjithashtu, duhet të kufizoni këto replika në konfigurim, në mënyrë që ato të mos përpiqen të bëhen liderë.
A do të jetë e mundur të organizohet një vonesë e kontrolluar e replikave në vëllime?
Këtë vit planifikoni të bëni vale në ClickHouse. A do të jetë e mundur të organizoni një vonesë të kontrolluar të replikave në to? Ne do të dëshironim ta përdorim këtë për të siguruar veten nga skenarët negativë me alteret dhe ndryshime të tjera.
A mund të bëhen ndonjë rollback për alteret? Për shembull, në një valë ekzistuese të themi që deri në këtë pikë të aplikojmë ndryshimet, dhe nga kjo pikë të ndalojmë aplikimin e ndryshimeve?
Nëse në klasterin tonë vjen një komandë dhe e shemben atë, ne kemi një replikë hipotetike me një vonesë prej një ore, ku mund të themi, le të përdorim pikërisht atë në këtë moment, por nuk do të aplikojmë ndryshimet e fundit dhjetë minutash në të?
Për fillimin e kontrollimit të vonesës së replikave. Një kërkesë e tillë nga përdoruesit ishte, dhe ne krijuam një çështje në GitHub me kërkesën: “Nëse dikujt i nevojitet kjo, jepni një like, vendosni një zemër”. Askush nuk vendosi, dhe çështja u mbyll. Megjithatë, tashmë mund të merrni një mundësi të tillë, duke konfiguruar ClickHouse. Megjithatë, vetëm duke filluar nga versioni 20.3.
ClickHouse vazhdimisht kryen bashkimin e të dhënave në sfond — merxh. Kur merxh është realizuar, një grup i caktuar i copave të të dhënave zëvendësohet me një copë më të madhe. Në këtë rast, copat e të dhënave që ishin më parë vazhdojnë të mbesin në disk për një kohë të caktuar.
Së pari, ato vazhdojnë të ruhen derisa të ketë kërkesa select që i përdorin, për të siguruar një funksionim jo-bllokues. Kërkesat select lehtësisht lexojnë nga copat e vjetra.
Së dyti, ka edhe një prag të kohës — copat e vjetra të të dhënave qëndrojnë në disk për tetë minuta. Këto tetë minuta mund të konfigurohen dhe të shndërrohen madje në një ditë. Kjo do të kushtojë hapësirë në disk: në varësi të fluksit të të dhënave, ndodh që për ditën e fundit të dhënat jo vetëm që do të dyfishohen, por mund të bëhen deri pesë herë më shumë. Megjithatë, ju do të jeni në gjendje të ndaloni serverin ClickHouse nëse ndodh ndonjë problem serioz dhe të zgjidhni gjithçka.
Tani lind pyetja, si e mbron kjo nga alteret. Këtu vlen të shikohet më thellë, sepse në versionet e vjetra të ClickHouse, alteri punonte në atë mënyrë që thjesht ndryshonte copat. Ka një copë të dhënash me disa skedarë dhe ne bëjmë, për shembull, alter drop column. Atëherë ky kolon është fizikisht i fshirë nga të gjitha copat.
Por që nga versioni 20.3, mekanizmi i altereve është ndryshuar plotsisht dhe tani copat e të dhënave janë gjithmonë imutabile. Ato nuk ndryshojnë fare — alteret tani funksionojnë në një mënyrë të ngjashme me merxhet. Në vend që të ndryshojmë një copë në vend, ne krijojmë një të re. Në copën e re, skedarët që nuk janë ndryshuar bëhen hardlink dhe, nëse kemi fshirë një kolon, ai thjesht do të mungojë në copën e re. Copë e vjetër do të fshihet automatikisht pas tetë minutash, dhe këtu mund të rregullojmë parametrat e përmendur më sipër.
E njëjta gjë vlen për alteret e tipit mutacione. Kur ju bëni alter delete ose alter update, ai nuk e ndryshon copën, por krijon një të re. Pastaj fshin të vjetrën.
Çfarë të bëjmë nëse struktura e tabelës ka ndryshuar?
Si të rrisni një backup që është bërë me skemën e vjetër? Dhe pyetja e dytë për rastin me snapshotet dhe mjetet e sistemit të skedarëve. A është e pranueshme këtu Btrfs në vend të ZFS në Linux LVM?
Nëse bëni attach partition nëse keni partitione me një strukturë tjetër, ClickHouse do t'ju njoftojë se kjo nuk është e lejueshme. Zgjidhja është e tillë. E para - krijoni një tabelë përkohshme të tipit MergeTree me strukturën e vjetër, lidhni atje të dhënat me anë të attach, bëni një kërkesë për alter. Më pas, mund të kopjoni ose të transferoni këto të dhëna dhe të bëni përsëri attach, ose të përdorni kërkesën alter table move partition.
Tani pyetja e dytë - a mund të përdoret Btrfs. Së pari, nëse keni LVM, atëherë mjaftojnë snapshot-et e LVM, ndërsa sistemi i skedarëve mund të jetë dhe ext4, kjo nuk ka rëndësi. Me Btrfs, gjithçka varet nga përvoja juaj në përdorimin e saj. Ky është një sistem i skedarëve i pjekur, por ende lindin disa dyshime në lidhje me mënyrën si do të funksionojë në praktikë në një skenar të caktuar. Nuk do ta rekomandoja këtë nëse nuk keni Btrfs në prodhim.
Cilat janë praktikat më të mira aktualisht në resharding-un e të dhënave?
Pyetja për ricaktimin është e komplikuar dhe shumëdimensionale. Mund të përgjigjemi menjëherë me disa mundësi. Mund ta shohim nga një anë dhe të themi kështu - në ClickHouse nuk ka një mundësi të integruar për ricaktimin. Por kam frikë se kjo përgjigje nuk do t'i kënaqë askënd. Prandaj mund ta shohim nga një anë tjetër dhe të themi se në ClickHouse ka shumë mënyra për të ricaktuar të dhënat.
Nëse po i mbaron hapësira në klasër ose ai nuk po i përballon ngarkesat, ju shtoni serverë të rinj. Por këta serverë në parazgjedhje janë bosh, nuk ka të dhëna atje, nuk ka ngarkesë që shkon. Ju duhet të ri-shpërndani të dhënat në mënyrë që ato të jenë të shpërndara njëlloj në klastrin e ri, të zgjeruar.
Mënyra e parë që mund ta bëni këtë është të kopjoni një pjesë të partitioneve në serverët e rinj me anë të kërkesës alter table fetch partition. Për shembull, nëse kishit partitione sipas muajve, ju merrni muajin e parë të vitit 2017 dhe e kopjoni në një server të ri, pastaj kopjoni muajin e tretë në një server tjetër të ri. Dhe kështu veproni derisa të bëhet disi e barabartë.
Transferimi mund të bëhet vetëm për ato partitione që nuk ndryshojnë gjatë shkrimit. Për partitionet e freskëta, do të duhet të çaktivizoni shkrimin, sepse transferimi i tyre nuk është atomar. Përndryshe, do të merrni kopje të dhënash ose mungesa në të dhëna. Megjithatë, kjo metodë është praktike dhe funksionon mjaft efektivisht. Të dhënat e ngjeshura, pra, transferohen përmes rrjetit, do të thotë se të dhënat nuk ngjeshen dhe nuk rikodohen.
Ky këtij mënyre i mungon një disavantazh, i cili varet nga skema e sharding-ut, nëse ju e keni planifikuar këtë skemë sharding, cila ka qenë çelësi juaj i sharding-ut. Në shembullin tuaj për rastin me metrikat, çelësi i sharding-ut është hash-i i rrugës. Kur bëni një zgjedhje në tabelën e Distribuuar, ajo shkon menjëherë në të gjitha shardet e klasterit dhe merr të dhënat që ndodhen aty.
Kjo do të thotë se për ju nuk ka rëndësi të vërtetë se cilat të dhëna ndodhen në cilin shard. E rëndësishme është se të dhënat për një rrugë specifike ndodhen në një shard, por cili, nuk ka rëndësi. Në këtë rast, transferimi i particioneve të gatshme është i përshtatshëm, sepse gjatë kërkesave të zgjedhjes gjithashtu — para dhe pas risharding-ut, skema e vlerave nuk ka ndonjë rëndësi — ju do të merrni të dhëna të plota.
Por ndodhin edhe raste më komplekse. Nëse në nivelin e logjikës së aplikacionit ju planifikoni një skemë të veçantë sharding-u, që ky klient ndodhet në një shard të caktuar, dhe kërkesa mund të dërgohet menjëherë atje, dhe jo në tabelën e Distribuuar. Ose ju po përdorni një version mjaft të ri të ClickHouse dhe keni aktivizuar cilësimin optimize skip unused shards. Në këtë rast, gjatë kërkesës së zgjedhjes, shprehja në seksionin ku do të analizohet, dhe do të përcaktohet se në cilat shard-e duhet të shkoj në përputhje me skemën e sharding-ut. Kjo funksionon me kushtin që të dhënat të jenë vendosur saktësisht sipas kësaj skeme sharding-u. Nëse i keni rivendosur manualisht, përputhja mund të ndryshojë.
Pra, kjo është mënyra e parë. Dhe unë po pres përgjigjen tuaj, nëse kjo mënyrë është e përshtatshme, apo do të vazhdojmë më tej.
Vladimir Kolobayev, administrator kryesor i sistemit në Avito: Alexey, ajo mënyra që ju përmendët nuk i përshtatet shumë mirë, kur duhet të shpërndajmë ngarkesën duke përfshirë edhe leximin. Mund të marrim një particion, i cili është për një muaj dhe mund të transferojmë muajin e kaluar në një nod tjetër, por kur të vijë kërkesa për këto të dhëna, ne do të ngarkojmë vetëm atë. Por do të donim të ngarkonim të gjithë klasterin, sepse, përndryshe, për një kohë të caktuar, gjithë ngarkesa për lexim do të përballohet nga dy shard-e.
Alexey Milovidov: Përgjigja këtu është e çuditshme - po, është keq, por ndoshta do e kalojë. Do ta shpjegoj se si. Është e rëndësishme të shikoni skenarin e ngarkesës që vjen pas të dhënave tuaja. Nëse këto janë të dhëna monitorimi, atëherë pothuajse me siguri mund të themi se shumica dërrmuese e kërkesave vjen për të dhënat e freskëta.
Keni vendosur serverë të rinj, keni transferuar partition-et e vjetra, por gjithashtu e keni ndryshuar mënyrën se si regjistrohen të dhënat e freskëta. Dhe të dhënat e freskëta do të shpërndahen në të gjithë klasterin. Kështu, pas pesë minutash, kërkesat për pesë minutat e fundit do të ngarkojnë në mënyrë të barabartë klasterin, pas një dite kërkesat për 24 orët e fundit do të ngarkojnë në mënyrë të barabartë klasterin. Dhe kërkesat për muajin e kaluar, për fat të keq, do të shkojnë vetëm në një pjesë të serverëve të klasterit.
Por shpeshherë nuk do të keni kërkesa për shkurtin e vitit 2019. Më së shumti, nëse kërkesat janë për vitin 2019, ato do të jenë për të gjithë vitin - për një interval të madh kohor, dhe jo për një interval të vogël. Dhe kërkesa të tilla gjithashtu do të mund të ngarkojnë në mënyrë të barabartë klasterin. Por në përgjithësi, vërejtja juaj është krejtësisht e saktë, që është një zgjidhje ad hoc, e cila nuk shpërndan të dhënat në mënyrë plotësisht të barabartë.
Kam disa pika të tjera për përgjigjen e pyetjes. Njëra nga to është se si fillimisht të bëni skemën e shardimit në mënyrë që të ketë më pak dhimbje nga ripërdorimi. Kjo nuk është gjithmonë e mundur.
Për shembull, keni të dhëna monitorimi. Të dhënat e monitorimit rriten për tri arsye. E para - akumulimi i të dhënave historike. E dyta - rritja e trafikut. Dhe e treta - rritja e numrit të gjërave që bien nën monitorim. Më në fund, shfaqen mikroshërbime të reja dhe metrika që duhet të ruhen.
Ndoshta rritja më e madhe është e lidhur me arsyen e tretë - kjo është rritja e përdorimit të monitorimit. Dhe në këtë rast, është e rëndësishme të shikoni karakteristikat e ngarkesës, cila është kërkesa kryesore për select. Kërkesat kryesore për select, me siguri, do të vijnë nga një nëngrup i caktuar metrikash.
Për shembull, përdorimi i CPU në disa servera nga ndonjë shërbim. Kështu, ekziston një nënshtresë e caktuar e çelësave, përmes së cilës merrni këto të dhëna. Dhe vetë kërkesa për këto të dhëna, shumë për një grevë, është mjaft e thjeshtë dhe ekzekutohet brenda disa dhjetëra milisekondash. Përdoret për shërbimet e monitorimit, për panelin e kontrollit. Shpresoj se e kuptoj saktë.
Vladimir Kolobaev: Çështja është se ne shumë shpesh apelojmë në të dhënat historike, pasi ne në kohë reale krahasojmë pozitën aktuale me atë historike. Dhe për ne është e rëndësishme të kemi akses të shpejtë në një volum të madh të dhënash, dhe ClickHouse e bën këtë shumë mirë.
Keni të drejtë, shumica e kërkesave për lexim ndodhin gjatë ditët e fundit, ashtu si çdo sistem monitorimi. Por megjithatë, ngarkesa mbi të dhënat historike është gjithashtu mjaft e madhe. Ajo vjen kryesisht nga sistemi i alerteve, i cili çdo tridhjetë sekonda shkon dhe i kërkon ClickHouse-it: "Më jep të dhënat për gjashtë javët e fundit. Tani, ndihmoje të krijoj një mesatare lëvizëse prej tyre, dhe le të krahasojmë vlerën aktuale me atë historike."
Doja të thoja se për kërkesat shumë të freskëta kemi një tabelë tjetër të vogël, në të cilën ruajmë të dhënat për vetëm dy ditë, dhe kërkesat kryesore dërgohen aty. Në tabelën e madhe të sharduar dërgojmë vetëm kërkesat e mëdha historike.
Alexey Milovidov: Për fat të keq, për skenarin tuaj është mjaft i papërstatshëm, por do t'ju tregoj një përshkrim të dy skemave të këqija dhe të komplikuara të shardimit, që nuk duhet përdorur, por që përdoren në shërbimin e miqve të mi.
Ekziston një klaster kryesor me ngjarjet "Yandex.Metrika". Ngjarjet janë shikimet e faqeve, klikimet dhe kalimet. Shumica e kërkesave shkojnë për një sit të caktuar. Ju hapni shërbimin "Yandex.Metrika", keni një faqe — avito.ru, hyni në raport, dhe bëhet kërkesa për sitin tuaj.
Por ka edhe kërkesa të tjera — analitike dhe globale, që i bëjnë analistët e brendshëm. Për çdo rast, dua të theksoj se analistët e brendshëm bëjnë kërkesa vetëm për shërbimet e "Yandex". Por megjithatë, madje edhe shërbimet e "Yandex" përbëjnë një pjesë të konsiderueshme të të gjitha të dhënave. Këto janë kërkesa jo për numëruesit e caktuar, por për filtrimin më të gjerë.
Si si organizojmë të dhënat në një mënyrë që të funksionojë efektivisht për një matës dhe të përballojë kërkesa globale gjithashtu? Sfidat përfshijnë numrin e kërkesave në ClickHouse në klasterin 'Metrika' — disa mijëra në sekondë. Këtu, një server ClickHouse nuk mund të përballojë disa mijëra kërkesa të ndërlikuara në sekondë.
Madhësia e klasterit është rreth pesëqind e ca serverë. Nëse thjesht mbështetemi në një tabelë të shpërndarë mbi këtë klaster dhe dërgojmë disa mijëra kërkesa, do të bëhet edhe më keq se të dërgojmë ato në një server. Nga ana tjetër, mundësia se të dhënat janë të shpërndara barazisht dhe ne kërkojmë nga të gjithë serverët, e eliminojmë menjëherë.
Ka një mundësi të kundërt diametralisht. Imagjinoni se nëse ne do të shpërndanim të dhënat sipas faqeve të internetit, dhe kërkesa për një faqe të vetme do të shkonte në një shard. Tani klasteri mund ta përballojë deri në dhjetë mijë kërkesa në sekondë, por në një shard, ndonjë kërkesë do të funksionojë shumë ngadalë. Ai nuk do të jetë më në gjendje të shkallëzohet sipas kapacitetit. Sidomos nëse kjo është faqja avito.ru. Nuk do të zbulonim ndonjë sekret nëse themi se Avito është një nga faqet më të vizituara në Runet. Edhe përpunimi i saj në një shard do të ishte një çmenduri.
Prandaj, skema e shpërndarjes është dizajnuar në një mënyrë më të mençur. I gjithë klasteri është ndarë në një numër të caktuar klasterkash, që ne i quajmë nivele. Brenda secilit klasterkë janë nga dhjetë deri në disa dhjetëra shard-e. Dhe gjithsej ka tridhjetë e nëntë të tillë.
Si e shkallëzojmë të gjithë këtë? Numri i klasterkave nuk ndryshon — sikurse ishin tridhjetë e nëntë disa vjet më parë, kështu ka mbetur. Por brenda secilës prej tyre ne gradualisht rritim numrin e shard-eve me kalimin e kohës. Dhe skema e shpërndarjes në përgjithësi është e tillë — ndarja në këto klasterka ndodh sipas faqeve të internetit, dhe për të kuptuar se cila faqe është në cilin klaster, përdoret një bazë e veçantë metadath në MySQL. Një faqe është në një klasterkë. Dhe brenda saj, shpërndarja ndodh sipas identifikuesve të vizitorëve.
Gjatë regjistrimit, ne i ndajmë ata sipas mbetjeve nga ndarja e identifikuesit të vizitorit. Por kur shtojmë një shard të ri, skema e shardingut ndryshon, ne vazhdojmë të ndajmë, por sipas mbetjeve nga ndarja me një numër tjetër. Kjo do të thotë se një vizitor tashmë ndodhet në disa servera, dhe kjo nuk mund të merret parasysh. Kjo është bërë ekskluzivisht për të përmirësuar kompresimin e të dhënave. Ndërsa për kërkesat, ne shkojmë në tabelën Distributed, e cila sheh klasterin dhe i drejtohet dhjetëra serverëve. Kjo është skema e çuditshme.
Por tregimi im do të ishte i paplotë nëse nuk do të thosha se ne e braktisëm këtë skemë. Në skemën e re, ne e ndryshuam gjithçka dhe të gjitha të dhënat i kopjuam me ndihmën e clickhouse-copier.
Në skemën e re, të gjitha faqet ndahen në dy kategori - të mëdha dhe të vogla. Nuk e di se si është përzgjedhur pragun, por rezultati është se faqet e mëdha regjistrohen në një klaster, ku ka 120 shard-e me nga tre replika në secilin - që do të thotë 360 servera. Dhe skema e shardingut është e tillë që çdo kërkesë shkon menjëherë në të gjithë shard-et. Nëse tani hapni një faqe raporti për avito.ru në "Yandex.Metrika", kërkesa do të shkojë në 120 servera. Faqet e mëdha në runet janë të pakta. Dhe kërkesat janë jo një mijë në sekondë, por madje më pak se njëqind. Të gjitha këto përpunohen lehtësisht nga tabela Distributed, e cila i trajton ato me 120 servera.
Dhe klasteri i dytë - për faqet e vogla. Këtu skema e shardingut është sipas identifikuesit të faqes, dhe çdo kërkesë shkon në një shard të vetëm.
Në ClickHouse ka një utilitare të quajtur clickhouse-copier. A mund të na flisni për të?
Të them qartë, kjo zgjidhje është më e ndërlikuar dhe disi më pak efektive. Avantazhi është se ajo shpërndan të dhënat plotësisht sipas skemës që do të tregoni. Por disavantazhi i utilitarit është se ajo nuk bën fare rishtim të shardingut. Ajo kopjon të dhënat nga një skemë klasteri në një tjetër skemë klasteri.
Kjo do të thotë se për të funksionuar, duhet të keni dy klasterë. Ato mund të jenë të vendosura në servera të njëjtë, por, megjithatë, të dhënat nuk do të shpërngulen në mënyrë inkrementale, por do të kopjohen.
Për shembull, ishin katër serverë, tani janë tetë. Ju krijoni një tabelë të re Distributed në të gjithë serverët, tabela të reja lokale dhe nisni clickhouse-copier, duke treguar në të skemën e punës, se ai duhet të lexojë nga aty, të pranojë skemën e re të shardimit dhe të transferojë të dhënat atje. Dhe ju në serverët e vjetër do t’ju nevojitet hapësirë një e gjysmë herë më shumë se ç’ka tani, sepse të dhënat e vjetra duhet të qëndrojnë mbi to, dhe për më tepër do të vijë një tjetër gjysmë e këtyre të dhënave të vjetra. Nëse keni menduar paraprakisht se të dhënat duhet të ri-shardohen dhe ka hapësirë, atëherë ky mënyrë do t’ju përshtatet.
Si është ndërtuar brenda clickhouse-copier? Ai e ndan të gjithë punën në një grup detyrash për përpunimin e një partie të një tabele në një shard. Të gjitha këto detyra mund të realizohen paralelisht, dhe clickhouse-copier mund të nisë në makina të ndryshme në disa ekzemplarë, por ajo që bën për një parti - nuk është asgjë tjetër veçse një insert select. Të dhënat lexohen, kompresohen, përshtaten, pastaj sërish kompresohen, regjistrohen diku, ri-sortohen. Kjo është një zgjidhje më e rëndë.
Keni pasur një pilot që quhej reshaping. Çfarë ndodhi me të?
Keni pasur një gjë pilotike që në 2017, e cila quhej resharding. Ka edhe një opsion në ClickHouse. Unë e kuptoj se nuk e arriti suksesin. A mund të flisni për arsyet pse ndodhi kështu? Duket shumë aktuale.
E gjithë problemi qëndron në faktin se kur është e nevojshme të ri-shardohen të dhënat në vend, kërkohet një sinkronizim shumë i komplikuar për ta bërë këtë në mënyrë atomike. Kur filluam të shohim se si funksionon ky sinkronizim, u bë e qartë se ka probleme themelore. Dhe këto probleme themelore nuk janë vetëm teorike, por filluan menjëherë të shfaqen në praktikë siç mund të shpjegohet shumë thjeshtë - asgjë nuk funksionon.
A mund të bashkohen të gjitha pjesët e të dhënave në një para se të kalohen në diskët e ngadalshëm?
Një pyetje për TTL me opsionin move to slow disk në kontekstin e bërrkave. A ka ndonjë mënyrë, përveç përmes cron, për të bashkuar të gjitha pjesët në një para se të zhvendosen në disqet e ngadalta?
Përgjigjja në pyetjen, a mund të bashkohen automatikisht të gjitha copat në një para transferimit të tyre - jo. Më duket se në këtë nuk ka nevojë. Mund të mos bashkohen të gjitha pjesët në një, por thjesht të llogaritet se ato do të transferohen në disqet e ngadalta automatikisht.
Ne kemi dy kritere për rregullat e transferimit. E para është baza e mbushjes. Nëse në nivelin aktual të depozitës ka më pak se një përqindje të caktuar të hapësirës së lirë, ne zgjedhim një pjesë dhe e transferojmë atë në një depozitë më të ngadaltë. Ndoshta jo më të ngadalta, por atë që do të konfiguroni.
Kriteri i dytë është sipërfaqja. Ai trajton transferimin e pjesëve të mëdha. Mund të rregulloni pragun për hapësirën e lirë në diskun e shpejtë dhe të dhënat do të transferohen automatikisht.
Si të kalojmë në versionet e reja të ClickHouse, nëse nuk kemi mundësi të verifikojmë përpara përputhshmërinë?
Ky temë diskutohet rregullisht duke marrë parasysh versionet e ndryshme, dhe megjithatë. Sa të sigurt është të azhurnoni nga versioni 19.11 në 19.16 dhe, për shembull, nga 19.16 në 20.3. Si të kaloni në versionet e reja, pa pasur mundësinë të kontrolloni paraprakisht pajtueshmërinë në një ambient të rërë?
Këtu ka disa rregulla "të arta". E para është . Ai është i gjerë, por aty ka pika specifike për ndryshimet që nuk janë përputhëse. Nuk duhet t'i qaseni këtyre pikave si një flamur i kuq. Zakonisht këto janë mospranueshmëri të vogla, që lidhen me disa funksionalitete kufitare, që është shumë e mundur që nuk i përdorni.
E dyta – nëse nuk keni mundësi të kontrolloni pajtueshmërinë në një ambient të rërë, dhe dëshironi të azhurnoni menjëherë në prodhim, rekomandimi është ky – mos e bëni këtë. Së pari krijoni një ambient të rërë dhe kontrolloni. Nëse nuk keni një ambient provë, atëherë me siguri kompania juaj nuk është shumë e madhe, dhe mund të kopjoni një pjesë të të dhënave në laptopin tuaj dhe të kontrolloni atje nëse gjithçka funksionon siç duhet. Mund të ngrini disa replika lokale në makinën tuaj. Ose mund të ngrini një version të ri diku afër dhe të ngarkoni atje një pjesë të të dhënave – pra, të krijoni një ambient provë të improvizuar.
Një rregull tjetër është – mos azhurnoni në një javë pas daljes së versionit për shkak të kapjes së defekteve në prodhim dhe shpejtë fiksekëve të mëvonshëm. Le të shohim numërimin e versioneve ClickHouse, për të mos u ngatërruar.
Ka kemi versionin 20.3.4. Numri 20 tregon vitin e lëshimit — 2020. Nga këndvështrimi i asaj që ndodhet brenda, kjo nuk ka ndonjë rëndësi, kështu që nuk do t'i kushtojmë vëmendje. Më tej — 20.3. Numri i dytë — në këtë rast 3 — ne e rrisim sa herë që lëshojmë një version të ri me ndonjë funksionalitet të ri. Nëse duam të shtojmë ndonjë mundësi në ClickHouse, jemi të detyruar ta rrisim këtë numër. Pra, në versionin 20.4 ClickHouse do të punojë edhe më mirë. Numri i tretë — 20.3.4. Këtu 4 është numri i versioneve të patch-it, në të cilat nuk kemi shtuar mundësi të reja, por kemi korrigjuar disa gabime. Dhe 4 do të thotë se ne e kemi bërë këtë katër herë.
Nuk duhet të mendoni se kjo është diçka e tmerrshme. Zakonisht përdoruesi mund të instalojë versionin më të fundit, dhe ai do të funksionojë pa ndonjë problem përputhje për një vit. Por imagjinoni, që në ndonjë funksion për përpunimin e bitmap-ëve, i cili u shtua nga shokët tanë kinezë, kur kalohen argumente të gabuara, serveri bie. Ne jemi të detyruar ta rregullojmë këtë. Ne do të lëshojmë një version të ri patch, dhe ClickHouse do të bëhet më i qëndrueshëm.
Nëse ClickHouse juaj funksionon në prodhim, dhe del një version i ri ClickHouse me funksione shtesë — për shembull, 20.4.1 — mos u ngutur ta vendosni atë në prodhim që ditën e parë. Për çfarë është ajo në fakt e nevojshme? Nëse akoma nuk e përdorni ClickHouse, mund ta instaloni dhe, me siguri, gjithçka do të shkojë mirë. Por nëse ClickHouse funksionon stabilisht, atëherë ndiqni patch-ët dhe përditësimet — çfarë probleme ne kemi rregulluar.
Kirill Shvakov: Dëshiroj të shtoj pak rreth mjediseve të testimit. Të gjithë kanë frikë nga mjediset e testimit dhe për një arsye të çuditshme mendojnë se, nëse keni një klaster shumë të madh ClickHouse, atëherë edhe mjedisi i testimit duhet të jetë jo më pak ose të paktën dhjetë herë më i vogël. Kjo nuk është e vërtetë fare.
Mund të flas sipas përvojës time. Kam një projekt dhe atje kam ClickHouse. Mjedisi ynë i testimit për të është një virtual i vogël në Hetzner për dvajzë euro, ku gjithçka është e vendosur. Për ta bërë këtë, ne kemi një automatizim të plotë në Ansible, dhe prandaj në parim nuk ka ndonjë ndryshim se ku shpërndahesh — në serverat fizikë ose thjesht të vendosmë në virtuale.
Çfarë mund të bëhet? Do të ishte mirë të kishte një shembull në dokumentacionin ClickHouse për të vendosur një klaster të vogël në Docker, në LXC, ndoshta të krijohej një Ansible playbook, sepse njerëz të ndryshëm kanë disa deploy të ndryshme. Kjo do ta thjeshtonte shumë. Kur merr dhe vendos një klaster pas pesë minutash, është shumë më e lehtë të kuptosh diçka. Kjo është shumë më praktike, sepse të kalosh në versionin e prodhimit që nuk e ke kontrolluar - është një rrugë e paqartë. Ndonjëherë funksionon, ndonjëherë jo. Prandaj, të shpresosh në sukses - është e keqe.
Maksim Kotyakov, inxhinier i lartë backend në Avito: Pak do të shtoja për ambientet testuese nga seria e problemeve të kompanive të mëdha. Ne kemi një klaster të plotë të kontrollit ClickHouse, sipas skemave të të dhënave dhe konfigurimeve, një kopje të saktë të asaj që është në prodhim. Ky klaster është vendosur në kontejnerë mjaft të thjeshtë me një minimum burimesh. Ne shkruajmë aty një përqindje të caktuar të të dhënave të prodhimit, për fat ka mundësi të replikojmë fluxin në Kafka. Aty të gjitha janë sinchronizuar dhe jashtëzakonisht të paqarta - si në fuqitë, ashtu edhe në flux, dhe, në teori, duke lejuar të gjitha përveç që duhet t'i përmbahen metrikave do të silleshin si prodhim. Çdo gjë e mundshme që do të ishte e rrezikshme fillimisht kalon në këtë skenë dhe qëndron atje për disa ditë deri sa të jetë gati. Por natyrisht, ky zgjidhje është e shtrenjtë, e rëndë dhe me shpenzime jo zero për mbështetje.
Alexey Milovidov: Do të flas për atë se çfarë paraqet ambienti testues të miqve tanë nga 'Yandex.Metrika'. Një klaster kishte mbi 600 serverë, tjetri mbi 360, dhe ka një të tretë dhe disa klasterë të tjerë. Ambienti testues për një nga ata - është thjesht dy sharda me dy replika në secilin. Pse dy sharda? Që të mos jetë vetëm një. Dhe replikat gjithashtu që të ketë. Thjesht një sasi minimale që mund të përballohet.
Ky ambient testues lejon të kontrollohet funksionimi i kërkesave dhe nëse diçka nuk është prishur thelbësisht. Por shpesh problemet ndodhin nga një karakter krejtësisht tjetër, kur gjithçka funksionon, por ka disa ndryshime të vogla me ngarkesën.
Do të jap një shembull. Vendosëm të instalonim versionin e ri të ClickHouse. Ai është nxjerrë në ambientin testues, janë kaluar testet automatizime në vetë 'Yandex.Metrika', të cilat krahasojnë të dhënat në versionin e vjetër dhe në atë të ri, duke kaluar të gjithë linjën e prodhimit. Dhe sigurisht, testet e gjelbra të CI tonë. Përndryshe, ne as nuk do ta kishim propozur këtë version.
Gjithçka është në rregull. Fillojmë të kalojmë në prodhim. Më vjen një mesazh që ngarkesa në grafikë është rritur disa herë. Ne kthejmë versionin. Shikoj në grafik dhe shoh: ngarkesa me të vërtetë është rritur disa herë gjatë nxjerrjes, dhe ka rënë përsëri, kur e nxorrëm. Pastaj filluam të kthejmë versionin. Dhe ngarkesa poashtu shkoi dhe u ul po ashtu. Pra, përfundimi është se ngarkesa u rrit për shkak të nxjerrjes, nuk është diçka befasuese.
Më pas ishte e vështirë të bindësh kolegët të vendosin versionin e ri. Unë thashë: «Gjithçka është në rregull, nxirrni. Mbani gishta të mbledhur, gjithçka do të funksionojë. Tani ngarkesa është rritur në grafikë, por gjithçka është në rregull. Qëndroni fort». Në përgjithësi, ne e bëmë kështu, dhe të gjitha — versioni është nxjerrë në prodhim. Por pothuajse në çdo nxjerrje ndodhin probleme të ngjashme.
Kill query duhet të vrasë запросы, por ai nuk e bën këtë. Pse?
Një përdorues, një lloj analisti, erdhi tek unë dhe krijoi një kërkesë që e përjashtoi klustërin tim të ClickHouse. Një node ose gjithsej klustërin — në varësi të asaj se në cilën replikë ose shard kërkesa shkoi. Unë shoh se të gjitha burimet nga CPU në këtë server janë në borde, gjithçka është e kuqe. Ndërkohë, vetë ClickHouse i përgjigjet kërkesave. Dhe unë shkruaj: «Të lutem, trego më listën e proceseve, cila kërkesë e prodhoi këtë marrzi».
Gjej këtë kërkesë dhe i them kill. Dhe shoh se nuk ndodh asgjë. Serveri im është në bord, ClickHouse më jep disa komanda dhe tregon se serveri është aktiv, dhe gjithçka është në rregull. Por kam degradim në të gjitha kërkesat e përdoruesve, fillon degradimi në shkrimin në ClickHouse, dhe mekeli im kill query nuk funksionon. Pse? Mendova se kill query duhet të vrasë kërkesat, por kjo nuk ndodh.
Tani do të jetë një përgjigje mjaft e çuditshme. Çështja është se kill query nuk vret kërkesat.
Kill query vendos një flamur të vogël me emrin «dua që kjo kërkesë të vritet». Dhe e gjithë kërkesa, gjatë përpunimit të çdo blloku, shikon këtë flamur. Nëse ai është vendosur, kërkesa ndalon punën. Pra, rezulton se askush nuk e vret kërkesën, ajo duhet vetë të kontrollojë gjithçka dhe të ndalojë. Dhe kjo duhet të funksionojë në të gjitha rastet, kur kërkesa është në gjendje përpunimi të blloqeve të dhënash. Ajo do të përpunojë bllokun e ardhshëm të dhënash, do të kontrollojë flamurin dhe do të ndalojë.
Kjo nuk funksionon në rastet kur kërkesa është bllokuar për ndonjë operacion. Në fakt, me sa duket, kjo nuk është rasti juaj, sepse sipas fjalëve tuaja, ai po përdor shumë burime të serverit. Mund të ndodhë që kjo mos të funksionojë në rastin e ndarjes së jashtme dhe në disa detaje të tjera. Por, në përgjithësi, kjo nuk duhet të ndodhë, kjo është një gabim. Dhe e vetmja gjë që mund të rekomandoj është të përditësoni ClickHouse.
Si të llogaritet koha e përgjigjes nën ngarkesë lexuese?
Ekziston një tavolinë ku ruhet agregatet sipas item - numra të ndryshëm. Numri i rreshtave është afërsisht njëqind milion. A mund të presim një kohë përgjigjeje të parashikueshme nëse përfundon 1K RPS për 1K item?
Duke parë kontekstin, është fjala për ngarkesë lexuese, sepse për shkrimin nuk ka ndonjë problem - mund të futni nga një mijë, nga njëqind mijë, madje edhe disa miliona rreshta.
Kërkesat lexuese janë shumë të ndryshme. Në select 1, ClickHouse mund të kryejë rreth dhjetë mijë kërkesa në sekondë, prandaj edhe kërkesat për një çelës kërkojnë disa burime. Dhe këto kërkesa të përpikta do të jenë më të komplikuara se në ndonjë bazë të dhënash key-value, sepse për çdo lexim është e nevojshme të lexoni një bllok të dhënash sipas indeksit. Indeksi ynë adreson jo çdo regjistër, por çdo interval. Kështu që do të jetë e nevojshme të lexoni të gjithë intervalin - kjo është 8192 rreshta siç është e paracaktuar. Dhe do të jetë e nevojshme të çkompresoni një bllok të dhënash të kompresuar nga 64 Kb në 1 Mb. Zakonisht, këto kërkesa të përpikta zgjatin nga disa milisekonda. Por ky është varianti më i thjeshtë.
Le të provojmë të bëjmë një aritmetikë të thjeshtë. Nëse shumëzojmë disa milisekonda me një mijë, rezultati është disa sekonda. Mësohet si të mbash një mijë kërkesa në sekondë, por në të vërtetë është e mundur, sepse kemi disa bërthama procesori. Kështu që, në parim, ClickHouse mund të mbajë ndonjëherë 1000 RPS, por për kërkesa të shkurtra, pikërisht ato të sakta.
Nëse duhet të skaloni klasterin ClickHouse për numrin e kërkesave të thjeshta, unë rekomandoj më të thjeshtën - të rrisni numrin e kopjeve dhe t'i dërgoni kërkesat në një kopje të rastësishme. Nëse një kopje e juaja mban pesëqind kërkesa në sekondë, që është plotësisht e mundur, atëherë tre kopje do të mbajnë një mijë e pesëqind.
Ndonjëherë, natyrisht, mund të konfigurohet ClickHouse për të arritur numrin maksimal të leximeve pikore. Çfarë është e nevojshme për këtë? E para - të reduktohet granulariteti i indeksit. Ky granularitet nuk duhet ulur deri në njësi, por në përllogaritje që numri i regjistrimeve në index do të jetë disa milion ose dhjetëra miliona në server. Nëse në tabelë ka njëqind milion rreshta, atëherë si granularitet mund të vendosni 64.
Mund të zvogëloni madhësinë e bllokut të kompresuar. Për këtë ka disa cilësime min compress block size, max compress block size. Ato mund të ulën, të ri-ndahen të dhënat dhe atëherë kërkesat pikore do të jenë më të shpejta. Por prapëseprapë, ClickHouse nuk është një bazë të dhënash key-value. Një numër i madh kërkesash të vogla është një anti-model ngarkese.
Kirill Shvakov: Do të jap një këshillë për rastin nëse aty ka llogari të zakonshme. Kjo është një situatë mjaft standarde, kur në ClickHouse mbahet një numër. Kam një përdorues, ai vjen nga një vend i caktuar, plus një fushë tjetër dhe duhet të rrisim diçka inkrementalisht. Merrni MySQL, bëni një çelës unik - në MySQL ai është çelës i dyfishtë, ndërsa në PostgreSQL ai është konflikt - dhe shtoni me plus. Kjo do të funksionojë shumë më mirë.
Kur keni pak të dhëna, nuk ka ndonjë kuptim të përdorni ClickHouse veçanërisht. Ka baza të dhënash të zakonshme dhe ato e menaxhojnë këtë mirë.
Çfarë të përmirësoni në ClickHouse, për të pasur më shumë të dhëna në cache?
Le të imagjinojmë një situatë - në servera ka 256 GB RAM, në rutinën e përditshme ClickHouse merr rreth 60-80 GB, në pikë - deri në 130. Çfarë mund të aktivizoni dhe përmirësoni, për të pasur më shumë të dhëna në cache dhe, për rrjedhojë, më pak kërkesa në disk?
Si rregull, cache-i i faqes së sistemit operativ e menaxhon mirë këtë detyrë. Nëse hapni thjesht një top, shihni atje cached ose free - gjithashtu është shkruar se sa është cache-uar - mund të vëreni se gjithë fondi i lirë është përdorur për cache. Dhe këto të dhëna gjatë leximit do të lexohen jo nga disku, por nga memoria operative. Duke mos harruar se mund të them se cache-i po përdoret në mënyrë efektive, sepse janë cache-uar të dhënat e kompresuara.
Megjithatë, nëse dëshironi të përshpejtoni disa kërkesa të thjeshta edhe më shumë, ka mundësi të aktivizoni brenda ClickHouse cache-in në të dhëna të pa kompresuara. Kjo quhet uncompressed cache. Në skedarin e konfigurimit config.xml, vendosni madhësinë e caches të pa kompresuar në vlerën e dëshiruar — unë sugjeroj të mos jetë më shumë se gjysma e memorjes RAM të lirë, sepse pjesa tjetër do të shkojë për cache të faqes.
Për më tepër, ka dy konfigurime në nivelin e kërkesës. Konfigurimi i parë — përdor cache të pa kompresuar — aktivizon përdorimin e tij. Rekomandohet të aktivizohet për të gjitha kërkesat, përveç atyre të rënda, të cilat mund të lexojnë të dhënat e gjitha dhe ta zbrazin këtë cache. Dhe konfigurimi i dytë — është diçka si numri maksimal i rreshtave për përdorimin e caches. Kjo automatikisht kufizon kërkesat e mëdha, në mënyrë që ato të kalojnë jashtë caches.
Si mund të konfigurojmë storage_configuration për ruajtjen në memorie?
Në dokumentacionin e ri të ClickHouse, kam lexuar një seksion lidhur . Në përshkrim ka një shembull me SSD të shpejtë.
Është interesante si mund të konfigurohet e njëjta gjë me memorie të nxehtë në volum. Dhe një pyetje tjetër. Si funksionon select me një organizim të tillë të të dhënave, a do të lexojë të gjithë setin apo vetëm atë që ndodhet në disk, dhe a kompresohen këto të dhëna në memorie? Dhe si funksionon seksioni prewhere në një organizim të tillë të të dhënave?
Ky konfigurim ndikon në ruajtjen e copave të të dhënave, dhe formati i tyre nuk ndryshon në asnjë mënyrë.
Le të shqyrtojmë më hollësisht.
Mund të konfigurohet ruajtja e të dhënave në RAM. Çdo gjë që konfiguroni për disk — është rruga e tij. Krijoni një ndarje tmpfs, e cila është e montuar në një rrugë të caktuar në sistemin e skedarëve. Shpjegojeni këtë rrugë si një rrugë për ruajtjen e të dhënave për ndarjen më të nxehtë, aty fillojnë të bien dhe të regjistrohen copat e të dhënave, gjithçka është mirë.
Por unë nuk rekomandoj ta bëni këtë për shkak të besueshmërisë së ulët, megjithatë, nëse keni të paktën tre replika në qendra të ndryshme të të dhënave, atëherë është e pranueshme. Në rast se ndodhemi, të dhënat do të rifitohet. Imagjinoni se serveri ndalon papritur dhe kthehet përsëri. Ndarja është montuar sërish, por atje është boshllëk. Serveri ClickHouse gjatë aktivizimit sheh se këto copa mungojnë, megjithëse, sipas metadata-ve të ZooKeeper ato duhet të jenë. Ai kontrollon në cilat replika janë, i kërkon ato dhe i shkarkon. Kështu të dhënat do të rifitohet.
Në këtë kuptim, ruajtja e të dhënave në RAM nuk ndryshon thelbësisht nga ruajtja e tyre në disk, sepse kur të dhënat shkruhen në disk, ato gjithashtu kalojnë fillimisht në page cache dhe regjistrohen fizikisht në mënyrë të vonuar. Kjo varet nga mënyra e montimit të sistemit të skedarëve. Megjithatë, për çdo rast do të them se ClickHouse nuk bën fsync gjatë insert.
Të dhënat në RAM ruhen në të njëjtin format si në disk. Kërkesa select gjithashtu zgjedh copa që duhet të lexohen, zgjedh diapazonet e nevojshme të të dhënave në copa dhe i lexon ato. Dhe prewhere funksionon në mënyrë të njëjtë, pavarësisht nëse të dhënat ishin në RAM apo në disk.
Derisa deri në sa vlera unike është efektive Low Cardinality?
Low Cardinality është i dizajnuar në mënyrë të zgjuar. Ai krijon fjalorë të të dhënave, por ata janë lokalë. Së pari, fjalorët janë të vetëdijshëm për secilën copë, së dyti, madje brenda një cope ata mund të jenë të ndryshëm për çdo diapazon. Kur numri i vlerave unike arrin një numër prag – mendimin tim, një milion – fjalori thjesht hiqet, dhe krijohet një i ri.
Përgjigjja në përgjithësi: për çdo diapazon lokal — le të themi, për çdo ditë — diku deri në një milion vlera unike, Low Cardinality është efektiv. Pas kësaj, do të ketë një fallback, ku do të përdoren shumë fjalorë të ndryshëm, jo një i vetëm. Do të funksionojë në mënyrë të ngjashme me një kolonë normale të tipit string, ndoshta pak më pak efektiv, por nuk do të ketë një degradim të dukshëm të performancës.
Cilat janë praktikat më të mira për kërkimin e plotë të teksteve në një tabelë me pesë miliardë rreshta?
Ka disa varianta përgjigjeje. E para – të thuash se ClickHouse nuk është një sistem për kërkimin me tekst të plotë. Për këtë ka sisteme speciale, për shembull, dhe . Megjithatë, unë po takohem gjithnjë e më shpesh me njerëz që thonë se po kalojnë nga Elasticsearch në ClickHouse.
Pse ndodh kjo? Ata e shpjegojnë këtë me faktin se Elasticsearch ndalon së funksionuari me ngarkesat e caktuara, duke filluar me ndërtimin e indekseve. Indekset bëhen shumë të ngarkuara dhe, nëse thjesht transferoni të dhënat në ClickHouse, do të rezultojë se ato ruhen shumë më efektivisht në volum. Për më tepër, kërkesat për kërkim shpesh nuk ishin të tilla që të nevojitej të gjendej një frazë në të gjithë volumet e të dhënave duke marrë parasysh morfologjinë, por krejtësisht të ndryshme. Për shembull, të gjeni në logs për disa nënsekuenca bajtësh në orët e fundit.
Në këtë rast, krijoni një indeks në ClickHouse, i cili do të ketë datën me kohën si fushën e parë. Dhe filtri më i madh i të dhënave do të jetë pikërisht në bazë të intervalit të datave. Brenda intervalit të përzgjedhur të datave, zakonisht është e mundur të realizoni kërkim me tekst të plotë, madje duke përdorur metodën brute-force me ndihmën e like. Operaori like në ClickHouse është operatori më efektiv like që mund të gjeni. Nëse gjeni një më të mirë - më tregoni.
Por prapë like është një skanim i plotë. Dhe skanimi i plotë mund të jetë i ngadalshëm jo vetëm për CPU, por edhe për diskun. Nëse ndodheni me një terabajt të dhënash në ditë, dhe për një ditë kërkoni një fjalë, do të duhet të skanoni një terabajt. Dhe ai sigurisht është në disqe të zakonshme, dhe përfundimisht ato do të ngarkohen aq shumë sa nuk do të mund të hyni në këtë server përmes SSH.
Në këtë rast, jam i gatshëm të propozoj një tjetër truk të vogël. Ai është nga kategoria eksperimentale - ndoshta do të funksionojë, ndoshta jo. Në ClickHouse ka indekse për kërkimin me tekst të plotë në formën e filtrave Bloom me trigram. Kolegtë tanë nga kompania Arenadata e kanë provuar këtë indeks, dhe shpesh herë ato funksionojnë ashtu siç janë menduar.
Për të përdorur ato siç duhet, është e nevojshme të kuptoni mirë se si funksionojnë: çfarë përbën një filtër Bloom me trigram dhe si të zgjidhni madhësinë e tij. Mund të them se ata do të ndihmojnë për kërkesat që lidhen me fraza të rralla, nënshkrime që shpeshherë nuk shfaqen në të dhëna. Në këtë rast, sipas indekseve do të zgjidhen nënintervale dhe do të lexohen më pak të dhëna.
Së fundmi, në ClickHouse u shfaqën edhe funksione më të avancuara për kërkimin me tekst të plotë. Kjo, së pari, është kërkimi i menjëhershëm i një numri të madh të nënshkrimeve në një kalim, përfshirë opsionet për llogaritjen e regjistrit, pa llogaritjen e regjistrit, me mbështetje për UTF-8 ose vetëm për ASCII. Zgjidhni atë që është më efektive për ju.
Dhe gjithashtu u shfaq kërkimi i disa shprehjeve të rregullta në një kalim. Ju nuk keni nevojë të shkruani X like një nënshkrim ose X like një tjetër nënshkrim. Thjesht shkruani menjëherë, dhe gjithçka realizohet maksimalisht efikas.
E treta - tani ka kërkim të afërt për regex dhe kërkim të afërt për nënshkrime. Nëse dikush ka shkruar një fjalë me gabim, ajo do të kërkohet për përputhjen maksimale.
Si mund ta organizojmë më mirë aksesin në ClickHouse për një numër të madh përdoruesish?
Tregoni se si si duhet të organizoni qasjen për një numër të madh konsumatorësh dhe analistësh. Si të formoni një radhë, të prioritizoni kërkesat max concurrent queries, dhe cilat mjete të përdorni?
Nëse klasteri është mjaft i madh, një zgjidhje e mirë është të ngrihen edhe dy serverë të tjerë, të cilët do të funksionojnë si pika hyrëse për analistët. Pra, mos i lejoni analistët të hyjnë në shard-at e caktuar të klasterit, por thjesht krijoni dy serverë të zbrazët, pa të dhëna, dhe në to konfiguroni të drejtat e aksesit. Po ashtu, konfigurimet e përdoruesve gjatë kërkesave të shpërndara dërgohen në serverët e largët. Kështu që ju konfiguroni gjithçka në këta dy serverë, dhe këto konfigurime kanë efekt në të gjithë klasterin.
Në parim, këta serverë janë pa të dhëna, por volumi i RAM-it në to është shumë i rëndësishëm për ekzekutimin e kërkesave. Disku gjithashtu mund të përdoret për të dhëna të përkohshme, nëse është aktivizuar agregimi i jashtëm ose renditja e jashtme.
Është e rëndësishme të shqyrtohet konfigurimi që lidhet me të gjitha limitet e mundshme. Nëse tani hyj në klasterin "Yandex.Metrika" si analist dhe bëj një kërkesë select count from hits, menjëherë do të më jepet një përjashtim, që nuk mund ta realizoj kërkesën. Numri maksimal i rreshtave që më lejohet të skanoj është hapësira e njëqind miliardësh, ndërsa përgjithësisht në klaster ka pesëdhjetë trilion rreshta në një tabelë. Ky është kufiri i parë.
Supozoni se e heq kufirin për numrin e rreshtave dhe e realizoj kërkesën përsëri. Atëherë do të shoh këtë përjashtim — është aktivizuar konfigurimi force index by date. Nuk e realizoj dot kërkesën, nëse nuk kam përcaktuar një interval datash. Mos u mbështetni në faktin se analistët do ta përcaktojnë atë manualisht. Një rast tipik është: është shkruar një interval datash ku data e ngjarjes është midis javës. Dhe pastaj thjesht është bërë një gabim me hapësirat, dhe në vend të and është marrë or — or URL match. Nëse nuk ka kufizim, do të fillojë të skanojë kolonën e URL-ve dhe do të humbasë thjesht një ton burimesh.
Për më tepër, në ClickHouse ka dy konfigurime për prioritete. Fatkeqësisht, ato janë shumë primitive. Njëra e thërret thjesht priority. Nëse prioriteti ≠ 0, dhe kërkesat me ndonjë prioritet ekzekutohen, por në të njëjtën kohë ekzekutohet një kërkesë me një prioritet më të ulët, që do të thotë prioritet më të lartë, atëherë kërkesa me një vlerë prioriteti më të lartë, që do të thotë prioritet më të ulët, thjesht do të pezullohet dhe nuk do të punojë fare gjatë kësaj kohe.
Kjo është një konfigurim shumë i rëndë dhe nuk është e përshtatshme për ato raste kur klasteri ka një ngarkesë të vazhdueshme. Por nëse keni kërkesa të shkurtra dhe impulsive që janë të rëndësishme, ndërsa kryesisht klasteri është në gjendje të qetë, një konfigurim i tillë do të funksionojë.
Konfigurimi i ardhshëm i prioriteteve quhet prioriteti i thread-ave OS. Ai thjesht vendos për të gjitha thread-at që ekzekutojnë kërkesën një vlerë nice për planifikuesin Linux. Funksionon më shumë ose më pak, por gjithsesi funksionon. Nëse vendosni vlerën më të ulët të mundshme nice - ajo është më e madhe në madhësi, dhe do të thotë prioritet më i ulët - dhe për kërkesat me prioritet të lartë vendosni -19, atëherë CPU do të konsumojë kërkesat me prioritet të ulët afërsisht katër herë më pak se ato me prioritet të lartë.
Gjithashtu është e nevojshme të konfiguroni kohën maksimale të ekzekutimit të kërkesës - le të themi pesë minuta. Shpejtësia minimale e ekzekutimit të kërkesës - kjo është më e shkëlqyera. Ky konfigurim ekziston prej kohësh dhe është i nevojshëm për të mos e bërë thjesht të pranueshme që ClickHouse nuk ngec, por për ta forcuar këtë.
Imagjinoni, jeni duke konfiguruar: nëse një kërkesë proceson më pak se një milion rreshta në sekondë - kjo nuk lejohet. Kjo turpëron emrin tonë të mirë, bazën tonë të mirë të dhënash. Le të thjesht e ndalim këtë. Në të vërtetë, ka dy konfigurime. Njëra quhet shpejtësia minimale e ekzekutimit — në rreshta në sekondë, dhe tjetra quhet "timeout para kontrollit të shpejtësisë minimale të ekzekutimit" - si parazgjedhje pesëmbëdhjetë sekonda. Pra, pesëmbëdhjetë sekonda janë të pranueshme, dhe pastaj, nëse është ngadalë, thjesht hidhet një përjashtim - ndalohet kërkesa.
Gjithashtu është e nevojshme të konfigurohen kuotat. Në ClickHouse ka një mundësi të ndërtuar për kuota, e cila llogarit konsumimin e burimeve. Por, me keqardhje, jo burimeve fizike si CPU, disqe, por logjike - numri i kërkesave të procesuar, rreshtave dhe byte-ve të lexuara. Dhe mund të konfiguroni, për shembull, maksimumin e njëqind kërkesave në pesë minuta dhe një mijë kërkesa në orë.
Pse është e rëndësishme? Sepse një pjesë e kërkesave të analizës do të ekzekutohen manualisht nga klienti ClickHouse. Dhe gjithçka do të shkojë mirë. Por nëse keni analistë të avancuar në kompaninë tuaj, ata do të shkruajnë një skenar, dhe në skenar mund të ketë një gabim. Ky gabim do të përfundojë në ekzekutimin e kërkesës në një cikël të pafund. Kështu duhet të mbrohemi nga kjo.
A mund të jepen rezultatet e një kërkese në dhjetë klientë?
Ne kemi disa përdorues që u pëlqen të vijnë me kërkesa shumë të mëdha në të njëjtën kohë. Kërkesa është e madhe, ekzekutohet në parim shpejt, por për shkak se ka shumë kërkesa në të njëjtën kohë, bëhet shumë e dhimbshme. A është e mundur të ekzekutohet e njëjta kërkesë që erdhi dhjetë herë radhazi vetëm një herë dhe rezultati t'i jepet dhjetë klientëve?
Problemi është se ne nuk kemi rezultate të cache-it ose të dhënave të ndërmjetme. Ka një cache për faqen nga sistemi operativ, i cili lejon që të dhënat të mos lexohen përsëri nga disku, por, fatkeqësisht, të dhënat megjithatë do të deshifrohen, do të deserializohen dhe do të përpunohen përsëri.
Do të doja në ndonjë mënyrë ta shmang këtë, qoftë duke ruajtur të dhënat e ndërmjetme, ose duke ndërtuar kërkesa të ngjashme në një rend dhe duke shtuar cache të rezultateve. Aktualisht kemi një pull request që është në zhvillim, i cili shton cache për kërkesat, por vetëm për nënkërkesat në seksionin in dhe join - që do të thotë se zgjidhja nuk është plotësisht e plotë.
Megjithatë, na ndodh gjithashtu një situatë e tillë. Sidomos shembulli kanonik është kërkesat me pagination. Ka një raport, në të ka disa faqe, dhe ka një kërkesë limit 10. Më pas e njëjta gjë, por limit 10,10. Pastaj vjen një faqe tjetër. Dhe pyetet, pse ne e llogarisim këtë të gjithin çdo herë? Por tani nuk ka zgjidhje, dhe nuk mund ta shmangim këtë.
Ka një zgjidhje alternative, e cila vendoset si një sidecar pranë ClickHouse - .
Kirill Shvakov: Në ClickHouse Proxy ka një limiter të integruar të normës dhe një cache të integruar të rezultateve. Ka shumë konfigurime të bëra, sepse problema e ngjashme u zgjidh. Proxy lejon të kufizohen kërkesat, duke i radhitur ato në një rend dhe duke vendosur se sa kohë e jeton cache i kërkesave. Nëse kërkesat ishin vërtet të njëjta, Proxy do t'i dorëzojë ato shumë herë, ndërsa do të shkojë në ClickHouse vetëm një herë.
Në Nginx gjithashtu ka një cache në versionin falas, dhe kjo do të funksionojë gjithashtu. Nginx ka edhe parametra, që, nëse kërkesat vijnë njëkohësisht, ai do të ngadalësojë të tjerat derisa njëra të ekzekutohet. Por në ClickHouse Proxy, konfigurimi është bërë shumë më mirë. Është zhvilluar saktësisht për ClickHouse, për këto kërkesa, prandaj i përshtatet më shumë. Po ashtu, instalohet lehtësisht.
Çfarë të bëjmë me operacionet asinkrone dhe pamjet materializuese?
Ekziston një problem i tillë, që operacionet me motorin e ri asinkron janë asinkrone - së pari regjistrohen të dhënat, pastaj ndodhin kompresimi i tyre. Nëse nën tabelën jeton një tabelë e materializuar me disa agregate, atëherë dyfishimet do të regjistrohen në të. Dhe nëse nuk ka ndonjë logjikë të komplikuar, të dhënat do të dyfishohen. Çfarë mund të bëjmë për këtë?
Ka një zgjidhje të qartë - të implementosh një trigger për një klasë të caktuar materializimi gjatë operacionit asinkron të kompresimit. A ka ndonjë "mollë argjendi", plane për implementimin e funksionaliteteve të tilla?
Është e nevojshme të kuptohet si funksionon deduplikimi. Ajo që do të flas tani nuk ka lidhje me pyetjen, por për çdo rast, vlen të mbahet mend.
Gjatë regjistrimit në një tabelë të replikuar, ka deduplikim të blloqeve të regjistruara tërësisht. Nëse regjistroni sërish të njëjtin bllok, që përmban të njëjtin numër rreshtash në të njëjtin rend, të dhënat do të deduplikohen. Do të merrni "Ok" si përgjigje për insert, por në fakt do të regjistrohet një paketë të dhënash dhe ajo nuk do të dyfishohet.
Kjo është e nevojshme për saktësinë. Nëse gjatë regjistrimit morët "Ok", atëherë të dhënat tuaja janë regjistruar. Nëse morët një gabim nga ClickHouse, atëherë ato nuk janë regjistruar, dhe duhet ta përsërisni regjistrimin. Por nëse gjatë regjistrimit u prish lidhja, atëherë nuk e dini nëse të dhënat janë regjistruar ose jo. Një mundësi e vetme është të përsërisni regjistrimin sërish. Nëse të dhënat me të vërtetë ishin regjistruar, dhe ju i regjistruat sërish, ekziston deduplikimi i blloqeve. Kjo është e nevojshme për të shmangur dyfishimet.
Dhe është e rëndësishme gjithashtu, si funksionon ajo për pamjet e materializuara. Nëse të dhënat janë deduplikuar gjatë regjistrimit në tabelën kryesore, atëherë ato nuk do të kalojnë as në pamjen e materializuar.
Tani përsa i përket pyetjes. Keni një situatë më të komplikuar, sepse po regjistroni dublika të rreshtave të veçantë. Pra, nuk është një paketë e tërë që është e dyfishuar, por saktësisht rreshtat konkretë, dhe ato përfshihen në sfond. Në të vërtetë, të dhënat do të përfshihen në tabelën kryesore, ndërsa në pamjen e materializuar do të shkojnë ato që nuk janë përfshirë, dhe gjatë bashkimeve nuk do të ndodhin ndryshime me pamjet e materializuara. Sepse pamja e materializuar nuk është asgjë tjetër veçse një nxitës për insert. Gjatë operacioneve të tjera, nuk ndodhin asnjë veprim shtesë me të.
Dhe këtu nuk mund të kënaqem fare. Duhet vetëm të kërkoni një zgjidhje të veçantë për këtë rast. Për shembull, a mund të bëjmë një zëvendësim në pamjen e materializuar, dhe ndoshta mënyra e deduplikimit do të funksionojë kështu. Por, fatkeqësisht, jo gjithmonë. Nëse është agreguese, atëherë nuk do të jetë e mundur.
Kirill Shvakov: Edhe ne kemi pasur konstrukte të ngjashme në kohën tonë. Kishte një problem, që ka shfaqje reklame dhe ka disa të dhëna që mund t'i tregojmë në kohë reale - këto janë thjesht shfaqje. Ato rrallë dublikohen, por, nëse ndodh një gjë e tillë, ne gjithsesi do t'i përfshijmë më vonë. Kishte edhe gjëra që nuk mund të dublikohen - klikimet dhe gjithë ajo histori. Por gjithashtu do të donim t'i shfaqnim ato gati menjëherë.
Si u bënë pamjet e materializuara? Kishin pamje, ku shkruhej direkt - shkon regjistrimi në të dhëna të papërpunuara dhe shkruhej në pamje. Aty në një moment të caktuar të dhënat nuk ishin shumë të sakta, ato dublikoheshin etj. Dhe ka një pjesë të dytë të tabelës, ku ato duken krejtësisht ashtu si pamjet e materializuara, domethënë, në strukturë ato janë krejtësisht të njëjta. Një herë pas një kohe, ne rregullojmë të dhënat, numërojmë të dhënat pa dublika dhe i shkruajmë në ato tabela.
Ne kaluam përmes API - në ClickHouse nuk do të funksionojë manualisht. Dhe API shikon: kur kam datën e fundit të shtimit në tabelë, ku të dhënat janë garantuar që janë të sakta, të llogaritura, dhe ai bën një kërkesë në një tabelë dhe në një tjetër tabelë. Nga njëra tabelë merr deri në një sasi të caktuar kohe, dhe nga tjetra merr atë që ende nuk është llogaritur. Dhe kjo funksionon, por jo me mjetet e vetëm ClickHouse.
Nëse keni ndonjë API – për analistët, për përdoruesit – atëherë, në parim, ky është një opsion. Ju gjithmonë bëni numërimin, gjithmonë rikalkuloni. Këtë mund ta bëni një herë në ditë ose në ndonjë kohë tjetër. Ju vetë zgjidhni intervalin që nuk ju nevojitet dhe nuk është kritik.
Në ClickHouse ka shumë regjistra. Si mund të shoh gjithçka që ndodh me serverin në momentin aktual?
Në ClickHouse ka një numër shumë të madh logesh të ndryshme dhe ky numër po rritet. Në versionet e reja, disa prej tyre madje janë të aktivizuara si parazgjedhje, ndërsa në versionet e vjetra duhet t’i aktivizoni gjatë përditësimit. Megjithatë, po bëhen gjithnjë e më shumë. Do të doja të shihja në fund se çfarë po ndodh aktualisht me serverin tim, ndoshta në ndonjë tabelë përmbledhëse.
A keni ndonjë ekip në ClickHouse, ose në ekipet e miqve tuaj, që ofron ndonjë funksionalitet të dashboard-eve të gatshme, të cilat do t’i shfaqin këto loge si një produkt të gatshëm? Në fund të fundit, të shohësh loget në ClickHouse është e shkëlqyer. Por do të ishte shumë e mrekullueshme nëse do të ishte tashmë në formë të një dashboard-i të përgatitur. Do ta isha shumë i kënaqur nga kjo.
Ka dashboard-e, por ato nuk janë standardizuar. Në kompaninë tonë, diku rreth 60 ekipe përdorin ClickHouse, dhe e çuditshme është se shumë prej tyre kanë dashboard-e që vetë i kanë bërë, dhe pak më ndryshe. Disa ekipe përdorin një instalim të brendshëm të 'Yandex.Cloud'. Ka disa raporte të gatshme atje, megjithatë jo të gjitha të nevojshmet. Të tjerët kanë të tyret.
Kolegët e mi nga 'Metrix' kanë dashboard-in e tyre në Grafana, ndërsa unë kam të mien për klasterin e tyre. Atje shoh gjëra si numrin e hit-eve për cache. Dhe edhe më e komplikuar është se ne përdorim mjete të ndryshme. Dashboard-in tim e krijova në një mjet shumë të vjetër, që quhet Graphite-web. Ai është krejtësisht i shëmtuar. Dhe unë akoma e përdor atë, përkundër faktit që Grafana do të ishte ndoshta më e përshtatshme dhe më e bukur.
Elementi bazë në dashboard janë të njëjta. Këto janë metrikat sistemike për klasterin: CPU, memorie, disk, rrjet. Të tjerat janë numri i kërkesave të njëkohshme, numri i bashkimeve të njëkohshme, numri i kërkesave për sekondë, numri maksimal i copëzave për partitë e tabelave MergeTree, vonesa e replikimit, madhësia e kërkesës për replikim, numri i rreshtave të futur për sekondë, numri i blloqeve të futur për sekondë. Këto janë të gjitha që marrim jo nga log-et, por nga metrikat.
Vladimir Kolobaev: Alexei, do të doja të bëja disa rregullime. Ka Grafana. Grafana ka një burim të dhënash, që është ClickHouse. Kështu që unë mund ta bëj kërkesën direkt në ClickHouse nga Grafana. Në ClickHouse ka një tabelë me log-et, e cila është e njëjtë për të gjithë. Dua që rezultati në Grafana të referohet në këtë tabelë log-esh dhe të shoh kërkesat që serveri im i bën. Do të ishte e shkëlqyer të kisha një dashboard të tillë.
E kam bërë vetë. Por më lind një pyetje – nëse gjithçka është standardizuar dhe Grafana përdoret nga të gjithë, pse nuk ka një dashboard zyrtar në 'Yandex'?
Kirill Shvakov: Në të vërtetë, burimi i të dhënave që është për ClickHouse tani mbështetet nga Altinity. Dhe thjesht dua të jap një drejtim se ku të kërkoj dhe kujt t'i dërgoj. Mund të pyesim ata, sepse 'Yandex' në fund të fundit e bën ClickHouse dhe jo historinë rreth tij. Altinity është kompania kryesore që tani promovon ClickHouse. Ata nuk do ta braktisin, por do ta mbështesin. Sepse në të vërtetë, për të ngarkuar një dashboard në faqen e Grafana-s, duhet thjesht të regjistrohesh dhe ta ngarkosh – nuk ka ndonjë problem të veçantë.
Alexey Milovidov: Gjatë vitit të fundit, në ClickHouse janë shtuar shumë mundësi për profilimin e kërkesave. Ka metrika për çdo kërkesë për përdorimin e burimeve. Dhe shumë kohë më parë u shtua edhe një profiler më i ulët për kërkesat, për të parë se ku kalon çdo milisekondë kërkesa. Por për të shfrytëzuar këtë funksionalitet, jam i detyruar të hap klientin e konsolës dhe të shkruaj kërkesën që vazhdimisht e harroj. E kam ruajtur diku dhe vazhdimisht harroj ku saktësisht.
Do doja me një mjet ku thjesht është shkruar - këtu janë kërkesat tuaja të rënda, të grumbulluara sipas klasave. Klikova në ndonjë dhe do më thonin se është e rëndë për këtë arsye. Tani nuk ka një zgjidhje të tillë. Në të vërtetë është mjaft e çuditshme që kur njerëzit më pyesin: "Më thoni, ka ndonjë dashboard të gatshëm për Grafana?", unë them: "Shkoni në faqen e Grafana, atje ka një komunitet 'Dashboard', dhe aty ka një dashboard nga Dima, një dashboard nga Kostja. Çfarë është kjo, nuk e di, unë vetë nuk e kam përdorur."
Si të ndikoj në merge që serveri të mos bjerë në OOM?
Kam një tabelë, në tabelë ka vetëm një particion, është ReplacingMergeTree. Unë shkruaj të dhëna në të për katër vjet. Më duhej të bëja një alter dhe të fshija disa të dhëna.
E bëra këtë, dhe gjatë përpunimit të këtij kërkese u konsumua gjith memorja në të gjithë serverat e klasterit, dhe të gjithë serverat e klasterit u zhvendosën në OOM. Pastaj ata gjithashtu u ngjitën, filluan të realizonin merger-in e kësaj operacioni, këtij bloku të dhënash, dhe përsëri ranë në OOM. Pastaj ata u ngjitën për së dyti dhe për së dyti ranë. Dhe kjo gjë nuk përfundoi.
Pastaj doli se në të vërtetë ishte një bug, që grupi e rregulloi. Kjo është shumë mirë, faleminderit shumë. Por mbetet një ndjenjë e keqe. Dhe tani, kur mendoj të bëj ndonjë merger në tabelë, më lind pyetja - pse nuk mund të ndikoj në këto merge në ndonjë mënyrë? Për shembull, të kufizoj ato sipas sasisë së memories që kërkohet, ose në përgjithësi sipas numrit të tyre, që do të përpunojnë këtë tabelë konkretisht.
Kam një tabelë që quhet 'Metrika', më përpunoni atë, ju lutem, me dy procese. Mos krijoni dhjetë ose pesë merge paralelisht, bëni me dy. Mendoj se me dy kam mjaft memorie, ndërsa për të dhjetë ndoshta nuk do të mjaftonte. Pse mbetet frika? Sepse tabela po rritet dhe një ditë do të përballem me situatën që në të vërtetë jo për shkak të një bugu, por për shkak se të dhënat do të ndryshojnë në një sasi të tillë të madhe, saqë mund të mos ketë mjaftueshëm memorie në server. Dhe atëherë serveri do të bjerë në OOM gjatë merge-it. Dhe unë mund të anuloj mutacionin, por merge-t jo.
E dini, gjatë bashkimeve serveri nuk do të bie në OOM, sepse gjatë bashkimit përdoret vetëm një sasi e vogël e RAM-it për një gamë të vogël të të dhënave. Pra, gjithçka do të jetë në rregull pavarësisht nga volumi i të dhënave.
Vladimir Kolobaev: Mirë. Këtu është një moment se pas rregullimit të defekteve, shkarkova versionin e ri dhe në një tabelë tjetër, më të vogël, ku kishte shumë parti, bëra një operacion të ngjashëm. Dhe gjatë bashkimit në server u konsumuan rreth 100 GB RAM. Kishit 150 të zënë, 100 mori, dhe mbeti një dritare prej 50 GB, kështu që nuk ra në OOM.
Çfarë po më mbron në këtë moment nga rënia në OOM, nëse ai vërtet po konsumon 100 GB RAM? Çfarë të bëj në situatën nëse për një moment RAM-i mbaron gjatë bashkimeve?
Alexey Milovidov: Ka një problem të tillë, se shpenzimi i RAM-it nuk kufizohet vetëm në bashkime. Problemi tjetër është se, nëse ndonjë bashkim është caktuar, ai duhet të ekzekutohet, sepse është shkruar në logun e replikimit. Logu i replikimit është ajo që është e nevojshme për të sjellë replikën në një gjendje konsistente. Nëse nuk bëhen manovra dorazi për ta rikthyer këtë log të replikimit, bashkimi do të duhet, pakuptuar, të ekzekutohet.
Sigurisht, do të ishte e dobishme të kishte një kufizim në RAM, i cili "për rast se" mbron pikërisht nga OOM. Ai nuk do të ndihmojë bashkimin të kryhet, ai do të fillojë përsëri, do të arrijë në një prag të caktuar, do të hedhë një përjashtim dhe pastaj do të fillojë përsëri - nuk do të dalë asgjë e mirë nga kjo. Por në thelb, do të ishte e dobishme të futet ky kufizim.
Si do të zhvillohet drejtuesi Golang për ClickHouse?
Drejtuesi Golang, i shkruar nga Kirill Shvakov, aktualisht duket se është mbështetur zyrtarisht nga ekipi i ClickHouse. Ai , tani është i madh dhe i vërtetë.
Një vërejtje e vogël. Ka një depo të mrekullueshme dhe të dashur për të gjithë, që quhet Vertica. Ata gjithashtu kanë një drejtpërdrejtës python, i cili mbështetet nga zhvilluesit e Vertica. Disa herë, ka ndodhur që versionet e depo dhe versionet e drejtpërdrejtës janë ndarë shumë, dhe drejtpërdrejtësi në një moment ka ndaluar së funksionuari. Një pikë e dytë. Mbështetjes për këtë drejtpërdrejtës zyrtare, më duket se i është dhënë sistemit "nipëll" - ti shkruan një problem, dhe ai mbetet aty përjetësisht.
Kam dy pyetje. Tani për tani, drejtpërdrejtësi e Kirill-it në Golang është mënyra standarde për të komunikuar nga Golang me ClickHouse. Përveç nëse dikush komunikon përmes ndërfaqes http, sepse i pëlqen kështu. Si do të zhvillohet kjo drejtpërdrejtësi? A do të sinkronizohet me disa ndryshime fondamentale në depotë? Dhe cili është rendi i shqyrtimit të problemeve?
Kirill Shvakov: E para - si funksionon gjithçka nga pikëpamja burokratike. Ky moment nuk është diskutuar, kështu që s'mund të përgjigjem.
Për të përgjigjur pyetjes për problemet, nevojitet një histori e vogël e drejtpërdrejtës. Kam punuar në një kompani që kishte shumë të dhëna. Kjo ishte një rreth virtual i reklamave me një numër të madh ngjarjesh që duhej të ruheshin diku. Dhe në një moment u shfaq ClickHouse. Ne e derdhëm atje të dhënat, dhe për një kohë të shkurtër gjithçka shkonte mirë, pastaj ClickHouse u rrëzua. Në atë moment, ne vendosëm se nuk na nevojitej.
Pas një viti, ne u kthyem në idenë e përdorimit të ClickHouse, dhe na duhej një mënyrë për të shkruar të dhënat atje. Parakushti ishte i tillë - harduari shumë i dobët, burimet pak. Por ne gjithmonë kemi punuar kështu, kështu që shikuam nga protokolli natyral.
Duke qenë se punonim në Go, ishte e qartë se na duhej një drejtpërdrejtës në Go. E zhvillova pothuajse me orar të plotë - kjo ishte detyra ime e punës. Deri në njëfarë momenti e arritëm, dhe në thelb askush nuk e mendonte se dikush tjetër do ta përdorte atë. Pastaj erdhi CloudFlare me një problem të njëjtë, dhe për një kohë punuam shumë ngushtë, sepse ata kishin të njëjtat detyra. Kështu që ne e bëmë këtë si në ClickHouse vetë, ashtu edhe në drejtpërdrejtës.
Në një moment, thjesht u ndala së punuari me ta, sepse aktiviteti im në lidhje me ClickHouse dhe puna ishte ndryshe. Prandaj, çështjet nuk përfundojnë. Periodikisht, njerëzit bëjnë komitete në repositorin, për të cilët ata vetë kanë ndonjë nevojë. Atëherë shoh pull request dhe ndonjëherë madje sajo ndonjë gjë vetë, por kjo ndodh rrallë.
Dua të kthehem te driva. Disa vite më parë, kur gjithçka filloi, ClickHouse ishte tjetër dhe me mundësi të tjera. Tani, ka një kuptim se si ta riparojmë drivën, që të jetë mirë. Nëse kjo ndodh, versioni 2 do të jetë për çfarëdo mënyre jo i përputhshëm për shkak të kostilëve të grumbulluar.
Nuk e di se si ta organizoj këtë. Unë vetë kam kohë të kufizuar. Nëse ndonjë person do të punojë për të përmirësuar drivën, unë do të mund t'u ndihmoj atyre dhe t'u tregoj se çfarë të bëjnë. Por, angazhimi aktiv i 'Yandex' në zhvillimin e projektit deri tani nuk është diskutuar aspak.
Alexey Milovidov: Në të vërtetë nuk ka asnjë burokraci për këta driva. E vetmja është që ata janë nxjerrë në një organizatë zyrtare, që do të thotë se ky driv është njohur si zgjidhja zyrtare për default për Go. Ka disa driva të tjerë, por ato shkojnë ndaras.
Nuk kemi asnjë zhvillim brenda për këta driva. Pyetja është - a do të jemi në gjendje të punësojmë një person të veçantë, jo për këtë driv konkret, por për zhvillimin e të gjitha drivave komitet, ose të gjejmë dikë nga jashtë.
Shtesa e jashtme nuk ngrihet pas ribashkimit me parametrin e aktivizuar lazy_load. Çfarë të bëj?
Ne kemi aktivizuar parametrin lazy_load, dhe pas ribashkimit të serverit, shtesa nuk ngrihet automatikisht. Ajo ngrihet vetëm pasi përdoruesi të përfitojë nga kjo shtesë. Dhe me kërkesën e parë jep një gabim. A mund të ngarkojmë automatikisht fjalorët me ndihmën e ClickHouse, apo duhet ta kontrollojmë gjithmonë ne përgatitjen e tyre, që përdoruesit të mos marrin gabime?
Mund të kemi një version të vjetër të ClickHouse, prandaj fjalori nuk është ngarkuar automatikisht. A mund të ndodhë kështu?
Së pari, fjalorët mund të ngarkohen forcërisht me ndihmën e pyetjes system reload dictionaries. Së dyti, përsa i përket gabimit - nëse fjalori është ngarkuar tashmë, atëherë kërkesat do të punojnë me të dhënat që janë ngarkuar. Nëse fjalori nuk është ngarkuar ende, ai do të ngarkohet në momentin e kërkesës.
Për fjalorët e rëndë, këtë është e vështirë. Për shembull, na nevojitet të tërheqim një milion rreshta nga MySQL. Disa bëjnë një pyetje të thjeshtë select, por kjo pyetje do të presë pikërisht atë një milion rreshta. Ka dy zgjidhje këtu. E para - çaktivizo lazy_load. E dyta - kur serveri ngrihet, para se t'i ngarkohet ai, të bëhet rilodim sistemin e fjalorit ose të thjesht ekzekutohet një pyetje që përdor fjalorin. Në këtë rast, fjalori do të ngarkohet. Duhet të monitoroni vetë disponueshmërinë e fjalorëve me konfigurimin e activizuar lazy_load, sepse ClickHouse automatikisht nuk i ngarkon ato.
Për pyetjen e fundit përgjigja është - ose versioni është i vjetër, ose duhet ta debug-oni.
Çfarë bëjmë me faktin që rinisja e sistemit nuk ngarkon asnjë nga shumë fjalorët nëse të paktën njëri prej tyre dështon me një gabim?
Ka edhe një pyetje në lidhje me rilodimin e fjalorëve të sistemit. Ne kemi dy fjalorë - njëri nuk ngarkohet, tjetri ngarkohet. Rilodimi i fjalorëve të sistemit në këtë rast nuk ngarkon asnjë fjalor, dhe duhet të ngarkohet pikërisht ai që ne duam me emrin e tij duke përdorur rilodimin e sistemit të fjalorit. A është kjo gjithashtu e lidhur me versionin e ClickHouse?
Dua t'ju gëzoj. Ky qëndrim ka ndryshuar. Do të thotë, nëse e përditësoni ClickHouse, atëherë gjithashtu do të ndryshojë. Nëse aktualja nuk ju kënaq, system reload dictionaries, përditësoni, dhe le të shpresojmë se do të ndryshojë në një drejtim më të mirë.
A ka një mënyrë për të konfiguruar kredencialet në konfigurimin ClickHouse, por pa i zbuluar ato gjatë gabimeve?
Pyetje tjetër lidhet me gabimet që shfaqen për fjalorin, sidomos me të dhënat e aksesit. Ne kemi shkruar të dhënat e lidhjes në konfigurimin e ClickHouse për fjalorin, dhe në rast gabimi ne marrim ato të dhëna dhe fjalëkalimin në përgjigje.
Ne e zgjidhëm këtë gabim duke nxjerrë të dhënat në konfigurimin e drejtorit ODBC. A ka ndonjë mënyrë për të konfiguruar të dhënat në konfigurimin e ClickHouse, por pa e ekspozuar këtë të dhënat në rast gabimesh?
Në këtë rast, zgjidhja është të especificoni këto kredenciale në odbc.ini, dhe në vetë ClickHouse të specifikoni vetëm Emrin e Burimit të Të Dhënave ODBC. Për burimet e tjera të fjalorëve kjo nuk do të ndodhë - as për fjalorin me MySQL, as për të tjerët nuk duhet të shihni fjalëkalimin në mesazh gabimi. Edhe për ODBC do ta kontrolloj - nëse e ka, duhet thjesht ta heqim.
Bonus: sfondet për Zoom nga mbledhjet
Duke klikuar mbi imazhin, për lexuesit më të durueshëm do të hapen sfondet bonus nga takimet. Shuarim zjarrin së bashku me maskotat e teknologjive Avito, diskutojmë me kolegët nga dhoma e sistemadministratorit ose klubi tradicional i kompjuterave dhe zhvillojmë aktivitete nën urë në sfondin e grafitit.
Burimi: habr.com
