Мен сизге Александр Валялкиндин 2019-жылдын аягындагы "VictoriaMetricsтеги оптималдаштырууга өтүү" баяндамасынын стенограммасын окууну сунуштайм.
— убакыттын сериясы түрүндөгү маалыматтарды сактоо жана иштетүү үчүн тез жана масштабдуу МББ (жазуулар убакытты жана ушул убакытка туура келген маанилердин топтомун түзөт, мисалы, сенсорлордун абалын мезгил-мезгили менен сурамжылоо же чогултуу аркылуу алынган) метрикалар).
Бул отчеттун видеосуна шилтеме -
Өзүңүз жөнүндө айтып бериңиз. Мен Александр Валялкинмин. Мына . Мен Go жана аткарууну оптималдаштырууну жакшы көрөм. Мен көптөгөн пайдалуу жана анча пайдалуу эмес китепканаларды жаздым. Алар экөөнөн башталат fast, же менен quick префикс.
Мен азыр VictoriaMetrics боюнча иштеп жатам. Бул эмне жана мен ал жерде эмне кылып жатам? Мен бул презентацияда бул тууралуу сөз кылам.
Докладдын схемасы төмөнкүдөй:
- Биринчиден, мен сизге VictoriaMetrics деген эмне экенин айтып берем.
- Анда мен сизге убакыт сериясы эмне экенин айтып берем.
- Анда мен сизге убакыт сериясынын маалымат базасы кантип иштээрин айтып берем.
- Андан кийин, мен сизге маалымат базасынын архитектурасы жөнүндө айтып берем: ал эмнеден турат.
- Анан VictoriaMetrics ээ болгон оптималдаштырууга өтөлү. Бул инверттелген индексти оптималдаштыруу жана Go программасында битсетти ишке ашыруу үчүн оптималдаштыруу.
Аудиториядагы кимдир бирөө VictoriaMetrics деген эмне экенин билеби? Wow, көп адамдар мурунтан эле билишет. Бул жакшы кабар. Билбегендер үчүн бул убакыт серияларынын маалымат базасы. Бул ClickHouse архитектурасына, ClickHouse ишке ашыруунун кээ бир деталдарына негизделген. Мисалы, мисалы: MergeTree, бардык колдо болгон процессор өзөктөрү боюнча параллелдүү эсептөө жана процессордун кэшинде жайгаштырылган маалымат блокторунда иштөө менен өндүрүмдүүлүктү оптималдаштыруу.
VictoriaMetrics башка убакыт серияларынын маалымат базаларына караганда жакшыраак маалыматтарды кысуу менен камсыз кылат.
Ал вертикалдуу масштабда, башкача айтканда, бир компьютерге көбүрөөк процессорлорду, көбүрөөк оперативдүү эсту кошууга болот. VictoriaMetrics бул жеткиликтүү ресурстарды ийгиликтүү пайдаланып, сызыктуу өндүрүмдүүлүктү жакшыртат.
VictoriaMetrics да горизонталдуу масштабда - башкача айтканда, VictoriaMetrics кластерине кошумча түйүндөрдү кошо аласыз жана анын иштеши дээрлик сызыктуу түрдө жогорулайт.
Сиз ойлогондой, VictoriaMetrics тез маалымат базасы, анткени мен башкаларга жаза албайм. Ал Go-да жазылган, ошондуктан мен бул жолугушууда бул жөнүндө айтып жатам.
Убакыт сериясы эмне экенин ким билет? Ал дагы көп адамдарды билет. Убакыт сериясы - жуптардын сериясы (timestamp, значение), бул жуптар убакыт боюнча иргелет. Мааниси калкыма чекит саны - float64.
Ар бир убакыт сериясы уникалдуу ачкыч менен аныкталат. Бул ачкыч эмнеден турат? Ал ачкыч-маани жуптарынын бош эмес топтомунан турат.
Бул жерде убакыт сериясынын бир мисалы болуп саналат. Бул сериянын ачкычы жуптардын тизмеси: __name__="cpu_usage" метрика аты болуп саналат, instance="my-server" - бул метрика чогултулган компьютер, datacenter="us-east" - бул компьютер жайгашкан маалымат борбору.
Биз үч ачкыч-маанилик жуптан турган убакыт сериясынын аталышына ээ болдук. Бул ачкыч жуптардын тизмесине туура келет (timestamp, value). t1, t3, t3, ..., tN - бул убакыт белгилери, 10, 20, 12, ..., 15 - тиешелүү маанилер. Бул берилген сап үчүн белгилүү бир убакта cpu-колдонуу болуп саналат.
Убакыт серияларын кайда колдонсо болот? Кимде кандайдыр бир идея барбы?
- DevOps'те сиз CPU, RAM, тармак, rpps, каталардын санын ж.б. өлчөй аласыз.
- IoT - биз температураны, басымды, гео координаттарды жана башка нерсени өлчөй алабыз.
- Ошондой эле каржылоо - биз акциялардын жана валюталардын бардык түрлөрүнө бааларды көзөмөлдөй алабыз.
- Мындан тышкары, убакыт сериялары фабрикалардагы өндүрүш процесстерин көзөмөлдөөдө колдонулушу мүмкүн. Бизде роботтор үчүн шамал турбиналарын көзөмөлдөө үчүн VictoriaMetrics колдонгон колдонуучулар бар.
- Убакыт сериялары ар кандай түзүлүштөрдүн сенсорлорунан маалымат чогултуу үчүн да пайдалуу. Мисалы, мотор үчүн; шинанын басымын өлчөө үчүн; ылдамдыкты, аралыкты өлчөө үчүн; бензин керектөөсүн өлчөө үчүн ж.б.
- Убакыт катарлары учактарды көзөмөлдөө үчүн да колдонулушу мүмкүн. Ар бир учакта учактын ден соолугунун ар кандай параметрлери үчүн убакыт серияларын чогултуучу кара куту бар. Убакыт катарлары аэрокосмостук өнөр жайында да колдонулат.
- Саламаттыкты сактоо - бул кан басымы, пульс, ж.
Мен унутуп калган тиркемелер дагы болушу мүмкүн, бирок убакыт сериялары заманбап дүйнөдө активдүү колдонулуп жатканын түшүнөсүз деп үмүттөнөм. Ал эми аларды пайдалануунун келему жыл сайын есууде.
Эмне үчүн сизге убакыт сериясынын маалымат базасы керек? Эмне үчүн убакыт сериясын сактоо үчүн кадимки реляциялык маалымат базасын колдоно албайсыз?
Анткени убакыт сериялары адатта көп көлөмдөгү маалыматты камтыйт, аларды кадимки маалымат базаларында сактоо жана иштетүү кыйын. Ошентип, убакыт сериялары үчүн атайын маалымат базалары пайда болду. Бул базалар упайларды эффективдүү сактайт (timestamp, value) берилген ачкыч менен. Алар сакталган маалыматтарды ачкыч, бир ачкыч-маани жуптары же бир нече ачкыч-маани жуптары же regexp боюнча окуу үчүн API менен камсыз кылат. Мисалы, сиз Америкадагы маалымат борборунан бардык кызматтарыңыздын CPU жүгүн тапкыңыз келсе, анда бул псевдосуроону колдонушуңуз керек.
Көбүнчө убакыт серияларынын маалымат базалары адистештирилген суроо тилдерин камсыз кылат, анткени SQL убакыт сериясы анча ылайыктуу эмес. SQLди колдогон маалымат базалары бар болсо да, ал абдан ылайыктуу эмес. сыяктуу тилдерди суроо , , , . Кимдир бирөө бул тилдердин жок дегенде бирин уккан деп үмүттөнөм. Көптөр PromQL жөнүндө уккандыр. Бул Prometheus суроо тили болуп саналат.
VictoriaMetricsти мисал катары колдонуу менен заманбап убакыт сериялары базасынын архитектурасы ушундай көрүнөт.
Ал эки бөлүктөн турат. Бул инверттелген индекс үчүн сактагыч жана убакыт сериясынын маанилери үчүн сактагыч. Бул репозиторийлер бөлүнгөн.
Маалыматтар базасына жаңы жазуу келгенде, биз алгач берилген топтомдун убакыт сериясынын идентификаторун табуу үчүн инверттелген индекске киребиз. label=value берилген метрика үчүн. Биз бул идентификаторду таап, маанини маалымат дүкөнүндө сактайбыз.
Сурам TSDBден маалыматтарды алуу үчүн келгенде, биз адегенде тескери индекске барабыз. Баарын алалы timeseries_ids бул топтомго дал келген рекорддор label=value. Андан кийин биз индекстелген маалыматтар кампасында бардык керектүү маалыматтарды алабыз timeseries_ids.
Келгиле, убакыт серияларынын маалымат базасы келген тандоо суроосун кантип иштетет деген мисалды карап көрөлү.
- Биринчиден, ал баарын алат
timeseries_idsберилген жуптарды камтыган инверттелген индекстенlabel=value, же берилген туруктуу сөз айкашын канааттандырыңыз. - Андан кийин ал табылгандар үчүн берилген убакыт аралыгында маалымат сактагычтан бардык маалымат чекиттерин чыгарат
timeseries_ids. - Андан кийин, маалымат базасы колдонуучунун талабына ылайык, бул маалымат чекиттери боюнча кээ бир эсептөөлөрдү жүргүзөт. Ошондон кийин жооп кайтарат.
Бул презентацияда мен биринчи бөлүгү жөнүндө айтып берем. Бул издөө timeseries_ids инверттелген индекс боюнча. Экинчи бөлүгүн, үчүнчү бөлүгүн кийин көрө аласыз , же мен башка отчетторду даярдаганча күтө туруңуз :)
Келгиле, тескери көрсөткүчкө өтөбүз. Көптөр муну жөнөкөй деп ойлошу мүмкүн. Инверттелген индекс деген эмне жана ал кандайча иштейт ким билет? Эх, азыр мынчалык көп эмес. Келгиле, бул эмне экенин түшүнүүгө аракет кылалы.
Бул чындыгында жөнөкөй. Бул жөн гана мааниге ачкычты көрсөткөн сөздүк. ачкыч деген эмне? Бул жубайлар label=valueкайда label и value - бул сызыктар. Жана баалуулуктар жыйындысы болуп саналат timeseries_ids, ага берилген жуп кирет label=value.
Inverted индекс баарын тез табууга мүмкүндүк берет timeseries_ids, берген label=value.
Ошондой эле тез табууга мүмкүндүк берет timeseries_ids бир нече жуп үчүн убакыт сериясы label=value, же жубайлар үчүн label=regexp. Бул кантип болот? Көптүктү кесилишкен жерин табуу менен timeseries_ids ар бир жуп үчүн label=value.
Инверттелген индекстин ар кандай аткарылышын карап көрөлү. Эң жөнөкөй жөнөкөй ишке ашыруудан баштайлы. Ал ушундай көрүнөт.
милдети getMetricIDs саптардын тизмесин алат. Ар бир сап камтыйт label=value. Бул функция тизмени кайтарат metricIDs.
Бул кандай иштейт? Бул жерде биз деп аталган глобалдык өзгөрмө бар invertedIndex. Бул кадимки сөздүк (map), ал сапты ints кесүү үчүн картага түшүрөт. сап камтыйт label=value.
Функцияны ишке ашыруу: алуу metricIDs биринчи үчүн label=value, андан кийин биз башканын баарын өткөрүп жатабыз label=value, биз түшүнөбүз metricIDs алар үчүн. Жана функцияны чакырыңыз intersectInts, бул төмөндө талкууланат. Жана бул функция бул тизмелердин кесилишин кайтарат.
Көрүнүп тургандай, инверттелген индексти ишке ашыруу өтө татаал эмес. Бирок бул жөнөкөй ишке ашыруу. Анын кандай кемчиликтери бар? Наив ишке ашыруунун негизги кемчилиги - мындай инверттелген индекс RAMда сакталат. Колдонмону кайра баштагандан кийин биз бул индексти жоготобуз. Бул индексти дискке сактоо жок. Мындай тескери индекс маалымат базасы үчүн ылайыктуу болушу күмөн.
Экинчи кемчилик да эс тутумга байланыштуу. Инверттелген индекс RAMга туура келиши керек. Эгерде ал RAM өлчөмүнөн ашып кетсе, анда биз эс тутумдан ката кетиребиз. Ошондо программа иштебейт.
сыяктуу даяр чечимдерди колдонуу менен бул маселени чечсе болот же .
Кыскасы, үч операцияны тез жасоого мүмкүндүк берген маалымат базасы керек.
- Биринчи операция жазуу болуп саналат
ключ-значениебул маалымат базасына. Ал муну абдан тез, кайда жасайтключ-значениеыктыярдуу саптар болуп саналат. - Экинчи операция - бул берилген ачкычтын жардамы менен маанини тез издөө.
- Ал эми үчүнчү операция - бул префикс боюнча бардык баалуулуктарды тез издөө.
LevelDB жана RocksDB - бул маалымат базалары Google жана Facebook тарабынан иштелип чыккан. Биринчи LevelDB келди. Андан кийин Facebookтун балдары LevelDB алып, аны өркүндөтө башташты, алар RocksDB жасашты. Азыр дээрлик бардык ички маалымат базалары Facebook ичиндеги RocksDBде иштейт, анын ичинде RocksDB жана MySQLге которулган. Алар анын атын коюшту .
Инверттелген индекс LevelDB аркылуу ишке ашырылышы мүмкүн. Муну кандай жасаш керек? Биз ачкыч катары сактайбыз label=value. Ал эми маани жуп турган убакыт сериясынын идентификатору болуп саналат label=value.
Эгерде бизде берилген жуп менен көп убакыт сериялары бар болсо label=value, анда бул маалымат базасында бир эле ачкыч жана башка көптөгөн катарлар болот timeseries_ids. Баарынын тизмесин алуу үчүн timeseries_ids, бул менен башталат label=prefix, биз бул маалымат базасы оптималдаштырылган диапазонду сканерлейбиз. Башкача айтканда, биз менен башталган бардык саптарды тандайбыз label=prefix жана керектүүсүн алуу timeseries_ids.
Бул Go'до кандай көрүнүшкө болорун үлгү ишке ашыруу. Бизде тескери көрсөткүч бар. Бул LevelDB.
Функция жөнөкөй ишке ашыруудагыдай эле. Бул жөнөкөй ишке ашырууну дээрлик сапка кайталайт. бир гана пункт бургандын ордуна map тескери көрсөткүчкө киребиз. Биз биринчи үчүн бардык баалуулуктарды алабыз label=value. Андан кийин бардык калган жуптарды аралап чыгабыз label=value жана алар үчүн metricIDдердин тиешелүү топтомун алыңыз. Андан кийин кесилишин табабыз.
Баары жакшы окшойт, бирок бул чечимдин кемчиликтери бар. VictoriaMetrics башында LevelDB негизинде инверттелген индексти ишке ашырган. Бирок акыры андан баш тартууга туура келди.
Неге? Анткени LevelDB жөнөкөй ишке ашырууга караганда жайыраак. Наив ишке ашырууда, берилген ачкыч берилгенде, биз дароо бүт кесимди алып чыгабыз metricIDs. Бул абдан тез операция - бүт кесим колдонууга даяр.
LevelDBде функция чакырылган сайын GetValues менен башталган бардык саптардан өтүү керек label=value. Жана ар бир сап үчүн бааны алыңыз timeseries_ids. Мындайлардан timeseries_ids булардын бир бөлүгүн чогултуу timeseries_ids. Албетте, бул жөн гана ачкыч менен кадимки картага кирүүдөн алда канча жайыраак.
Экинчи кемчилиги - LevelDB C тилинде жазылган. Go'дон C функцияларын чакыруу өтө тез эмес. Бул жүздөгөн наносекунддарды талап кылат. Бул өтө тез эмес, анткени go режиминде жазылган, 1-5 наносекундду талап кылган кадимки функциялык чакырууга салыштырмалуу аткаруудагы айырма ондогон эсеге жетет. VictoriaMetrics үчүн бул коркунучтуу кемчилик болду :)
Ошентип, мен инверттелген индекстин өзүмдүн ишке ашыруусун жаздым. Анан аны чакырды .
Mergeset MergeTree маалымат структурасына негизделген. Бул маалымат структурасы ClickHouseдан алынган. Албетте, mergeset тез издөө үчүн оптималдаштырылышы керек timeseries_ids берилген ачкычка ылайык. Mergeset толугу менен Go тилинде жазылган. Сиз көрө аласыз . Mergesetтин ишке ашырылышы папкада . Ал жерде эмне болуп жатканын түшүнүүгө аракет кылсаңыз болот.
Mergeset API LevelDB жана RocksDBге абдан окшош. Башкача айтканда, ал жерде жаңы жазууларды тез сактоого жана берилген префикс боюнча жазууларды тез тандоого мүмкүндүк берет.
Бириктирүүнүн кемчиликтери жөнүндө кийинчерээк сүйлөшөбүз. Эми инверттелген индексти ишке ашырууда VictoriaMetrics өндүрүшүндө кандай көйгөйлөр пайда болгону жөнүндө сүйлөшөлү.
Алар эмне үчүн пайда болгон?
Биринчи себеп - бул жоготуулардын жогорку деңгээли. Орус тилине которгондо, бул убакыт катарларынын тез-тез өзгөрүшү. Бул убакыт сериясы аяктап, жаңы сериялар башталат же көптөгөн жаңы убакыт сериялары башталат. Жана бул көп кездешет.
Экинчи себеп - убакыттык катарлардын көптүгү. Башында, мониторинг популярдуу болуп жатканда, убакыт серияларынын саны аз болчу. Мисалы, ар бир компьютер үчүн CPU, эстутум, тармак жана диск жүгүн көзөмөлдөө керек. Бир компьютерге 4 убакыт сериясы. Сизде 100 компьютер жана 400 убакыт сериясы бар дейли. Бул аябай аз.
Убакыттын өтүшү менен адамдар көбүрөөк майдаланган маалыматты өлчөй аларын түшүнүштү. Мисалы, жүктү бүт процессордун эмес, ар бир процессордун өзөгү үчүн өзүнчө өлчөңүз. Эгер сизде 40 процессор өзөгү болсо, анда процессордун жүгүн өлчөө үчүн 40 эсе көп убакыт сериясы бар.
Бирок бул баары эмес. Ар бир процессордун өзөгү бир нече абалга ээ болушу мүмкүн, мисалы, бош турганда. Ошондой эле колдонуучу мейкиндигинде иштөө, ядро мейкиндигинде жана башка штаттарда иштөө. Жана ар бир мындай абалды өзүнчө убакыт сериясы катары да ченесе болот. Бул кошумча иретинде катарлардын санын 7—8 эсеге кебейтет.
Бир метрикадан биз бир эле компьютер үчүн 40 x 8 = 320 метрика алдык. 100гө көбөйтсө 32 эмес 000 чыгат.
Андан кийин Кубернетес келди. Жана андан да начарлады, анткени Kubernetes ар кандай кызматтарды кабыл ала алат. Kubernetes'теги ар бир кызмат көптөгөн поддондордон турат. Анан мунун баарын көзөмөлдөш керек. Мындан тышкары, биз сиздин кызматтарыңыздын жаңы версияларын тынымсыз жайылтып турабыз. Ар бир жаңы версия үчүн жаңы убакыт катар түзүлүшү керек. Натыйжада, убакыттык катарлардын саны экспоненциалдуу түрдө өсүүдө жана биз жогорку кардиналдуулук деп аталган көп сандагы убакыттык катар көйгөйүнө туш болобуз. VictoriaMetrics башка убакыт серияларынын маалымат базаларына салыштырмалуу аны ийгиликтүү чечет.
Келгиле, жогорку ылдамдыкты кененирээк карап көрөлү. Өндүрүштүн жогорку ылдамдыгы эмнеге алып келет? Анткени этикеткалардын жана белгилердин кээ бир маанилери тынымсыз өзгөрүп турат.
Мисалы, концепциясы бар Кубернетести алалы deployment, б.а. колдонмоңуздун жаңы версиясы чыкканда. Эмнегедир, Kubernetes иштеп чыгуучулары энбелгиге жайылтуу идентификаторун кошууну чечишти.
Бул эмнеге алып келди? Мындан тышкары, ар бир жаңы жайгаштыруу менен бардык эски убакыт сериялары үзгүлтүккө учурайт жана алардын ордуна жаңы убакыт сериялары жаңы энбелгиси менен башталат deployment_id. Мындай катарлар жүз миңдеген, ал тургай миллиондогон болушу мүмкүн.
Мунун баары жөнүндө маанилүү нерсе, убакыт серияларынын жалпы саны өсүп жатат, бирок учурда активдүү жана маалыматтарды кабыл алган убакыт серияларынын саны туруктуу бойдон калууда. Бул абал жогорку кыйроо ылдамдыгы деп аталат.
Жооптуулуктун жогорку ылдамдыгынын негизги көйгөйү – белгилүү бир убакыт аралыгындагы белгилердин берилген топтому үчүн бардык убакыт сериялары үчүн туруктуу издөө ылдамдыгын камсыз кылуу. Эреже катары, бул акыркы сааттын же акыркы күндүн убакыт аралыгы.
Бул маселени кантип чечүү керек? Бул жерде биринчи вариант. Бул тескери индексти убакыттын өтүшү менен көз карандысыз бөлүктөргө бөлүү болуп саналат. Башкача айтканда, бир аз убакыт аралыгы өтүп, биз учурдагы инверттелген индекс менен иштөөнү бүтүрөбүз. Жана жаңы инверттелген индексти түзүңүз. Дагы бир убакыт аралыгы өтөт, биз башкасын жана башкасын түзөбүз.
Жана бул инверттелген индекстерден тандап алууда биз берилген интервалга туура келген инверттелген индекстердин жыйындысын табабыз. Жана, ошого жараша, биз ошол жерден убакыт сериясынын идентификаторун тандайбыз.
Бул ресурстарды үнөмдөйт, анткени биз берилген интервалга туура келбеген бөлүктөрдү кароонун кажети жок. Башкача айтканда, адатта, биз акыркы саат үчүн маалыматтарды тандасак, анда мурунку убакыт аралыгы үчүн биз сурамдарды өткөрүп жиберебиз.
Бул маселени чечүү үчүн дагы бир вариант бар. Бул ар бир күн үчүн ошол күнү болгон убакыт серияларынын идентификаторлорунун өзүнчө тизмесин сактоо үчүн керек.
Бул чечимдин мурунку чечимге караганда артыкчылыгы, биз убакыттын өтүшү менен жоголбогон убакыт серияларынын маалыматын кайталабайбыз. Алар дайыма бар жана өзгөрбөйт.
Кемчилиги мындай чечимди ишке ашыруу кыйыныраак жана каталарды оңдоо кыйыныраак. Ал эми VictoriaMetrics бул чечимди тандап алган. Тарыхый жактан ушундай болгон. Бул чечим мурункуга салыштырмалуу жакшы иштейт. Анткени бул чечим өзгөрбөгөн, б.а. убакыттын өтүшү менен жоголбогон убакыт катарлары үчүн ар бир бөлүмдө маалыматтарды кайталоо зарыл болгондугуна байланыштуу ишке ашырылган эмес. VictoriaMetrics биринчи кезекте диск мейкиндигин керектөө үчүн оптималдаштырылган жана мурунку ишке ашыруу диск мейкиндигин керектөөнү начарлаткан. Бирок бул ишке ашыруу диск мейкиндигин керектөөнү азайтуу үчүн жакшыраак ылайыктуу, ошондуктан ал тандалды.
Мен аны менен күрөшүүгө туура келди. Күрөш бул ишке ашырууда дагы эле бир топ чоң санды тандоо керек болчу timeseries_ids маалыматтар үчүн инверттелген индекс убакытка бөлүнгөнгө караганда.
Бул маселени кантип чечтик? Биз аны оригиналдуу түрдө чечтик - бир идентификатордун ордуна ар бир инверттелген индекс жазуусунда бир нече убакыт сериясынын идентификаторлорун сактоо менен. Башкача айтканда, бизде ачкыч бар label=value, ар бир убакыт сериясында кездешет. Эми бир нечесин сактап калабыз timeseries_ids бир кириште.
Бул жерде бир мисал. Мурда бизде N жазуу бар болчу, бирок азыр бизде префикси бардык башкалар менен бирдей болгон бир жазуу бар. Мурунку жазуу үчүн маани бардык убакыт серияларынын идентификаторлорун камтыйт.
Бул мындай тескери көрсөткүчтүн сканерлөө ылдамдыгын 10 эсеге чейин жогорулатууга мүмкүндүк берди. Жана бул бизге кэш үчүн эстутум керектөөнү кыскартууга мүмкүндүк берди, анткени азыр биз сапты сактайбыз label=value кэште бир гана жолу бирге N жолу. Жана бул сызык чоң болушу мүмкүн, эгерде сиз узун сызыктарды тегиңизде жана этикеткаларыңызда сактасаңыз, Кубернетес ал жакка түрткөндү жакшы көрөт.
Инверттелген индексте издөөнү тездетүүнүн дагы бир варианты - бул sharding. Биринин ордуна бир нече тескери индекстерди түзүү жана алардын ортосунда маалыматтарды ачкыч менен бөлүшүү. Бул топтом key=value буу. Башкача айтканда, биз бир нече көз карандысыз инвертивдүү индекстерди алабыз, аларды бир нече процессорго параллелдүү түрдө сурай алабыз. Мурунку ишке ашыруулар бир процессорлуу режимде гана иштөөгө, б.а., маалыматтарды бир гана өзөктө сканерлөөгө мүмкүндүк берген. Бул чечим ClickHouse жасаганды жакшы көргөндөй, бир эле учурда бир нече өзөктөгү маалыматтарды сканерлөөгө мүмкүндүк берет. Бул биз ишке ашырууну пландаштырып жатабыз.
Эми биздин койлорубузга - кесилиш функциясына кайтып келели timeseries_ids. Келгиле, кандай ишке ашыруулар болушу мүмкүн экенин карап көрөлү. Бул функция табууга мүмкүндүк берет timeseries_ids берилген топтом үчүн label=value.
Биринчи вариант - жөнөкөй ишке ашыруу. Эки уяланган илмек. Бул жерде биз функциянын киришин алабыз intersectInts эки кесим - a и b. Чыгуу учурунда, ал бизге бул кесимдердин кесилишин кайтарып бериши керек.
Наив ишке ашыруу ушундай көрүнөт. Биз кесимдин бардык баалуулуктарын кайталайбыз a, бул циклдин ичинде биз кесимдин бардык баалуулуктарынан өтөбүз b. А биз аларды салыштырабыз. Алар дал келсе, анда биз кесилиш таптык. Жана сактаңыз result.
Кандай кемчиликтери бар? Квадраттык татаалдык - анын негизги кемчилиги. Мисалы, сиздин өлчөмдөрүңүз кесим болсо a и b бир эле учурда бир миллион, анда бул функция сизге эч качан жооп кайтарбайт. Анткени ага бир триллион кайталоо керек болот, бул заманбап компьютерлер үчүн да көп.
Экинчи ишке ашыруу картага негизделген. Биз карта түзөбүз. Биз бул картага кесимдин бардык баалуулуктарын койдук a. Андан кийин өзүнчө циклде кесимден өтөбүз b. Жана биз бул маани тилкеден экендигин текшеребиз b картада. Эгер ал бар болсо, анда аны натыйжага кошуңуз.
Кандай пайдасы бар? Артыкчылыгы бир гана сызыктуу татаалдык бар. Башкача айтканда, функция чоңураак тилкелер үчүн тезирээк аткарылат. Миллион өлчөмдөгү кесим үчүн бул функция мурунку функциянын триллион итерациясынан айырмаланып, 2 миллион итерацияда аткарылат.
Кемчилиги бул функция бул картаны түзүү үчүн көбүрөөк эстутумду талап кылат.
Экинчи кемчилик - хэширлөө үчүн чоң чыгым. Бул кемчилик абдан ачык эмес. Ал эми биз үчүн бул өтө ачык-айкын эмес болчу, андыктан алгач VictoriaMetricsте кесилишин ишке ашыруу карта аркылуу болгон. Бирок андан кийин профилдөө процессордун негизги убактысы картага жазуу жана бул картада маанинин бар-жоктугун текшерүүгө сарпталарын көрсөттү.
Эмне үчүн бул жерлерде CPU убактысы текке кетет? Анткени Go бул саптарда хэшинг операциясын аткарат. Башкача айтканда, ал HashMapдагы берилген индексте ага жетүү үчүн ачкычтын хэштерин эсептейт. Хешти эсептөө операциясы ондогон наносекундтарда аяктайт. VictoriaMetrics үчүн бул жай.
Мен бул иш үчүн атайын оптималдаштырылган битсетти ишке ашырууну чечтим. Эки тиликтин кесилиши мына ушундай көрүнөт. Бул жерде биз битсетти түзөбүз. Биз ага биринчи тилкеден элементтерди кошобуз. Андан кийин биз экинчи тилкеде бул элементтердин бар экендигин текшеребиз. Жана аларды натыйжага кошуңуз. Башкача айтканда, мурунку мисалдан дээрлик айырмаланбайт. Бул жерде бир гана нерсе, биз картага кирүү мүмкүнчүлүгүн ыңгайлаштырылган функциялар менен алмаштырдык add и has.
Бир караганда, бул жайыраак иштеши керек окшойт, эгерде мурда ал жерде стандарттуу карта колдонулса, андан кийин башка функциялар чакырылса, бирок профилдөө VictoriaMetrics учурда бул нерсе стандарттык картага караганда 10 эсе тезирээк иштейт.
Мындан тышкары, ал картаны ишке ашырууга салыштырмалуу бир топ аз эстутумду колдонот. Анткени биз бул жерде сегиз байт баалуулуктардын ордуна биттерди сактап жатабыз.
Бул ишке ашыруунун кемчилиги - бул анчалык ачык эмес, майда-барат эмес.
Көптөр байкабай турган дагы бир кемчилик - бул ишке ашыруу кээ бир учурларда жакшы иштебей калышы мүмкүн. Башкача айтканда, ал VictoriaMetrics убакыт сериясынын идентификаторлорунун кесилишинин бул учуру үчүн белгилүү бир учур үчүн оптималдаштырылган. Бул бардык учурларда ылайыктуу дегенди билдирбейт. Эгер ал туура эмес колдонулса, биз өндүрүмдүүлүктү жогорулатпай, эстутумда ката кетирип, аткаруунун басаңдашы мүмкүн.
Бул структуранын ишке ашырылышын карап көрөлү. Карагыңыз келсе, ал VictoriaMetrics булактарында, папкада жайгашкан . Бул VictoriaMetrics иши үчүн атайын оптималдаштырылган timeseries_id 64 биттик маани, мында биринчи 32 бит негизинен туруктуу жана акыркы 32 бит гана өзгөрөт.
Бул маалымат структурасы дискте сакталбайт, ал эстутумда гана иштейт.
Бул жерде анын API болуп саналат. Бул өтө татаал эмес. API VictoriaMetrics колдонуунун белгилүү бир мисалына ылайыкташтырылган. Башкача айтканда, бул жерде эч кандай керексиз функциялар жок. Бул жерде VictoriaMetrics тарабынан ачык колдонулган функциялар.
Функциялар бар add, бул жаңы баалуулуктарды кошот. Функциясы бар has, ал жаңы баалуулуктарды текшерет. Жана функция бар delбаалуулуктарды жок кылган. Жардамчы функциясы бар len, бул топтомдун өлчөмүн кайтарат. Функция clone көп клондошот. Жана функция appendto бул топтомду кесимге айлантат timeseries_ids.
Бул маалымат структурасын ишке ашыруу ушундай көрүнөт. топтом эки элементтен турат:
-
ItemsCountтоптомдогу элементтердин санын тез кайтаруу үчүн жардамчы талаа болуп саналат. Бул көмөкчү талаасыз эле жасоого болот, бирок аны бул жерге кошуу керек болчу, анткени VictoriaMetrics алгоритмдериндеги битсеттин узундугун көп сурайт. -
Экинчи талаа болуп саналат
buckets. Бул структурадан үзүндүbucket32. Ар бир структура сакталатhiталаа. Булар жогорку 32 бит. Жана эки кесим -b16hisиbucketsчейинbucket16структуралар.
16 биттик структуранын экинчи бөлүгүнүн жогорку 64 биттери бул жерде сакталат. Жана бул жерде битсеттер ар бир байттын төмөнкү 16 битине сакталат.
Bucket64 массивден турат uint64. Узундук ушул константалардын жардамы менен эсептелет. Биринде bucket16 максималдуу сакталышы мүмкүн 2^16=65536 бит. Эгер муну 8ге бөлсөңүз, анда 8 килобайт болот. Дагы 8ге бөлсөң 1000 болот uint64 мааниси. Ушул Bucket16 – бул биздин 8 килобайт структурабыз.
Келгиле, жаңы наркты кошуу үчүн бул структуранын ыкмаларынын бири кантип ишке ашырылганын карап көрөлү.
Мунун баары менен башталат uint64 маанилери. Жогорку 32 битти эсептейбиз, төмөнкү 32 битти эсептейбиз. Баарын башыбыздан өткөрөлү buckets. Ар бир чакадагы жогорку 32 битти кошулуп жаткан маани менен салыштырабыз. Эгерде алар дал келсе, анда функцияны чакырабыз add структурасында b32 buckets. Ал жерде төмөнкү 32 битти кошуңуз. Анан кайтып келсе true, анда бул биз ал жерде мындай наркты коштук жана бизде андай баалуулук болгон эмес дегенди билдирет. Ал кайтып келсе false, анда мындай маани мурунтан эле бар болчу. Андан кийин структурадагы элементтердин санын көбөйтөбүз.
Эгер биз сизге керектүүсүн таба албасак bucket талап кылынган жогорку маани менен, анда биз функцияны чакырабыз addAlloc, ал жаңысын чыгарат bucket, аны чака структурасына кошуу.
Бул функцияны ишке ашыруу b32.add. Бул мурунку ишке окшош. Биз эң маанилүү 16 битти, эң азы 16 битти эсептейбиз.
Андан кийин биз бардык жогорку 16 бит аркылуу өтөбүз. Биз дал келүүчүлөрдү табабыз. Эгерде дал келүү болсо, биз кийинки бетте карай турган кошуу ыкмасын чакырабыз bucket16.
Жана бул жерде мүмкүн болушунча оптималдаштырылган эң төмөнкү деңгээл. үчүн эсептеп чыгабыз uint64 id мааниси кесим битинде жана ошондой эле bitmask. Бул берилген 64 биттик маани үчүн маска, аны ушул биттин бар-жоктугун текшерүү же аны коюу үчүн колдонсо болот. Бул бит орнотулганын текшерип, аны орнотуп, бар экендигин кайтарабыз. Бул биздин ишке ашыруубуз, ал бизге кадимки карталарга салыштырмалуу убакыттык катарлардын кесилишкен идентификаторлорунун иштешин 10 эсе тездетүүгө мүмкүндүк берди.
Бул оптималдаштыруудан тышкары, VictoriaMetrics башка көптөгөн оптималдаштырууга ээ. Бул оптималдаштыруулардын көбү кандайдыр бир себептерден улам кошулган, бирок өндүрүштө кодду профилдештиргенден кийин.
Бул оптималдаштыруунун негизги эрежеси - бул жерде тоскоолдук болот деп оптималдаштырууну кошпоңуз, анткени ал жерде эч кандай тоскоолдук болбойт. Оптималдаштыруу адатта коддун сапатын начарлатат. Ошондуктан, бул реалдуу маалымат болушу үчүн, профилдештирүү жана өндүрүштө гана оптималдаштыруу керек. Эгер кимдир бирөө кызыкдар болсо, VictoriaMetrics булак кодун карап, ал жердеги башка оптималдаштырууларды изилдей аласыз.
Менин битсет жөнүндө суроом бар. C++ вектордук bool ишке ашырууга абдан окшош, оптималдаштырылган битсет. Ишке ашырууну ошол жерден алдыңызбы?
Жок, ал жактан эмес. Бул битсетти ишке ашырууда, мен VictoriaMetricsте колдонулган бул идентификаторлордун убакыт серияларынын структурасын билүү менен жетекчиликке алдым. Жана алардын түзүлүшү жогорку 32 бит негизинен туруктуу болуп саналат. Төмөнкү 32 бит өзгөрүшү мүмкүн. Бит канчалык төмөн болсо, ошончолук тез-тез өзгөрүшү мүмкүн. Ошондуктан, бул ишке ашыруу атайын бул маалымат структурасы үчүн оптималдаштырылган. C++ ишке ашыруу, мен билгенден, жалпы иш үчүн оптималдаштырылган. Эгер сиз жалпы иш үчүн оптималдаштырсаңыз, бул конкреттүү иш үчүн эң оптималдуу болбойт дегенди билдирет.
Мен дагы Алексей Миловиддин репортажын көрүүнү сунуштайм. Болжол менен бир ай мурун, ал белгилүү адистиктер үчүн ClickHouse-да оптималдаштыруу жөнүндө айткан. Ал жөн гана жалпы учурда, C ++ ишке ашыруу же башка ишке ашыруу ооруканада орточо жакшы иштеши үчүн ылайыкташтырылган дейт. Ал биздикине окшош билимге багытталган ишке ашырууга караганда начарраак иштеши мүмкүн, анда биз эң жогорку 32 бит негизинен туруктуу экенин билебиз.
Экинчи суроом бар. InfluxDBден негизги айырмасы эмнеде?
Көптөгөн негизги айырмачылыктар бар. Өндүрүмдүүлүк жана эстутум керектөө жагынан, InfluxDB тесттердеги жогорку кардиналдуулук убакыт сериялары үчүн эстутум керектөөсүн 10 эсе көп көрсөтөт, алар сизде көп болгондо, мисалы, миллиондогон. Мисалы, VictoriaMetrics миллион жигердүү катарга 1 ГБ, InfluxDB 10 ГБ сарптайт. Жана бул чоң айырма.
Экинчи негизги айырма InfluxDB кызыктай суроо тилдери бар - Flux жана InfluxQL. Аларга салыштырмалуу убакыт катарлары менен иштөө үчүн өтө ыңгайлуу эмес , аны VictoriaMetrics колдойт. PromQL - Prometheus'тун суроо тили.
Жана дагы бир айырмачылык InfluxDB бир аз кызыктай маалымат моделине ээ, мында ар бир сап ар кандай тегдер менен бир нече талааларды сактай алат. Бул саптар дагы ар кандай таблицаларга бөлүнөт. Бул кошумча татаалдыктар бул маалымат базасы менен кийинки ишти кыйындатат. Аны колдоо жана түшүнүү кыйын.
VictoriaMetricsте баары бир топ жөнөкөй. Ал жерде ар бир убакыт сериясы ачкыч-маани болуп саналат. Маани пункттардын жыйындысы болуп саналат - (timestamp, value), жана ачкыч топтом болуп саналат label=value. Талаалар менен өлчөөлөрдүн ортосунда эч кандай бөлүнүү жок. Бул ар кандай маалыматтарды тандап, андан кийин InfluxDBден айырмаланып, ар кандай саптардын ортосундагы эсептөөлөр мен билгендей ишке ашырыла элек, бириктирүү, кошуу, кемитүү, көбөйтүү, бөлүү мүмкүнчүлүгүн берет. Алар ишке ашырылса дагы, бул кыйын, көп код жазуу керек.
Менин тактоочу суроом бар. Мен туура түшүндүмбү, сиз айткан кандайдыр бир көйгөй бар экенин, бул инвертивдүү индекс эстутумга туура келбейт, демек, ал жерде бөлүү бар?
Биринчиден, мен стандарттуу Go картасында инверттелген индекстин жөнөкөй ишке ашырылышын көрсөттү. Бул ишке ашыруу маалымат базалары үчүн ылайыктуу эмес, анткени бул инверттелген индекс дискке сакталбайт жана маалымат базасы дискке сакталышы керек, бул маалыматтар кайра иштетилгенде жеткиликтүү бойдон кала берет. Бул ишке ашырууда, сиз тиркемени кайра баштаганда, сиздин тескери индексиңиз жок болот. Жана сиз бардык маалыматтарга кирүү мүмкүнчүлүгүн жоготосуз, анткени сиз аны таба албай каласыз.
Салам! Баяндама үчүн рахмат! Менин атым Павел. Мен Wildberriesден болом. Мен сен үчүн бир нече суроо бар. Биринчи суроо. Сиздин оюңузча, эгер сиз тиркемеңиздин архитектурасын курууда башка принципти тандап, убакыттын өтүшү менен берилиштерди бөлгөн болсоңуз, анда, балким, издөөдө бир бөлүмдө бир бөлүмдүн маалыматтары камтылгандыгына таянып, маалыматтарды кесип алат белеңиз? убакыт аралыгы, башкача айтканда, бир убакыт аралыгында жана сиздин даанаңыз башкача чачырап кеткенинен кабатыр болбойсузбу? №2 суроо - сиз битсет жана башка бардык нерселер менен окшош алгоритмди ишке ашырып жаткандыктан, балким, процессордун көрсөтмөлөрүн колдонууга аракет кылгандырсыз? Балким, сиз ушундай оптималдаштырууга аракет кылгандырсыз?
Экинчисине дароо жооп берем. Биз ал деңгээлге жете элекпиз. Бирок керек болсо ошол жакка жетебиз. Анан биринчиси, кандай суроо болду?
Сиз эки сценарийди талкууладыңыз. Анан дагы татаалыраак ишке ашыруу менен экинчисин тандашканын айтышты. Жана алар биринчисин жактырышкан жок, мында маалыматтар убакыт боюнча бөлүнгөн.
Ооба. Биринчи учурда, индекстин жалпы көлөмү чоңураак болмок, анткени ар бир бөлүмдө биз бул бөлүмдөрдүн бардыгы аркылуу уланган ошол убакыт сериялары үчүн кайталанган маалыматтарды сактоого туура келет. Ал эми сиздин убакыт катарыңыздын бузулуу ылдамдыгы аз болсо, башкача айтканда, ошол эле сериялар тынымсыз колдонулса, анда биринчи учурда биз экинчи учурга салыштырмалуу дисктин ээлеген мейкиндигинен алда канча көп жоготобуз.
Ошентип - ооба, убакытты бөлүштүрүү жакшы вариант. Прометей аны колдонот. Бирок Прометейдин дагы бир кемчилиги бар. Берилиштердин бул бөлүктөрүн бириктиргенде, ал эстутумда бардык энбелгилер жана убакыт сериялары үчүн мета маалымат сакталышы керек. Ошондуктан, эгерде ал бириктирилген маалыматтар чоң болсо, VictoriaMetricsтен айырмаланып, биригүү учурунда эстутум керектөө абдан көбөйөт. Бириктирүү учурунда VictoriaMetrics эстутумду такыр колдонбойт; бириктирилген маалымат бөлүктөрүнүн көлөмүнө карабастан, бир нече килобайт гана сарпталат.
Сиз колдонуп жаткан алгоритм эстутумду колдонот. Ал баалуулуктарды камтыган убакыт серияларынын тегдерин белгилейт. Жана ушундай жол менен сиз бир маалымат массивинде жана башкасында жупташкан болушун текшересиз. Ал эми кесилишкен же болбогонун түшүнөсүз. Адатта, маалымат базалары курсорлорду жана итераторлорду ишке ашырат, алар учурдагы мазмунун сакташат жана бул операциялардын жөнөкөй татаалдыгынан улам сорттолгон маалыматтар аркылуу иштейт.
Эмне үчүн биз маалыматтарды өтүү үчүн курсорлорду колдонбойбуз?
Ооба.
Биз сорттолгон саптарды LevelDB же бириктирилгенде сактайбыз. Курсорду жылдырып, кесилишин таба алабыз. Эмне үчүн биз аны колдонбойбуз? Анткени ал жай. Анткени курсорлор ар бир сап үчүн функцияны чакыруу керек дегенди билдирет. Функцияны чакыруу 5 наносекундду түзөт. Эгер сизде 100 000 000 сап болсо, анда биз функцияны чакырууга жарым секунд сарптайбыз.
Мындай нерсе бар, ооба. Жана менин акыркы суроом. Суроо бир аз кызыктай угулушу мүмкүн. Эмне үчүн маалыматтар келип түшкөн учурда бардык керектүү агрегаттарды окуп, керектүү формада сактоого мүмкүн эмес? Эмне үчүн VictoriaMetrics, ClickHouse ж.б. сыяктуу кээ бир системаларда чоң көлөмдөрдү сактап, анан аларга көп убакыт коротуш керек?
Түшүнүктүү болушу үчүн мен бир мисал келтирейин. кичинекей оюнчук спидометр кантип иштейт дейли? Бул сиз басып өткөн аралыкты жазып, ар дайым бир мааниге кошуп, экинчиси - жолу. Жана бөлөт. Жана орточо ылдамдыкты алат. Сиз ошол эле нерсени кыла аласыз. Керектүү фактылардын бардыгын тез арада кошуңуз.
Макул, мен суроону түшүнөм. Сиздин мисал өз орду бар. Эгер сизге кандай агрегаттар керек экенин билсеңиз, анда бул эң жакшы ишке ашыруу. Бирок көйгөй адамдар бул көрсөткүчтөрдү, кээ бир маалыматтарды ClickHouse'та сакташат жана алар келечекте аларды кантип бириктирип, чыпкалай турганын билишпейт, андыктан бардык чийки маалыматтарды сактоого туура келет. Бирок, эгер сиз бир нерсени орточо эсеп менен эсептөө керек экенин билсеңиз, анда чийки баалуулуктарды сактоонун ордуна эмне үчүн аны эсептеп көрбөйсүз? Бирок бул сизге эмне керек экенин так билсеңиз гана болот.
Айтмакчы, убакыт серияларын сактоо үчүн маалымат базалары агрегаттарды эсептөөнү колдойт. Мисалы, Prometheus колдойт . Башкача айтканда, бул сизге кандай бирдиктер керек экенин билсеңиз болот. VictoriaMetricsте бул азырынча жок, бирок, адатта, муну кайра коддоо эрежелеринде жасоого мүмкүн болгон Prometheus алдында турат.
Мисалы, мурунку жумушумда мен акыркы сааттын ичинде жылма терезедеги окуялардын санын санашым керек болчу. Маселе, мен Go'до ыңгайлаштырылган ишке ашырууну, башкача айтканда, бул нерсени эсептөө үчүн кызматты жасашым керек болчу. Бул кызмат акыр аягында маанисиз болгон эмес, анткени аны эсептөө кыйын. Эгер белгилүү бир убакыт аралыгы менен айрым агрегаттарды санашыңыз керек болсо, ишке ашыруу жөнөкөй болушу мүмкүн. Эгер сиз жылма терезеде окуяларды санагыңыз келсе, анда бул көрүнгөндөй жөнөкөй эмес. Менин оюмча, бул ClickHouse же тайм серияларынын маалымат базаларында азырынча ишке ашырыла элек, анткени аны ишке ашыруу кыйын.
Жана дагы бир суроо. Биз жөн гана орточо эсеп жөнүндө сүйлөшүп жатканбыз жана мен бир жолу Carbon backend менен Графит сыяктуу нерсе болгонун эстедим. Жана ал эски маалыматтарды кантип жукартууну билген, башкача айтканда, мүнөтүнө бир упай, саатына бир упай ж.б. калтыруу. Негизи, бул бир айга чийки маалыматтар керек болсо, анда бул абдан ыңгайлуу, ал эми калганынын баары болот. арыктоо. Бирок Prometheus жана VictoriaMetrics бул функцияны колдобойт. Аны колдоо пландалып жатабы? Эгерде жок болсо, анда эмне үчүн?
Сурооңуз үчүн рахмат. Биздин колдонуучулар мезгил-мезгили менен бул суроону беришет. Төмөндөө үчүн колдоону качан кошобуз деп сурашат. Бул жерде бир нече көйгөйлөр бар. Биринчиден, ар бир колдонуучу түшүнөт downsampling башка нерсе: кимдир бирөө берилген интервалда каалаган каалаган чекит алууну каалайт, кимдир бирөө максималдуу, минималдуу, орточо маанилерди каалайт. Эгерде көптөгөн системалар маалымат базасына маалыматтарды жазса, анда сиз алардын баарын бириктире албайсыз. Ар бир система ар кандай суюлтууну талап кылышы мүмкүн. Жана муну ишке ашыруу кыйын.
Экинчиси, VictoriaMetrics, ClickHouse сыяктуу, ири көлөмдөгү чийки маалыматтар менен иштөө үчүн оптималдаштырылган, андыктан тутумуңузда көптөгөн өзөктөр болсо, ал бир секундага жетпеген убакытта миллиард сызыктарды сүзө алат. VictoriaMetrics-те скандоочу убакыт сериясы пункттары – өзөк үчүн секундасына 50 000 000 упай. Ал эми бул аткаруу учурдагы өзөктөрдү масштабдуу. Башкача айтканда, сизде 20 ядро бар болсо, мисалы, секундасына миллиард пунктту сканерлейсиз. Ал эми VictoriaMetrics жана ClickHouse бул касиети төмөндөтүү зарылчылыгын азайтат.
Дагы бир өзгөчөлүгү VictoriaMetrics бул маалыматтарды натыйжалуу кысып турат. Өндүрүштө орточо кысуу бир пунктка 0,4төн 0,8 байтка чейин. Ар бир чекит убакыт белгиси + маани. Жана ал орто эсеп менен бир байттан азыраак кысылган.
Сергей. Менде суроо бар. Минималдуу жазуу убактысы канча?
Бир миллисекунд. Биз жакында башка убакыт сериялары базасын иштеп чыгуучулар менен сүйлөштүк. Алардын минималдуу убакыт тилкеси бир секунд. Ал эми Graphite, мисалы, бул дагы бир секунд. OpenTSDBде бул дагы бир секунд. InfluxDB наносекунддук тактыкка ээ. VictoriaMetricsте бул бир миллисекунд, анткени Прометейде бул бир миллисекунд. Ал эми VictoriaMetrics алгач Prometheus үчүн алыскы сактагыч катары иштелип чыккан. Бирок азыр ал башка системалардан маалыматтарды сактай алат.
Мен сүйлөшкөн адам алардын экинчи секунданын тактыгына ээ экенин айтты - бул алар үчүн жетиштүү, анткени бул убакыт сериясынын маалымат базасында сакталып жаткан маалыматтардын түрүнөн көз каранды. Эгерде бул DevOps маалыматтары же инфраструктурадан алынган маалыматтар болсо, анда сиз аны мүнөтүнө 30 секунд аралыкта чогултсаңыз, анда экинчи тактык жетиштүү, сизге андан азыраак эч нерсе керек эмес. Эгер сиз бул маалыматтарды жогорку жыштыктагы соода системаларынан чогултсаңыз, анда наносекунддук тактык керек.
VictoriaMetricsдеги миллисекунддук тактык DevOps иши үчүн да ылайыктуу жана мен отчеттун башында айткан учурлардын көбү үчүн ылайыктуу болушу мүмкүн. Бул ылайыктуу эмес болушу мүмкүн болгон бир гана нерсе - жогорку жыштык соода системалары.
Рахмат! Жана дагы бир суроо. PromQLде шайкештик деген эмне?
Толук артка шайкештик. VictoriaMetrics PromQLди толугу менен колдойт. Мындан тышкары, ал PromQL деп аталган кошумча өркүндөтүлгөн функцияларды кошот . Бул кеңейтилген функция жөнүндө YouTube'да сөз бар. Мен жазында Санкт-Петербургда өткөн Мониторинг жолугушуусунда сөз сүйлөдүм.
Telegram channel .
Сурамжылоого катталган колдонуучулар гана катыша алышат. , өтүнөмүн.
Prometheus үчүн узак мөөнөттүү сактагыч катары VictoriaMetricsке өтүүгө сизге эмне тоскоолдук кылып жатат? (Комментарийге жазыңыз, мен аны сурамжылоого кошом))
-
71,4%Мен Prometheus5 колдонбойм
-
28,6%VictoriaMetrics2 жөнүндө билчү эмесмин
7 колдонуучу добуш берди. 12 колдонуучу добуш берүүдөн баш тартты.
Source: www.habr.com