Në vitet e fundit, bazat e të dhënave për seritë e kohës (Time-series databases) janë kthyer nga një gjë e pazakontë (e përdorur kryesisht në sisteme specifike monitorimi ose në projekte Big Data) në një "mall për konsum të gjerë". Në territorin e RF, një falënderim të veçantë duhet t'i lutemi Yandex-it dhe ClickHouse. Deri në këtë moment, nëse ju nevojitej të ruani një sasi të madhe të dhënash time-series, duhej ose të pajtoheshit me nevojën për të ngritur një stack monstruoz Hadoop dhe ta mirrni atë, ose të flisnit me protokolle, të cilat ishin individuale për çdo sistem.
Mund të duket se në vitin 2019, një artikull mbi atë se cila TSDB duhet të përdoret do të përbëhej vetëm nga një fjali: "thjesht përdorni ClickHouse." Por... ka nuanca.
Vërtet, ClickHouse po zhvillohet me shpejtësi, baza e përdoruesve po rritet, dhe mbështetja ofrohet shumë aktivisht, por a jemi bërë rob të suksesit publik të ClickHouse, i cili ka zënë hije për zgjidhje të tjera, ndoshta më efektive/për të besuara?
Në fillim të vitit të kaluar, ne filluam rishikimin e sistemit tonë të monitorimit, dhe gjatë procesit u shfaq një pyetje për të zgjedhur bazën e përshtatshme për ruajtjen e të dhënave. Historia e këtij zgjedhjeje është ajo që dua të ndaj këtu.
Formulimi i detyrës
SĂ« pari â njĂ« parathĂ«nie e domosdoshme. Pse na duhet njĂ« sistem monitorimi dhe si Ă«shtĂ« organizuar ai?
Ne filluam ofrimin e shĂ«rbimeve tĂ« mbĂ«shtetjes nĂ« vitin 2008, dhe deri nĂ« vitin 2010 u bĂ« e qartĂ« se ishte e vĂ«shtirĂ« tĂ« agregoheshin tĂ« dhĂ«nat mbi proceset qĂ« ndodhnin nĂ« infrastrukturĂ«n e klientit me zgjidhjet qĂ« ekzistonin nĂ« atĂ« kohĂ« (flasim pĂ«r, sâka gjĂ«, Cacti, Zabbix dhe Graphite-n nĂ« zhvillim).
KĂ«rkesat tona kryesore ishin:
- mbĂ«shtetje (nĂ« atĂ« moment â dhjetĂ«ra, dhe nĂ« perspektivĂ« â qindra) klientĂ«sh brenda njĂ« sistemi dhe gjithashtu tĂ« kishte njĂ« sistem tĂ« centralizuar menaxhimi tĂ« njoftimeve;
- fleksibilitet në menaxhimin e sistemit të njoftimeve (eskalimi i njoftimeve mes turneve, llogaritja e orarit, baza e njohurive);
- mundësia për detaje të thelluara në grafika (Zabbix në atë moment vizatonte grafika si imazhe);
- ruajtja e gjatë e një sasi të madhe të dhënash (një vit e më shumë) dhe mundësia e nxjerrjes së shpejtë të tyre.
Në këtë artikull na intereson pika e fundit.
Kurse për ruajtjen, kërkesat ishin si në vijim:
- sistemi duhet të punojë shpejt;
- preferohet që sistemi të ketë një ndërfaqe SQL;
- sistemi duhet të jetë stabil dhe të ketë një bazë aktive përdoruesish dhe mbështetje (dikur kemi përjetuar nevojën për të mbështetur sisteme si MemcacheDB, e cila u ndal përparimi, ose depërtimi i shpërndarë MooseFS, ku problemi dokumentohej në gjuhën kineze: nuk dëshironim ta përsërisnim këtë histori për projektin tonë);
- pĂ«rputhshmĂ«ria me teoremĂ«n CAP: Consistency (e nevojshme) â tĂ« dhĂ«nat duhet tĂ« jenĂ« aktuale, nuk duam qĂ« sistemi i menaxhimit tĂ« njoftimeve tĂ« mos marrĂ« tĂ« dhĂ«na tĂ« reja dhe tĂ« lĂ«shojĂ« alarme pĂ«r mungesĂ« tĂ« dhĂ«nash pĂ«r tĂ« gjithĂ« projektet; Partition Tolerance (e nevojshme) â nuk duam tĂ« kemi njĂ« sistem Split Brain; Availability (jo kritike, nĂ« raste tĂ« njĂ« replike aktive) â mund tĂ« kalojmĂ« vetĂ« nĂ« sistemin rezervĂ« nĂ« rast emergjence, me kod.
Siç ndodh shpesh, zgjidhja ideale pĂ«r ne nĂ« atĂ« moment ishte MySQL. Struktura jonĂ« e tĂ« dhĂ«nave ishte jashtĂ«zakonisht e thjeshtĂ«: id e serverit, id e numĂ«ruesit, timestamp dhe vlera; kĂ«rkimi i shpejtĂ« i tĂ« dhĂ«nave tĂ« nxehta arrihej me madhĂ«sinĂ« e madhe tĂ« buffer pool, ndĂ«rsa kĂ«rkimi i tĂ« dhĂ«nave historike â me SSD.
Në këtë mënyrë, arritëm të nxjerrim të dhënat e freskëta të dy javëve, me detaje deri në sekondë për 200 ms deri në momentin e plotë të vizatimit të të dhënave, dhe jetuam në këtë sistem për një kohë të gjatë.
Megjithatë, koha kalonte dhe sasia e të dhënave po rritej. Deri në vitin 2016, volumet e të dhënave arritën dhjetëra terabajt, që nën kushtet e ruajtjeve SSD në qira ishte një shpenzim substancial.
Në këtë moment, database kolonare ishin përhapur aktivisht, për të cilat filluam të mendonim seriozisht: në databazat kolonare të dhënat ruhen, siç mund ta kuptoni, në kolona, dhe nëse shikoni të dhënat tona, është e lehtë të shihni një numër të madh duplikatesh, të cilat mund të kompresohen në rastin e përdorimit të një database kolonare.
Megjithatë, sistemi kyç për funksionimin e kompanisë vazhdonte të punonte stabilisht, dhe nuk dëshironim të eksperimentonim me kalimin në diçka tjetër.
NĂ« vitin 2017, nĂ« konferencĂ«n Percona Live nĂ« San Jose, ndoshta pĂ«r herĂ« tĂ« parĂ« zhvilluesit e Clickhouse shpallĂ«n veten. NĂ« pamje tĂ« parĂ«, sistemi dukej i pĂ«rshtatshĂ«m pĂ«r prodhim (pĂ«r tĂ« qenĂ« tĂ« sinqertĂ«, Yandex.Metrica â Ă«shtĂ« njĂ« prodhim i vĂ«shtirĂ«), mbĂ«shtetja ishte e shpejtĂ« dhe e thjeshtĂ«, dhe mĂ« e rĂ«ndĂ«sishmja, operimi ishte i lehtĂ«. QĂ« nga viti 2018 filluam procesin e kalimit. Por nĂ« atĂ« kohĂ« kishte shumĂ« sisteme TSDB tĂ«
Në shtesë të kërkesave tashmë të përmendura për magazinimin, u shfaqën disa të reja:
- sistemi i ri duhet të ofrojë, të paktën, të njëjtin performancë si MySQL, në të njëjtin sasi hardueri;
- magazina e sistemit të ri duhet të marrë ndjeshëm më pak hapësirë;
- SGBD duhet të vazhdojë të jetë i thjeshtë për t'u menaxhuar;
- do të doja të ndryshoja sa më pak aplikacionin kur të kaloj te SGBD tjetër.
Cilat sisteme filluam të shqyrtonim
Apache Hive/ Apache Impala
Staku Hadoop, i provuar nga beteja. Në thelb, ky është një ndërfaqe SQL e ndërtuar mbi ruajtjen e të dhënave në formate specifike në HDFS.
PĂ«rfitimet.
- Me një funksionim të stabilizuar, është shumë e lehtë të shkallëzosh të dhënat.
- Ka zgjidhje kolonë për ruajtjen e të dhënave (më pak hapësirë).
- Ekzekutimi i shpejtë i detyrave të ndara kur ka burime.
Disavantazhet.
- Kjo është Hadoop, dhe është e ndërlikuar për t'u operuar. Nëse nuk jemi të gatshëm të marrim një zgjidhje të gatshme në cloud (dhe ne nuk jemi të gatshëm për shkak të kostos), e gjithë staku duhet të ndërtohet dhe mbështetet manualisht nga administratorët, dhe kjo nuk është diçka që dëshirojmë.
- Të dhënat agregohen .
Megjithatë:
ShpejtĂ«sia arrihet duke shkallĂ«zuar numrin e serverĂ«ve tĂ« pĂ«rpunimit. ThĂ«nĂ« ndryshe, nĂ«se jemi njĂ« kompani e madhe, merremi me analitikĂ«n dhe pĂ«r biznesin Ă«shtĂ« kritikisht e rĂ«ndĂ«sishme tĂ« agregojmĂ« informacionin sa mĂ« shpejt tĂ« jetĂ« e mundur (madje edhe me çmimin e pĂ«rdorimit tĂ« njĂ« sasie tĂ« madhe burimesh pĂ«rpunuese) â kjo mund tĂ« jetĂ« zgjedhja jonĂ«. Por ne nuk ishim tĂ« gatshĂ«m tĂ« rritnim ndjeshĂ«m numrin e harduerit pĂ«r shpejtĂ«sinĂ« e ekzekutimit tĂ« detyrave.
Druid/Pinot
Tani, shumĂ« mĂ« tepĂ«r pĂ«r konkret TSDB, por pĂ«rsĂ«ri â staku Hadoop.
Ka .
Në disa fjalë: Druid/Pinot duken më mirë se Clickhouse në raste kur:
- Ju keni një karakter heterogjen të të dhënave (në këtë rast ne regjistrojmë vetëm seri temporale të metrikave të serverëve, dhe, në thelb, kjo është një tabelë. Por mund të ketë raste të tjera: seri temporale të pajisjeve, seri temporale ekonomike, etj. - çdo njëra me strukturën e saj, të cilat duhet të agregohen dhe të përpunohen).
- Megjithatë, këto të dhëna janë shumë të shumta.
- Tabelat dhe të dhënat me seri temporale shfaqen dhe zhduken (domethënë, një grup i caktuar të dhënash ka ardhur, është analizuar dhe është fshirë).
- Nuk ka një kriter të qartë sipas të cilit të dhënat mund të ndahen në pjesë.
Në raste të tjera, ClickHouse tregon rezultate më të mira, dhe kjo është rasti ynë.
ClickHouse
- Përafërsisht si SQL.
- E lehtë për t'u menaxhuar.
- Njerëzit thonë se funksionon.
Bën pjesë në listën e shkurtër për testim.
InfluxDB
Alternativa ndërkombëtare për ClickHouse. Nga disavantazhet: Disponueshmëria e Lartë gjendet vetëm në versionin komercial, por duhet ta krahasojmë.
Bën pjesë në listën e shkurtër për testim.
Cassandra
Nga njëra anë, ne e dimë se përdoret për ruajtjen e serive temporale metrikore nga sisteme monitorimi si, për shembull, ose OkMeter. Megjithatë, ka disa veçori.
Cassandra nuk është një bazë të dhënash kolonore në kuptimin e zakonshëm të saj. Duket më shumë si thjesht një rresht, por në çdo rresht mund të ketë numra të ndryshëm kolonesh, çka lehtëson organizimin e përfaqësimit kolonor. Në këtë kuptim është e kuptueshme që me një kufizim prej 2 miliard kolonash, mund të ruhet disa të dhëna në kolonat (po ato seritë temporale). Për shembull, në MySQL ka një kufizim prej 4096 kolonash dhe atje është e lehtë të hasësh në gabimin me kod 1117, nëse përpiqesh të bësh të njëjtën gjë.
Motor Cassandra Ă«shtĂ« i orientuar pĂ«r ruajtjen e sasisĂ« sĂ« madhe tĂ« tĂ« dhĂ«nave nĂ« njĂ« sistem tĂ« shpĂ«rndarĂ« pa master, dhe nĂ« teoremĂ«n CAP tĂ« pĂ«rmendur mĂ« sipĂ«r, Cassandra Ă«shtĂ« mĂ« shumĂ« pĂ«r AP, pra pĂ«r disponueshmĂ«rinĂ« e tĂ« dhĂ«nave dhe qĂ«ndrueshmĂ«rinĂ« ndaj ndarjes sĂ« particioneve. KĂ«shtu, ky mjet mund tĂ« jetĂ« shumĂ« i pĂ«rshtatshĂ«m, nĂ«se ne duam tĂ« shkruajmĂ« vetĂ«m nĂ« kĂ«tĂ« bazĂ« dhe tĂ« lexojmĂ« mjaft rrallĂ« nga ajo. Dhe kĂ«tu ka logjikĂ« qĂ« ta pĂ«rdorim Cassandra si njĂ« âdepozitĂ« tĂ« ftohtĂ«â. KĂ«shtu, si njĂ« vend tĂ« besueshĂ«m pĂ«r ruajtjen afatgjatĂ« tĂ« sasisĂ« sĂ« madhe tĂ« tĂ« dhĂ«nave historike qĂ« kĂ«rkohen rrallĂ«, por nĂ« rast nevoje mund tĂ« nxirren. MegjithatĂ«, pĂ«r plotĂ«sinĂ« e imazhit, do ta testojmĂ« edhe atĂ«. Por, siç e kam thĂ«nĂ« mĂ« parĂ«, nuk kam dĂ«shirĂ« tĂ« rishkruaj aktivisht kodin pĂ«r zgjidhjen e zgjedhur tĂ« DB, prandaj do ta testojmĂ« atĂ« disi tĂ« kufizuar - pa adaptimin e strukturĂ«s sĂ« bazĂ«s sipas specifikave tĂ« Cassandra.
Prometheus
Pra, dhe tashmë nga kurioziteti, vendosëm të testojmë performancën e magazinës Prometheus - thjesht për të kuptuar nëse ne jemi më të shpejtë se zgjidhjet aktuale ose më të ngadaltë dhe sa.
Metodika dhe rezultatet e testimit
Pra, testuam 5 bazat e të dhënave në 6 konfigurime të mëposhtme: ClickHouse (1 nod), ClickHouse (tabela e shpërndarë në 3 node), InfluxDB, Mysql 8, Cassandra (3 node) dhe Prometheus. Plani i testimit është si më poshtë:
- ngarkojmë të dhënat historike për një javë (840 mln vlera në ditë; 208 mijë metrika);
- gjenerojmë ngarkesën për shkrim (kemi konsideruar 6 mënyra ngarkese, shih më poshtë);
- paralelisht me shkrimin, kryejmë përjashtime duke imituar pyetje nga përdoruesi, që punon me grafikët. Për të mos e komplikuar shumë, zgjedhim të dhënat për 10 metrika (aq sa janë në grafikun CPU) për një javë.
Ngarkojmë, duke imituar sjelljen e agjentit tonë të monitorimit, i cili dërgon në çdo metrikë vlera çdo 15 sekonda. Në këtë rast, na intereson të ndryshojmë:
- numri i përgjithshëm i metricave, në të cilat shkruhen të dhënat;
- intervali i dërgimit të vlerave në një metrikë;
- përmasat e grupit.
Përmasat e grupit. Duke qenë se pothuajse të gjitha bazat tona të studimit nuk rekomandojnë ngarkimin me inserte të vetme, do të na nevojitet një sistem që mbledh metrikat e ardhura dhe i grumbullon ato ndonjëherë dhe i shkruan në bazë me insert të paketuar.
Po kĂ«saj radhe, pĂ«r tĂ« kuptuar mĂ« mirĂ« si tĂ« interpretojmĂ« tĂ« dhĂ«nat e marrĂ« mĂ« vonĂ«, le tĂ« imagjinojmĂ« se nuk po dĂ«rgojmĂ« thjesht njĂ« mori metrikash, por metrikat janĂ« tĂ« organizuara nĂ« serverĂ« â me nga 125 metrika pĂ«r server. KĂ«tu serveri Ă«shtĂ« thjesht njĂ« entitet virtual â thjesht pĂ«r tĂ« kuptuar se, pĂ«r shembull, 10000 metrika pĂ«rputhen me rreth 80 serverĂ«.
Dhe tani, duke marrë parasysh të gjitha këto, kemi 6 modelet e ngarkesës për bazën në shkrim:
Këtu ka dy pika. Së pari, për Cassandra, këto madhësi grupesh rezultuan tepër të mëdha, aty ne përdorëm vlera 50 ose 100. Së dyti, duke qenë se Prometheus funksionon ngushtësisht në mënyrën pull, pra ai shkon dhe merr të dhëna nga burimet e metrikave (dhe madje pushgateway, pavarësisht emrit, nuk e ndryshon situatën thelbësisht), ngarkesat përkatëse u realizuan me një kombinim të konfigurimeve statike.
Rezultatet e testimit janë këto:
Ăka Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« theksohet: pĂ«rzgjedhjet jashtĂ«zakonisht tĂ« shpejta nga Prometheus, pĂ«rzgjedhjet tepĂ«r tĂ« ngadalta nga Cassandra, pĂ«rzgjedhjet e papranueshme tĂ« ngadalta nga InfluxDB; nĂ« shpejtĂ«sinĂ« e shkrimit, ClickHouse fitoi tĂ« gjitha garat, ndĂ«rsa Prometheus nuk mori pjesĂ«, sepse ai bĂ«n inserte brenda vetes dhe ne nuk matim asgjĂ«.
NĂ« fund: mĂ« mirĂ« se tĂ« gjithĂ« u treguan ClickHouse dhe InfluxDB, por njĂ« klaster nga Influx mund tĂ« ndĂ«rtohet vetĂ«m mbi bazĂ«n e versionit Enterprise, i cili ka njĂ« çmim, ndĂ«rsa ClickHouse nuk ka kosto dhe Ă«shtĂ« bĂ«rĂ« nĂ« Rusi. Logjikisht, nĂ« SHBA zgjedhja, ndoshta, do tĂ« ishte pĂ«r InfluxDB, ndĂ«rsa tek ne â pĂ«r ClickHouse.
Burimi: habr.com
