Balandžio mėnesį „Avito“ inžinieriai susirinko į internetinius susitikimus su pagrindiniu „ClickHouse“ kūrėju Aleksejumi Milovidovu ir „Integros“ „Golang“ kūrėju Kirilu Shvakovu. Aptarėme, kaip naudojame duomenų bazių valdymo sistemą ir su kokiais sunkumais susiduriame.
Remdamiesi susitikimu, parengėme straipsnį su ekspertų atsakymais į mūsų ir auditorijos klausimus apie atsargines kopijas, duomenų perskirstymą, išorinius žodynus, Golang tvarkyklę ir ClickHouse versijų atnaujinimą. Tai gali būti naudinga kūrėjams, kurie jau aktyviai dirba su „Yandex DBVS“ ir domisi jos dabartimi ir ateitimi. Pagal numatytuosius nustatymus atsako Aleksejus Milovidovas, jei neparašyta kitaip.
Būkite atsargūs, po pjūviu yra daug teksto. Tikimės, kad turinys su klausimais padės jums naršyti.
Turinys
Jei nenorite skaityti teksto, galite žiūrėti susibūrimų įrašą . Laiko kodai yra pirmame komentare po vaizdo įrašu.
ClickHouse nuolat atnaujinama, bet mūsų duomenys ne. Ką su tuo daryti?
ClickHouse yra nuolat atnaujinamas, o mūsų duomenys, kurie buvo optimizuoti galutinai apdoroti, neatnaujinami ir yra atsarginėje kopijoje.
Tarkime, kad kilo problemų ir duomenys buvo prarasti. Nusprendėme atkurti ir paaiškėjo, kad senieji skirsniai, kurie saugomi atsarginiuose serveriuose, labai skiriasi nuo šiuo metu naudojamos ClickHouse versijos. Ką daryti tokioje situacijoje ir ar tai įmanoma?
Situacija, kai atkūrėte duomenis iš atsarginės kopijos senu formatu, bet ji neprisijungia prie naujos versijos, neįmanoma. Užtikriname, kad ClickHouse duomenų formatas visada išliktų atgalinis suderinamas. Tai yra daug svarbiau nei atgalinis funkcionalumo suderinamumas, jei pasikeitė kai kurios retai naudojamos funkcijos elgsena. Naujoji ClickHouse versija visada turėtų turėti galimybę nuskaityti duomenis, kurie yra saugomi diske. Tai yra įstatymas.
Kokia dabartinė geriausia „ClickHouse“ duomenų atsarginių kopijų kūrimo praktika?
Kaip pasidaryti atsargines kopijas, atsižvelgiant į tai, kad turime optimizuoti galutines operacijas, didžiulę terabaitų duomenų bazę ir duomenis, kurie atnaujinami, tarkime, paskutines tris dienas, o tada jokių procedūrų nevyksta?
Mes galime padaryti savo sprendimą ir parašyti ant bash: rinkti šias atsargines kopijas tokiu ir tokiu būdu. Gal nieko ramentuoti nereikia, o dviratis seniai išrastas?
Pradėkime nuo geriausios praktikos. Mano kolegos visada pataria atsakant į klausimus apie atsargines kopijas priminti apie Yandex.Cloud paslaugą, kurioje ši problema jau buvo išspręsta. Taigi naudokite, jei įmanoma.
Nėra viso sprendimo dėl atsarginių kopijų, šimtu procentų integruoto į ClickHouse. Yra keletas ruošinių, kuriuos galima naudoti. Norėdami gauti išsamų sprendimą, turėsite šiek tiek padirbėti rankiniu būdu arba sukurti scenarijus.
Pradėsiu nuo paprasčiausių sprendimų ir baigsiu sudėtingiausiais, priklausomai nuo duomenų apimties ir klasterio dydžio. Kuo didesnis klasteris, tuo sudėtingesnis sprendimas.
Jei lentelė su duomenimis užima tik kelis gigabaitus, atsarginę kopiją galima padaryti taip:
- Išsaugoti lentelės apibrėžimą, ty metaduomenis − parodyti sukurti lentelę.
- Sukurkite sąvartyną naudodami „ClickHouse“ klientą - pasirinkti * nuo stalo į failą. Pagal numatytuosius nustatymus gausite failą TabSeparated formatu. Jei norite būti efektyvesni, galite tai padaryti vietiniu formatu.
Jei duomenų kiekis didesnis, atsarginės kopijos kūrimas užims daugiau laiko ir daug vietos. Tai vadinama logine atsargine kopija; ji nėra susieta su ClickHouse duomenų formatu. Jei taip, tada kaip paskutinę priemonę galite pasidaryti atsarginę kopiją ir įkelti ją į MySQL, kad ją atkurtumėte.
Pažangesniems atvejams ClickHouse turi integruotą galimybę sukurti skaidinių momentinį vaizdą vietinėje failų sistemoje. Ši funkcija pasiekiama pagal užklausą pakeisti stalo užšaldymo skaidinį. Arba tiesiog pakeisti stalo užšaldymą - tai visos lentelės momentinė nuotrauka.
Momentinė nuotrauka bus kuriama nuosekliai vienai lentelei vienoje skevelėje, tai yra, tokiu būdu neįmanoma sukurti nuoseklaus visos klasterio momentinės nuotraukos. Tačiau daugeliui užduočių tokio poreikio nėra, pakanka įvykdyti užklausą kiekvienai skeveldrai ir gauti nuoseklų momentinį vaizdą. Jis sukurtas kietųjų nuorodų pavidalu, todėl neužima papildomos vietos. Tada nukopijuokite šią momentinę nuotrauką į atsarginės kopijos serverį arba saugyklą, kurią naudojate atsarginėms kopijoms kurti.
Atkurti tokią atsarginę kopiją yra gana paprasta. Pirmiausia sukurkite lenteles naudodami esamus lentelių apibrėžimus. Tada nukopijuokite išsaugotas skaidinių momentines nuotraukas į šių lentelių katalogą ir paleiskite užklausą pritvirtinti pertvarą. Šis sprendimas yra gana tinkamas rimčiausiam duomenų kiekiui.
Kartais prireikia kažko dar šaunesnio – tais atvejais, kai kiekviename serveryje yra dešimtys ar net šimtai terabaitų ir šimtai serverių. Čia yra sprendimas, kurį pasirinkau iš savo kolegų iš Yandex.Metrica. Nerekomenduočiau visiems – perskaitykite ir patys nuspręskite, tinka ar ne.
Pirmiausia turite sukurti kelis serverius su didelėmis diskų lentynomis. Tada šiuose serveriuose pakelkite kelis ClickHouse serverius ir sukonfigūruokite juos taip, kad jie veiktų kaip kita tų pačių skeveldrų kopija. Tada šiuose serveriuose naudokite failų sistemą arba kokį nors įrankį, leidžiantį kurti momentines nuotraukas. Čia yra du variantai. Pirmoji parinktis yra LVM momentinės nuotraukos, antroji parinktis yra ZFS Linux sistemoje.
Po to kiekvieną dieną reikia sukurti momentinį vaizdą, jis gulės ir užims šiek tiek vietos. Natūralu, kad pasikeitus duomenims, laikui bėgant vietos kiekis padidės. Šią momentinę nuotrauką galima bet kada nuimti ir atkurti duomenis, toks keistas sprendimas. Be to, mes taip pat turime apriboti šias kopijas konfigūracijoje, kad jos nebandytų tapti lyderiais.
Ar bus galima organizuoti kontroliuojamą replikų atsilikimą šachtose?
Šiais metais „ClickHouse“ planuojate gaminti velenus. Ar pavyks juose suorganizuoti kontroliuojamą replikų atsilikimą? Norėtume jį panaudoti apsisaugodami nuo neigiamų scenarijų su pokyčiais ir kitais pokyčiais.
Ar galima kaip nors pakeisti alterius? Pavyzdžiui, esamoje šachtoje paimkite ir pasakykite, kad iki šio momento taikote pakeitimus, o nuo šio momento nustojate taikyti pakeitimus?
Jei komanda atėjo į mūsų klasterį ir ją sulaužė, tai mes turime sąlyginę kopiją su valandos vėlavimu, kur galime pasakyti, kad naudokime ją šiuo metu, bet paskutines dešimt minučių netaikome jos pakeitimų?
Pirma, apie kontroliuojamą kopijų atsilikimą. Buvo toks vartotojų prašymas, ir mes sukūrėme problemą „Github“ su užklausa: „Jei kam to reikia, pamėginkite, įdėk širdį“. Niekas nepristatė ir problema buvo uždaryta. Tačiau šią galimybę jau galite gauti nustatę ClickHouse. Tiesa, tik nuo 20.3 versijos.
ClickHouse nuolat atlieka duomenų sujungimą fone. Kai sujungimas baigiamas, tam tikras duomenų rinkinys pakeičiamas didesniu. Tuo pačiu metu anksčiau buvę duomenų fragmentai kurį laiką lieka diske.
Pirma, jie ir toliau saugomi tol, kol yra pasirinktų užklausų, kurios jas naudoja, kad būtų užtikrinta neblokuojanti veikla. Pasirinktos užklausos lengvai nuskaitomos iš senų dalių.
Antra, taip pat yra laiko slenkstis – seni duomenys aštuonias minutes guli diske. Šias aštuonias minutes galima pritaikyti ir netgi paversti viena diena. Tai kainuos vietos diske: priklausomai nuo duomenų srauto, paaiškėja, kad paskutinę dieną duomenų ne tik padvigubės, bet gali padidėti ir penkis kartus. Bet jei yra rimta problema, galite sustabdyti ClickHouse serverį ir viską sutvarkyti.
Dabar kyla klausimas, kaip tai apsaugo nuo pakitimų. Čia verta pažvelgti giliau, nes senesnėse „ClickHouse“ versijose alter veikė taip, kad tiesiog pakeitė dalis. Kai kuriuose failuose yra duomenų dalis, o mes, pavyzdžiui, pakeisti lašo stulpelį. Tada šis stulpelis fiziškai pašalinamas iš visų gabalų.
Tačiau pradedant nuo 20.3 versijos, keitimo mechanizmas buvo visiškai pakeistas, o dabar duomenų dalys visada yra nekintamos. Jie visiškai nesikeičia – dabar pakeitimai veikia taip pat, kaip ir sujungimai. Užuot vietoje pakeitę gabalą, sukuriame naują. Naujame gabale nepasikeitę failai tampa kietosiomis nuorodomis, o jei ištrinsime stulpelį, jo tiesiog trūks naujame gabale. Senasis kūrinys pagal numatytuosius nustatymus bus ištrintas po aštuonių minučių, o čia galėsite pakoreguoti pirmiau minėtus nustatymus.
Tas pats pasakytina apie pokyčius, tokius kaip mutacijos. Kai tai padarysi pakeisti ištrinti arba pakeisti atnaujinimą, tai kūrinio nekeičia, o sukuria naują. Ir tada ištrina seną.
Ką daryti, jei pasikeitė lentelės struktūra?
Kaip atkurti atsarginę kopiją, kuri buvo sukurta pagal seną schemą? Antrasis klausimas yra apie momentines nuotraukas ir failų sistemos įrankius. Ar čia geras Btrfs, o ne ZFS Linux LVM?
Jei taip pritvirtinti pertvarą skaidinius su kitokia struktūra, tada ClickHouse pasakys, kad tai neįmanoma. Tai yra sprendimas. Pirmasis yra sukurti laikiną MergeTree tipo lentelę su sena struktūra, pridėti ten duomenis naudodami add ir atlikti pakeitimo užklausą. Tada galite nukopijuoti arba perkelti šiuos duomenis ir vėl pridėti, arba naudoti užklausą pakeisti lentelės perkėlimo skaidinį.
Dabar antras klausimas, ar galima naudoti Btrfs. Pirmiausia, jei turite LVM, pakanka LVM momentinių vaizdų, o failų sistema gali būti ext4, nesvarbu. Naudojant Btrts, viskas priklauso nuo jūsų patirties naudojant jį. Tai subrendusi failų sistema, tačiau vis dar kyla įtarimų, kaip viskas pasiteisins praktiškai pagal tam tikrą scenarijų. Nerekomenduočiau to naudoti, nebent turite Btrfs gamyboje.
Kokia yra dabartinė geriausia duomenų perskirstymo praktika?
Perskirstymo klausimas yra sudėtingas ir daugialypis. Čia yra keletas galimų atsakymų. Galite pereiti iš vienos pusės ir pasakyti štai ką – „ClickHouse“ neturi integruotos perskyrimo funkcijos. Bet bijau, kad šis atsakymas niekam netiks. Todėl galite pereiti iš kitos pusės ir pasakyti, kad „ClickHouse“ turi daug būdų, kaip iš naujo susmulkinti duomenis.
Jei klasteryje pritrūksta vietos arba jis negali susidoroti su apkrova, pridedate naujų serverių. Bet šie serveriai pagal nutylėjimą yra tušti, juose nėra duomenų, nėra apkrovos. Turite pertvarkyti duomenis taip, kad jie būtų tolygiai paskirstyti naujame didesniame klasteryje.
Pirmasis būdas tai padaryti yra nukopijuoti dalį skaidinių į naujus serverius naudojant užklausą pakeisti lentelės gavimo skaidinį. Pavyzdžiui, turėjote skirsnius pagal mėnesį, o pirmą 2017 m. mėnesį nukopijuojate jį į naują serverį, o trečią mėnesį nukopijuojate į kitą naują serverį. Darykite tai tol, kol pasidarys daugiau ar mažiau tolygus.
Perkėlimas gali būti atliekamas tik tose skaidiniuose, kurie nesikeičia įrašymo metu. Naujose pertvarose įrašymas turės būti išjungtas, nes jų perdavimas nėra atominis. Priešingu atveju turėsite duomenų dublikatus arba spragų. Tačiau šis metodas yra praktiškas ir veikia gana efektyviai. Paruoštos suspaustos skaidinės perduodamos per tinklą, tai yra, duomenys nėra suglaudinami ar perkoduojami.
Šis metodas turi vieną trūkumą, ir tai priklauso nuo dalijimosi schemos, ar įsipareigojote šiai dalijimosi schemai, kokį dalijimosi raktą turėjote. Jūsų pavyzdyje metrikos atveju dalijimosi raktas yra kelio maiša. Kai pasirenkate paskirstytą lentelę, ji vienu metu patenka į visas klasterio dalis ir iš ten paima duomenis.
Tai reiškia, kad jums iš tikrųjų nesvarbu, kokie duomenys atsidūrė ant kurios skeveldros. Svarbiausia, kad viename kelyje esantys duomenys atsidurtų vienoje skeveldroje, bet kuris iš jų nėra svarbus. Šiuo atveju paruoštų skaidinių perkėlimas yra tobulas, nes su pasirinktomis užklausomis taip pat gausite išsamius duomenis - ar prieš perdalinant, ar po to, schema tikrai nesvarbu.
Tačiau yra atvejų, kurie yra sudėtingesni. Jei programos logikos lygmenyje pasikliaujate specialia dalijimosi schema, kad šis klientas yra tokioje ir tokioje skeveldoje, o užklausa gali būti siunčiama tiesiai ten, o ne į paskirstytą lentelę. Arba naudojate gana naujausią ClickHouse versiją ir įgalinote nustatymą optimizuoti praleisti nepanaudotas skeveldras. Tokiu atveju pasirinkimo užklausos metu bus išanalizuota kur skiltyje esanti išraiška ir apskaičiuojama, kokias skeveldras reikia naudoti pagal sharding schemą. Tai veikia, jei duomenys yra suskirstyti tiksliai pagal šią skirstymo schemą. Jei juos pertvarkėte rankiniu būdu, korespondencija gali pasikeisti.
Taigi tai yra metodas numeris vienas. Ir laukiu jūsų atsakymo, ar metodas tinkamas, ar judėkime toliau.
Vladimiras Kolobajevas, „Avito“ pagrindinis sistemos administratorius: Aleksejus, jūsų minėtas metodas neveikia labai gerai, kai reikia paskirstyti krūvį, įskaitant skaitymą. Galime perkelti skaidinį, kuris yra kas mėnesį ir gali perkelti ankstesnį mėnesį į kitą mazgą, bet kai bus užklausa dėl šių duomenų, mes tik įkelsime juos. Bet norėtume įkelti visą klasterį, nes priešingu atveju kurį laiką visą skaitymo apkrovą apdoros dvi šukės.
Aleksejus Milovidovas: Atsakymas čia keistas – taip, tai blogai, bet gali veikti. Aš tiksliai paaiškinsiu, kaip. Verta pažvelgti į įkėlimo scenarijų, kuris yra už jūsų duomenų. Jei tai yra stebėjimo duomenys, galime beveik neabejotinai teigti, kad didžioji dauguma užklausų yra dėl naujų duomenų.
Įdiegėte naujus serverius, perkėlėte senus skaidinius, bet taip pat pakeitėte naujų duomenų įrašymo būdą. Ir nauji duomenys bus paskleisti visame klasteryje. Taigi vos po penkių minučių paskutinių penkių minučių užklausos tolygiai įkels klasterį, o po paros XNUMX valandų užklausos – tolygiai. O užklausos už praėjusį mėnesį, deja, pateks tik į dalį klasterio serverių.
Tačiau dažnai neturėsite prašymų konkrečiai 2019 m. vasario mėn. Greičiausiai, jei užklausos pateks į 2019 m., tada jos bus už visus 2019 metus – ilgam laikotarpiui, o ne kokiam nors mažam diapazonui. Ir tokios užklausos taip pat galės įkelti klasterį tolygiai. Bet apskritai jūsų pastaba yra visiškai teisinga, kad tai yra ad hoc sprendimas, kuris ne visiškai tolygiai paskirsto duomenis.
Turiu dar kelis punktus, kad atsakyčiau į klausimą. Vienas iš jų yra apie tai, kaip iš pradžių sukurti skeldinimo schemą, kad pakartotinis suskaidymas sukeltų mažiau skausmo. Tai ne visada įmanoma.
Pavyzdžiui, turite stebėjimo duomenis. Stebėjimo duomenys auga dėl trijų priežasčių. Pirmasis – istorinių duomenų kaupimas. Antrasis – eismo augimas. Trečia – stebimų dalykų skaičiaus padidėjimas. Yra naujų mikropaslaugų ir metrikų, kurias reikia išsaugoti.
Gali būti, kad iš jų didžiausias padidėjimas siejamas su trečiąja priežastimi – stebėsenos naudojimo padidėjimu. Ir šiuo atveju verta pažvelgti į apkrovos pobūdį, kokios yra pagrindinės pasirinkimo užklausos. Pagrindinės pasirinkimo užklausos greičiausiai bus pagrįstos tam tikru metrikos poaibiu.
Pavyzdžiui, kai kurių paslaugų procesoriaus naudojimas kai kuriuose serveriuose. Pasirodo, kad yra tam tikras raktų poaibis, kuriuo jūs gaunate šiuos duomenis. Ir pati užklausa dėl šių duomenų greičiausiai yra gana paprasta ir užpildoma per kelias dešimtis milisekundžių. Naudojamas stebėjimo paslaugoms ir prietaisų skydeliams. Tikiuosi tai teisingai supratau.
Vladimiras Kolobajevas: Faktas yra tas, kad mes labai dažnai kreipiamės į istorinius duomenis, nes esamą situaciją lyginame su istorine realiuoju laiku. Mums svarbu turėti greitą prieigą prie didelio duomenų kiekio, o „ClickHouse“ atlieka puikų darbą.
Jūs esate visiškai teisus, mes patiriame daugumą skaitymo užklausų per paskutinę dieną, kaip ir bet kuri stebėjimo sistema. Tačiau tuo pačiu metu istorinių duomenų apkrova taip pat yra gana didelė. Iš esmės tai yra perspėjimo sistema, kuri sukasi kas trisdešimt sekundžių ir „ClickHouse“ sako: „Duokite man paskutinių šešių savaičių duomenis. Dabar sukurkite man iš jų slenkantį vidurkį ir palyginkime dabartinę vertę su istorine.
Norėčiau pasakyti, kad tokioms labai nesenoms užklausoms turime dar vieną nedidelę lentelę, kurioje saugome tik dviejų dienų duomenis, o pagrindinės užklausos patenka į ją. Į didelę susmulkintą lentelę siunčiame tik dideles istorines užklausas.
Aleksejus Milovidovas: Deja, pasirodo, kad tai prastai tinka jūsų scenarijui, bet papasakosiu dviejų blogų ir sudėtingų atskyrimo schemų, kurių nereikia naudoti, bet kurios naudojamos mano draugų paslaugoms, aprašymą.
Yra pagrindinė „Yandex.Metrica“ įvykių grupė. Įvykiai yra puslapių peržiūros, paspaudimai ir konversijos. Dauguma užklausų patenka į konkrečią svetainę. Atidarote „Yandex.Metrica“ paslaugą, turite svetainę - avito.ru, eikite į ataskaitą ir pateikiama jūsų svetainės užklausa.
Tačiau yra ir kitų – analitinių ir visuotinių – prašymų, kuriuos pateikia vidiniai analitikai. Tik tuo atveju atkreipiu dėmesį, kad vidiniai analitikai teikia užklausas tik dėl „Yandex“ paslaugų. Tačiau nepaisant to, net „Yandex“ paslaugos užima didelę visų duomenų dalį. Tai užklausos ne dėl konkrečių skaitiklių, o dėl platesnio filtravimo.
Kaip sutvarkyti duomenis taip, kad viskas veiktų efektyviai ir vienam skaitikliui, ir visuotinėms užklausoms? Kitas sunkumas yra tas, kad „ClickHouse“ užklausų skaičius „Metrics“ klasteriui yra keli tūkstančiai per sekundę. Tuo pačiu metu vienas ClickHouse serveris negali apdoroti nereikšmingų užklausų, pavyzdžiui, kelių tūkstančių per sekundę.
Klasterio dydis yra šeši šimtai serverių. Jei tiesiog pertrauksite paskirstytą lentelę per šį klasterį ir išsiųsite ten kelis tūkstančius užklausų, tai bus dar blogiau nei siųsti juos į vieną serverį. Kita vertus, iš karto atmetama galimybė, kad duomenys paskirstomi tolygiai, o mes einame ir prašome iš visų serverių.
Yra variantas, kuris yra diametraliai priešingas. Įsivaizduokite, jei duomenis dalijame įvairiose svetainėse, o vienos svetainės užklausa patenka į vieną fragmentą. Dabar klasteris galės apdoroti dešimt tūkstančių užklausų per sekundę, tačiau viena užklausa veiks per lėtai. Jis nebebus keičiamas pralaidumo požiūriu. Ypač jei tai svetainė avito.ru. Neatskleisiu paslapties, jei pasakysiu, kad Avito yra viena lankomiausių „RuNet“ svetainių. O apdoroti ją ant vienos šukės būtų beprotybė.
Todėl skaldymo schema sukurta gudriau. Visas klasteris yra padalintas į keletą grupių, kurias vadiname sluoksniais. Kiekviename klasteryje yra nuo keliolikos iki kelių dešimčių šukių. Iš viso yra trisdešimt devynios tokios grupės.
Kaip visa tai mastas? Klasterių skaičius nesikeičia – koks prieš kelerius metus buvo trisdešimt devyni, toks ir išlieka. Tačiau kiekviename iš jų kaupdami duomenis palaipsniui didiname šukių skaičių. O bendra dalijimosi schema yra tokia: šie klasteriai yra suskirstyti į svetaines, o norint suprasti, kuri svetainė kurioje klasteryje yra, naudojama atskira MySQL metabazė. Viena svetainė – viename klasteryje. O jo viduje skeveldymas vyksta pagal lankytojų ID.
Įrašydami juos padalijame iš likusios lankytojo ID padalijimo dalies. Tačiau pridedant naują skeveldrą pasikeičia dalijimosi schema; mes ir toliau dalijame, bet dalijame likutį iš kitu skaičiumi. Tai reiškia, kad vienas lankytojas jau yra keliuose serveriuose, ir jūs negalite tuo pasikliauti. Tai daroma tik siekiant užtikrinti, kad duomenys būtų geriau suspausti. O darydami užklausas einame į Distributed lentelę, kuri žiūri į klasterį ir pasiekia daugybę serverių. Tai tokia kvaila schema.
Tačiau mano istorija bus neišsami, jei nesakysiu, kad atsisakėme šios schemos. Naujoje schemoje viską pakeitėme ir visus duomenis nukopijavome naudodami clickhouse-copier.
Naujoje schemoje visos svetainės suskirstytos į dvi kategorijas – dideles ir mažas. Nežinau, kaip buvo pasirinktas slenkstis, bet rezultatas buvo toks, kad didelės svetainės įrašomos į vieną klasterį, kur yra 120 fragmentų su trimis kopijomis - tai yra 360 serverių. O smulkinimo schema tokia, kad bet koks prašymas eina į visas šukes iš karto. Jei dabar atidarysite bet kurį avito.ru ataskaitų puslapį Yandex.Metrica, užklausa pateks į 120 serverių. „RuNet“ yra keletas didelių svetainių. O prašymų – ne tūkstantis per sekundę, o net mažiau nei šimtas. Visa tai tyliai sukramto Distributed lentelė, kurią kiekvienas apdoroja su 120 serverių.
O antrasis klasteris skirtas mažoms svetainėms. Čia yra dalijimosi schema, pagrįsta svetainės ID, ir kiekviena užklausa siunčiama tiksliai vienai daliai.
„ClickHouse“ turi „Clickhouse“ kopijavimo priemonę. Ar galite papasakoti apie ją?
Iš karto pasakysiu, kad šis sprendimas yra sudėtingesnis ir šiek tiek mažiau produktyvus. Privalumas yra tas, kad jis visiškai sutepa duomenis pagal jūsų nurodytą modelį. Tačiau naudingumo trūkumas yra tas, kad jis visiškai nesusmulkina. Jis kopijuoja duomenis iš vienos klasterio schemos į kitą klasterio schemą.
Tai reiškia, kad norint, kad jis veiktų, turite turėti dvi grupes. Jie gali būti tuose pačiuose serveriuose, tačiau, nepaisant to, duomenys nebus perkeliami laipsniškai, o bus nukopijuoti.
Pavyzdžiui, buvo keturi serveriai, dabar – aštuoni. Visuose serveriuose sukuriate naują paskirstytą lentelę, naujas vietines lenteles ir paleidžiate „clickhouse-copier“, joje nurodydami darbo schemą, kurią jis turėtų skaityti iš ten, sutinkate su nauja dalijimosi schema ir perkeliate duomenis ten. O senuose serveriuose vietos prireiks pusantro karto daugiau nei dabar, nes juose turi likti seni duomenys, o ant jų ateis pusė tų pačių senų duomenų. Jei iš anksto pagalvojote, kad duomenis reikia iš naujo susmulkinti ir yra vietos, šis metodas tinka.
Kaip „clickhouse“ kopijavimo aparatas veikia viduje? Jis suskaido visą darbą į užduočių rinkinį, skirtą vienos lentelės skaidiniui apdoroti vienoje skeveldrėje. Visos šios užduotys gali būti vykdomos lygiagrečiai, o „Clickhouse-copier“ gali būti paleistas skirtinguose įrenginiuose keliais atvejais, tačiau tai, ką jis daro vienam skaidiniui, yra ne kas kita, kaip įterpimo pasirinkimas. Duomenys nuskaitomi, suglaudinami, perskirstomi, tada vėl suglaudinami, kažkur įrašomi ir iš naujo rūšiuojami. Tai sunkesnis sprendimas.
Turėjote bandomąjį dalyką, vadinamą perskeldimu. Kas su ja?
2017 m. turėjote bandomąjį dalyką, vadinamą perskeldimu. „ClickHouse“ netgi yra parinktis. Kaip suprantu, nepakilo. Ar galite man pasakyti, kodėl taip atsitiko? Atrodo, kad tai labai aktualu.
Visa problema yra ta, kad jei reikia iš naujo susmulkinti duomenis, norint tai padaryti atomiškai, reikalingas labai sudėtingas sinchronizavimas. Kai pradėjome žiūrėti, kaip veikia šis sinchronizavimas, tapo aišku, kad yra esminių problemų. Ir šios esminės problemos yra ne tik teorinės, bet ir iš karto pradėjo reikštis praktikoje kaip kažkas, ką galima paaiškinti labai paprastai – niekas neveikia.
Ar galima sujungti visus duomenis prieš perkeliant juos į lėtus diskus?
Klausimas apie TTL su perėjimo prie lėto disko parinktimi sujungimų kontekste. Ar yra būdas, išskyrus per cron, sujungti visas dalis į vieną prieš perkeliant jas į lėtus diskus?
Atsakymas į klausimą, ar galima kažkaip automatiškai suklijuoti visas dalis į vieną prieš jas perkeliant - ne. Nemanau, kad tai būtina. Nereikia sujungti visų dalių į vieną, o tiesiog tikėtis, kad jos bus automatiškai perkeltos į lėtus diskus.
Turime du perdavimo taisyklių kriterijus. Pirmasis yra toks, koks jis užpildytas. Jei dabartinė saugyklos pakopa turi mažiau nei tam tikrą procentą laisvos vietos, pasirenkame vieną dalį ir perkeliame į lėtesnę saugyklą. Tiksliau, ne lėčiau, o kitą - kaip sukonfigūravote.
Antrasis kriterijus yra dydis. Kalbama apie didelių gabalų perkėlimą. Galite reguliuoti slenkstį pagal laisvą vietą greitajame diske ir duomenys bus perkelti automatiškai.
Kaip pereiti prie naujų ClickHouse versijų, jei nėra galimybės iš anksto patikrinti suderinamumo?
Ši tema nuolat aptarinėjama atsižvelgiant į skirtingas versijas, ir vis tiek. Ar saugu atnaujinti iš 19.11 versijos į 19.16 ir, pavyzdžiui, iš 19.16 į 20.3. Koks yra geriausias būdas pereiti prie naujų versijų, iš anksto nepatikrinus suderinamumo smėlio dėžėje?
Čia yra keletas „auksinių“ taisyklių. Pirmas - . Jis didelis, tačiau yra atskiros pastraipos apie atgal nesuderinamus pakeitimus. Nelaikykite šių taškų raudona vėliava. Paprastai tai yra nedideli nesuderinamumai, susiję su tam tikromis krašto funkcijomis, kurių greičiausiai nenaudojate.
Antra, jei nėra galimybės patikrinti suderinamumo smėlio dėžėje ir norite nedelsiant atnaujinti gamyboje, rekomenduojama to daryti nereikėtų. Pirmiausia sukurkite smėlio dėžę ir išbandykite. Jei nėra testavimo aplinkos, greičiausiai neturite labai didelės įmonės, o tai reiškia, kad galite nukopijuoti kai kuriuos duomenis į nešiojamąjį kompiuterį ir įsitikinti, kad viskas jame veikia tinkamai. Jūs netgi galite sukurti kelias kopijas vietoje savo kompiuteryje. Arba galite kur nors netoliese pasiimti naują versiją ir ten įkelti dalį duomenų – tai yra sukurti improvizuotą testavimo aplinką.
Kita taisyklė – neatnaujinti savaitę po versijos išleidimo dėl gamybos klaidų ir vėlesnių greitų pataisymų. Išsiaiškinkime ClickHouse versijų numeraciją, kad nesusipainiotume.
Yra 20.3.4 versija. Skaičius 20 nurodo pagaminimo metus – 2020. Žiūrint iš to, kas yra viduje, tai nesvarbu, todėl nekreipsime dėmesio. Kitas - 20.3. Kiekvieną kartą išleisdami leidimą su naujomis funkcijomis padidiname antrąjį skaičių – šiuo atveju 3. Jei norime prie ClickHouse pridėti kokią nors funkciją, turime padidinti šį skaičių. Tai reiškia, kad 20.4 versijoje ClickHouse veiks dar geriau. Trečiasis skaitmuo yra 20.3.4. Čia yra 4 pataisų leidimų, į kuriuos nepridėjome naujų funkcijų, bet ištaisėme kai kurias klaidas, skaičius. O 4 reiškia, kad tai padarėme keturis kartus.
Nemanykite, kad tai kažkas baisaus. Paprastai vartotojas gali įdiegti naujausią versiją ir ji veiks be jokių problemų su veikimo laiku per metus. Tačiau įsivaizduokite, kad tam tikroje bitmaps apdorojimo funkcijoje, kurią pridėjo mūsų Kinijos draugai, serveris sugenda, kai perduoda neteisingus argumentus. Mes privalome tai ištaisyti. Išleisime naują pataisos versiją ir ClickHouse taps stabilesnis.
Jei turite gamybinę ClickHouse versiją, o nauja ClickHouse versija yra išleista su papildomomis funkcijomis – pavyzdžiui, 20.4.1 yra pati pirmoji, neskubėkite jos pradėti gaminti pirmą dieną. Kodėl to net reikia? Jei dar nenaudojate ClickHouse, tuomet galite jį įdiegti, ir greičiausiai viskas bus gerai. Bet jei „ClickHouse“ jau veikia stabiliai, stebėkite pataisas ir atnaujinimus, kad pamatytumėte, kokias problemas sprendžiame.
Kirilas Švakovas: Norėčiau šiek tiek pridurti apie bandomąsias aplinkas. Visi labai bijo testavimo aplinkų ir kažkodėl mano, kad jei turite labai didelį ClickHouse klasterį, tai testavimo aplinka turėtų būti ne mažesnė ar bent dešimt kartų mažesnė. Tai visai ne taip.
Galiu pasakyti iš savo pavyzdžio. Turiu projektą ir yra ClickHouse. Mūsų testavimo aplinka kaip tik jam – tai maža virtuali mašina Hetzneryje už dvidešimt eurų, kurioje įdiegta absoliučiai viskas. Norėdami tai padaryti, „Ansible“ turime visišką automatizavimą, todėl iš esmės nėra skirtumo, kur eiti - į aparatūros serverius ar tiesiog įdiegti virtualiose mašinose.
Ką galima padaryti? Būtų malonu ClickHouse dokumentacijoje pateikti pavyzdį, kaip įdiegti nedidelį klasterį savo namuose – „Docker“, LXC, galbūt sukurkite Ansible žaidimų knygą, nes skirtingi žmonės naudoja skirtingus diegimus. Tai labai supaprastins. Kai paimate ir įdiegiate grupę per penkias minutes, daug lengviau bandyti ką nors išsiaiškinti. Tai daug patogiau, nes perėjimas prie gamybinės versijos, kurios neišbandėte, yra kelias į niekur. Kartais pavyksta, o kartais ne. Ir todėl tikėtis sėkmės yra blogai.
Maksimas Kotjakovas, vyresnysis inžinierius „Avito“: Pridėsiu šiek tiek apie bandymų aplinkas iš daugelio problemų, su kuriomis susiduria didelės įmonės. Turime pilnavertį ClickHouse priėmimo klasterį, duomenų schemų ir nustatymų atžvilgiu tai yra tiksli gamyboje esančio kopija. Šis klasteris yra įdiegtas gana išeikvotuose konteineriuose su minimaliais ištekliais. Ten rašome tam tikrą procentą gamybos duomenų, laimei, galima atkartoti srautą Kafkoje. Ten viskas yra sinchronizuota ir suskirstyta - tiek talpos, tiek srauto prasme, tiek teoriškai, jei visi kiti dalykai yra vienodi, pagal metriką jis turėtų elgtis kaip gamyba. Viskas, kas gali sprogti, pirmiausia suvyniojama ant šio stovo ir paliekama kelioms dienoms, kol bus paruošta. Tačiau natūralu, kad šis sprendimas yra brangus, sudėtingas ir jo palaikymo išlaidos nėra nulinės.
Aleksejus Milovidovas: Papasakosiu, kokia yra mūsų draugų iš Yandex.Metrica testavimo aplinka. Viename klasteryje buvo 600 nelyginių serverių, kitame buvo 360, o trečiame ir keli klasteriai. Vieno iš jų bandymo aplinka yra tiesiog dvi skeveldros, kurių kiekvienoje yra dvi kopijos. Kodėl dvi šukės? Kad būtum ne vienas. Ir kopijų taip pat turėtų būti. Tiesiog tam tikra minimali suma, kurią galite sau leisti.
Ši bandomoji aplinka leidžia patikrinti, ar jūsų užklausos veikia ir ar kas nors nepažeista. Tačiau dažnai iškyla visai kitokio pobūdžio problemos, kai viskas veikia, tik būna nedideli krūvio pakitimai.
Pateiksiu pavyzdį. Nusprendėme įdiegti naują ClickHouse versiją. Jis buvo paskelbtas bandomojoje aplinkoje, pačioje „Yandex.Metrica“ buvo atlikti automatiniai testai, kurie lygina senosios ir naujosios versijos duomenis, paleidžiant visą dujotiekį. Ir, žinoma, žalieji mūsų CI testai. Kitaip net nebūtume pasiūlę šios versijos.
Viskas gerai. Pradedame pereiti prie gamybos. Gaunu pranešimą, kad grafikų krūvis išaugo kelis kartus. Atšaukiame versiją. Žiūriu į grafiką ir matau: išleidus apkrovą iš tikrųjų padidėjo kelis kartus, o išleidus – sumažėjo. Tada pradėjome atšaukti versiją. Ir krūvis lygiai taip pat didėjo ir lygiai taip pat krito atgal. Taigi išvada tokia: apkrova padidėjo dėl išplanavimo, nieko stebėtino.
Tada buvo sunku įtikinti kolegas įdiegti naują versiją. Aš sakau: „Viskas gerai, išleisk. Laikykite kumščius, viskas pavyks. Dabar grafikų krūvis padidėjo, bet viskas gerai. Laikykis." Apskritai mes tai padarėme, ir viskas - versija buvo išleista gamybai. Tačiau beveik su kiekvienu išdėstymu iškyla panašių problemų.
Nužudyti užklausą turėtų užmušti užklausas, bet taip nėra. Kodėl?
Vartotojas, kažkoks analitikas, atėjo pas mane ir sukūrė užklausą, kuri padėjo mano „ClickHouse“ klasterį. Tam tikras mazgas arba visas klasteris, atsižvelgiant į tai, į kurią kopiją ar fragmentą buvo išsiųsta užklausa. Matau, kad visi CPU resursai šiame serveryje yra lentynoje, viskas raudona. Tuo pačiu metu „ClickHouse“ pati atsako į užklausas. Ir aš rašau: „Parodykite man, procesų sąrašą, koks prašymas sukėlė šią beprotybę“.
Surandu šį prašymą ir rašau į jį kill. Ir matau, kad nieko nevyksta. Mano serveris yra lentynoje, tada ClickHouse man duoda keletą komandų, parodo, kad serveris gyvas, ir viskas puiku. Tačiau visos vartotojų užklausos pablogėja, pablogėjimas prasideda nuo įrašų „ClickHouse“, o mano užklausa „žudyti“ neveikia. Kodėl? Maniau, kad nužudymo užklausa turėjo panaikinti užklausas, bet taip nėra.
Dabar bus gana keistas atsakymas. Esmė ta, kad nužudymo užklausa neužmuša užklausų.
Užklausa „Nužudyti“ pažymi mažą langelį pavadinimu „Noriu, kad ši užklausa būtų panaikinta“. Ir pati užklausa žiūri į šią vėliavėlę apdorojant kiekvieną bloką. Jei jis nustatytas, užklausa nustoja veikti. Pasirodo, prašymo niekas neužmuša, jis pats turi viską patikrinti ir sustoti. Ir tai turėtų veikti visais atvejais, kai užklausa yra duomenų blokų apdorojimo būsenoje. Jis apdoros kitą duomenų bloką, patikrins vėliavėlę ir sustos.
Tai neveikia tais atvejais, kai užklausa blokuojama atliekant tam tikrą operaciją. Tiesa, greičiausiai tai ne jūsų atvejis, nes, pasak jūsų, jis naudoja daugybę serverio resursų. Gali būti, kad tai neveikia išorinio rūšiavimo ir kai kurių kitų detalių atveju. Bet apskritai tai neturėtų atsitikti, tai yra klaida. Ir vienintelis dalykas, kurį galiu rekomenduoti, yra atnaujinti ClickHouse.
Kaip apskaičiuoti reakcijos laiką esant skaitymo apkrovai?
Yra lentelė, kurioje saugomi prekių agregatai – įvairūs skaitikliai. Eilučių skaičius yra maždaug šimtas milijonų. Ar galima tikėtis nuspėjamo atsako laiko, jei už 1 tūkst. prekių išpilsite 1K RPS?
Sprendžiant iš konteksto, kalbame apie skaitymo krūvį, nes rašant problemų nėra – galima įterpti net tūkstantį, net šimtą tūkstančių, o kartais ir kelis milijonus eilučių.
Skaitymo prašymai labai skirtingi. 1 pasirinkime ClickHouse gali atlikti apie dešimtis tūkstančių užklausų per sekundę, todėl net ir vieno rakto užklausoms jau reikės tam tikrų išteklių. Ir tokios taško užklausos bus sunkesnės nei kai kuriose raktinių reikšmių duomenų bazėse, nes kiekvienam skaitymui reikia perskaityti duomenų bloką pagal indeksą. Mūsų indeksas skirtas ne kiekvienam įrašui, o kiekvienam diapazonui. Tai reiškia, kad turėsite perskaityti visą diapazoną - pagal numatytuosius nustatymus tai yra 8192 eilutės. O suspaustą duomenų bloką teks išskleisti nuo 64 KB iki 1 MB. Paprastai tokios tikslinės užklausos užtrunka kelias milisekundes. Bet tai yra paprasčiausias variantas.
Pabandykime atlikti paprastą aritmetiką. Jei keletą milisekundžių padauginsite iš tūkstančio, gausite kelias sekundes. Lyg ir neįmanoma suspėti su tūkstančio užklausų per sekundę, bet iš tikrųjų tai įmanoma, nes turime kelis procesoriaus branduolius. Taigi iš principo ClickHouse kartais gali sutalpinti 1000 RPS, bet trumpiems užklausoms – konkrečiai tiksliniams.
Jei jums reikia padidinti ClickHouse klasterį pagal paprastų užklausų skaičių, rekomenduoju paprasčiausią dalyką - padidinti kopijų skaičių ir siųsti užklausas į atsitiktinę kopiją. Jei vienoje kopijoje yra penki šimtai užklausų per sekundę, o tai yra visiškai realu, tada trys kopijos apdoros pusantro tūkstančio.
Kartais, žinoma, galite sukonfigūruoti „ClickHouse“ maksimaliam taškų rodmenų skaičiui. Ko tam reikia? Pirmasis – sumažinti indekso detalumą. Šiuo atveju jis turėtų būti sumažintas ne iki vieno, o remiantis tuo, kad įrašų skaičius indekse bus keli milijonai ar dešimtys milijonų viename serveryje. Jei lentelėje yra šimtas milijonų eilučių, detalumą galima nustatyti į 64.
Galite sumažinti suspausto bloko dydį. Tam yra nustatymai min kompresinio bloko dydis, maksimalus suspaudimo bloko dydis. Juos galima sumažinti, papildyti duomenimis, tada tikslinės užklausos bus greitesnės. Tačiau vis tiek „ClickHouse“ nėra raktinių verčių duomenų bazė. Daug mažų užklausų yra apkrovos antipatternas.
Kirilas Švakovas: Patarsiu, jei ten bus paprastos sąskaitos. Tai gana standartinė situacija, kai ClickHouse saugo kažkokį skaitiklį. Turiu vartotoją, jis iš tokios ir tokios šalies, ir kažkokios trečios srities, ir man reikia pamažu kažką didinti. Paimkite MySQL, sukurkite unikalų raktą – MySQL tai yra pasikartojantis raktas, o PostgreSQL – konfliktas – ir pridėkite pliuso ženklą. Tai veiks daug geriau.
Kai neturite daug duomenų, nėra prasmės naudoti ClickHouse. Yra įprastų duomenų bazių ir jos tai daro gerai.
Ką galiu koreguoti ClickHouse, kad talpykloje būtų daugiau duomenų?
Įsivaizduokime situaciją - serveriai turi 256 GB RAM, kasdienėje rutinoje ClickHouse užima apie 60-80 GB, piko metu - iki 130. Ką galima įjungti ir pakoreguoti, kad talpykloje būtų daugiau duomenų ir atitinkamai ar yra mažiau kelionių į diską?
Paprastai operacinės sistemos puslapio talpykla atlieka gerą darbą. Jei tik atidarysite viršų, pažiūrėsite, kas yra talpykloje arba laisva – taip pat nurodoma, kiek yra talpykloje – tada pastebėsite, kad visa laisva atmintis naudojama talpyklai. Ir skaitant šiuos duomenis jie bus skaitomi ne iš disko, o iš RAM. Tuo pačiu galiu pasakyti, kad talpykla naudojama efektyviai, nes talpykloje saugomi suspausti duomenys.
Tačiau, jei norite dar labiau paspartinti kai kurias paprastas užklausas, „ClickHouse“ galite įjungti talpyklą išspaustuose duomenyse. Tai vadinama nesuspausta talpykla. Konfigūracijos faile config.xml nustatykite nesuspaustos talpyklos dydį į reikiamą reikšmę – rekomenduoju ne daugiau nei pusę laisvos RAM, nes likusi dalis pateks į puslapio talpyklą.
Be to, yra du užklausos lygio nustatymai. Pirmas nustatymas - naudoti nesuspaustą talpyklą - apima jo naudojimą. Rekomenduojama jį įjungti visoms užklausoms, išskyrus sunkias, kurios gali nuskaityti visus duomenis ir išvalyti talpyklą. Antrasis nustatymas yra panašus į maksimalų eilučių skaičių, skirtą naudoti talpyklą. Tai automatiškai apriboja dideles užklausas, kad jos apeitų talpyklą.
Kaip sukonfigūruoti storage_configuration saugojimui RAM?
Naujoje ClickHouse dokumentacijoje perskaičiau skyrių, susijusį . Aprašyme yra greito SSD pavyzdys.
Įdomu, kaip tą patį galima sukonfigūruoti naudojant garsumo karštąją atmintį. Ir dar vienas klausimas. Kaip Select veikia su šia duomenų organizacija, ar ji skaitys visą rinkinį ar tik tą, kuris yra diske, ir ar šie duomenys yra suglaudinti atmintyje? O kaip prewhere skyrius veikia su tokia duomenų organizacija?
Šis nustatymas turi įtakos duomenų gabalų saugojimui, o jų formatas jokiu būdu nesikeičia.
Pažiūrėkime atidžiau.
Galite konfigūruoti duomenų saugojimą RAM. Viskas, kas sukonfigūruota diske, yra jo kelias. Jūs sukuriate tmpfs skaidinį, kuris yra prijungtas prie tam tikro kelio failų sistemoje. Nurodote šį kelią kaip karščiausio skaidinio duomenų saugojimo kelią, pradės ateiti ir ten rašyti duomenų dalys, viskas gerai.
Tačiau nerekomenduoju to daryti dėl mažo patikimumo, nors jei turite bent tris kopijas skirtinguose duomenų centruose, tai įmanoma. Jei kas nors atsitiks, duomenys bus atkurti. Įsivaizduokime, kad serveris staiga buvo išjungtas ir vėl įjungtas. Pertvara buvo vėl sumontuota, bet ten nieko nebuvo. Kai ClickHouse serveris paleidžiamas, jis mato, kad jame nėra šių dalių, nors pagal ZooKeeper metaduomenis jie turėtų būti. Jis žiūri, kurios kopijos turi jas, paprašo jų ir atsisiunčia. Tokiu būdu duomenys bus atkurti.
Šia prasme duomenų saugojimas RAM iš esmės nesiskiria nuo jų saugojimo diske, nes įrašant duomenis į diską, jie taip pat pirmiausia patenka į puslapio talpyklą ir fiziškai įrašomi vėliau. Tai priklauso nuo failų sistemos montavimo parinkties. Bet tik tuo atveju pasakysiu, kad „ClickHouse“ nesinchronizuoja įterpiant.
Šiuo atveju duomenys RAM išsaugomi lygiai tokiu pat formatu kaip ir diske. Pasirinkimo užklausa tuo pačiu būdu atrenka dalis, kurias reikia perskaityti, parenka reikalingus duomenų diapazonus vienetuose ir juos nuskaito. Ir prewhere veikia lygiai taip pat, nepaisant to, ar duomenys buvo RAM, ar diske.
Iki kiek unikalių verčių yra efektyvus Low Cardinality?
Low Cardinality yra sumaniai sukurtas. Jis sudaro duomenų žodynus, tačiau jie yra vietiniai. Pirma, kiekvienam kūriniui yra skirtingi žodynai, antra, net ir viename gabale jie gali skirtis kiekvienam diapazonui. Kai unikalių reikšmių skaičius pasiekia slenkstinį skaičių – manau, milijoną – žodynas tiesiog nukeliamas į lentyną ir sukuriamas naujas.
Atsakymas yra bendras: kiekvienam vietiniam diapazonui - tarkime, kiekvienai dienai - kažkur iki milijono unikalių verčių Žemas kardinalumas yra veiksmingas. Vėliau bus tiesiog atsarginis variantas, kuriame bus naudojama daug skirtingų žodynų, o ne vienas. Jis veiks maždaug taip pat, kaip įprastas styginių stulpelis, galbūt šiek tiek mažiau efektyvus, tačiau nebus rimto veikimo pablogėjimo.
Kokie yra geriausi viso teksto paieškos lentelėje su penkiais milijardais eilučių praktika?
Yra įvairių atsakymų. Pirmiausia reikia pasakyti, kad ClickHouse nėra viso teksto paieškos sistema. Tam yra specialios sistemos, pvz. и . Tačiau vis dažniau matau žmonių, kurie sako, kad jie pereina nuo Elasticsearch prie ClickHouse.
Kodėl taip nutinka? Jie tai paaiškina tuo, kad Elasticsearch nustoja susidoroti su apkrova tam tikrais kiekiais, pradedant indeksų konstravimu. Indeksai tampa per daug gremėzdiški, o tiesiog perkėlus duomenis į ClickHouse, paaiškėja, kad pagal apimtį jie saugomi kelis kartus efektyviau. Tuo pačiu metu paieškos užklausos dažnai būdavo ne tokios, kad visame duomenų apimtyje, atsižvelgiant į morfologiją, reikėtų rasti kokią nors frazę, o visiškai kitokias. Pavyzdžiui, suraskite baitų seką žurnaluose per pastarąsias kelias valandas.
Tokiu atveju ClickHouse sukursite indeksą, kurio pirmas laukas bus data ir laikas. Didžiausias duomenų apribojimas bus pagrįstas dienų seka. Pasirinktoje datų diapazone, kaip taisyklė, jau galima atlikti viso teksto paiešką, net naudojant brute force metodą naudojant like. Panašus operatorius ClickHouse yra efektyviausias panašus operatorius, kurį galite rasti. Jei rasi ką nors geresnio, pasakyk.
Bet vis tiek, kaip ir pilnas nuskaitymas. Ir pilnas nuskaitymas gali būti lėtas ne tik CPU, bet ir diske. Jei staiga turite vieną terabaitą duomenų per dieną ir per dieną ieškote žodžio, turėsite nuskaityti terabaitą. Ir tai tikriausiai yra įprastuose kietuosiuose diskuose, ir galiausiai jie bus įkelti taip, kad negalėsite pasiekti šio serverio per SSH.
Šiuo atveju esu pasiruošęs pasiūlyti dar vieną mažą gudrybę. Tai eksperimentinė – gal pavyks, gali ir ne. „ClickHouse“ turi viso teksto indeksus trigramų „Bloom“ filtrų pavidalu. Mūsų kolegos iš „Arenadata“ jau išbandė šiuos indeksus ir dažnai veikia tiksliai taip, kaip numatyta.
Norėdami juos teisingai naudoti, turėtumėte gerai suprasti, kaip jie veikia: kas yra trigraminis Bloom filtras ir kaip pasirinkti jo dydį. Galiu pasakyti, kad jie padės užklausoms dėl kai kurių retų frazių, poeilučių, kurios retai randamos duomenyse. Tokiu atveju subdiapazonai bus parinkti pagal indeksus ir bus nuskaitoma mažiau duomenų.
Neseniai ClickHouse pridėjo dar daugiau pažangių viso teksto paieškos funkcijų. Visų pirma, tai yra kelių eilučių paieška vienu metu, įskaitant parinktis, kuriose skiriamos didžiosios ir mažosios raidės, palaikomos UTF-8 arba tik ASCII. Pasirinkite efektyviausią, kurio jums reikia.
Taip pat atsirado kelių reguliarių posakių paieška vienu žingsniu. Nereikia rašyti X kaip vienos poeilutės arba X kaip kitos poeilutės. Rašai iš karto, ir viskas daroma kuo efektyviau.
Trečia, dabar yra apytikslė reguliariųjų reiškinių paieška ir apytikslė poeilučių paieška. Jei kas nors neteisingai parašė žodį, bus ieškoma didžiausios atitikties.
Koks yra geriausias būdas organizuoti prieigą prie ClickHouse daugeliui vartotojų?
Papasakokite, kaip geriausiai organizuoti prieigą daugeliui vartotojų ir analitikų. Kaip sudaryti eilę, teikti pirmenybę maksimalioms lygiagrečioms užklausoms ir kokiais įrankiais?
Jei klasteris yra pakankamai didelis, tada geras sprendimas būtų pakelti dar du serverius, kurie taps analitikų įėjimo tašku. Tai yra, neleiskite analitikams pasiekti konkrečių klasterio skeveldrų, o tiesiog sukurkite du tuščius serverius be duomenų ir sukonfigūruokite juose prieigos teises. Tokiu atveju paskirstytų užklausų vartotojo nustatymai perkeliami į nuotolinius serverius. Tai yra, jūs konfigūruojate viską šiuose dviejuose serveriuose, o nustatymai turi įtakos visam klasteriui.
Iš principo šie serveriai neturi duomenų, tačiau užklausų vykdymui labai svarbus RAM kiekis juose. Diskas taip pat gali būti naudojamas laikiniems duomenims, jei įjungtas išorinis agregavimas arba išorinis rūšiavimas.
Svarbu pažvelgti į nustatymus, kurie yra susieti su visais įmanomais apribojimais. Jei dabar eisiu į „Yandex.Metrica“ klasterį kaip analitikas ir paprašysiu užklausos pasirinkite skaičių iš įvykių, tada man iš karto bus suteikta išimtis, kad negaliu įvykdyti prašymo. Didžiausias eilučių, kurias man leidžiama nuskaityti, skaičius yra šimtas milijardų, o iš viso jų vienoje klasterio lentelėje yra penkiasdešimt trilijonų. Tai pirmasis apribojimas.
Tarkime, pašalinsiu eilučių limitą ir paleidžiu užklausą dar kartą. Tada pamatysiu tokią išimtį – nustatymas įjungtas jėgos indeksas pagal datą. Negaliu užpildyti užklausos, jei nenurodžiau dienų sekos. Nereikia pasikliauti analitikais, kad tai nurodytumėte rankiniu būdu. Įprastas atvejis, kai įrašoma dienų seka, kai įvykio data yra tarp savaitės. Ir tada jie tiesiog nurodė skliaustą netinkamoje vietoje, o vietoj ir pasirodė, kad tai yra arba - arba URL atitiktis. Jei apribojimų nėra, jis nuskaitys URL stulpelį ir tik išeikvos daugybę išteklių.
Be to, ClickHouse turi du prioritetinius nustatymus. Deja, jie labai primityvūs. Vienas tiesiog vadinamas prioritetas. Jei prioritetas ≠ 0, o užklausos su tam tikru prioritetu vykdomos, bet vykdoma užklausa, kurios prioriteto reikšmė mažesnė už, o tai reiškia didesnį prioritetą, tada užklausa, kurios prioriteto reikšmė didesnė, o tai reiškia mažesnį prioritetą , yra tiesiog sustabdytas ir tuo metu visiškai neveiks.
Tai labai neapdorotas nustatymas ir netinka tais atvejais, kai klasteris turi nuolatinę apkrovą. Bet jei turite trumpų, masyvių užklausų, kurios yra svarbios, o klasteris dažniausiai neveikia, ši sąranka tinka.
Iškviečiamas kitas prioriteto nustatymas OS gijos prioritetas. Tai tiesiog nustato gražią visų užklausų vykdymo gijų, skirtų „Linux planuokliui“, vertę. Tai veikia taip ir taip, bet vis tiek veikia. Jei nustatysite mažiausią gražią reikšmę - ji yra didžiausia, taigi ir žemiausio prioriteto - ir nustatysite -19 užklausoms su aukštu prioritetu, tada procesorius sunaudos žemo prioriteto užklausas maždaug keturis kartus mažiau nei aukšto prioriteto.
Taip pat reikia sukonfigūruoti maksimalų užklausos vykdymo laiką – tarkime, penkias minutes. Minimalus užklausos vykdymo greitis yra šauniausias dalykas. Šis nustatymas egzistuoja jau seniai, todėl reikia ne tik tvirtinti, kad ClickHouse nesulėtėja, bet ir priversti.
Įsivaizduokite, jūs nustatėte: jei kuri nors užklausa apdoroja mažiau nei vieną milijoną eilučių per sekundę, to padaryti negalite. Tai sumenkina mūsų gerą vardą ir gerą duomenų bazę. Tiesiog uždrauskime tai. Iš tikrųjų yra du nustatymai. Vienas vadinamas min vykdymo greitis - eilutėmis per sekundę, o antrasis vadinamas skirtuoju laiku prieš tikrinant min. vykdymo greitį - pagal numatytuosius nustatymus penkiolika sekundžių. Tai yra, galima penkiolika sekundžių, o tada, jei tai lėta, tiesiog pateikite išimtį ir nutraukite užklausą.
Taip pat reikia nustatyti kvotas. ClickHouse turi integruotą kvotos funkciją, kuri skaičiuoja išteklių suvartojimą. Bet, deja, ne aparatūros ištekliai, tokie kaip centrinis procesorius, diskai, o loginiai - apdorotų užklausų, nuskaitytų eilučių ir baitų skaičius. Pavyzdžiui, galite sukonfigūruoti ne daugiau kaip šimtą užklausų per penkias minutes ir tūkstantį užklausų per valandą.
Kodėl tai svarbu? Kadangi kai kurios analizės užklausos bus atliekamos rankiniu būdu tiesiai iš ClickHouse kliento. Ir viskas bus gerai. Bet jei jūsų įmonėje yra pažengusių analitikų, jie parašys scenarijų ir gali būti scenarijaus klaida. Ir dėl šios klaidos užklausa bus vykdoma begaliniu ciklu. Štai nuo ko turime apsisaugoti.
Ar galima vienos užklausos rezultatus pateikti dešimčiai klientų?
Turime kelis vartotojus, kurie mėgsta tuo pačiu metu pateikti labai didelių užklausų. Prašymas yra didelis ir iš esmės greitai įvykdomas, tačiau dėl to, kad tokių prašymų yra daug vienu metu, tai tampa labai skausminga. Ar įmanoma tą pačią užklausą, kuri buvo gauta dešimt kartų iš eilės, įvykdyti vieną kartą ir pateikti rezultatą dešimčiai klientų?
Problema ta, kad neturime tarpinių duomenų talpyklos ar talpyklos rezultatų. Yra operacinės sistemos puslapio talpykla, kuri neleis jums vėl nuskaityti duomenų iš disko, bet, deja, duomenys vis tiek bus išspausti, deserializuoti ir apdoroti iš naujo.
Norėčiau kažkaip to išvengti, įkeldamas tarpinius duomenis arba sudėdamas panašias užklausas į kokią nors eilę ir pridėdamas rezultatų talpyklą. Šiuo metu kuriama viena ištraukimo užklausa, kuri prideda užklausų talpyklą, bet tik papildomoms užklausoms įvedimo ir prisijungimo skyriuose – tai yra, sprendimas neišsamus.
Tačiau susiduriame ir su tokia situacija. Ypač kanoninis pavyzdys yra puslapių užklausos. Yra ataskaita, ji turi kelis puslapius ir yra prašymas limito 10. Tada tas pats, bet limitas 10,10. Tada kitas kitas puslapis. Ir kyla klausimas, kodėl mes visa tai kiekvieną kartą skaičiuojame? Tačiau dabar sprendimo nėra ir nėra būdo jo išvengti.
Yra alternatyvus sprendimas, kuris dedamas kaip šoninė priekaba šalia ClickHouse - .
Kirilas Švakovas: „ClickHouse Proxy“ turi įmontuotą greičio ribotuvą ir įmontuotą rezultatų talpyklą. Ten buvo atlikta daug nustatymų, nes buvo sprendžiama panaši problema. Tarpinis serveris leidžia apriboti užklausas įtraukiant jas į eilę ir sukonfigūruoti, kiek laiko užklausų talpykla galioja. Jei užklausos tikrai buvo vienodos, Proxy jas išsiųs daug kartų, bet į ClickHouse pateks tik vieną kartą.
„Nginx“ taip pat turi talpyklą nemokamoje versijoje, ir tai taip pat veiks. „Nginx“ netgi turi nustatymus, pagal kuriuos, jei užklausos gaunamos tuo pačiu metu, ji sulėtins kitus, kol bus baigta. Tačiau „ClickHouse Proxy“ sąranka atliekama daug geriau. Jis buvo sukurtas specialiai ClickHouse, specialiai šioms užklausoms, todėl jis yra tinkamesnis. Na, tai lengva įdiegti.
Ką apie asinchronines operacijas ir materializuotus vaizdus?
Iškilo bėda, kad operacijos su pakartojimo varikliu vyksta asinchroniškai – iš pradžių įrašomi duomenys, paskui sutrinka. Jei po ženklu gyvena materializuota planšetė su tam tikrais agregatais, tada į ją bus rašomi dublikatai. Ir jei nėra sudėtingos logikos, tada duomenys bus dubliuojami. Ką galite padaryti dėl to?
Yra akivaizdus sprendimas – įdiegti trigerį tam tikroje matview klasėje asinchroninio sutraukimo operacijos metu. Ar yra kokių nors sidabrinių kulkų ar planų įdiegti panašias funkcijas?
Verta suprasti, kaip veikia deduplikacija. Tai, ką aš jums dabar pasakysiu, nėra susiję su klausimu, bet tik tuo atveju, jei verta prisiminti.
Įterpiant į pakartojamą lentelę, panaikinamas visų įterptų blokų dubliavimas. Jei iš naujo įterpiate tą patį bloką, kuriame yra toks pat skaičius tų pačių eilučių ta pačia tvarka, tada duomenys bus panaikinti. Atsakydami į įterpimą gausite „Gerai“, tačiau iš tikrųjų bus parašytas vienas duomenų paketas ir jis nebus dubliuojamas.
Tai būtina siekiant tikrumo. Jei įterpdami gaunate „Gerai“, vadinasi, jūsų duomenys buvo įterpti. Jei gaunate klaidą iš ClickHouse, tai reiškia, kad jie nebuvo įterpti ir turite pakartoti įterpimą. Bet jei įvedimo metu ryšys nutrūksta, tada jūs nežinote, ar duomenys buvo įterpti, ar ne. Vienintelė galimybė – pakartoti įterpimą. Jei duomenys iš tikrųjų buvo įterpti, o jūs juos įdėjote iš naujo, blokuojamas dubliavimas. Tai reikalinga norint išvengti pasikartojančių dalykų.
Taip pat svarbu, kaip tai veikia materializuotoms nuomonėms. Jei duomenys buvo panaikinti įterpiant į pagrindinę lentelę, jie taip pat nepateks į materializuotą rodinį.
Dabar apie klausimą. Jūsų situacija yra sudėtingesnė, nes įrašote atskirų eilučių dublikatus. Tai reiškia, kad dubliuojamas ne visas paketas, o konkrečios eilutės ir jos susitraukia fone. Iš tikrųjų duomenys sutrauks pagrindinėje lentelėje, bet nesutraukti duomenys pateks į materializuotą rodinį, o sujungimo metu materializuotiems rodiniams nieko neatsitiks. Nes materializuotas vaizdas yra ne kas kita, kaip įterpimo paleidiklis. Atliekant kitas operacijas jai nieko papildomai nevyksta.
Ir aš negaliu tavęs čia pradžiuginti. Jums tereikia ieškoti konkretaus sprendimo šiam atvejui. Pvz., ar galima pakartotinai paleisti jį materializuotame rodinyje, o dubliavimo panaikinimo metodas gali veikti taip pat. Bet, deja, ne visada. Jei jis sujungiamas, jis neveiks.
Kirilas Švakovas: Taip pat ankščiau turėjome ramentų statybą. Iškilo bėda, kad yra reklamos parodymai, ir yra keletas duomenų, kuriuos galime parodyti realiu laiku – tai tik parodymai. Jie retai kartojami, bet jei taip atsitiks, mes vis tiek vėliau juos sutrauksime. Ir buvo dalykų, kurių nepavyko dubliuoti – paspaudimai ir visa ši istorija. Bet aš taip pat norėjau juos parodyti beveik iš karto.
Kaip buvo suformuotos materializuotos pažiūros? Buvo rodinių, kur buvo rašoma tiesiogiai – buvo įrašyta į neapdorotus duomenis, o rašoma į rodinius. Ten tam tikru momentu duomenys nelabai teisingi, dubliuojasi ir pan. Ir yra antroji lentelės dalis, kurioje jie atrodo lygiai taip pat kaip materializuoti vaizdai, tai yra, jie yra visiškai identiški savo struktūra. Kartą perskaičiuojame duomenis, skaičiuojame duomenis be dublikatų, rašome į tas lenteles.
Perėjome per API – „ClickHouse“ rankiniu būdu tai neveiks. O API atrodo: kai turiu paskutinio papildymo datą prie lentelės, kur garantuotai jau paskaičiuoti teisingi duomenys ir daro užklausą į vieną lentelę ir į kitą lentelę. Iš vieno užklausa parenkama iki tam tikro laiko, o iš kito gaunama tai, kas dar neapskaičiuota. Ir tai veikia, bet ne tik per ClickHouse.
Jei turite kokią nors API - analitikams, vartotojams - tada iš esmės tai yra galimybė. Jūs visada skaičiuojate, visada skaičiuojate. Tai galima padaryti kartą per dieną arba kitu laiku. Jūs pasirenkate sau asortimentą, kurio jums nereikia ir kuris nėra kritinis.
ClickHouse turi daug žurnalų. Kaip iš pirmo žvilgsnio pamatyti viską, kas vyksta su serveriu?
„ClickHouse“ turi labai daug skirtingų žurnalų, ir šis skaičius didėja. Naujose versijose kai kurios iš jų netgi įjungtos pagal numatytuosius nustatymus, o senesnėse versijose jos turi būti įjungtos atnaujinant. Tačiau jų daugėja. Galiausiai norėčiau pamatyti, kas dabar vyksta su mano serveriu, galbūt kokioje nors suvestinės informacijos suvestinėje.
Ar turite „ClickHouse“ komandą arba jūsų draugų komandas, kurios palaiko tam tikras paruoštų prietaisų skydelių funkcijas, kuriose šie žurnalai būtų rodomi kaip gatavas produktas? Galų gale, tiesiog peržiūrėti žurnalus „ClickHouse“ yra puiku. Bet būtų labai šaunu, jei jis jau būtų paruoštas prietaisų skydelio pavidalu. Aš iš to gaučiau smūgį.
Yra prietaisų skydelių, nors jie nėra standartizuoti. Mūsų įmonėje „ClickHouse“ naudoja apie 60 komandų, o keisčiausia, kad daugelis jų turi sau pagamintus prietaisų skydelius ir kiek kitokius. Kai kurios komandos naudoja vidinį „Yandex.Cloud“ diegimą. Yra keletas paruoštų ataskaitų, nors ir ne visos reikalingos. Kiti turi savo.
Mano kolegos iš Metrica turi savo prietaisų skydelį Grafana, o aš turiu savo jų grupei. Aš žiūriu į tokius dalykus kaip „Serif“ talpyklos pataikė. O dar sunkiau, kad naudojame skirtingas priemones. Savo prietaisų skydelį sukūriau naudodamas labai seną įrankį, pavadintą „Graphite-web“. Jis visiškai bjaurus. Ir iki šiol taip naudoju, nors Grafana turbūt būtų patogiau ir gražiau.
Pagrindinis dalykas prietaisų skydeliuose yra tas pats. Tai yra klasterio sistemos metrika: CPU, atmintis, diskas, tinklas. Kiti – vienu metu pateikiamų užklausų skaičius, vienalaikių sujungimų skaičius, užklausų skaičius per sekundę, maksimalus MergeTree lentelės skaidinių gabalų skaičius, replikacijos delsa, replikacijos eilės dydis, įterptų eilučių skaičius per sekundę, įterptų blokų skaičius per sekundę. Tai viskas, kas gaunama ne iš žurnalų, o iš metrikų.
Vladimiras Kolobajevas: Aleksejus, norėčiau šiek tiek pataisyti. Yra Grafana. „Grafana“ turi duomenų šaltinį, kuris yra „ClickHouse“. Tai yra, galiu pateikti užklausas iš Grafana tiesiai į ClickHouse. ClickHouse turi lentelę su žurnalais, ji visiems vienoda. Todėl noriu pasiekti šią žurnalo lentelę Grafana ir pamatyti užklausas, kurias pateikia mano serveris. Būtų puiku turėti tokį prietaisų skydelį.
Pats važinėjau dviračiu. Bet turiu klausimą - jei visa tai standartizuota, o „Grafana“ naudoja visi, kodėl „Yandex“ neturi tokio oficialaus prietaisų skydelio?
Kirilas Švakovas: Tiesą sakant, „ClickHouse“ siunčiamas duomenų šaltinis dabar palaiko „Altinity“. Ir aš tik noriu duoti vektorių, kur kasti ir kam stumti. Galite jų paklausti, nes „Yandex“ vis dar gamina „ClickHouse“, o ne istoriją apie jį. „Altinity“ yra pagrindinė bendrovė, šiuo metu reklamuojanti „ClickHouse“. Jie jo neapleis, bet palaikys. Nes iš esmės norint įkelti prietaisų skydelį į Grafana svetainę, tereikia užsiregistruoti ir įkelti – jokių ypatingų problemų nėra.
Aleksejus Milovidovas: Per pastaruosius metus ClickHouse pridėjo daug užklausų profiliavimo galimybių. Kiekvienai užklausai dėl išteklių naudojimo yra metrika. Ir visai neseniai pridėjome dar žemesnio lygio užklausų profiliavimo priemonę, kad pamatytume, kur užklausa praleidžia kiekvieną milisekundę. Tačiau norint naudotis šia funkcija, turiu atidaryti konsolės klientą ir įvesti užklausą, kurią visada pamirštu. Kažkur išsaugojau ir vis pamirštu, kur tiksliai.
Norėčiau, kad būtų įrankis, kuris ką tik pasakytų: štai jūsų sunkios užklausos, sugrupuotos pagal užklausų klasę. Paspaudžiau vieną, ir jie man pasakytų, kad todėl jis sunkus. Dabar tokio sprendimo nėra. Ir tikrai gana keista, kad kai manęs klausia: „Pasakyk man, ar yra paruoštų „Grafana“ prietaisų skydelių?“, aš sakau: „Eikite į Grafana svetainę, ten yra „Dashboards“ bendruomenė ir yra prietaisų skydelis. iš Dimka, yra Kostyan prietaisų skydelis. Aš nežinau, kas tai yra, aš pats jo nenaudojau.
Kaip paveikti sujungimus, kad serveris nesudužtų į OOM?
Turiu lentelę, lentelėje yra tik vienas skaidinys, tai yra „ReplaceingMergeTree“. Duomenis į jį rašau jau ketverius metus. Man reikėjo jį pakeisti ir ištrinti kai kuriuos duomenis.
Aš tai padariau ir apdorojant šią užklausą, visa atmintis visuose klasterio serveriuose buvo sunaudota ir visi klasterio serveriai pateko į OOM. Tada jie visi atsistojo kartu, pradėjo sujungti tą pačią operaciją, šį duomenų bloką ir vėl pateko į OOM. Tada jie vėl pakilo ir vėl krito. Ir šis dalykas nesibaigė.
Tada paaiškėjo, kad tai iš tikrųjų buvo klaida, kurią vaikinai ištaisė. Tai labai šaunu, labai ačiū. Bet liko likutis. Ir dabar, kai galvoju apie kažkokį sujungimą lentelėje, man kyla klausimas – kodėl aš negaliu kažkaip paveikti šių sujungimų? Pavyzdžiui, apribokite juos pagal reikalingą RAM kiekį arba, iš esmės, pagal kiekį, kuris apdoros šią konkrečią lentelę.
Turiu lentelę pavadinimu „Metrika“, apdorokite ją dviem gijomis. Nereikia lygiagrečiai kurti dešimties ar penkių sujungimų, darykite tai dviese. Manau, kad atminties užtenka dviem, bet gali neužtekti apdoroti dešimt. Kodėl baimė išlieka? Kadangi lentelė auga ir kažkada susidursiu su situacija, kuri iš esmės nebe dėl klaidos, o dėl to, kad duomenys pasikeis taip dideliais kiekiais, kad man tiesiog neužteks atminties serveris. Tada serveris sujungs OOM. Be to, galiu atšaukti mutaciją, bet Merji nebėra.
Žinote, sujungiant serveris nepateks į OOM, nes sujungiant RAM kiekis išnaudojamas tik vienam nedideliam duomenų diapazonui. Taigi viskas bus gerai nepriklausomai nuo duomenų kiekio.
Vladimiras Kolobajevas: gerai. Čia momentas toks, kad ištaisęs klaidą, parsisiunčiau sau naują versiją, o ant kitos lentelės, mažesnės, kur daug skirsnių, padariau panašią operaciją. O sujungimo metu serveryje buvo sudeginta apie 100 GB RAM. Turėjau 150 užimtų, 100 suvalgytų ir 50 GB langą, todėl nepatekau į OOM.
Kas šiuo metu apsaugo mane nuo patekimo į OOM, jei iš tikrųjų sunaudoja 100 GB RAM? Ką daryti, jei staiga baigiasi sujungimo RAM?
Aleksejus Milovidovas: Yra tokia problema, kad RAM suvartojimas specialiai sujungimui nėra ribojamas. Ir antra problema yra ta, kad jei buvo priskirtas kažkoks sujungimas, tai jis turi būti vykdomas, nes tai įrašyta replikacijos žurnale. Replikacijos žurnalas yra veiksmai, kurių reikia, kad kopija būtų nuosekli. Jei neatliksite rankinių manipuliacijų, kurios atšauks šį replikacijos žurnalą, sujungimas turės būti atliktas vienaip ar kitaip.
Žinoma, nebūtų nereikalinga turėti RAM apribojimą, kuris „tik tuo atveju“ apsaugotų nuo OOM. Tai nepadės užbaigti sujungimo, jis prasidės iš naujo, pasieks tam tikrą slenkstį, padarys išimtį ir pradės iš naujo – nieko gero iš to nebus. Tačiau iš esmės būtų naudinga įvesti šį apribojimą.
Kaip bus sukurta „ClickHouse“ skirta „Golang“ tvarkyklė?
„Golang“ tvarkyklę, kurią parašė Kirilas Shvakovas, dabar oficialiai palaiko „ClickHouse“ komanda. Jis , jis dabar didelis ir tikras.
Maža pastaba. Yra nuostabi ir mylima normalių begalinės tvarkos formų saugykla – tai Vertica. Jie taip pat turi savo oficialią python tvarkyklę, kurią palaiko Vertica kūrėjai. Ir kelis kartus atsitiko, kad saugyklos versijos ir tvarkyklės versijos gana smarkiai skyrėsi, o tvarkyklė tam tikru momentu nustojo veikti. Ir antras punktas. Šio oficialaus vairuotojo palaikymą, man atrodo, vykdo „spenelių“ sistema - parašote jiems problemą, ir ji užstoja amžinai.
Turiu du klausimus. Dabar Kirill's Golang tvarkyklė yra beveik numatytasis būdas bendrauti iš Golango su ClickHouse. Nebent kas nors dar bendrautų per http sąsają, nes jam taip patinka. Kaip vyks šio vairuotojo kūrimas? Ar jis bus sinchronizuojamas su bet kokiais neveikiančiais pačios saugyklos pakeitimais? O kokia yra problemos svarstymo procedūra?
Kirilas Švakovas: Pirma, kaip viskas organizuojama biurokratiškai. Šis punktas nebuvo aptartas, todėl neturiu ką atsakyti.
Norėdami atsakyti į klausimą apie problemą, mums reikia šiek tiek vairuotojo istorijos. Dirbau įmonėje, kuri turėjo daug duomenų. Tai buvo reklaminis suktukas su daugybe įvykių, kuriuos reikėjo kažkur saugoti. Ir tam tikru momentu pasirodė ClickHouse. Užpildėme duomenis ir iš pradžių viskas buvo gerai, bet paskui ClickHouse sudužo. Tą akimirką nusprendėme, kad mums to nereikia.
Po metų grįžome prie idėjos naudoti ClickHouse ir mums reikėjo kažkaip ten įrašyti duomenis. Įžanginė žinutė buvo tokia: aparatinė įranga labai silpna, mažai išteklių. Bet mes visada taip dirbome, todėl žiūrėjome į gimtąjį protokolą.
Kadangi dirbome Go, buvo aišku, kad mums reikia Go vairuotojo. Dariau tai beveik visu etatu – tai buvo mano darbo užduotis. Mes jį atnešėme iki tam tikro taško, ir iš esmės niekas nemanė, kad juo naudosis kas nors kitas, išskyrus mus. Tada „CloudFlare“ atėjo su lygiai tokia pačia problema ir kurį laiką mes su jais dirbome labai sklandžiai, nes jie turėjo tas pačias užduotis. Be to, tai padarėme ir „ClickHouse“, ir su tvarkykle.
Kažkuriuo metu aš tiesiog nustojau tai daryti, nes mano veikla ClickHouse ir darbo atžvilgiu šiek tiek pasikeitė. Todėl klausimai nėra uždaryti. Periodiškai žmonės, kuriems ko nors reikia, patys įsipareigoja prie saugyklos. Tada žiūriu į ištraukimo užklausą ir kartais net pats ką nors redaguoju, bet taip nutinka retai.
Noriu grįžti pas vairuotoją. Prieš keletą metų, kai viskas prasidėjo, ClickHouse taip pat buvo kitoks ir su skirtingomis galimybėmis. Dabar mes suprantame, kaip pertvarkyti tvarkyklę, kad ji veiktų gerai. Jei taip atsitiks, 2 versija bet kokiu atveju bus nesuderinama dėl susikaupusių ramentų.
Aš nežinau, kaip organizuoti šį reikalą. Aš pats neturiu daug laiko. Jei kai kurie žmonės baigs vairuoti, galiu jiems padėti ir pasakyti, ką daryti. Tačiau aktyvus „Yandex“ dalyvavimas kuriant projektą dar nebuvo aptartas.
Aleksejus Milovidovas: Tiesą sakant, dėl šių vairuotojų dar nėra biurokratijos. Vienintelis dalykas yra tai, kad jie pateikiami oficialiai organizacijai, tai yra, ši tvarkyklė yra pripažinta oficialiu numatytuoju „Go“ sprendimu. Yra ir kitų vairuotojų, bet jie ateina atskirai.
Mes neturime jokio vidinio šių tvarkyklių tobulinimo. Kyla klausimas, ar galime pasamdyti pavienį žmogų ne šiam konkrečiam vairuotojui, o visų bendruomenės vairuotojų tobulėjimui, ar galime rasti ką nors iš išorės.
Išorinis žodynas neįkeliamas po perkrovimo, kai įjungtas lazy_load parametras. Ką daryti?
Įjungėme nustatymą lazy_load, o serveriui paleidus iš naujo, žodynas neįkeliamas savaime. Jis iškeliamas tik vartotojui prisijungus prie šio žodyno. Ir kai pirmą kartą prieinu prie jo, pasirodo klaida. Ar galima kažkaip automatiškai įkelti žodynus naudojant ClickHouse, ar visada reikia patiems kontroliuoti jų pasirengimą, kad vartotojai negautų klaidų?
Galbūt turime seną ClickHouse versiją, todėl žodynas nebuvo įkeltas automatiškai. Ar taip gali būti?
Pirma, žodynai gali būti priverstinai įkeliami naudojant užklausą sistemos perkrauti žodynus. Antra, dėl klaidos - jei žodynas jau įkeltas, užklausos veiks pagal įkeltus duomenis. Jei žodynas dar nebuvo įkeltas, jis bus įkeltas tiesiogiai užklausos metu.
Tai nėra labai patogu sunkiems žodynams. Pavyzdžiui, jums reikia ištraukti milijoną eilučių iš MySQL. Kažkas atlieka paprastą pasirinkimą, tačiau šis pasirinkimas lauks tų pačių milijonų eilučių. Čia yra du sprendimai. Pirmasis yra išjungti lazy_load. Antra, kai serveris veikia, prieš jį apkraunant, padarykite sistemos perkrovimo žodynas arba tiesiog atlikite užklausą naudodami žodyną. Tada žodynas bus įkeltas. Turite kontroliuoti žodynų prieinamumą su įjungtu lazy_load nustatymu, nes ClickHouse automatiškai jų neįkelia.
Atsakymas į paskutinį klausimą yra tai, kad versija yra sena, arba ją reikia derinti.
Ką daryti su tuo, kad sistemos perkrovimo žodynai neįkelia nė vieno iš daugelio žodynų, jei bent vienas iš jų sugenda su klaida?
Yra dar vienas klausimas dėl sistemos perkrovimo žodynų. Turime du žodynus – vienas neįkeltas, antras įkeltas. Tokiu atveju Sistemos perkrovimo žodynai neįkelia jokio žodyno, o konkretų žodyną reikia įkelti taškas po taško, naudodamiesi sistemos perkrovimo žodynu. Ar tai taip pat susiję su ClickHouse versija?
As noriu padaryti tave laimingu. Toks elgesys keitėsi. Tai reiškia, kad jei atnaujinsite ClickHouse, tai taip pat pasikeis. Jei nesate patenkintas savo dabartiniu elgesiu sistemos perkrauti žodynus, atnaujinkite ir tikėkimės, kad tai pasikeis į gerąją pusę.
Ar yra būdas sukonfigūruoti išsamią informaciją ClickHouse konfigūracijoje, bet nerodyti jos klaidų atveju?
Kitas klausimas yra apie klaidas, susijusias su žodynu, būtent detales. Žodyno „ClickHouse“ konfigūracijoje nurodėme prisijungimo duomenis, o jei įvyktų klaida, mes atsakysime į šiuos duomenis ir slaptažodį.
Išsprendėme šią klaidą pridėdami išsamios informacijos prie ODBC tvarkyklės konfigūracijos. Ar yra koks nors būdas sukonfigūruoti „ClickHouse“ konfigūracijos detales, bet nerodyti šios informacijos klaidų atveju?
Tikrasis sprendimas čia yra nurodyti šiuos kredencialus odbc.ini, o pačiame ClickHouse nurodyti tik ODBC duomenų šaltinio pavadinimą. To nenutiks kitiems žodyno šaltiniams – nei žodynui su MySQL, nei kitiems, gavę klaidos pranešimą neturėtumėte matyti slaptažodžio. Taip pat ieškosiu ODBC - jei jis yra, jums tereikia jį pašalinti.
Premija: mastelio keitimo fonai iš susibūrimų
Spustelėjus paveikslėlį atkakliausiems skaitytojams atsivers papildomi susibūrimų fonai. Gaisrą gesiname kartu su Avito technologijos talismanais, pasitariame su kolegomis iš sistemos administratoriaus kambario ar senosios mokyklos kompiuterių klubo, kasdien vedame susitikimus po tiltu grafičių fone.
Šaltinis: www.habr.com
