Në prill, inxhinierët e Avito u mblodhën për takime në internet me zhvilluesin kryesor të ClickHouse Alexey Milovidov dhe Kirill Shvakov, një zhvillues Golang nga Integros. Ne diskutuam se si ne përdorim një sistem të menaxhimit të bazës së të dhënave dhe çfarë vështirësish hasim.
Bazuar në takimin, ne kemi përpiluar një artikull me përgjigjet e ekspertëve për pyetjet tona dhe të audiencës në lidhje me kopjet rezervë, rishkëmbimin e të dhënave, fjalorët e jashtëm, drejtuesin Golang dhe përditësimin e versioneve të ClickHouse. Mund të jetë e dobishme për zhvilluesit që tashmë janë duke punuar në mënyrë aktive me Yandex DBMS dhe janë të interesuar për të tashmen dhe të ardhmen e tij. Si parazgjedhje, përgjigjet janë nga Alexey Milovidov, përveç nëse shkruhet ndryshe.
Kini kujdes, ka shumë tekst nën prerje. Shpresojmë që përmbajtja me pyetje t'ju ndihmojë të lundroni.
Përmbajtje
Nëse nuk dëshironi ta lexoni tekstin, mund të shikoni regjistrimin e mbledhjeve . Kodet janë në komentin e parë nën video.
ClickHouse përditësohet vazhdimisht, por të dhënat tona jo. Çfarë duhet bërë për këtë?
ClickHouse përditësohet vazhdimisht dhe të dhënat tona, të cilat u optimizuan dhe u përpunuan përfundimisht, nuk përditësohen dhe janë në një kopje rezervë.
Le të themi se kishim ndonjë problem dhe të dhënat humbën. Ne vendosëm të rivendosnim dhe doli që ndarjet e vjetra, të cilat ruhen në serverët rezervë, janë shumë të ndryshme nga versioni i përdorur aktualisht i ClickHouse. Çfarë duhet bërë në një situatë të tillë dhe a është e mundur?
Një situatë në të cilën keni rivendosur të dhënat nga një kopje rezervë në një format të vjetër, por nuk lidhet me versionin e ri, është e pamundur. Ne sigurohemi që formati i të dhënave në ClickHouse të mbetet gjithmonë i pajtueshëm me të kaluarën. Kjo është shumë më e rëndësishme sesa përputhshmëria e prapambetur në funksionalitet nëse sjellja e disa funksioneve të përdorura rrallë ka ndryshuar. Versioni i ri i ClickHouse duhet të jetë gjithmonë në gjendje të lexojë të dhënat që ruhen në disk. Ky është ligji.
Cilat janë praktikat më të mira aktuale për rezervimin e të dhënave nga ClickHouse?
Si të bëjmë kopje rezervë, duke marrë parasysh që kemi operacionet përfundimtare të optimizimit, një bazë të dhënash të madhe me terabajt dhe të dhëna që përditësohen, le të themi, për tre ditët e fundit, dhe më pas nuk ndodhin asnjë procedurë?
Ne mund të bëjmë zgjidhjen tonë dhe të shkruajmë në bash: mblidhni këto kopje rezervë në këtë dhe atë mënyrë. Ndoshta nuk ka nevojë të patericë asgjë, dhe biçikleta është shpikur shumë kohë më parë?
Le të fillojmë me praktikat më të mira. Kolegët e mi gjithmonë këshillojnë, në përgjigje të pyetjeve në lidhje me kopjet rezervë, t'i kujtojnë ata për shërbimin Yandex.Cloud, ku ky problem tashmë është zgjidhur. Pra, përdorni nëse është e mundur.
Nuk ka asnjë zgjidhje të plotë për kopje rezervë, njëqind për qind e integruar në ClickHouse. Ka disa boshllëqe që mund të përdoren. Për të marrë një zgjidhje të plotë, ose do të duhet të ngatërroni pak me dorë, ose të krijoni mbështjellës në formën e skripteve.
Do të filloj me zgjidhjet më të thjeshta dhe do të përfundoj me ato më të sofistikuara, në varësi të vëllimit të të dhënave dhe madhësisë së grupit. Sa më i madh të jetë grupi, aq më komplekse bëhet zgjidhja.
Nëse tabela me të dhëna zë vetëm disa gigabajt, rezervimi mund të bëhet si kjo:
- Ruani përkufizimin e tabelës, d.m.th. metadatat − tregojnë krijimin e tabelës.
- Bëni një hale duke përdorur klientin ClickHouse - zgjidhni * nga tavolina për të paraqitur. Si parazgjedhje do të merrni një skedar në formatin TabSeparated. Nëse dëshironi të jeni më efikas, mund ta bëni në formatin Native.
Nëse sasia e të dhënave është më e madhe, atëherë rezervimi do të marrë më shumë kohë dhe shumë hapësirë. Ky quhet një kopje rezervë logjike; nuk është e lidhur me formatin e të dhënave ClickHouse. Nëse është, atëherë si mjeti i fundit mund të merrni një kopje rezervë dhe ta ngarkoni në MySQL për rikuperim.
Për raste më të avancuara, ClickHouse ka një aftësi të integruar për të krijuar një fotografi të ndarjeve në sistemin lokal të skedarëve. Ky funksion është i disponueshëm si kërkesë ndryshimi i ndarjes së ngrirjes së tabelës. Ose thjesht alter ngrirjen e tavolinës - kjo është një pamje e të gjithë tabelës.
Pamja e çastit do të krijohet vazhdimisht për një tabelë në një copë, domethënë është e pamundur të krijohet një fotografi e qëndrueshme e të gjithë grupit në këtë mënyrë. Por për shumicën e detyrave nuk ka një nevojë të tillë, dhe mjafton të ekzekutoni një kërkesë për çdo copëz dhe të merrni një pamje të qëndrueshme. Krijohet në formën e lidhjeve të forta dhe për këtë arsye nuk zë hapësirë shtesë. Më pas, ju kopjoni këtë fotografi në serverin rezervë ose në hapësirën ruajtëse që përdorni për kopje rezervë.
Rivendosja e një kopje rezervë të tillë është mjaft e lehtë. Së pari, krijoni tabela duke përdorur përkufizimet ekzistuese të tabelave. Më pas, kopjoni fotografitë e ruajtura të ndarjeve në Directory-Detached për këto tabela dhe ekzekutoni pyetjen bashkangjit ndarjen. Kjo zgjidhje është mjaft e përshtatshme për vëllimet më serioze të të dhënave.
Ndonjëherë keni nevojë për diçka edhe më të freskët - në rastet kur keni dhjetëra apo edhe qindra terabajt në secilin server dhe qindra serverë. Ekziston një zgjidhje këtu që e mora nga kolegët e mi nga Yandex.Metrica. Nuk do t'ua rekomandoja të gjithëve - lexoni dhe vendosni vetë nëse është i përshtatshëm apo jo.
Së pari ju duhet të krijoni disa serverë me rafte të mëdhenj disqesh. Më pas, në këta serverë, ngrini disa serverë ClickHouse dhe konfiguroni ato në mënyrë që të funksionojnë si një kopje tjetër për të njëjtat copëza. Dhe më pas përdorni një sistem skedari ose ndonjë mjet në këta serverë që ju lejon të krijoni fotografi. Këtu ka dy opsione. Opsioni i parë është fotografitë e LVM, opsioni i dytë është ZFS në Linux.
Pas kësaj, çdo ditë ju duhet të krijoni një fotografi, ajo do të gënjejë dhe do të zërë pak hapësirë. Natyrisht, nëse të dhënat ndryshojnë, sasia e hapësirës do të rritet me kalimin e kohës. Kjo fotografi mund të nxirret në çdo kohë dhe të dhënat të restaurohen, një zgjidhje kaq e çuditshme. Plus, ne gjithashtu duhet t'i kufizojmë këto kopje në konfigurim në mënyrë që ata të mos përpiqen të bëhen udhëheqës.
A do të jetë e mundur të organizohet një vonesë e kontrolluar e kopjeve në boshte?
Këtë vit ju po planifikoni të bëni boshte në ClickHouse. A do të jetë e mundur të organizohet një vonesë e kontrolluar e kopjeve në to? Ne do të donim ta përdorim atë për të mbrojtur veten nga skenarët negativë me ndryshime dhe ndryshime të tjera.
A është e mundur të bëhet një lloj rikthimi për ndryshime? Për shembull, në një bosht ekzistues, merrni dhe thoni që deri në këtë moment ju aplikoni ndryshimet, dhe nga ky moment ndaloni së aplikuari ndryshimet?
Nëse një komandë erdhi në grupin tonë dhe e prishi atë, atëherë kemi një kopje të kushtëzuar me një orë vonesë, ku mund të themi se le ta përdorim atë për momentin, por nuk do të aplikojmë ndryshime në të për dhjetë minutat e fundit?
Së pari, për vonesën e kontrolluar të kopjeve. Kishte një kërkesë të tillë nga përdoruesit, dhe ne krijuam një problem në Github me kërkesën: "Nëse dikush ka nevojë për këtë, pëlqeni atë, vendosni një zemër." Askush nuk dorëzoi dhe çështja u mbyll. Sidoqoftë, tashmë mund ta merrni këtë mundësi duke konfiguruar ClickHouse. Vërtetë, vetëm duke filluar nga versioni 20.3.
ClickHouse vazhdimisht kryen bashkimin e të dhënave në sfond. Kur një bashkim përfundon, një grup i caktuar të dhënash zëvendësohet me një pjesë më të madhe. Në të njëjtën kohë, pjesët e të dhënave që ishin aty më parë vazhdojnë të mbeten në disk për ca kohë.
Së pari, ato vazhdojnë të ruhen për sa kohë që ka pyetje të zgjedhura që i përdorin ato, për të siguruar funksionim jo-bllokues. Pyetjet e zgjedhura lexohen lehtësisht nga pjesët e vjetra.
Së dyti, ekziston edhe një prag kohor - pjesët e vjetra të të dhënave shtrihen në disk për tetë minuta. Këto tetë minuta mund të personalizohen dhe madje të kthehen në një ditë. Kjo do të kushtojë hapësirën në disk: në varësi të rrjedhës së të dhënave, rezulton se në ditën e fundit të dhënat jo vetëm që do të dyfishohen, por mund të bëhen pesë herë më shumë. Por nëse ka një problem serioz, mund të ndaloni serverin ClickHouse dhe të zgjidhni gjithçka.
Tani shtrohet pyetja se si kjo mbron nga ndryshimet. Këtu ia vlen të hedhim një vështrim më të thellë, sepse në versionet më të vjetra të ClickHouse, alter funksiononte në atë mënyrë që thjesht ndryshonte pjesët drejtpërdrejt. Ekziston një pjesë e të dhënave me disa skedarë, dhe ne bëjmë, për shembull, alter drop kolona. Pastaj kjo kolonë hiqet fizikisht nga të gjitha pjesët.
Por duke filluar me versionin 20.3, mekanizmi i ndryshimit është ndryshuar plotësisht dhe tani pjesët e të dhënave janë gjithmonë të pandryshueshme. Ato nuk ndryshojnë fare - ndryshimet tani funksionojnë në të njëjtën mënyrë si bashkimet. Në vend që të zëvendësojmë një pjesë në vend, ne krijojmë një të re. Në pjesën e re, skedarët që nuk kanë ndryshuar bëhen lidhje të forta dhe nëse fshijmë një kolonë, ajo thjesht do të mungojë në pjesën e re. Pjesa e vjetër do të fshihet si parazgjedhje pas tetë minutash, dhe këtu mund të ndryshoni cilësimet e përmendura më lart.
E njëjta gjë vlen edhe për ndryshime të tilla si mutacionet. Kur ju bëni ndrysho fshij ose ndrysho përditësimin, nuk e ndryshon copën, por krijon një të re. Dhe pastaj fshin të vjetrën.
Po sikur struktura e tabelës të ketë ndryshuar?
Si të rivendosni një kopje rezervë që është bërë me skemën e vjetër? Dhe pyetja e dytë ka të bëjë me rastin me fotografitë dhe mjetet e sistemit të skedarëve. A është Btrfs i mirë këtu në vend të ZFS në Linux LVM?
Nëse ju bëni bashkangjit ndarjen ndarjet me një strukturë të ndryshme, atëherë ClickHouse do t'ju tregojë se kjo nuk është e mundur. Kjo është zgjidhja. E para është krijimi i një tabele të përkohshme të tipit MergeTree me strukturën e vjetër, bashkëngjitni të dhënat atje duke përdorur bashkëngjitni dhe bëni një pyetje alternative. Pastaj mund t'i kopjoni ose transferoni këto të dhëna dhe t'i bashkëngjitni përsëri, ose të përdorni një kërkesë ndryshimi i ndarjes së lëvizjes së tabelës.
Tani pyetja e dytë është nëse Btrfs mund të përdoren. Për të filluar, nëse keni LVM, atëherë fotografitë e LVM janë të mjaftueshme, dhe sistemi i skedarëve mund të jetë ext4, nuk ka rëndësi. Me Btrts, gjithçka varet nga përvoja juaj në përdorimin e tij. Ky është një sistem skedari i pjekur, por ka ende disa dyshime se si gjithçka do të funksionojë në praktikë në një skenar të caktuar. Unë nuk do ta rekomandoja ta përdorni këtë nëse nuk keni Btrf në prodhim.
Cilat janë praktikat më të mira aktuale në rishkëmbimin e të dhënave?
Çështja e rishardimit është komplekse dhe e shumëanshme. Këtu ka disa përgjigje të mundshme. Mund të shkoni nga njëra anë dhe të thoni këtë - ClickHouse nuk ka një veçori të integruar rishardimi. Por kam frikë se kjo përgjigje nuk do t'i përshtatet askujt. Prandaj, mund të shkoni nga ana tjetër dhe të thoni se ClickHouse ka shumë mënyra për të rindërtuar të dhënat.
Nëse grupit i mbaron hapësira ose nuk mund të përballojë ngarkesën, ju shtoni serverë të rinj. Por këta serverë janë bosh si parazgjedhje, nuk ka të dhëna për to, nuk ka ngarkesë. Ju duhet të riorganizoni të dhënat në mënyrë që ato të shpërndahen në mënyrë të barabartë në grupin e ri, më të madh.
Mënyra e parë që mund të bëhet kjo është të kopjoni një pjesë të ndarjeve në serverë të rinj duke përdorur një kërkesë ndryshimi i ndarjes së tërheqjes së tabelës. Për shembull, keni pasur ndarje sipas muajve dhe merrni muajin e parë të 2017-ës dhe e kopjoni në një server të ri, pastaj kopjoni muajin e tretë në ndonjë server tjetër të ri. Dhe ju e bëni këtë derisa të bëhet pak a shumë e barabartë.
Transferimi mund të kryhet vetëm për ato ndarje që nuk ndryshojnë gjatë regjistrimit. Për ndarjet e reja, regjistrimi do të duhet të çaktivizohet, sepse transferimi i tyre nuk është atomik. Përndryshe, do të përfundoni me dublikatë ose boshllëqe në të dhëna. Megjithatë, kjo metodë është praktike dhe funksionon mjaft efektivisht. Ndarjet e kompresuara të gatshme transmetohen përmes rrjetit, domethënë të dhënat nuk kompresohen ose ri-kodohen.
Kjo metodë ka një pengesë, dhe kjo varet nga skema e ndarjes, nëse jeni zotuar për këtë skemë ndarjeje, çfarë çelësi copëtimi keni pasur. Në shembullin tuaj për rastin me metrikë, çelësi i ndarjes është hash-i i shtegut. Kur zgjidhni një tabelë të shpërndarë, ajo shkon te të gjitha pjesët e grupit menjëherë dhe merr të dhëna nga atje.
Kjo do të thotë që në fakt nuk ka rëndësi për ju se cilat të dhëna përfunduan në cilën copëza. Gjëja kryesore është se të dhënat përgjatë një rruge përfundojnë në një copë, por cila nuk është e rëndësishme. Në këtë rast, transferimi i ndarjeve të gatshme është i përsosur, sepse me pyetje të zgjedhura do të merrni gjithashtu të dhëna të plota - qoftë para rishardimit apo pas, skema nuk ka shumë rëndësi.
Por ka raste që janë më komplekse. Nëse në nivelin e logjikës së aplikacionit mbështeteni në një skemë të veçantë të ndarjes, se ky klient ndodhet në një copëz të tillë dhe të tillë, dhe kërkesa mund të dërgohet direkt atje, dhe jo në tabelën e shpërndarë. Ose po përdorni një version mjaft të fundit të ClickHouse dhe e keni aktivizuar cilësimin optimizoni kapërceni copëzat e papërdorura. Në këtë rast, gjatë pyetjes së selektimit, do të analizohet shprehja në seksionin ku dhe do të llogaritet se cilat copëza duhet të përdoren sipas skemës së ndarjes. Kjo funksionon me kusht që të dhënat të ndahen pikërisht sipas kësaj skeme ndarjeje. Nëse i riorganizoni ato me dorë, korrespondenca mund të ndryshojë.
Pra, kjo është metoda numër një. Dhe unë jam duke pritur për përgjigjen tuaj, nëse metoda është e përshtatshme, apo le të vazhdojmë.
Vladimir Kolobaev, administratori kryesor i sistemit në Avito: Alexey, metoda që përmende nuk funksionon shumë mirë kur duhet të shpërndash ngarkesën, përfshirë leximin. Mund të marrim një ndarje që është mujore dhe mund ta çojë muajin e mëparshëm në një nyje tjetër, por kur të vijë një kërkesë për këto të dhëna, ne vetëm do ta ngarkojmë atë. Por ne do të dëshironim të ngarkonim të gjithë grupin, sepse përndryshe, për ca kohë e gjithë ngarkesa e leximit do të përpunohet nga dy copëza.
Alexey Milovidov: Përgjigja këtu është e çuditshme - po, është e keqe, por mund të funksionojë. Unë do të shpjegoj saktësisht se si. Vlen të shikoni skenarin e ngarkesës që vjen pas të dhënave tuaja. Nëse këto janë të dhëna monitorimi, atëherë me siguri mund të themi se shumica dërrmuese e kërkesave janë për të dhëna të reja.
Keni instaluar serverë të rinj, migruat ndarjet e vjetra, por gjithashtu ndryshuat se si regjistrohen të dhënat e freskëta. Dhe të dhënat e freskëta do të shpërndahen në të gjithë grupin. Kështu, pas vetëm pesë minutash, kërkesat për pesë minutat e fundit do të ngarkojnë në mënyrë të barabartë grupin; pas një dite, kërkesat për XNUMX orë do të ngarkojnë në mënyrë të barabartë grupin. 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ë grupimit.
Por shpesh nuk do të keni kërkesa konkretisht për shkurt 2019. Me shumë mundësi, nëse kërkesat shkojnë në vitin 2019, atëherë ato do të jenë për të gjithë vitin 2019 - për një periudhë të madhe kohore, dhe jo për një gamë të vogël. Dhe kërkesa të tilla gjithashtu do të mund të ngarkojnë grupin në mënyrë të barabartë. Por në përgjithësi, vërejtja juaj është absolutisht e saktë se kjo është një zgjidhje ad hoc që nuk i shpërndan të dhënat plotësisht në mënyrë të barabartë.
Kam edhe disa pika për t'iu përgjigjur pyetjes. Njëra prej tyre ka të bëjë me atë se si të hartohet fillimisht një skemë copëzimi në mënyrë që ri-ndarja të shkaktonte më pak dhimbje. Kjo nuk është gjithmonë e mundur.
Për shembull, ju keni të dhëna monitorimi. Të dhënat e monitorimit po rriten për tre arsye. E para është grumbullimi i të dhënave historike. E dyta është rritja e trafikut. Dhe e treta është rritja e numrit të gjërave që janë objekt monitorimi. Ka mikroshërbime dhe metrika të reja që duhet të ruhen.
Ka mundësi që nga këto, rritja më e madhe të lidhet me arsyen e tretë – rritjen e përdorimit të monitorimit. Dhe në këtë rast, ia vlen të shikoni natyrën e ngarkesës, cilat janë pyetjet kryesore të përzgjedhjes. Pyetjet bazë të përzgjedhjes ka shumë të ngjarë të bazohen në disa nëngrup metrikash.
Për shembull, përdorimi i CPU-së në disa serverë nga ndonjë shërbim. Rezulton se ekziston një nëngrup i caktuar çelësash me të cilët merrni këto të dhëna. Dhe vetë kërkesa për këto të dhëna ka shumë të ngjarë mjaft e thjeshtë dhe plotësohet në dhjetëra milisekonda. Përdoret për monitorimin e shërbimeve dhe paneleve. Shpresoj ta kuptoj këtë saktë.
Vladimir Kolobaev: Fakti është se ne shumë shpesh i drejtohemi të dhënave historike, pasi e krahasojmë situatën aktuale me atë historike në kohë reale. Dhe është e rëndësishme për ne që të kemi akses të shpejtë në një sasi të madhe të dhënash, dhe ClickHouse bën një punë të shkëlqyer me këtë.
Ju keni absolutisht të drejtë, ne i përjetojmë shumicën e kërkesave të lexuara ditën e fundit, si çdo sistem monitorimi. Por në të njëjtën kohë, ngarkesa në të dhënat historike është gjithashtu mjaft e madhe. Në thelb vjen nga një sistem alarmi që shkon çdo tridhjetë sekonda dhe i thotë ClickHouse: “Më jep të dhënat për gjashtë javët e fundit. Tani më ndërto një lloj mesatare lëvizëse prej tyre dhe le të krahasojmë vlerën aktuale me atë historike.”
Dua të them se për kërkesa të tilla shumë të fundit kemi një tabelë tjetër të vogël në të cilën ruajmë vetëm dy ditë të dhëna dhe kërkesat kryesore fluturojnë në të. Ne dërgojmë vetëm pyetje të mëdha historike në tabelën e madhe të copëtuar.
Alexey Milovidov: Fatkeqësisht, rezulton të jetë keq i zbatueshëm për skenarin tuaj, por unë do t'ju tregoj një përshkrim të dy skemave të këqija dhe komplekse të ndarjes që nuk kanë nevojë të përdoren, por që përdoren në shërbimin e miqve të mi.
Ekziston një grup kryesor me ngjarjet Yandex.Metrica. Ngjarjet janë shikimet e faqeve, klikimet dhe konvertimet. Shumica e kërkesave shkojnë në një faqe interneti specifike. Ju hapni shërbimin Yandex.Metrica, keni një faqe interneti - avito.ru, shkoni te raporti dhe bëhet një kërkesë për faqen tuaj të internetit.
Por ka kërkesa të tjera – analitike dhe globale – që bëhen nga analistë të brendshëm. Për çdo rast, vërej se analistët e brendshëm bëjnë kërkesa vetëm për shërbimet Yandex. Por megjithatë, edhe shërbimet Yandex zënë një pjesë të konsiderueshme të të gjitha të dhënave. Këto nuk janë kërkesa për sportele specifike, por për filtrim më të gjerë.
Si t'i organizoni të dhënat në mënyrë të tillë që gjithçka të funksionojë në mënyrë efikase për një numërator, dhe gjithashtu pyetjet globale? Një vështirësi tjetër është se numri i kërkesave në ClickHouse për grupin Metrics është disa mijëra në sekondë. Në të njëjtën kohë, një server ClickHouse nuk mund të trajtojë kërkesa jo të parëndësishme, për shembull, disa mijëra në sekondë.
Madhësia e grupit është gjashtëqind e disa serverë. Nëse thjesht tërhiqni një tabelë të shpërndarë mbi këtë grup dhe dërgoni disa mijëra kërkesa atje, do të bëhet edhe më keq sesa dërgimi i tyre në një server. Nga ana tjetër, opsioni që të dhënat të shpërndahen në mënyrë të barabartë, dhe ne shkojmë dhe kërkojmë nga të gjithë serverët, hidhet menjëherë.
Ekziston një opsion që është diametralisht i kundërt. Imagjinoni nëse i ndajmë të dhënat nëpër sajte, dhe një kërkesë për një sajt shkon në një copëz. Tani grupi do të jetë në gjendje të trajtojë dhjetë mijë kërkesa në sekondë, por në një pjesë çdo kërkesë do të funksionojë shumë ngadalë. Ai nuk do të shkallëzohet më për sa i përket xhiros. Sidomos nëse kjo është faqja avito.ru. Nuk do ta zbuloj sekretin nëse them se Avito është një nga faqet më të vizituara në RuNet. Dhe ta përpunosh atë në një copëz do të ishte çmenduri.
Prandaj, skema e ndarjes është projektuar në një mënyrë më dinake. I gjithë grupi ndahet në një numër grupimesh, të cilat ne i quajmë shtresa. Çdo grup përmban nga një duzinë deri në disa dhjetëra copëza. Gjithsej janë tridhjetë e nëntë grupime të tilla.
Si përmasohet e gjithë kjo? Numri i grupimeve nuk ndryshon - siç ishte tridhjetë e nëntë vjet më parë, ai mbetet i tillë. Por brenda secilit prej tyre, ne gradualisht rrisim numrin e copëzave ndërsa grumbullojmë të dhëna. Dhe skema e ndarjes në tërësi është e tillë: këto grupe ndahen në faqe interneti dhe për të kuptuar se cila faqe interneti është në cilin grup, përdoret një metabazë e veçantë në MySQL. Një faqe - në një grup. Dhe brenda tij, ndarja ndodh sipas ID-ve të vizitorëve.
Gjatë regjistrimit, ne i ndajmë ato me pjesën e mbetur të ndarjes së ID-së së vizitorit. Por kur shtojmë një copëz të re, skema e ndarjes ndryshon; ne vazhdojmë të ndajmë, por me një pjesë të mbetur të pjesëtimit me një numër tjetër. Kjo do të thotë që një vizitor është tashmë i vendosur në disa serverë dhe nuk mund të mbështeteni në këtë. Kjo bëhet vetëm për të siguruar që të dhënat të jenë më të ngjeshura. Dhe kur bëjmë kërkesa, shkojmë te tabela e shpërndarë, e cila shikon grupin dhe akseson dhjetëra serverë. Kjo është një skemë kaq e trashë.
Por historia ime do të jetë e paplotë nëse nuk them se e kemi braktisur këtë skemë. Në skemën e re, ne ndryshuam gjithçka dhe kopjuam të gjitha të dhënat duke përdorur 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 u zgjodh pragu, por rezultati ishte që sajte të mëdha regjistrohen në një grup, ku ka 120 copëza me tre kopje secila - domethënë 360 serverë. Dhe skema e ndarjes është e tillë që çdo kërkesë shkon tek të gjitha copëzat menjëherë. Nëse tani hapni ndonjë faqe raporti për avito.ru në Yandex.Metrica, kërkesa do të shkojë në 120 serverë. Ka pak site të mëdha në RuNet. Dhe kërkesat nuk janë një mijë në sekondë, por edhe më pak se njëqind. E gjithë kjo përtypet në heshtje nga tabela e shpërndarë, të cilën secili prej tyre e përpunon me 120 serverë.
Dhe grupi i dytë është për faqet e vogla. Këtu është një skemë ndarjeje e bazuar në ID-në e faqes, dhe çdo kërkesë shkon saktësisht në një copëz.
ClickHouse ka një mjet kopjues të klikimit. Mund të na tregoni për të?
Unë do të them menjëherë se kjo zgjidhje është më e rëndë dhe disi më pak produktive. Avantazhi është se i njollos të dhënat plotësisht sipas modelit që specifikoni. Por pengesa e mjetit është se nuk rifreskohet fare. Ai kopjon të dhënat nga një skemë grupimi në një skemë tjetër grupimi.
Kjo do të thotë që që të funksionojë duhet të keni dy grupime. Ato mund të vendosen në të njëjtët serverë, por, megjithatë, të dhënat nuk do të zhvendosen gradualisht, por do të kopjohen.
Për shembull, kishte katër serverë, tani ka tetë. Ju krijoni një tabelë të re të shpërndarë në të gjithë serverët, tabela të reja lokale dhe hapni clickhouse-copier, duke treguar në të skemën e punës që duhet të lexojë nga atje, të pranojë skemën e re të ndarjes dhe të transferojë të dhënat atje. Dhe në serverët e vjetër do t'ju duhet një herë e gjysmë më shumë hapësirë se sa ka tani, sepse të dhënat e vjetra duhet të mbeten në to, dhe gjysma e të njëjtave të dhëna të vjetra do të mbërrijnë në krye të tyre. Nëse keni menduar paraprakisht se të dhënat duhet të rishlyhen dhe ka hapësirë, atëherë kjo metodë është e përshtatshme.
Si funksionon clickhouse-copier brenda? Ai e ndan të gjithë punën në një grup detyrash për përpunimin e një ndarjeje të një tabele në një copëz. Të gjitha këto detyra mund të ekzekutohen paralelisht, dhe clickhouse-copier mund të ekzekutohet në makina të ndryshme në shumë raste, por ajo që bën për një ndarje nuk është gjë tjetër veçse një përzgjedhje e insertit. Të dhënat lexohen, dekompresohen, rindahen, më pas kompresohen përsëri, shkruhen diku dhe rizgjidhen. Ky është një vendim më i ashpër.
Ju kishit një gjë pilot të quajtur resharding. Po me të?
Në vitin 2017, ju kishit një gjë pilot të quajtur resharding. Ekziston edhe një opsion në ClickHouse. Siç e kuptoj, nuk u ngrit. Mund të më thoni pse ndodhi kjo? Duket se është shumë e rëndësishme.
I gjithë problemi është se nëse është e nevojshme të risharkoni të dhënat në vend, kërkohet sinkronizim shumë kompleks për ta bërë këtë në mënyrë atomike. Kur filluam të shikonim se si funksionon ky sinkronizim, u bë e qartë se kishte probleme thelbësore. Dhe këto probleme themelore nuk janë vetëm teorike, por menjëherë filluan të shfaqen në praktikë në formën e diçkaje që mund të shpjegohet shumë thjesht - asgjë nuk funksionon.
A është e mundur të bashkohen të gjitha pjesët e të dhënave së bashku përpara se t'i zhvendosësh në disqe të ngadalta?
Pyetje rreth TTL me opsionin e lëvizjes në diskun e ngadaltë në kontekstin e bashkimeve. A ka ndonjë mënyrë, përveç nëpërmjet cron, për t'i bashkuar të gjitha pjesët në një para se t'i zhvendosni në disqe të ngadalta?
Përgjigja e pyetjes është e mundur që disi të ngjitni automatikisht të gjitha pjesët në një para se t'i transferoni - jo. Nuk mendoj se kjo është e nevojshme. Nuk është e nevojshme t'i bashkoni të gjitha pjesët në një, por thjesht mbështeteni në faktin se ato do të transferohen automatikisht në disqe të ngadalta.
Ne kemi dy kritere për rregullat e transferimit. E para është ashtu siç është mbushur. Nëse niveli aktual i ruajtjes ka më pak se një përqindje e caktuar e hapësirës së lirë, ne zgjedhim një pjesë dhe e zhvendosim në ruajtje më të ngadaltë. Ose më mirë, jo më i ngadalshëm, por tjetri - siç e konfiguroni.
Kriteri i dytë është madhësia. Bëhet fjalë për lëvizjen e pjesëve të mëdha. Mund ta rregulloni pragun sipas hapësirës së lirë në diskun e shpejtë dhe të dhënat do të transferohen automatikisht.
Si të migroni në versionet e reja të ClickHouse nëse nuk ka asnjë mënyrë për të kontrolluar përputhshmërinë paraprakisht?
Kjo temë diskutohet rregullisht duke marrë parasysh versione të ndryshme, dhe ende. Sa i sigurt është të përmirësoni nga versioni 19.11 në 19.16 dhe, për shembull, nga 19.16 në 20.3. Cila është mënyra më e mirë për të migruar në versione të reja pa qenë në gjendje të kontrolloni paraprakisht përputhshmërinë në sandbox?
Këtu ka disa rregulla "të arta". Së pari - . Është i madh, por ka paragrafë të veçantë për ndryshime të papajtueshme prapa. Mos i trajtoni këto pika si një flamur të kuq. Këto janë zakonisht papajtueshmëri të vogla që përfshijnë disa funksione të skajshme që me shumë mundësi nuk i përdorni.
Së dyti, nëse nuk ka asnjë mënyrë për të kontrolluar përputhshmërinë në sandbox dhe dëshironi të përditësoni menjëherë në prodhim, rekomandimi është që të mos keni nevojë ta bëni këtë. Së pari krijoni një sandbox dhe provoni. Nëse nuk ka mjedis testimi, atëherë ka shumë të ngjarë që nuk keni një kompani shumë të madhe, që do të thotë se mund të kopjoni disa nga të dhënat në laptop dhe të siguroheni që gjithçka të funksionojë siç duhet në të. Ju madje mund të ngrini disa kopje në vend në kompjuterin tuaj. Ose mund të merrni një version të ri diku afër dhe të ngarkoni disa nga të dhënat atje - domethënë, të krijoni një mjedis testimi të improvizuar.
Një rregull tjetër është të mos përditësoni për një javë pas lëshimit të versionit për shkak të kapjes së gabimeve në prodhim dhe rregullimeve të shpejta pasuese. Le të kuptojmë numërimin e versioneve të ClickHouse në mënyrë që të mos ngatërrohemi.
Ekziston versioni 20.3.4. Numri 20 tregon vitin e prodhimit - 2020. Nga pikëpamja e asaj që është brenda, kjo nuk ka rëndësi, kështu që ne nuk do t'i kushtojmë vëmendje. Tjetra - 20.3. Ne rrisim numrin e dytë - në këtë rast 3 - sa herë që lëshojmë një version me disa funksionalitete të reja. Nëse duam të shtojmë ndonjë veçori në ClickHouse, duhet ta rrisim këtë numër. Kjo do të thotë, në versionin 20.4 ClickHouse do të funksionojë edhe më mirë. Shifra e tretë është 20.3.4. Këtu 4 është numri i lëshimeve të patch-it në të cilat ne nuk shtuam veçori të reja, por rregulluam disa gabime. Dhe 4 do të thotë se e kemi bërë katër herë.
Mos mendoni se kjo është diçka e tmerrshme. Zakonisht përdoruesi mund të instalojë versionin më të fundit dhe do të funksionojë pa asnjë problem me kohën e funksionimit në vit. Por imagjinoni që në një funksion për përpunimin e bitmap-ve, i cili u shtua nga shokët tanë kinezë, serveri prishet kur kalon argumente të pasakta. Ne kemi përgjegjësi për ta rregulluar 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 e keni ClickHouse në prodhim dhe një version i ri i ClickHouse lëshohet me veçori shtesë - për shembull, 20.4.1 është i pari, mos nxitoni ta vini në prodhim ditën e parë. Pse është madje e nevojshme? Nëse nuk e keni përdorur tashmë ClickHouse, atëherë mund ta instaloni dhe me shumë mundësi gjithçka do të jetë mirë. Por nëse ClickHouse tashmë po funksionon në mënyrë të qëndrueshme, atëherë mbani një sy në arna dhe përditësime për të parë se çfarë problemesh po rregullojmë.
Kirill Shvakov: Do të doja të shtoja pak rreth mjediseve të testimit. Të gjithë kanë shumë frikë nga mjediset e testimit dhe për disa arsye ata besojnë se nëse keni një grup shumë të madh ClickHouse, atëherë mjedisi i testimit duhet të jetë jo më pak ose të paktën dhjetë herë më i vogël. Nuk është aspak kështu.
Unë mund t'ju them nga shembulli im. Unë kam një projekt, dhe ka ClickHouse. Mjedisi ynë i testimit është vetëm për të - kjo është një makinë e vogël virtuale në Hetzner për njëzet euro, ku është vendosur absolutisht gjithçka. Për ta bërë këtë, ne kemi automatizim të plotë në Ansible, dhe për këtë arsye, në parim, nuk ka dallim se ku të shkojmë - te serverët e harduerit ose thjesht të vendosemi në makinat virtuale.
Çfarë mund të bëhet? Do të ishte mirë të jepni një shembull në dokumentacionin e ClickHouse se si të vendosni një grup të vogël në shtëpinë tuaj - në Docker, në LXC, ndoshta të krijoni një libër lojërash Ansible, sepse njerëz të ndryshëm kanë vendosje të ndryshme. Kjo do të thjeshtojë shumë. Kur merrni dhe vendosni një grup në pesë minuta, është shumë më e lehtë të përpiqeni të kuptoni diçka. Kjo është shumë më e përshtatshme, sepse shtytja në një version prodhimi që nuk e keni testuar është një rrugë drejt askund. Ndonjëherë funksionon dhe ndonjëherë jo. Dhe për këtë arsye, shpresa për sukses është e keqe.
Maxim Kotyakov, inxhinier i lartë i mbështetjes Avito: Do të shtoj pak për mjediset e testimit nga një sërë problemesh me të cilat përballen kompanitë e mëdha. Ne kemi një grup të plotë të pranimit të ClickHouse; për sa i përket skemave dhe cilësimeve të të dhënave, është një kopje e saktë e asaj që është në prodhim. Ky grup është vendosur në kontejnerë mjaft të varfër me një minimum burimesh. Ne shkruajmë një përqindje të caktuar të të dhënave të prodhimit atje, për fat të mirë është e mundur të përsëritet rryma në Kafka. Gjithçka atje është e sinkronizuar dhe e shkallëzuar - si në aspektin e kapacitetit ashtu edhe të rrjedhës, dhe, në teori, të gjitha gjërat e tjera janë të barabarta, duhet të sillet si prodhim sipas metrikës. Çdo gjë potencialisht shpërthyese fillimisht rrokulliset në këtë stendë dhe lihet atje për disa ditë derisa të jetë gati. Por natyrshëm, kjo zgjidhje është e shtrenjtë, e vështirë dhe ka kosto mbështetëse jo zero.
Alexey Milovidov: Unë do t'ju tregoj se si është mjedisi i testimit të miqve tanë nga Yandex.Metrica. Një grup kishte 600 serverë tek, një tjetër kishte 360, dhe ekziston një grup i tretë dhe disa grupe. Mjedisi i testimit për njërën prej tyre është thjesht dy copëza me dy kopje në secilën. Pse dy copa? Që të mos jeni vetëm. Dhe duhet të ketë edhe kopje. Vetëm një sasi minimale e caktuar që mund të përballoni.
Ky mjedis testimi ju lejon të kontrolloni nëse pyetjet tuaja po funksionojnë dhe nëse ndonjë gjë e rëndësishme është prishur. Por shpesh lindin probleme të një natyre krejtësisht të ndryshme, kur gjithçka funksionon, por ka disa ndryshime të vogla në ngarkesë.
Më lejoni t'ju jap një shembull. Ne vendosëm të instalojmë një version të ri të ClickHouse. Është postuar në një mjedis testimi, testet e automatizuara janë përfunduar në vetë Yandex.Metrica, të cilat krahasojnë të dhënat e versionit të vjetër dhe atij të ri, duke drejtuar të gjithë tubacionin. Dhe sigurisht, testet jeshile të CI-së sonë. Përndryshe nuk do ta kishim propozuar as këtë version.
Cdo gje eshte ne rregull. Ne kemi filluar të kalojmë në prodhim. Më vjen një mesazh se ngarkesa në grafikët është rritur disa herë. Ne po e rikthejmë versionin. Unë shikoj grafikun dhe shoh: ngarkesa në fakt u rrit disa herë gjatë prezantimit dhe u ul përsëri kur ato u shfaqën. Më pas filluam të kthenim versionin. Dhe ngarkesa u rrit në të njëjtën mënyrë dhe ra përsëri në të njëjtën mënyrë. Pra, përfundimi është ky: ngarkesa është rritur për shkak të paraqitjes, asgjë për t'u habitur.
Atëherë ishte e vështirë të bindeshin kolegët të instalonin versionin e ri. Unë them: "Është në rregull, dil. Mbani gishtat e kryqëzuar, gjithçka do të funksionojë. Tani ngarkesa në grafikë është rritur, por gjithçka është në rregull. Rri aty." Në përgjithësi, ne e bëmë këtë, dhe kjo është ajo - versioni u lëshua për prodhim. Por pothuajse me çdo paraqitje lindin probleme të ngjashme.
Kill query supozohet të vrasë pyetjet, por nuk e bën. Pse?
Një përdorues, një lloj analisti, erdhi tek unë dhe krijoi një kërkesë që vendosi grupin tim ClickHouse. Disa nyje ose një grup i tërë, në varësi të cilës kopje ose copëza shkoi kërkesa. Unë shoh që të gjitha burimet e CPU në këtë server janë në një raft, gjithçka është e kuqe. Në të njëjtën kohë, vetë ClickHouse u përgjigjet kërkesave. Dhe unë shkruaj: "Ju lutem më tregoni, përpunoni listën, çfarë kërkese krijoi këtë çmenduri."
E gjej këtë kërkesë dhe i shkruaj vras. Dhe shoh që asgjë nuk po ndodh. Serveri im është në një raft, ClickHouse më pas më jep disa komanda, tregon se serveri është i gjallë dhe gjithçka është e shkëlqyer. Por unë kam degradim në të gjitha kërkesat e përdoruesve, degradimi fillon me regjistrimet në ClickHouse, dhe pyetja ime e vrasjes nuk funksionon. Pse? Mendova se vrasja e pyetjes supozohej të vriste pyetjet, por nuk ndodh.
Tani do të ketë një përgjigje mjaft të çuditshme. Çështja është se vrasja e pyetjes nuk i vret pyetjet.
Kill query kontrollon një kuti të vogël të quajtur "Unë dua që kjo pyetje të vritet". Dhe vetë kërkesa shikon këtë flamur kur përpunon çdo bllok. Nëse është vendosur, kërkesa ndalon së punuari. Rezulton se askush nuk e vret kërkesën, ai vetë duhet të kontrollojë gjithçka dhe të ndalojë. Dhe kjo duhet të funksionojë në të gjitha rastet kur kërkesa është në gjendje të përpunimit të blloqeve të të dhënave. Ai do të përpunojë bllokun tjetër të të dhënave, do të kontrollojë flamurin dhe do të ndalojë.
Kjo nuk funksionon në rastet kur kërkesa është e bllokuar në ndonjë operacion. Vërtetë, ka shumë të ngjarë që ky nuk është rasti juaj, sepse, sipas jush, ai përdor një ton burimesh serveri. Është e mundur që kjo të mos funksionojë në rastin e renditjes së jashtme dhe në disa detaje të tjera. Por në përgjithësi kjo nuk duhet të ndodhë, është një gabim. Dhe e vetmja gjë që mund të rekomandoj është të përditësoni ClickHouse.
Si të llogarisni kohën e përgjigjes nën ngarkesën e leximit?
Ekziston një tabelë që ruan agregatet e artikujve - numërues të ndryshëm. Numri i rreshtave është afërsisht njëqind milionë. A është e mundur të mbështeteni në një kohë të parashikueshme përgjigjeje nëse derdhni 1K RPS për 1K artikuj?
Duke gjykuar nga konteksti, ne po flasim për ngarkesën e leximit, sepse nuk ka probleme me shkrimin - madje mund të futen një mijë, madje njëqind mijë, dhe ndonjëherë disa miliona rreshta.
Kërkesat për lexim janë shumë të ndryshme. Në përzgjedhjen 1, ClickHouse mund të kryejë rreth dhjetëra mijëra kërkesa në sekondë, kështu që edhe kërkesat për një çelës do të kërkojnë tashmë disa burime. Dhe pyetje të tilla pikash do të jenë më të vështira sesa në disa baza të dhënash me vlerë kyçe, sepse për çdo lexim është e nevojshme të lexoni një bllok të dhënash sipas indeksit. Indeksi ynë adreson jo çdo rekord, por çdo varg. Kjo do të thotë, do të duhet të lexoni të gjithë gamën - kjo është 8192 rreshta si parazgjedhje. Dhe do t'ju duhet të dekompresoni bllokun e të dhënave të ngjeshur nga 64 KB në 1 MB. Në mënyrë tipike, pyetje të tilla të synuara kërkojnë disa milisekonda për t'u përfunduar. Por ky është opsioni më i thjeshtë.
Le të provojmë disa aritmetikë të thjeshtë. Nëse shumëzoni disa milisekonda me një mijë, merrni disa sekonda. Është sikur është e pamundur të mbash një mijë kërkesa në sekondë, por në fakt është e mundur, sepse ne kemi disa bërthama procesori. Pra, në parim, ClickHouse ndonjëherë mund të mbajë 1000 RPS, por për kërkesa të shkurtra, veçanërisht ato të synuara.
Nëse keni nevojë të shkallëzoni një grupim ClickHouse sipas numrit të kërkesave të thjeshta, atëherë unë rekomandoj gjënë më të thjeshtë - rrisni numrin e kopjeve dhe dërgoni kërkesa në një kopje të rastësishme. Nëse një kopje përmban pesëqind kërkesa në sekondë, që është plotësisht realiste, atëherë tre kopje do të trajtojnë një mijë e gjysmë.
Ndonjëherë, sigurisht, mund të konfiguroni ClickHouse për numrin maksimal të leximeve të pikave. Çfarë nevojitet për këtë? E para është zvogëlimi i granularitetit të indeksit. Në këtë rast, ai nuk duhet të reduktohet në një, por në bazë të faktit se numri i hyrjeve në indeks do të jetë disa miliona ose dhjetëra miliona për server. Nëse tabela ka njëqind milionë rreshta, atëherë përmasat mund të vendosen në 64.
Ju mund të zvogëloni madhësinë e bllokut të ngjeshur. Ka cilësime për këtë madhësia min e bllokut të kompresës, madhësia maksimale e bllokut të kompresës. Ato mund të reduktohen, të rimbushen me të dhëna dhe më pas pyetjet e synuara do të jenë më të shpejta. Por megjithatë, ClickHouse nuk është një bazë të dhënash me vlerë kyçe. Një numër i madh kërkesash të vogla është një antimodel i ngarkesës.
Kirill Shvakov: Unë do të jap këshilla në rast se ka llogari të zakonshme atje. Kjo është një situatë mjaft standarde kur ClickHouse ruan një lloj sporteli. Unë kam një përdorues, ai është nga ky dhe ai vend, dhe një fushë e tretë, dhe më duhet të rris diçka gradualisht. Merrni MySQL, bëni një çelës unik - në MySQL është një çelës dublikatë, dhe në PostgreSQL është një konflikt - dhe shtoni një shenjë plus. Kjo do të funksionojë shumë më mirë.
Kur nuk keni shumë të dhëna, nuk ka shumë kuptim të përdorni ClickHouse. Ka baza të të dhënave të rregullta dhe ata e bëjnë këtë mirë.
Çfarë mund të ndryshoj në ClickHouse në mënyrë që më shumë të dhëna të jenë në cache?
Le të imagjinojmë një situatë - serverët kanë 256 GB RAM, në rutinën e përditshme ClickHouse merr rreth 60-80 GB, në kulm - deri në 130. Çfarë mund të aktivizohet dhe rregullohet në mënyrë që më shumë të dhëna të jenë në cache dhe, në përputhje me rrethanat, ka më pak udhëtime në disk?
Në mënyrë tipike, cache e faqeve të sistemit operativ bën një punë të mirë për këtë. Nëse thjesht hapni pjesën e sipërme, shikoni atje të memories ose të lirë - gjithashtu tregon se sa është memoria e fshehtë - atëherë do të vini re se e gjithë memoria e lirë përdoret për cache. Dhe kur lexoni këto të dhëna, ato do të lexohen jo nga disku, por nga RAM. Në të njëjtën kohë, mund të them se cache përdoret në mënyrë efektive sepse janë të dhënat e kompresuara që ruhen.
Megjithatë, nëse doni të shpejtoni edhe më shumë disa pyetje të thjeshta, është e mundur të aktivizoni një cache në të dhënat e dekompresuara brenda ClickHouse. Quhet cache e pakompresuar. Në skedarin e konfigurimit config.xml, vendosni madhësinë e cache-it të pakompresuar në vlerën që ju nevojitet - Unë rekomandoj jo më shumë se gjysmën e RAM-it të lirë, sepse pjesa tjetër do të shkojë nën cache-in e faqes.
Përveç kësaj, ka dy cilësime të nivelit të kërkesës. Cilësimi i parë - përdorni cache të pakompresuar - përfshin përdorimin e tij. Rekomandohet ta aktivizoni atë për të gjitha kërkesat, përveç atyre të rënda, të cilat mund të lexojnë të gjitha të dhënat dhe të pastrojnë cache. Dhe cilësimi i dytë është diçka si numri maksimal i rreshtave për të përdorur cache. Ai kufizon automatikisht pyetjet e mëdha në mënyrë që ato të anashkalojnë cache.
Si mund të konfiguroj storage_configuration për ruajtje në RAM?
Në dokumentacionin e ri të ClickHouse lexova seksionin që lidhet . Përshkrimi përmban një shembull me SSD të shpejtë.
Pyes veten se si mund të konfigurohet e njëjta gjë me memorien e nxehtë të vëllimit. Dhe një pyetje tjetër. Si funksionon përzgjedhja me këtë organizim të të dhënave, a do të lexojë të gjithë grupin apo vetëm atë që është në disk dhe a janë këto të dhëna të ngjeshura në memorie? Dhe si funksionon seksioni prewhere me një organizim të tillë të dhënash?
Ky cilësim ndikon në ruajtjen e pjesëve të të dhënave dhe formati i tyre nuk ndryshon në asnjë mënyrë.
Le të hedhim një vështrim më të afërt.
Mund të konfiguroni ruajtjen e të dhënave në RAM. Gjithçka që është konfiguruar për diskun është rruga e tij. Ju krijoni një ndarje tmpfs që është montuar në një shteg në sistemin e skedarëve. Ju e specifikoni këtë shteg si shtegun për ruajtjen e të dhënave për ndarjen më të nxehtë, pjesët e të dhënave fillojnë të mbërrijnë dhe të shkruhen atje, gjithçka është në rregull.
Por unë nuk e rekomandoj ta bëni këtë për shkak të besueshmërisë së ulët, megjithëse nëse keni të paktën tre kopje në qendra të ndryshme të të dhënave, atëherë është e mundur. Nëse ndodh ndonjë gjë, të dhënat do të rikthehen. Le të imagjinojmë që serveri u fikur papritur dhe u ndez përsëri. Ndarja u montua përsëri, por nuk kishte asgjë atje. Kur serveri ClickHouse fillon, ai sheh që nuk i ka këto pjesë, megjithëse, sipas meta të dhënave ZooKeeper, ato duhet të jenë aty. Ai shikon se cilat kopje i kanë, i kërkon dhe i shkarkon. Në këtë mënyrë të dhënat do të rikthehen.
Në këtë kuptim, ruajtja e të dhënave në RAM nuk është thelbësisht e ndryshme nga ruajtja e tyre në disk, sepse kur të dhënat shkruhen në disk, ato gjithashtu fillimisht përfundojnë në cache-in e faqeve dhe shkruhen fizikisht më vonë. Kjo varet nga opsioni i montimit të sistemit të skedarëve. Por për çdo rast, do të them që ClickHouse nuk sinkronizohet kur futet.
Në këtë rast, të dhënat në RAM ruhen saktësisht në të njëjtin format si në disk. Pyetja e përzgjedhjes në të njëjtën mënyrë zgjedh pjesët që duhet të lexohen, zgjedh vargjet e nevojshme të të dhënave në pjesë dhe i lexon ato. Dhe prewhere funksionon saktësisht njësoj, pavarësisht nëse të dhënat ishin në RAM ose në disk.
Deri në cilin numër vlerash unike është efektiv Kardinaliteti i ulët?
Kardinaliteti i ulët është projektuar me zgjuarsi. Ai përpilon fjalorë të dhënash, por ata janë lokalë. Së pari, ka fjalorë të ndryshëm për secilën pjesë, dhe së dyti, edhe brenda një pjese ata mund të jenë të ndryshëm për çdo gamë. Kur numri i vlerave unike arrin një numër pragu - një milion, mendoj - fjalori thjesht mbyllet dhe krijohet një i ri.
Përgjigja është në përgjithësi: për çdo varg lokal - le të themi, për çdo ditë - diku deri në një milion vlera unike Kardinaliteti i ulët është efektiv. Më pas do të ketë thjesht një kthim prapa, në të cilin do të përdoren shumë fjalorë të ndryshëm, dhe jo vetëm një. Do të funksionojë afërsisht njësoj si një kolonë e rregullt e vargut, ndoshta pak më pak efikase, por nuk do të ketë degradim serioz të performancës.
Cilat janë praktikat më të mira për kërkimin me tekst të plotë në një tabelë me pesë miliardë rreshta?
Ka përgjigje të ndryshme. E para është të thuhet se ClickHouse nuk është një motor kërkimi me tekst të plotë. Ka sisteme të veçanta për këtë, për shembull, и . Megjithatë, unë shoh gjithnjë e më shumë njerëz që thonë se po kalojnë nga Elasticsearch në ClickHouse.
Pse ndodh kjo? Ata e shpjegojnë këtë me faktin se Elasticsearch pushon së përballuari ngarkesën në disa vëllime, duke filluar me ndërtimin e indekseve. Indekset bëhen shumë të rëndë dhe nëse thjesht i transferoni të dhënat në ClickHouse, rezulton se ato ruhen disa herë më me efikasitet për sa i përket vëllimit. Në të njëjtën kohë, pyetjet e kërkimit shpesh nuk ishin të tilla që të ishte e nevojshme të gjendej ndonjë frazë në të gjithë vëllimin e të dhënave, duke marrë parasysh morfologjinë, por ato krejtësisht të ndryshme. Për shembull, gjeni disa vijimësi të bajteve në regjistrat gjatë orëve të fundit.
Në këtë rast, ju krijoni një indeks në ClickHouse, fusha e parë e të cilit do të jetë data dhe ora. Dhe ndarja më e madhe e të dhënave do të bazohet në intervalin e datave. Brenda intervalit të zgjedhur të datave, si rregull, tashmë është e mundur të kryhet një kërkim me tekst të plotë, madje duke përdorur metodën e forcës brutale duke përdorur like. Operatori i ngjashëm në ClickHouse është operatori më efikas i pëlqimit që mund të gjeni. Nëse gjeni diçka më të mirë, më tregoni.
Por ende, si është një skanim i plotë. Dhe skanimi i plotë mund të jetë i ngadaltë jo vetëm në CPU, por edhe në disk. Nëse papritmas keni një terabajt të dhënash në ditë dhe kërkoni një fjalë gjatë ditës, atëherë do t'ju duhet të skanoni terabajtin. Dhe ndoshta është në disqet e rregullt të ngurtë, dhe në fund ata do të ngarkohen në atë mënyrë që nuk do të mund të hyni në këtë server përmes SSH.
Në këtë rast, unë jam gati të ofroj edhe një truk të vogël. Është eksperimentale - mund të funksionojë, mund jo. ClickHouse ka indekse me tekst të plotë në formën e filtrave të trigramit Bloom. Kolegët tanë në Arenadata i kanë provuar tashmë këto indekse dhe ato shpesh funksionojnë saktësisht siç synohet.
Për t'i përdorur ato në mënyrë korrekte, duhet të keni një kuptim të mirë të mënyrës se si funksionojnë: çfarë është filtri i trigramit Bloom dhe si të zgjidhni madhësinë e tij. Mund të them se do të ndihmojnë për pyetjet në disa fraza të rralla, nënvargje që gjenden rrallë në të dhëna. Në këtë rast, nëndarjet do të zgjidhen sipas indekseve dhe do të lexohen më pak të dhëna.
Kohët e fundit, ClickHouse ka shtuar funksione edhe më të avancuara për kërkimin e tekstit të plotë. Ky është, së pari, një kërkim për një grup nënvargjesh menjëherë në një kalim, duke përfshirë opsione që janë të ndjeshme ndaj shkronjave të vogla, të pandjeshme ndaj shkronjave, me mbështetje për UTF-8 ose vetëm për ASCII. Zgjidhni më efektivin që ju nevojitet.
Kërkimi për shprehje të shumta të rregullta në një kalim është shfaqur gjithashtu. Ju nuk keni nevojë të shkruani X si një nënvarg ose X si një nënvarg tjetër. Ju shkruani menjëherë, dhe gjithçka bëhet sa më efikase të jetë e mundur.
Së treti, tani ekziston një kërkim i përafërt për regexps dhe një kërkim i përafërt për nënstrings. Nëse dikush e ka shkruar gabim një fjalë, ajo do të kërkohet për përputhjen maksimale.
Cila është mënyra më e mirë për të organizuar qasjen në ClickHouse për një numër të madh përdoruesish?
Na tregoni se si të organizojmë më së miri aksesin për një numër të madh konsumatorësh dhe analistësh. Si të formoni një radhë, t'i jepni përparësi pyetjeve maksimale të njëkohshme dhe me cilat mjete?
Nëse grupi është mjaft i madh, atëherë një zgjidhje e mirë do të ishte ngritja e dy serverëve të tjerë, të cilët do të bëhen një pikë hyrje për analistët. Kjo do të thotë, mos lejoni analistët të kenë akses në copëza specifike në grup, por thjesht krijoni dy serverë bosh, pa të dhëna dhe konfiguroni të drejtat e aksesit në to. Në këtë rast, cilësimet e përdoruesit për kërkesat e shpërndara transferohen në serverë të largët. Kjo do të thotë, ju konfiguroni gjithçka në këta dy serverë dhe cilësimet kanë një efekt në të gjithë grupin.
Në parim, këta serverë nuk kanë të dhëna, por sasia e RAM-it në to është shumë e rëndësishme për ekzekutimin e kërkesave. Disku mund të përdoret gjithashtu për të dhëna të përkohshme nëse aktivizohet grumbullimi i jashtëm ose renditja e jashtme.
Është e rëndësishme të shikoni cilësimet që lidhen me të gjitha kufijtë e mundshëm. Nëse tani shkoj në grupin Yandex.Metrica si analist dhe bëj një kërkesë zgjidhni numërimin nga goditjet, atëherë do të më jepet menjëherë një përjashtim që nuk mund ta ekzekutoj kërkesën. Numri maksimal i rreshtave që më lejohet të skanoj është njëqind miliardë, dhe në total ka pesëdhjetë trilion prej tyre në një tabelë në grup. Ky është kufizimi i parë.
Le të themi se kam hequr kufirin e rreshtit dhe e ekzekutoj përsëri pyetjen. Pastaj do të shoh përjashtimin e mëposhtëm - cilësimi i aktivizuar indeksi i forcës sipas datës. Nuk mund ta plotësoj pyetjen nëse nuk kam specifikuar një interval datash. Ju nuk duhet të mbështeteni te analistët për ta specifikuar atë me dorë. Një rast tipik është kur shkruhet një interval datash ku data e ngjarjes midis javës. Dhe pastaj ata thjesht specifikuan një kllapa në vendin e gabuar, dhe në vend të dhe doli të ishte ose - ose URL përputhet. Nëse nuk ka kufi, ai do të zvarritet në kolonën URL dhe thjesht do të harxhojë një ton burimesh.
Përveç kësaj, ClickHouse ka dy cilësime prioritare. Fatkeqësisht, ata janë shumë primitivë. Njëri quhet thjesht prioritet. Nëse prioriteti ≠ 0, dhe kërkesat me disa prioritete janë duke u ekzekutuar, por një kërkesë me vlerë prioriteti më të vogël se, që do të thotë një prioritet më i lartë, është duke u ekzekutuar, atëherë një kërkesë me një vlerë përparësie më të madhe, që do të thotë një prioritet më i ulët. , thjesht është pezulluar dhe nuk do të funksionojë fare gjatë kësaj kohe.
Ky është një mjedis shumë i papërpunuar dhe nuk është i përshtatshëm për rastet kur grupi ka një ngarkesë konstante. Por nëse keni kërkesa të shkurtra dhe të mëdha që janë të rëndësishme dhe grupi është kryesisht i papunë, ky konfigurim është i përshtatshëm.
Caktimi tjetër i prioritetit quhet Prioriteti i fillit të OS. Thjesht vendos vlerën e mirë për të gjitha temat e ekzekutimit të kërkesave për planifikuesin Linux. Punon kështu-ashtu, por gjithsesi funksionon. Nëse vendosni vlerën minimale të bukur - është më e madhja në vlerë, dhe për rrjedhojë prioriteti më i ulët - dhe vendosni -19 për kërkesat me prioritet të lartë, atëherë CPU do të konsumojë kërkesat me prioritet të ulët rreth katër herë më pak se ato me prioritet të lartë.
Ju gjithashtu duhet të konfiguroni kohën maksimale të ekzekutimit të kërkesës - të themi, pesë minuta. Shpejtësia minimale e ekzekutimit të pyetjeve është gjëja më interesante. Ky cilësim ka ekzistuar për një kohë të gjatë dhe kërkohet jo vetëm për të pohuar që ClickHouse nuk ngadalësohet, por edhe për ta detyruar atë.
Imagjinoni, ju vendosni: nëse disa pyetje përpunojnë më pak se një milion rreshta në sekondë, nuk mund ta bëni këtë. Kjo turpëron emrin tonë të mirë, bazën tonë të të dhënave të mirë. Le ta ndalojmë këtë. Në fakt ka dy cilësime. Njëri quhet min shpejtësia e ekzekutimit - në rreshta për sekondë, dhe e dyta quhet timeout përpara se të kontrolloni shpejtësinë min të ekzekutimit - pesëmbëdhjetë sekonda si parazgjedhje. Kjo do të thotë, pesëmbëdhjetë sekonda janë të mundshme, dhe pastaj, nëse është e ngadaltë, atëherë thjesht hidhni një përjashtim dhe anuloni kërkesën.
Ju gjithashtu duhet të vendosni kuota. ClickHouse ka një veçori të integruar të kuotës që numëron konsumin e burimeve. Por, për fat të keq, jo burimet e harduerit si CPU, disqet, por ato logjike - numri i kërkesave të përpunuara, linjave dhe bajteve të lexuara. Dhe mund të konfiguroni, për shembull, një maksimum prej njëqind kërkesash brenda pesë minutave dhe një mijë kërkesa në orë.
Pse është e rëndësishme? Sepse disa pyetje analitike do të kryhen manualisht direkt nga klienti ClickHouse. Dhe gjithçka do të jetë mirë. Por nëse keni analistë të avancuar në kompaninë tuaj, ata do të shkruajnë një skenar dhe mund të ketë një gabim në skenar. Dhe ky gabim do të bëjë që kërkesa të ekzekutohet në një lak të pafund. Nga kjo duhet të mbrohemi.
A është e mundur të jepni rezultatet e një pyetjeje për dhjetë klientë?
Ne kemi disa përdorues që duan të vijnë me kërkesa shumë të mëdha në të njëjtën kohë. Kërkesa është e madhe dhe, në parim, ekzekutohet shpejt, por për faktin se kërkesa të tilla ka shumë në të njëjtën kohë, bëhet shumë e dhimbshme. A është e mundur të ekzekutohet e njëjta kërkesë, e cila ka mbërritur dhjetë herë radhazi, një herë dhe t'u jepet rezultati dhjetë klientëve?
Problemi është se ne nuk kemi rezultatet e cache ose cache të të dhënave të ndërmjetme. Ekziston një cache faqesh e sistemit operativ, i cili do t'ju pengojë të lexoni përsëri të dhënat nga disku, por, për fat të keq, të dhënat do të dekompresohen, deserializohen dhe ripërpunohen.
Do të doja ta shmangja disi këtë, ose duke ruajtur të dhënat e ndërmjetme, ose duke rreshtuar pyetje të ngjashme në një lloj radhe dhe duke shtuar një cache të rezultateve. Aktualisht kemi një kërkesë tërheqëse në zhvillim që shton një memorie të fshehtë të kërkesës, por vetëm për pyetjet e nënshtruara në seksionet në dhe bashkim - domethënë, zgjidhja është e paplotë.
Megjithatë, edhe ne përballemi me një situatë të tillë. Një shembull veçanërisht kanonik janë pyetjet me faqe. Ka një raport, ka disa faqe, dhe ka një kërkesë për limit 10. Pastaj e njëjta gjë, por limit 10,10. Pastaj një faqe tjetër. Dhe pyetja është, pse i numërojmë të gjitha këto çdo herë? Por tani nuk ka zgjidhje dhe nuk ka asnjë mënyrë për ta shmangur atë.
Ekziston një zgjidhje alternative që vendoset si karrige anësore pranë ClickHouse - .
Kirill Shvakov: ClickHouse Proxy ka një kufizues të integruar të shpejtësisë dhe një cache të integruar të rezultateve. Aty u bënë shumë cilësime sepse po zgjidhej një problem i ngjashëm. Proxy ju lejon të kufizoni kërkesat duke i vendosur ato në radhë dhe të konfiguroni sa kohë jeton cache e kërkesave. Nëse kërkesat ishin vërtet të njëjta, Proxy do t'i dërgojë ato shumë herë, por do të shkojë në ClickHouse vetëm një herë.
Nginx gjithashtu ka një cache në versionin falas, dhe kjo gjithashtu do të funksionojë. Nginx madje ka cilësime që nëse kërkesat mbërrijnë në të njëjtën kohë, ai do të ngadalësojë të tjerët derisa të përfundojë njëra. Por është në ClickHouse Proxy që konfigurimi është bërë shumë më mirë. Është bërë posaçërisht për ClickHouse, posaçërisht për këto kërkesa, kështu që është më i përshtatshëm. Epo, është e lehtë për t'u instaluar.
Po në lidhje me operacionet asinkrone dhe pamjet e materializuara?
Ekziston një problem që operacionet me motorin e riprodhimit janë asinkron - së pari shkruhen të dhënat, pastaj shemben. Nëse një tabletë e materializuar me disa agregate jeton nën shenjën, atëherë do t'i shkruhen dublikatë. Dhe nëse nuk ka logjikë komplekse, atëherë të dhënat do të dyfishohen. Çfarë mund të bëni për këtë?
Ekziston një zgjidhje e qartë - të zbatohet një shkas në një klasë të caktuar matviews gjatë një operacioni kolapsi asinkron. A ka ndonjë plumb argjendi apo plane për të zbatuar funksione të ngjashme?
Vlen të kuptohet se si funksionon deduplikimi. Ajo që do t'ju them tani nuk është e rëndësishme për pyetjen, por vetëm në rast se ia vlen të kujtohet.
Kur futet në një tabelë të përsëritur, ka dedublikim të të gjithë blloqeve të futura. Nëse rifutni të njëjtin bllok që përmban të njëjtin numër të të njëjtave rreshta në të njëjtin rend, atëherë të dhënat do të fshihen. Do të merrni "Ok" në përgjigje të futjes, por në fakt do të shkruhet një paketë e të dhënave dhe nuk do të kopjohet.
Kjo është e nevojshme për siguri. Nëse merrni "Ok" gjatë futjes, atëherë të dhënat tuaja janë futur. Nëse merrni një gabim nga ClickHouse, do të thotë se ato nuk janë futur dhe ju duhet të përsërisni futjen. Por nëse lidhja prishet gjatë futjes, atëherë nuk e dini nëse të dhënat janë futur apo jo. Mundësia e vetme është të përsërisni futjen përsëri. Nëse të dhënat janë futur në të vërtetë dhe ju i keni rifutur ato, ka dedublikim të bllokut. Kjo është e nevojshme për të shmangur dublikatat.
Dhe është gjithashtu e rëndësishme se si funksionon për pikëpamjet e materializuara. Nëse të dhënat janë deduplikuar kur janë futur në tabelën kryesore, atëherë ato nuk do të kalojnë as në pamjen e materializuar.
Tani për pyetjen. Situata juaj është më e ndërlikuar sepse po regjistroni dublikatë të rreshtave individualë. Kjo do të thotë, nuk është e gjithë paketa ajo që dublikohet, por linja specifike dhe ato shemben në sfond. Në të vërtetë, të dhënat do të shemben në tabelën kryesore, por të dhënat e pakompuara do të shkojnë në pamjen e materializuar dhe gjatë bashkimeve nuk do të ndodhë asgjë me pamjet e materializuara. Sepse një pamje e materializuar nuk është gjë tjetër veçse një insert shkas. Gjatë operacioneve të tjera, asgjë shtesë nuk i ndodh.
Dhe nuk mund të të bëj të lumtur këtu. Thjesht duhet të kërkoni një zgjidhje specifike për këtë rast. Për shembull, a është e mundur të riprodhohet në një pamje të materializuar, dhe metoda e dedublikimit mund të funksionojë në të njëjtën mënyrë. Por për fat të keq, jo gjithmonë. Nëse grumbullohet, nuk do të funksionojë.
Kirill Shvakov: Ne gjithashtu kishim ndërtim me paterica në atë ditë. Kishte një problem që ka përshtypje reklamash, dhe ka disa të dhëna që mund t'i shfaqim në kohë reale - këto janë vetëm përshtypje. Ato rrallë dublikohen, por nëse kjo ndodh, ne do t'i shembim gjithsesi më vonë. Dhe kishte gjëra që nuk mund të dyfishoheshin - klikimet dhe e gjithë kjo histori. Por gjithashtu doja t'i tregoja pothuajse menjëherë.
Si u realizuan pikëpamjet e materializuara? Kishte pamje ku shkruhej drejtpërdrejt - shkruhej në të dhëna të papërpunuara dhe shkruhej në pamje. Atje, në një moment të dhënat nuk janë shumë të sakta, janë të dyfishuara, etj. Dhe ka një pjesë të dytë të tabelës, ku ato duken saktësisht të njëjta me pamjet e materializuara, domethënë janë absolutisht identike në strukturë. Herë pas here ne rillogaritim të dhënat, i numërojmë të dhënat pa dublikatë, shkruajmë në ato tabela.
Ne kaluam API - kjo nuk do të funksionojë manualisht në ClickHouse. Dhe API duket: kur kam datën e shtimit të fundit në tabelë, ku garantohet që të dhënat e sakta janë llogaritur tashmë, dhe ai bën një kërkesë në një tabelë dhe në një tabelë tjetër. Nga njëra kërkesa zgjedh deri në një kohë të caktuar, dhe nga tjetra merr atë që ende nuk është llogaritur. Dhe funksionon, por jo vetëm përmes ClickHouse.
Nëse keni një lloj API - për analistët, për përdoruesit - atëherë, në parim, ky është një opsion. Ju jeni gjithmonë duke numëruar, gjithmonë duke numëruar. Kjo mund të bëhet një herë në ditë ose në një kohë tjetër. Ju zgjidhni për veten tuaj një gamë që nuk ju nevojitet dhe nuk është kritike.
ClickHouse ka shumë regjistra. Si mund të shoh gjithçka që ndodh me serverin me një shikim?
ClickHouse ka një numër shumë të madh regjistrash të ndryshëm dhe ky numër po rritet. Në versionet e reja, disa prej tyre madje janë të aktivizuara si parazgjedhje; në versionet e vjetra ato duhet të aktivizohen kur përditësohen. Megjithatë, ka gjithnjë e më shumë prej tyre. Në fund të fundit, do të doja të shihja se çfarë po ndodh me serverin tim tani, ndoshta në një lloj pulti përmbledhës.
A keni një ekip ClickHouse, ose ekipe të miqve tuaj, që mbështesin disa funksione të paneleve të gatshme që do t'i shfaqnin këto regjistra si një produkt të përfunduar? Në fund të fundit, vetëm shikimi i regjistrave në ClickHouse është i shkëlqyeshëm. Por do të ishte shumë mirë nëse do të ishte përgatitur tashmë në formën e një pulti. Unë do të marr një goditje nga ajo.
Ka tabela, megjithëse nuk janë të standardizuara. Në kompaninë tonë, rreth 60 ekipe përdorin ClickHouse, dhe gjëja më e çuditshme është se shumë prej tyre kanë panele kontrolli që i kanë bërë vetë, dhe paksa të ndryshëm. Disa ekipe përdorin një instalim të brendshëm Yandex.Cloud. Ka disa raporte të gatshme, edhe pse jo të gjitha ato të nevojshme. Të tjerët kanë të tyren.
Kolegët e mi nga Metrica kanë pultin e tyre në Grafana, dhe unë kam timin për grupin e tyre. Po shikoj gjëra të tilla si cache hit për serif cache. Dhe akoma më e vështirë është se ne përdorim mjete të ndryshme. Kam krijuar pultin tim duke përdorur një mjet shumë të vjetër të quajtur Graphite-web. Ai është plotësisht i shëmtuar. Dhe unë ende e përdor në këtë mënyrë, megjithëse Grafana ndoshta do të ishte më e përshtatshme dhe më e bukur.
Gjëja themelore në panelet e kontrollit është e njëjtë. Këto janë matjet e sistemit për grupin: CPU, memorie, disku, rrjeti. Të tjera - numri i kërkesave të njëkohshme, numri i bashkimeve të njëkohshme, numri i kërkesave për sekondë, numri maksimal i pjesëve për ndarjet e tabelës MergeTree, vonesa e përsëritjes, madhësia e radhës së përsëritjes, numri i rreshtave të futur për sekondë, numri i blloqeve të futura për sekondë. Kjo është gjithçka që merret jo nga regjistrat, por nga metrikat.
Vladimir Kolobaev: Alexey, do të doja ta korrigjoja pak. Aty është Grafana. Grafana ka një burim të dhënash, i cili është ClickHouse. Kjo do të thotë, unë mund të bëj kërkesa nga Grafana direkt në ClickHouse. ClickHouse ka një tabelë me regjistrat, është e njëjtë për të gjithë. Si rezultat, unë dua të hyj në këtë tabelë log në Grafana dhe të shoh kërkesat që bën serveri im. Do të ishte mirë të kishim një pult si ky.
E kam hipur me biçikletë vetë. Por unë kam një pyetje - nëse është e gjitha e standardizuar, dhe Grafana përdoret nga të gjithë, pse Yandex nuk ka një pult të tillë zyrtar?
Kirill Shvakov: Në fakt, burimi i të dhënave që shkon në ClickHouse tani mbështet Altinity. Dhe unë thjesht dua të jap një vektor se ku të gërmoj dhe kë të shtyjë. Ju mund t'i pyesni ata, sepse Yandex ende bën ClickHouse, dhe jo historinë rreth tij. Altinity është kompania kryesore që aktualisht promovon ClickHouse. Ata nuk do ta braktisin, por do ta mbështesin. Sepse, në parim, për të ngarkuar një panel kontrolli në faqen e internetit të Grafana, duhet vetëm të regjistroheni dhe ta ngarkoni atë - nuk ka probleme të veçanta.
Alexey Milovidov: Gjatë vitit të kaluar, ClickHouse ka shtuar shumë aftësi për profilizimin e pyetjeve. Ka matje për çdo kërkesë për përdorimin e burimeve. Dhe vetëm kohët e fundit, ne shtuam një profilues pyetjesh të nivelit edhe më të ulët për të parë se ku po shpenzon një pyetje çdo milisekondë. Por për të përdorur këtë funksionalitet, duhet të hap klientin e konsolës dhe të shkruaj një kërkesë, të cilën e harroj gjithmonë. E ruajta diku dhe vazhdoj të harroj se ku saktësisht.
Do të doja të kishte një mjet që sapo tha, këtu janë pyetjet tuaja të rënda, të grupuara sipas klasës së pyetjeve. Shtyva njërën dhe më thoshin se prandaj është e rëndë. Nuk ka një zgjidhje të tillë tani. Dhe është vërtet shumë e çuditshme që kur njerëzit më pyesin: "Më thuaj, a ka ndonjë panel të gatshëm për Grafana?", Unë them: "Shko në faqen e internetit të Grafana, ka një komunitet "Dashboards" dhe ka një panel kontrolli. nga Dimka, ka një pult nga Kostyan. Nuk e di se çfarë është, nuk e kam përdorur vetë.”
Si të ndikoni në bashkimet në mënyrë që serveri të mos përplaset në OOM?
Unë kam një tabelë, ka vetëm një ndarje në tabelë, ajo është ReplacingMergeTree. Unë kam shkruar të dhëna në të për katër vjet. Më duhej të bëja një ndryshim në të dhe të fshija disa të dhëna.
E bëra këtë dhe gjatë përpunimit të kësaj kërkese, e gjithë memoria në të gjithë serverët në grup u konsumua dhe të gjithë serverët në grup u futën në OOM. Pastaj ata u ngritën të gjithë së bashku, filluan të bashkojnë të njëjtin operacion, këtë bllok të dhënash dhe ranë përsëri në OOM. Pastaj u ngritën përsëri dhe ranë përsëri. Dhe kjo gjë nuk u ndal.
Pastaj doli se ky ishte në të vërtetë një gabim që djemtë e rregulluan. Kjo është shumë e bukur, faleminderit shumë. Por një mbetje mbeti. Dhe tani, kur mendoj të bëj një lloj shkrirjeje në tabelë, kam një pyetje - pse nuk mund të ndikoj disi në këto bashkime? Për shembull, kufizoni ato me sasinë e RAM-it të kërkuar, ose, në parim, me sasinë që do të përpunojë këtë tabelë të veçantë.
Unë kam një tabelë të quajtur "Metrics", ju lutem përpunoni atë për mua në dy tema. Nuk ka nevojë të krijoni dhjetë ose pesë bashkime paralelisht, bëjeni në dy. Mendoj se kam memorie të mjaftueshme për dy, por mund të mos mjaftojë për të përpunuar dhjetë. Pse mbetet frika? Sepse tabela po rritet dhe një ditë do të përballem me një situatë që, në parim, nuk është më për shkak të një gabimi, por sepse të dhënat do të ndryshojnë në një sasi kaq të madhe sa që thjesht nuk do të kem memorie të mjaftueshme në server. Dhe pastaj serveri do të përplaset në OOM kur bashkohet. Për më tepër, mund ta anuloj mutacionin, por Merji nuk është më aty.
E dini, kur bashkohet, serveri nuk do të bjerë në OOM, sepse kur bashkohet, sasia e RAM-it përdoret vetëm për një gamë të vogël të dhënash. Pra, gjithçka do të jetë mirë, pavarësisht nga sasia e të dhënave.
Vladimir Kolobaev: Mirë. Këtu momenti është i tillë që pasi u rregullua gabimi, shkarkova një version të ri për veten time dhe në një tabelë tjetër, një më të vogël, ku ka shumë ndarje, bëra një operacion të ngjashëm. Dhe gjatë bashkimit, rreth 100 GB RAM u dogj në server. Kisha 150 të zëna, 100 të ngrëna dhe një dritare 50 GB të mbetur, kështu që nuk rashë në OOM.
Çfarë më mbron aktualisht nga rënia në OOM nëse në fakt konsumon 100 GB RAM? Çfarë duhet të bëni nëse papritmas RAM-i në bashkime mbaron?
Alexey Milovidov: Ekziston një problem i tillë që konsumi i RAM-it posaçërisht për bashkim nuk është i kufizuar. Dhe problemi i dytë është se nëse është caktuar një lloj bashkimi, atëherë ai duhet të ekzekutohet sepse është regjistruar në regjistrin e replikimit. Regjistri i replikimit është veprimet që nevojiten për ta sjellë replikën në një gjendje të qëndrueshme. Nëse nuk bëni manipulime manuale që do të rikthejnë këtë regjistër të përsëritjes, bashkimi do të duhet të kryhet në një mënyrë ose në një tjetër.
Sigurisht, nuk do të ishte e tepërt të kishim një kufizim RAM që "vetëm në rast" mbron nga OOM. Nuk do të ndihmojë që bashkimi të përfundojë, ai do të fillojë përsëri, do të arrijë një prag, do të bëjë një përjashtim dhe pastaj do të fillojë përsëri - asgjë e mirë nuk do të vijë nga kjo. Por në parim, do të ishte e dobishme të futej ky kufizim.
Si do të zhvillohet drejtuesi Golang për ClickHouse?
Shoferi Golang, i cili u shkrua nga Kirill Shvakov, tani mbështetet zyrtarisht nga ekipi ClickHouse. Ai , ai tani është i madh dhe i vërtetë.
Një shënim i vogël. Ekziston një depo e mrekullueshme dhe e dashur e formave normale të rendit të pafund - kjo është Vertica. Ata gjithashtu kanë drejtuesin e tyre zyrtar të python, i cili mbështetet nga zhvilluesit e Vertica. Dhe disa herë ndodhi që versionet e ruajtjes dhe versionet e shoferit ndryshuan mjaft dramatikisht, dhe shoferi në një moment pushoi së punuari. Dhe pika e dytë. Mbështetja për këtë shofer zyrtar, më duket, kryhet nga sistemi "thimtha" - ju i shkruani atyre një çështje dhe ai qëndron përgjithmonë.
Kam dy pyetje. Tani shoferi Golang i Kirill është pothuajse mënyra e paracaktuar për të komunikuar nga Golang me ClickHouse. Përveç nëse dikush ende komunikon përmes ndërfaqes http sepse i pëlqen në këtë mënyrë. Si do të vazhdojë zhvillimi i këtij drejtuesi? A do të sinkronizohet me ndonjë ndryshim të thyer në vetë depo? Dhe cila është procedura për shqyrtimin e një çështjeje?
Kirill Shvakov: E para është se si gjithçka është organizuar në mënyrë burokratike. Kjo pikë nuk u diskutua, kështu që nuk kam çfarë të përgjigjem.
Për t'iu përgjigjur pyetjes në lidhje me këtë çështje, na duhet një histori e vogël e shoferit. Kam punuar për një kompani që kishte shumë të dhëna. Ishte një rrotullues reklamash me një numër të madh ngjarjesh që duheshin ruajtur diku. Dhe në një moment u shfaq ClickHouse. E mbushëm me të dhëna dhe në fillim gjithçka ishte në rregull, por më pas ClickHouse u rrëzua. Në atë moment vendosëm që nuk kishim nevojë për të.
Një vit më vonë, ne iu kthyem idesë së përdorimit të ClickHouse dhe na duhej të shkruanim disi të dhënat atje. Mesazhi hyrës ishte ky: hardueri është shumë i dobët, ka pak burime. Por ne kemi punuar gjithmonë në këtë mënyrë, dhe për këtë arsye kemi parë drejt protokollit vendas.
Meqenëse punonim në Go, ishte e qartë se kishim nevojë për një shofer Go. E bëra pothuajse me kohë të plotë - ishte detyra ime e punës. Ne e sollëm atë në një pikë të caktuar dhe në parim askush nuk supozoi se dikush tjetër përveç nesh do ta përdorte atë. Pastaj CloudFlare erdhi me të njëjtin problem, dhe për disa kohë ne punuam me ta shumë mirë, sepse ata kishin të njëjtat detyra. Për më tepër, ne e bëmë këtë si në ClickHouse vetë ashtu edhe në shofer.
Në një moment, thjesht ndalova së bëri, sepse aktiviteti im përsa i përket ClickHouse dhe punës ndryshoi pak. Prandaj çështjet nuk janë mbyllur. Periodikisht, njerëzit që kanë nevojë për diçka vetë angazhohen në depo. Pastaj shikoj kërkesën për tërheqje dhe ndonjëherë e modifikoj diçka vetë, por kjo ndodh rrallë.
Dua të kthehem te shoferi. Disa vite më parë, kur filloi e gjithë kjo gjë, ClickHouse ishte gjithashtu i ndryshëm dhe me aftësi të ndryshme. Tani ne kemi një kuptim se si të rikrijojmë drejtuesin në mënyrë që të funksionojë mirë. Nëse kjo ndodh, atëherë versioni 2 do të jetë i papajtueshëm në çdo rast për shkak të patericave të grumbulluara.
Nuk di si ta organizoj këtë çështje. Unë vetë nuk kam shumë kohë. Nëse disa njerëz mbarojnë shoferin, unë mund t'i ndihmoj dhe t'u them se çfarë të bëjnë. Por pjesëmarrja aktive e Yandex në zhvillimin e projektit nuk është diskutuar ende.
Alexey Milovidov: Në fakt, ende nuk ka burokraci për këta shoferë. E vetmja gjë është që ato i dorëzohen një organizate zyrtare, domethënë, ky shofer njihet si zgjidhja zyrtare e paracaktuar për Go. Ka disa shoferë të tjerë, por ata vijnë veçmas.
Ne nuk kemi ndonjë zhvillim të brendshëm për këta drejtues. Pyetja është nëse ne mund të punësojmë një person individual, jo për këtë shofer të veçantë, por për zhvillimin e të gjithë drejtuesve të komunitetit, apo mund të gjejmë dikë nga jashtë.
Fjalori i jashtëm nuk ngarkohet pas një rindezjeje me cilësimin lazy_load të aktivizuar. Çfarë duhet bërë?
Ne kemi aktivizuar cilësimin lazy_load dhe pasi serveri është rindezur, fjalori nuk ngarkohet më vete. Ai ngrihet vetëm pasi përdoruesi të ketë akses në këtë fjalor. Dhe herën e parë që e aksesoj, jep një gabim. A është e mundur që disi të ngarkoni automatikisht fjalorët duke përdorur ClickHouse, apo duhet të kontrolloni gjithmonë vetë gatishmërinë e tyre në mënyrë që përdoruesit të mos marrin gabime?
Ndoshta ne kemi një version të vjetër të ClickHouse, kështu që fjalori nuk u ngarkua automatikisht. A mund të jetë ky rasti?
Së pari, fjalorët mund të ngarkohen me detyrim duke përdorur një pyetje ringarkoni fjalorët e sistemit. Së dyti, në lidhje me gabimin - nëse fjalori është tashmë i ngarkuar, atëherë pyetjet do të funksionojnë bazuar në të dhënat që janë ngarkuar. Nëse fjalori nuk është ngarkuar ende, ai do të ngarkohet direkt gjatë kërkesës.
Kjo nuk është shumë e përshtatshme për fjalorë të rëndë. Për shembull, ju duhet të tërhiqni një milion rreshta nga MySQL. Dikush bën një përzgjedhje të thjeshtë, por kjo përzgjedhje do të presë të njëjtat milion rreshta. Këtu ka dy zgjidhje. E para është të çaktivizoni lazy_load. Së dyti, kur serveri është në punë, përpara se të vendosni ngarkesën mbi të, bëni fjalori i ringarkimit të sistemit ose thjesht bëni një pyetje që përdor një fjalor. Më pas fjalori do të ngarkohet. Duhet të kontrolloni disponueshmërinë e fjalorëve me cilësimin lazy_load të aktivizuar, sepse ClickHouse nuk i ngarkon automatikisht.
Përgjigja për pyetjen e fundit është ose versioni është i vjetër ose duhet të korrigjohet.
Çfarë duhet bërë me faktin se fjalorët e rifreskimit të sistemit nuk ngarkojnë asnjë nga shumë fjalorë nëse të paktën njëri prej tyre rrëzohet me një gabim?
Ekziston një pyetje tjetër në lidhje me fjalorët e ringarkimit të sistemit. Ne kemi dy fjalorë - njëri nuk është i ngarkuar, i dyti është i ngarkuar. Në këtë rast, fjalorët e rifreskimit të sistemit nuk ngarkojnë asnjë fjalor dhe ju duhet të ngarkoni pikë për pikë një të veçantë me emrin e tij duke përdorur fjalorin e rifreskimit të sistemit. A lidhet kjo edhe me versionin ClickHouse?
Dua te te bej te lumtur. Kjo sjellje po ndryshonte. Kjo do të thotë që nëse përditësoni ClickHouse, ai gjithashtu do të ndryshojë. Nëse nuk jeni të kënaqur me sjelljen tuaj aktuale ringarkoni fjalorët e sistemit, përditëso dhe le të shpresojmë se do të ndryshojë për mirë.
A ka ndonjë mënyrë për të konfiguruar detajet në konfigurimin e ClickHouse, por jo për t'i shfaqur ato në rast gabimesh?
Pyetja tjetër ka të bëjë me gabimet që lidhen me fjalorin, përkatësisht detajet. Ne kemi specifikuar detajet e lidhjes në konfigurimin e ClickHouse për fjalorin dhe nëse ka një gabim, ne i marrim këto detaje dhe fjalëkalimin si përgjigje.
Ne e zgjidhëm këtë gabim duke shtuar detaje në konfigurimin e shoferit ODBC. A ka ndonjë mënyrë për të konfiguruar detajet në konfigurimin e ClickHouse, por të mos shfaqen këto detaje në rast gabimesh?
Zgjidhja e vërtetë këtu është të specifikoni këto kredenciale në odbc.ini, dhe në vetë ClickHouse të specifikoni vetëm emrin e burimit të të dhënave ODBC. Kjo nuk do të ndodhë për burimet e tjera të fjalorit - as për fjalorin me MySQL, as për të tjerët, nuk duhet ta shihni fjalëkalimin kur merrni një mesazh gabimi. Për ODBC, unë gjithashtu do të shikoj - nëse ekziston, thjesht duhet ta hiqni atë.
Bonus: sfonde për Zoom nga mbledhjet
Duke klikuar mbi foto, sfondet bonus nga mbledhjet do të hapen për lexuesit më këmbëngulës. Ne shuajmë zjarrin së bashku me maskotat e teknologjisë Avito, bisedojmë me kolegët nga dhoma e administratorit të sistemit ose nga klubi kompjuterik i shkollës së vjetër dhe zhvillojmë takime të përditshme nën urë në sfondin e grafiteve.
Burimi: www.habr.com