Në vitet e fundit, databazat e serive kohore (Time-series databases) janë transformuar nga një gjë e pazakontë (që aplikohej veçanërisht në sistemet e monitorimit të hapura, që lidhej me zgjidhje specifike, ose në projektet Big Data) në një "produkt të konsumit të përditshëm". Në territori i RF, për këtë duhet falenderuar veçanërisht Yandex dhe ClickHouse. Para kësaj, nëse kishit nevojë të ruani një sasi të madhe të të dhënave të serive kohore, ishit të detyruar ose të pranoni nevojën për të ngritur një stak monstër Hadoop dhe për ta mbajtur atë, ose të komunikoni me protokollet e veçanta për çdo sistem.
Mund të duket se në vitin 2019, artikulli në lidhje me atë se cila TSDB duhet të përdoret, do të përbëhet vetëm nga një frazë: "thjesht përdorni ClickHouse". Por... ka nuanca.
Në të vërtetë, ClickHouse po zhvillohet intensivisht, baza e përdoruesve po rritet dhe mbështetja po ofrohet shumë aktivisht, por a nuk kemi rënë viktimë e suksesit publik të ClickHouse, që ka mbizotëruar zgjidhje të tjera, ndoshta më efikase/ndihmuese?
Në fillim të vitit të kaluar, ne filluam ripërpunimin e sistemit tonë të monitorimit, gjatë procesit të të cilit u paraqit pyetja për zgjedhjen e një baze të përshtatshme për ruajtjen e të dhënave. Historia e kësaj zgjedhjeje është ajo që dëshiroj të ndaj këtu.
Vendosja e detyrës
Para sĂ« gjithash â njĂ« parafjalĂ« e nevojshme. Pse na duhej neve njĂ« sistem monitorimi dhe si ishte i organizuar?
Ne filluam të ofronim shërbime mbështetjeje në vitin 2008, dhe deri në vitin 2010 u bë e qartë se ishte e vështirë të grumbulloheshin të dhënat mbi proceset që ndodhnin në infrastrukturën e klientëve, me zgjidhjet që ishin të disponueshme në atë kohë (po flasim për, falni Zot, Cacti, Zabbix dhe Graphite që po fillonte të zhvillohej).
KĂ«rkesat tona kryesore ishin:
- mbĂ«shtetje pĂ«r (nĂ« atĂ« moment â dhjetĂ«ra, dhe nĂ« perspektivĂ« â qindra) klientĂ« brenda njĂ« sistemi dhe njĂ« kohĂ«shtu duhet tĂ« kishte njĂ« sistem qendror tĂ« menaxhimit tĂ« njoftimeve;
- fleksibilitet në menaxhimin e sistemit të njoftimeve (eskalimi i njoftimeve mes turneve, mbajtja e grafikut të orarit, baza e njohurive);
- mundësia për detajimin e thellë të grafikëve (Zabbix në atë kohë vizatonte grafikët si imazhe);
- ruajtje afatgjatë e një sasie të madhe të dhënash (një vit e më shumë) dhe mundësia e marrjes së shpejtë të tyre.
Në këtë artikull na intereson pika e fundit.
Duke folur për ruajtjen, kërkesat ishin si më poshtë:
- sistemi duhet të punojë shpejt;
- preferohet që sistemi të ketë një ndërfaqe SQL;
- sistemi duhet të jetë i qëndrueshëm dhe të ketë një bazë aktive përdoruesish dhe mbështetje (njëherë na ndodhi të mbështesim sisteme si MemcacheDB, që u ndal së zhvilluari, ose ruajtja e shpërndarë MooseFS, për të cilin bug-tracker ishte në kinezisht: nuk do dëshironim të 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Ă« tĂ« azhurnuara, nuk duam qĂ« sistemi i menaxhimit tĂ« njoftimeve tĂ« mos marrĂ« tĂ« dhĂ«na tĂ« reja dhe tĂ« lĂ«shojĂ« alarme pĂ«r mungesĂ«n e tĂ« dhĂ«nave nga tĂ« gjitha projektet; Partition Tolerance (e nevojshme) â nuk duam tĂ« pĂ«rfundojmĂ« me njĂ« sistem Split Brain; DisponueshmĂ«ria (jo kritike, nĂ« rast se ekziston njĂ« replikĂ« aktive) â mund tĂ« kalojmĂ« vetĂ« nĂ« sistemin rezervĂ« nĂ« rast emergjence, me kod.
Si e çuditshme, në atë moment, zgjidhja ideale për ne u bë MySQL. Struktura jonë e të dhënave ishte ekstremisht e thjeshtë: id e serverit, id e numrit të matësit, timestamp dhe vlera; marrja e shpejtë e të dhënave të nxehta u sigurua nga një madhësi e madhe e buffer pool, ndërsa marrja e të dhënave historike nga SSD.
Kështu, ne arritëm të merrnim të dhëna të freskëta dyjavore, me detaje deri në sekondë për 200 ms deri në momentin e plotë të vizatimit të të dhënave, dhe jetonim në këtë sistem për një kohë të gjatë.
Ndërkohë, koha kalonte dhe sasia e të dhënave rritej. Deri në vitin 2016, volumi i të dhënave arriti dhjetëra terabajt, që në kushtet e ruajtjes SSD me qira ishte një shpenzim të konsiderueshëm.
Në atë kohë, bazat e të dhënave kolona ishin përhapur gjerësisht, për të cilat filluam të mendojmë aktivisht: në bazat e të dhënave kolona, të dhënat ruhen, siç mund ta kuptoni, në kolona, dhe nëse i shikojmë të dhënat tona, lehtë mund të shohim një numër të madh kopjesh që do të mund të kompresoheshin në rastin e përdorimit të një baze të dhënash kolona.
Megjithatë, sistemi kyç për punën e kompanisë vazhdoi të funksionojë stabilisht, dhe nuk dëshironim të eksperimentohem me kalimin në diçka tjetër.
Në vitin 2017, në konferencën Percona Live në San Jose, zhvilluesit e Clickhouse, ndoshta për herë të parë, e shprehen veten. Në pamje të parë, sistemi dukej i gatshëm për prodhim (në të vërtetë, Yandex.Metrica është një prodhim i fortë), mbështetjeja ishte e shpejtë dhe e thjeshtë, dhe, më e rëndësishmja, eksploatimi ishte i lehtë. Që nga viti 2018, filluam procesin e kalimit. Por deri atëherë kishte shumë sisteme TSDB që kishin përvojë dhe ishin të provuara me kohë, prandaj vendosëm të kushtojmë një kohë të konsiderueshme dhe të krahasojmë alternativat, për t'u siguruar që nuk kishte zgjidhje alternative për Clickhouse që përputheshin me kërkesat tona.
Së bashku me kërkesat tashmë të përmendura për depot e të dhënave, u shfaqën edhe disa të reja:
- sistemi i ri duhet të sigurojë, të paktën, të njëjtin performancë si MySQL, me të njëjtën sasi harduari;
- depoja e sistemit të ri duhet të zë ndjeshëm më pak hapësirë;
- SGBD-në duhet të vazhdojë të jetë e lehtë për t'u menaxhuar;
- do të donim ta ndryshonim sa më pak aplikacionin gjatë kalimit në SGBD-në e re.
Cilat sisteme filluam të shqyrtojmë
Apache Hive/Apache Impala
Një stak Hadoop, i provuar nga lufta. Në thelb, kjo është një ndërfaqe SQL, e ndërtuar mbi ruajtjen e të dhënave në formate të veta në HDFS.
Pikat e forta.
- Me lehtëson shumë zgjerimin e të dhënave gjatë funksionimit të qëndrueshëm.
- Ka zgjidhje kolumne për ruajtjen e të dhënave (më pak hapësirë).
- Ekzekutim shumë i shpejtë i detyrave të paralelizuara në prani të burimeve.
Disavantazhet.
- Ky është Hadoop, dhe është i komplikuar për t'u administruar. Nëse nuk jemi të gatshëm të marrim një zgjidhje për këtë në re (dhe nuk jemi të gatshëm për shkak të kostos), e gjithë staku do të duhet të përbëhet dhe të mbështetet nga administratorët, dhe kjo është diçka që nuk e dëshirojmë.
- Të dhënat agregohen .
Megjithatë:
ShpejtĂ«sia arrihet duke zgjeruar numrin e serverĂ«ve tĂ« llogaritjes. Thjesht, nĂ«se ne jemi njĂ« kompani e madhe, merremi me analizĂ«n dhe pĂ«r biznesin Ă«shtĂ« kritikisht e rĂ«ndĂ«sishme tĂ« agregojmĂ« informacionin sa mĂ« shpejt tĂ« jetĂ« e mundur (edhe me kushtin e pĂ«rdorimit tĂ« burimeve tĂ« shumta tĂ« llogaritjes) â ky mund tĂ« jetĂ« zgjedhja jonĂ«. Por ne nuk ishim tĂ« gatshĂ«m tĂ« rritnim ndjeshĂ«m parku i pajisjeve pĂ«r shpejtĂ«sinĂ« e realizimit tĂ« detyrave.
Druid/Pinot
Tani Ă«shtĂ« shumĂ« mĂ« tepĂ«r pĂ«r TSDB-nĂ«, por pĂ«rsĂ«ri â stack-un Hadoop.
Ka .
Në disa fjalë: Druid/Pinot duken më mirë se ClickHouse në rastet kur:
- Keni njĂ« karakter tĂ« heterogjen tĂ« tĂ« dhĂ«nave (nĂ« rastin tonĂ«, ne regjistrojmĂ« vetĂ«m seritĂ« temporale tĂ« metrikave tĂ« serverĂ«ve, dhe, nĂ« thelb, kjo Ă«shtĂ« njĂ« tabelĂ«. Por mund tĂ« ketĂ« edhe raste tĂ« tjera: seritĂ« temporale tĂ« pajisjeve, seritĂ« ekonomike etj. â çdo njĂ«ra me strukturĂ«n e saj, qĂ« duhet tĂ« agregohen dhe pĂ«rpunohen).
- Megjithatë, këto të dhëna janë shumë të shumta.
- Tabelat dhe të dhënat me seritë temporale shfaqen dhe zhduken (pra, një grup i caktuar të dhënash erdhi, u analizua dhe u fshi).
- Nuk ka një kriter të qartë, sipas të cilit të dhënat mund të ndahen në pjesë.
Në raste të tjera, ClickHouse tregon performancë më të mirë, dhe kjo është rasti ynë.
ClickHouse
- Si SQL.
- E lehtë për menaxhim.
- Njerëzit thonë se funksionon.
Shkon në listën e shkurtër për testim.
InfluxDB
Një alternativë e huaj për ClickHouse. Nga disavantazhet: High Availability është në dispozitë vetëm në versionin komercial, por duhet të krahasohet.
Shkon 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, apo OkMeter. Megjithatë, ka specifika.
Cassandra nuk është një bazë të dhënash kolonash në kuptimin e saj tradicional. Duket më shumë si një bazë të dhënash rreshtash, por në çdo rresht mund të ketë një numër të ndryshëm kolonesh, duke e bërë të lehtë organizimin e një prezantimi kolonash. Në këtë kuptim, është e qartë se me një kufizim prej 2 miliard kolonesh, mund të ruhen disa të dhëna pikërisht në kolona (për shembull seritë temporale). Për shembull, në MySQL ka një kufizim prej 4096 kolonesh dhe aty është lehtë të hasësh një gabim me kodin 1117, nëse përpiqesh të bësh të njëjtën gjë.
Motorri Cassandra Ă«shtĂ« i fokusuar nĂ« ruajtjen e volumesh tĂ« mĂ«dha tĂ« dhĂ«nash nĂ« njĂ« sistem tĂ« shpĂ«rndarĂ« pa njĂ« master, dhe nĂ« teoremĂ«n e pĂ«rmendur CAP, Cassandra Ă«shtĂ« mĂ« shumĂ« nĂ« lidhje me AP, qĂ« do tĂ« thotĂ« disponueshmĂ«rinĂ« e dhĂ«nave dhe qĂ«ndrueshmĂ«rinĂ« ndaj ndarje-sĂ« sĂ« partitive. KĂ«shtu, ky instrument mund tĂ« jetĂ« i shkĂ«lqyer nĂ«se duhet tĂ« shkruani vetĂ«m nĂ« kĂ«tĂ« bazĂ« dhe lexoni mjaft rrallĂ« nga ajo. NĂ« kĂ«tĂ« rast, Ă«shtĂ« logjike tĂ« pĂ«rdoret Cassandra si njĂ« depo âtĂ« ftohtĂ«â. Pra, si njĂ« vend i besueshĂ«m pĂ«r ruajtjen e pĂ«rkohshme tĂ« sasisĂ« tĂ« madhe tĂ« dhĂ«nash historike, tĂ« cilat kĂ«rkohen rrallĂ«, por qĂ« mund tĂ« nxirren kur Ă«shtĂ« e nevojshme. MegjithatĂ«, pĂ«r tĂ« parĂ« tĂ« gjithĂ« pamjen, do ta testojmĂ« edhe atĂ«. Por, siç e kam thĂ«nĂ« mĂ« parĂ«, nuk kam dĂ«shirĂ« tĂ« riprogramoj aktivisht kodin pĂ«r zgjidhjen e zgjedhur tĂ« DB, kĂ«shtu qĂ« do ta testojmĂ« atĂ« nĂ« mĂ«nyrĂ« disi tĂ« kufizuar â pa adaptimin e strukturĂ«s sĂ« bazĂ«s sipas specifikave tĂ« Cassandra.
Prometheus
Po ashtu, nga kurioziteti, vendosĂ«m tĂ« testojmĂ« performancĂ«n e ruajtjes Prometheus â thjesht pĂ«r tĂ« kuptuar nĂ«se jemi mĂ« tĂ« shpejtĂ« se zgjidhjet aktuale apo mĂ« tĂ« ngadaltĂ« dhe sa.
Metodika dhe rezultatet e testimit
Pra fituam, ne kemi testuar 5 baza të dhënash në 6 konfiguracione të ndryshme: 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ëna historike për një javë (840 milion vlera në ditë; 208 mijë metrika);
- gjenerojmë ngarkesë në shkrim (kemi shqyrtuar 6 skema ngarkese, shih më poshtë);
- paralelisht me shkrimin, herë pas here bëjmë mostrat, duke simuluar pyetje nga përdoruesi që punon me grafike. Për të mos e komplikuar shumë, zgjodhëm të dhënat për 10 metrika (aq sa ka në grafikun e CPU) për javën.
Ngarkojmë, duke simuluar sjelljen e agjentit tonë të monitorimit, i cili dërgon në çdo metrikë vlerat çdo 15 sekonda. Në këtë rast, na intereson të varirojmë:
- numrin e përgjithshëm të metrikave që shkruhen të dhëna;
- intervalin e dërgimit të vlerave në një metrikë;
- shkëlqimin e paketës.
Për madhësinë e paketës. Duke qenë se pothuajse të gjitha bazat tona të testuara nuk rekomandohet të ngarkohen me inserte të vetme, na nevojitet një rregullator që mbledh metrikat e ardhura dhe i grupon për disa dhe i shkruan në bazë me inserte të paketuar.
Po ashtu, pĂ«r tĂ« kuptuar mĂ« mirĂ« se si tĂ« interpretojmĂ« tĂ« dhĂ«nat e marra, le tĂ« imagjinojmĂ« se nuk po dĂ«rgojmĂ« thjesht njĂ« grusht metrike, por metrike tĂ« organizuara nĂ« servera â 125 metrika pĂ«r server. KĂ«tu serveri Ă«shtĂ« thjesht njĂ« entitet virtual â nĂ« mĂ«nyrĂ« qĂ« tĂ« kuptojmĂ« se, pĂ«r shembull, 10000 metrika pĂ«rputhen nĂ« mĂ«nyrĂ« tĂ« pĂ«rafĂ«rt me rreth 80 servera.
Dhe tani, duke marrë parasysh gjithçka, kemi 6 modet e ngarkesës të bazës në shkrim:
Këtu janë dy aspekte. Së pari, për Cassandra këto dimensione të grupeve rezultuan tepër të mëdha, aty kemi përdorur vlera 50 ose 100. Dhe së dyti, përderisa Prometheus punon ndryshe në mënyrë pull, dmth. vetë shkon dhe merr të dhënat nga burimet e metrikeve (madje edhe pushgateway, pavarësisht emrit, nuk ndryshon asgjë), 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: seleksionet fantastikisht tĂ« shpejta nga Prometheus, seleksionet shqetĂ«suese tĂ« ngadalta nga Cassandra, seleksionet e pranueshme tĂ« ngadalta nga InfluxDB; nĂ« shpejtĂ«sinĂ« e shkrimit tĂ« gjithĂ« i ka fituar ClickHouse, ndĂ«rsa Prometheus nuk merr pjesĂ« nĂ« garĂ«, sepse ai bĂ«n insertin brenda vetes dhe ne nuk matim asgjĂ«.
Si rezultat: ClickHouse dhe InfluxDB kanĂ« treguar rezultate mĂ« tĂ« mira, por klasteri i Influx-it mund tĂ« ndĂ«rtohet vetĂ«m mbi versionin Enterprise, i cili kushton, ndĂ«rsa ClickHouse Ă«shtĂ« falas dhe Ă«shtĂ« zhvilluar nĂ« Rusi. ĂshtĂ« e logjikshme qĂ« nĂ« SHBA zgjedhja Ă«shtĂ« ndoshta nĂ« favor tĂ« InfluxDB, ndĂ«rsa kĂ«tu zgjedhim ClickHouse.
Burimi: habr.com
