Ez ji we re pêşniyar dikim ku hûn nusxeya rapora dawiya sala 2019-an a Alexander Valyalkin bixwînin "Di VictoriaMetrics de optimîzasyonan biçin"
- DBMSek bilez û berbelav ji bo hilanîn û hilberandina daneyan di forma rêzek demjimêr de (qeyd dem û komek nirxên ku bi vê demê re têkildar in, mînakî, ku bi hilkolandina demkî ya rewşa senzoran an berhevkirina metrîk).
Li vir lînka vîdyoya vê raportê heye -
Ji me re behsa xwe bike. Ez Alexander Valyalkin im. Vir . Ez ji Go û xweşbîniya performansê re dilşewat im. Min gelek pirtûkxaneyên bikêr û ne bikêr nivîsandin. Ew bi yek dest pê dikin fast, an bi quick pêşkîte.
Ez niha li ser VictoriaMetrics dixebitim. Ew çi ye û ez li wir çi dikim? Ez ê di vê pêşkêşiyê de behsa vê bikim.
Naveroka raporê wiha ye:
- Pêşîn, ez ê ji we re vebêjim ka VictoriaMetrics çi ye.
- Dûv re ez ê ji we re bibêjim ku rêzikên demjimêr çi ne.
- Dûv re ez ê ji we re vebêjim ka databasek rêzikên demjimêr çawa dixebite.
- Dûv re, ez ê li ser mîmariya databasê ji we re bibêjim: ew ji çi pêk tê.
- Û paşê em werin ser xweşbîniyên ku VictoriaMetrics hene. Ev optimîzasyonek e ji bo pêveka berevajîkirî û xweşbîniyek ji bo pêkanîna bitset li Go.
Ma kesek di temaşevanan de dizane VictoriaMetrics çi ye? Wow, gelek kes jixwe dizanin. Ew nûçeyek baş e. Ji bo kesên ku nizanin, ev databasek rêzikên demê ye. Ew li ser mîmariya ClickHouse, li ser hin hûrguliyên pêkanîna ClickHouse-yê ye. Mînakî, li ser wekî: MergeTree, hesabkirina paralel li ser hemî navgînên pêvajoyê yên berdest û xweşbînkirina performansê bi xebata li ser blokên daneya ku di cacheya pêvajoyê de têne danîn.
VictoriaMetrics ji databasên rêzikên demê yên din berhevkirina daneyê çêtir peyda dike.
Ew bi rengek vertîkal mezin dibe - ango, hûn dikarin li ser yek komputerek bêtir pêvajoyan, bêtir RAM zêde bikin. VictoriaMetrics dê van çavkaniyên berdest bi serfirazî bikar bîne û dê hilberîna xêzikî baştir bike.
VictoriaMetrics di heman demê de horizontî jî pîvan dike - ango, hûn dikarin girêkên din li koma VictoriaMetrics zêde bikin, û performansa wê dê hema hema bi xêzikî zêde bibe.
Wekî ku we texmîn kir, VictoriaMetrics databasek bilez e, ji ber ku ez nikarim yên din binivîsim. Û ew di Go de hatî nivîsandin, ji ber vê yekê ez li ser vê civînê dipeyivim.
Kî dizane rêzedem çi ye? Ew jî gelek kesan nas dike. Rêzeya demê rêzeka cotan e (timestamp, значение), ku ev cot li gorî demê têne rêz kirin. Nirx jimareyek xala herikîn e - float64.
Her rêze dem bi rengek yekta ji hêla mifteyê ve tête nas kirin. Ev kilît ji çi pêk tê? Ew ji komek ne vala ya cotên key-nirxê pêk tê.
Li vir mînakek rêzek dem heye. Mifteya vê rêzê navnîşek cotan e: __name__="cpu_usage" navê metrîkê ye, instance="my-server" - ev komputera ku ev metrîk li ser hatî berhev kirin e, datacenter="us-east" - ev navenda daneyê ye ku ev komputer lê ye.
Me navek rêzedemek ku ji sê cotên nirx-kilît pêk tê bi dawî kir. Ev mift bi navnîşek cotan re têkildar e (timestamp, value). t1, t3, t3, ..., tN - ev nîşaneyên demê ne, 10, 20, 12, ..., 15 - nirxên têkildar. Ev cpu-bikaranîna di demek diyarkirî de ji bo rêzek diyarkirî ye.
Li ku derê rêzikên demê dikarin werin bikar anîn? Ma kesek fikrek heye?
- Di DevOps de, hûn dikarin CPU, RAM, torê, rps, hejmara xeletiyan, hwd bipîvin.
- IoT - em dikarin germahî, zext, hevrêzên erdnîgarî û tiştek din bipîvin.
- Di heman demê de darayî - em dikarin bihayên ji bo her cûre stok û dirav bişopînin.
- Wekî din, rêzikên demê dikarin di şopandina pêvajoyên hilberînê yên li kargehan de werin bikar anîn. Bikarhênerên me hene ku VictoriaMetrics bikar tînin ji bo şopandina turbînên bayê, ji bo robotan.
- Rêzên demê jî ji bo berhevkirina agahdariya ji sensorên cîhazên cihêreng bikêr in. Mînak ji bo motorekê; ji bo pîvandina zexta tire; ji bo pîvandina leza, dûr; ji bo pîvandina xerckirina benzînê û hwd.
- Rêzên demjimêr jî dikarin ji bo çavdêriya balafiran werin bikar anîn. Her balafirek qutiyek reş heye ku rêzikên demê ji bo pîvanên cihêreng ên tenduristiya balafirê berhev dike. Rêzên demjimêr di pîşesaziya hewayê de jî têne bikar anîn.
- Tenduristî tansiyona xwînê, puls û hwd e.
Dibe ku bêtir serîlêdanên ku min ji bîr kiriye hebin, lê ez hêvî dikim ku hûn fêm bikin ku rêzikên demê di cîhana nûjen de bi rengek çalak têne bikar anîn. Û qebareya bikaranîna wan her sal zêde dibe.
Çima hûn hewceyê databasek rêzikên demê ne? Çima hûn nikarin databasek pêwendiya birêkûpêk bikar bînin da ku rêzikên demê hilînin?
Ji ber ku rêzikên demê bi gelemperî gelek agahdarî dihewîne, ku di databasên kevneşopî de hilanîn û hilanîn dijwar e. Ji ber vê yekê, databasên pispor ên ji bo rêzikên demê xuya bûn. Van bingehan bi bandor xalan diparêzin (timestamp, value) bi kilîta daye. Ew API-yek peyda dikin ji bo xwendina daneya hilandî ji hêla mifteyê, bi yek cotek key-nirx, an bi çend cotên key-nirx, an bi regexp ve. Mînakî, hûn dixwazin barkirina CPU ya hemî karûbarên xwe li navendek daneyê li Amerîka bibînin, wê hingê hûn hewce ne ku vê pseudo-pirsînê bikar bînin.
Bi gelemperî databasên rêzikên demjimêrî zimanên lêpirsînê yên pispor peyda dikin ji ber ku rêzikên demjimêr SQL ne pir xweş e. Her çend databases hene ku SQL piştgirî dikin, ew ne pir maqûl e. Pirsa zimanên wek , , , . Ez hêvî dikim ku kesek bi kêmanî yek ji van zimanan bihîstibe. Dibe ku gelek kesan li ser PromQL bihîstine. Ev zimanê pirsa Prometheus e.
Ev e ya ku mîmariya databasa rêzedemî ya nûjen wekî mînakek VictoriaMetrics bikar tîne.
Ji du beşan pêk tê. Ev hilanîn ji bo nîşana berevajîkirî û hilanîn ji bo nirxên rêzikên demê ye. Ev depo ji hev veqetandî ne.
Dema ku tomarek nû di databasê de tê, em pêşî xwe digihînin navnîşa berevajîkirî da ku ji bo komek diyar nasnavê rêza demê bibînin. label=value ji bo metricek diyarkirî. Em vê nasnameyê dibînin û nirxê di hilanîna daneyê de hilînin.
Dema ku daxwazek tê ku daneyan ji TSDB-ê bikişîne, em pêşî diçin navnîşa berevajîkirî. Werin em her tiştî bistînin timeseries_ids qeydên ku bi vê set hev label=value. Û dûv re em hemî daneyên pêwîst ji depoya daneyê digirin, ji hêla ve têne navnîş kirin timeseries_ids.
Ka em li mînakek binihêrin ka databasek rêzedemî çawa pirsek hilbijartî ya hatî pêvajoyê dike.
- Berî her tiştî ew her tiştî digire
timeseries_idsji îndekseke berevajîkirî ya ku cotên diyarkirî dihewînelabel=value, an jî îfadeya birêkûpêk a diyarkirî têr bike. - Dûv re ew hemî nuqteyên daneyê ji hilanîna daneyê di navberek demkî diyarkirî de ji bo yên ku hatine dîtin vedigire
timeseries_ids. - Piştî vê yekê, databas li gorî daxwaza bikarhêner li ser van xalên daneyê hin hesaban dike. Û piştî ku ew bersiv vedigere.
Di vê pêşkêşiyê de ez ê ji we re behsa beşa yekem bikim. Ev lêgerînek e timeseries_ids bi îndeksa berevajîkirî. Hûn dikarin li ser beşa duyemîn û beşa sêyemîn paşê temaşe bikin an jî li bendê bin ku ez raporên din amade bikim :)
Ka em herin ser îndeksa berevajîkirî. Gelek kes dikarin bifikirin ku ev hêsan e. Kî dizane indexek berevajîkirî çi ye û ew çawa dixebite? Oh, êdî ne ewqas mirov. Ka em hewl bidin ku fêm bikin ka ew çi ye.
Ew bi rastî hêsan e. Ew bi tenê ferhengek e ku kilîtek nirxek nexşe dike. Miftek çi ye? Ev cot label=valueko label и value - ev xet in. Û nirx komek in timeseries_ids, ku tê de cotek dayîn label=value.
Indeksa berevajîkirî dihêle hûn zû her tiştî bibînin timeseries_ids, yên ku dane label=value.
Ew jî dihêle hûn zû bibînin timeseries_ids rêzikên dem ji bo çend cotên label=value, an jî ji bo cotan label=regexp. Ev çawa dibe? Bi dîtina xaçerêya setê timeseries_ids ji bo her cotek label=value.
Ka em li pêkanînên cihêreng ên pêveka berevajî binêrin. Ka em bi pêkanîna herî hêsan a naîf dest pê bikin. Ew bi vî rengî xuya dike.
function getMetricIDs navnîşek têlan digire. Her rêzek dihewîne label=value. Ev fonksiyon lîsteyek vedigerîne metricIDs.
Çawa dixebite? Li vir guhêrbarek gerdûnî ya ku jê re tê gotin heye invertedIndex. Ev ferhengek asayî ye (map), ya ku dê xêzikê ji bo perçekirina intan nexşeyê. Rêze dihewîne label=value.
Pêkanîna fonksiyonê: bigirin metricIDs ji bo yekem label=value, paşê em bi her tiştê din re derbas dibin label=value, em distînin metricIDs ji bo wan. Û fonksiyonê bang bikin intersectInts, ku dê li jêr were nîqaş kirin. Û ev fonksiyon navbera van navnîşan vedigerîne.
Wekî ku hûn dikarin bibînin, pêkanîna pêdekek berevajîkirî ne pir tevlihev e. Lê ev pêkanînek nefî ye. Çi kêmasiyên wê hene? Kêmasiya sereke ya pêkanîna naîf ev e ku pêdekek wusa berevajîkirî di RAM-ê de tê hilanîn. Piştî destpêkirina serîlêdanê em vê pêvekê winda dikin. Li ser dîskê tomarkirina vê indexê tune. Indeksa berevajîkirî ya wusa ne gengaz e ku ji bo databasek guncan be.
Kêmasiya duyemîn jî bi bîranînê ve girêdayî ye. Pêdivî ye ku navnîşa berevajîkirî di RAM-ê de cih bigire. Ger ew ji mezinahiya RAM-ê derbas bibe, wê hingê eşkere ye ku em ê ji xeletiya bîranînê derkevin. Û bername dê nexebite.
Ev pirsgirêk bi karanîna çareseriyên amadekirî yên wekî an jî .
Bi kurtasî, em hewceyê databasek e ku destûrê dide me ku em zû sê operasyonan bikin.
- Operasyona yekem tomarkirin e
ключ-значениеji bo vê databasê. Ew vê yekê pir zû, li kuключ-значениеtêlên keyfî ne. - Operasyona duyemîn lêgerînek bilez a nirxek bi karanîna mifteyek diyarkirî ye.
- Û operasyona sêyemîn lêgerînek bilez e ji bo hemî nirxan bi pêşgirek diyarkirî.
LevelDB û RocksDB - ev databas ji hêla Google û Facebook ve hatine pêşve xistin. Pêşî LevelDB hat. Dûv re xortên ji Facebookê LevelDB girtin û dest bi başkirina wê kirin, wan RocksDB çêkirin. Naha hema hemî databasên hundurîn li ser RocksDB di hundurê Facebookê de dixebitin, di nav de yên ku ji RocksDB û MySQL re hatine veguheztin. Navê wî dan .
Indeksek berevajîkirî dikare bi karanîna LevelDB were bicîh kirin. Çawa bike? Em wekî kilît xilas dikin label=value. Û nirx nasnavê rêzikên demê ye ku cot lê heye label=value.
Ger em bi cotek diyarî gelek rêzikên demê hebin label=value, wê hingê dê di vê databasê de gelek rêzên bi heman key û cûda hebin timeseries_ids. Ji bo bidestxistina navnîşek hemî timeseries_ids, ku bi vê dest pê dike label=prefix, em lêgerînek rêzê dikin ku ji bo vê databasê xweşbîn e. Ango, em hemî rêzikên ku bi dest pê dikin hilbijêrin label=prefix û tiştên pêwîst bistînin timeseries_ids.
Li vir pêkanîna nimûneyek heye ku ew ê di Go de çawa xuya bike. Indeksa me ya berevajîkirî heye. Ev LevelDB ye.
Fonksiyon ji bo pêkanîna naîf heman e. Hema bêje rêz bi rêz pêkanîna naîf dubare dike. Tenê xal ew e ku li şûna zivirî map em xwe digihînin îndeksa berevajîkirî. Em ji bo yekem hemî nirxan digirin label=value. Dûv re em hemî cotên mayî derbas dibin label=value û ji bo wan komên metricID-ên têkildar bistînin. Dûv re em xaçerêyê dibînin.
Her tişt baş xuya dike, lê kêmasiyên vê çareseriyê hene. VictoriaMetrics di destpêkê de li ser bingeha LevelDB indexek berevajîkirî bicîh kir. Lê di dawiyê de ez neçar bûm ku dev jê berdim.
Çima? Ji ber ku LevelDB ji pêkanîna nefsbiçûk hêdîtir e. Di pêkanînek nefsbiçûk de, ku kilîtek hatî dayîn, em tavilê tevahiya perçeyê vedigirin metricIDs. Ev operasyonek pir bilez e - tevahiya perçe ji bo karanîna amade ye.
Di LevelDB de, her gava ku fonksiyonek tê gazî kirin GetValues hûn hewce ne ku hemî rêzikên ku bi dest pê dikin derbas bibin label=value. Û ji bo her rêzê nirxê bistînin timeseries_ids. Ji yên weha timeseries_ids pariyek ji van berhev bike timeseries_ids. Eşkere ye, ev ji hêsan gihandina nexşeyek birêkûpêk bi mifteyê pir hêdîtir e.
Kêmasiya duyemîn ev e ku LevelDB bi C-yê hatî nivîsandin. Banga fonksiyonên C ji Go ne pir zû ye. Bi sedan nan çirkeyan digire. Ev ne pir zû ye, ji ber ku li gorî bangek fonksiyonek birêkûpêk ku di go-ê de hatî nivîsandin, ku 1-5 nanosecond digire, cûdahiya performansê bi dehan carî ye. Ji bo VictoriaMetrics ev xeletiyek kujer bû :)
Ji ber vê yekê min pêkanîna xwe ya pêveka berevajî nivîsand. Û wî gazî wê kir .
Mergeset li ser bingeha daneya MergeTree ye. Ev avahiya daneyê ji ClickHouse ve hatî deyn kirin. Eşkere ye, mergeset divê ji bo lêgerîna bilez were xweşbîn kirin timeseries_ids li gor mifteya dayî. Mergeset bi tevahî di Go de hatî nivîsandin. Hûn dikarin bibînin . Pêkanîna mergeset di peldankê de ye . Hûn dikarin hewl bidin ku fêm bikin ka li wir çi diqewime.
API-ya mergeset pir dişibihe LevelDB û RocksDB. Ango, ew dihêle hûn zû tomarên nû li wir tomar bikin û zû tomar bi pêşgirek diyarkirî hilbijêrin.
Em ê paşê li ser dezawantajên mergeset biaxivin. Naha em bipeyivin ka çi pirsgirêk bi VictoriaMetrics re di hilberînê de dema ku îndekek berevajî bicîh dikin de derketin.
Çima rabûn?
Sedema yekem rêjeya bilindbûna bilind e. Bi rûsî hatî wergerandin, ev di rêzikên demê de guherînek pir caran e. Ev gava ku rêzek dem diqede û rêzek nû dest pê dike, an jî gelek rêzikên dema nû dest pê dikin. Û ev pir caran dibe.
Sedema duyemîn jî hejmara zêde ya rêzikên demê ye. Di destpêkê de, dema ku çavdêrî populerbûna xwe bi dest dixist, hejmara rêzikên demê hindik bû. Mînakî, ji bo her komputerê hûn hewce ne ku CPU, bîranîn, torê û barkirina dîskê bişopînin. 4 rêzikên demê ji bo her komputerê. Em bibêjin 100 komputer û 400 rêzikên we hene. Ev pir hindik e.
Bi demê re, mirovan fêhm kir ku ew dikarin agahdariya hûrgelî bipîvin. Mînakî, barkirina ne ya tevahiya pêvajoyê, lê ji hev cuda ya her bingehê pêvajoyê bipîve. Ger we 40 core pêvajoyê hene, wê hingê we 40 carî zêdetir rêzikên dem hene ku hûn barkirina pêvajoyê bipîvin.
Lê ev ne hemû ye. Her bingehek pêvajoyek dikare çend rewşan hebin, wek bêkar, dema ku bêkar be. Û her weha di cîhê bikarhêner de, di cîhê kernel û dewletên din de bixebitin. Û her rewşek weha dikare wekî rêzek demjimêrek cûda jî were pîvandin. Ev jî hejmara rêzan 7-8 carî zêde dike.
Ji yek metrîkê me tenê ji bo yek kompîturê 40 x 8 = 320 metrîk girt. Bi 100 zêde bikin, li şûna 32 em 000 distînin.
Dûv re Kubernetes hat. Û ew xirabtir bû ji ber ku Kubernetes dikare gelek karûbarên cûda mêvandar bike. Her karûbarek li Kubernetes ji gelek podan pêk tê. Û ev hemû divê bên şopandin. Digel vê yekê, me bi domdarî guhertoyên nû yên karûbarên we bicîh dike. Ji bo her guhertoya nû, divê rêzikên dema nû werin afirandin. Di encamê de, hejmara rêzikên demê qat bi qat mezin dibe û em bi pirsgirêka hejmareke mezin a rêzikên demê re rû bi rû ne, ku jê re kardinalîteya bilind tê gotin. VictoriaMetrics bi wê re bi serfirazî li gorî databasên rêzikên dem ên din re mijûl dibe.
Werin em ji nêz ve li rêjeya bilindbûna bilindbûnê binêrin. Çi dibe sedem ku di hilberînê de rêjeyek bilind a hilberandinê? Ji ber ku hin wateyên etîket û etîketan tim diguherin.
Mînakî, Kubernetes bigirin, ku têgehek heye deployment, ango dema ku guhertoyek nû ya serîlêdana we tê derxistin. Ji ber hin sedeman, pêşdebirên Kubernetes biryar dan ku id-ya bicîhkirinê li labelê zêde bikin.
Ev bû sedema çi? Digel vê yekê, bi her danîna nû re, hemî rêzikên demên kevn têne qut kirin, û li şûna wan, rêzikên dema nû bi nirxek etîketek nû dest pê dikin. deployment_id. Dibe ku bi sed hezaran û heta bi mîlyonan rêzên weha hebin.
Di van hemûyan de ya girîng ew e ku hejmara giştî ya rêzikên demê mezin dibe, lê hêjmara rêzikên dema ku niha çalak in û daneyan distînin sabît dimîne. Ji vê rewşê re rêjeya bilindbûnê tê gotin.
Pirsgirêka sereke ya rêjeya bilindbûna bilind ev e ku ji bo hemî rêzikên demê ji bo komek diyarkirî ya etîketan di navberek demkî de bilezek lêgerînê ya domdar peyda bike. Bi gelemperî ev navbera demjimêra demjimêr an roja paşîn e.
Çawa vê pirsgirêkê çareser bike? Li vir vebijarka yekem e. Ev e ku bi demê re indexa berevajîkirî li beşên serbixwe dabeş bike. Ango, hin navberek dem derbas dibe, em xebata bi îndeksa berevajîkirî ya heyî diqedînin. Û navnîşek nû ya berevajî biafirînin. Demek din derbas dibe, em yekî din û ya din diafirînin.
Û dema ku ji van nîşaneyên berevajîkirî nimûne têne girtin, em komek nîşanekên berevajîkirî yên ku di nav navbera diyarkirî de dikevin, dibînin. Û, li gorî vê yekê, em ji wir id-ya rêzikên demjimêr hilbijêrin.
Ev çavkaniyan xilas dike ji ber ku em ne hewce ne ku li beşên ku di navbeyna diyarkirî de nagerin binihêrin. Ango, bi gelemperî, heke em daneyên demjimêra paşîn hilbijêrin, wê hingê ji bo navberên demên berê em daxwazan berdidin.
Ji bo çareserkirina vê pirsgirêkê vebijarkek din heye. Ev e ku ji bo her roj navnîşek cûda ya nasnameyên rêzikên demjimêr ên ku di wê rojê de qewimîne hilîne.
Feydeya vê çareseriyê li ser çareseriya berê ev e ku em agahdariya rêzikên demê yên ku bi demê re winda nabin dubare nakin. Ew bi berdewamî hene û naguherin.
Kêmasî ev e ku çareseriyek wusa dijwartir e ku were bicîh kirin û jêbirina wê jî dijwartir e. Û VictoriaMetrics vê çareseriyê hilbijart. Ji aliyê dîrokî ve bi vî rengî bû. Ev çareserî jî li gorî ya berê baş pêk tîne. Ji ber ku ev çareserî nehat bicîhanîn ji ber ku pêdivî ye ku daneyên di her dabeşkirinê de ji bo rêzikên demê yên ku naguherin, ango bi demê re winda nebin, bêne dubare kirin. VictoriaMetrics di serî de ji bo xerckirina cîhê dîskê xweşbîn bû, û pêkanîna berê xerckirina cîhê dîskê xirabtir kir. Lê ev pêkanîn ji bo kêmkirina xerckirina cîhê dîskê çêtir e, ji ber vê yekê hate hilbijartin.
Diviyabû ez bi wê re şer bikim. Têkoşîn ev bû ku di vê pêkanînê de hûn hîn jî hewce ne ku hejmareke pir mezintir hilbijêrin timeseries_ids ji bo daneyan ji dema ku nîşaneya berevajîkirî dem tê dabeş kirin.
Me ev pirsgirêk çawa çareser kir? Me ew bi rengek orîjînal çareser kir - bi hilanîna çend nasnameyên rêzikên demê di her navnîşek pêveka berevajîkirî de li şûna yek nasnameyê. Yanî kilîteke me heye label=value, ku di her rêzikên demê de pêk tê. Û niha em gelek xilas dikin timeseries_ids di yek têketinê de.
Li vir mînakek heye. Berê me N têketin hebûn, lê naha yek têketinek me heye ku pêşgira wê wekî hemî yên din e. Ji bo têketina berê, nirx hemî nasnameyên rêzikên demê dihewîne.
Vê yekê gengaz kir ku leza şopandinê ya pêdekek wusa berevajîkirî heya 10 carî zêde bike. Û ew hişt ku em xerckirina bîranînê ji bo cache kêm bikin, ji ber ku naha em rêzê hilînin label=value tenê carekê di kaşê de bi hev re N caran. Û ev xêz dikare mezin be ger hûn rêzikên dirêj di tag û etîketên xwe de hilînin, yên ku Kubernetes hez dike ku li wir bihejîne.
Vebijarkek din a ji bo bilezkirina lêgerîna li ser pêdekek berevajîkirî parvekirin e. Afirandina çend indexên berevajîkirî li şûna yek û parvekirina daneyan di navbera wan de bi mifteyê. Ev set e key=value bixar. Ango, em çend indeksên berevajîkirî yên serbixwe distînin, ku em dikarin li ser çend pêvajoyan bi paralelî lêpirsîn bikin. Sazkirinên berê tenê di moda yek-prosesor de destûr didin xebitandinê, ango, şopandina daneyan tenê li ser yek bingehîn. Ev çareserî dihêle hûn bi yekcarî daneyan li ser çend bingehan bişopînin, wekî ku ClickHouse hez dike. Ya ku em plan dikin ku pêk bînin ev e.
Naha em vegerin ser pezê xwe - li fonksiyona hevberdanê timeseries_ids. Werin em binihêrin ka çi pêkanîn dikarin hebin. Ev fonksiyon dihêle hûn bibînin timeseries_ids ji bo set dayîn label=value.
Vebijarka yekem pêkanînek naîf e. Du hêlînên hêlînkirî. Li vir em têketina fonksiyonê digirin intersectInts du perçe - a и b. Di encam de, divê ew li hevberdana van perçeyan li me vegere.
Pêkanîna naîf bi vî rengî xuya dike. Em li ser hemî nirxan ji perçeyê dubare dikin a, di hundurê vê pêlê de em di hemî nirxên perçeyê re derbas dibin b. Û em wan didin ber hev. Ger ew li hev bikin, wê hingê me navberek dîtiye. Û wê xilas bike result.
dezawantaj çi ne? Tevliheviya çargoşe kêmasiya wê ya sereke ye. Mînakî, heke pîvanên we perçe ne a и b yek mîlyon yek, wê hingê ev fonksiyon dê çu carî bersivek ji we re venegere. Ji ber ku ew ê hewce bike ku yek trîlyon dubareyan bike, ku ji bo komputerên nûjen jî pir e.
Pêkanîna duyemîn li ser nexşeyê ye. Em nexşeyê çêdikin. Em hemî nirxan ji perçeyê di vê nexşeyê de danîn a. Dûv re em di perçeyek veqetandî de derbas dibin b. Û em kontrol dikin ka ev nirx ji perçeyê ye b di nexşeyê de. Ger hebe, wê hingê wê li encamê zêde bike.
feydeyên wê çi ne? Awantaj ev e ku tenê tevliheviya xêzikî heye. Ango, fonksiyon dê ji bo perçeyên mezin pir zûtir pêk were. Ji bo perçeyek mîlyonek mezin, ev fonksiyon dê di 2 mîlyon dubareyan de, berevajî trîlyon dubareyên fonksiyona berê pêk were.
Nebaş ev e ku ev fonksiyon ji bo afirandina vê nexşeyê bêtir bîranîn hewce dike.
Kêmasiya duyemîn sermaya mezin a hashkirinê ye. Ev kêmasî ne pir eşkere ye. Û ji bo me ew jî ne pir eşkere bû, ji ber vê yekê di destpêkê de di VictoriaMetrics de pêkanîna hevberdanê bi nexşeyek bû. Lê dûv re profîlan nîşan da ku dema pêvajoyê ya sereke bi nivîsandina nexşeyê û kontrolkirina hebûna nirxek di vê nexşeyê de derbas dibe.
Çima dema CPU li van deran winda dibe? Ji ber ku Go li ser van xetan operasyonek haşkirinê pêk tîne. Ango, ew hashê mifteyê dihesibîne da ku paşê bigihîje navnîşek diyarkirî ya di HashMap-ê de. Operasyona hesabkirina hash bi dehan nanoseconds qediya. Ev ji bo VictoriaMetrics hêdî ye.
Min biryar da ku ez bitsetek bi taybetî ji bo vê dozê xweşbîn bikim. Bi vî awayî hevberdana du perçan niha dişibe. Li vir em bitsetek çêbikin. Em hêmanên ji parça yekem lê zêde dikin. Dûv re em hebûna van hêmanan di perçeya duyemîn de kontrol dikin. Û wan di encamê de zêde bike. Yanî hema bêje ji mînaka berê cudatir nîne. Li vir tenê tişt ev e ku me gihîştina nexşeyê bi fonksiyonên xwerû veguhezand add и has.
Di nihêrîna pêşîn de, wusa dixuye ku ev pêdivî ye ku hêdîtir bixebite, heke berê nexşeyek standard li wir hate bikar anîn, û dûv re hin fonksiyonên din têne gotin, lê profîlan nîşan dide ku ev tişt di doza VictoriaMetrics de 10 carî ji nexşeya standard zûtir dixebite.
Wekî din, ew li gorî pêkanîna nexşeyê pir kêmtir bîranîn bikar tîne. Ji ber ku em li vir li şûna nirxên heşt-byte bit-an hilînin.
Kêmasiya vê pêkanînê ew e ku ne ew qas eşkere ye, ne piçûk e.
Kêmasiyek din a ku dibe ku pir kes pê nehese ev e ku dibe ku ev pêkanîn di hin rewşan de baş nexebite. Ango, ew ji bo dozek taybetî, ji bo vê bûyera hevberdana nasnameyên rêzikên dema VictoriaMetrics, xweşbîn e. Ev nayê wê wateyê ku ew ji bo hemî rewşan maqûl e. Ger ew bi xeletî were bikar anîn, em ê ne zêdebûnek performansê, lê xeletiyek ji bîrê û kêmbûna performansê bistînin.
Werin em li ser pêkanîna vê strukturê bifikirin. Heke hûn dixwazin lê binêrin, ew di çavkaniyên VictoriaMetrics, di peldankê de ye . Ew bi taybetî ji bo doza VictoriaMetrics, li ku derê, xweşbîn e timeseries_id nirxek 64-bit e, ku 32 bitên pêşîn di bingeh de domdar in û tenê 32 bitên paşîn diguhezin.
Ev avahiya daneyê li ser dîskê nayê hilanîn, ew tenê di bîranînê de dixebite.
Li vir API-ya wê ye. Ew ne pir tevlihev e. API bi taybetî ji bo mînakek taybetî ya karanîna VictoriaMetrics ve hatî çêkirin. Ango li vir tu fonksiyonên nepêwîst nînin. Li vir fonksiyonên ku bi eşkere ji hêla VictoriaMetrics ve têne bikar anîn hene.
Fonksiyon hene add, ku nirxên nû zêde dike. Fonksiyonek heye has, ku ji bo nirxên nû kontrol dike. Û fonksiyonek heye del, ku nirxan jê dike. Fonksiyona alîkar heye len, ku mezinahiya set vedigere. Karkirin clone gelek klon dike. Û fonksiyonê appendto vê setê vediguherîne perçeyê timeseries_ids.
Ev e ku pêkanîna vê sazûmana daneyê wekî xuya dike. set du hêman hene:
-
ItemsCountzeviyek alîkar e ku zû vegere hejmara hêmanên di komekê de. Dê gengaz be ku bêyî vê qada alîkar were kirin, lê pêdivî bû ku ew li vir were zêdekirin ji ber ku VictoriaMetrics pir caran dirêjahiya bitsetê di algorîtmayên xwe de dipirse. -
Qada duyemîn e
buckets. Ev perçeyek ji avahiyê yebucket32. Her avahî dikanehierd. Ev 32 bitên jorîn in. Û du perçe -b16hisиbucketsjibucket16strukturên.
16 bitên jorîn ên beşa duyemîn a avahiya 64-bit li vir têne hilanîn. Û li vir bitset ji bo 16 bitsên jêrîn ên her byte têne hilanîn.
Bucket64 ji rêzê pêk tê uint64. Dirêjahî bi karanîna van berdewaman tê hesibandin. Di yek bucket16 herî zêde dikare were hilanîn 2^16=65536 gem. Heke hûn vê yekê bi 8-ê parve bikin, wê hingê ew 8 kilobyte ye. Ger hûn dîsa bi 8-ê dabeş bikin, ew dibe 1000 uint64 mane. Ku heye Bucket16 - ev avahiya me ya 8 kîlobyte ye.
Ka em binihêrin ka yek ji rêbazên vê strukturê ji bo lêzêdekirina nirxek nû çawa tête bicîh kirin.
Ev hemû bi dest pê dike uint64 wateyên. Em 32 bitên jorîn hesab dikin, em 32 bitên jêrîn hesab dikin. Werin em her tiştî derbas bikin buckets. Em 32 bitên jorîn ên di her kelekekê de bi nirxa ku lê zêde dikin re didin ber hev. Û heke ew li hev bikin, wê hingê em fonksiyonê dibêjin add di avahiya b32 de buckets. Û 32 bitên jêrîn li wir zêde bikin. Û eger ew vegeriya true, wê demê ev tê wê wateyê ku me nirxek wisa li wir zêde kiriye û nirxek me ya weha tuneye. Ger vegere false, hingê wateyek weha jixwe hebû. Dûv re em hejmara hêmanên di avahiyê de zêde dikin.
Ger me ya ku hûn hewce ne nedît bucket bi hi-nirxa pêwîst, wê hingê em fonksiyonê dibêjin addAlloc, ku dê yekî nû hilberîne bucket, wê li avahiya kepçeyê zêde bike.
Ev pêkanîna fonksiyonê ye b32.add. Dişibe pêkanîna berê. Em herî girîng 16 bit, ya herî kêm girîng 16 bit hesab dikin.
Dûv re em hemî 16 biteyên jorîn derbas dibin. Em lihevhatinan dibînin. Û heke hevberdanek hebe, em gazî rêbaza lêzêdekirinê dikin, ku em ê di rûpela pêş de ji bo wê bifikirin bucket16.
Û li vir asta herî jêrîn e, ku divê bi qasî ku gengaz were xweşbîn kirin. Em ji bo hesab dikin uint64 nirxa id di bit perçek û her weha bitmask. Ev maskek ji bo nirxek 64-bit a diyarkirî ye, ku dikare were bikar anîn da ku hebûna vê bîtê kontrol bike, an jî wê saz bike. Em kontrol dikin ku bibînin ka ev bit hatî danîn û wê saz bikin, û hebûna xwe vedigerînin. Ev pêkanîna me ye, ku destûr da me ku em li gorî nexşeyên kevneşopî 10 carî lezkirina xebata nasnameyên hevberdanê yên rêzikên demê zûtir bikin.
Ji bilî vê xweşbîniyê, VictoriaMetrics gelek xweşbîniyên din hene. Piraniya van xweşbîniyan ji ber sedemek hatine zêdekirin, lê piştî profîlkirina kodê di hilberînê de.
Ev qaîdeya sereke ya xweşbîniyê ye - xweşbîniyê lê zêde nekin bihesibînin ku dê li vir qeçikek çêbibe, ji ber ku dibe ku derkeve holê ku dê li wir xelekek tune be. Optimîzasyon bi gelemperî kalîteya kodê xirab dike. Ji ber vê yekê, hêja ye ku meriv tenê piştî profîlkirinê û bi tercîh di hilberînê de xweşbîn bike, da ku ev daneya rastîn be. Ger kesek eleqedar be, hûn dikarin li koda çavkaniya VictoriaMetrics binihêrin û xweşbîniyên din ên ku li wir hene bigerin.
Pirsek min li ser bitset heye. Pir dişibihe pêkanîna boolê vektorê C++, bitset xweşbînkirî. We pêkanîn ji wir girt?
Na, ne ji wir. Dema ku ez vê bitsetê bicih dikim, ez bi zanîna strukturên van rêzikên id-ê, yên ku di VictoriaMetrics de têne bikar anîn, rêberiya min kir. Û strûktûra wan wisa ye ku 32 bitên jorîn di bingeh de domdar in. 32 bitên jêrîn têne guhertin. Bit çiqas kêmtir be, pir caran ew dikare biguhere. Ji ber vê yekê, ev pêkanîn bi taybetî ji bo vê avahiya daneyê xweşbîn e. Pêkanîna C ++, bi qasî ku ez dizanim, ji bo doza gelemperî xweşbîn e. Ger hûn ji bo doza gelemperî xweşbîn bikin, ev tê vê wateyê ku ew ê ji bo dozek taybetî ne ya herî çêtirîn be.
Ez jî ji we re şîret dikim ku hûn li rapora Alexey Milovid temaşe bikin. Nêzîkî mehek berê, wî ji bo pisporên taybetî yên li ClickHouse li ser xweşbîniyê axivî. Ew tenê dibêje ku di rewşa gelemperî de, pêkanîna C ++ an hin pêkanînek din tête çêkirin ku bi navînî li nexweşxaneyê baş bixebite. Dibe ku ew ji pêkanînek zanîn-taybetî ya mîna ya me xirabtir bixebite, ku em dizanin ku 32 bitên jorîn bi piranî domdar in.
Pirsa min a duyemîn heye. Cûdahiya bingehîn ji InfluxDB çi ye?
Gelek cudahiyên bingehîn hene. Di warê performans û mezaxtina bîranînê de, InfluxDB di ceribandinan de 10 qat zêdetir xerckirina bîranînê ji bo rêzikên zemanê yên kardîneya bilind nîşan dide, gava ku we gelek ji wan hebin, mînakî bi mîlyonan. Mînakî, VictoriaMetrics ji mîlyon rêzên çalak 1 GB dixwe, dema ku InfluxDB 10 GB vedixwe. Û ew cudahiyek mezin e.
Cûdahiya bingehîn a duyemîn ev e ku InfluxDB xwedan zimanên pirsê yên ecêb e - Flux û InfluxQL. Ew ji bo xebata bi rêzikên demê re li gorî wan ne pir rehet in , ku ji hêla VictoriaMetrics ve tê piştgirî kirin. PromQL ji Prometheus zimanek pirsê ye.
Û cûdahiyek din jî ev e ku InfluxDB xwedan modelek daneya hûrgelek xerîb e, ku her rêzek dikare çend zeviyan bi komek celebên cûda hilîne. Van rêzan bêtir di tabloyên cihêreng de têne dabeş kirin. Van tevliheviyên zêde xebata paşîn bi vê databasê re tevlihev dike. Piştgirî û fêmkirin zehmet e.
Di VictoriaMetrics de her tişt pir hêsan e. Li wir, her rêzikên demkî mifteyek-nirxek e. Nirx komek xalan e - (timestamp, value), û kilît set e label=value. Di navbera zevî û pîvandinê de cudahî tune. Ew dihêle hûn her daneyê hilbijêrin û dûv re bihev bikin, lê zêde bikin, kêm bikin, zêde bikin, dabeş bikin, berevajî InfluxDB ku hesabên di navbera rêzên cihêreng de hîn jî bi qasî ku ez dizanim nayên pêkanîn. Ger ew bêne bicîh kirin jî, dijwar e, divê hûn gelek kodan binivîsin.
Pirseke min a zelalker heye. Ma min rast fêm kir ku pirsgirêkek ku we behs kir heye, ku ev nîşana berevajîkirî di bîra xwe de nagire, ji ber vê yekê li wir dabeşkirin heye?
Pêşîn, min li ser nexşeyek Go standard pêkanînek nefsbiçûk nîşanek berevajî nîşan da. Ev pêkanîn ji bo databasan ne guncaw e ji ber ku ev indexa berevajîkirî li ser dîskê nayê hilanîn, û divê databas li dîskê were hilanîn da ku ev dane piştî nûve destpêkirinê berdest bimîne. Di vê pêkanînê de, gava ku hûn serîlêdanê ji nû ve bidin destpêkirin, navnîşa weya berevajîkirî dê winda bibe. Û hûn ê gihîştina hemî daneyan winda bikin ji ber ku hûn ê nikaribin wê bibînin.
Slav! Spas ji bo raporê! Navê min Pavel e. Ez ji Wildberries im. Çend pirsên min ji we re hene. Pirs yek. Ma hûn difikirin ku heke we di avakirina mîmariya serîlêdana xwe de prensîbek cûda hilbijartibûya û we daneya bi demê re parve kiribûya, wê hingê dibe ku we di dema lêgerînê de daneya hev bikira, tenê li ser bingeha vê rastiyê ku yek dabeşek daneya yek heye heyama demê, ango di navberek demkî de û hûn neçar in ku ji rastiya ku perçeyên we bi rengek cûda belav bûne xeman bikin? Pirsa hejmar 2 - ji ber ku hûn bi bitset û her tiştê din re algorîtmayek wusa pêk tînin, wê hingê dibe ku we bi karanîna rêwerzên pêvajoyê hewl da? Dibe ku we xweşbîniyên weha ceribandiye?
Ez ê di cih de bersiva ya duyemîn bidim. Em hê negihîştine wê astê. Lê ger hewce bike em ê bigihin wir. Û ya yekem, pirs çi bû?
We du senaryo nîqaş kirin. Û wan got ku wan ya duyemîn bi pêkanîna tevlihevtir hilbijart. Û wan ya yekem tercîh nekir, ku dane ji hêla demê ve têne dabeş kirin.
Erê. Di bûyera yekem de, dê hêjmara giştî ya pêvekê mezintir be, ji ber ku di her dabeşkirinê de pêdivî ye ku em daneyên dubare ji bo wan rêzikên demê yên ku di nav van hemî dabeşan de berdewam dikin hilînin. Û heke rêjeya hejandina rêza weya demê piçûk be, ango heman rêz bi domdarî têne bikar anîn, wê hingê di rewşa yekem de em ê li gorî rewşa duyemîn di mîqdara cîhê dîskê de pir zêde winda bikin.
Û vî awayî - erê, dabeşkirina demê vebijarkek baş e. Prometheus bi kar tîne. Lê Prometheus kêmasiyeke din jî heye. Dema ku van perçeyên daneyan bi hev ve girêdide, pêdivî ye ku ew agahdariya meta ji bo hemî etîket û demjimêran di bîranînê de bigire. Ji ber vê yekê, heke perçeyên daneyên ku ew li hev dike mezin in, wê hingê vexwarina bîranînê di dema yekbûnê de pir zêde dibe, berevajî VictoriaMetrics. Dema ku yekbûnek çêdibe, VictoriaMetrics qet bîranînê naxwe; tenê çend kilobytes têne xerc kirin, bêyî ku mezinahiya perçeyên daneya hevgirtî be.
Algorîtmaya ku hûn bikar tînin bîra bikar tîne. Ew etîketên rêzikên demên ku nirxan dihewîne nîşan dide. Û bi vî awayî hûn hebûna cotek li yek rêzek daneyê û di yekî din de kontrol dikin. Û hûn fêm dikin ka hevberdan çêbûye an na. Bi gelemperî, databas cursors û îteratoran bicîh dikin ku naveroka xwe ya heyî hilînin û ji ber tevliheviya hêsan a van operasyonan di nav daneyên cûrbecûr re derbas dibin.
Çima em cursoran bikar naynin ku daneyan bigerin?
Erê
Em rêzikên rêzkirî di LevelDB an mergeset de hilînin. Em dikarin kursorê bilivînin û veqetandinê bibînin. Çima em wê bikar neynin? Ji ber ku hêdî ye. Ji ber ku kursor tê vê wateyê ku hûn hewce ne ku ji bo her rêzek fonksiyonek bang bikin. Bangek fonksiyonê 5 nanosecond e. Û heke we 100 xetên we hene, wê hingê derdikeve holê ku em nîv saniyeyê tenê gazîkirina fonksiyonê derbas dikin.
Tiştekî wisa heye, belê. Û pirsa min a dawî. Dibe ku pirs hinekî xerîb xuya bike. Çima ne mimkûn e ku di dema gihîştina daneyê de hemî berhevokên pêwîst bixwînin û wan di forma pêwîst de hilînin? Çima di hin pergalên mîna VictoriaMetrics, ClickHouse, hwd. de cildên mezin hilînin, û dûv re gelek wext li ser wan derbas dikin?
Ji bo zelaltir bibe ez ê mînakekê bidim. Ka em bibêjin leza pîvana pêlîstokek piçûk çawa dixebite? Ew dûrahiya ku we rê kiriye tomar dike, her dem wê li nirxek, û ya duyemîn - dema zêde dike. Û dabeş dike. Û leza navîn digire. Hûn dikarin li ser heman tiştî bikin. Hemî rastiyên pêwîst li ser firînê zêde bikin.
Okay, ez pirsê fam dikim. Mînaka we cihê xwe heye. Heke hûn dizanin ku hûn çi koman hewce ne, wê hingê ev pêkanîna çêtirîn e. Lê pirsgirêk ev e ku mirov van pîvanan, hin daneyan di ClickHouse de hilînin û ew hîn nizanin ka ew ê di pêşerojê de çawa wan kom bikin û fîlter bikin, ji ber vê yekê ew neçar in ku hemî daneyên xav hilînin. Lê heke hûn dizanin ku hûn hewce ne ku tiştek bi navînî hesab bikin, wê hingê çima li şûna ku hûn komek nirxên xav li wir hilînin, wê hesab nekin? Lê ev tenê heke hûn bi rastî zanibin ku hûn hewce ne.
Bi awayê, databasên ji bo hilanîna rêzikên demê piştgirî didin jimartina berhevokan. Mînak Prometheus piştgirî dike . Ango, heke hûn zanibin hûn ê hewceyê kîjan yekîneyên hanê bibin, ev dikare were kirin. VictoriaMetrics hîna vê yekê tune, lê bi gelemperî ji hêla Prometheus ve tê pêş, ku tê de ev dikare di qaîdeyên ji nû ve kodkirinê de were kirin.
Mînakî, di karê xweya berê de min hewce kir ku di saeta paşîn de hejmara bûyeran di pencereyek dakêşanê de bijmêrim. Pirsgirêk ev e ku ez neçar bûm ku di Go de pêkanîna xwerû, ango karûbarek ji bo jimartina vî tiştî bikim. Ev karûbar di dawiyê de ne-pîvan bû, ji ber ku ew zehmet e ku meriv hesab bike. Ger hewce be ku hûn di navberên demkî yên diyar de hin berhevokan bijmêrin, pêkanîn dikare hêsan be. Ger hûn dixwazin bûyeran di pencereyek şemitok de bijmêrin, wê hingê ew ne ew qas hêsan e ku xuya dike. Ez difikirim ku ev hîna di ClickHouse an di databasesên demjimêran de nehatiye bicîh kirin, ji ber ku pêkanîna wê dijwar e.
Û pirsek din. Me tenê li ser naverastkirinê dipeyivî, û hat bîra min ku carek tiştek wekî Grafît bi pişta Karbonê hebû. Û wî dizanibû ku meriv çawa daneyên kevin hûr bike, ango, her hûrdemek, di saetekê de xalek, hwd. Bihêle. Di prensîbê de, heke ji me re daneyên xav hewce bike, ji bo mehekê, û her tiştê din dikare hewce bike, ev pir hêsan e. zirav bibin. Lê Prometheus û VictoriaMetrics vê fonksiyonê piştgirî nakin. Ma tê plankirin ku piştgirî bikin? Ger na, çima na?
Spas ji bo pirsê. Bikarhênerên me vê pirsê dem bi dem dipirsin. Ew dipirsin ka em ê kengê piştgirî ji bo dakêşanê zêde bikin. Li vir gelek pirsgirêk hene. Ya yekem, her bikarhêner fêm dike downsampling tiştek cûda: kesek dixwaze li ser navberek diyarkirî xalek keyfî bigire, kesek nirxên herî zêde, hindik, navîn dixwaze. Ger gelek pergal daneyan li databasa we binivîsin, wê hingê hûn nekarin wan hemî bi hev re berhev bikin. Dibe ku her pergalek ziravkirina cûda hewce dike. Û ev yek zehmet e ku bicîh bikin.
Tişta duyemîn ev e ku VictoriaMetrics, mîna ClickHouse, ji bo xebitandina bi cildên mezin ên daneya xav xweştir e, ji ber vê yekê heke di pergala we de gelek naverok hebin, ew dikare di kêmtirî çirkeyek de mîlyar xet bişo. Di VictoriaMetrics-ê de xalên rêza demjimêran dişoxilînin - 50 xal di çirkê de serê bingehîn. Û ev performans li ser bingehên heyî tê pîvandin. Ango, heke mînakî 000 core we hebin, hûn ê di çirkeyê de mîlyar xalan bişopînin. Û ev taybetmendiya VictoriaMetrics û ClickHouse hewcedariya dakêşanê kêm dike.
Taybetmendiyek din ev e ku VictoriaMetrics bi bandor vê daneyê berhev dike. Di hilberînê de bi navgîniya tevlihevkirinê ji 0,4 ber 0,8 bayt per xalek e. Her xalek demjimêrek + nirxek e. Û ew bi navînî di kêmtirî yek byte de tê pêçandin.
Sergey. Pirsek min heye. Kuantuma dema tomarkirinê ya herî kêm çi ye?
Yek millisecond. Me herî dawî bi pêşdebirên databasên rêzikên dem ên din re danûstendinek kir. Parçeya dema wan a herî kêm yek saniye ye. Û di Graphite de, wek nimûne, ew jî yek duyemîn e. Di OpenTSDB de ew jî yek saniye ye. InfluxDB rastbûna nanosecond heye. Di VictoriaMetrics de ew millisecondek e, ji ber ku di Prometheus de ew yek millisecond e. Û VictoriaMetrics bi eslê xwe wekî hilanîna dûr ji bo Prometheus hate pêşve xistin. Lê niha ew dikare daneyên ji pergalên din xilas bike.
Kesê ku ez pê re peyivîm dibêje ku ew rastbûna duyemîn-duyemîn heye - ew ji wan re bes e ji ber ku ew bi celebê daneya ku di databasa rêzikên demê de têne hilanîn ve girêdayî ye. Ger ev daneya DevOps an daneya ji binesaziyê ye, ku hûn wê di navberên 30 çirkeyan de, serê hûrdemê berhev dikin, wê hingê rastbûna duyemîn bes e, hûn ne hewce ne tiştek kêmtir in. Û heke hûn van daneyan ji pergalên bazirganiya frekansa bilind berhev bikin, wê hingê hûn hewceyê rastbûna nanosecondê ne.
Di VictoriaMetrics de rastbûna millisecond di heman demê de ji bo doza DevOps jî maqûl e, û dikare ji bo piraniya dozên ku min di destpêka raporê de behs kir re maqûl be. Tenê tiştê ku dibe ku ew ne guncaw be pergalên bazirganiya frekansa bilind e.
Sipas ji were! Û pirsek din. Lihevhatî di PromQL de çi ye?
Lihevhatina paşverû ya tevahî. VictoriaMetrics bi tevahî PromQL piştgirî dike. Wekî din, ew fonksiyonên pêşkeftî yên din ên li PromQL, ku jê re tê gotin, zêde dike . Li ser YouTube-ê li ser vê fonksiyona dirêjkirî axaftinek heye. Ez di Civîna Şopandinê ya biharê de li St.
Kanala Telegram .
Tenê bikarhênerên qeydkirî dikarin beşdarî anketê bibin. ji kerema xwe.
Çi rê li ber we digre ku hûn ji bo Prometheus veguherînin VictoriaMetrics wekî hilanîna weya demdirêj? (Di şîroveyan de binivîsin, ez ê wê li anketê zêde bikim))
-
71,4%Ez Prometheus5 bikar naynim
-
28,6%Di derbarê VictoriaMetrics2 de nizanibû
7 bikarhêneran deng dan. 12 bikarhêner jî betal bûn.
Source: www.habr.com