Ninapendekeza usome nakala ya ripoti ya marehemu ya 2019 na Alexander Valyalkin "Nenda uboreshaji katika VictoriaMetrics"
- DBMS ya haraka na yenye hatari ya kuhifadhi na kusindika data katika mfumo wa safu ya wakati (rekodi hutengeneza wakati na seti ya maadili inayolingana na wakati huu, kwa mfano, inayopatikana kupitia upigaji kura wa mara kwa mara wa hali ya sensorer au mkusanyiko wa vipimo).
Hapa kuna kiunga cha video ya ripoti hii -
Tuambie kukuhusu. Mimi ni Alexander Valyalkin. Hapa . Nina shauku kuhusu Go na uboreshaji wa utendaji. Niliandika maktaba nyingi muhimu na sio muhimu sana. Wanaanza na ama fast, au na quick kiambishi awali.
Kwa sasa ninafanya kazi kwenye VictoriaMetrics. Ni nini na ninafanya nini huko? Nitazungumza juu ya hili katika uwasilishaji huu.
Muhtasari wa ripoti ni kama ifuatavyo:
- Kwanza, nitakuambia VictoriaMetrics ni nini.
- Kisha nitakuambia ni mfululizo gani wa saa.
- Kisha nitakuambia jinsi hifadhidata ya mfululizo wa wakati inavyofanya kazi.
- Ifuatayo, nitakuambia juu ya usanifu wa hifadhidata: inajumuisha nini.
- Na kisha tuendelee kwenye uboreshaji ambao VictoriaMetrics inayo. Huu ni uboreshaji wa faharasa iliyogeuzwa na uboreshaji wa utekelezaji wa bitset katika Go.
Je, kuna mtu yeyote katika hadhira anayejua VictoriaMetrics ni nini? Wow, watu wengi tayari wanajua. Ni habari njema. Kwa wale ambao hawajui, hii ni hifadhidata ya safu ya wakati. Inategemea usanifu wa ClickHouse, juu ya maelezo kadhaa ya utekelezaji wa ClickHouse. Kwa mfano, kwenye kama vile: MergeTree, hesabu sambamba kwenye vichakato vyote vinavyopatikana na uboreshaji wa utendakazi kwa kufanyia kazi vizuizi vya data ambavyo vimewekwa kwenye akiba ya kichakataji.
VictoriaMetrics hutoa mbano bora wa data kuliko hifadhidata zingine za mfululizo wa wakati.
Inapunguza wima - yaani, unaweza kuongeza wasindikaji zaidi, RAM zaidi kwenye kompyuta moja. VictoriaMetrics itatumia rasilimali hizi zinazopatikana kwa ufanisi na itaboresha tija ya mstari.
VictoriaMetrics pia hupima usawa - yaani, unaweza kuongeza nodi za ziada kwenye nguzo ya VictoriaMetrics, na utendaji wake utaongezeka karibu kwa mstari.
Kama ulivyokisia, VictoriaMetrics ni hifadhidata ya haraka, kwa sababu siwezi kuandika zingine. Na imeandikwa katika Go, kwa hivyo ninazungumza juu yake kwenye mkutano huu.
Nani anajua mfululizo wa saa ni nini? Pia anajua watu wengi. Msururu wa saa ni msururu wa jozi (timestamp, Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅), ambapo jozi hizi hupangwa kwa wakati. Thamani ni nambari ya sehemu inayoelea - float64.
Kila mfululizo wa saa unatambulishwa kipekee kwa ufunguo. Ufunguo huu unajumuisha nini? Inajumuisha seti isiyo tupu ya jozi za thamani-msingi.
Hapa kuna mfano wa mfululizo wa wakati. Ufunguo wa safu hii ni orodha ya jozi: __name__="cpu_usage" ni jina la kipimo, instance="my-server" - hii ndio kompyuta ambayo metriki hii inakusanywa, datacenter="us-east" - hii ni kituo cha data ambapo kompyuta hii iko.
Tulimalizia na jina la mfululizo wa saa linalojumuisha jozi tatu za thamani-msingi. Ufunguo huu unalingana na orodha ya jozi (timestamp, value). t1, t3, t3, ..., tN - hizi ni alama za nyakati, 10, 20, 12, ..., 15 - maadili yanayolingana. Haya ndio matumizi ya cpu kwa wakati fulani kwa safu fulani.
Mfululizo wa saa unaweza kutumika wapi? Je, kuna mtu yeyote ana wazo lolote?
- Katika DevOps, unaweza kupima CPU, RAM, mtandao, rps, idadi ya makosa, nk.
- IoT - tunaweza kupima joto, shinikizo, kuratibu za geo na kitu kingine.
- Pia fedha - tunaweza kufuatilia bei za kila aina ya hisa na sarafu.
- Kwa kuongeza, mfululizo wa saa unaweza kutumika katika ufuatiliaji wa michakato ya uzalishaji katika viwanda. Tuna watumiaji wanaotumia VictoriaMetrics kufuatilia mitambo ya upepo, kwa roboti.
- Mfululizo wa muda pia ni muhimu kwa kukusanya taarifa kutoka kwa vitambuzi vya vifaa mbalimbali. Kwa mfano, kwa injini; kwa kupima shinikizo la tairi; kwa kupima kasi, umbali; kwa kupima matumizi ya petroli, nk.
- Msururu wa saa unaweza pia kutumika kufuatilia ndege. Kila ndege ina kisanduku cheusi ambacho hukusanya mfululizo wa saa kwa vigezo mbalimbali vya afya ya ndege. Mfululizo wa wakati pia hutumiwa katika tasnia ya anga.
- Huduma ya afya ni shinikizo la damu, mapigo ya moyo, nk.
Kunaweza kuwa na programu zaidi ambazo nilisahau, lakini natumai unaelewa kuwa safu za wakati zinatumika kikamilifu katika ulimwengu wa kisasa. Na kiasi cha matumizi yao kinaongezeka kila mwaka.
Kwa nini unahitaji hifadhidata ya mfululizo wa wakati? Kwa nini huwezi kutumia hifadhidata ya kawaida ya uhusiano kuhifadhi safu za wakati?
Kwa sababu mfululizo wa wakati huwa na kiasi kikubwa cha habari, ambayo ni vigumu kuhifadhi na kuchakata katika hifadhidata za kawaida. Kwa hivyo, hifadhidata maalum za safu za wakati zilionekana. Misingi hii huhifadhi pointi kwa ufanisi (timestamp, value) na ufunguo uliopewa. Wanatoa API ya kusoma data iliyohifadhiwa kwa ufunguo, kwa jozi moja ya thamani ya ufunguo, au kwa jozi nyingi za thamani-funguo, au kwa regexp. Kwa mfano, unataka kupata mzigo wa CPU wa huduma zako zote katika kituo cha data huko Amerika, basi unahitaji kutumia hoja hii ya uwongo.
Kwa kawaida hifadhidata za mfululizo wa saa hutoa lugha maalum za maswali kwa sababu SQL ya mfululizo wa saa haifai sana. Ingawa kuna hifadhidata zinazounga mkono SQL, haifai sana. Lugha za maswali kama vile , , , . Natumaini kwamba kuna mtu amesikia angalau mojawapo ya lugha hizi. Watu wengi pengine wamesikia kuhusu PromQL. Hii ni lugha ya swala ya Prometheus.
Hivi ndivyo usanifu wa hifadhidata wa mfululizo wa kisasa unavyoonekana kutumia VictoriaMetrics kama mfano.
Inajumuisha sehemu mbili. Hii ni hifadhi ya faharasa iliyogeuzwa na hifadhi ya thamani za mfululizo wa saa. Hifadhi hizi zimetenganishwa.
Rekodi mpya inapofika kwenye hifadhidata, kwanza tunafikia faharasa iliyogeuzwa ili kupata kitambulisho cha mfululizo wa saa kwa seti fulani. label=value kwa kipimo fulani. Tunapata kitambulisho hiki na kuhifadhi thamani katika hifadhi ya data.
Ombi linapokuja la kupata data kutoka kwa TSDB, kwanza tunaenda kwenye faharasa iliyogeuzwa. Hebu tupate kila kitu timeseries_ids rekodi zinazolingana na seti hii label=value. Na kisha tunapata data zote muhimu kutoka kwa ghala la data, indexed by timeseries_ids.
Wacha tuangalie mfano wa jinsi hifadhidata ya mfululizo wa wakati inavyochakata swali linaloingia la kuchagua.
- Kwanza kabisa anapata kila kitu
timeseries_idskutoka kwa faharasa iliyogeuzwa ambayo ina jozi zilizotolewalabel=value, au ridhisha usemi fulani wa kawaida. - Kisha hupata pointi zote za data kutoka kwa hifadhi ya data kwa muda fulani kwa wale waliopatikana
timeseries_ids. - Baada ya hayo, hifadhidata hufanya mahesabu kadhaa kwenye vidokezo hivi vya data, kulingana na ombi la mtumiaji. Na baada ya hapo inarudisha jibu.
Katika uwasilishaji huu nitakuambia juu ya sehemu ya kwanza. Huu ni utafutaji timeseries_ids kwa faharasa iliyogeuzwa. Unaweza kutazama sehemu ya pili na ya tatu baadaye , au subiri hadi nitayarishe ripoti zingine :)
Wacha tuendelee kwenye faharasa iliyogeuzwa. Wengi wanaweza kufikiria hii ni rahisi. Nani anajua faharisi iliyogeuzwa ni nini na jinsi inavyofanya kazi? Lo, sio watu wengi tena. Hebu jaribu kuelewa ni nini.
Ni kweli rahisi. Ni kamusi tu inayoweka ufunguo wa thamani. Ufunguo ni nini? Wanandoa hawa label=valueAmbapo label ΠΈ value - hizi ni mistari. Na maadili ni seti timeseries_ids, ambayo inajumuisha jozi iliyotolewa label=value.
Faharasa iliyogeuzwa hukuruhusu kupata kila kitu haraka timeseries_ids, ambao wametoa label=value.
Pia hukuruhusu kupata haraka timeseries_ids mfululizo wa muda kwa jozi kadhaa label=value, au kwa wanandoa label=regexp. Je, hii hutokeaje? Kwa kutafuta makutano ya seti timeseries_ids kwa kila jozi label=value.
Hebu tuangalie utekelezaji mbalimbali wa faharisi iliyogeuzwa. Wacha tuanze na utekelezaji rahisi zaidi wa ujinga. Anaonekana hivi.
Kazi getMetricIDs hupata orodha ya masharti. Kila mstari una label=value. Chaguo hili la kukokotoa hurejesha orodha metricIDs.
Inavyofanya kazi? Hapa tunayo tofauti ya kimataifa inayoitwa invertedIndex. Hii ni kamusi ya kawaida (map), ambayo itaweka ramani ya kamba ili kukata ints. Mstari una label=value.
Utekelezaji wa kazi: pata metricIDs kwa wa kwanza label=value, kisha tunapitia kila kitu kingine label=value, tunaipata metricIDs kwa ajili yao. Na piga kazi intersectInts, ambayo itajadiliwa hapa chini. Na kazi hii inarudisha makutano ya orodha hizi.
Kama unaweza kuona, kutekeleza faharisi iliyogeuzwa sio ngumu sana. Lakini huu ni utekelezaji wa ujinga. Je, ina hasara gani? Ubaya kuu wa utekelezaji wa ujinga ni kwamba faharisi iliyogeuzwa huhifadhiwa kwenye RAM. Baada ya kuanzisha upya programu tunapoteza index hii. Hakuna uhifadhi wa faharisi hii kwenye diski. Faharasa kama hiyo iliyogeuzwa haiwezekani kufaa kwa hifadhidata.
Upungufu wa pili pia unahusiana na kumbukumbu. Faharasa iliyogeuzwa lazima ilingane na RAM. Ikiwa inazidi saizi ya RAM, basi ni wazi tutapata - kutoka kwa kosa la kumbukumbu. Na programu haitafanya kazi.
Tatizo hili linaweza kutatuliwa kwa kutumia suluhu zilizotengenezwa tayari kama vile Au .
Kwa kifupi, tunahitaji hifadhidata ambayo huturuhusu kufanya shughuli tatu haraka.
- Operesheni ya kwanza ni kurekodi
ΠΊΠ»ΡΡ-Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅kwenye hifadhidata hii. Yeye hufanya hivi haraka sana, wapiΠΊΠ»ΡΡ-Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅ni masharti holela. - Operesheni ya pili ni utafutaji wa haraka wa thamani kwa kutumia ufunguo fulani.
- Na operesheni ya tatu ni utaftaji wa haraka wa maadili yote kwa kiambishi awali.
LevelDB na RocksDB - hifadhidata hizi zilitengenezwa na Google na Facebook. Kwanza ilikuja LevelDB. Kisha watu kutoka Facebook walichukua LevelDB na kuanza kuiboresha, wakatengeneza RocksDB. Sasa karibu hifadhidata zote za ndani zinafanya kazi kwenye RocksDB ndani ya Facebook, pamoja na zile ambazo zimehamishiwa RocksDB na MySQL. Wakampa jina .
Faharasa iliyogeuzwa inaweza kutekelezwa kwa kutumia LevelDB. Jinsi ya kufanya hivyo? Tunahifadhi kama ufunguo label=value. Na thamani ni kitambulisho cha mfululizo wa saa ambapo jozi iko label=value.
Ikiwa tuna mfululizo wa muda mwingi na jozi fulani label=value, basi kutakuwa na safu nyingi katika hifadhidata hii na ufunguo sawa na tofauti timeseries_ids. Ili kupata orodha ya yote timeseries_ids, ambayo huanza na hii label=prefix, tunachanganua masafa ambayo hifadhidata hii imeboreshwa. Hiyo ni, tunachagua mistari yote inayoanza label=prefix na kupata kinachohitajika timeseries_ids.
Hapa kuna sampuli ya utekelezaji wa jinsi inavyoonekana katika Go. Tuna faharasa iliyogeuzwa. Hii ni LevelDB.
Kazi ni sawa na ya utekelezaji wa ujinga. Inarudia utekelezaji wa ujinga karibu mstari kwa mstari. Jambo pekee ni kwamba badala ya kugeuka map tunafikia faharisi iliyogeuzwa. Tunapata maadili yote kwa kwanza label=value. Kisha tunapitia jozi zote zilizobaki label=value na upate seti zinazolingana za vitambulisho vyao. Kisha tunapata makutano.
Kila kitu kinaonekana kuwa sawa, lakini kuna vikwazo kwa ufumbuzi huu. VictoriaMetrics hapo awali ilitekeleza faharasa iliyogeuzwa kulingana na LevelDB. Lakini mwishowe nililazimika kuiacha.
Kwa nini? Kwa sababu LevelDB ni polepole kuliko utekelezaji wa ujinga. Katika utekelezaji usio na maana, kutokana na ufunguo fulani, tunapata kipande nzima mara moja metricIDs. Hii ni operesheni ya haraka sana - kipande kizima kiko tayari kutumika.
Katika LevelDB, kila wakati kitendakazi kinapoitwa GetValues unahitaji kupitia mistari yote inayoanza label=value. Na upate thamani ya kila mstari timeseries_ids. Ya vile timeseries_ids kukusanya kipande cha hizi timeseries_ids. Ni wazi, hii ni polepole zaidi kuliko kupata tu ramani ya kawaida kwa ufunguo.
Kikwazo cha pili ni kwamba LevelDB imeandikwa katika C. Kupiga kazi kwa C kutoka kwa Go sio haraka sana. Inachukua mamia ya nanoseconds. Hii sio haraka sana, kwa sababu ikilinganishwa na simu ya kawaida ya kazi iliyoandikwa kwa kwenda, ambayo inachukua nanoseconds 1-5, tofauti katika utendaji ni makumi ya nyakati. Kwa VictoriaMetrics hii ilikuwa dosari mbaya :)
Kwa hivyo niliandika utekelezaji wangu mwenyewe wa faharisi iliyogeuzwa. Naye akamwita .
Mergeset inategemea muundo wa data wa MergeTree. Muundo huu wa data umekopwa kutoka kwa ClickHouse. Ni wazi, mergeset inapaswa kuboreshwa kwa utafutaji wa haraka timeseries_ids kulingana na ufunguo uliopewa. Mergeset imeandikwa kabisa katika Go. Unaweza kuona . Utekelezaji wa mergeset uko kwenye folda . Unaweza kujaribu kujua nini kinaendelea huko.
API ya kuunganisha ni sawa na LevelDB na RocksDB. Hiyo ni, hukuruhusu kuhifadhi haraka rekodi mpya hapo na uchague rekodi haraka kwa kiambishi awali.
Tutazungumza juu ya ubaya wa mergeset baadaye. Sasa hebu tuzungumze juu ya shida gani zilizotokea na VictoriaMetrics katika uzalishaji wakati wa kutekeleza faharisi iliyoingia.
Kwa nini yalitokea?
Sababu ya kwanza ni kiwango cha juu cha churn. Ilitafsiriwa kwa Kirusi, hii ni mabadiliko ya mara kwa mara katika mfululizo wa wakati. Huu ndio wakati ambapo mfululizo wa saa unaisha na mfululizo mpya huanza, au mfululizo mpya wa saa huanza. Na hii hutokea mara nyingi.
Sababu ya pili ni idadi kubwa ya safu za wakati. Mwanzoni, wakati ufuatiliaji ulikuwa unapata umaarufu, idadi ya mfululizo wa muda ilikuwa ndogo. Kwa mfano, kwa kila kompyuta unahitaji kufuatilia CPU, kumbukumbu, mtandao na mzigo wa disk. Mfululizo wa saa 4 kwa kila kompyuta. Wacha tuseme una kompyuta 100 na safu 400 za wakati. Hii ni kidogo sana.
Baada ya muda, watu waligundua kuwa wanaweza kupima habari zaidi ya punjepunje. Kwa mfano, pima mzigo sio wa processor nzima, lakini tofauti ya kila msingi wa processor. Ikiwa una cores 40 za kichakataji, basi una mfululizo wa muda mara 40 zaidi wa kupima mzigo wa kichakataji.
Lakini si hayo tu. Kila msingi wa kichakataji unaweza kuwa na majimbo kadhaa, kama vile kutofanya kitu, wakati hakuna kitu. Na pia fanya kazi katika nafasi ya mtumiaji, fanya kazi katika nafasi ya kernel na majimbo mengine. Na kila hali kama hiyo inaweza pia kupimwa kama safu tofauti ya wakati. Hii kwa kuongeza huongeza idadi ya safu kwa mara 7-8.
Kutoka kwa kipimo kimoja tulipata 40 x 8 = metrics 320 kwa kompyuta moja tu. Zidisha kwa 100, tunapata 32 badala ya 000.
Kisha Kubernetes akaja. Na ikawa mbaya zaidi kwa sababu Kubernetes inaweza kukaribisha huduma nyingi tofauti. Kila huduma katika Kubernetes ina maganda mengi. Na hii yote inahitaji kufuatiliwa. Kwa kuongeza, tuna uwekaji wa mara kwa mara wa matoleo mapya ya huduma zako. Kwa kila toleo jipya, mfululizo mpya wa saa lazima uundwe. Matokeo yake, idadi ya mfululizo wa muda inakua kwa kasi na tunakabiliwa na tatizo la idadi kubwa ya mfululizo wa muda, ambayo inaitwa high-cardinality. VictoriaMetrics inakabiliana nayo kwa mafanikio ikilinganishwa na hifadhidata zingine za safu za wakati.
Wacha tuangalie kwa karibu kiwango cha juu cha churn. Ni nini husababisha kiwango cha juu cha uchujaji katika uzalishaji? Kwa sababu baadhi ya maana za lebo na lebo zinabadilika kila mara.
Kwa mfano, chukua Kubernetes, ambayo ina dhana deployment, yaani, toleo jipya la programu yako linapotolewa. Kwa sababu fulani, wasanidi wa Kubernetes waliamua kuongeza kitambulisho cha kupeleka kwenye lebo.
Hii ilisababisha nini? Zaidi ya hayo, kwa kila utumaji mpya, safu zote za zamani hukatizwa, na badala yake, safu mpya ya wakati huanza na bei mpya ya lebo. deployment_id. Kunaweza kuwa na mamia ya maelfu na hata mamilioni ya safu kama hizo.
Jambo muhimu kuhusu haya yote ni kwamba idadi ya jumla ya mfululizo wa wakati inakua, lakini idadi ya mfululizo wa saa ambayo sasa ni hai na kupokea data inabaki mara kwa mara. Hali hii inaitwa kiwango cha juu cha churn.
Tatizo kuu la kiwango cha juu cha churn ni kuhakikisha kasi ya utafutaji ya mara kwa mara kwa mfululizo wa muda wote kwa seti fulani ya lebo kwa muda fulani. Kwa kawaida hiki ndicho kipindi cha saa cha mwisho au siku ya mwisho.
Jinsi ya kutatua tatizo hili? Hapa kuna chaguo la kwanza. Hii ni kugawanya faharasa iliyogeuzwa kuwa sehemu huru baada ya muda. Hiyo ni, muda wa muda hupita, tunamaliza kufanya kazi na faharisi ya sasa iliyogeuzwa. Na unda faharasa mpya iliyogeuzwa. Muda mwingine unapita, tunaunda mwingine na mwingine.
Na wakati wa kuchukua sampuli kutoka kwa fahirisi hizi zilizogeuzwa, tunapata seti ya fahirisi zilizogeuzwa ambazo ziko ndani ya muda uliotolewa. Na, ipasavyo, tunachagua kitambulisho cha safu ya saa kutoka hapo.
Hii inaokoa rasilimali kwa sababu sio lazima tuangalie sehemu ambazo haziingii ndani ya muda uliotolewa. Hiyo ni, kwa kawaida, ikiwa tunachagua data kwa saa iliyopita, basi kwa vipindi vya muda uliopita tunaruka maswali.
Kuna chaguo jingine la kutatua tatizo hili. Hii ni kuhifadhi kwa kila siku orodha tofauti ya vitambulisho vya mfululizo wa saa vilivyotokea siku hiyo.
Faida ya suluhisho hili juu ya suluhisho la awali ni kwamba haturudishi habari ya mfululizo wa saa ambayo haipotei baada ya muda. Wapo kila wakati na hawabadiliki.
Ubaya ni kwamba suluhisho kama hilo ni ngumu zaidi kutekeleza na ni ngumu zaidi kurekebisha. Na VictoriaMetrics ilichagua suluhisho hili. Hivi ndivyo ilivyotokea kihistoria. Suluhisho hili pia hufanya vizuri ikilinganishwa na uliopita. Kwa sababu suluhisho hili halikutekelezwa kwa sababu ya ukweli kwamba inahitajika kurudia data katika kila kizigeu kwa safu za wakati ambazo hazibadilika, i.e. ambazo hazipotee kwa wakati. VictoriaMetrics iliboreshwa kimsingi kwa matumizi ya nafasi ya diski, na utekelezaji uliopita ulifanya utumiaji wa nafasi ya diski kuwa mbaya zaidi. Lakini utekelezaji huu unafaa zaidi kwa kupunguza matumizi ya nafasi ya disk, kwa hiyo ilichaguliwa.
Ilibidi nipigane naye. Mapambano yalikuwa kwamba katika utekelezaji huu bado unahitaji kuchagua idadi kubwa zaidi timeseries_ids kwa data kuliko wakati faharasa iliyogeuzwa inagawanywa.
Je, tulitatuaje tatizo hili? Tuliitatua kwa njia ya asili - kwa kuhifadhi vitambulishi kadhaa vya mfululizo wa saa katika kila ingizo lililogeuzwa la faharasa badala ya kitambulisho kimoja. Hiyo ni, tuna ufunguo label=value, ambayo hutokea katika kila mfululizo wa wakati. Na sasa tunaokoa kadhaa timeseries_ids katika ingizo moja.
Hapa kuna mfano. Hapo awali tulikuwa na maingizo N, lakini sasa tuna ingizo moja ambalo kiambishi awali chake ni sawa na vingine vyote. Kwa ingizo la awali, thamani ina vitambulisho vya mfululizo wa muda wote.
Hii ilifanya iwezekane kuongeza kasi ya skanning ya faharisi iliyogeuzwa hadi mara 10. Na ilituruhusu kupunguza matumizi ya kumbukumbu kwa cache, kwa sababu sasa tunahifadhi kamba label=value mara moja tu kwenye kashe pamoja mara N. Na mstari huu unaweza kuwa mkubwa ikiwa utahifadhi mistari mirefu katika lebo na lebo zako, ambazo Kubernetes hupenda kusukuma hapo.
Chaguo jingine la kuharakisha utaftaji kwenye faharisi iliyogeuzwa ni kugawanyika. Kuunda faharasa kadhaa zilizogeuzwa badala ya moja na kushiriki data kati yao kwa ufunguo. Hii ni seti key=value mvuke. Hiyo ni, tunapata indexes kadhaa za kujitegemea zilizogeuzwa, ambazo tunaweza kuuliza kwa sambamba kwenye wasindikaji kadhaa. Utekelezaji wa awali uliruhusu tu uendeshaji katika hali ya kichakataji kimoja, yaani, kuchanganua data kwenye msingi mmoja pekee. Suluhisho hili hukuruhusu kuchanganua data kwenye cores kadhaa mara moja, kama ClickHouse inavyopenda kufanya. Hili ndilo tunalopanga kutekeleza.
Sasa hebu turudi kwa kondoo wetu - kwa kazi ya makutano timeseries_ids. Wacha tuchunguze ni utekelezaji gani unaweza kuwa. Kitendaji hiki hukuruhusu kupata timeseries_ids kwa seti fulani label=value.
Chaguo la kwanza ni utekelezaji wa ujinga. Vitanzi viwili vya kiota. Hapa tunapata ingizo la chaguo la kukokotoa intersectInts vipande viwili - a ΠΈ b. Katika pato, inapaswa kurudi kwetu makutano ya vipande hivi.
Utekelezaji wa ujinga unaonekana kama hii. Tunasisitiza juu ya maadili yote kutoka kwa kipande a, ndani ya kitanzi hiki tunapitia maadili yote ya kipande b. Na tunawalinganisha. Ikiwa zinalingana, basi tumepata makutano. Na uihifadhi ndani result.
Je, kuna hasara gani? Ugumu wa Quadratic ni drawback yake kuu. Kwa mfano, ikiwa vipimo vyako ni vipande a ΠΈ b milioni moja kwa wakati mmoja, basi kazi hii haitarudi jibu kwako. Kwa sababu itahitaji kufanya marudio ya trilioni moja, ambayo ni mengi hata kwa kompyuta za kisasa.
Utekelezaji wa pili unategemea ramani. Tunatengeneza ramani. Tunaweka maadili yote kutoka kipande hadi kwenye ramani hii a. Kisha tunapitia kipande katika kitanzi tofauti b. Na sisi kuangalia kama thamani hii ni kutoka kipande b katika ramani. Ikiwa iko, basi uiongeze kwenye matokeo.
Je, ni faida gani? Faida ni kwamba kuna utata wa mstari tu. Hiyo ni, kazi itafanya kwa kasi zaidi kwa vipande vikubwa. Kwa kipande cha ukubwa wa milioni, chaguo hili la kukokotoa litatekelezwa kwa marudio milioni 2, kinyume na marudio ya trilioni ya chaguo la kukokotoa la awali.
Upande wa chini ni kwamba kitendakazi hiki kinahitaji kumbukumbu zaidi ili kuunda ramani hii.
Kikwazo cha pili ni kichwa kikubwa cha hashing. Drawback hii sio dhahiri sana. Na kwetu sisi pia haikuwa dhahiri sana, kwa hivyo mwanzoni katika VictoriaMetrics utekelezaji wa makutano ulikuwa kupitia ramani. Lakini basi uwekaji wasifu ulionyesha kuwa wakati mkuu wa kichakataji hutumika kuandika kwenye ramani na kuangalia uwepo wa thamani kwenye ramani hii.
Kwa nini wakati wa CPU unapotea katika maeneo haya? Kwa sababu Go hufanya operesheni ya hashing kwenye mistari hii. Hiyo ni, huhesabu heshi ya ufunguo ili kuifikia kwa faharasa fulani katika HashMap. Operesheni ya kuhesabu heshi inakamilishwa katika makumi ya nanoseconds. Hii ni polepole kwa VictoriaMetrics.
Niliamua kutekeleza bitset iliyoboreshwa haswa kwa kesi hii. Hivi ndivyo makutano ya vipande viwili sasa inaonekana. Hapa tunaunda bitset. Tunaongeza vitu kutoka kwa kipande cha kwanza kwake. Kisha tunaangalia uwepo wa vipengele hivi kwenye kipande cha pili. Na uwaongeze kwenye matokeo. Hiyo ni, ni karibu hakuna tofauti na mfano uliopita. Jambo pekee hapa ni kwamba tulibadilisha ufikiaji wa ramani na vitendaji maalum add ΠΈ has.
Kwa mtazamo wa kwanza, inaonekana kwamba hii inapaswa kufanya kazi polepole, ikiwa hapo awali ramani ya kawaida ilitumiwa hapo, na kisha kazi nyingine huitwa, lakini maelezo mafupi yanaonyesha kuwa jambo hili linafanya kazi mara 10 kwa kasi zaidi kuliko ramani ya kawaida katika kesi ya VictoriaMetrics.
Kwa kuongeza, hutumia kumbukumbu kidogo sana ikilinganishwa na utekelezaji wa ramani. Kwa sababu tunahifadhi biti hapa badala ya thamani za baiti nane.
Ubaya wa utekelezaji huu ni kwamba sio dhahiri sana, sio kidogo.
Kikwazo kingine ambacho wengi hawawezi kutambua ni kwamba utekelezaji huu unaweza usifanye kazi vizuri katika baadhi ya matukio. Hiyo ni, imeboreshwa kwa kesi mahususi, kwa kesi hii ya makutano ya vitambulisho vya mfululizo wa saa vya VictoriaMetrics. Hii haimaanishi kuwa inafaa kwa kesi zote. Ikiwa inatumiwa vibaya, hatutapata ongezeko la utendaji, lakini kosa la nje ya kumbukumbu na kushuka kwa utendaji.
Hebu fikiria utekelezaji wa muundo huu. Ikiwa unataka kuangalia, iko katika vyanzo vya VictoriaMetrics, kwenye folda . Imeboreshwa haswa kwa kesi ya VictoriaMetrics, ambapo timeseries_id ni thamani ya 64-bit, ambapo biti 32 za kwanza kimsingi hazibadilika na ni biti 32 pekee za mwisho hubadilika.
Muundo huu wa data hauhifadhiwa kwenye diski, inafanya kazi tu kwenye kumbukumbu.
Hapa kuna API yake. Sio ngumu sana. API imeundwa mahsusi kwa mfano maalum wa kutumia VictoriaMetrics. Hiyo ni, hakuna kazi zisizohitajika hapa. Hapa kuna chaguo za kukokotoa ambazo zinatumiwa kwa uwazi na VictoriaMetrics.
Kuna kazi add, ambayo huongeza maadili mapya. Kuna kazi has, ambayo hukagua maadili mapya. Na kuna kazi del, ambayo huondoa maadili. Kuna kazi ya msaidizi len, ambayo inarudisha saizi ya seti. Kazi clone clones sana. Na kazi appendto hubadilisha seti hii kuwa kipande timeseries_ids.
Hivi ndivyo utekelezaji wa muundo huu wa data unavyoonekana. seti ina mambo mawili:
-
ItemsCountni sehemu ya usaidizi ya kurejesha kwa haraka idadi ya vipengele katika seti. Ingewezekana kufanya bila uga huu msaidizi, lakini ilibidi iongezwe hapa kwa sababu VictoriaMetrics mara nyingi huuliza urefu wa bitset katika algoriti zake. -
Sehemu ya pili ni
buckets. Hii ni kipande kutoka kwa muundobucket32. Kila muundo huhifadhihishamba. Hizi ni bits 32 za juu. Na vipande viwili -b16hisΠΈbucketsyabucket16miundo.
Biti 16 za juu za sehemu ya pili ya muundo wa 64-bit zimehifadhiwa hapa. Na hapa bitsets huhifadhiwa kwa bits 16 za chini za kila byte.
Bucket64 inajumuisha safu uint64. Urefu huhesabiwa kwa kutumia viunga hivi. Katika moja bucket16 upeo unaweza kuhifadhiwa 2^16=65536 kidogo. Ikiwa unagawanya hii na 8, basi ni 8 kilobytes. Ukigawanya kwa 8 tena, ni 1000 uint64 maana. Hiyo ni Bucket16 - huu ni muundo wetu wa kilobyte 8.
Wacha tuangalie jinsi moja ya njia za muundo huu wa kuongeza thamani mpya inatekelezwa.
Yote huanza na uint64 maana. Tunahesabu bits 32 za juu, tunahesabu bits 32 za chini. Hebu kupitia kila kitu buckets. Tunalinganisha biti 32 za juu katika kila ndoo na thamani inayoongezwa. Na ikiwa zinalingana, basi tunaita kazi add katika muundo b32 buckets. Na ongeza bits 32 za chini hapo. Na ikiwa imerudi true, basi hii ina maana kwamba tuliongeza thamani hiyo hapo na hatukuwa na thamani hiyo. Ikiwa inarudi false, basi maana kama hiyo tayari ipo. Kisha tunaongeza idadi ya vipengele katika muundo.
Ikiwa hatujapata unayohitaji bucket na thamani inayohitajika ya hi, basi tunaita kazi addAlloc, ambayo itazalisha mpya bucket, akiiongeza kwenye muundo wa ndoo.
Huu ni utekelezaji wa kazi b32.add. Ni sawa na utekelezaji uliopita. Tunahesabu biti 16 muhimu zaidi, biti 16 muhimu zaidi.
Kisha tunapitia bits zote 16 za juu. Tunapata mechi. Na ikiwa kuna mechi, tunaita njia ya kuongeza, ambayo tutazingatia kwenye ukurasa unaofuata bucket16.
Na hapa kuna kiwango cha chini kabisa, ambacho kinapaswa kuboreshwa iwezekanavyo. Tunahesabu kwa uint64 thamani ya id katika kipande kidogo na pia bitmask. Hii ni mask kwa thamani fulani ya 64-bit, ambayo inaweza kutumika kuangalia uwepo wa biti hii, au kuiweka. Tunaangalia ili kuona ikiwa biti hii imewekwa na kuiweka, na kurudisha uwepo. Huu ni utekelezaji wetu, ambao ulituruhusu kuharakisha utendakazi wa vitambulisho vya kuingiliana vya mfululizo wa wakati kwa mara 10 ikilinganishwa na ramani za kawaida.
Kando na uboreshaji huu, VictoriaMetrics ina uboreshaji mwingine mwingi. Uboreshaji mwingi uliongezwa kwa sababu fulani, lakini baada ya kuorodhesha msimbo katika uzalishaji.
Hii ndio kanuni kuu ya utoshelezaji - usiongeze uboreshaji kwa kudhani kutakuwa na kizuizi hapa, kwa sababu inaweza kuibuka kuwa hakutakuwa na kizuizi hapo. Uboreshaji kawaida hushusha ubora wa msimbo. Kwa hivyo, inafaa kuboresha tu baada ya kuorodhesha na ikiwezekana katika uzalishaji, ili hii ni data halisi. Ikiwa kuna mtu yeyote anayevutiwa, unaweza kuangalia msimbo wa chanzo wa VictoriaMetrics na uchunguze uboreshaji mwingine ulio hapo.
Nina swali kuhusu bitset. Sawa sana na utekelezaji wa bool ya vekta ya C++, bitset iliyoboreshwa. Umechukua utekelezaji kutoka hapo?
Hapana, sio kutoka hapo. Wakati wa kutekeleza bitset hii, niliongozwa na ujuzi wa muundo wa vipindi hivi vya vitambulisho, vinavyotumika katika VictoriaMetrics. Na muundo wao ni kwamba bits 32 za juu ni za mara kwa mara. Biti 32 za chini zinaweza kubadilika. Kidogo kidogo, mara nyingi kinaweza kubadilika. Kwa hivyo, utekelezaji huu umeboreshwa mahususi kwa muundo huu wa data. Utekelezaji wa C ++, ninavyojua, umeboreshwa kwa kesi ya jumla. Ikiwa utaboresha kwa kesi ya jumla, hii inamaanisha kuwa haitakuwa bora zaidi kwa kesi maalum.
Pia nakushauri uangalie ripoti ya Alexey Milovid. Karibu mwezi mmoja uliopita, alizungumza juu ya uboreshaji katika ClickHouse kwa utaalam maalum. Anasema tu kwamba kwa ujumla, utekelezaji wa C ++ au utekelezaji mwingine umewekwa ili kufanya kazi vizuri kwa wastani katika hospitali. Inaweza kufanya vibaya zaidi kuliko utekelezaji wa maarifa mahususi kama yetu, ambapo tunajua kuwa biti 32 za juu hazibadiliki.
Nina swali la pili. Ni tofauti gani ya kimsingi kutoka kwa InfluxDB?
Kuna tofauti nyingi za kimsingi. Kwa upande wa utendaji na matumizi ya kumbukumbu, InfluxDB katika vipimo inaonyesha matumizi ya kumbukumbu mara 10 zaidi kwa mfululizo wa muda wa kadiinality, wakati una mengi yao, kwa mfano, mamilioni. Kwa mfano, VictoriaMetrics hutumia GB 1 kwa kila safu mlalo milioni amilifu, huku InfluxDB hutumia GB 10. Na hiyo ni tofauti kubwa.
Tofauti ya pili ya kimsingi ni kwamba InfluxDB ina lugha za ajabu za maswali - Flux na InfluxQL. Sio rahisi sana kufanya kazi na safu ya wakati ikilinganishwa na , ambayo inaungwa mkono na VictoriaMetrics. PromQL ni lugha ya kuuliza kutoka Prometheus.
Na tofauti moja zaidi ni kwamba InfluxDB ina modeli ya data ya kushangaza kidogo, ambapo kila mstari unaweza kuhifadhi sehemu kadhaa na seti tofauti za vitambulisho. Mistari hii imegawanywa zaidi katika meza mbalimbali. Matatizo haya ya ziada yanatatiza kazi inayofuata na hifadhidata hii. Ni vigumu kuunga mkono na kuelewa.
Katika VictoriaMetrics kila kitu ni rahisi zaidi. Huko, kila mfululizo wa saa ni thamani-msingi. Thamani ni seti ya pointi - (timestamp, value), na ufunguo ni seti label=value. Hakuna utengano kati ya uwanja na vipimo. Inakuruhusu kuchagua data yoyote na kisha kuchanganya, kuongeza, kutoa, kuzidisha, kugawanya, tofauti na InfluxDB ambapo mahesabu kati ya safu mlalo tofauti bado hayatekelezwi nijuavyo. Hata kama yanatekelezwa, ni vigumu, lazima uandike kanuni nyingi.
Nina swali la kufafanua. Je, nilielewa kwa usahihi kwamba kulikuwa na aina fulani ya tatizo ulilozungumzia, kwamba faharasa hii iliyogeuzwa haiingii kwenye kumbukumbu, kwa hivyo kuna ugawaji hapo?
Kwanza, nilionyesha utekelezaji wa ujinga wa faharisi iliyogeuzwa kwenye ramani ya kawaida ya Go. Utekelezaji huu haufai kwa hifadhidata kwa sababu faharasa hii iliyogeuzwa haijahifadhiwa kwenye diski, na hifadhidata lazima ihifadhiwe kwenye diski ili data hii iendelee kupatikana inapowashwa upya. Katika utekelezaji huu, unapoanzisha upya programu, faharasa yako iliyogeuzwa itatoweka. Na utapoteza ufikiaji wa data yote kwa sababu hutaweza kuipata.
Habari! Asante kwa ripoti! Jina langu ni Pavel. Ninatoka Wildberries. Nina maswali machache kwako. Swali moja. Unafikiria kwamba ikiwa ungechagua kanuni tofauti wakati wa kujenga usanifu wa programu yako na kugawa data kwa wakati, basi labda ungekuwa na uwezo wa kuingiliana na data wakati wa kutafuta, kwa kuzingatia tu ukweli kwamba kizigeu kimoja kina data ya moja. kipindi cha muda , yaani, katika muda mmoja na hungehitaji kuwa na wasiwasi kuhusu ukweli kwamba vipande vyako vimetawanyika tofauti? Swali namba 2 - kwa kuwa unatekeleza algorithm sawa na bitset na kila kitu kingine, basi labda ulijaribu kutumia maelekezo ya processor? Labda umejaribu uboreshaji kama huo?
Nitajibu la pili mara moja. Bado hatujafikia hatua hiyo. Lakini ikiwa ni lazima, tutafika huko. Na la kwanza, swali lilikuwa nini?
Ulijadili matukio mawili. Na walisema kwamba walichagua ya pili na utekelezaji ngumu zaidi. Na hawakupendelea ile ya kwanza, ambapo data imegawanywa kwa wakati.
Ndiyo. Katika kesi ya kwanza, jumla ya kiasi cha faharisi kingekuwa kikubwa zaidi, kwa sababu katika kila kizigeu tutalazimika kuhifadhi nakala za data kwa safu hizo za saa zinazoendelea kupitia sehemu hizi zote. Na ikiwa kiwango chako cha churn cha safu ya wakati ni ndogo, i.e. safu kama hiyo hutumiwa kila wakati, basi katika kesi ya kwanza tutapoteza zaidi kwa kiasi cha nafasi ya diski iliyochukuliwa ikilinganishwa na kesi ya pili.
Na kwa hivyo - ndio, kugawa wakati ni chaguo nzuri. Prometheus anaitumia. Lakini Prometheus ana shida nyingine. Wakati wa kuunganisha vipande hivi vya data, inahitaji kuweka katika kumbukumbu maelezo ya meta kwa lebo zote na mfululizo wa nyakati. Kwa hiyo, ikiwa vipande vya data ambavyo huunganisha ni kubwa, basi matumizi ya kumbukumbu huongezeka sana wakati wa kuunganisha, tofauti na VictoriaMetrics. Wakati wa kuunganisha, VictoriaMetrics haitumii kumbukumbu hata kidogo; ni kilobaiti chache tu ndizo zinazotumiwa, bila kujali ukubwa wa vipande vya data vilivyounganishwa.
Algorithm unayotumia hutumia kumbukumbu. Inaashiria lebo za mfululizo wa nyakati ambazo zina thamani. Na kwa njia hii unaangalia uwepo wa vilivyooanishwa katika safu moja ya data na katika nyingine. Na unaelewa ikiwa makutano yalitokea au la. Kwa kawaida, hifadhidata hutekeleza vielekezi na virudiarudia ambavyo huhifadhi maudhui yao ya sasa na hupitia data iliyopangwa kutokana na uchangamano rahisi wa shughuli hizi.
Kwa nini hatutumii vishale kupitisha data?
Ndiyo.
Tunahifadhi safu mlalo zilizopangwa katika LevelDB au mergeset. Tunaweza kusogeza mshale na kupata makutano. Kwa nini tusiitumie? Kwa sababu ni polepole. Kwa sababu cursors ina maana kwamba unahitaji kupiga kazi kwa kila mstari. Simu ya kukokotoa ni nanoseconds 5. Na ikiwa una mistari 100, basi inageuka kuwa tunatumia nusu ya pili tu kuita kazi.
Kuna kitu kama hicho, ndio. Na swali langu la mwisho. Swali linaweza kuonekana kuwa la kushangaza kidogo. Kwa nini haiwezekani kusoma majumuisho yote muhimu wakati data inapofika na kuihifadhi katika fomu inayotakiwa? Kwa nini uhifadhi kiasi kikubwa katika baadhi ya mifumo kama VictoriaMetrics, ClickHouse, n.k., kisha utumie muda mwingi kuzitumia?
Nitatoa mfano ili kuifanya iwe wazi zaidi. Hebu tuseme jinsi kipima kasi cha toy kinafanya kazi? Inarekodi umbali ambao umesafiri, wakati wote ukiiongeza kwa thamani moja, na ya pili - wakati. Na kugawanyika. Na hupata kasi ya wastani. Unaweza kufanya juu ya kitu kimoja. Kuongeza juu ya ukweli wote muhimu juu ya kuruka.
Sawa, ninaelewa swali. Mfano wako una nafasi yake. Ikiwa unajua ni aggregates gani unahitaji, basi hii ni utekelezaji bora. Lakini tatizo ni kwamba watu huhifadhi vipimo hivi, baadhi ya data katika ClickHouse na bado hawajui jinsi watakavyojumlisha na kuzichuja katika siku zijazo, kwa hivyo wanapaswa kuhifadhi data zote mbichi. Lakini ikiwa unajua unahitaji kuhesabu kitu kwa wastani, basi kwa nini usihesabu badala ya kuhifadhi rundo la maadili ghafi hapo? Lakini hii ni tu ikiwa unajua hasa unahitaji.
Kwa njia, hifadhidata za kuhifadhi safu za wakati zinasaidia kuhesabu jumla. Kwa mfano, Prometheus inasaidia . Hiyo ni, hii inaweza kufanywa ikiwa unajua ni vitengo gani utahitaji. VictoriaMetrics haina hii bado, lakini kawaida hutanguliwa na Prometheus, ambayo hii inaweza kufanywa katika sheria za kuweka upya.
Kwa mfano, katika kazi yangu ya awali nilihitaji kuhesabu idadi ya matukio katika dirisha la kuteleza zaidi ya saa iliyopita. Shida ni kwamba ilinibidi kufanya utekelezaji maalum katika Go, yaani, huduma ya kuhesabu kitu hiki. Huduma hii hatimaye haikuwa ndogo, kwa sababu ni vigumu kuhesabu. Utekelezaji unaweza kuwa rahisi ikiwa unahitaji kuhesabu majumuisho kadhaa kwa vipindi maalum vya wakati. Ikiwa unataka kuhesabu matukio kwenye dirisha la kuteleza, basi sio rahisi kama inavyoonekana. Nadhani hii bado haijatekelezwa katika ClickHouse au katika hifadhidata za mfululizo, kwa sababu ni ngumu kutekeleza.
Na swali moja zaidi. Tulikuwa tu kuzungumza juu ya wastani, na nikakumbuka kwamba kulikuwa na kitu kama Graphite na backend Carbon. Na alijua jinsi ya kupunguza data ya zamani, yaani, kuacha pointi moja kwa dakika, pointi moja kwa saa, nk. Kimsingi, hii ni rahisi sana ikiwa tunahitaji data ghafi, kwa kiasi kikubwa, kwa mwezi, na kila kitu kingine kinaweza. kupunguzwa. Lakini Prometheus na VictoriaMetrics haziungi mkono utendakazi huu. Je, imepangwa kuiunga mkono? Ikiwa sivyo, kwa nini?
Asante kwa swali. Watumiaji wetu huuliza swali hili mara kwa mara. Wanauliza ni lini tutaongeza usaidizi wa kupunguza sampuli. Kuna matatizo kadhaa hapa. Kwanza, kila mtumiaji anaelewa downsampling kitu tofauti: mtu anataka kupata hatua yoyote ya kiholela kwa muda fulani, mtu anataka kiwango cha juu, cha chini, maadili ya wastani. Ikiwa mifumo mingi itaandika data kwenye hifadhidata yako, basi huwezi kuiweka pamoja. Inaweza kuwa kwamba kila mfumo unahitaji kukonda tofauti. Na hii ni ngumu kutekeleza.
Na jambo la pili ni kwamba VictoriaMetrics, kama ClickHouse, imeboreshwa kwa kufanya kazi kwa idadi kubwa ya data mbichi, kwa hivyo inaweza kusukuma mistari bilioni chini ya sekunde ikiwa una cores nyingi kwenye mfumo wako. Inachanganua pointi za mfululizo wa muda katika VictoriaMetrics - pointi 50 kwa sekunde kwa kila msingi. Na utendaji huu unalingana na cores zilizopo. Hiyo ni, ikiwa una cores 000, kwa mfano, utachambua pointi bilioni kwa pili. Na mali hii ya VictoriaMetrics na ClickHouse inapunguza hitaji la kupunguza.
Kipengele kingine ni kwamba VictoriaMetrics inabana data hii kwa ufanisi. Mfinyazo kwa wastani katika uzalishaji ni kutoka baiti 0,4 hadi 0,8 kwa kila nukta. Kila nukta ni muhuri wa muda + thamani. Na imebanwa kuwa chini ya baiti moja kwa wastani.
Sergey. Nina swali. Kiasi cha chini cha muda wa kurekodi ni kipi?
Milisekunde moja. Hivi majuzi tulifanya mazungumzo na watengenezaji hifadhidata wengine wa mfululizo wa saa. Muda wao wa chini ni sekunde moja. Na katika Graphite, kwa mfano, pia ni sekunde moja. Katika OpenTSDB pia ni sekunde moja. InfluxDB ina usahihi wa nanosecond. Katika VictoriaMetrics ni millisecond moja, kwa sababu katika Prometheus ni millisecond moja. Na VictoriaMetrics hapo awali ilitengenezwa kama hifadhi ya mbali kwa Prometheus. Lakini sasa inaweza kuhifadhi data kutoka kwa mifumo mingine.
Mtu niliyezungumza naye anasema wana usahihi wa pili hadi pili - hiyo inatosha kwao kwa sababu inategemea aina ya data ambayo inahifadhiwa kwenye hifadhidata ya safu ya saa. Ikiwa hii ni data ya DevOps au data kutoka kwa miundombinu, ambapo unaikusanya kwa muda wa sekunde 30, kwa dakika, basi usahihi wa pili unatosha, huhitaji chochote kidogo. Na ikiwa unakusanya data hii kutoka kwa mifumo ya biashara ya mzunguko wa juu, basi unahitaji usahihi wa nanosecond.
Usahihi wa milisekunde katika VictoriaMetrics pia inafaa kwa kesi ya DevOps, na inaweza kufaa kwa kesi nyingi ambazo nilitaja mwanzoni mwa ripoti. Kitu pekee ambacho hakifai ni mifumo ya biashara ya masafa ya juu.
Asante! Na swali jingine. Je, utangamano katika PromQL ni nini?
Utangamano kamili wa nyuma. VictoriaMetrics inasaidia kikamilifu PromQL. Kwa kuongeza, inaongeza utendaji wa ziada wa juu katika PromQL, ambayo inaitwa . Kuna mazungumzo kwenye YouTube kuhusu utendakazi huu uliopanuliwa. Nilizungumza kwenye Mkutano wa Ufuatiliaji katika majira ya kuchipua huko St.
Kituo cha Telegraph .
Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. tafadhali.
Ni nini kinakuzuia kubadili hadi VictoriaMetrics kama hifadhi yako ya muda mrefu ya Prometheus? (Andika kwenye maoni, nitaiongeza kwenye kura))
-
71,4%Situmii Prometheus5
-
28,6%Sikujua kuhusu VictoriaMetrics2
Watumiaji 7 walipiga kura. Watumiaji 12 walijizuia.
Chanzo: mapenzi.com