Alexander Valyalkin-en 2019 amaierako txostenaren transkripzioa irakurtzea gomendatzen dizut "Joan optimizazioak VictoriaMetrics-en"
β DBMS azkarra eta eskalagarria, datuak gordetzeko eta prozesatzeko denbora serie moduan (erregistroak denbora eta denbora horri dagozkion balio multzo bat osatzen du, adibidez, sentsoreen egoeraren aldizkako galdeketaren bidez edo bilketaren bidez lortutakoa. metrikoak).
Hona hemen erreportaje honen bideorako esteka -
Kontaiguzu zeure buruari buruz. Ni Alexander Valyalkin naiz. Hemen . Go eta errendimenduaren optimizazioa gogotsu nago. Liburutegi erabilgarriak eta ez hain erabilgarriak asko idatzi nituen. Biekin hasten dira fast, edo rekin quick aurrizkia.
Gaur egun VictoriaMetrics-en nabil. Zer da eta zertan ari naiz? Honetaz hitz egingo dut aurkezpen honetan.
Txostenaren eskema hau da:
- Lehenik eta behin, VictoriaMetrics zer den esango dizut.
- Orduan esango dizut zeintzuk diren denbora serieak.
- Ondoren, denbora serieen datu-base batek nola funtzionatzen duen kontatuko dizut.
- Jarraian, datu-basearen arkitekturaren berri emango dizut: zertan datzan.
- Eta gero pasa gaitezen VictoriaMetrics-ek dituen optimizazioetara. Hau alderantzizko indizearen optimizazioa da eta Go-n bitset inplementaziorako optimizazioa da.
Ikusleen artean inork ba al daki zer den VictoriaMetrics? Aupa, jende askok badaki jada. Berri ona da. Ezagutzen ez duenarentzat, hau denbora serieen datu-base bat da. ClickHouse arkitekturan oinarritzen da, ClickHouse ezarpenaren xehetasun batzuetan. Adibidez, adibidez: MergeTree, prozesadore-nukleo guztien kalkulu paraleloa eta errendimenduaren optimizazioa prozesadorearen cachean jartzen diren datu-blokeetan lan eginez.
VictoriaMetrics-ek datu-konpresio hobea eskaintzen du denbora serieko beste datu-baseek baino.
Bertikalean eskalatzen da, hau da, prozesadore gehiago, RAM gehiago ordenagailu batean gehi ditzakezu. VictoriaMetrics-ek erabilgarri dauden baliabide hauek arrakastaz erabiliko ditu eta produktibitate lineala hobetuko du.
VictoriaMetrics ere horizontalki eskalatzen da, hau da, VictoriaMetrics klusterrean nodo gehigarriak gehi ditzakezu eta bere errendimendua ia linealki handituko da.
Asmatu zenuenez, VictoriaMetrics datu-base azkarra da, ezin ditudalako beste batzuk idatzi. Eta Go-n idatzita dago, hortaz hitz egiten ari naiz topaketa honetan.
Nork daki zer den denbora serie bat? Jende asko ere ezagutzen du. Denbora seriea bikoteen serie bat da (timestamp, Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅), non bikote hauek denboraren arabera ordenatuta dauden. Balioa koma mugikorreko zenbaki bat da - float64.
Denbora-serie bakoitza gako baten bidez identifikatzen da. Zertan datza giltza hau? Gako-balio bikoteen multzo ez huts batek osatzen du.
Hona hemen denbora serie baten adibide bat. Serie honen gakoa bikoteen zerrenda bat da: __name__="cpu_usage" metrikaren izena da, instance="my-server" - Hau da metrika hau biltzen den ordenagailua, datacenter="us-east" - hau da ordenagailu hau dagoen datu-zentroa.
Hiru gako-balio bikotez osatutako denbora seriearen izena lortu genuen. Gako hau bikoteen zerrenda bati dagokio (timestamp, value). t1, t3, t3, ..., tN - Hauek denbora-zigiluak dira, 10, 20, 12, ..., 15 β dagozkion balioak. Hau da serie jakin baterako une jakin batean CPU-erabilera.
Non erabil daitezke denbora serieak? Inork ba al du ideiarik?
- DevOps-en, CPU, RAM, sarea, rps, errore kopurua, etab neur ditzakezu.
- IoT - tenperatura, presioa, geokoordenatuak eta beste zerbait neur ditzakegu.
- Finantza ere: era guztietako izakinen eta monetaren prezioak kontrola ditzakegu.
- Horrez gain, fabriketako ekoizpen-prozesuen jarraipena egiteko denbora serieak erabil daitezke. VictoriaMetrics aerosorgailuak kontrolatzeko erabiltzen duten erabiltzaileak ditugu, robotentzat.
- Denbora serieak ere erabilgarriak dira hainbat gailutako sentsoreetatik informazioa biltzeko. Adibidez, motor baterako; pneumatikoen presioa neurtzeko; abiadura, distantzia neurtzeko; gasolina-kontsumoa neurtzeko, etab.
- Denbora serieak hegazkinak kontrolatzeko ere erabil daitezke. Hegazkin bakoitzak kutxa beltz bat du, hegazkinaren osasunaren hainbat parametroren denbora-serieak biltzen dituena. Denbora-serieak industria aeroespazialean ere erabiltzen dira.
- Osasuna odol-presioa, pultsua, etab.
Agian ahaztu zaizkidan aplikazio gehiago egon daitezke, baina espero dut ulertzea denbora-serieak aktiboki erabiltzen direla mundu modernoan. Eta haien erabileraren bolumena hazten ari da urtero.
Zergatik behar duzu denbora serieen datu-base bat? Zergatik ezin duzu ohiko datu-base erlazional bat erabili denbora serieak gordetzeko?
Denbora-serieek informazio kopuru handia izan ohi dutelako, ohiko datu-baseetan gorde eta prozesatzen zaila dena. Horregatik, denbora serieetarako datu-base espezializatuak agertu ziren. Oinarri hauek modu eraginkorrean gordetzen dituzte puntuak (timestamp, value) emandako gakoarekin. API bat eskaintzen dute gordetako datuak gakoaren arabera, gako-balio bikote bakar baten bidez edo hainbat gako-balio bikoteen bidez edo adierazpen erregularraren arabera. Adibidez, zure zerbitzu guztien CPU karga aurkitu nahi duzu Ameriketako datu-zentro batean, eta sasi-kontsulta hau erabili behar duzu.
Normalean denbora-serieen datu-baseek kontsulta-lengoaia espezializatuak eskaintzen dituzte denbora-serie SQL ez baita oso egokia. SQL onartzen duten datu-baseak badaude ere, ez da oso egokia. Kontsulta hizkuntzak, esaterako , , , . Espero dut norbaitek gutxienez hizkuntza horietako bat entzun izana. Jende askok PromQLri buruz entzun du ziurrenik. Hau Prometheus kontsulta-lengoaia da.
Hauxe da denbora serieen datu-baseen arkitektura moderno batek VictoriaMetrics adibide gisa erabiliz.
Bi zatiz osatuta dago. Alderantzizko indizearen biltegiratzea da eta denbora-serieen balioen biltegiratzea. Biltegi hauek bereizita daude.
Erregistro berri bat datu-basera iristen denean, lehenik alderantzizko indizera sartzen gara multzo jakin baterako denbora-seriearen identifikatzailea aurkitzeko. label=value metrika jakin baterako. Identifikatzaile hau aurkitzen dugu eta balioa datu biltegian gordetzen dugu.
TSDBko datuak berreskuratzeko eskaera bat datorrenean, lehenik alderantzizko indizera joaten gara. Lor dezagun dena timeseries_ids multzo honekin bat datozen erregistroak label=value. Eta gero datu biltegitik beharrezko datu guztiak eskuratzen ditugu, indexatuta timeseries_ids.
Ikus dezagun denbora serieen datu-base batek sarrerako aukeraketa kontsulta bat nola prozesatzen duen erakusten duen adibide bat.
- Lehenik eta behin dena lortzen du
timeseries_idsemandako bikoteak dituen alderantzizko indize batetiklabel=value, edo emandako adierazpen erregular bat bete. - Ondoren, datuen biltegitik datu-puntu guztiak berreskuratzen ditu aurkitutakoen denbora-tarte jakin batean
timeseries_ids. - Horren ostean, datu-baseak kalkulu batzuk egiten ditu datu-puntu horietan, erabiltzailearen eskaeraren arabera. Eta horren ostean erantzuna itzultzen du.
Aurkezpen honetan lehenengo zatiaren berri emango dizuet. Hau bilaketa bat da timeseries_ids alderantzizko indizearen bidez. Bigarren zatia eta hirugarren zatia geroago ikusi ahal izango dituzu , edo itxaron beste txosten batzuk prestatu arte :)
Joan gaitezen alderantzizko indizera. Askok pentsa dezakete hori erraza dela. Nork daki zer den alderantzizko indize bat eta nola funtzionatzen duen? Oh, jada ez hainbeste jende. Saia gaitezen zer den ulertzen.
Benetan sinplea da. Balore bati gako bat mapatzen dion hiztegi bat besterik ez da. Zer da giltza? Bikote hau label=valueNon label ΠΈ value - hauek lerroak dira. Eta balioak multzo bat dira timeseries_ids, emandako bikotea barne hartzen duena label=value.
Alderantzizko indizeak dena azkar aurkitzeko aukera ematen du timeseries_ids, eman dutenak label=value.
Gainera, azkar aurkitzeko aukera ematen du timeseries_ids hainbat bikoterentzat denbora seriea label=value, edo bikoteentzat label=regexp. Nola gertatzen da hau? Multzoaren ebakidura aurkituz timeseries_ids bikote bakoitzeko label=value.
Ikus ditzagun alderantzizko indizearen hainbat ezarpen. Has gaitezen inplementazio inozoenetik. Honela dirudi.
Funtzioa getMetricIDs kateen zerrenda lortzen du. Lerro bakoitzak dauka label=value. Funtzio honek zerrenda bat itzultzen du metricIDs.
Nola dabil? Hemen dugu izeneko aldagai global bat invertedIndex. Hau ohiko hiztegi bat da (map), katea mapatuko duena ints zatitzeko. Lerroak dauka label=value.
Funtzioaren ezarpena: lortu metricIDs lehenengorako label=value, gero gainontzeko guztia pasatzen dugu label=value, lortzen dugu metricIDs haientzat. Eta deitu funtzioari intersectInts, jarraian aztertuko dena. Eta funtzio honek zerrenda horien ebakidura itzultzen du.
Ikus dezakezunez, alderantzizko indize bat ezartzea ez da oso zaila. Baina hau inplementazio inozoa da. Zein desabantaila ditu? Inplementazio inozoaren desabantaila nagusia indize alderantzikatu bat RAM-n gordetzen dela da. Aplikazioa berrabiarazi ondoren indize hau galtzen dugu. Ez dago indize hau diskoan gordetzen. Alderantzizko indize hori nekez izango da datu-base baterako egokia.
Bigarren eragozpena memoriarekin ere lotuta dago. Alderantzizko indizea RAM-an sartu behar da. RAMaren tamaina gainditzen badu, jakina, memoria-errorea aterako dugu. Eta programak ez du funtzionatuko.
Arazo hau prest dauden irtenbideak erabiliz konpon daiteke, adibidez Edo .
Laburbilduz, hiru eragiketa azkar egiteko aukera emango digun datu-base bat behar dugu.
- Lehenengo eragiketa grabaketa da
ΠΊΠ»ΡΡ-Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅datu-base honetara. Oso azkar egiten du hau, nonΠΊΠ»ΡΡ-Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅kate arbitrarioak dira. - Bigarren eragiketa gako jakin bat erabiliz balio baten bilaketa azkarra da.
- Eta hirugarren eragiketa balio guztien bilaketa azkar bat da, aurrizki jakin baten bidez.
LevelDB eta RocksDB - Googlek eta Facebookek garatu zituzten datu-base hauek. Lehenengo LevelDB etorri zen. Gero Facebookeko mutilek LevelDB hartu eta hobetzen hasi ziren, RocksDB egin zuten. Orain ia barne datu-base guztiek RocksDB-en funtzionatzen dute Facebook-en, RocksDB eta MySQL-ra transferitu direnak barne. Izena jarri zioten .
Alderantzizko indize bat inplementa daiteke LevelDB erabiliz. Nola egin? Giltza gisa gordetzen dugu label=value. Eta balioa bikotea dagoen denbora seriearen identifikatzailea da label=value.
Denbora-serie asko baditugu bikote jakin batekin label=value, orduan datu-base honetan errenkada asko egongo dira gako berdinarekin eta ezberdinekin timeseries_ids. Guztien zerrenda lortzeko timeseries_ids, honekin hasten direnak label=prefix, datu-base hau optimizatuta dagoen barrutiaren eskaneatzea egiten dugu. Hau da, hasten diren lerro guztiak hautatzen ditugu label=prefix eta lortu behar dena timeseries_ids.
Hona hemen Go-n izango litzatekeen inplementazio lagin bat. Alderantzizko indizea dugu. Hau LevelDB da.
Funtzioa inplementazio inozoaren berdina da. Inplementazio inozoa errepikatzen du ia lerroz lerro. Puntu bakarra hori da buelta eman beharrean map alderantzizko indizean sartzen gara. Lehenengoaren balio guztiak lortzen ditugu label=value. Ondoren, gainerako bikote guztiak igaroko ditugu label=value eta lortu haiei dagozkien metricID multzoak. Ondoren, elkargunea aurkituko dugu.
Dena ondo dagoela dirudi, baina irtenbide honek eragozpenak ditu. VictoriaMetrics-ek hasieran LevelDB-n oinarritutako alderantzizko indize bat ezarri zuen. Baina azkenean amore eman behar izan nuen.
Zergatik? LevelDB inplementazio inozoa baino motelagoa delako. Inplementazio inozo batean, emandako gako bat emanda, berehala berreskuratzen dugu xerra osoa metricIDs. Oso eragiketa azkarra da - xerra osoa erabiltzeko prest dago.
LevelDB-n, funtzio bati deitzen zaion bakoitzean GetValues hasten diren lerro guztiak pasatu behar dituzu label=value. Eta lortu lerro bakoitzaren balioa timeseries_ids. Halakoak timeseries_ids bildu hauen zati bat timeseries_ids. Jakina, hau askoz motelagoa da mapa arrunt batean teklaz sartzea baino.
Bigarren eragozpena LevelDB C-n idatzita dagoela da. Go-tik C funtzioei deitzea ez da oso azkarra. Ehunka nanosegundo behar ditu. Hau ez da oso azkarra, zeren go-n idatzitako funtzio-dei arrunt batekin alderatuta, 1-5 nanosegundo hartzen dituena, errendimenduaren aldea hamarnaka aldiz da. VictoriaMetrics-entzat akats larria izan zen :)
Beraz, alderantzizko indizearen inplementazioa idatzi nuen. Eta deitu zion .
Mergeset MergeTree datu-egituran oinarritzen da. Datu-egitura hau ClickHouse-tik hartu da. Jakina, mergeset bilaketa azkarrak egiteko optimizatu behar da timeseries_ids emandako gakoaren arabera. Mergeset Go-n idatzita dago guztiz. Ikus dezakezu . mergeset-en ezarpena karpetan dago . Saia zaitezke han zer gertatzen den asmatzen.
mergeset APIa LevelDB eta RocksDB-ren oso antzekoa da. Hau da, bertan erregistro berriak azkar gordetzeko eta aurrizki jakin baten arabera erregistroak azkar hautatzeko aukera ematen du.
mergeset-en desabantailei buruz hitz egingo dugu geroago. Orain hitz egin dezagun zer arazo sortu ziren VictoriaMetrics-ekin ekoizpenean alderantzizko indize bat ezartzerakoan.
Zergatik sortu ziren?
Lehenengo arrazoia txandakako tasa altua da. Errusierara itzulita, denbora-serieen aldaketa maiz gertatzen da. Hau da denbora serie bat amaitzen denean eta serie berri bat hasten denean, edo denbora serie berri asko hasten direnean. Eta hau askotan gertatzen da.
Bigarren arrazoia denbora serie kopuru handia da. Hasieran, monitorizazioa ospea lortzen ari zenean, denbora serieen kopurua txikia zen. Adibidez, ordenagailu bakoitzeko CPU, memoria, sarea eta diskoaren karga kontrolatu behar dituzu. 4 denbora serie ordenagailu bakoitzeko. Demagun 100 ordenagailu eta 400 denbora serie dituzula. Hau oso gutxi da.
Denborarekin, jendeak informazio zehatzagoa neurtu zezakeela konturatu zen. Adibidez, neurtu karga ez prozesadore osoarena, prozesadorearen nukleo bakoitzaren bereizita baizik. 40 prozesadore nukleo badituzu, orduan 40 aldiz denbora serie gehiago dituzu prozesadorearen karga neurtzeko.
Baina hori ez da guztia. Prozesadorearen nukleo bakoitzak hainbat egoera izan ditzake inaktibo dagoenean, adibidez inaktibo. Erabiltzaile-espazioan ere lan egin, nukleo-espazioan eta beste egoera batzuetan. Eta halako egoera bakoitza denbora-serie bereizi gisa neur daiteke. Horrek, gainera, errenkada kopurua 7-8 aldiz handitzen du.
Metrika batetik 40 x 8 = 320 metrika lortu dugu ordenagailu bakarrerako. 100ez biderkatu, 32 lortuko dugu 000 beharrean.
Gero Kubernetes etorri zen. Eta okerrera egin zen, Kubernetes-ek hainbat zerbitzu osta ditzakeelako. Kubernetes-en zerbitzu bakoitzak pod asko ditu. Eta hori guztia kontrolatu behar da. Horrez gain, zure zerbitzuen bertsio berrien etengabeko hedapena dugu. Bertsio berri bakoitzeko, denbora serie berriak sortu behar dira. Ondorioz, denbora-serie-kopurua esponentzialki hazten da eta denbora-serie-kopuru handi baten arazoaren aurrean gaude, kardinaltasun handiko deritzona. VictoriaMetrics-ek arrakastaz aurre egiten dio beste denbora serieen datu-baseekin alderatuta.
Ikus ditzagun hurbilagotik bira tasa altua. Zerk eragiten du produkzioan itzulera-tasa altua? Etiketen eta etiketen esanahi batzuk etengabe aldatzen ari direlako.
Adibidez, hartu kontzeptua Kubernetes deployment, hau da, zure aplikazioaren bertsio berri bat zabaltzen denean. Arrazoiren batengatik, Kuberneteseko garatzaileek inplementazio-id-a etiketara gehitzea erabaki zuten.
Zer ekarri zuen horrek? Gainera, hedapen berri bakoitzarekin, denbora-serie zahar guztiak eten egiten dira, eta horien ordez, denbora-serie berriak etiketa-balio berri batekin hasten dira. deployment_id. Ehunka mila eta baita milioika halako errenkada egon daitezke.
Honen guztiaren garrantzitsuena denbora-serieen kopuru osoa hazten dela da, baina une honetan aktibo dauden eta datuak jasotzen dituzten denbora-serieen kopurua konstante mantentzen da. Egoera honi churn-tasa altua deitzen zaio.
Churn-tasa altuaren arazo nagusia denbora-tarte jakin batean etiketa-multzo jakin baterako denbora-serie guztien bilaketa-abiadura konstantea ziurtatzea da. Normalean, azken orduko edo azken eguneko denbora tartea izaten da.
Nola konpondu arazo hau? Hona hemen lehen aukera. Alderantzizko indizea denboran zehar zati independenteetan zatitzea da. Hau da, denbora-tarte batzuk igarotzen dira, uneko indize alderantzikatuarekin lan egiten amaitzen dugu. Eta alderantzizko indize berri bat sortu. Beste denbora tarte bat pasatzen da, beste bat eta beste bat sortzen dugu.
Eta alderantzizko indize horietatik laginketak egiterakoan, emandako tartean sartzen diren alderantzizko indizeen multzoa aurkitzen dugu. Eta, horren arabera, denbora seriearen id-a hautatzen dugu hortik.
Horrek baliabideak aurrezten ditu, ez baititugu begiratu behar emandako tartean sartzen ez diren zatiak. Hau da, normalean, azken orduko datuak hautatzen baditugu, aurreko denbora tarteetarako kontsultak saltatzen ditugu.
Arazo hau konpontzeko beste aukera bat dago. Hau da, egun bakoitzerako egun horretan gertatutako denbora-serieen IDen zerrenda bereizia gordetzeko.
Soluzio honek aurreko soluzioaren aldean duen abantaila da ez dugula denboran zehar desagertzen ez den denbora serieko informazioa bikoizten. Etengabe daude eta ez dira aldatzen.
Desabantaila da irtenbide hori ezartzea zailagoa dela eta arazketa zailagoa dela. Eta VictoriaMetrics-ek irtenbide hau aukeratu zuen. Horrela gertatu zen historikoki. Irtenbide honek ere ondo funtzionatzen du aurrekoarekin alderatuta. Irtenbide hau ez baita inplementatu partizio bakoitzean datuak bikoiztu behar direlako aldatzen ez diren denbora-serieetarako, hau da, denborarekin desagertzen ez direnetarako. VictoriaMetrics diskoko espazioaren kontsumorako optimizatu zen batez ere, eta aurreko inplementazioak diskoko espazioaren kontsumoa okerrera egin zuen. Baina inplementazio hau hobeto egokitzen da diskoko espazioaren kontsumoa gutxitzeko, beraz, aukeratu zen.
Berarekin borrokatu behar izan nuen. Borroka inplementazio honetan oraindik kopuru askoz handiagoa aukeratu behar duzula izan zen timeseries_ids alderantzizko indizea denbora zatitzen denean baino datuetarako.
Nola konpondu dugu arazo hau? Modu original batean konpondu dugu: alderantzizko indize-sarrera bakoitzean denbora-serie-identifikatzaile batzuk gordez identifikatzaile baten ordez. Hau da, badugu giltza label=value, denbora serie guztietan gertatzen dena. Eta orain hainbat gordetzen ditugu timeseries_ids sarrera batean.
Hona hemen adibide bat. Lehen N sarrera genituen, baina orain sarrera bat dugu zeinaren aurrizkia beste guztien berdina den. Aurreko sarrerarako, balioak denbora serieen ID guztiak ditu.
Horri esker, alderantzizko indize baten eskaneatze-abiadura 10 aldiz handitu zen. Eta cacherako memoria-kontsumoa murrizteko aukera eman zigun, orain katea gordetzen dugulako label=value behin bakarrik cachean elkarrekin N aldiz. Eta lerro hau handia izan daiteke zure etiketa eta etiketetan lerro luzeak gordetzen badituzu, Kubernetes-ek bertan sartzea gustatzen zaiona.
Alderantzizko indize batean bilaketak bizkortzeko beste aukera bat zatikatzea da. Baten ordez alderantzizko hainbat indize sortzea eta haien artean datuak gakoen bidez zatitzea. Hau multzo bat da key=value lurruna. Hau da, hainbat indize alderantzikatu independente lortzen ditugu, eta horiek paraleloan kontsulta ditzakegu hainbat prozesadoretan. Aurreko inplementazioek prozesadore bakarreko moduan bakarrik funtzionatzen zuten, hau da, datuak nukleo bakarrean eskaneatzen zituzten. Irtenbide honek hainbat nukleotako datuak aldi berean eskaneatzeko aukera ematen du, ClickHouse-k gustuko duen bezala. Hau da ezartzeko asmoa duguna.
Orain itzul gaitezen gure ardietara - elkargune funtziora timeseries_ids. Azter dezagun zer inplementazio egon daitezkeen. Funtzio honek aurkitzeko aukera ematen du timeseries_ids multzo jakin baterako label=value.
Lehenengo aukera inplementazio inozoa da. Bi begizta habiaratuak. Hemen funtzioaren sarrera jasoko dugu intersectInts bi xerra - a ΠΈ b. Irteeran, xerra horien ebakidura itzuli behar digu.
Inplementazio inozo batek honen itxura du. Balio guztien gainean errepikatzen dugu xerratik a, begizta honen barruan xerraren balio guztiak zeharkatzen ditugu b. Eta konparatzen ditugu. Bat badatoz, bidegurutze bat aurkitu dugu. Eta gorde ezazu result.
Zeintzuk dira desabantailak? Konplexutasun koadratikoa da bere eragozpen nagusia. Adibidez, zure neurriak xerra badira a ΠΈ b milioi bat aldi berean, orduan funtzio honek ez dizu inoiz erantzunik itzuliko. Bilioi bat iterazio egin beharko dituelako, eta hori asko da ordenagailu modernoentzat ere.
Bigarren ezarpena mapan oinarritzen da. Mapa sortzen dugu. Mapa honetan xerrako balio guztiak jarri ditugu a. Ondoren, xerra zeharkatuko dugu begizta bereizi batean b. Eta balio hori xerratakoa den egiaztatzen dugu b mapan. Bada, gehitu emaitzari.
Zeintzuk dira onurak? Abantaila konplexutasun lineala baino ez dagoela da. Hau da, funtzioa askoz azkarrago exekutatuko da xerra handiagoetarako. Milioi-tamainako xerra baterako, funtzio hau 2 milioi iteraziotan exekutatzen da, aurreko funtzioaren bilioi iterazioen aldean.
Alde txarra da funtzio honek memoria gehiago behar duela mapa hau sortzeko.
Bigarren eragozpena hashing-eko gastu handia da. Eragozpen hori ez da oso agerikoa. Eta guretzat ere ez zen oso agerikoa, beraz, hasieran VictoriaMetrics-en elkargunearen ezarpena mapa baten bidez izan zen. Baina gero profilak erakutsi zuen prozesadorearen denbora nagusia mapan idazten eta mapa honetan balio bat dagoen egiaztatzen igarotzen dela.
Zergatik galtzen da CPU denbora leku hauetan? Gok hashing eragiketa bat egiten duelako lerro hauetan. Hau da, gakoaren hash-a kalkulatzen du, gero HashMap-en indize jakin batean sartzeko. Hash kalkulu eragiketa hamarnana nanosegundotan burutzen da. Hau motela da VictoriaMetrics-entzat.
Kasu honetarako bereziki optimizatutako bitset bat ezartzea erabaki nuen. Hauxe da orain bi xerraren elkargunea. Hemen bitset bat sortzen dugu. Lehen zatitik elementuak gehitzen dizkiogu. Ondoren, elementu horien presentzia egiaztatuko dugu bigarren xerrean. Eta gehitu emaitzari. Hau da, ez da ia aurreko adibidearen desberdina. Hemen gauza bakarra da maparako sarbidea funtzio pertsonalizatuekin ordezkatu dugula add ΠΈ has.
Lehen begiratuan, badirudi honek motelago funtzionatu beharko lukeela, aurretik mapa estandarra erabiltzen bazen bertan, eta gero beste funtzio batzuk deitzen dira, baina profilak erakusten du gauza honek mapa estandarrak baino 10 aldiz azkarrago funtzionatzen duela VictoriaMetrics-en kasuan.
Horrez gain, askoz memoria gutxiago erabiltzen du maparen ezarpenarekin alderatuta. Hemen bitak gordetzen ditugulako zortzi byteko balioen ordez.
Ezarpen honen desabantaila da ez dela hain agerikoa, ez hutsala.
Askok nabarituko ez duten beste eragozpen bat inplementazio honek kasu batzuetan ondo ez funtzionatzea da. Hau da, kasu zehatz baterako optimizatuta dago, VictoriaMetrics denbora serieen id-en elkargune kasu honetarako. Horrek ez du esan nahi kasu guztietarako egokia denik. Gaizki erabiltzen bada, ez dugu errendimendu-igoerarik lortuko, memoria falta den errorea eta errendimendua moteltzea baizik.
Azter dezagun egitura honen ezarpena. Begiratu nahi baduzu, VictoriaMetrics iturrietan dago, karpetan . VictoriaMetrics kasurako bereziki optimizatuta dago, non timeseries_id 64 biteko balioa da, non lehen 32 bitak funtsean konstanteak diren eta azken 32 bitak soilik aldatzen diren.
Datu-egitura hau ez da diskoan gordetzen, memorian bakarrik funtzionatzen du.
Hona hemen bere APIa. Ez da oso konplikatua. APIa VictoriaMetrics erabiltzearen adibide zehatz batera egokituta dago. Hau da, hemen ez dago alferrikako funtziorik. Hona hemen VictoriaMetrics-ek esplizituki erabiltzen dituen funtzioak.
Funtzioak daude add, balio berriak gehitzen dituena. Funtzio bat dago has, balio berriak egiaztatzen dituena. Eta funtzio bat dago del, balioak kentzen dituena. Laguntza-funtzio bat dago len, multzoaren tamaina itzultzen duena. Funtzioa clone asko klonatzen ditu. Eta funtzioa appendto multzo hau xerra bihurtzen du timeseries_ids.
Horrelakoa da datu-egitura honen ezarpenak. multzoak bi elementu ditu:
-
ItemsCountmultzo bateko elementu kopurua azkar itzultzeko eremu laguntzaile bat da. Eremu laguntzaile hori gabe egitea posible izango litzateke, baina hemen gehitu behar izan da VictoriaMetrics-ek sarritan bere algoritmoetan bit-setaren luzera kontsultatzen duelako. -
Bigarren eremua da
buckets. Hau egituraren zatia dabucket32. Egitura bakoitzak gordetzen duhieremua. Hauek dira goiko 32 bitak. Eta bi xerra -b16hisΠΈbuckets-bucket16egiturak.
16 biteko egituraren bigarren zatiaren goiko 64 bitak gordetzen dira hemen. Eta hemen bitsetak byte bakoitzaren beheko 16 bitetarako gordetzen dira.
Bucket64 array batez osatuta dago uint64. Luzera konstante hauek erabiliz kalkulatzen da. Batean bucket16 gehienez gorde daiteke 2^16=65536 bit. Hau 8z zatitzen baduzu, orduan 8 kilobyte da. Berriro 8rekin zatitzen baduzu, 1000 da uint64 esanahia. Hori da Bucket16 β hau da gure 8 kilobyteko egitura.
Ikus dezagun nola gauzatzen den balio berri bat gehitzeko egitura honen metodoetako bat.
Dena hasten da uint64 esanahiak. Goiko 32 bitak kalkulatzen ditugu, beheko 32 bitak kalkulatzen ditugu. Goazen denetik buckets. Ontzi bakoitzeko goiko 32 bitak gehitutako balioarekin alderatzen ditugu. Eta bat egiten badute, funtzioari deitzen diogu add b32 egituran buckets. Eta hor gehitu beheko 32 bitak. Eta itzuliko balitz true, orduan horrek esan nahi du hor halako balio bat gehitu genuela eta ez genuela halako baliorik. Itzultzen bada false, orduan jada existitzen zen halako esanahi bat. Ondoren, egiturako elementu kopurua handitzen dugu.
Behar duzuna aurkitu ez badugu bucket behar den hi-balioarekin, orduan deitzen diogu funtzioari addAlloc, berri bat sortuko duena bucket, kuboaren egiturari gehituz.
Hau da funtzioaren ezarpena b32.add. Aurreko ezarpenaren antzekoa da. 16 bit esanguratsuenak, 16 bit esanguratsuenak kalkulatzen ditugu.
Ondoren, goiko 16 bit guztiak zeharkatuko ditugu. Popoloak aurkitzen ditugu. Eta bat-etortzerik badago, gehitu metodoari deitzen diogu, hurrengo orrialdean kontuan hartuko duguna bucket16.
Eta hona hemen maila baxuena, ahalik eta gehien optimizatu behar dena. Horretarako kalkulatzen dugu uint64 id balioa xerra bitetan eta gainera bitmask. Hau 64 biteko balio jakin baterako maskara bat da, bit honen presentzia egiaztatzeko edo ezartzeko erabil daitekeena. Bit hau ezarrita dagoen eta ezarrita dagoen egiaztatzen dugu eta presentzia itzultzen dugu. Hau da gure inplementazioa, eta horri esker, denbora-serieen gurutzatutako IDen eragiketa 10 aldiz azkartu genuen ohiko mapekin alderatuta.
Optimizazio honetaz gain, VictoriaMetrics-ek beste optimizazio asko ditu. Optimizazio horietako gehienak arrazoi batengatik gehitu ziren, baina ekoizpenean kodea profilatu ondoren.
Hau da optimizazio-arau nagusia - ez gehitu optimizazioa hemen botila-lepo bat egongo dela suposatuz, baliteke han ez dela leporik egongo. Optimizazioak normalean kodearen kalitatea hondatzen du. Hori dela eta, merezi du profila egin ondoren soilik optimizatzea eta hobe produkzioan, datu errealak izan daitezen. Norbaitek interesa badu, VictoriaMetrics iturburu-kodea begiratu eta bertan dauden beste optimizazio batzuk arakatu ditzakezu.
Bitset-i buruzko galdera bat daukat. C++ bektorial bool inplementazioaren oso antzekoa, bitset optimizatua. Hortik hartu duzu ezarpena?
Ez, ez hortik. Bitset hau ezartzerakoan, VictoriaMetrics-en erabiltzen diren id-denbora-serie hauen egituraren ezagutzak gidatu ninduen. Eta haien egitura da goiko 32 bitak, funtsean, konstanteak direla. Beheko 32 bitak alda daitezke. Zenbat eta txikiagoa izan bit, orduan eta maizago alda daiteke. Hori dela eta, inplementazio hau datu-egitura honetarako bereziki optimizatuta dago. C++ inplementazioa, nik dakidala, kasu orokorrerako optimizatuta dago. Kasu orokorrerako optimizatzen baduzu, horrek esan nahi du ez dela egokiena izango kasu zehatz baterako.
Alexey Miloviden erreportajea ikustea ere gomendatzen dizut. Duela hilabete inguru, espezializazio zehatzetarako ClickHouse-n optimizazioari buruz hitz egin zuen. Kasu orokorrean, C++ inplementazio bat edo beste inplementazioren bat ospitale batean batez beste ondo funtzionatzeko egokituta dagoela besterik ez du esaten. Gurea bezalako ezagutza espezifikoko inplementazio batek baino okerragoa izan dezake, non goiko 32 bitak konstanteak direla dakigun.
Bigarren galdera bat daukat. Zein da InfluxDB-ren oinarrizko aldea?
Oinarrizko desberdintasun asko daude. Errendimenduari eta memoria-kontsumoari dagokionez, InfluxDB-k probetan 10 aldiz memoria-kontsumo handiagoa erakusten du kardinaltasun handiko denbora serieetarako, horietako asko dituzunean, adibidez, milioika. Esate baterako, VictoriaMetrics-ek milioi bat errenkada aktibo bakoitzeko 1 GB kontsumitzen ditu, InfluxDB-k 10 GB kontsumitzen dituen bitartean. Eta hori alde handia da.
Bigarren funtsezko aldea InfluxDB-k kontsulta-hizkuntza arraroak dituela da - Flux eta InfluxQL. Ez dira oso erosoak denbora serieekin lan egiteko , VictoriaMetrics-ek onartzen duena. PromQL Prometheus-en kontsulta-lengoaia da.
Eta beste desberdintasun bat da InfluxDB-k datu-eredu apur bat arraroa duela, non lerro bakoitzak etiketa multzo ezberdin batekin hainbat eremu gorde ditzakeela. Lerro hauek hainbat taulatan banatzen dira. Konplikazio gehigarri hauek datu-base honekin ondorengo lana zailtzen dute. Zaila da onartzen eta ulertzea.
VictoriaMetrics-en dena askoz errazagoa da. Bertan, denbora serie bakoitza gako-balio bat da. Balioa puntu multzo bat da - (timestamp, value), eta gakoa multzoa da label=value. Ez dago eremuen eta neurketen arteko bereizketarik. Edozein datu hautatzeko eta gero konbinatu, batu, kendu, biderkatu, zatitu ahalbidetzen du, InfluxDB ez bezala, non errenkada ezberdinen arteko kalkuluak oraindik ez diren inplementatzen nik dakidala. Inplementatzen badira ere, zaila da, kode asko idatzi behar duzu.
Galdera argitzaile bat daukat. Ondo ulertu al dut hitz egin duzun arazoren bat zegoela, alderantzizko indize hori ez dela memorian sartzen, beraz, hor zatiketa dagoela?
Lehenik eta behin, alderantzizko indize baten ezarpen inozoa erakutsi nuen Go mapa estandar batean. Inplementazio hau ez da egokia datu-baseetarako, alderantzizko indize hori ez baita diskoan gordetzen, eta datu-baseak diskoan gorde behar du, berrabiarazi orduko datu horiek erabilgarri egon daitezen. Inplementazio honetan, aplikazioa berrabiarazten duzunean, alderantzizko indizea desagertuko da. Eta datu guztietarako sarbidea galduko duzu ezingo duzulako aurkitu.
Kaixo! Eskerrik asko erreportajeagatik! Nire izena Pavel da. Wildberrieskoa naiz. Galdera batzuk ditut zuretzat. Galdera bat. Uste duzu zure aplikazioaren arkitektura eraikitzean beste printzipio bat aukeratu izan bazenu eta datuak denboran zehar zatitu izan bazenu, agian bilaketak egiterakoan datuak gurutzatzeko gai izango zenituzkeela, partizio batek batentzako datuak dituenean soilik oinarrituta. denbora-tarte batean, hau da, denbora-tarte batean eta ez zenuke kezkatu beharko zure piezak modu ezberdinean sakabanatuta daudelako? 2. galdera - bitsetarekin eta beste guztiarekin antzeko algoritmo bat ezartzen ari zarenez, agian prozesadorearen argibideak erabiltzen saiatu zara? Agian horrelako optimizazioak probatu al dituzu?
Bigarrenari berehala erantzungo diot. Oraindik ez gara iritsi puntu horretara. Baina beharrezkoa bada, iritsiko gara. Eta lehenengoa, zein zen galdera?
Bi eszenatoki eztabaidatu dituzu. Eta bigarrena ezarpen konplexuago batekin aukeratu dutela esan dute. Eta ez zuten nahiago lehena, non datuak denboraren arabera banatzen diren.
Bai. Lehenengo kasuan, indizearen guztizko bolumena handiagoa izango litzateke, partizio bakoitzean partizio guzti hauetan zehar jarraitzen duten denbora serie horietarako datu bikoiztuak gorde beharko genituzkeelako. Eta zure denbora-serieen txandakatze-tasa txikia bada, hau da, serie berdinak etengabe erabiltzen badira, lehenengo kasuan askoz gehiago galduko genuke bigarren kasuarekin alderatuta okupatutako disko-espazioan.
Eta, beraz, bai, denboraren zatiketa aukera ona da. Prometeok erabiltzen du. Baina Prometeok badu beste eragozpen bat. Datu horiek batzean, memorian gorde behar du etiketa eta denbora serie guztien meta informazioa. Hori dela eta, batzen dituen datu-zatiak handiak badira, memoria-kontsumoa asko handitzen da bateratzean, VictoriaMetrics ez bezala. Bateratzerakoan, VictoriaMetrics-ek ez du batere memoria kontsumitzen; kilobyte pare bat baino ez dira kontsumitzen, bateratutako datuen tamaina edozein dela ere.
Erabiltzen ari zaren algoritmoak memoria erabiltzen du. Balioak dituzten denbora-serieko etiketak markatzen ditu. Eta horrela egiaztatuko duzu parekatuta dagoen presentzia datu-matrize batean eta beste batean. Eta ulertzen duzu gurutzaketa gertatu den ala ez. Normalean, datu-baseek uneko edukia gordetzen duten eta ordenatutako datuak ibiltzen dituzten kurtsoreak eta itertatzaileak inplementatzen dituzte, eragiketa horien konplexutasun sinpleagatik.
Zergatik ez ditugu kurtsoreak erabiltzen datuak zeharkatzeko?
Bai.
LevelDB edo mergeset-en ordenatutako errenkadak gordetzen ditugu. Kurtsorea mugitu eta elkargunea aurki dezakegu. Zergatik ez dugu erabiltzen? Geldoa delako. Kurtsoreek lerro bakoitzeko funtzio bat deitu behar duzula esan nahi baitu. Funtzio-dei bat 5 nanosegundokoa da. Eta 100 lerro badituzu, orduan bigarren erdi bat funtzioari deitzen besterik ez dugu ematen.
Badago halakorik, bai. Eta nire azken galdera. Galderak arraro samarra izan dezake. Zergatik ezin da datuak iristen diren momentuan beharrezko agregatu guztiak irakurri eta behar den moduan gorde? Zergatik gorde bolumen handiak VictoriaMetrics, ClickHouse, etab. bezalako sistema batzuetan, eta gero denbora asko igaro?
Adibide bat jarriko dut argiago uzteko. Esan dezagun nola funtzionatzen du jostailuzko abiadura-neurgailu txiki batek? Bidaiatutako distantzia erregistratzen du, denbora guztian balio bati gehituz, eta bigarrena - denbora. Eta banatzen du. Eta batez besteko abiadura lortzen du. Gauza bera egin dezakezu. Gehitu beharrezko datu guztiak hegan.
Ados, ulertzen dut galdera. Zure adibideak badu bere lekua. Badakizu zer agregatu behar dituzun, orduan hau da inplementaziorik onena. Baina arazoa da jendeak neurri hauek gordetzen dituela, datu batzuk ClickHousen eta oraindik ez dakitela etorkizunean nola bildu eta iragaziko dituzten, beraz, datu gordina guztiak gorde behar dituzte. Baina batez besteko zerbait kalkulatu behar duzula badakizu, zergatik ez kalkulatu balio gordin mordoa bertan gorde beharrean? Baina hori behar duzuna zehatz-mehatz ezagutzen baduzu bakarrik da.
Bide batez, denbora serieak gordetzeko datu-baseek agregatuak zenbatzea onartzen dute. Adibidez, Prometheus-ek onartzen du . Hau da, zer unitate beharko dituzun jakinez gero egin daiteke. VictoriaMetrics-ek ez du oraindik hori, baina normalean Prometheus-ek aurrea hartu du, eta bertan birkodetze-arauetan egin daiteke.
Adibidez, nire aurreko lanean azken orduko leiho lerragarri bateko gertakari kopurua zenbatu behar nuen. Arazoa da Go-n ezarpen pertsonalizatu bat egin behar izan dudala, hau da, gauza hau zenbatzeko zerbitzu bat. Zerbitzu hau, azken batean, ez zen hutsala, zaila delako kalkulatzea. Inplementazioa erraza izan daiteke agregatu batzuk denbora-tarte finkoetan zenbatu behar badituzu. Leiho lerragarri batean gertaerak zenbatu nahi badituzu, ez da dirudien bezain erraza. Uste dut oraindik ez dela inplementatu ClickHousen edo denbora serieko datu-baseetan, ezartzea zaila delako.
Eta galdera bat gehiago. Batez bestekoaz hitz egiten ari ginen, eta gogoratu nintzen garai batean bazela grafitoa Carbon backend batekin. Eta jakin zuen datu zaharrak mehetzen, hau da, minutuko puntu bat uzten, orduko puntu bat, etab. Printzipioz, hau nahiko erosoa da datu gordinak behar baditugu, erlatiboki hitz eginda, hilabete baterako, eta gainerako guztia. mehetu izan . Baina Prometheus eta VictoriaMetrics-ek ez dute funtzionalitate hori onartzen. Laguntza ematea aurreikusten al da? Ez bada, zergatik ez?
Eskerrik asko galderagatik. Gure erabiltzaileek galdera hau egiten dute aldian-aldian. Behe-laginketarako laguntza noiz gehituko dugun galdetzen dute. Hemen hainbat arazo daude. Lehenik eta behin, erabiltzaile bakoitzak ulertzen du downsampling zerbait ezberdina: norbaitek edozein puntu arbitrario lortu nahi du tarte jakin batean, norbaitek balio maximoak, minimoak eta batez bestekoak nahi ditu. Sistema askok datuak idazten badituzu zure datu-basean, ezin dituzu guztiak bateratu. Baliteke sistema bakoitzak mehetze desberdinak behar izatea. Eta hori gauzatzea zaila da.
Eta bigarren gauza da VictoriaMetrics, ClickHouse bezala, datu gordinen kantitate handietan lan egiteko optimizatuta dagoela, beraz, segundo batean baino gutxiagoan mila milioi lerro bota ditzake zure sisteman nukleo asko badituzu. VictoriaMetrics-en denbora serieko puntuak eskaneatzea - ββ50 puntu segundoko nukleo bakoitzeko. Eta errendimendu hau lehendik dauden nukleoetara eskalatzen da. Hau da, 000 nukleo badituzu, adibidez, segundoko mila milioi puntu eskaneatuko dituzu. Eta VictoriaMetrics eta ClickHouse-ren propietate honek txikiagotzearen beharra murrizten du.
Beste ezaugarri bat VictoriaMetrics-ek datu hauek modu eraginkorrean konprimitzen dituela da. Produkzioan batez besteko konpresioa 0,4 eta 0,8 byte artekoa da puntu bakoitzeko. Puntu bakoitza denbora-zigilua + balio bat da. Eta byte bat baino gutxiagotan konprimitzen da batez beste.
Sergey. Galdera bat daukat. Zein da gutxieneko grabazio-denbora kuantikoa?
Milisegundo bat. Duela gutxi denbora serieko datu-baseen garatzaile batzuekin elkarrizketa bat izan dugu. Haien gutxieneko denbora-tartea segundo batekoa da. Eta Grafitoan, adibidez, segundo batekoa ere bada. OpenTSDBn ere segundo batekoa da. InfluxDB-k nanosegundoko doitasuna du. VictoriaMetrics-en milisegundo batekoa da, Prometheus-en milisegundo batekoa delako. Eta VictoriaMetrics jatorriz Prometheus-en urruneko biltegiratze gisa garatu zen. Baina orain beste sistemetako datuak gorde ditzake.
Hitz egin dudan pertsonak segundoz segundoko zehaztasuna duela dio; hori nahikoa da denbora serieen datu-basean gordetzen diren datu-motaren araberakoa baita. Hau DevOps datuak edo azpiegiturako datuak badira, non 30 segundoko tarteetan biltzen dituzun, minutuko, orduan bigarren zehaztasuna nahikoa da, ez duzu ezer gutxiago behar. Eta datu hauek maiztasun handiko merkataritza-sistemetatik biltzen badituzu, nanosegundoko zehaztasuna behar duzu.
VictoriaMetrics-en milisegundoko zehaztasuna DevOps kasurako ere egokia da eta txostenaren hasieran aipatu ditudan kasu gehienetarako egokia izan daiteke. Beharbada egokia ez den gauza bakarra maiztasun handiko merkataritza-sistemak dira.
Eskerrik asko! Eta beste galdera bat. Zer da bateragarritasuna PromQL-en?
Atzerako bateragarritasun osoa. VictoriaMetrics-ek PromQL guztiz onartzen du. Horrez gain, deitzen den PromQL-en funtzionalitate aurreratu gehigarriak gehitzen ditu . YouTube-n hitz egin da funtzionalitate hedatu honi buruz. San Petersburgoko udaberrian Monitoring Meetup-en hitz egin nuen.
Telegram kanala .
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Zerk galarazten zaitu VictoriaMetrics-era aldatzea Prometheus-en epe luzerako biltegiratze gisa? (Idatzi iruzkinetan, inkestera gehituko dut))
-
71,4%Ez dut Prometheus5 erabiltzen
-
28,6%Ez nekien VictoriaMetrics2-i buruz
7 erabiltzailek eman dute botoa. 12 erabiltzaile abstenitu ziren.
Iturria: www.habr.com