Иди на оптимизацију у ВицториаМетрицс. Александар Ваљалкин

Предлажем да прочитате транскрипт извештаја Александра Ваљалкина из касне 2019. године „Идите оптимизације у ВицториаМетрицс“

ВицториаМетрицс — брз и скалабилан ДБМС за складиштење и обраду података у облику временске серије (запис формира време и скуп вредности које одговарају овом времену, на пример, добијене периодичним испитивањем статуса сензора или прикупљањем метрика).

Ево линка до видео снимка овог извештаја - https://youtu.be/MZ5P21j_HLE

Слајдови

Реците нам нешто о себи. Ја сам Александар Ваљалкин. Ево мој ГитХуб налог. Ја сам страствен за Го и оптимизацију перформанси. Написао сам много корисних и не баш корисних библиотека. Почињу са било којим fast, или са quick префикс.

Тренутно радим на ВицториаМетрицс. Шта је то и шта ја радим тамо? О томе ћу говорити у овој презентацији.

Преглед извештаја је следећи:

• Прво ћу вам рећи шта је ВицториаМетрицс.
• Онда ћу вам рећи шта су временске серије.
• Онда ћу вам рећи како функционише база података временских серија.
• Затим ћу вам рећи о архитектури базе података: од чега се састоји.
• А онда пређимо на оптимизације које ВицториаМетрицс има. Ово је оптимизација за обрнути индекс и оптимизација за имплементацију скупа битова у Го.

Да ли неко у публици зна шта је ВицториаМетрицс? Вау, многи људи већ знају. То је добра вест. За оне који не знају, ово је база података временских серија. Заснован је на ЦлицкХоусе архитектури, на неким детаљима имплементације ЦлицкХоусе. На пример, на: МергеТрее, паралелно израчунавање на свим доступним процесорским језграма и оптимизација перформанси радом на блоковима података који су смештени у кеш процесора.

ВицториаМетрицс пружа бољу компресију података од других база података временских серија.

Скалира се вертикално - то јест, можете додати више процесора, више РАМ-а на један рачунар. ВицториаМетрицс ће успешно користити ове расположиве ресурсе и побољшаће линеарну продуктивност.

ВицториаМетрицс такође скалира хоризонтално – то јест, можете додати додатне чворове ВицториаМетрицс кластеру, а његове перформансе ће се повећати скоро линеарно.

Као што сте претпоставили, ВицториаМетрицс је брза база података, јер не могу писати друге. И то је написано у Го, тако да говорим о томе на овом састанку.

Ко зна шта је временска серија? Он такође познаје много људи. Временска серија је низ парова (timestamp, значение), где су ови парови сортирани по времену. Вредност је број са покретним зарезом – флоат64.

Свака временска серија је јединствено идентификована кључем. Од чега се састоји овај кључ? Састоји се од непразног скупа парова кључ/вредност.

Ево примера временске серије. Кључ ове серије је листа парова: __name__="cpu_usage" је назив метрике, instance="my-server" - ово је рачунар на којем се ова метрика прикупља, datacenter="us-east" - ово је дата центар у коме се налази овај рачунар.

На крају смо добили назив временске серије који се састоји од три пара кључ/вредност. Овај кључ одговара листи парова (timestamp, value). t1, t3, t3, ..., tN - ово су временске ознаке, 10, 20, 12, ..., 15 — одговарајуће вредности. Ово је употреба процесора у датом тренутку за дату серију.

Где се могу користити временске серије? Има ли неко идеју?

• У ДевОпс-у можете мерити ЦПУ, РАМ, мрежу, рпс, број грешака итд.
• ИоТ - можемо мерити температуру, притисак, гео координате и још нешто.
• Такође и финансије – можемо да пратимо цене за све врсте акција и валута.
• Поред тога, временске серије се могу користити у праћењу производних процеса у фабрикама. Имамо кориснике који користе ВицториаМетрицс за праћење турбина на ветар, за роботе.
• Временске серије су такође корисне за прикупљање информација са сензора различитих уређаја. На пример, за мотор; за мерење притиска у гумама; за мерење брзине, удаљености; за мерење потрошње бензина итд.
• Временске серије се такође могу користити за праћење авиона. Сваки авион има црну кутију која прикупља временске серије за различите параметре здравственог стања авиона. Временске серије се такође користе у ваздухопловној индустрији.
• Здравствена заштита је крвни притисак, пулс итд.

Можда има још апликација на које сам заборавио, али надам се да разумете да се временске серије активно користе у савременом свету. А обим њихове употребе расте сваке године.

Зашто вам је потребна база података временских серија? Зашто се обична релациона база података не може користити за чување временских серија?

Зато што временске серије обично садрже велику количину информација, које је тешко чувати и обрадити у конвенционалним базама података. Стога су се појавиле специјализоване базе података за временске серије. Ове базе ефикасно чувају бодове (timestamp, value) са датим кључем. Они обезбеђују АПИ за читање ускладиштених података по кључу, по једном пару кључ-вредност, или по више парова кључ-вредност, или по редовном изразу. На пример, желите да пронађете ЦПУ оптерећење свих ваших услуга у дата центру у Америци, онда морате да користите овај псеудо-упит.

Обично базе података временских серија пружају специјализоване језике за упите јер СКЛ временски низ није баш погодан. Иако постоје базе података које подржавају СКЛ, он није баш погодан. Језици упита као што су ПромКЛ, ИнфлукКЛ, Флукс, Q. Надам се да је неко чуо бар један од ових језика. Многи људи су вероватно чули за ПромКЛ. Ово је Прометејев језик упита.

Овако изгледа модерна архитектура базе података временских серија користећи ВицториаМетрицс као пример.

Састоји се из два дела. Ово је складиште за обрнути индекс и складиште за вредности временских серија. Ова спремишта су одвојена.

Када нови запис стигне у базу података, прво приступамо обрнутом индексу да бисмо пронашли идентификатор временске серије за дати скуп label=value за дату метрику. Проналазимо овај идентификатор и чувамо вредност у складишту података.

Када дође захтев за преузимање података из ТСДБ, прво идемо на обрнути индекс. Хајде да добијемо све 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, о чему ће бити речи у наставку. И ова функција враћа пресек ових листа.

Као што видите, имплементација обрнутог индекса није много компликована. Али ово је наивна имплементација. Које недостатке има? Главни недостатак наивне имплементације је тај што се такав обрнути индекс чува у РАМ-у. Након поновног покретања апликације губимо овај индекс. Нема чувања овог индекса на диску. Такав обрнути индекс вероватно неће бити погодан за базу података.

Други недостатак је такође повезан са меморијом. Обрнути индекс мора да стане у РАМ. Ако премашује величину РАМ-а, онда ћемо очигледно добити - грешку у меморији. И програм неће радити.

Овај проблем се може решити коришћењем готових решења као нпр ЛевелДБИли РоцксДБ.

Укратко, потребна нам је база података која нам омогућава да брзо обавимо три операције.

• Прва операција је снимање ключ-значение овој бази података. Она то ради веома брзо, где ключ-значение су произвољни низови.
• Друга операција је брза претрага вредности помоћу датог кључа.
• И трећа операција је брза претрага свих вредности по датом префиксу.

ЛевелДБ и РоцксДБ - ове базе података су развили Гугл и Фејсбук. Први је дошао ЛевелДБ. Онда су момци са Фејсбука узели ЛевелДБ и почели да га побољшавају, направили су РоцксДБ. Сада скоро све интерне базе података раде на РоцксДБ унутар Фацебоок-а, укључујући и оне које су пребачене у РоцксДБ и МиСКЛ. Дали су му име МиРоцкс.

Обрнути индекс се може имплементирати помоћу ЛевелДБ. Како се то ради? Чувамо као кључ label=value. А вредност је идентификатор временске серије у којој је пар присутан label=value.

Ако имамо много временских серија са датим паром label=value, тада ће у овој бази података бити много редова са истим кључем и различитим timeseries_ids. Да бисте добили списак свих timeseries_ids, који почињу са овим label=prefix, вршимо скенирање опсега за које је ова база података оптимизована. То јест, бирамо све линије које почињу са label=prefix и добити потребно timeseries_ids.

Ево примера имплементације како би то изгледало у Го. Имамо обрнути индекс. Ово је ЛевелДБ.

Функција је иста као и за наивну имплементацију. Понавља наивну имплементацију скоро ред по ред. Једина ствар је да уместо да се окренемо map приступамо обрнутом индексу. Добијамо све вредности за први label=value. Затим пролазимо кроз све преостале парове label=value и добијете одговарајуће скупове метричких ИД-ова за њих. Затим налазимо раскрсницу.

Чини се да је све у реду, али ово решење има недостатака. ВицториаМетрицс је у почетку имплементирао обрнути индекс заснован на ЛевелДБ. Али на крају сам морао да одустанем.

Зашто? Зато што је ЛевелДБ спорији од наивне имплементације. У наивној имплементацији, с обзиром на дати кључ, одмах преузимамо цео исечак metricIDs. Ово је веома брза операција - цео комад је спреман за употребу.

У ЛевелДБ, сваки пут када се позове функција GetValues треба да прођете кроз све редове који почињу са label=value. И добијте вредност за сваки ред timeseries_ids. Таквог timeseries_ids сакупите парче ових timeseries_ids. Очигледно, ово је много спорије од једноставног приступа обичној мапи помоћу кључа.

Други недостатак је што је ЛевелДБ написан у Ц. Позивање Ц функција из Го није баш брзо. Потребно је стотине наносекунди. Ово није веома брзо, јер у поређењу са обичним позивом функције написаним у го, који траје 1-5 наносекунди, разлика у перформансама је десетине пута. За ВицториаМетрицс ово је била фатална мана :)

Зато сам написао сопствену имплементацију обрнутог индекса. И он ју је позвао мергесет.

Мергесет је заснован на структури података МергеТрее. Ова структура података је позајмљена од ЦлицкХоусе-а. Очигледно, скуп спајања треба да буде оптимизован за брзо претраживање timeseries_ids према задатом кључу. Мергесет је у потпуности написан у Го. Можете видети ВицториаМетрицс извори на ГитХуб-у. Имплементација мергесет-а је у фасцикли /либ/мергесет. Можете покушати да схватите шта се тамо дешава.

АПИ за спајање је веома сличан ЛевелДБ и РоцксДБ. Односно, омогућава вам да брзо сачувате нове записе тамо и брзо изаберете записе према датом префиксу.

Касније ћемо причати о недостацима спајања. Хајде сада да разговарамо о томе који су проблеми настали са ВицториаМетрицс-ом у производњи приликом имплементације обрнутог индекса.

Зашто су настали?

Први разлог је висока стопа одлива. Преведено на руски, ово је честа промена временских серија. Ово је када се завршава временска серија и почиње нова серија или почиње много нових временских серија. И то се често дешава.

Други разлог је велики број временских серија. У почетку, када је праћење постајало све популарније, број временских серија је био мали. На пример, за сваки рачунар морате да пратите оптерећење ЦПУ-а, меморије, мреже и диска. 4 временске серије по рачунару. Рецимо да имате 100 рачунара и 400 временских серија. Ово је врло мало.

Временом су људи схватили да могу мерити детаљније информације. На пример, мерите оптерећење не целог процесора, већ посебно сваког језгра процесора. Ако имате 40 процесорских језгара, онда имате 40 пута више временских серија за мерење оптерећења процесора.

Али то није све. Свако језгро процесора може имати неколико стања, као што је мировање, када је неактивно. И такође рад у корисничком простору, рад у простору кернела и другим стањима. А свако такво стање се такође може мерити као посебна временска серија. Ово додатно повећава број редова за 7-8 пута.

Из једне метрике добили смо 40 к 8 = 320 метрика за само један рачунар. Помножите са 100, добијамо 32 уместо 000.

Онда је дошао Кубернетес. И постало је горе јер Кубернетес може да хостује много различитих услуга. Свака услуга у Кубернетес-у се састоји од много подова. И све ово треба пратити. Поред тога, имамо сталну примену нових верзија ваших услуга. За сваку нову верзију морају се креирати нове временске серије. Као резултат тога, број временских серија расте експоненцијално и суочавамо се са проблемом великог броја временских серија, који се назива високо-кардиналност. ВицториаМетрицс се успешно носи са тим у поређењу са другим базама података временских серија.

Хајде да ближе погледамо високу стопу одлива. Шта узрокује високу стопу одустајања у производњи? Зато што се нека значења ознака и ознака стално мењају.

На пример, узмите Кубернетес, који има концепт deployment, тј. када се појави нова верзија ваше апликације. Из неког разлога, Кубернетес програмери су одлучили да додају ИД имплементације на ознаку.

До чега је ово довело? Штавише, са сваким новим применом, све старе временске серије се прекидају, а уместо њих почињу нове временске серије са новом вредношћу ознаке deployment_id. Таквих редова може бити стотине хиљада, па чак и милиони.

Важно је у свему томе да укупан број временских серија расте, али број временских серија које су тренутно активне и које примају податке остаје константан. Ово стање се назива висока стопа одлива.

Главни проблем високе стопе одлива је да се обезбеди константна брзина претраге за све временске серије за дати скуп ознака у одређеном временском интервалу. Обично је ово временски интервал за последњи сат или последњи дан.

Како решити овај проблем? Ево прве опције. Ово је да се обрнути индекс подели на независне делове током времена. То јест, прође неки временски интервал, завршавамо рад са тренутним обрнутим индексом. И креирајте нови обрнути индекс. Прође још један временски интервал, стварамо још један и још један.

И када узоркујемо из ових инвертованих индекса, налазимо скуп обрнутих индекса који спадају у дати интервал. И, сходно томе, одатле бирамо ид временске серије.

Ово штеди ресурсе јер не морамо да гледамо делове који не спадају у задати интервал. То јест, обично, ако бирамо податке за последњи сат, онда за претходне временске интервале прескачемо упите.

Постоји још једна опција за решавање овог проблема. Ово је да се за сваки дан чува посебна листа ИД-ова временских серија које су се десиле тог дана.

Предност овог решења у односу на претходно решење је у томе што не дуплирамо информације о временским серијама које не нестају током времена. Они су стално присутни и не мењају се.

Недостатак је што је такво решење теже имплементирати и теже отклонити грешке. ВицториаМетрицс је изабрала ово решење. Тако се то историјски десило. Ово решење такође има добре резултате у поређењу са претходним. Јер ово решење није имплементирано због чињенице да мора да дуплира податке у свакој партицији за временске серије које се не мењају, односно које не нестају током времена. ВицториаМетрицс је првенствено оптимизован за потрошњу простора на диску, а претходна имплементација је погоршала потрошњу простора на диску. Али ова имплементација је погоднија за минимизирање потрошње простора на диску, па је изабрана.

Морао сам да се борим са њом. Борба је била у томе што у овој имплементацији још увек треба да изаберете много већи број timeseries_ids за податке него када је обрнути индекс временски партициониран.

Како смо решили овај проблем? Решили смо то на оригиналан начин – чувањем неколико идентификатора временских серија у сваком инвертованом индексном уносу уместо једног идентификатора. То јест, имамо кључ label=value, који се јавља у свакој временској серији. А сада спашавамо неколико timeseries_ids у једном уносу.

Ево примера. Раније смо имали Н уноса, али сада имамо један унос чији је префикс исти као и сви остали. За претходни унос, вредност садржи ИД-ове свих временских серија.

Ово је омогућило повећање брзине скенирања таквог обрнутог индекса до 10 пута. И то нам је омогућило да смањимо потрошњу меморије за кеш, јер сада чувамо стринг label=value само једном у кешу заједно Н пута. А ова линија може бити велика ако складиштите дугачке редове у своје ознаке и етикете, које Кубернетес тамо воли да гурне.

Друга опција за убрзање претраге на обрнутом индексу је шардовање. Креирање неколико инвертираних индекса уместо једног и дељење података између њих по кључу. Ово је сет key=value паре. То јест, добијамо неколико независних инвертираних индекса, које можемо паралелно испитивати на неколико процесора. Претходне имплементације су дозвољавале рад само у режиму једног процесора, тј. скенирање података само на једном језгру. Ово решење вам омогућава да скенирате податке на неколико језгара одједном, као што ЦлицкХоусе воли да ради. То је оно што планирамо да спроведемо.

Сада се вратимо на нашу овцу - на функцију раскрснице timeseries_ids. Хајде да размотримо које имплементације могу бити. Ова функција вам омогућава да пронађете timeseries_ids за дати скуп label=value.

Прва опција је наивна имплементација. Две угнежђене петље. Овде добијамо улаз функције intersectInts две кришке - a и b. На излазу, требало би да нам врати пресек ових пресека.

Наивна имплементација изгледа овако. Итерирамо све вредности из пресека a, унутар ове петље пролазимо кроз све вредности пресека b. И поредимо их. Ако се поклапају, онда смо пронашли раскрсницу. И сачувајте га result.

Који су недостаци? Квадратна сложеност је његов главни недостатак. На пример, ако су ваше димензије исечене a и b милион по милион, онда вам ова функција никада неће вратити одговор. Зато што ће морати да направи трилион итерација, што је много чак и за модерне рачунаре.

Друга имплементација је заснована на мапи. Ми креирамо мапу. Ставили смо све вредности из пресека у ову мапу a. Затим пролазимо кроз рез у посебној петљи b. И проверавамо да ли је ова вредност из пресека b у мапи. Ако постоји, додајте га у резултат.

Које су предности? Предност је што постоји само линеарна сложеност. То јест, функција ће се извршавати много брже за веће резове. За исечак величине милион, ова функција ће се извршити у 2 милиона итерација, за разлику од трилиона итерација претходне функције.

Лоша страна је што је овој функцији потребно више меморије за креирање ове мапе.

Други недостатак су велики трошкови за хеширање. Овај недостатак није баш очигледан. И за нас то такође није било очигледно, па је у ВицториаМетрицс-у у почетку имплементација раскрснице била преко мапе. Али онда је профилисање показало да се време главног процесора троши на писање на мапи и проверу присуства вредности на овој мапи.

Зашто се на овим местима губи ЦПУ време? Зато што Го врши операцију хеширања на овим линијама. То јест, он израчунава хеш кључа да би му затим приступио на датом индексу у ХасхМап-у. Операција израчунавања хеша се завршава за десетине наносекунди. Ово је споро за ВицториаМетрицс.

Одлучио сам да имплементирам битсет оптимизован посебно за овај случај. Овако сада изгледа пресек два пресека. Овде креирамо битсет. У њега додајемо елементе из првог пресека. Затим проверавамо присуство ових елемената у другом пресеку. И додајте их резултату. То јест, готово се не разликује од претходног примера. Једина ствар овде је да смо приступ мапи заменили прилагођеним функцијама add и has.

На први поглед изгледа да би ово требало да ради спорије, ако је раније коришћена стандардна мапа, па се позивају неке друге функције, али профилисање показује да ова ствар ради 10 пута брже од стандардне мапе у случају ВицториаМетрицс-а.

Поред тога, користи много мање меморије у поређењу са имплементацијом мапе. Зато што овде складиштимо битове уместо вредности од осам бајтова.

Недостатак ове имплементације је што није тако очигледан, није тривијалан.

Још један недостатак који многи можда не примећују је да ова имплементација можда неће добро функционисати у неким случајевима. Односно, оптимизован је за конкретан случај, за овај случај пресека ИД-ова временских серија ВицториаМетрицс. То не значи да је погодан за све случајеве. Ако се погрешно користи, нећемо добити повећање перформанси, већ грешку у недостатку меморије и успоравање перформанси.

Хајде да размотримо имплементацију ове структуре. Ако желите да погледате, налази се у ВицториаМетрицс изворима, у фасцикли либ/уинт64сет. Оптимизован је посебно за ВицториаМетрицс случај, где timeseries_id је 64-битна вредност, где су прва 32 бита у основи константна, а само последња 32 бита се мењају.

Ова структура података није ускладиштена на диску, она ради само у меморији.

Ево његовог АПИ-ја. Није много компликовано. АПИ је посебно прилагођен конкретном примеру коришћења ВицториаМетрицс-а. То јест, овде нема непотребних функција. Ево функција које ВицториаМетрицс експлицитно користи.

Постоје функције add, што додаје нове вредности. Постоји функција has, који проверава нове вредности. И постоји функција del, који уклања вредности. Постоји помоћна функција len, који враћа величину скупа. Функција clone много клонова. И функција appendto претвара овај скуп у пресек timeseries_ids.

Овако изгледа имплементација ове структуре података. сет има два елемента:

• ItemsCount је помоћно поље за брзо враћање броја елемената у скупу. Било би могуће и без овог помоћног поља, али оно је морало бити додато овде јер ВицториаМетрицс често испитује дужину битова у својим алгоритмима.

• Друго поље је 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 у структури б32 buckets. И додајте нижа 32 бита тамо. А ако се врати true, онда ово значи да смо ту додали такву вредност а такву вредност нисмо имали. Ако се врати false, онда је такво значење већ постојало. Затим повећавамо број елемената у структури.

Ако нисмо пронашли ону која вам је потребна bucket са траженом хи-вредношћу, тада позивамо функцију addAlloc, који ће произвести нову bucket, додајући га структури корпе.

Ово је имплементација функције b32.add. Слично је претходној имплементацији. Израчунавамо најзначајнијих 16 бита, најмање значајних 16 бита.

Затим пролазимо кроз свих горњих 16 бита. Проналазимо подударања. А ако постоји подударање, позивамо метод додавања, који ћемо размотрити на следећој страници bucket16.

А ево и најнижег нивоа, који треба максимално оптимизовати. Рачунамо за uint64 ид вредност у биту пресека и такође bitmask. Ово је маска за дату 64-битну вредност, која се може користити за проверу присуства овог бита или за подешавање. Проверавамо да ли је овај бит постављен и постављамо га и враћамо присуство. Ово је наша имплементација, која нам је омогућила да убрзамо рад пресецања ИД-ова временских серија за 10 пута у поређењу са конвенционалним мапама.

Поред ове оптимизације, ВицториаМетрицс има много других оптимизација. Већина ових оптимизација је додата са разлогом, али након профилисања кода у производњи.

Ово је главно правило оптимизације - немојте додавати оптимизацију под претпоставком да ће овде бити уско грло, јер се може испоставити да ту неће бити уско грло. Оптимизација обично деградира квалитет кода. Стога је вредно оптимизовати тек након профилисања и по могућности у производњи, тако да су ово стварни подаци. Ако је неко заинтересован, може погледати ВицториаМетрицс изворни код и истражити друге оптимизације које постоје.

Имам питање о битсету. Веома сличан Ц++ векторској имплементацији боол-а, оптимизован сет битова. Да ли сте одатле преузели имплементацију?

Не, не одатле. Када сам имплементирао овај сет битова, водио сам се знањем о структури ових ИД-ова временских серија, које се користе у ВицториаМетрицс. А њихова структура је таква да су горња 32 бита у основи константна. Доња 32 бита су подложна променама. Што је бит нижи, то се чешће може мењати. Стога је ова имплементација посебно оптимизована за ову структуру података. Имплементација Ц++-а, колико ја знам, је оптимизована за општи случај. Ако оптимизујете за општи случај, то значи да неће бити најоптималнији за конкретан случај.

Такође вам саветујем да погледате извештај Алексеја Миловида. Пре око месец дана говорио је о оптимизацији у ЦлицкХоусе-у за одређене специјализације. Он само каже да је у општем случају имплементација Ц++ или нека друга имплементација прилагођена да у просеку добро функционише у болници. Може имати лошије резултате од имплементације специфичне за знање као што је наша, где знамо да су горња 32 бита углавном константна.

Имам друго питање. Која је суштинска разлика од ИнфлукДБ-а?

Постоји много фундаменталних разлика. Што се тиче перформанси и потрошње меморије, ИнфлукДБ у тестовима показује 10 пута већу потрошњу меморије за временске серије високе кардиналности, када их имате много, на пример, милионе. На пример, ВицториаМетрицс троши 1 ГБ на милион активних редова, док ИнфлукДБ троши 10 ГБ. И то је велика разлика.

Друга фундаментална разлика је у томе што ИнфлукДБ има чудне језике упита - Флук и ИнфлукКЛ. Нису баш згодне за рад са временским серијама у поређењу са ПромКЛ, који подржава ВицториаМетрицс. ПромКЛ је језик упита из Прометхеуса.

И још једна разлика је у томе што ИнфлукДБ има помало чудан модел података, где свака линија може да ускладишти неколико поља са различитим скупом ознака. Ови редови су даље подељени у различите табеле. Ове додатне компликације компликују каснији рад са овом базом података. Тешко је то подржати и разумети.

У ВицториаМетрицс све је много једноставније. Тамо је свака временска серија кључ/вредност. Вредност је скуп поена - (timestamp, value), а кључ је сет label=value. Нема раздвајања између поља и мерења. Омогућава вам да изаберете било који податак, а затим комбинујете, сабирате, одузимате, множите, делите, за разлику од ИнфлукДБ-а где се прорачуни између различитих редова још увек не примењују колико ја знам. Чак и ако се имплементирају, тешко је, морате написати много кода.

Имам једно разјашњавајуће питање. Да ли сам добро разумео да је постојао неки проблем о коме сте говорили, да се овај обрнути индекс не уклапа у меморију, па постоји партиционисање?

Прво сам показао наивну имплементацију обрнутог индекса на стандардној Го мапи. Ова имплементација није погодна за базе података јер овај инвертирани индекс није сачуван на диску, а база података мора да се сачува на диску тако да ови подаци остану доступни након поновног покретања. У овој имплементацији, када поново покренете апликацију, ваш обрнути индекс ће нестати. И изгубићете приступ свим подацима јер нећете моћи да их пронађете.

Здраво! Хвала на извештају! Моје име је Павел. Ја сам из Вилдберриеса. Имам неколико питања за вас. Прво питање. Да ли мислите да бисте, да сте изабрали другачији принцип приликом изградње архитектуре ваше апликације и поделили податке током времена, можда бисте могли да укрштате податке приликом претраживања, само на основу чињенице да једна партиција садржи податке за једну временском периоду, односно у једном временском интервалу и не бисте морали да бринете о чињеници да су ваши комади различито разбацани? Питање број 2 - пошто имплементирате сличан алгоритам са битсетом и свим осталим, онда сте можда покушали да користите инструкције процесора? Можда сте пробали такве оптимизације?

На другу ћу одмах одговорити. Нисмо још стигли до те тачке. Али ако треба, стићи ћемо тамо. А прво, које је било питање?

Разговарали сте о два сценарија. И рекли су да су изабрали другу са сложенијом имплементацијом. И нису више волели први, где су подаци подељени по времену.

Да. У првом случају, укупан обим индекса би био већи, јер бисмо у свакој партицији морали да складиштимо дуплиране податке за оне временске серије које се настављају кроз све ове партиције. А ако је ваша стопа одлива временских серија мала, односно константно се користе исте серије, онда бисмо у првом случају изгубили много више у количини заузетог простора на диску у односу на други случај.

И тако - да, подела времена је добра опција. Прометеј га користи. Али Прометеј има још један недостатак. Када спаја ове делове података, потребно је да задржи у меморији мета информације за све ознаке и временске серије. Стога, ако су делови података које спаја велики, потрошња меморије се веома повећава током спајања, за разлику од ВицториаМетрицс-а. Када се спаја, ВицториаМетрицс уопште не троши меморију; троши се само неколико килобајта, без обзира на величину спојених делова података.

Алгоритам који користите користи меморију. Означава ознаке временских серија које садрже вредности. И на овај начин проверавате присуство упарених у једном низу података иу другом. И разумете да ли је дошло до пресека или не. Обично базе података имплементирају курсоре и итераторе који чувају њихов тренутни садржај и пролазе кроз сортиране податке због једноставне сложености ових операција.

Зашто не користимо курсоре за прелазак података?

Да.

Чувамо сортиране редове у ЛевелДБ или обједињеном скупу. Можемо да померимо курсор и пронађемо раскрсницу. Зашто га не искористимо? Зато што је споро. Зато што курсори значе да треба да позовете функцију за сваку линију. Позив функције је 5 наносекунди. А ако имате 100 линија, онда се испоставља да пола секунде трошимо само на позивање функције.

Постоји тако нешто, да. И моје последње питање. Питање може звучати мало чудно. Зашто није могуће прочитати све потребне агрегате у тренутку када подаци стигну и сачувати их у траженом облику? Зашто штедити огромне количине у неким системима као што су ВицториаМетрицс, ЦлицкХоусе, итд., а затим трошити много времена на њих?

Даћу пример да буде јасније. Рецимо како ради мали брзиномјер играчке? Он бележи раздаљину коју сте прешли, све време додајући је једној вредности, а другој - времену. И дели. И добија просечну брзину. Можеш да урадиш отприлике исту ствар. Додајте све потребне чињенице у ходу.

У реду, разумем питање. Ваш пример има своје место. Ако знате који агрегати су вам потребни, онда је ово најбоља имплементација. Али проблем је у томе што људи чувају ове метрике, неке податке у ЦлицкХоусе-у и још не знају како ће их агрегирати и филтрирати у будућности, тако да морају да сачувају све необрађене податке. Али ако знате да треба да израчунате нешто у просеку, зашто то не бисте израчунали уместо да тамо складиштите гомилу сирових вредности? Али ово је само ако знате тачно шта вам треба.

Иначе, базе података за складиштење временских серија подржавају бројање агрегата. На пример, Прометеј подржава правила снимања. То јест, то се може урадити ако знате које јединице ће вам требати. ВицториаМетрицс ово још нема, али му обично претходи Прометеј, у коме се то може урадити у правилима за кодирање.

На пример, у мом претходном послу морао сам да избројим број догађаја у клизном прозору током последњег сата. Проблем је што сам морао да направим прилагођену имплементацију у Го, односно сервис за бројање ове ствари. Ова услуга је на крају била нетривијална, јер је тешко израчунати. Имплементација може бити једноставна ако треба да пребројите неке агрегате у фиксним временским интервалима. Ако желите да бројите догађаје у клизном прозору, онда то није тако једноставно као што изгледа. Мислим да ово још није имплементирано у ЦлицкХоусе или у базама података временских серија, јер је тешко имплементирати.

И још једно питање. Управо смо причали о усредњавању, и сетио сам се да је некада постојала таква ствар као што је Графит са карбонским позадинским делом. И знао је да прореди старе податке, односно да остави један поен у минути, један поен на сат итд. У принципу, ово је прилично згодно ако су нам потребни сирови подаци, релативно говорећи, за месец дана, а све остало може бити проређен . Али Прометхеус и ВицториаМетрицс не подржавају ову функционалност. Да ли је планирано да се то подржи? Ако не, зашто не?

Хвала на питању. Наши корисници периодично постављају ово питање. Питају када ћемо додати подршку за смањење узорковања. Овде постоји неколико проблема. Прво, сваки корисник разуме downsampling нешто другачије: неко жели да добије било коју произвољну тачку на датом интервалу, неко жели максималне, минималне, просечне вредности. Ако многи системи записују податке у вашу базу података, онда не можете све то збројити. Може бити да сваки систем захтева различито проређивање. А ово је тешко спровести.

А друга ствар је да је ВицториаМетрицс, попут ЦлицкХоусе-а, оптимизован за рад на великим количинама необрађених података, тако да може да избаци милијарду редова за мање од секунде ако имате много језгара у вашем систему. Скенирање тачака временске серије у ВицториаМетрицс – 50 поена у секунди по језгру. И ове перформансе се скалирају на постојећа језгра. То јест, ако имате 000 језгара, на пример, скенираћете милијарду тачака у секунди. А ово својство ВицториаМетрицс и ЦлицкХоусе смањује потребу за смањењем броја узорака.

Још једна карактеристика је да ВицториаМетрицс ефикасно компримује ове податке. Компресија у просеку у производњи је од 0,4 до 0,8 бајтова по тачки. Свака тачка је временска ознака + вредност. И у просеку је компримован у мање од једног бајта.

Сергеј. Имам питање. Колики је минимални квант времена снимања?

Једна милисекунда. Недавно смо разговарали са другим програмерима база података о временским серијама. Њихов минимални временски одсек је једна секунда. А у Грапхиту, на пример, то је такође једна секунда. У ОпенТСДБ је такође једна секунда. ИнфлукДБ има наносекундну прецизност. У ВицториаМетрицс-у је једна милисекунда, јер је у Прометеју једна милисекунда. А ВицториаМетрицс је првобитно развијен као удаљено складиште за Прометхеус. Али сада може да сачува податке из других система.

Особа са којом сам разговарао каже да имају тачност од секунде до секунде – то им је довољно јер зависи од врсте података који се чувају у бази података временских серија. Ако су ово ДевОпс подаци или подаци из инфраструктуре, где их прикупљате у интервалима од 30 секунди, по минуту, онда је тачност секунде довољна, не треба вам ништа мање. А ако прикупљате ове податке из високофреквентних трговачких система, онда вам је потребна тачност од наносекунде.

Прецизност у милисекунди у ВицториаМетрицс-у је такође погодна за ДевОпс случај и може бити погодна за већину случајева које сам поменуо на почетку извештаја. Једина ствар за коју можда није погодна су високофреквентни системи трговања.

Хвала вам! И још једно питање. Шта је компатибилност у ПромКЛ-у?

Потпуна компатибилност уназад. ВицториаМетрицс у потпуности подржава ПромКЛ. Поред тога, додаје додатну напредну функционалност у ПромКЛ, која се зове МетрицсКЛ. На Јутјубу се говори о овој проширеној функционалности. Говорио сам на Мониторинг Меетуп-у у пролеће у Санкт Петербургу.

Телеграм канал ВицториаМетрицс.

Само регистровани корисници могу учествовати у анкети. Пријавите се, Добродошао си.

Шта вас спречава да пређете на ВицториаМетрицс као дуготрајно складиште за Прометхеус? (Пишите у коментарима, ја ћу то додати у анкету))

• 100%Не користим Прометхеус5

• 100%Нисам знао за ВицториаМетрицс2

Гласало је 7 корисника. Уздржано је било 12 корисника.

Извор: ввв.хабр.цом