Мен сізге Александр Валялкиннің 2019 жылдың аяғында жасалған «VictoriaMetrics-те оңтайландыруларға өту» баяндамасының транскрипциясын оқуды ұсынамын.
— уақыттық қатар түріндегі деректерді сақтауға және өңдеуге арналған жылдам және масштабталатын ДҚБЖ (жазба уақытты және осы уақытқа сәйкес келетін мәндер жинағын құрайды, мысалы, датчиктердің күйін мерзімді сұрау немесе жинау арқылы алынған. көрсеткіштер).
Міне, осы есептің видеосына сілтеме -
Өзіңіз туралы айтып беріңізші. Мен Александр Валялкинмін. Мұнда . Мен Go және өнімділікті оңтайландыруға құмармын. Мен көптеген пайдалы және онша пайдалы емес кітапханаларды жаздым. Олар екеуінен басталады fast, немесе бірге quick префикс.
Мен қазір VictoriaMetrics-те жұмыс істеймін. Бұл не және мен онда не істеп жатырмын? Мен бұл туралы осы презентацияда айтатын боламын.
Есептің сұлбасы келесідей:
- Алдымен мен сізге VictoriaMetrics деген не екенін айтайын.
- Содан кейін мен сізге уақыт қатарларының не екенін айтамын.
- Содан кейін мен сізге уақыт сериясының деректер қоры қалай жұмыс істейтінін айтып беремін.
- Әрі қарай, мен сізге дерекқор архитектурасы туралы айтып беремін: ол неден тұрады.
- Содан кейін VictoriaMetrics бар оңтайландыруларға көшейік. Бұл инверттелген индекс үшін оңтайландыру және Go бағдарламасында бит жиынын енгізу үшін оңтайландыру.
Аудиториядағы біреу VictoriaMetrics не екенін біледі ме? Уау, көп адам біледі. Бұл жақсы жаңалық. Білмейтіндер үшін бұл уақыт серияларының деректер базасы. Ол 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 жүйесінде процессорды, жедел жадты, желіні, rps-ді, қателер санын және т.б. өлшеуге болады.
- 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.
Инверттелген индекс бәрін жылдам табуға мүмкіндік береді timeseries_ids, берген label=value.
Ол сонымен қатар жылдам табуға мүмкіндік береді timeseries_ids бірнеше жұпқа арналған уақыт қатары label=value, немесе жұптар үшін label=regexp. Бұл қалай болады? Жиынның қиылысуын табу арқылы timeseries_ids әр жұп үшін label=value.
Төңкерілген индекстің әртүрлі іске асырылуын қарастырайық. Ең қарапайым аңғал іске асырудан бастайық. Ол осылай көрінеді.
функция getMetricIDs жолдардың тізімін алады. Әрбір жол бар label=value. Бұл функция тізімді қайтарады metricIDs.
Бұл қалай жұмыс істейді? Мұнда бізде жаһандық айнымалы бар invertedIndex. Бұл кәдімгі сөздік (map), ол жолды инттерді кесу үшін салыстырады. Жолда бар label=value.
Функцияны жүзеге асыру: алу metricIDs бірінші үшін label=value, содан кейін біз қалғандарының бәрін өткіземіз label=value, түсінеміз metricIDs олар үшін. Және функцияны шақырыңыз intersectInts, ол төменде талқыланады. Және бұл функция осы тізімдердің қиылысын қайтарады.
Көріп отырғаныңыздай, инверттелген индексті енгізу өте күрделі емес. Бірақ бұл аңғал іске асыру. Оның қандай кемшіліктері бар? Аңғал іске асырудың негізгі кемшілігі - мұндай инверттелген индекс жедел жадта сақталады. Қолданбаны қайта іске қосқаннан кейін біз бұл индексті жоғалтамыз. Бұл индексті дискіге сақтау мүмкін емес. Мұндай инверттелген индекстің дерекқор үшін қолайлы болуы екіталай.
Екінші кемшілік жадыға да қатысты. Төңкерілген индекс жедел жадқа сәйкес келуі керек. Егер ол ЖЖҚ көлемінен асып кетсе, онда біз жадтан шығу қатесін аламыз. Ал бағдарлама жұмыс істемейді.
сияқты дайын шешімдердің көмегімен бұл мәселені шешуге болады , немесе .
Қысқасы, бізге үш операцияны жылдам орындауға мүмкіндік беретін мәліметтер базасы қажет.
- Бірінші операция – жазу
ключ-значениеосы дерекқорға. Ол мұны өте тез, қайда жасайдыключ-значениеерікті жолдар болып табылады. - Екінші операция – берілген кілт арқылы мәнді жылдам іздеу.
- Үшінші операция - берілген префикс бойынша барлық мәндерді жылдам іздеу.
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 және олар үшін метрикалық идентификаторлардың сәйкес жиынын алыңыз. Содан кейін біз қиылысты табамыз.
Барлығы жақсы сияқты, бірақ бұл шешімнің кемшіліктері бар. VictoriaMetrics бастапқыда LevelDB негізіндегі инверттелген индексті енгізді. Бірақ соңында мен одан бас тартуға тура келді.
Неліктен? Өйткені LevelDB аңғал енгізуге қарағанда баяу. Аңғал іске асыруда, берілген кілт берілгенде, біз барлық бөлікті дереу шығарып аламыз metricIDs. Бұл өте жылдам операция - бүкіл тілім пайдалануға дайын.
LevelDB-де функция шақырылған сайын GetValues деп басталатын барлық жолдардан өту керек label=value. Әр жолдың мәнін алыңыз timeseries_ids. Осындайлардан timeseries_ids осылардың бір бөлігін жинаңыз timeseries_ids. Бұл қарапайым картаға кілт арқылы қол жеткізуден әлдеқайда баяу екені анық.
Екінші кемшілігі - LevelDB C тілінде жазылған. Go қолданбасынан C функцияларын шақыру өте жылдам емес. Ол жүздеген наносекундтарды алады. Бұл өте жылдам емес, өйткені 1-5 наносекундты алатын go режимінде жазылған кәдімгі функционалды шақырумен салыстырғанда өнімділік айырмашылығы ондаған есеге жетеді. VictoriaMetrics үшін бұл өлімге әкелетін кемшілік болды :)
Сондықтан мен инверттелген индексті өзімнің орындауымды жаздым. Және ол оны шақырды .
Mergeset MergeTree деректер құрылымына негізделген. Бұл деректер құрылымы ClickHouse сайтынан алынған. Біріктіру жиынын жылдам іздеу үшін оңтайландыру керек екені анық timeseries_ids берілген кілтке сәйкес. Mergeset толығымен Go тілінде жазылған. Сен көре аласын . Біріктіру жиынтығының орындалуы қалтада . Онда не болып жатқанын анықтауға тырысуға болады.
Біріктіру API интерфейсі LevelDB және RocksDB-ге өте ұқсас. Яғни, ол жерде жаңа жазбаларды жылдам сақтауға және берілген префикс бойынша жазбаларды жылдам таңдауға мүмкіндік береді.
Біріктірудің кемшіліктері туралы кейінірек айтатын боламыз. Енді инверттелген индексті енгізу кезінде VictoriaMetrics өндірісінде қандай мәселелер туындағаны туралы сөйлесейік.
Олар неліктен пайда болды?
Бірінші себеп - шығынның жоғары деңгейі. Орыс тіліне аударғанда бұл уақыт қатарларының жиі өзгеруі. Бұл уақыт қатары аяқталып, жаңа сериялар басталған кезде немесе көптеген жаңа уақыт қатарлары басталады. Және бұл жиі болады.
Екінші себеп – уақыттық қатарлардың көптігі. Басында мониторинг танымал бола бастаған кезде уақыттық қатарлардың саны аз болды. Мысалы, әрбір компьютер үшін процессорды, жадты, желіні және дискінің жүктемесін бақылау керек. Бір компьютерге 4 уақыт қатары. Сізде 100 компьютер және 400 уақыт сериясы бар делік. Бұл өте аз.
Уақыт өте келе адамдар түйіршікті ақпаратты өлшей алатынын түсінді. Мысалы, жүктемені бүкіл процессордың емес, әрбір процессор өзегі үшін бөлек өлшеңіз. Егер сізде 40 процессор өзегі болса, процессор жүктемесін өлшеу үшін 40 есе көп уақыт қатары бар.
Бірақ бұл бәрі емес. Әрбір процессор өзегі жұмыс істемей тұрғанда, жұмыссыз сияқты бірнеше күйге ие болуы мүмкін. Сондай-ақ пайдаланушы кеңістігінде жұмыс істеу, ядро кеңістігінде және басқа күйлерде жұмыс істеу. Және әрбір мұндай күйді жеке уақыт қатары ретінде де өлшеуге болады. Бұл қосымша жолдар санын 7-8 есе арттырады.
Бір метрикадан біз тек бір компьютер үшін 40 x 8 = 320 метрика алдық. 100-ге көбейтсек, 32-дің орнына 000 шығады.
Содан кейін Кубернетес келді. Және бұл нашарлады, өйткені Kubernetes көптеген әртүрлі қызметтерді қабылдай алады. Кубернетестегі әрбір қызмет көптеген қосқыштардан тұрады. Және мұның барлығын қадағалау керек. Сонымен қатар, бізде сіздің қызметтеріңіздің жаңа нұсқаларын тұрақты орналастыру бар. Әрбір жаңа нұсқа үшін жаңа уақыт қатары жасалуы керек. Нәтижесінде уақыттық қатарлардың саны экспоненциалды түрде өседі және біз жоғары кардиналдық деп аталатын көп уақыттық қатар мәселесімен бетпе-бет келеміз. VictoriaMetrics онымен басқа уақыт сериялары дерекқорларымен салыстырғанда сәтті күреседі.
Жоғары шығын жылдамдығын толығырақ қарастырайық. Өндірістегі жоғары тоқырауға не себеп болады? Өйткені белгілер мен тегтердің кейбір мағыналары үнемі өзгеріп отырады.
Мысалы, тұжырымдамасы бар Кубернетесті алайық deployment, яғни қолданбаңыздың жаңа нұсқасы шығарылған кезде. Қандай да бір себептермен Kubernetes әзірлеушілері белгіге орналастыру идентификаторын қосуды шешті.
Бұл не әкелді? Сонымен қатар, әрбір жаңа орналастыру кезінде барлық ескі уақыт қатарлары үзіледі және олардың орнына жаңа уақыт қатарлары жаңа белгі мәнімен басталады. deployment_id. Мұндай жолдар жүздеген мың, тіпті миллиондаған болуы мүмкін.
Мұның бәрі туралы маңызды нәрсе - уақыттық қатарлардың жалпы саны өседі, бірақ қазіргі уақытта белсенді және деректерді қабылдайтын уақыттық қатарлар саны тұрақты болып қалады. Бұл күй жоғары шығын жылдамдығы деп аталады.
Жоғары босату жылдамдығының негізгі мәселесі белгілі бір уақыт аралығындағы белгілердің берілген жиынтығы үшін барлық уақыттық қатарлар үшін тұрақты іздеу жылдамдығын қамтамасыз ету болып табылады. Әдетте бұл соңғы сағаттың немесе соңғы күннің уақыт аралығы.
Бұл мәселені қалай шешуге болады? Міне, бірінші нұсқа. Бұл инверттелген индексті уақыт бойынша тәуелсіз бөліктерге бөлу. Яғни, біраз уақыт аралығы өтеді, біз ағымдағы инверттелген индекспен жұмысты аяқтаймыз. Және жаңа инверттелген индексті жасаңыз. Басқа уақыт аралығы өтеді, біз басқасын және басқасын жасаймыз.
Ал осы инверттелген индекстерден іріктеу кезінде біз берілген интервалға түсетін инверттелген индекстер жиынын табамыз. Және, сәйкесінше, біз сол жерден уақыттық қатардың идентификаторын таңдаймыз.
Бұл ресурстарды үнемдейді, өйткені берілген аралыққа түспейтін бөліктерді қараудың қажеті жоқ. Яғни, әдетте, соңғы сағаттағы деректерді таңдасақ, алдыңғы уақыт аралығы үшін сұрауларды өткізіп жібереміз.
Бұл мәселені шешудің тағы бір нұсқасы бар. Бұл әр күн үшін сол күні орын алған уақыт қатарларының идентификаторларының бөлек тізімін сақтау үшін қажет.
Бұл шешімнің алдыңғы шешімнен артықшылығы - біз уақыт өте келе жойылмайтын уақыттық қатар туралы ақпаратты қайталамаймыз. Олар үнемі қатысады және өзгермейді.
Кемшілігі - мұндай шешімді жүзеге асыру қиынырақ және жөндеу қиынырақ. Ал VictoriaMetrics осы шешімді таңдады. Тарихи түрде осылай болды. Бұл шешім алдыңғысымен салыстырғанда жақсы жұмыс істейді. Өйткені бұл шешім өзгермейтін, яғни уақыт өте келе жойылмайтын уақыттық қатарлар үшін әрбір бөлімдегі деректерді қайталау қажет болғандықтан орындалмады. VictoriaMetrics негізінен дискілік кеңістікті тұтыну үшін оңтайландырылған және алдыңғы енгізу дискілік кеңістікті тұтынуды нашарлатты. Бірақ бұл іске асыру дискілік кеңістікті тұтынуды азайту үшін жақсырақ, сондықтан ол таңдалды.
Мен онымен күресуге тура келді. Күрес бұл іске асыруда сіз әлі де әлдеқайда көп санды таңдауыңыз керек болды timeseries_ids деректер үшін инверттелген индекс уақыт бойынша бөлінген кездегіге қарағанда.
Біз бұл мәселені қалай шештік? Біз оны түпнұсқалық жолмен шештік - бір идентификатордың орнына әрбір инверттелген индекс жазбасында бірнеше уақыт қатарының идентификаторларын сақтау арқылы. Яғни, бізде кілт бар label=value, ол әрбір уақыт қатарында кездеседі. Ал қазір бірнешеуін үнемдейміз timeseries_ids бір жазбада.
Міне, мысал. Бұрын бізде N жазба болды, бірақ қазір бізде префиксі басқаларымен бірдей бір жазба бар. Алдыңғы жазба үшін мән барлық уақыт қатарларының идентификаторларын қамтиды.
Бұл инверттелген индексті сканерлеу жылдамдығын 10 есеге дейін арттыруға мүмкіндік берді. Бұл кэш үшін жадты тұтынуды азайтуға мүмкіндік берді, өйткені қазір біз жолды сақтаймыз label=value тек бір рет кэште бірге N рет. Кубернетес тегтеріңіз бен жапсырмаларыңызда ұзын жолдарды сақтасаңыз, бұл жол үлкен болуы мүмкін.
Төңкерілген индексте іздеуді жылдамдатудың тағы бір нұсқасы - бөлшектеу. Біреуінің орнына бірнеше инверттелген индекстер жасау және олардың арасында деректерді кілт арқылы бөлу. Бұл жиынтық 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 жүйесінде сақтайды және олар болашақта оларды қалай біріктіретінін және сүзетінін әлі білмейді, сондықтан олар барлық бастапқы деректерді сақтауы керек. Бірақ егер сіз бірдеңені орташа есеппен есептеу керек екенін білсеңіз, онда көптеген шикізатты сақтаудың орнына неге оны есептемеске? Бірақ бұл сізге не қажет екенін нақты білсеңіз ғана.
Айтпақшы, уақыттық қатарларды сақтауға арналған дерекқорлар агрегаттарды санауды қолдайды. Мысалы, Прометей қолдайды . Яғни, сізге қандай бірлік қажет болатынын білсеңіз, мұны жасауға болады. VictoriaMetrics-те бұл әлі жоқ, бірақ әдетте оны қайта кодтау ережелерінде орындауға болатын Прометей бар.
Мысалы, алдыңғы жұмысымда мен соңғы сағатта жылжымалы терезедегі оқиғалар санын санауым керек болды. Мәселе мынада, мен Go бағдарламасында теңшелетін енгізуді, яғни осы нәрсені санау қызметін жасауым керек болды. Бұл қызмет ақыр соңында тривиальды емес болды, өйткені оны есептеу қиын. Белгіленген уақыт аралықтарында кейбір агрегаттарды санау қажет болса, іске асыру қарапайым болуы мүмкін. Жылжымалы терезеде оқиғаларды санағыңыз келсе, бұл көрінгендей қарапайым емес. Менің ойымша, бұл әлі ClickHouse-да немесе уақыт сериясының дерекқорларында жүзеге асырылған жоқ, себебі оны жүзеге асыру қиын.
Және тағы бір сұрақ. Біз жай ғана орташалау туралы сөйлескен болатынбыз, мен бір кездері көміртегі бар графит сияқты нәрсе болғанын есіме түсірдім. Және ол ескі деректерді қалай жұқару керектігін білді, яғни минутына бір нүкте, сағатына бір ұпай қалдыру және т.б.. Негізінде, бұл бізге бір ай ішінде бастапқы деректер қажет болса, өте ыңғайлы, ал қалғанының бәрі мүмкін. жұқа болу. Бірақ Prometheus және VictoriaMetrics бұл функцияны қолдамайды. Оны қолдау жоспарланып отыр ма? Егер жоқ болса, неге жоқ?
Сұрақ үшін рахмет. Біздің қолданушылар бұл сұрақты мезгіл-мезгіл қояды. Олар кішірейту үшін қолдауды қашан қосатынымызды сұрайды. Бұл жерде бірнеше мәселе бар. Біріншіден, әрбір пайдаланушы түсінеді downsampling басқа нәрсе: біреу берілген аралықта кез келген ерікті нүктені алғысы келеді, біреу максималды, минималды, орташа мәндерді қалайды. Егер көптеген жүйелер дерекқорыңызға деректерді жазса, олардың барлығын біріктіре алмайсыз. Әрбір жүйе әртүрлі жұқаруды қажет етуі мүмкін. Ал мұны жүзеге асыру қиын.
Екінші нәрсе, VictoriaMetrics, ClickHouse сияқты, үлкен көлемдегі өңделмеген деректермен жұмыс істеу үшін оңтайландырылған, сондықтан сіздің жүйеңізде көптеген ядролар болса, ол бір секундтан аз уақыт ішінде миллиард жолды жоя алады. VictoriaMetrics-тегі уақыт серияларының нүктелерін сканерлеу – бір ядроға секундына 50 000 000 ұпай. Және бұл өнімділік бар ядроларға таралады. Яғни, сізде 20 ядро болса, мысалы, секундына миллиард нүктені сканерлейсіз. VictoriaMetrics және ClickHouse бұл қасиеті кішірейту қажеттілігін азайтады.
Тағы бір ерекшелігі, VictoriaMetrics бұл деректерді тиімді түрде қысады. Өндірістегі қысу орта есеппен бір нүктеге 0,4-тен 0,8 байтқа дейін. Әрбір нүкте уақыт белгісі + мән болып табылады. Және ол орта есеппен бір байттан азға қысылады.
Сергей. Менде сұрақ бар. Ең аз жазу уақытының кванты қандай?
Бір миллисекунд. Жақында біз басқа уақыт сериялары дерекқорын әзірлеушілерімен сөйлестік. Олардың ең аз уақыт тілі бір секунд. Мысалы, Графитте бұл да бір секунд. OpenTSDB-де бұл да бір секунд. InfluxDB наносекундтық дәлдікке ие. VictoriaMetrics-те бұл бір миллисекунд, өйткені Прометейде бұл бір миллисекунд. Ал VictoriaMetrics бастапқыда Prometheus үшін қашықтағы сақтау орны ретінде жасалған. Бірақ қазір ол басқа жүйелерден деректерді сақтай алады.
Мен сөйлескен адам олардың секундтық дәлдікке ие екенін айтады - бұл олар үшін жеткілікті, өйткені бұл уақыт сериясының дерекқорында сақталатын деректер түріне байланысты. Егер бұл DevOps деректері немесе оны минутына 30 секунд аралықпен жинайтын инфрақұрылым деректері болса, екінші дәлдік жеткілікті, сізге одан кем ештеңе қажет емес. Ал егер сіз бұл деректерді жоғары жиілікті сауда жүйелерінен жинасаңыз, онда сізге наносекундтық дәлдік қажет.
VictoriaMetrics-тегі миллисекунд дәлдігі DevOps жағдайына да сәйкес келеді және мен есептің басында айтқан жағдайлардың көпшілігі үшін қолайлы болуы мүмкін. Ол жарамсыз болуы мүмкін жалғыз нәрсе - жоғары жиілікті сауда жүйелері.
Рақмет сізге! Және тағы бір сұрақ. PromQL-де үйлесімділік дегеніміз не?
Толық кері үйлесімділік. VictoriaMetrics PromQL тілін толығымен қолдайды. Сонымен қатар, ол PromQL деп аталатын қосымша кеңейтілген функционалдылықты қосады . YouTube сайтында бұл кеңейтілген функция туралы әңгіме бар. Мен көктемде Санкт-Петербургте өткен Мониторинг кездесуінде сөз сөйледім.
Telegram каналы .
Сауалнамаға тек тіркелген пайдаланушылар қатыса алады. , өтінемін.
Prometheus үшін ұзақ мерзімді сақтау орны ретінде VictoriaMetrics жүйесіне ауысуыңызға не кедергі? (Пікірге жазыңыз, мен оны сауалнамаға қосамын))
-
71,4%Мен Prometheus5 қолданбаймын
-
28,6%VictoriaMetrics2 туралы білмедім
7 пайдаланушы дауыс берді. 12 пайдаланушы қалыс қалды.
Ақпарат көзі: www.habr.com