Dažu pÄdÄjo gadu laikÄ laikrindu datu bÄzes no neparastas lietas (ļoti specializÄtas, ko izmanto vai nu atvÄrtÄs uzraudzÄ«bas sistÄmÄs (un piesaistÄ«tas konkrÄtiem risinÄjumiem) vai lielo datu projektos) ir kļuvuÅ”as par "patÄriÅa produktu". Krievijas FederÄcijas teritorijÄ par to Ä«paÅ”s paldies jÄsaka Yandex un ClickHouse. LÄ«dz Å”im brÄ«dim, ja jums bija jÄuzglabÄ liels daudzums laikrindu datu, jums vai nu bija jÄsamierinÄs ar nepiecieÅ”amÄ«bu izveidot milzÄ«gu Hadoop steku un to uzturÄt, vai arÄ« sazinÄties ar katrai sistÄmai atseviŔķiem protokoliem.
Var Ŕķist, ka 2019. gadÄ raksts, par kuru ir vÄrts izmantot TSDB, sastÄvÄs tikai no viena teikuma: "vienkÄrÅ”i izmantojiet ClickHouse". Bet... ir nianses.
PatieÅ”Äm, ClickHouse aktÄ«vi attÄ«stÄs, lietotÄju bÄze aug, un atbalsts ir ļoti aktÄ«vs, bet vai esam kļuvuÅ”i par ClickHouse publisko panÄkumu Ä·Ä«lniekiem, kas ir aizÄnojuÅ”i citus, iespÄjams, efektÄ«vÄkus/uzticamÄkus risinÄjumus?
PagÄjuÅ”Ä gada sÄkumÄ sÄkÄm pÄrstrÄdÄt savu monitoringa sistÄmu, kuras laikÄ radÄs jautÄjums par datu glabÄÅ”anai piemÄrotas datu bÄzes izvÄli. Es gribu Å”eit runÄt par Ŕīs izvÄles vÄsturi.
ProblÄmas paziÅojums
PirmkÄrt, nepiecieÅ”ams priekÅ”vÄrds. KÄpÄc mums vispÄr ir vajadzÄ«ga sava uzraudzÄ«bas sistÄma un kÄ tÄ tika izveidota?
Atbalsta pakalpojumus sÄkÄm sniegt 2008. gadÄ, un lÄ«dz 2010. gadam kļuva skaidrs, ka ir grÅ«ti apkopot datus par klientu infrastruktÅ«rÄ notiekoÅ”ajiem procesiem ar tobrÄ«d pastÄvoÅ”ajiem risinÄjumiem (runa ir par Dievs piedod, Kaktusi, Zabbix un topoÅ”ais grafÄ«ts).
MÅ«su galvenÄs prasÄ«bas bija:
- atbalsts (tolaik - desmitiem, bet nÄkotnÄ - simtiem) klientu vienas sistÄmas ietvaros un vienlaikus centralizÄtas brÄ«dinÄjumu pÄrvaldÄ«bas sistÄmas klÄtbÅ«tne;
- brÄ«dinÄjuma sistÄmas pÄrvaldÄ«bas elastÄ«ba (brÄ«dinÄjumu eskalÄcija starp dežurantiem, grafiks, zinÄÅ”anu bÄze);
- spÄja dziļi detalizÄt grafikus (Zabbix tolaik grafikus renderÄja attÄlu veidÄ);
- liela datu apjoma ilgstoÅ”a uzglabÄÅ”ana (gadu vai ilgÄk) un iespÄja tos Ätri izgÅ«t.
Å ajÄ rakstÄ mÅ«s interesÄ pÄdÄjais punkts.
RunÄjot par uzglabÄÅ”anu, prasÄ«bas bija Å”Ädas:
- sistÄmai jÄdarbojas Ätri;
- vÄlams, lai sistÄmai bÅ«tu SQL interfeiss;
- sistÄmai jÄbÅ«t stabilai, un tai ir jÄbÅ«t aktÄ«vai lietotÄju bÄzei un atbalstam (kad mÄs saskÄrÄmies ar nepiecieÅ”amÄ«bu atbalstÄ«t tÄdas sistÄmas kÄ MemcacheDB, kas vairs netika izstrÄdÄta, vai MooseFS izplatÄ«tÄ krÄtuve, kuras kļūdu izsekotÄjs tika glabÄts Ä·Ä«nieÅ”u valodÄ: mÄs atkÄrtojam Å”o stÄstu mÅ«su projektam nevÄlÄjÄs);
- atbilstÄ«ba KLP teorÄmai: Konsekvence (obligÄti) - datiem jÄbÅ«t aktuÄliem, nevÄlamies, lai brÄ«dinÄjumu vadÄ«bas sistÄma nesaÅem jaunus datus un izspļauj brÄ«dinÄjumus par datu neienÄkÅ”anu visiem projektiem; Partition Tolerance (obligÄts) - mÄs nevÄlamies iegÅ«t Split Brain sistÄmu; PieejamÄ«ba (nav kritiska, ja ir aktÄ«va replika) - varam paÅ”i pÄrslÄgties uz rezerves sistÄmu avÄrijas gadÄ«jumÄ, izmantojot kodu.
SavÄdi, bet tajÄ laikÄ MySQL mums izrÄdÄ«jÄs ideÄls risinÄjums. MÅ«su datu struktÅ«ra bija ÄrkÄrtÄ«gi vienkÄrÅ”a: servera ID, skaitÄ«tÄja ID, laikspiedols un vÄrtÄ«ba; Ätru karsto datu iztverÅ”anu nodroÅ”inÄja liels bufera baseins, bet vÄsturisko datu iztverÅ”anu nodroÅ”inÄja SSD.
TÄdÄjÄdi mÄs panÄcÄm jaunu divu nedÄļu datu paraugu ar detalizÄtu informÄciju lÄ«dz sekundÄm 200 ms pirms datu pilnÄ«gas renderÄÅ”anas, un mÄs dzÄ«vojÄm Å”ajÄ sistÄmÄ diezgan ilgu laiku.
TikmÄr pagÄja laiks un pieauga datu apjoms. LÄ«dz 2016. gadam datu apjomi sasniedza desmitiem terabaitu, kas bija ievÄrojami izdevumi saistÄ«bÄ ar Ä«rÄtu SSD krÄtuvi.
LÄ«dz tam laikam jau bija aktÄ«vi izplatÄ«juÅ”Äs kolonnu datu bÄzes, par kurÄm sÄkÄm aktÄ«vi domÄt: kolonnu datubÄzÄs dati tiek glabÄti, kÄ noprotat, kolonnÄs, un, aplÅ«kojot mÅ«su datus, ir viegli redzÄt lielu dublikÄtu skaits, kas varÄtu bÅ«t Ja izmantojat kolonnu datu bÄzi, saspiest to, izmantojot saspieÅ”anu.
TomÄr uzÅÄmuma atslÄgas sistÄma turpinÄja darboties stabili, un es negribÄju eksperimentÄt ar pÄreju uz kaut ko citu.
2017. gadÄ Percona Live konferencÄ SanhosÄ Clickhouse izstrÄdÄtÄji, iespÄjams, pirmo reizi paziÅoja par sevi. No pirmÄ acu uzmetiena sistÄma bija gatava ražoÅ”anai (labi, Yandex.Metrica ir skarba ražoÅ”anas sistÄma), atbalsts bija Ätrs un vienkÄrÅ”s, un, pats galvenais, darbÄ«ba bija vienkÄrÅ”a. KopÅ” 2018. gada esam sÄkuÅ”i pÄrejas procesu. TaÄu lÄ«dz tam laikam bija daudz āpieauguÅ”oā un laika pÄrbaudÄ«tu TSDB sistÄmu, un mÄs nolÄmÄm veltÄ«t ievÄrojamu laiku un salÄ«dzinÄt alternatÄ«vas, lai pÄrliecinÄtos, ka Clickhouse nav alternatÄ«vu risinÄjumu atbilstoÅ”i mÅ«su prasÄ«bÄm.
Papildus jau noteiktajÄm uzglabÄÅ”anas prasÄ«bÄm ir parÄdÄ«juÅ”Äs jaunas:
- jaunajai sistÄmai ir jÄnodroÅ”ina vismaz tÄda pati veiktspÄja kÄ MySQL ar tÄdu paÅ”u aparatÅ«ras daudzumu;
- jaunÄs sistÄmas glabÄÅ”anai vajadzÄtu aizÅemt ievÄrojami mazÄk vietas;
- DBVS joprojÄm ir jÄbÅ«t viegli pÄrvaldÄmai;
- Mainot DBVS gribÄju aplikÄciju mainÄ«t minimÄli.
KÄdas sistÄmas mÄs sÄkÄm apsvÄrt?
Apache Hive/Apache Impala
Vecs, kaujÄs pÄrbaudÄ«ts Hadoop steks. BÅ«tÄ«bÄ tas ir SQL interfeiss, kura pamatÄ ir datu glabÄÅ”ana vietÄjos formÄtos HDFS.
Plusi.
- Ar stabilu darbÄ«bu datu mÄrogoÅ”ana ir ļoti vienkÄrÅ”a.
- Ir kolonnu risinÄjumi datu glabÄÅ”anai (mazÄk vietas).
- Ä»oti Ätra paralÄlu uzdevumu izpilde, kad ir pieejami resursi.
MÄ«nusi
- Tas ir Hadoop, un to ir grÅ«ti izmantot. Ja mÄs neesam gatavi uzÅemt gatavu risinÄjumu mÄkonÄ« (un mÄs neesam gatavi izmaksu ziÅÄ), visa kaudze bÅ«s jÄsaliek un jÄatbalsta ar administratoru rokÄm, un mÄs patieÅ”Äm nevÄlamies Å”is.
- Dati tiek apkopoti .
TomÄr:
Ätrums tiek sasniegts, mÄrogojot skaitļoÅ”anas serveru skaitu. VienkÄrÅ”i sakot, ja mÄs esam liels uzÅÄmums, kas nodarbojas ar analÄ«zi, un uzÅÄmumam ir ļoti svarÄ«gi apkopot informÄciju pÄc iespÄjas ÄtrÄk (pat par lielu skaitļoÅ”anas resursu izmantoÅ”anu), tÄ var bÅ«t mÅ«su izvÄle. TaÄu mÄs nebijÄm gatavi pavairot aparatÅ«ras parku, lai paÄtrinÄtu uzdevumu izpildi.
Druīds/Pinot
KonkrÄti ir daudz vairÄk par TSDB, bet atkal par Hadoop steku.
Ir .
Dažos vÄrdos: DruÄ«ds/Pinot izskatÄs labÄk nekÄ Clickhouse gadÄ«jumos, kad:
- Jums ir neviendabÄ«gs datu raksturs (mÅ«su gadÄ«jumÄ mÄs ierakstÄm tikai servera metrikas laikrindas, un patiesÄ«bÄ Å”Ä« ir viena tabula. Bet var bÅ«t arÄ« citi gadÄ«jumi: aprÄ«kojuma laikrindas, ekonomiskÄs laikrindas utt. ā katra ar sava struktÅ«ra, kas jÄapkopo un jÄapstrÄdÄ).
- TurklÄt Å”o datu ir daudz.
- ParÄdÄs un pazÅ«d tabulas un dati ar laikrindÄm (tas ir, daži datu kopumi tika saÅemti, tika analizÄti un izdzÄsti).
- Nav skaidru kritÄriju, pÄc kuriem datus var sadalÄ«t.
PretÄjÄ gadÄ«jumÄ ClickHouse darbojas labÄk, un tas ir mÅ«su gadÄ«jums.
NoklikŔķiniet uz MÄja
- SQL līdzīgi
- Viegli pÄrvaldÄ«t.
- CilvÄki saka, ka tas darbojas.
Tiek iekļauts testÄÅ”anas sarakstÄ.
InfluxDB
Ärzemju alternatÄ«va ClickHouse. No mÄ«nusiem: Augsta pieejamÄ«ba ir tikai komerciÄlajÄ versijÄ, taÄu tÄ ir jÄsalÄ«dzina.
Tiek iekļauts testÄÅ”anas sarakstÄ.
Cassandra
No vienas puses, mÄs zinÄm, ka to izmanto, lai saglabÄtu metrikas laikrindas tÄdÄs uzraudzÄ«bas sistÄmÄs kÄ, piemÄram, vai OkMeter. TomÄr ir specifika.
Cassandra nav kolonnu datubÄze tradicionÄlajÄ izpratnÄ. Tas vairÄk izskatÄs pÄc rindas skata, taÄu katrÄ rindÄ var bÅ«t atŔķirÄ«gs kolonnu skaits, tÄdÄjÄdi atvieglojot kolonnu skata organizÄÅ”anu. Å ajÄ ziÅÄ ir skaidrs, ka ar 2 miljardu kolonnu ierobežojumu ir iespÄjams saglabÄt dažus datus kolonnÄs (un tajÄs paÅ”Äs laikrindÄs). PiemÄram, MySQL ir 4096 kolonnu ierobežojums, un, mÄÄ£inot darÄ«t to paÅ”u, ir viegli paklupt uz kļūdu ar kodu 1117.
Cassandra dzinÄjs ir vÄrsts uz lielu datu apjomu glabÄÅ”anu sadalÄ«tÄ sistÄmÄ bez galvenÄ, un iepriekÅ” minÄtÄ Cassandra CAP teorÄma ir vairÄk par AP, tas ir, par datu pieejamÄ«bu un izturÄ«bu pret sadalÄ«Å”anu. TÄdÄjÄdi Å”is rÄ«ks var bÅ«t lielisks, ja jums ir nepiecieÅ”ams tikai rakstÄ«t Å”ajÄ datubÄzÄ un reti lasÄ«t no tÄs. Un Å”eit ir loÄ£iski izmantot Cassandra kÄ āaukstoā krÄtuvi. Tas ir, kÄ ilgtermiÅa, uzticama vieta liela apjoma vÄsturisko datu glabÄÅ”anai, kas ir reti nepiecieÅ”ami, bet vajadzÄ«bas gadÄ«jumÄ tos var izgÅ«t. TomÄr pilnÄ«bas labad mÄs arÄ« to pÄrbaudÄ«sim. Bet, kÄ jau teicu iepriekÅ”, nav vÄlmes aktÄ«vi pÄrrakstÄ«t izvÄlÄtÄ datu bÄzes risinÄjuma kodu, tÄpÄc mÄs to testÄsim nedaudz ierobežoti - nepielÄgojot datu bÄzes struktÅ«ru Cassandra specifikai.
Prometejs
Nu, ziÅkÄrÄ«bas pÄc nolÄmÄm pÄrbaudÄ«t Prometheus krÄtuves veiktspÄju ā lai saprastu, vai esam ÄtrÄki vai lÄnÄki par paÅ”reizÄjiem risinÄjumiem un par cik.
TestÄÅ”anas metodika un rezultÄti
TÄtad, mÄs pÄrbaudÄ«jÄm 5 datu bÄzes Å”ÄdÄs 6 konfigurÄcijÄs: ClickHouse (1 mezgls), ClickHouse (izplatÄ«ta tabula 3 mezgliem), InfluxDB, Mysql 8, Cassandra (3 mezgli) un Prometheus. PÄrbaudes plÄns ir Å”Äds:
- augÅ”upielÄdÄt vÄsturiskos datus par nedÄļu (840 miljoni vÄrtÄ«bu dienÄ; 208 tÅ«kstoÅ”i metrikas);
- mÄs Ä£enerÄjam ierakstÄ«Å”anas slodzi (tika Åemti vÄrÄ 6 slodzes režīmi, skatÄ«t zemÄk);
- ParalÄli ierakstÄ«Å”anai mÄs periodiski veicam atlasi, atdarinot ar diagrammÄm strÄdÄjoÅ”a lietotÄja pieprasÄ«jumus. Lai lietas pÄrÄk nesarežģītu, mÄs atlasÄ«jÄm datus 10 metrikÄm (tieÅ”i tik daudz ir CPU diagrammÄ) uz nedÄļu.
MÄs ielÄdÄjam, atdarinot mÅ«su uzraudzÄ«bas aÄ£enta darbÄ«bu, kas nosÅ«ta vÄrtÄ«bas katram rÄdÄ«tÄjam reizi 15 sekundÄs. TajÄ paÅ”Ä laikÄ mÄs esam ieinteresÄti dažÄdos veidos:
- kopÄjais metriku skaits, kurÄs tiek ierakstÄ«ti dati;
- intervÄls vÄrtÄ«bu nosÅ«tÄ«Å”anai uz vienu metriku;
- partijas lielums.
Par partijas lielumu. TÄ kÄ nav ieteicams gandrÄ«z visas mÅ«su eksperimentÄlÄs datu bÄzes ielÄdÄt ar atseviŔķiem ieliktÅiem, mums bÅ«s nepiecieÅ”ams relejs, kas apkopo ienÄkoÅ”os rÄdÄ«tÄjus un sagrupÄ tos grupÄs un ieraksta datu bÄzÄ kÄ pakeÅ”u ievietojumu.
TurklÄt, lai labÄk saprastu, kÄ pÄc tam interpretÄt saÅemtos datus, iedomÄsimies, ka mÄs ne tikai nosÅ«tÄm virkni metrikas, bet arÄ« metrika ir sakÄrtota serveros ā 125 metrika uz serveri. Å eit serveris ir vienkÄrÅ”i virtuÄla entÄ«tija ā lai saprastu, ka, piemÄram, 10000 80 metrikas atbilst aptuveni XNUMX serveriem.
Un Å”eit, Åemot vÄrÄ to visu, ir mÅ«su 6 datu bÄzes rakstÄ«Å”anas ielÄdes režīmi:
Å eit ir divi punkti. PirmkÄrt, Cassandra Å”ie partiju izmÄri izrÄdÄ«jÄs pÄrÄk lieli, tur mÄs izmantojÄm vÄrtÄ«bas 50 vai 100. Un, otrkÄrt, tÄ kÄ Prometheus darbojas stingri vilkÅ”anas režīmÄ, t.i. tas pats iet un apkopo datus no metrikas avotiem (un pat pushgateway, neskatoties uz nosaukumu, bÅ«tiski nemaina situÄciju), atbilstoÅ”Äs slodzes tika ieviestas, izmantojot statisko konfigurÄciju kombinÄciju.
PÄrbaudes rezultÄti ir Å”Ädi:
Kas ir vÄrts atzÄ«mÄt: fantastiski Ätri paraugi no Prometheus, Å”ausmÄ«gi lÄni sempli no Cassandra, nepieÅemami lÄni paraugi no InfluxDB; Ieraksta Ätruma ziÅÄ ClickHouse uzvarÄja visus, un Prometheus konkursÄ nepiedalÄs, jo pats taisa ieliktÅus un mÄs neko nemÄrÄm.
KÄ rezultÄtÄ,: ClickHouse un InfluxDB sevi parÄdÄ«ja kÄ labÄkos, bet klasteru no Influx var uzbÅ«vÄt tikai uz Enterprise versijas bÄzes, kas maksÄ naudu, savukÄrt ClickHouse neko nemaksÄ un tiek ražots KrievijÄ. LoÄ£iski, ka ASV izvÄle, iespÄjams, ir par labu inInfluxDB, un pie mums tÄ ir par labu ClickHouse.
Avots: www.habr.com