Per pastaruosius kelerius metus laiko eilučių duomenų bazės iš nepaprasto dalyko (labai specializuotos, naudojamos atvirose stebėjimo sistemose (ir susietos su konkrečiais sprendimais) arba didelių duomenų projektuose) virto „vartotojišku produktu“. Rusijos Federacijos teritorijoje už tai ypatinga padėka turi būti skirta „Yandex“ ir „ClickHouse“. Iki tol, jei jums reikėjo saugoti daug laiko eilučių duomenų, turėjote susitaikyti su būtinybe sukurti milžinišką „Hadoop“ krūvą ir ją prižiūrėti, arba bendrauti su kiekvienai sistemai atskirais protokolais.
Gali atrodyti, kad 2019 m. straipsnis, apie kurį verta naudoti TSDB, sudarys tik vieną sakinį: „tiesiog naudokite ClickHouse“. Bet... yra niuansų.
Išties „ClickHouse“ aktyviai vystosi, auga vartotojų ratas, o palaikymas labai aktyvus, tačiau ar tapome „ClickHouse“ viešos sėkmės įkaitais, kurie užgožė kitus, galbūt efektyvesnius/patikimesnius sprendimus?
Praėjusių metų pradžioje pradėjome pertvarkyti savo stebėjimo sistemą, kurios metu iškilo klausimas, kaip pasirinkti tinkamą duomenų bazę duomenims saugoti. Čia noriu pakalbėti apie šio pasirinkimo istoriją.
Problemos teiginys
Visų pirma būtina pratarmė. Kodėl mums apskritai reikia savo stebėjimo sistemos ir kaip ji buvo sukurta?
Pagalbos paslaugas pradėjome teikti 2008 m., o iki 2010 m. tapo aišku, kad su tuo metu egzistavusiais sprendimais (kalbame apie „atleisk Dieve“, „Cactus“, „Zabbix“) tapo sunku apibendrinti duomenis apie kliento infrastruktūroje vykstančius procesus. ir atsirandantis Grafitas).
Pagrindiniai mūsų reikalavimai buvo:
- palaikymas (tuo metu - dešimtys, o ateityje - šimtai) klientų vienoje sistemoje ir tuo pačiu centralizuotos perspėjimų valdymo sistemos buvimas;
- lankstumas valdant perspėjimo sistemą (perspėjimų eskalavimas tarp budinčių pareigūnų, tvarkaraštis, žinių bazė);
- gebėjimas giliai detalizuoti grafikus (Zabbix tuo metu grafikus teikė paveikslėlių pavidalu);
- ilgalaikis didelio duomenų kiekio saugojimas (metus ar daugiau) ir galimybė greitai juos atkurti.
Šiame straipsnyje mus domina paskutinis punktas.
Kalbant apie saugojimą, reikalavimai buvo tokie:
- sistema turi veikti greitai;
- pageidautina, kad sistema turėtų SQL sąsają;
- sistema turi būti stabili ir turėti aktyvią vartotojų bazę bei palaikymą (kartą jau susidūrėme su būtinybe palaikyti tokias sistemas kaip MemcacheDB, kuri nebebuvo sukurta, arba MooseFS paskirstyta saugykla, kurios klaidų sekimo priemonė buvo saugoma kinų kalba: kartojame šią istoriją mūsų projekto nenorėjo);
- atitikimas BŽŪP teoremai: Nuoseklumas (reikalingas) - duomenys turi būti atnaujinami, nenorime, kad perspėjimų valdymo sistema negautų naujų duomenų ir išspjautų perspėjimus apie visų projektų duomenų neatvykimą; Pasiskirstymo tolerancija (būtina) – nenorime gauti Split Brain sistemos; Prieinamumas (nekritinis, jei yra aktyvi replika) – galime patys persijungti į atsarginę sistemą įvykus nelaimei, naudodami kodą.
Kaip bebūtų keista, tuo metu MySQL mums pasirodė idealus sprendimas. Mūsų duomenų struktūra buvo labai paprasta: serverio ID, skaitiklio ID, laiko žyma ir vertė; greitą karštų duomenų atranką užtikrino didelis buferinis baseinas, o istorinių duomenų atranką – SSD.
Taigi, mes pasiekėme naujų dviejų savaičių duomenų pavyzdį, kurio detalumas buvo iki 200 ms, kol duomenys buvo visiškai pateikti, ir gyvenome šioje sistemoje gana ilgą laiką.
Tuo tarpu laikas bėgo ir duomenų kiekis augo. Iki 2016 m. duomenų apimtys siekė dešimtis terabaitų, o tai buvo didelės išlaidos nuomojamos SSD saugyklos kontekste.
Iki to laiko buvo aktyviai paplitę stulpelinės duomenų bazės, apie kurias pradėjome aktyviai galvoti: stulpelinėse duomenų bazėse duomenys saugomi, kaip suprantate, stulpeliuose, o pažvelgus į mūsų duomenis nesunku pamatyti didelį dublikatų skaičius, kuris gali būti Jei naudojate stulpelių duomenų bazę, suglaudinkite ją naudodami glaudinimą.
Tačiau įmonės raktų sistema ir toliau veikė stabiliai, ir aš nenorėjau eksperimentuoti, pereidamas prie kažko kito.
2017 metais „Percona Live“ konferencijoje San Chosėje „Clickhouse“ kūrėjai tikriausiai pirmą kartą paskelbė apie save. Iš pirmo žvilgsnio sistema buvo paruošta gamybai (na, „Yandex.Metrica“ yra griežta gamybos sistema), palaikymas buvo greitas ir paprastas, o svarbiausia – paprastas valdymas. Nuo 2018 m. pradėjome pereinamąjį procesą. Tačiau iki to laiko buvo daug „suaugusiesiems skirtų“ ir laiko patikrintų TSDB sistemų, todėl nusprendėme skirti nemažai laiko ir palyginti alternatyvas, kad įsitikintume, jog pagal mūsų reikalavimus nėra alternatyvių sprendimų Clickhouse.
Be jau nurodytų saugojimo reikalavimų, atsirado naujų:
- naujoji sistema turėtų užtikrinti bent tokį patį našumą kaip MySQL naudojant tą patį aparatinės įrangos kiekį;
- naujos sistemos saugykla turėtų užimti žymiai mažiau vietos;
- DBVS vis tiek turi būti lengvai valdoma;
- Keičiant DBVS norėjau pakeisti programą minimaliai.
Kokias sistemas pradėjome svarstyti?
Apache Hive / Apache Impala
Senas, mūšyje patikrintas Hadoop krūvas. Iš esmės tai yra SQL sąsaja, sukurta siekiant saugoti duomenis vietiniais formatais HDFS.
Argumentai už.
- Esant stabiliam veikimui, labai lengva keisti duomenis.
- Yra stulpelių sprendimų duomenų saugojimui (mažiau vietos).
- Labai greitas lygiagrečių užduočių vykdymas, kai yra išteklių.
Suvart
- Tai „Hadoop“ ir jį sunku naudoti. Jei nesame pasiruošę priimti paruošto sprendimo debesyje (o nesame pasiruošę sąnaudų prasme), visą krūvą turės surinkti ir palaikyti administratorių rankos, o mes tikrai nenorime tai.
- Duomenys yra apibendrinti .
Tačiau:
Greitis pasiekiamas keičiant skaičiavimo serverių skaičių. Paprasčiau tariant, jei esame didelė įmonė, užsiimame analitika ir verslui labai svarbu kuo greičiau sukaupti informaciją (net ir naudojant daug kompiuterinių išteklių), tai gali būti mūsų pasirinkimas. Tačiau mes nebuvome pasirengę padauginti techninės įrangos parko, kad paspartintume užduotis.
Druidas / Pinot
Yra daug daugiau konkrečiai apie TSDB, bet vėlgi, „Hadoop“ krūva.
Yra .
Keliais žodžiais: Druid / Pinot atrodo geriau nei Clickhouse tais atvejais, kai:
- Turite nevienalytį duomenų pobūdį (mūsų atveju įrašome tik serverio metrikos laiko eilutes, o iš tikrųjų tai yra viena lentelė. Tačiau gali būti ir kitų atvejų: įrangos laiko eilutės, ekonominės laiko eilutės ir kt. savo struktūrą, kurią reikia apibendrinti ir apdoroti).
- Be to, tokių duomenų yra labai daug.
- Lentelės ir duomenys su laiko eilutėmis atsiranda ir išnyksta (ty kai kurie duomenų rinkiniai atkeliavo, buvo išanalizuoti ir ištrinti).
- Nėra aiškaus kriterijaus, pagal kurį duomenys gali būti skaidomi.
Priešingais atvejais ClickHouse veikia geriau, ir tai yra mūsų atvejis.
„ClickHouse“
- Panašus į SQL
- Lengva valdyti.
- Žmonės sako, kad tai veikia.
Jis įtraukiamas į testavimo galutinį sąrašą.
InfluxDB
Užsienio alternatyva ClickHouse. Iš minusų: didelis prieinamumas yra tik komercinėje versijoje, tačiau jį reikia palyginti.
Jis įtraukiamas į testavimo galutinį sąrašą.
Kasandra
Viena vertus, mes žinome, kad jį naudoja tokios stebėjimo sistemos, kaip, pavyzdžiui, arba OkMeter. Tačiau yra specifikos.
„Cassandra“ nėra stulpelinė duomenų bazė tradicine prasme. Tai labiau atrodo kaip eilutės rodinys, tačiau kiekvienoje eilutėje gali būti skirtingas stulpelių skaičius, todėl lengva tvarkyti stulpelių rodinį. Šia prasme aišku, kad esant 2 milijardų stulpelių ribai, kai kuriuos duomenis galima saugoti stulpeliuose (ir tose pačiose laiko eilutėse). Pavyzdžiui, „MySQL“ yra 4096 stulpelių limitas, o jei bandote daryti tą patį, lengva aptikti klaidą su kodu 1117.
Cassandra variklis yra orientuotas į didelių duomenų kiekių saugojimą paskirstytoje sistemoje be pagrindinio kompiuterio, o minėta Cassandra CAP teorema yra daugiau apie AP, tai yra apie duomenų prieinamumą ir atsparumą skaidymui. Taigi, šis įrankis gali būti puikus, jei jums reikia tik rašyti į šią duomenų bazę ir retai iš jos skaityti. Ir čia logiška Cassandra naudoti kaip „šaltą“ saugyklą. Tai yra ilgalaikė ir patikima vieta dideliems istorinių duomenų kiekiams saugoti, kurių retai reikia, bet prireikus galima juos atkurti. Vis dėlto, siekdami išsamumo, mes jį taip pat išbandysime. Bet, kaip jau sakiau anksčiau, nėra noro aktyviai perrašyti pasirinkto duomenų bazės sprendimo kodo, todėl jį išbandysime kiek ribotai – nepritaikant duomenų bazės struktūros Cassandra specifikai.
Prometėjas
Na, o iš smalsumo nusprendėme išbandyti Prometheus saugyklos veikimą – kad tik suprastume, ar esame greitesni ar lėtesni už dabartinius sprendimus ir kiek.
Testavimo metodika ir rezultatai
Taigi, mes išbandėme 5 duomenų bazes šiose 6 konfigūracijose: ClickHouse (1 mazgas), ClickHouse (paskirstyta lentelė 3 mazgams), InfluxDB, Mysql 8, Cassandra (3 mazgai) ir Prometheus. Bandymo planas yra toks:
- įkelti savaitės istorinius duomenis (840 milijonų verčių per dieną; 208 tūkst. metrikų);
- generuojame įrašymo apkrovą (buvo atsižvelgta į 6 apkrovos režimus, žr. toliau);
- Lygiagrečiai su įrašymu mes periodiškai atliekame pasirinkimus, imituodami vartotojo, dirbančio su diagramomis, užklausas. Kad per daug neapsunkintume, savaitei atrinkome duomenis 10 metrikų (būtent tiek yra procesoriaus grafike).
Įkeliame mėgdžiodami savo stebėjimo agento elgesį, kuris siunčia reikšmes kiekvienai metrikai kartą per 15 sekundžių. Tuo pačiu metu mus domina įvairūs:
- bendras metrikų, į kurias įrašomi duomenys, skaičius;
- intervalas verčių siuntimui į vieną metriką;
- partijos dydis.
Apie partijos dydį. Kadangi nerekomenduojama beveik visų mūsų eksperimentinių duomenų bazių įkelti su pavieniais intarpais, mums reikės relės, kuri surenka gaunamus rodiklius ir sugrupuoja juos į grupes bei įrašo į duomenų bazę kaip paketinį įterpimą.
Be to, norėdami geriau suprasti, kaip tada interpretuoti gautus duomenis, įsivaizduokime, kad mes ne tik siunčiame krūvą metrikų, bet ir yra suskirstytos į serverius – 125 metrikos vienam serveriui. Čia serveris yra tiesiog virtualus subjektas – tik norint suprasti, kad, pavyzdžiui, 10000 80 metrikų atitinka apie XNUMX serverių.
Ir čia, atsižvelgiant į visa tai, yra mūsų 6 duomenų bazės rašymo įkėlimo režimai:
Čia yra du punktai. Pirma, Cassandrai šie partijų dydžiai pasirodė per dideli, ten naudojome 50 arba 100 vertes. Ir antra, kadangi Prometheus dirba griežtai traukimo režimu, t.y. ji pati eina ir renka duomenis iš metrikos šaltinių (ir net pushgateway, nepaisant pavadinimo, situacijos iš esmės nekeičia), atitinkamos apkrovos buvo įgyvendintos naudojant statinių konfigūracijų derinį.
Bandymo rezultatai yra tokie:
Į ką verta atkreipti dėmesį: fantastiškai greiti mėginiai iš Prometheus, siaubingai lėti mėginiai iš Cassandra, nepriimtinai lėti mėginiai iš InfluxDB; Pagal įrašymo greitį „ClickHouse“ laimėjo visus, o „Prometheus“ konkurse nedalyvauja, nes pats daro intarpus, o mes nieko nematuojame.
Kaip rezultatas,: „ClickHouse“ ir „InfluxDB“ pasirodė geriausi, tačiau „Influx“ klasterį galima sukurti tik „Enterprise“ versijos pagrindu, kuri kainuoja pinigus, o „ClickHouse“ nieko nekainuoja ir yra pagaminta Rusijoje. Logiška, kad JAV pasirinkimas tikriausiai yra inInfluxDB naudai, o pas mus – ClickHouse.
Šaltinis: www.habr.com