Undanfarin ár hafa tímaraðir gagnagrunnar breyst úr fráleitan hlut (mjög sérhæfður notaður annaðhvort í opnum vöktunarkerfum (og bundin við sérstakar lausnir) eða í stórgagnaverkefnum) í „neytendavöru“. Á yfirráðasvæði Rússlands ber að þakka Yandex og ClickHouse sérstaklega fyrir þetta. Fram að þessum tímapunkti, ef þú þurftir að geyma mikið magn af tímaröðgögnum, þurftir þú annað hvort að sætta þig við nauðsyn þess að smíða voðalegan Hadoop stafla og viðhalda honum, eða eiga samskipti við samskiptareglur fyrir hvert kerfi.
Það kann að virðast að árið 2019 muni grein um hvaða TSDB er þess virði að nota aðeins samanstanda af einni setningu: „notaðu bara ClickHouse. En... það eru blæbrigði.
Reyndar er ClickHouse í virkri þróun, notendahópurinn stækkar og stuðningur er mjög virkur, en erum við orðin gísl fyrir almennum velgengni ClickHouse, sem hefur skyggt á aðrar, ef til vill áhrifaríkari/áreiðanlegri lausnir?
Í byrjun síðasta árs hófum við endurvinnslu á eigin vöktunarkerfi þar sem spurningin vaknaði um að velja hentugan gagnagrunn til að geyma gögn. Mig langar að tala um sögu þessa vals hér.
Samsetning vandans
Fyrst af öllu, nauðsynlegur formála. Hvers vegna þurfum við okkar eigið eftirlitskerfi yfirleitt og hvernig var það hannað?
Við byrjuðum að veita stuðningsþjónustu árið 2008 og árið 2010 varð ljóst að það varð erfitt að safna saman gögnum um ferla sem eiga sér stað í innviðum viðskiptavinarins með þeim lausnum sem voru til á þeim tíma (við erum að tala um, Guð fyrirgefi mér, kaktusa, Zabbix og grafítið sem er að koma upp).
Helstu kröfur okkar voru:
- styðja (á þeim tíma - tugum og í framtíðinni - hundruð) viðskiptavina innan eins kerfis og á sama tíma tilvist miðlægs viðvörunarstjórnunarkerfis;
- sveigjanleiki í stjórnun viðvörunarkerfisins (aukning á viðvörunum milli vaktstjóra, tímasetningar, þekkingargrunnur);
- hæfileikinn til að gera smáatriði í línuritum (Zabbix á þeim tíma sýndi línurit í formi mynda);
- langtíma geymsla á miklu magni gagna (ár eða meira) og getu til að endurheimta þau fljótt.
Í þessari grein höfum við áhuga á síðasta atriðinu.
Talandi um geymslu þá voru kröfurnar sem hér segir:
- kerfið verður að virka hratt;
- æskilegt er að kerfið hafi SQL viðmót;
- Kerfið verður að vera stöðugt og hafa virkan notendagrunn og stuðning (einu sinni stóðum við frammi fyrir þörfinni á að styðja kerfi eins og MemcacheDB, sem var ekki lengur þróað, eða MooseFS dreifða geymsluna, en villurakjarinn var geymdur á kínversku: við endurtökum þessa sögu fyrir verkefnið okkar vildi ekki);
- samræmi við CAP setninguna: Consitency (krafist) - gögnin verða að vera uppfærð, við viljum ekki að viðvörunarstjórnunarkerfið fái ekki ný gögn og spýti út viðvörunum um að gögn berist ekki fyrir öll verkefni; Skiptingaþol (áskilið) - við viljum ekki fá skipt heilakerfi; Framboð (ekki mikilvægt, ef það er virk eftirmynd) - við getum sjálf skipt yfir í afritunarkerfið ef slys ber að höndum með því að nota kóða.
Merkilegt nokk, á þeim tíma reyndist MySQL vera tilvalin lausn fyrir okkur. Gagnauppbyggingin okkar var afar einföld: auðkenni netþjóns, teljaraauðkenni, tímastimpil og gildi; Hröð sýnataka af heitum gögnum var tryggð með stórum biðminni og sýnatöku á sögulegum gögnum var tryggð með SSD.
Þannig náðum við sýnishorni af ferskum tveggja vikna gögnum, með smáatriðum niður í sekúndu 200 ms áður en gögnin voru að fullu birt, og bjuggum í þessu kerfi í nokkuð langan tíma.
Á meðan leið tíminn og gagnamagnið jókst. Árið 2016 náði gagnamagn tugum terabæta, sem var verulegur kostnaður í samhengi við leigða SSD geymslu.
Á þessum tíma voru dálkagagnagrunnar orðnir virkir útbreiddir, sem við fórum að velta fyrir okkur: í dálkagagnagrunnum eru gögn geymd, eins og þú getur skilið, í dálkum og ef þú skoðar gögnin okkar er auðvelt að sjá stóra fjöldi afrita sem gæti, í Ef þú notar dálkagagnagrunn, þjappað honum með þjöppun.
Hins vegar hélt lykilkerfi fyrirtækisins áfram að virka stöðugt og ég vildi ekki gera tilraunir með að skipta yfir í eitthvað annað.
Árið 2017, á Percona Live ráðstefnunni í San Jose, tilkynntu Clickhouse verktaki líklega í fyrsta skipti. Við fyrstu sýn var kerfið framleiðslutilbúið (jæja, Yandex.Metrica er harðgert framleiðslukerfi), stuðningur var fljótur og einfaldur og síðast en ekki síst var aðgerðin einföld. Síðan 2018 höfum við hafið umbreytingarferlið. En á þeim tíma var mikið af „fullorðnum“ og tímaprófuðum TSDB kerfum og við ákváðum að verja töluverðum tíma og bera saman valkosti til að ganga úr skugga um að engar aðrar lausnir væru til við Clickhouse, í samræmi við kröfur okkar.
Til viðbótar við þegar tilgreindar kröfur um geymslu hafa nýjar birst:
- nýja kerfið ætti að veita að minnsta kosti sömu afköst og MySQL á sama magni af vélbúnaði;
- geymsla nýja kerfisins ætti að taka verulega minna pláss;
- DBMS verður samt að vera auðvelt að stjórna;
- Ég vildi breyta forritinu í lágmarki þegar ég breytti DBMS.
Hvaða kerfi byrjuðum við að huga að?
Apache Hive/Apache Impala
Gamall, bardagaprófaður Hadoop stafla. Í meginatriðum er það SQL viðmót byggt ofan á að geyma gögn á innfæddum sniðum á HDFS.
Kostir.
- Með stöðugri virkni er mjög auðvelt að skala gögn.
- Það eru dálkalausnir fyrir gagnageymslu (minna pláss).
- Mjög hröð framkvæmd samhliða verkefna þegar úrræði eru til staðar.
Gallar.
- Það er Hadoop og það er erfitt í notkun. Ef við erum ekki tilbúin að taka tilbúna lausn í skýinu (og við erum ekki tilbúin með tilliti til kostnaðar) verður að setja allan staflann saman og styðja af höndum stjórnenda, og við viljum í raun ekki þetta.
- Gögn eru tekin saman .
Hins vegar:
Hraði er náð með því að stækka fjölda tölvuþjóna. Einfaldlega sagt, ef við erum stórt fyrirtæki, þátt í greiningu, og það er mikilvægt fyrir fyrirtækið að safna upplýsingum eins fljótt og auðið er (jafnvel á kostnað þess að nota mikið magn af tölvuauðlindum), gæti þetta verið val okkar. En við vorum ekki tilbúin að fjölga vélbúnaðarflotanum til að flýta fyrir verkefnum.
Druid/Pinot
Það er miklu meira um TSDB sérstaklega, en aftur, Hadoop staflan.
Það er .
Í nokkrum orðum: Druid/Pinot líta betur út en Clickhouse í þeim tilvikum þar sem:
- Þú ert með misleitt eðli gagna (í okkar tilviki skráum við aðeins tímaraðir miðlaramælinga, og í raun er þetta ein tafla. En það geta verið önnur tilvik: tímaraðir búnaðar, efnahagslegar tímaraðir osfrv. - hvert með eigin uppbyggingu, sem þarf að safna saman og vinna úr).
- Þar að auki er mikið af þessum gögnum.
- Töflur og gögn með tímaröð birtast og hverfa (þ.e. eitthvað sett af gögnum kom, var greint og eytt).
- Það er engin skýr viðmiðun sem hægt er að skipta gögnum eftir.
Í öfugum tilfellum gengur ClickHouse betur og þetta er okkar mál.
smellahús
- SQL-líkt
- Auðvelt að stjórna.
- Fólk segir að það virki.
Fer á lista til að prófa.
InnstreymiDB
Erlendur valkostur við ClickHouse. Af göllum: High Availability er aðeins til staðar í auglýsingu útgáfu, en það þarf að bera saman.
Fer á lista til að prófa.
Cassandra
Annars vegar vitum við að það er notað til að geyma mælingartímaraðir af slíkum vöktunarkerfum eins og td. eða OkMeter. Hins vegar eru sérkenni.
Cassandra er ekki dálkagagnagrunnur í hefðbundnum skilningi. Það lítur meira út eins og raðmynd, en hver lína getur haft mismunandi fjölda dálka, sem gerir það auðvelt að skipuleggja dálka. Í þessum skilningi er ljóst að með hámarki upp á 2 milljarða dálka er hægt að geyma sum gögn í dálkum (og sömu tímaröð). Til dæmis, í MySQL er takmörk fyrir 4096 dálka og það er auðvelt að rekast á villu með kóða 1117 ef þú reynir að gera það sama.
Cassandra vélin einbeitir sér að því að geyma mikið magn af gögnum í dreifðu kerfi án meistara og ofangreind Cassandra CAP setning snýst meira um AP, það er um aðgengi að gögnum og viðnám gegn skiptingu. Þannig getur þetta tól verið frábært ef þú þarft aðeins að skrifa í þennan gagnagrunn og les sjaldan úr honum. Og hér er rökrétt að nota Cassandra sem „kalda“ geymslu. Það er, sem langtíma, áreiðanlegur staður til að geyma mikið magn af sögulegum gögnum sem sjaldan er þörf á, en hægt er að sækja ef þörf krefur. Engu að síður, til að vera fullkomnari, munum við prófa það líka. En, eins og ég sagði áðan, þá er engin löngun til að endurskrifa kóðann fyrir valda gagnagrunnslausnina á virkan hátt, svo við munum prófa hann nokkuð takmarkað - án þess að laga gagnagrunnsbygginguna að sérkennum Cassöndru.
Prometheus
Jæja, af forvitni ákváðum við að prófa frammistöðu Prometheus geymslu - bara til að skilja hvort við erum hraðari eða hægari en núverandi lausnir og hversu mikið.
Prófunaraðferðir og niðurstöður
Þannig að við prófuðum 5 gagnagrunna í eftirfarandi 6 stillingum: ClickHouse (1 hnút), ClickHouse (dreift tafla fyrir 3 hnúta), InfluxDB, Mysql 8, Cassandra (3 hnúta) og Prometheus. Prófunaráætlunin er sem hér segir:
- hlaðið upp sögulegum gögnum í viku (840 milljónir gilda á dag; 208 þúsund mæligildi);
- við búum til upptökuálag (6 hleðsluhamir voru teknir til greina, sjá hér að neðan);
- Samhliða upptöku gerum við reglulega val og líkjum eftir beiðnum notanda sem vinnur með töflur. Til að flækja hlutina ekki of mikið völdum við gögn fyrir 10 mælikvarða (það er nákvæmlega hversu mörg það eru á CPU línuritinu) í viku.
Við hleðst með því að líkja eftir hegðun eftirlitsaðila okkar, sem sendir gildi á hverja mælingu einu sinni á 15 sekúndna fresti. Á sama tíma höfum við áhuga á að breyta:
- heildarfjöldi mælikvarða sem gögn eru skráð í;
- bil til að senda gildi í einn mælikvarða;
- lotustærð.
Um lotustærð. Þar sem ekki er mælt með því að hlaða næstum öllum tilraunagagnagrunnum okkar með stökum innskotum, þá þurfum við gengi sem safnar mæligildum sem koma inn og flokkar þær í hópa og skrifar þær í gagnagrunninn sem runuinnskot.
Einnig, til að skilja betur hvernig á að túlka síðan móttekin gögn, skulum við ímynda okkur að við séum ekki bara að senda fullt af mælingum, heldur er mælingunum skipulögð í netþjóna - 125 mælingar á hvern netþjón. Hér er þjónninn einfaldlega sýndareining - bara til að skilja að til dæmis samsvara 10000 mælingum um 80 netþjónum.
Og hér, að teknu tilliti til alls þessa, eru 6 gagnagrunnshleðsluhamir okkar:
Hér eru tveir punktar. Í fyrsta lagi, fyrir Cassöndru, reyndust þessar lotustærðir vera of stórar, þar notuðum við gildi upp á 50 eða 100. Og í öðru lagi, þar sem Prometheus vinnur stranglega í togham, þ.e. það sjálft fer og safnar gögnum frá mæligildum (og jafnvel pushgateway, þrátt fyrir nafnið, breytir ekki ástandinu í grundvallaratriðum), samsvarandi álag var útfært með því að nota blöndu af kyrrstæðum stillingum.
Niðurstöður prófsins eru sem hér segir:
Hvað er vert að benda á: ótrúlega hröð sýni frá Prometheus, hræðilega hæg sýni frá Cassöndru, óviðunandi hæg sýni frá InfluxDB; Hvað upptökuhraða varðar þá vann ClickHouse alla og Prometheus tekur ekki þátt í keppninni, því það gerir sjálft innlegg og við mælum ekki neitt.
Þar af leiðandi,: ClickHouse og InfluxDB sýndu sig best, en þyrping frá Influx er aðeins hægt að byggja á grunni Enterprise útgáfunnar sem kostar peninga á meðan ClickHouse kostar ekkert og er framleitt í Rússlandi. Það er rökrétt að í Bandaríkjunum er valið líklega hlynnt inInfluxDB og í okkar landi er það hlynnt ClickHouse.
Heimild: www.habr.com