Apirilean, Avitoko ingeniariak sareko bileretarako bildu ziren Alexey Milovidov ClickHouse garatzaile nagusiarekin eta Kirill Shvakov, Integros-eko Golang garatzailearekin. Datu-baseak kudeatzeko sistema nola erabiltzen dugun eta zein zailtasun aurkitzen ditugun eztabaidatu dugu.
Bileran oinarrituta, artikulu bat bildu dugu adituen erantzunak gure eta ikusleen galderei buruz babeskopiei, datuen birpartekatzeari, kanpoko hiztegiei, Golang kontrolatzaileari eta ClickHouse bertsioen eguneratzeari buruz. Dagoeneko Yandex DBMS-rekin aktiboki lanean ari diren eta bere oraina eta etorkizuna interesatuta dauden garatzaileentzat erabilgarria izan daiteke. Berez, erantzunak Alexey Milovidovenenak dira, bestela idatzi ezean.
Kontuz, ebakiaren azpian testu asko dago. Galderak dituen edukiak nabigatzen lagunduko dizula espero dugu.
Edukia
Testua irakurri nahi ez baduzu, topaketen grabazioa ikus dezakezu . Denbora-kodeak bideoaren azpiko lehen iruzkinean daude.
ClickHouse etengabe eguneratzen da, baina gure datuak ez. Zer egin horren aurrean?
ClickHouse etengabe eguneratzen da, eta gure datuak, azken prozesatutako optimizatu zirenak, ez dira eguneratzen eta babeskopia batean daude.
Demagun arazoren bat izan dugula eta datuak galdu direla. Berrezartzea erabaki genuen, eta ondorioztatu zen backup zerbitzarietan gordetzen diren partizio zaharrak gaur egun erabiltzen den ClickHouse-ren bertsioaren oso desberdinak direla. Zer egin horrelako egoera batean, eta posible al da?
Ezinezkoa da babeskopia batetik datuak formatu zaharrean leheneratu dituzunean, baina bertsio berrira konektatzen ez den egoera. Ziurtatzen dugu ClickHouse-ko datu-formatuak alderantziz bateragarriak izaten jarraitzen duela beti. Funtzionalitatean atzerako bateragarritasuna baino askoz ere garrantzitsuagoa da gutxi erabiltzen diren funtzio batzuen portaera aldatu bada. ClickHouse-ren bertsio berriak diskoan gordetako datuak irakurtzeko gai izan behar du beti. Hau da legea.
Zeintzuk dira ClickHouse-ko datuen babeskopiak egiteko egungo jardunbide onenak?
Nola egin segurtasun-kopiak, azken eragiketak optimizatzeko, terabyte-ko datu-base erraldoi bat eta azken hiru egunetan eguneratzen diren datuak, esate baterako, eta gero prozedurarik gertatzen ez dela?
Gure irtenbidea egin dezakegu eta bash-ean idatzi: bildu babeskopia hauek halako eta horrela. Agian ez dago ezer makulu beharrik, eta bizikleta aspaldi asmatu zen?
Has gaitezen praktika onekin. Nire lankideek beti gomendatzen dute, babeskopiei buruzko galderei erantzuteko, Yandex.Cloud zerbitzuari buruz gogorarazteko, non arazo hau dagoeneko konpondu den. Beraz, erabili ahal izanez gero.
Ez dago babeskopietarako irtenbide osoa, ClickHousen ehuneko ehunean sartuta. Hutsune batzuk erabil daitezke. Irtenbide osoa lortzeko, eskuz apur bat egin beharko duzu, edo bilgarriak sortu script moduan.
Irtenbide errazenetatik hasiko naiz eta sofistikatuenekin amaituko dut, datu-bolumenaren eta klusterraren tamainaren arabera. Zenbat eta handiagoa izan klusterra, orduan eta konplexuagoa da irtenbidea.
Datuak dituen taulak gigabyte batzuk besterik ez baditu, babeskopia honela egin daiteke:
- Gorde taularen definizioa, hau da, metadatuak - erakutsi taula sortu.
- Egin zabortegia ClickHouse bezeroa erabiliz - hautatu * mahaitik artxibatzeko. Lehenespenez, fitxategi bat jasoko duzu TabSeparated formatuan. Eraginkorragoa izan nahi baduzu, jatorrizko formatuan egin dezakezu.
Datu-kopurua handiagoa bada, babeskopiak denbora gehiago eta leku asko beharko ditu. Hau babeskopia logikoa deitzen da; ez dago ClickHouse datu-formatuari lotuta. Hala bada, azken aukera gisa babeskopia bat egin dezakezu eta MySQLra igo dezakezu berreskuratzeko.
Kasu aurreratuagoetarako, ClickHouse-k fitxategi-sistema lokalean partizioen argazki bat sortzeko gaitasuna du. Ezaugarri hau eskaera gisa erabilgarri dago aldatu taula izoztu partizioa. Edo besterik gabe aldatu mahaia izoztu - Hau taula osoaren argazkia da.
Argazkia koherentziaz sortuko da zati bateko taula baterako, hau da, ezinezkoa da era honetan kluster osoaren argazki koherente bat sortzea. Baina zeregin gehienetarako ez dago halako beharrik, eta nahikoa da zati bakoitzean eskaera bat exekutatu eta argazki koherente bat lortzea. Esteka gogorren moduan sortzen da eta, beraz, ez du leku gehigarririk hartzen. Ondoren, kopiatuko duzu argazki hau babeskopien zerbitzarian edo babeskopiak egiteko erabiltzen duzun biltegiratzera.
Horrelako babeskopia berreskuratzea nahiko erraza da. Lehenik eta behin, sortu taulak dauden taulen definizioak erabiliz. Ondoren, kopiatu partizioen gordetako argazkiak Directory-Detached-era taula hauetarako eta exekutatu kontsulta erantsi partizioa. Irtenbide hau nahiko egokia da datu-bolumen larrienetarako.
Batzuetan, zerbait are freskoagoa behar duzu - zerbitzari bakoitzean hamarnaka edo ehunka terabyte eta ehunka zerbitzari dituzun kasuetan. Hemen Yandex.Metricako nire lankideengandik jaso nuen irtenbide bat dago. Ez nieke guztiei gomendatuko; irakurri eta erabaki ezazu zuk zeuk egokia den ala ez.
Lehenik eta behin, hainbat zerbitzari sortu behar dituzu disko-apalategi handiekin. Ondoren, zerbitzari hauetan, igo ClickHouse zerbitzari batzuk eta konfiguratu zati berdinetarako beste erreplika gisa funtziona dezaten. Eta gero erabili fitxategi-sistema bat edo zerbitzari hauetan argazkiak sortzeko aukera ematen duen tresnaren bat. Hemen bi aukera daude. Lehenengo aukera LVM argazkiak dira, bigarren aukera Linux-en ZFS da.
Horren ondoren, egunero argazki bat sortu behar duzu, gezurra izango da eta leku pixka bat hartuko du. Jakina, datuak aldatzen badira, denboraren poderioz espazio kopurua handituko da. Argazki hau edozein unetan atera daiteke eta datuak leheneratu, hain irtenbide arraroa. Gainera, erreplika hauek konfigurazioan ere mugatu behar ditugu, lider izaten saiatu ez daitezen.
Posible al da ardatzetan errepliken desfase kontrolatua antolatzea?
Aurten ClickHousen ardatzak egiteko asmoa duzu. Posible al da horietan errepliken desfase kontrolatua antolatzea? Aldaketekin eta beste aldaketa batzuekin eszenatoki negatiboetatik babesteko erabili nahiko genuke.
Posible al da aldaketetarako nolabaiteko itzulera bat egitea? Adibidez, lehendik dagoen ardatz batean, hartu eta esan momentu honetara arte aldaketak aplikatzen dituzula, eta momentu honetatik aldaketak aplikatzeari uzten diozula?
Komando bat gure klusterera iritsi eta hautsi badu, orduan ordubeteko atzerapena duen erreplika baldintzatua dugu, non une honetan erabil dezagun esan dezakegu, baina ez diogu aldaketarik aplikatuko azken hamar minutuetan?
Lehenik eta behin, errepliken atzerapen kontrolatuari buruz. Erabiltzaileen eskaera bat zegoen, eta eskaerarekin arazo bat sortu genuen Github-en: "Norbaitek hau behar badu, gustatu, jarri bihotza". Inork ez zuen entregatu, eta arazoa itxi egin zen. Hala ere, dagoeneko lor dezakezu aukera hau ClickHouse konfiguratuz. Egia da, 20.3 bertsiotik hasita bakarrik.
ClickHouse-k etengabe egiten ditu datuak atzeko planoan bateratzea. Batzea amaitzen denean, datu multzo jakin bat zati handiago batekin ordezkatzen da. Aldi berean, aurretik zeuden datuek denbora batez diskoan jarraitzen dute.
Lehenik eta behin, haiek erabiltzen dituzten kontsulta hautatuak dauden bitartean gordetzen jarraitzen dute, blokeorik gabeko eragiketa eskaintzeko. Hautatutako kontsultak zati zaharretatik erraz irakurtzen dira.
Bigarrenik, denbora-atalase bat ere badago: datu zaharrak zortzi minutuz daude diskoan. Zortzi minutu hauek pertsonaliza daitezke eta baita egun bakar batean ere bihurtu. Horrek diskoko espazioa kostatuko du: datu-fluxuaren arabera, azken egunean datuak bikoiztu ez ezik, bost aldiz gehiago izan daitezkeela gertatzen da. Baina arazo larri bat badago, ClickHouse zerbitzaria gelditu eta dena ordenatu dezakezu.
Orain, hau aldaketen aurka nola babesten duen galdera sortzen da. Merezi du hemen sakonago aztertzea, izan ere, ClickHouse-ren bertsio zaharretan, aldaerak modu horretan funtzionatzen zuen, piezak zuzenean aldatzen baitzituen. Fitxategi batzuekin datu bat dago, eta guk, adibidez, aldatu jaregin zutabea. Ondoren, zutabe hau zati guztietatik kentzen da fisikoki.
Baina 20.3 bertsiotik hasita, aldatzeko mekanismoa guztiz aldatu da, eta orain datu zatiak beti aldaezinak dira. Ez dira batere aldatzen; orain aldaketek bateratzeen modu berean funtzionatzen dute. Pieza bat lekuan bertan ordezkatu beharrean, berria sortzen dugu. Zati berrian, aldatu ez diren fitxategiak esteka gogor bihurtzen dira, eta zutabe bat ezabatzen badugu, zati berrian besterik gabe faltako da. Pieza zaharra lehenespenez ezabatuko da zortzi minuturen buruan, eta hemen goian aipatutako ezarpenak doi ditzakezu.
Gauza bera gertatzen da aldaketekin, hala nola mutazioekin. Egiten duzunean aldatu ezabatu edo eguneratzea aldatu, ez du pieza aldatzen, berri bat sortzen du baizik. Eta gero zaharra ezabatzen du.
Zer gertatzen da taularen egitura aldatu bada?
Nola berreskuratu eskema zaharrarekin egindako babeskopia? Eta bigarren galdera argazkien eta fitxategi-sistemako tresnen kasuari buruzkoa da. Btrfs ona al da hemen Linux LVM-n ZFS-ren ordez?
Egiten baduzu erantsi partizioa egitura ezberdineko partizioak, orduan ClickHouse-k hori ezinezkoa dela esango dizu. Hau da irtenbidea. Lehenengoa MergeTree motako aldi baterako taula bat sortzea da egitura zaharrarekin, hor datuak erantsi attach erabiliz eta aldatzeko kontsulta bat egitea. Ondoren, datu hauek kopiatu edo transferitu eta berriro erantsi ditzakezu, edo eskaera bat erabili aldatu taula mugitu partizioa.
Orain bigarren galdera da Btrfs erabil daitekeen. Hasteko, LVM baduzu, orduan LVM argazkiekin nahikoa da, eta fitxategi-sistema ext4 izan daiteke, berdin du. Btrts-ekin, dena erabiltzen duzun esperientziaren araberakoa da. Fitxategi-sistema heldua da, baina egoera jakin batean dena praktikan nola funtzionatuko duen susmo batzuk daude oraindik. Ez nuke gomendatuko hau erabiltzea produkzioan Btrfs ez baduzu.
Zeintzuk dira gaur egungo jardunbide egokiak datuak birpartikatzean?
Resharding-aren arazoa konplexua eta askotarikoa da. Hainbat erantzun posible daude hemen. Alde batetik joan zaitezke eta hau esan dezakezu - ClickHouse-k ez du birpartidatze-funtziorik barneraturik. Baina beldur naiz erantzun hau ez zaiola inori egokituko. Hori dela eta, beste alde batetik joan eta esan dezakezu ClickHouse-k datuak birzikatzeko modu asko dituela.
Klusterra lekurik gabe geratzen bada edo karga kudeatu ezin badu, zerbitzari berriak gehitzen dituzu. Baina zerbitzari hauek hutsik daude lehenespenez, ez dago daturik, ez dago kargarik. Datuak berrantolatu behar dituzu, kluster handiago berrian uniformeki heda daitezen.
Hori egin daitekeen lehen modua partizioen zati bat zerbitzari berrietara kopiatzea da eskaera baten bidez aldatu taula lortzeko partizioa. Adibidez, hilabeteka partizioak zenituen, eta 2017ko lehen hilabetea hartu eta zerbitzari berri batera kopiatu eta hirugarren hilabetea beste zerbitzari berri batera kopiatu. Eta hori egiten duzu, gutxi gorabehera, berdindu arte.
Grabazioan aldatzen ez diren partizioetarako soilik egin daiteke transferentzia. Partizio freskoetarako, grabaketa desgaitu egin beharko da, haien transferentzia ez baita atomikoa. Bestela, datu bikoiztuak edo hutsuneak izango dituzu. Hala ere, metodo hau praktikoa da eta nahiko eraginkorra da. Prestatutako partizio konprimituak sarean transmititzen dira, hau da, datuak ez dira konprimitzen edo birkodetzen.
Metodo honek eragozpen bat du, eta zatiketa-eskemaren araberakoa da, zatiketa-eskema honekin konpromisoa hartu duzun ala ez, zein zatiketa-gako zeneukan. Neurrien kasuan zure adibidean, zatiketa-gakoa bidearen hash da. Banatutako taula bat hautatzen duzunean, klusterreko zati guztietara joaten da aldi berean eta hortik datuak hartzen ditu.
Horrek esan nahi du ez dizula axola zer datu zein zatitan amaitu den. Gauza nagusia da bide bateko datuak zati batean amaitzen direla, baina zein ez da garrantzitsua. Kasu honetan, prest egindako partizioak transferitzea ezin hobea da, aukeratutako kontsultekin datu osoak ere jasoko dituzulako - birpartidatu aurretik edo ondoren, eskemak ez du benetan axola.
Baina badira konplexuagoak diren kasuak. Aplikazio-mailan logika mailan zatiketa-eskema berezi batean oinarritzen bazara, bezero hau halako zati batean kokatuta dagoela eta eskaera zuzenean bertara bidali daiteke, eta ez Banatutako taulara. Edo ClickHouse-ren bertsio berri samarra erabiltzen ari zara eta ezarpena gaitu duzu optimizatu saltatu erabili gabeko zatiak. Kasu honetan, hautatzeko kontsultan, non ataleko adierazpena aztertuko da eta zatiketa-eskemaren arabera zein zati erabili behar diren kalkulatuko da. Horrek funtzionatzen du, baldin eta datuak zatiketa-eskema honen arabera zehatz-mehatz banatzen badira. Eskuz berrantolatu badituzu, baliteke korrespondentzia aldatzea.
Beraz, hau da lehen metodoa. Eta zure erantzunaren zain nago, metodoa egokia den ala aurrera goazen.
Vladimir Kolobaev, Avitoko sistemaren administratzaile nagusia: Alexey, aipatu duzun metodoak ez du oso ondo funtzionatzen karga zabaldu behar duzunean, irakurketa barne. Hilerokoa den eta aurreko hilabetea beste nodo batera eraman dezakeen partizio bat har dezakegu, baina datu hauen eskaera bat etortzen denean, bakarrik kargatuko dugu. Baina kluster osoa kargatu nahiko genuke, zeren eta, bestela, denbora batez irakurketa-karga osoa bi zatik prozesatu egingo baitute.
Alexey Milovidov: Hemen erantzuna bitxia da - bai, txarra da, baina baliteke funtzionatzea. Zehazki azalduko dut nola. Merezi du zure datuen atzean dagoen karga-egoera aztertzea. Hau jarraipena datuak bada, orduan ia ziur esan dezakegu eskaera gehienak datu freskoak direla.
Zerbitzari berriak instalatu dituzu, partizio zaharrak migratu dituzu, baina datu freskoak nola erregistratzen diren ere aldatu duzu. Eta datu freskoak kluster osoan zabalduko dira. Horrela, bost minutu besterik ez igaro ondoren, azken bost minutuetako eskaerek berdin kargatuko dute clusterra; egun baten ondoren, XNUMX orduko eskaerek berdin kargatuko dute clusterra. Eta aurreko hilabeteko eskaerak, zoritxarrez, kluster zerbitzarien zatietara bakarrik joango dira.
Baina askotan ez duzu eskaerarik izango 2019ko otsailerako. Seguruenik, eskaerak 2019an sartzen badira, 2019 osorako izango dira, denbora luzez, eta ez tarte txiki baterako. Eta horrelako eskaerak ere klusterra berdin kargatu ahal izango dute. Baina, oro har, zure oharra guztiz zuzena da, datuak guztiz uniformeki zabaltzen ez dituen ad hoc irtenbidea dela.
Galdera erantzuteko puntu batzuk gehiago ditut. Horietako bat hasieran zatiketa-eskema bat diseinatzeari buruzkoa da, berriro zatikatzeak min gutxiago eragin dezan. Hau ez da beti posible.
Adibidez, jarraipen datuak dituzu. Jarraipen datuak hazten ari dira hiru arrazoirengatik. Lehenengoa datu historikoen metaketa da. Bigarrena trafikoaren hazkundea da. Eta hirugarrena, jarraipenaren menpe dauden gauzen kopurua handitzea da. Badaude gorde beharreko mikrozerbitzu eta metrika berriak.
Baliteke hauen artean igoera handiena hirugarren arrazoiarekin lotzea: jarraipenaren erabilera areagotzea. Eta kasu honetan, merezi du kargaren izaera aztertzea, zeintzuk diren aukeratutako kontsulta nagusiak. Oinarrizko hautapen-kontsultak neurketa azpimultzo batzuetan oinarrituko dira ziurrenik.
Adibidez, zerbitzari batzuetan CPUren erabilera zerbitzu batzuek. Datu hauek lortzeko gakoen azpimultzo jakin bat dagoela ematen du. Eta datu hauen eskaera bera nahiko erraza da ziurrenik eta hamarnaka milisegundotan betetzen da. Zerbitzuak eta aginte-panelak kontrolatzeko erabiltzen da. Espero dut ondo ulertzea.
Vladimir Kolobaev: Kontua da askotan datu historikoetara jotzen dugula, egungo egoera historikoarekin alderatzen baitugu denbora errealean. Eta guretzat garrantzitsua da datu kopuru handietarako sarbide azkarra izatea, eta ClickHouse-k lan bikaina egiten du honekin.
Arrazoi osoa duzu, irakurketa eskaera gehienak azken egunean bizi ditugu, edozein monitorizazio sistema bezala. Baina, aldi berean, datu historikoen karga ere nahiko handia da. Funtsean, hogeita hamar segundoro ibiltzen den alerta sistema batetik dator eta ClickHouse-ri esaten dio: “Emaidazu azken sei asteetako datuak. Orain, eraiki iezadazu batez besteko mugikorren bat haietatik, eta konparatu dezagun egungo balioa historikoarekin».
Esan nahiko nuke, hain berritsu diren eskaerak egiteko beste taula txiki bat daukagula, bertan bi eguneko datuak soilik gordetzen ditugun eta eskaera nagusiak bertara hegan egiten direla. Kontsulta historiko handiak soilik bidaltzen ditugu zatitutako taula handira.
Alexey Milovidov: Zoritxarrez, gaizki aplikatzen da zure eszenatokirako, baina erabili behar ez diren baina nire lagunen zerbitzuan erabiltzen diren bi zatiketa-eskema txar eta konplexuen deskribapena esango dizut.
Yandex.Metrica ekitaldiekin kluster nagusi bat dago. Gertaerak orrialdeen bistak, klikak eta bihurketak dira. Eskaera gehienak webgune zehatz batera joaten dira. Yandex.Metrica zerbitzua irekitzen duzu, webgune bat duzu - avito.ru, joan txostenera eta zure webgunerako eskaera egiten da.
Baina badira beste eskaera batzuk –analitikoak eta globalak– barneko analistek egiten dituztenak. Badaezpada, ohartzen naiz barne analistek Yandex zerbitzuetarako soilik egiten dituztela eskaerak. Baina, hala ere, Yandex zerbitzuek ere datu guztien zati garrantzitsua hartzen dute. Hauek ez dira kontagailu zehatzetarako eskaerak, iragazketa zabalagoetarako baizik.
Nola antolatu datuak kontagailu bakarrerako dena eraginkortasunez funtziona dezan eta kontsulta globalak ere? Beste zailtasun bat da ClickHouse-n Metrics klusterraren eskaera kopurua segundoko hainbat milakoa dela. Aldi berean, ClickHouse zerbitzari batek ezin ditu hutsalak ez diren eskaerak kudeatu, adibidez, hainbat mila segundoko.
Klusterren tamaina seiehun bat zerbitzari da. Besterik gabe, Banatutako taula bat kluster honen gainean tiratzen baduzu eta hara milaka eskaera bidaltzen badituzu, zerbitzari batera bidaltzea baino are okerragoa izango da. Bestalde, datuak uniformeki zabaltzeko aukera, eta zerbitzari guztietatik eskatzera joan eta berehala baztertzen da.
Diametralki kontrakoa den aukera bat dago. Imajinatu datuak gune guztietan zatikatzen baditugu eta gune baten eskaera zati batera joaten bada. Orain klusterrak hamar mila eskaera kudeatu ahal izango ditu segundoko, baina zati batean edozein eskaera motelegi funtzionatuko du. Jada ez da eskalatuko errendimenduaren arabera. Batez ere hau avito.ru gunea bada. Ez dut sekretua azalduko Avito RuNet-eko gunerik bisitatuenetako bat dela esaten badut. Eta zati batean prozesatzea eromena litzateke.
Hori dela eta, sharding eskema modu maltzurrean diseinatuta dago. Kluster osoa geruza deitzen diogun multzo batzuetan banatuta dago. Kluster bakoitzak dozena batetik dozena bat zati ditu. Hogeita hemeretzi multzo daude guztira.
Nola eskalatzen da hau guztia? Kluster kopurua ez da aldatzen —duela urte batzuk hogeita hemeretzi zen bezala, hala izaten jarraitzen du—. Baina horietako bakoitzaren barruan, pixkanaka zati kopurua handitzen joango gara datuak pilatzen ditugun heinean. Eta sharding-eskema oro har honelakoa da: kluster hauek webguneetan banatuta daude, eta zein webgunetan dagoen zein kluster ulertzeko, MySQL-en metabase bereizia erabiltzen da. Gune bat - kluster batean. Eta bere barruan, sharding bisitarien IDen arabera gertatzen da.
Grabatzerakoan, bisitariaren IDaren zatiketaren gainerakoarekin zatitzen ditugu. Baina zati berri bat gehitzean, zatiketa eskema aldatzen da; zatitzen jarraitzen dugu, baina zatiketaren hondarra beste zenbaki batekin. Horrek esan nahi du bisitari bat dagoeneko hainbat zerbitzaritan kokatuta dagoela eta ezin zarela horretan fidatu. Datuak hobeto konprimituta daudela ziurtatzeko soilik egiten da. Eta eskaerak egiterakoan, Banatutako taulara joaten gara, klusterra begiratzen duena eta dozenaka zerbitzarietara sartzen diren. Hau eskema ergel bat da.
Baina nire istorioa osatugabea izango da eskema hori alde batera utzi genuela esaten ez badut. Eskema berrian, dena aldatu dugu eta datu guztiak kopiatu ditugu clickhouse-copier erabiliz.
Eskema berrian, gune guztiak bi kategoriatan banatzen dira: handiak eta txikiak. Ez dakit nola aukeratu zen atalasea, baina emaitza izan zen gune handiak kluster batean erregistratzen direla, non 120 zati dauden hiru erreplikak, hau da, 360 zerbitzariak. Eta zatiketa-eskema halakoa da edozein eskaera zati guztietara aldi berean doazela. Orain Yandex.Metrica-n avito.ru-ren edozein txosten orri irekitzen baduzu, eskaera 120 zerbitzarietara joango da. RuNet-en gune handi gutxi daude. Eta eskaerak ez dira mila segundoko, ehun baino gutxiago baizik. Hori guztia lasai murtxikatzen du Banatutako taulak, bakoitzak 120 zerbitzarirekin prozesatzen duen.
Eta bigarren multzoa gune txikietarako da. Hona hemen gunearen IDan oinarritutako zatiketa-eskema bat, eta eskaera bakoitza zati batera doa.
ClickHouse-k clickhouse-kopiagailuaren erabilgarritasuna du. Berari buruz esan al diguzu?
Berehala esango dut irtenbide hau astunagoa eta zertxobait gutxiago produktiboa dela. Abantaila da datuak guztiz zikintzen dituela zuk zehaztutako ereduaren arabera. Baina erabilgarritasunaren eragozpena da ez duela batere birziklatzen. Kluster-eskema batetik datuak kopiatzen ditu beste kluster-eskema batera.
Horrek esan nahi du funtziona dezan bi kluster izan behar dituzula. Zerbitzari berdinetan egon daitezke, baina, hala ere, datuak ez dira inkrementalki mugituko, kopiatu baizik.
Esaterako, lau zerbitzari zeuden, orain zortzi. Banatutako taula berri bat sortzen duzu zerbitzari guztietan, tokiko taula berrietan eta clickhouse-copier abiarazten duzu, hortik irakurri behar duen lan-eskema adieraziz, sharding-eskema berria onartu eta datuak hara transferitzeko. Eta zerbitzari zaharretan orain dagoena baino bide bat eta erdi gehiago beharko duzu, datu zaharrak haien gainean geratu behar direlako, eta datu zahar berdinen erdia haien gainean iritsiko baita. Datuak birpartitu behar direla eta lekua dagoela uste bazenuen, metodo hau egokia da.
Nola funtzionatzen du clickhouse-copier barruan? Lan guztia zati batean taula bateko partizio bat prozesatzeko zeregin multzo batean banatzen du. Zeregin horiek guztiak paraleloan exekutatu daitezke, eta clickhouse-copier makina ezberdinetan exekutatu daiteke hainbat instantziatan, baina partizio baterako egiten duena txertatze hautaketa bat baino ez da. Datuak irakurri, deskonprimitu, birpartizionatu, gero berriro konprimitu, nonbait idatzi eta berriro ordenatzen dira. Hau erabaki gogorragoa da.
Resharding izeneko gauza pilotu bat izan zenuen. Zer berarekin?
2017an, resharding izeneko gauza pilotu bat izan zenuen. ClickHousen ere badago aukera bat. Ulertzen dudanez, ez zen aireratu. Esango al didazu zergatik gertatu den hau? Oso garrantzitsua dirudi.
Arazo osoa da datuak lekuan birbidaltzea beharrezkoa bada, sinkronizazio oso konplexua behar dela atomikoki hori egiteko. Sinkronizazio honek nola funtzionatzen duen aztertzen hasi ginenean, oinarrizko arazoak zeudela argi geratu zen. Eta oinarrizko arazo hauek ez dira teorikoak bakarrik, baizik eta berehala praktikan erakusten hasi ziren oso sinpleki azal daitekeen zerbaiten moduan - ezer ez dabil.
Posible al da datu guztiak bateratzea disko moteletara eraman aurretik?
TTL-ri buruzko galdera, disko motelura aukerarekin bateratzeen testuinguruan. Ba al dago modurik, cron bidez ez den, zati guztiak bakar batean batzeko, disko moteletara eraman aurretik?
Galderaren erantzuna da posible dela nolabait automatikoki pieza guztiak bakar batean itsatsi transferitu aurretik - ez. Ez dut uste hau beharrezkoa denik. Ez duzu zati guztiak bateratu behar, baizik eta automatikoki disko geldoetara transferituko direla konturatu.
Bi irizpide ditugu transferentzia-arauetarako. Lehenengoa bete bezala dago. Uneko biltegiratze mailak espazio librearen ehuneko jakin bat baino gutxiago badu, zati bat hautatzen dugu eta biltegiratze motelagora eramango dugu. Edo hobeto esanda, ez motelago, hurrengoa baizik - konfiguratzen duzun bezala.
Bigarren irizpidea tamaina da. Pieza handiak mugitzea da. Atalasea disko azkarreko espazio librearen arabera doitu dezakezu eta datuak automatikoki transferituko dira.
Nola migratu ClickHouse-ren bertsio berrietara aldez aurretik bateragarritasuna egiaztatzeko modurik ez badago?
Gai hau aldizka eztabaidatzen da bertsio ezberdinak kontuan hartuta, eta oraindik. Zein da segurua 19.11 bertsiotik 19.16ra eta, adibidez, 19.16tik 20.3ra eguneratzea. Zein da bertsio berrietara migratzeko modurik onena sandbox-en bateragarritasuna aldez aurretik egiaztatu gabe?
Hainbat "urrezko" arau daude hemen. Lehenengoa - . Handia da, baina atzetik bateraezinak diren aldaketei buruzko paragrafo bereiziak daude. Ez tratatu puntu hauek bandera gorri gisa. Hauek normalean bateraezintasun txikiak izan ohi dira, seguru asko erabiltzen ez dituzun ertz-funtzionalitate batzuk inplikatzen dutenak.
Bigarrenik, sandbox-en bateragarritasuna egiaztatzeko modurik ez badago eta produkzioan berehala eguneratu nahi baduzu, gomendioa hau ez duzula egin behar da. Lehenik eta behin, sortu sandbox bat eta probatu. Proba-ingurunerik ez badago, ziurrenik ez duzu enpresa handirik izango, hau da, datu batzuk zure ordenagailu eramangarrira kopiatu ditzakezu eta ziurtatu dena behar bezala funtzionatzen duela. Hainbat erreplika ere igo ditzakezu lokalean zure makinan. Edo gertuko bertsio berri bat har dezakezu eta bertan datu batzuk karga ditzakezu, hau da, proba ingurune inprobisatu bat sortu.
Beste arau bat bertsioa kaleratu ondoren astebetez ez eguneratzea da, ekoizpenean akatsak atzemateko eta ondorengo konponketa azkarrak direla eta. Azter dezagun ClickHouse-ren bertsioen zenbaketa, ez nahasteko.
20.3.4 bertsioa dago. 20 zenbakiak fabrikazio urtea adierazten du - 2020. Barruan dagoenaren ikuspuntutik, horrek ez du axola, beraz, ez diogu kasurik egingo. Hurrengoa - 20.3. Bigarren zenbakia handitzen dugu, kasu honetan 3, funtzionalitate berriren bat duen bertsio bat kaleratzen dugun bakoitzean. ClickHouse-ri eginbideren bat gehitu nahi badiogu, kopuru hori handitu behar dugu. Hau da, 20.4 bertsioan ClickHouse-k are hobeto funtzionatuko du. Hirugarren zifra 20.3.4 da. Hona hemen 4 adabakien bertsio kopurua, zeinetan ezaugarri berriak gehitu ez ditugun, baina akats batzuk konpondu ditugu. Eta 4 esan nahi du lau aldiz egin dugula.
Ez pentsa hau zerbait ikaragarria denik. Normalean, erabiltzaileak azken bertsioa instalatu dezake eta urteko funtzionamenduarekin arazorik gabe funtzionatuko du. Baina imajinatu bit-mapak prozesatzeko funtzio batzuetan, gure kide txinatarrek gehitutakoa, zerbitzaria huts egiten duela argumentu okerrak pasatzen dituenean. Hau konpontzeko ardura dugu. Adabaki bertsio berria kaleratuko dugu eta ClickHouse egonkorragoa izango da.
ClickHouse produkzioan exekutatzen baduzu eta ClickHouse-ren bertsio berri bat funtzio gehigarriekin ateratzen bada (adibidez, 20.4.1 lehenengoa da, ez izan presarik lehen egunean produkzioan jartzera). Zergatik behar da ere? ClickHouse erabiltzen ez baduzu, instalatu dezakezu eta ziurrenik dena ondo egongo da. Baina ClickHouse dagoeneko egonkor funtzionatzen ari bada, begiratu adabakiak eta eguneratzeak zein arazo konpontzen ari garen ikusteko.
Kirill Shvakov: Proba-inguruneei buruzko apur bat gehitu nahiko nuke. Guztiek beldur handia diote proba-inguruneei eta arrazoiren batengatik uste dute ClickHouse kluster oso handia baduzu, proba-inguruneak ez lukeela gutxiago edo gutxienez hamar aldiz txikiagoa izan behar. Ez da batere horrela.
Nire adibidetik esan dezaket. Proiektu bat daukat, eta ClickHouse dago. Gure proba-ingurunea berarentzat besterik ez da: Hetzner-en hogei euroren truke dagoen makina birtual txiki bat da, non erabat dena zabaltzen den. Horretarako, automatizazio osoa dugu Ansible-n, eta, beraz, printzipioz, ez du alderik nora joan: hardware zerbitzarietara edo makina birtualetan zabaltzea besterik ez.
Zer egin daiteke? Polita litzateke ClickHouse dokumentazioan adibide bat ematea zure etxean kluster txiki bat nola zabaldu - Docker-en, LXC-n, agian Ansible playbook bat sortzea, pertsona ezberdinek inplementazio desberdinak dituztelako. Horrek asko erraztuko du. Bost minututan kluster bat hartu eta zabaltzen duzunean, askoz errazagoa da zerbait asmatzen saiatzea. Hau askoz erosoagoa da, probatu ez duzun produkzio-bertsio batean sartzea ezerezerako bidea delako. Batzuetan funtzionatzen du eta besteetan ez. Eta horregatik, arrakastaren itxaropena txarra da.
Maxim Kotyakov, Avito backend ingeniari seniorra: Proba-inguruneei buruzko apur bat gehituko dut enpresa handiek dituzten arazo batzuetatik. ClickHouse onarpen-kluster osoa dugu; datu-eskemei eta ezarpenei dagokienez, ekoizpenean dagoenaren kopia zehatza da. Kluster hau nahiko gutxietsitako edukiontzietan zabaltzen da gutxieneko baliabideekin. Ekoizpen datuen ehuneko jakin bat idazten dugu bertan, zorionez Kafkan korrontea errepikatzea posible da. Bertan dena sinkronizatuta eta eskalatuta dago, bai ahalmenari eta fluxuari dagokionez, bai, teorian, gainerako gauza guztiak berdinak izanik, metrika aldetik ekoizpenaren antzera jokatu beharko luke. Lehergarria izan daitekeen guztia stand honetara botatzen da lehenik eta hainbat egunez bertan uzten da prest arte. Baina, jakina, irtenbide hau garestia, zaila da eta laguntza-kostuak ez-zero ditu.
Alexey Milovidov: Yandex.Metricako gure lagunen proba-ingurunea nolakoa den esango dizut. Kluster batek 600 bakoiti zerbitzari zituen, beste batek 360 zituen, eta hirugarren bat eta hainbat kluster daude. Horietako baten proba-ingurunea bakoitzean bi erreplika dituzten bi zati besterik ez dira. Zergatik bi zati? Bakarrik ez egoteko. Eta erreplikak ere egon beharko lirateke. Ordaindu dezakezun gutxieneko kopuru bat besterik ez.
Proba-ingurune honek zure kontsultak funtzionatzen ari ote diren eta zerbait garrantzitsu apurtuta dagoen egiaztatzeko aukera ematen dizu. Baina askotan arazoak guztiz bestelako izaerakoak sortzen dira, dena funtzionatzen duenean, baina kargan aldaketa txiki batzuk daude.
Adibide bat jartzen dizut. ClickHouse-ren bertsio berri bat instalatzea erabaki genuen. Proba-ingurunean argitaratu da, proba automatizatuak burutu dira Yandex.Metrican bertan, bertsio zaharraren eta berriaren datuak konparatzen dituztenak, kanalizazio osoa martxan jarriz. Eta noski, gure CIren proba berdeak. Bestela ez genuke bertsio hau proposatu ere egingo.
Dena ondo dago. Ekoizpenera pasatzen hasiak gara. Mezu bat jasotzen dut grafikoen karga hainbat aldiz handitu dela. Bertsioa atzera botatzen ari gara. Grafikoa begiratu eta ikusten dut: karga benetan handitu egin zen hainbat aldiz zabaltzean, eta atzera egin zuen zabaltzean. Ondoren, bertsioa atzera botatzen hasi ginen. Eta karga era berean handitu eta atzera erori zen modu berean. Beraz, ondorioa hau da: karga handitu egin da diseinuaren ondorioz, ez da harritzekoa.
Orduan zaila zen lankideak konbentzitzea bertsio berria instalatzeko. Nik esaten diot: “Ongi dago, atera. Mantendu behatzak gurutzatuta, dena funtzionatuko du. Orain grafikoen karga handitu egin da, baina dena ondo dago. Eskatu hor". Oro har, hau egin genuen, eta kitto - bertsioa ekoizpenerako kaleratu zen. Baina ia diseinu guztietan antzeko arazoak sortzen dira.
Kill query-k kontsultak hil behar ditu, baina ez du. Zergatik?
Erabiltzaile bat, analista moduko bat, etorri zitzaidan eta nire ClickHouse klusterra jarri zuen eskaera sortu zuen. Nodoren bat edo kluster osoa, eskaera zein erreplika edo zatiren arabera joan den. Zerbitzari honetako CPU baliabide guztiak apal batean daudela ikusten dut, dena gorria da. Aldi berean, ClickHousek berak erantzuten die eskaerei. Eta idazten dut: "Mesedez, erakutsi iezadazu, prozesu zerrenda, zer eskaerak sortu duen eromen hori".
Eskaera hau aurkitzen dut eta kill idazten diot. Eta ikusten dut ez dela ezer gertatzen. Nire zerbitzaria apal batean dago, ClickHousek komando batzuk ematen dizkit, zerbitzaria bizirik dagoela erakusten du eta dena bikaina da. Baina degradazioa dut erabiltzaileen eskaera guztietan, degradazioa ClickHouse-ko erregistroekin hasten da eta nire hiltze-kontsultak ez du funtzionatzen. Zergatik? Hilketa kontsultak kontsultak hil behar zituela uste nuen, baina ez da horrela.
Orain erantzun arraro samarra izango da. Kontua da hilketa kontsultak ez dituela kontsultak hiltzen.
Kill query "Kontsulta hau hiltzea nahi dut" izeneko laukitxo bat markatzen du. Eta eskaerak berak bandera honi begiratzen dio bloke bakoitza prozesatzen duenean. Ezarrita badago, eskaerak funtzionatzeari uzten dio. Gertatzen da inork ez duela eskaera hiltzen, berak dena egiaztatu eta gelditu behar du. Eta honek funtzionatu beharko luke eskaera datu-blokeak prozesatzeko egoeran dagoen kasu guztietan. Hurrengo datu-blokea prozesatu, bandera egiaztatu eta geldituko da.
Horrek ez du funtzionatzen eskaera eragiketa batean blokeatuta dagoen kasuetan. Egia da, ziurrenik hori ez da zure kasua, zure ustez zerbitzari baliabide pila bat erabiltzen dituelako. Baliteke honek kanpoko sailkapenaren kasuan eta beste xehetasun batzuetan ez funtzionatzea. Baina, oro har, hau ez litzateke gertatu behar, akats bat da. Eta gomenda dezakedan gauza bakarra ClickHouse eguneratzea da.
Nola kalkulatu erantzun-denbora irakurketa-kargapean?
Elementu agregatuak gordetzen dituen taula bat dago: hainbat kontagailu. Linea kopurua ehun milioikoa da gutxi gorabehera. Posible al da aurreikus daitekeen erantzun denborarekin kontatzea 1K RPS botatzen badituzu 1K elementuetarako?
Testuinguruaren arabera, irakurketa-kargari buruz ari gara, idazteko arazorik ez dagoelako -mila, ehun mila ere, eta batzuetan milioi bat errenkada txerta daitezke-.
Irakurketa eskaerak oso desberdinak dira. 1. hautatzean, ClickHousek hamarnaka mila eskaera egin ditzake segundoko, beraz, gako baten eskaerak ere baliabide batzuk beharko ditu dagoeneko. Eta horrelako puntu-kontsultak gako-balioen datu-base batzuetan baino zailagoak izango dira, irakurketa bakoitzeko datu-bloke bat indizeka irakurtzea beharrezkoa delako. Gure indizeak ez ditu erregistro bakoitzari zuzentzen, barruti bakoitzari baizik. Hau da, barruti osoa irakurri beharko duzu - 8192 lerro dira lehenespenez. Eta konprimitutako datu-blokea 64 KB-tik 1 MB-ra deskonprimitu beharko duzu. Normalean, zuzendutako kontsultak milisegundo batzuk behar izaten dituzte osatzeko. Baina hau da aukerarik errazena.
Saia gaitezen aritmetika sinple batzuk. Milisegundo batzuk milaz biderkatzen badituzu, segundo batzuk lortuko dituzu. Segundoko mila eskaerarekin jarraitzea ezinezkoa izango balitz bezala, baina egia esan posible da, hainbat prozesadore nukleo ditugulako. Beraz, printzipioz, ClickHousek batzuetan 1000 RPS eduki ditzake, baina eskaera laburretarako, bereziki zuzendutakoetarako.
ClickHouse kluster bat eskaera sinpleen kopuruaren arabera eskalatu behar baduzu, orduan gauzarik errazena gomendatzen dizut: erreplika kopurua handitu eta eskaerak ausazko erreplika batera bidali. Erreplika batek segundoko bostehun eskaera jasotzen baditu, guztiz errealista dena, hiru erreplikek mila eta erdi kudeatuko dituzte.
Batzuetan, noski, ClickHouse konfigura dezakezu puntuen irakurketa gehienerako. Zer behar da horretarako? Lehenengoa indizearen granulartasuna murriztea da. Kasu honetan, ez da bakarrera murriztu behar, indizearen sarrera kopurua zerbitzari bakoitzeko hainbat milioi edo hamarnaka milioikoa izango dela oinarritzat hartuta baizik. Taulak ehun milioi errenkada baditu, granulartasuna 64an ezarri daiteke.
Bloke konprimituaren tamaina murriztu dezakezu. Horretarako ezarpenak daude konprimitzeko blokearen tamaina minimoa, konprimitze blokearen gehienezko tamaina. Murriztu egin daitezke, datuz bete eta gero zuzendutako kontsultak azkarragoak izango dira. Hala ere, ClickHouse ez da gako-balioen datu-base bat. Eskaera txiki kopuru handi bat kargaren aurkako eredua da.
Kirill Shvakov: Aholkuak emango ditut bertan kontu arruntak egonez gero. Egoera nahiko estandarra da ClickHouse-k kontagailu motaren bat gordetzen duenean. Erabiltzaile bat daukat, halako herrialde batekoa da, eta hirugarren eremuren bat, eta pixkanaka zerbait handitu behar dut. Hartu MySQL, egin gako bakarra - MySQL-n gako bikoiztua da, eta PostgreSQL-n gatazka bat da- eta gehitu plus ikurra. Horrek askoz hobeto funtzionatuko du.
Datu asko ez dituzunean, ez du ezertarako balio ClickHouse erabiltzeak. Ohiko datu-baseak daude eta ondo egiten dute.
Zer moldatu dezaket ClickHousen datu gehiago cachean egon daitezen?
Imajina dezagun egoera bat - zerbitzariek 256 GB RAM dituzte, ClickHousek egunerokotasunean 60-80 GB inguru hartzen ditu, gailurrean - 130 arte. Zer gaitu eta doi daiteke datu gehiago cachean egon daitezen eta, horren arabera, bidai gutxiago daude diskora?
Normalean, sistema eragilearen orriaren cacheak lan ona egiten du. Goialdea ireki besterik ez baduzu, begiratu han cachean edo librean - cachean zenbat dagoen ere esaten du - orduan ohartuko zara memoria libre guztia cacherako erabiltzen dela. Eta datu hauek irakurtzean, ez dira diskotik irakurriko, RAMetik baizik. Aldi berean, esan dezaket cachea modu eraginkorrean erabiltzen dela, konprimitutako datuak direlako cachean gordetzen dena.
Hala ere, kontsulta sinple batzuk are gehiago bizkortu nahi badituzu, deskonprimitutako datuetan cache bat gaitu dezakezu ClickHouse barruan. Deitzen da konprimitu gabeko cachea. Config.xml konfigurazio fitxategian, ezarri konprimitu gabeko cachearen tamaina behar duzun balioarekin - Doako RAMaren erdia baino ez gomendatzen dut, gainerakoa orrialdeko cachearen azpian egongo delako.
Horrez gain, eskaera-maila bi ezarpen daude. Lehen ezarpena - erabili konprimitu gabeko cachea - bere erabilera barne hartzen du. Eskaera guztietarako gaitzea gomendatzen da, astunetarako izan ezik, datu guztiak irakurri eta cachea hustu ditzaketenak. Eta bigarren ezarpena cachea erabiltzeko gehienezko lerro kopurua bezalako zerbait da. Kontsulta handiak automatikoki mugatzen ditu, cachea saihestu dezaten.
Nola konfigura dezaket memoria_konfigurazioa RAM biltegiratzeko?
ClickHouse dokumentazio berrian erlazionatutako atala irakurri dut . Deskribapenak SSD azkarra duen adibide bat dauka.
Galdetzen dut nola konfigura daitekeen gauza bera bolumenaren memoria beroarekin. Eta galdera bat gehiago. Nola funtzionatzen du select datu-antolaketa honekin, multzo osoa irakurriko du edo diskoan dagoena bakarrik, eta datu hauek memorian konprimituta al daude? Eta nola funtzionatzen du prewhere atalak halako datu-antolaketa batekin?
Ezarpen honek datu zatien biltegian eragiten du, eta haien formatua ez da inola ere aldatzen.
Ikus dezagun hurbilagotik.
Datuen biltegiratzea RAMan konfigura dezakezu. Diskorako konfiguratuta dagoen guztia bere bidea da. Tmpfs partizio bat sortzen duzu fitxategi-sistemako bideren batean muntatuta dagoena. Bide hau zehazten duzu partiziorik beroenaren datuak gordetzeko bide gisa, datu zatiak iristen hasten dira eta bertan idazten dira, dena ondo dago.
Baina ez dut gomendatzen hau egitea fidagarritasun txikia delako, nahiz eta datu-zentro desberdinetan gutxienez hiru erreplika badituzu, posible da. Zerbait gertatzen bada, datuak leheneratu egingo dira. Imajina dezagun zerbitzaria bat-batean itzali eta berriro piztu zela. Banaketa berriro muntatu zen, baina ez zegoen ezer. ClickHouse zerbitzaria hasten denean, pieza horiek ez dituela ikusten du, nahiz eta, ZooKeeper-en metadatuen arabera, hor egon beharko luketen. Zein erreplik dituzten aztertu, eskatu eta deskargatu egiten ditu. Horrela datuak berreskuratuko dira.
Zentzu honetan, datuak RAM-en gordetzea ez da funtsean ezberdina diskoan gordetzearekin, zeren datuak diskoan idazten direnean, lehenik ere orrialdeko cachean amaitzen dira eta fisikoki geroago idazten dira. Hau fitxategi-sistema muntatzeko aukeraren araberakoa da. Baina badaezpada, esango dut ClickHouse-k ez duela fsync egiten txertatzean.
Kasu honetan, RAM-eko datuak diskoan dauden formatu berean gordetzen dira. Hautatze-kontsultak modu berean hautatzen ditu irakurri behar diren piezak, beharrezko datu-barrutiak hautatzen ditu piezetan eta irakurtzen ditu. Eta prewhere-k berdin funtzionatzen du, datuak RAM edo diskoan zeuden kontuan hartu gabe.
Zenbat balio esklusiboraino da eraginkorra Kardinaltasun Baxua?
Kardinaltasun baxua ongi diseinatuta dago. Datu-hiztegiak biltzen ditu, baina tokikoak dira. Lehenik eta behin, hiztegi desberdinak daude pieza bakoitzerako, eta bigarrenik, pieza baten barruan ere desberdinak izan daitezke sorta bakoitzeko. Balio esklusiboen kopurua atalase-zenbaki batera iristen denean —milioi bat, nire ustez— hiztegia besterik gabe uzten da eta berri bat sortzen da.
Erantzuna orokorrean da: tokiko barruti bakoitzeko - esate baterako, egun bakoitzeko - nonbait milioi bat balio esklusibo Kardinaltasun baxua eraginkorra da. Ondoren, hutsune bat besterik ez da egingo, eta bertan hainbat hiztegi erabiliko dira, eta ez bakarra. Gutxi gorabehera, kate-zutabe arrunt baten berdina funtzionatuko du, agian apur bat eraginkorrago, baina ez da errendimenduaren hondatze larririk izango.
Zeintzuk dira bost mila milioi errenkada dituen taula batean testu osoa bilatzeko praktika onenak?
Erantzun desberdinak daude. Lehenengoa esan nahi du ClickHouse ez dela testu osoko bilatzaile bat. Horretarako sistema bereziak daude, adibidez, и . Hala ere, gero eta gehiago ikusten dut Elasticsearch-tik ClickHousera aldatzen ari dela esaten.
Zergatik gertatzen da hau? Hori azaltzen dute Elasticsearch-ek bolumen batzuetan kargari aurre egiteari uzten diola indizeen eraikuntzatik hasita. Indizeak astunegiak bihurtzen dira, eta datuak ClickHousera transferitzen badituzu, bolumenari dagokionez, hainbat aldiz eraginkorrago gordetzen dira. Aldi berean, bilaketa-kontsultak ez ziren askotan datu-bolumen osoan esaldiren bat aurkitzea beharrezkoa zen, morfologia kontuan hartuta, guztiz desberdinak baizik. Adibidez, aurkitu azken orduetako erregistroetan byte-segida batzuk.
Kasu honetan, aurkibide bat sortzen duzu ClickHouse-n, eta horren lehenengo eremua data eta ordua izango dira. Eta datuen ebaketa handiena data tartean oinarrituta egongo da. Hautatutako data-tartearen barruan, oro har, dagoeneko posible da testu osoko bilaketa bat egitea, nahiz eta indar gordinaren metodoa erabili antzekoa erabiliz. ClickHouse-ko antzeko operadorea aurki dezakezun antzeko operadorea da. Zerbait hoberik aurkitzen baduzu, esaidazu.
Baina hala ere, eskaneatu osoa bezala. Eta eskaneatu osoa motela izan daiteke CPUan ez ezik, diskoan ere. Bat-batean egunean terabyte bat datuak badituzu eta egunean zehar hitz bat bilatzen baduzu, orduan terabyte-a eskaneatu beharko duzu. Eta ziurrenik ohiko disko gogorretan dago, eta azkenean kargatuko dira zerbitzari honetara SSH bidez sartu ahal izango ez zaren moduan.
Kasu honetan, beste trikimailu txiki bat eskaintzeko prest nago. Esperimentala da, baliteke funtzionatzea, agian ez. ClickHouse-k testu osoko indizeak ditu trigrama Bloom iragazki moduan. Arenadatako gure lankideek dagoeneko probatu dituzte indize hauek, eta askotan nahi bezala funtzionatzen dute.
Behar bezala erabiltzeko, ondo ulertu behar duzu nola funtzionatzen duten: zer den trigrama Bloom iragazkia eta nola aukeratu bere tamaina. Esan dezaket esaldi arraro batzuei buruzko kontsultak egiteko lagunduko dutela, datuetan gutxitan aurkitzen diren azpikateak. Kasu honetan, azpibarrutiak indizeen bidez hautatuko dira eta datu gutxiago irakurriko dira.
Duela gutxi, ClickHousek testu osoko bilaketarako funtzio aurreratuagoak gehitu ditu. Lehenik eta behin, pasarte batean azpikate mordo bat bilatzea da, maiuskulak eta minuskulak bereizten dituzten aukerak barne, UTF-8rako laguntzarekin edo ASCIIrako soilik. Aukeratu behar duzun eraginkorrena.
Adierazpen erregular anitz bilaketa pase bakarrean ere agertu da. Ez duzu X azpikate bat bezala idatzi behar edo X beste azpikate bat bezala. Berehala idazten duzu, eta dena ahalik eta eraginkorren egiten da.
Hirugarrenik, orain adierazpen erregularentzako gutxi gorabeherako bilaketa bat dago eta azpikateen gutxi gorabeherako bilaketa bat. Norbaitek hitz bat gaizki idatzi badu, gehieneko bat etortzea bilatuko da.
Zein da erabiltzaile askorentzat ClickHouserako sarbidea antolatzeko modurik onena?
Esan iezaguzu kontsumitzaile eta analista ugarientzako sarbidea nola antolatzeko onena. Nola osatu ilara bat, lehenetsi gehienez aldibereko kontsultak eta zein tresnarekin?
Klusterra nahikoa handia bada, irtenbide ona izango litzateke beste bi zerbitzari planteatzea, analisten sarrera puntu bihurtuko direnak. Hau da, ez utzi analistei klusterreko zati zehatzetara sartzeko, baizik eta bi zerbitzari huts sortu, daturik gabe, eta haietan sarbide-eskubideak konfiguratu. Kasu honetan, banatutako eskaeren erabiltzaileen ezarpenak urruneko zerbitzarietara transferitzen dira. Hau da, bi zerbitzari hauetan dena konfiguratzen duzu, eta ezarpenek kluster osoan eragina dute.
Printzipioz, zerbitzari hauek ez dute daturik, baina RAM kopurua oso garrantzitsua da eskaerak exekutatzeko. Diskoa aldi baterako datuetarako ere erabil daiteke kanpoko agregazioa edo kanpoko ordenamendua gaituta badago.
Garrantzitsua da muga posible guztiekin lotuta dauden ezarpenak aztertzea. Orain analista gisa Yandex.Metrica klusterera joaten banaiz eta eskaera bat egiten badut hautatu hits kopurua, orduan berehala emango didate eskaera exekutatu ezin dudan salbuespen bat. Eskaneatzeko baimena daukadan gehienezko errenkada kopurua ehun mila milioi da, eta guztira berrogeita hamar bilioi daude multzoko taula batean. Hau da lehen muga.
Demagun errenkadaren muga kentzen dudala eta berriro exekutatzen dudala kontsulta. Ondoren, hurrengo salbuespena ikusiko dut: ezarpena gaituta indar-indizea dataren arabera. Ezin dut kontsulta osatu data-tarterik zehaztu ez badut. Ez duzu analistengan fidatu behar eskuz zehazteko. Kasu tipiko bat da data-tartea idazten denean aste arteko gertaera data. Eta, ondoren, parentesi bat besterik ez zuten zehaztu leku okerrean, eta horren ordez eta edo - edo URL bat-etortzea izan zen. Mugarik ez badago, URL zutabea arakatuko du eta baliabide asko alferrik galduko ditu.
Gainera, ClickHousek lehentasunezko bi ezarpen ditu. Zoritxarrez, oso primitiboak dira. Bat besterik ez da deitzen lehentasuna. Lehentasuna ≠ 0 eta lehentasunen bat duten eskaerak exekutatzen ari badira, baina lehentasun-balioa baino txikiagoa duen eskaera bat exekutatzen bada, hau da, lehentasun handiagoa duena, orduan lehentasun-balio handiagoa duen eskaera bat, eta horrek lehentasun txikiagoa esan nahi du. , bertan behera geratzen da eta ez du funtzionatuko denbora horretan.
Hau oso ezarpen gordina da eta ez da egokia klusterrak karga konstantea duen kasuetarako. Baina garrantzitsuak diren eskaera laburrak eta lehertuak badituzu eta klusterra gehienetan inaktibo badago, konfigurazio hau egokia da.
Hurrengo lehentasun ezarpenari deitzen zaio OS hariaren lehentasuna. Besterik gabe, balio polita ezartzen du eskaera exekutatzeko hari guztientzat Linux programatzailearentzat. Horrela funtzionatzen du, baina oraindik ere funtzionatzen du. Gutxieneko balio polita ezartzen baduzu -baliorik handiena da, eta, beraz, lehentasun baxuena- eta -19 ezartzen baduzu lehentasun handiko eskaeretarako, orduan PUZak lehentasun baxuko eskaerak lehentasun handikoak baino lau aldiz gutxiago kontsumituko ditu.
Eskaera exekutatzeko gehienezko denbora ere konfiguratu behar duzu, esate baterako, bost minutu. Kontsulten exekuzio abiadura minimoa da gauzarik politena. Ezarpen hau aspalditik dago, eta ClickHouse moteltzen ez dela baieztatzea ez ezik, behartu egin behar da.
Imajinatu, konfiguratzen duzula: kontsulta batzuek segundoko milioi bat errenkada baino gutxiago prozesatzen badute, ezin duzu hori egin. Honek gure izen ona, gure datu-base ona, lotsatzen du. Debekatu dezagun hau. Egia esan, bi ezarpen daude. Bat deitzen da exekuzio abiadura minimoa - segundoko lerrotan, eta bigarrenari denbora-muga deitzen zaio exekuzio-abiadura minimoa egiaztatu aurretik - hamabost segundo lehenespenez. Hau da, hamabost segundo posible da, eta gero, motela bada, salbuespen bat bota eta eskaera bertan behera utzi.
Kuotak ere ezarri behar dituzu. ClickHousek baliabideen kontsumoa zenbatzen duen kuota eginbide integratua du. Baina, zoritxarrez, ez hardware baliabideak, hala nola CPU, diskoak, logikoak baizik - prozesatutako eskaerak, lerroak eta irakurritako byte kopurua. Eta, adibidez, bost minutuko epean gehienez ehun eskaera eta orduko mila eskaera konfigura ditzakezu.
Zergatik da garrantzitsua? Kontsulta analitiko batzuk eskuz egingo direlako ClickHouse bezerotik zuzenean. Eta dena ondo egongo da. Baina zure enpresan analista aurreratuak badituzu, gidoi bat idatziko dute, eta gidoian errore bat egon daiteke. Eta errore honek eskaera begizta infinitu batean exekutatuko du. Hau da gure burua babestu behar duguna.
Posible al da kontsulta baten emaitzak hamar bezerori ematea?
Hainbat erabiltzaile ditugu une berean eskaera handiekin etortzea gustatzen zaiena. Eskaera handia da eta, printzipioz, azkar gauzatzen da, baina aldi berean horrelako eskaera asko daudelako, oso mingarria bihurtzen da. Posible al da eskaera bera exekutatu, hamar aldiz jarraian iritsi dena, behin, eta emaitza hamar bezerori ematea?
Arazoa da ez ditugula tarteko datuen cachearen edo cachearen emaitzak. Sistema eragilearen orrialde-cache bat dago, eta horrek diskoko datuak berriro irakurtzea eragotziko du, baina, tamalez, datuak oraindik deskonprimitu, deserializatu eta birprozesatu egingo dira.
Hori nolabait saihestu nahiko nuke, tarteko datuak cachean sartuz, edo antzeko kontsultak ilara batean lerrokatuz eta emaitzen cache bat gehituz. Momentu honetan, eskaeraren cache bat gehitzen duen tira-eskaera bat dugu garapenean, baina sartu eta batzeko ataletako azpikontsultetarako soilik, hau da, irtenbidea osatu gabe dago.
Hala ere, horrelako egoera bati ere aurre egiten diogu. Adibide bereziki kanonikoa orrialdedun kontsultak dira. Txosten bat dago, hainbat orrialde ditu, eta 10. mugaren eskaera dago. Orduan gauza bera, baina 10,10 muga. Ondoren, beste orrialde bat. Eta galdera da, zergatik kontatzen dugu hori guztia aldiro? Baina orain ez dago irtenbiderik, eta ez dago saihesteko modurik.
ClickHouseren ondoan sidecar gisa jartzen den irtenbide alternatibo bat dago - .
Kirill Shvakov: ClickHouse Proxy-k tasa-mugatzailea eta emaitzen cachea ditu. Ezarpen asko egin ziren bertan, antzeko arazo bat konpontzen ari zelako. Proxy-k eskaerak ilaran jarrita mugatu eta eskaeraren cacheak zenbat iraungo duen konfiguratzeko aukera ematen du. Eskaerak benetan berdinak balira, Proxy-k askotan bidaliko ditu, baina behin bakarrik joango da ClickHousera.
Nginx-ek cache bat ere badu doako bertsioan, eta honek ere funtzionatuko du. Nginx-ek ezarpenak ere baditu eskaerak aldi berean iristen badira, beste batzuk motelduko dituela bat osatu arte. Baina ClickHouse Proxy-n konfigurazioa askoz hobeto egiten da. ClickHouserako berariaz egin zen, eskaera horietarako bereziki, beraz, egokiagoa da. Beno, erraza da instalatzen.
Zer gertatzen da eragiketa asinkronoekin eta ikuspegi materializatuekin?
Arazo bat dago erreprodukzio-motorrarekin eragiketak asinkronoak direla: lehenik datuak idazten dira, gero tolestu egiten dira. Agregatu batzuk dituen tableta materializatu bat zeinuaren azpian bizi bada, bikoiztuak idatziko zaizkio. Eta logika konplexurik ez badago, datuak bikoiztu egingo dira. Zer egin dezakezu horri buruz?
Ageriko irtenbide bat dago: matview-en klase jakin batean abiarazlea ezartzea kolapso asinkronoko eragiketa batean. Ba al dago antzeko funtzionalitateak ezartzeko zilarrezko balak edo planik?
Merezi du desduplicazioak nola funtzionatzen duen ulertzea. Orain esango dizudana ez da galderari dagokiona, baina badaezpada gogoratzea merezi du.
Erreplikatutako taula batean txertatzean, txertatutako bloke osoen desduplicazioa dago. Errenkada bereko kopuru bera duen bloke bera berriro txertatzen baduzu ordena berean, datuak desbikoiztu egingo dira. Txertatzeko erantzuteko "Ok" jasoko duzu, baina egia esan datu-pakete bat idatziko da, eta ez da bikoiztuko.
Hau beharrezkoa da ziurtasunerako. Txertatzean "Ok" jasotzen baduzu, zure datuak sartu dira. ClickHouse-ren errore bat jasotzen baduzu, esan nahi du ez direla txertatu eta txertaketa errepikatu behar duzula. Baina txertatzean konexioa hausten bada, orduan ez dakizu datuak sartu diren ala ez. Aukera bakarra txertaketa berriro errepikatzea da. Datuak benetan txertatu badira eta berriro txertatu badituzu, blokeen desduplicazioa dago. Hau beharrezkoa da bikoiztuak saihesteko.
Eta garrantzitsua da nola funtzionatzen duen ikuspegi materializatuetarako. Datuak taula nagusian txertatzean desbikoiztu egin badira, orduan ere ez dira materializatutako ikuspegian sartuko.
Orain galderari buruz. Zure egoera konplikatuagoa da, lerro indibidualen bikoiztuak grabatzen ari zarelako. Hau da, ez da pakete osoa bikoiztuta dagoena, lerro zehatzak baizik, eta atzealdean kolapsatzen dira. Izan ere, datuak taula nagusian tolestuko dira, baina tolestu gabeko datuak materializatutako ikuspegira joango dira, eta bateratzean ez da ezer gertatuko materializatutako ikuspegiekin. Ikuspegi materializatu bat txertatzeko abiarazlea baino ez baita. Beste eragiketetan, ez zaio ezer gehigarririk gertatzen.
Eta hemen ezin zaitut zoriontsu egin. Kasu honetarako irtenbide zehatz bat bilatu besterik ez duzu behar. Esate baterako, posible al da erreproduzitzea materializatutako ikuspegi batean, eta deduplicazio-metodoak modu berean funtziona dezake. Baina, zoritxarrez, ez beti. Agregatzen bada, ez du funtzionatuko.
Kirill Shvakov: Makuluen eraikuntza ere izan genuen garai hartan. Arazo bat izan da publizitate-inpresioak daudelako, eta denbora errealean erakutsi ditzakegun datu batzuk daude - inpresioak besterik ez dira. Gutxitan bikoiztu egiten dira, baina hori gertatzen bada, gero kolapsatu egingo ditugu hala ere. Eta bikoiztu ezin ziren gauzak zeuden: klikak eta istorio hau guztia. Baina ia berehala erakutsi nahi nituen ere.
Nola egin ziren materializatutako ikuspegiak? Zuzenean idatzitako ikuspegiak zeuden: datu gordinetan idatzita zegoen eta ikuspegietan idatzita zegoen. Bertan, noizbait datuak ez dira oso zuzenak, bikoiztu egiten dira, etab. Eta taularen bigarren zati bat dago, non ikuspegi materializatuen itxura berdina duten, hau da, egitura guztiz berdinak diren. Tarteka datuak berriro kalkulatzen ditugu, datuak bikoiztu gabe zenbatu, taula horietan idatzi.
APItik pasatu gara; honek ez du eskuz funtzionatuko ClickHousen. Eta APIak itxura du: taulan azken gehiketaren data dudanean, non bermatzen den datu zuzenak dagoeneko kalkulatu direla, eta eskaera bat egiten dion taula bati eta beste taula bati. Batetik eskaerak denbora jakin batera aukeratzen du, eta bestetik oraindik kalkulatu ez dena lortzen du. Eta funtzionatzen du, baina ez ClickHouse bidez bakarrik.
API motaren bat baduzu - analistarentzat, erabiltzaileentzat - orduan, printzipioz, hau aukera bat da. Beti kontatzen ari zara, beti kontatzen. Hau egunean behin edo beste momentu batean egin daiteke. Zuk zeuk aukeratzen duzu behar ez duzun eta kritikoa ez den sorta.
ClickHouse-k erregistro asko ditu. Nola ikus dezaket zerbitzariari gertatzen zaion guztia begirada batean?
ClickHouse-k erregistro desberdin asko ditu, eta kopuru hori gero eta handiagoa da. Bertsio berrietan, horietako batzuk lehenespenez ere gaituta daude; bertsio zaharretan aktibatu behar dira eguneratzean. Hala ere, gero eta gehiago daude. Azken finean, orain nire zerbitzariarekin zer gertatzen ari den ikusi nahiko nuke, agian laburpen-panel batean.
Badaukazu ClickHouse talderik, edo zure lagunen talderik, erregistro hauek amaitutako produktu gisa erakutsiko lituzkeen aginte-panelen funtzionalitate batzuk onartzen dituztenak? Azken finean, ClickHouse-n erregistroak ikustea bikaina da. Baina oso polita litzateke dagoeneko aginte-panel moduan prestatuta egongo balitz. Ostiko bat aterako nuke.
Aginte-panelak daude, normalizatuta ez dauden arren. Gure enpresan, 60 bat taldek erabiltzen dute ClickHouse, eta bitxiena da horietako askok beraiek egindako aginte-panelak dituztela, eta apur bat desberdinak. Talde batzuek Yandex.Cloud barneko instalazio bat erabiltzen dute. Badaude prest egindako txosten batzuk, nahiz eta beharrezkoak ez diren guztiak. Besteek berea dute.
Metricako nire lankideek beren aginte-panela dute Grafanan, eta nik neurea daukat euren klustererako. Serif cacherako cache hit bezalako gauzei begira ari naiz. Eta are zailagoa da tresna desberdinak erabiltzen ditugula. Nire panela Graphite-web izeneko tresna oso zaharra erabiliz sortu nuen. Erabat itsusia da. Eta oraindik ere horrela erabiltzen dut, nahiz eta ziurrenik Grafana erosoagoa eta ederragoa izango litzatekeen.
Arbelen oinarrizko gauza bera da. Hauek dira klusterraren sistema-neurriak: CPU, memoria, diskoa, sarea. Beste batzuk - aldibereko eskaera kopurua, aldibereko bateratze kopurua, segundoko eskaera kopurua, MergeTree taulako partizioetarako zati kopuru maximoa, erreplikazioaren atzerapena, erreplikazio-ilararen tamaina, segundoko txertatutako errenkada kopurua, segundoko txertatutako bloke kopurua. Hau da, ez erregistroetatik, metriketatik lortzen dena.
Vladimir Kolobaev: Alexey, pixka bat zuzendu nahiko nuke. Grafana dago. Grafanak datu-iturburu bat du, hau da, ClickHouse. Hau da, Grafanatik zuzenean egin ditzaket eskaerak ClickHouse-ra. ClickHouse-k erregistroekin taula bat dauka, denentzat berdina da. Ondorioz, Grafanako erregistro-taula honetara sartu eta nire zerbitzariak egiten dituen eskaerak ikusi nahi ditut. Oso ondo legoke horrelako aginte-panel bat edukitzea.
Nik neuk bizikletaz egin nuen. Baina galdera bat daukat: dena estandarizatuta badago eta Grafana denek erabiltzen badute, zergatik ez du Yandex-ek aginte-panel ofizialik?
Kirill Shvakov: Izan ere, ClickHouse-ra doan datu-iturburuak Altinity onartzen du orain. Eta bektore bat eman nahi dut non zulatu eta nori bultzatu. Galde diezaiekezu, Yandexek oraindik ClickHouse egiten duelako, eta ez inguruko istorioa. Altinity da ClickHouse sustatzen duen enpresa nagusia. Ez dute abandonatuko, baizik eta lagundu egingo diote. Izan ere, printzipioz, Grafana webgunera panel bat igotzeko, erregistratu eta igo besterik ez duzu egin behar - ez dago arazorik berezirik.
Alexey Milovidov: Azken urtean, ClickHousek kontsulta profilak egiteko gaitasun asko gehitu ditu. Baliabideen erabilerari buruzko eskaera bakoitzerako neurriak daude. Eta duela gutxi, maila baxuagoko kontsulten profilera gehitu dugu kontsulta batek milisegundo bakoitzean non gastatzen duen ikusteko. Baina funtzionalitate hau erabiltzeko, kontsola bezeroa ireki eta eskaera bat idatzi behar dut, beti ahazten dudana. Nonbait gorde dut eta non zehazki ahazten jarraitzen dut.
Gustatuko litzaidake tresna bat egotea esan berri duena, hona hemen zure kontsulta astunak, kontsulta-klaseen arabera sailkatuta. Bat sakatu nuen, eta horregatik astuna dela esango zidaten. Orain ez dago horrelako irtenbiderik. Eta benetan arraroa da jendeak galdetzen didanean: "Esadazu, ba al dago prest egindako aginte-panelrik Grafanarentzat?", nik esaten dudana: "Joan Grafana webgunera, "Arbelak" komunitate bat dago, eta aginte-panel bat dago. Dimka-tik, Kostyan-eko aginte-panela dago. Ez dakit zer den, ez dut neuk erabili».
Nola eragin konbinazioetan zerbitzaria OOM-ra erori ez dadin?
Taula bat daukat, taulan partizio bakarra dago, ReplacingMergeTree da. Lau urte daramatzat datuak idazten. Aldaketa bat egin behar nuen eta datu batzuk ezabatu.
Hau egin nuen, eta eskaera hau prozesatzean, klusterreko zerbitzari guztietako memoria guztia kontsumitu zen eta klusterreko zerbitzari guztiak OOM-ra sartu ziren. Orduan denak batera altxatu ziren, eragiketa hori bera, datu-bloke hau batzen hasi eta berriro OOM-ra erori ziren. Gero berriro altxatu eta berriro erori ziren. Eta gauza hau ez zen gelditu.
Orduan konturatu zen hau benetan mutilek konpondutako akats bat zela. Oso polita da hau, eskerrik asko. Baina hondakin bat geratu zen. Eta orain, taulan nolabaiteko batuketa egitea pentsatzen dudanean, galdera bat daukat: zergatik ezin dut nolabait eragin bateratze horietan? Adibidez, mugatu itzazu behar den RAM kopuruaren arabera, edo, printzipioz, taula jakin hau prozesatuko duen kopuruaren arabera.
"Metrikoak" izeneko taula bat daukat, mesedez prozesatu bi haritan. Ez dago paraleloan hamar edo bost batuketa sortu beharrik, egin bitan. Birentzat nahikoa memoria dudala uste dut, baina agian ez da nahikoa izango hamar prozesatzeko. Zergatik geratzen da beldurra? Taula hazten ari delako, eta noizbait, printzipioz jada akats baten ondorioz ez den egoera baten aurrean egongo naizelako, datuak hain kopuru handian aldatuko direlako baizik eta memoria nahikoa ez dudalako izango. zerbitzaria. Eta orduan zerbitzaria OOM-ra eroriko da bat egitean. Gainera, mutazioa bertan behera utzi dezaket, baina Merji ez dago jada.
Badakizu, bat egitean, zerbitzaria ez da OOM-n eroriko, bat egitean RAM kopurua datu sorta txiki baterako bakarrik erabiltzen baita. Beraz, dena ondo egongo da datu kopurua edozein dela ere.
Vladimir Kolobaev: Ederki. Hona hemen momentua, akatsa konpondu ondoren, bertsio berri bat deskargatu nuen niretzat, eta beste mahai batean, txikiago batean, partizio asko daudenean, antzeko eragiketa bat egin nuen. Eta bateratzean, 100 GB inguru RAM zerbitzarian erre ziren. 150 okupatu nituen, 100 jan eta 50 GBko leiho bat geratzen zitzaidan, beraz, ez nintzen OOMn erori.
Zerk babesten nau OOM-en erortzetik, benetan 100 GB RAM kontsumitzen baditu? Zer egin bat-batean bateratzeen RAMa agortzen bada?
Alexey Milovidov: Arazo bat dago, RAM-aren kontsumoa berariaz bateratzeko ez dela mugatua. Eta bigarren arazoa zera da: batuketa motaren bat esleitu bada, orduan exekutatu egin behar da, erreplikazioen erregistroan erregistratuta dagoelako. Erreplika-erregistroa erreplika egoera koherente batera eramateko behar diren ekintzak dira. Erreplikazio-erregistro hau atzera botako duten eskuzko manipulazioak egiten ez badituzu, bateratzea era batera edo bestera egin beharko da.
Jakina, ez litzateke alferrikakoa izango "badaezpada" OOMren aurka babesten duen RAM muga bat izatea. Ez du bategitea osatzen lagunduko, berriro hasiko da, atalaseren batera iritsiko da, salbuespen bat botako du eta gero berriro hasiko da - honetatik ez da ezer onik aterako. Baina printzipioz, komenigarria litzateke murrizketa hori ezartzea.
Nola garatuko da Golang kontrolatzailea ClickHouserako?
Golang gidaria, Kirill Shvakov-ek idatzitakoa, orain ofizialki onartzen du ClickHouse taldeak. Berak , orain handia eta benetakoa da.
Ohar txiki bat. Ordena infinituko forma normalen biltegi zoragarri eta maitatu bat dago - hau Vertica da. Beren python kontrolatzaile ofiziala ere badute, Vertica garatzaileek onartzen dutena. Eta hainbat aldiz gertatu zen biltegiratze-bertsioak eta gidari-bertsioak guztiz desberdindu zirela eta gidariak uneren batean lan egiteari utzi zion. Eta bigarren puntua. Gidari ofizial honen laguntza, iruditzen zait, "titia" sistemak egiten du - arazo bat idazten diezu eta betirako zintzilikatzen da.
Bi galdera ditut. Orain Kirill-en Golang kontrolatzailea da Golang-etik ClickHouse-rekin komunikatzeko modu lehenetsia. Norbaitek http interfazearen bidez komunikatzen ez badu behintzat, horrela gustatzen zaiolako. Nola egingo da gidari honen garapena? Sinkronizatuko al da biltegian bertan egindako aldaketarekin? Eta zein da gai bat aztertzeko prozedura?
Kirill Shvakov: Lehenengoa, dena nola antolatzen den burokratikoki. Puntu hau ez zen eztabaidatu, beraz, ez dut ezer erantzuteko.
Arazoari buruzko galderari erantzuteko, gidariaren historia apur bat behar dugu. Datu asko zituen enpresa batean lan egin nuen. Nonbait gorde behar ziren ekitaldi ugari zituen publizitate-spinner bat zen. Eta noizbait ClickHouse agertu zen. Datuz bete genuen, eta hasieran dena ondo zegoen, baina gero ClickHouse huts egin zuen. Momentu horretan erabaki genuen ez genuela behar.
Urtebete geroago, ClickHouse erabiltzeko ideiara itzuli ginen, eta nolabait idatzi behar genituen bertan datuak. Sarrerako mezua hau zen: hardwarea oso ahula da, baliabide gutxi daude. Baina beti egin dugu lan horrela, eta horregatik bertako protokoloari begira jarri gara.
Gon lanean ari ginenez, argi zegoen Go gidari bat behar genuela. Ia denbora osoz egin nuen - nire lan egitekoa zen. Puntu bateraino ekarri genuen, eta, printzipioz, inork ez zuen suposatzen guk ez beste inork erabiliko zuenik. Orduan, CloudFlare arazo berdinarekin etorri zen, eta denbora batez oso ondo aritu ginen haiekin, zeregin berdinak baitzituzten. Gainera, hori bai ClickHousen guk geuk eta baita gidarian ere egin dugu.
Noizbait, egiteari utzi nion, ClickHouse eta lanari dagokionez nire jarduera pixka bat aldatu baitzen. Beraz, gaiak ez daude itxita. Aldian-aldian, zerbait behar duten pertsonek beren burua biltegira konprometitzen dute. Gero tira eskaerari begiratzen diot eta batzuetan neuk ere editatzen dut zerbait, baina hori gutxitan gertatzen da.
Gidariarengana itzuli nahi dut. Duela urte batzuk, hau guztia hasi zenean, ClickHouse ere ezberdina zen eta gaitasun ezberdinekin. Orain, kontrolatzailea nola birsortu ulertzen dugu ondo funtziona dezan. Hori gertatzen bada, 2. bertsioa bateraezina izango da edozein kasutan pilatutako makuluen ondorioz.
Ez dakit nola antolatu gai hau. Nik neuk ez daukat denbora askorik. Batzuek gidaria amaitzen badute, nik lagundu eta zer egin behar duten esango diet. Baina Yandex-en parte-hartze aktiboa proiektuaren garapenean oraindik ez da eztabaidatu.
Alexey Milovidov: Izan ere, oraindik ez dago gidari hauei buruzko burokraziarik. Gauza bakarra da erakunde ofizial batera bidaltzen direla, hau da, gidari hau Go-rako soluzio lehenetsi ofizial gisa aitortzen da. Badira beste gidari batzuk, baina bereiz etortzen dira.
Ez dugu barne garapenik gidari hauentzat. Kontua da ea pertsona indibidual bat kontratatu dezakegun, ez gidari zehatz honetarako, komunitateko gidari guztien garapenerako baizik, edo kanpoko norbait aurki dezakegun.
Kanpoko hiztegia ez da kargatzen lazy_load ezarpena gaituta berrabiarazi ondoren. Zer egin?
Lazy_load ezarpena gaituta dugu, eta zerbitzaria berrabiarazi ondoren, hiztegia ez da bere kabuz kargatzen. Erabiltzailea hiztegi honetara sartu ondoren bakarrik planteatzen da. Eta lehen aldiz sartzen naizenean, errore bat ematen du. Posible al da nolabait automatikoki kargatu hiztegiak ClickHouse erabiliz, edo zuk zeuk kontrolatu behar al duzu beti haien presttasuna, erabiltzaileek akatsik jaso ez dezaten?
Agian ClickHouse-ren bertsio zahar bat dugu, beraz hiztegia ez da automatikoki kargatu. Hau izan al liteke?
Lehenik eta behin, hiztegiak behartu egin daitezke kontsulta baten bidez sistema birkargatu hiztegiak. Bigarrenik, erroreari dagokionez - hiztegia dagoeneko kargatuta badago, kontsultak kargatutako datuetan oinarrituta funtzionatuko dute. Hiztegia oraindik kargatu ez bada, zuzenean kargatuko da eskaeran zehar.
Hau ez da oso erosoa hiztegi astunentzat. Adibidez, MySQL-tik milioi bat errenkada atera behar dituzu. Norbaitek aukeraketa sinple bat egiten du, baina aukeraketa honek milioi bat errenkada berdinen zain egongo dira. Hemen bi irtenbide daude. Lehenengoa lazy_load desaktibatzea da. Bigarrenik, zerbitzaria martxan dagoenean, karga jarri aurretik, egin sistema birkargatu hiztegia edo hiztegi bat erabiltzen duen kontsulta bat egin. Ondoren hiztegia kargatuko da. Hiztegien erabilgarritasuna kontrolatu behar duzu lazy_load ezarpena gaituta, ClickHouse-k ez dituelako automatikoki kargatzen.
Azken galderaren erantzuna bertsio zaharra da edo arazketa egin behar da.
Zer egin sistemaren hiztegiak birkargatzen ez dituelako hiztegi askoren bat kargatzen, gutxienez horietako bat hutsegite baten ondorioz?
Beste galdera bat dago sistemaren birkargatzeko hiztegiak. Bi hiztegi ditugu: bata ez dago kargatuta, bigarrena kargatuta dago. Kasu honetan, System reload dictionaries-ek ez du hiztegirik kargatzen, eta puntuz puntu kargatu behar duzu berariazko bat bere izenarekin sistemaren birkargatu hiztegia erabiliz. Hau ere ClickHouse bertsioarekin erlazionatuta al dago?
Zoriontsu egin nahi zaitut. Jokabide hori aldatzen ari zen. Horrek esan nahi du ClickHouse eguneratzen baduzu, hori ere aldatu egingo dela. Zure egungo portaerarekin pozik ez bazaude sistema birkargatu hiztegiak, eguneratu eta espero dezagun hobera aldatzea.
Ba al dago ClickHouse konfigurazioan xehetasunak konfiguratzeko modurik, baina akatsen kasuan bistaratu ez?
Hurrengo galdera hiztegiarekin lotutako akatsei buruzkoa da, hots, xehetasunei buruzkoa. Hiztegirako ClickHouse konfigurazioan konexioaren xehetasunak zehaztu ditugu, eta erroreren bat izanez gero, xehetasun hauek eta pasahitza jasoko ditugu erantzun moduan.
Errore hau ODBC kontrolatzailearen konfigurazioari xehetasunak gehituz konpondu dugu. Ba al dago ClickHouse konfigurazioan xehetasunak konfiguratzeko modurik, baina akatsen kasuan xehetasun horiek ez erakusteko?
Benetako irtenbidea hemen kredentzial hauek odbc.ini-n zehaztea da, eta ClickHousen bertan ODBC datu-iturburuaren izena soilik zehaztea. Hau ez da gertatuko beste hiztegi-iturri batzuetarako - ez MySQL-ren hiztegirako, ezta besteetarako ere, ez zenuke pasahitza ikusi behar errore-mezu bat jasotzen duzunean. ODBCrako ere begiratuko dut; existitzen bada, kendu besterik ez duzu egin behar.
Bonua: Zoom-erako atzeko planoak topaguneetatik
Irudian klik eginez gero, topaketetako atzeko planoak irekiko dira irakurle iraunkorrenentzat. Sua itzaltzen dugu Avito teknologiako maskotekin batera, sistemaren administratzaile gelako lankideekin edo eskola zaharreko informatika klubeko lankideekin hitz egiten dugu eta zubi azpian egunero bilerak egiten ditugu graffitien atzealdean.
Iturria: www.habr.com