Отидете на оптимизации във VictoriaMetrics. Александър Валялкин

Предлагам да прочетете стенограмата на доклада от края на 2019 г. на Александър Валялкин „Go optimizations in VictoriaMetrics“

ВикторияМетрикс - бърза и мащабируема СУБД за съхранение и обработка на данни под формата на времеви серии (записът формира време и набор от стойности, съответстващи на това време, например получени чрез периодично проучване на състоянието на сензорите или колекцията от показатели).

Ето връзка към видеоклипа на този доклад - https://youtu.be/MZ5P21j_HLE

Слайдове

Разкажи ни за себе си. Аз съм Александър Валялкин. Тук моят акаунт в github. Аз съм запален по Go и оптимизацията на производителността. Написах много всякакви полезни и не много библиотеки. Те или започват с fast, или с quick префикс.

В момента работя върху VictoriaMetrics. Какво е и какво правя там? Ще говоря за това в тази презентация.

Схемата на доклада е следната:

• Първо ще ви кажа какво е VictoriaMetrics.
• Тогава ще ви кажа какво представляват времевите редове.
• След това ще ви кажа как работи базата данни с времеви редове.
• След това ще говоря за архитектурата на базата данни: от какво се състои.
• И тогава нека да преминем към оптимизациите, които са във VictoriaMetrics. Това са оптимизация за обърнатия индекс и оптимизация за внедряването на bitset в Go.

Какво е VictoriaMetrics знае ли някой от публиката? Уау, много хора вече знаят. Това е добра новина. За тези, които не знаят, това е база данни за времеви редове. Базиран е на архитектурата на ClickHouse, на някои подробности за внедряването на ClickHouse. Например, на такива като: MergeTree, паралелно изчисление на всички налични процесорни ядра и оптимизиране на производителността чрез работа върху блокове от данни, които се поставят в кеша на процесора.

VictoriaMetrics осигурява най-доброто компресиране на данни в сравнение с други бази данни с времеви редове.

Той се мащабира вертикално - тоест можете да добавите повече процесори, повече RAM на един компютър. 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 са съответните стойности. Това е текущото използване на процесора за дадения ред.

Къде могат да се използват времеви серии? Някой има ли представа?

• В DevOps можете да измервате CPU, RAM, мрежа, rps, грешки и т.н.
• IoT - можем да измерваме температура, налягане, гео координати и още нещо.
• Също така финанси - можем да следим цените за всякакви акции и валути.
• В допълнение, времеви редове могат да се използват за наблюдение на производствените процеси във фабриките. Имаме потребители, които използват VictoriaMetrics за наблюдение на вятърни турбини за роботи.
• Също така времевите серии са полезни за събиране на информация от сензори на различни устройства. Например за двигателя; за измерване на налягането в гумите; за измерване на скорост, разстояние; за измерване на разход на бензин и др.
• Също така времевите серии могат да се използват за наблюдение на самолети. Всеки самолет има черна кутия, която събира времеви серии за различни параметри на здравето на самолета. Времевите редове се използват и в космическата индустрия.
• Здравеопазването е кръвно налягане, пулс и т.н.

Може би все още има приложения, за които съм забравил, но се надявам, че разбирате, че времевите редове се използват активно в съвременния свят. И употребата им нараства всяка година.

За какво е база данни с времеви редове? Защо не можете да използвате обикновена релационна база данни за съхраняване на времеви редове?

Тъй като времевите редове обикновено съдържат голямо количество информация, която трудно се съхранява и обработва в конвенционалните бази данни. Затова се появиха специализирани бази данни за динамични редове. Тези бази ефективно съхраняват точки (timestamp, value) с дадения ключ. Те предоставят API за четене на съхранени данни по ключ, по една двойка ключ-стойност или по няколко такива двойки, или по регулярен израз. Например, искате да намерите натоварването на процесора на всички ваши услуги в център за данни в Америка, тогава трябва да използвате тази псевдо-заявка.

Обикновено базите данни за времеви серии са специализирани езици за заявки, тъй като SQL за времеви серии не е подходящ. Въпреки че има бази данни, които поддържат SQL, това не е много подходящо. По-подходящи езици за заявки като PromQL, InfluxQL, Flux, Q. Надявам се някой да е чувал поне един от тези езици. Много от вас вероятно са чували за PromQL. Това е езикът за заявки Prometheus.

Ето как изглежда архитектурата на съвременна база данни за времеви редове, използвайки VictoriaMetrics като пример.

Състои се от две части. Това е паметта за обърнатия индекс и паметта за стойностите на времевия ред. Тези хранилища са разделени.

Когато в базата данни пристигне нов запис, първо осъществяваме достъп до обърнатия индекс, за да намерим идентификатора на времевата серия за дадения набор label=value за този показател. Ние намираме този идентификатор и съхраняваме стойността в хранилището на данни.

Когато дойде някаква заявка за извличане на данни от TSDB, ние първо се качваме в обърнатия индекс. Получаваме всичко timeseries_ids записи, които съответстват на дадения набор label=value. И тогава получаваме всички необходими данни от хранилището на данни, индексирано от timeseries_ids.

Нека да разгледаме пример за това как база данни с времеви серии обработва входяща заявка за избор.

• На първо място, тя получава всичко timeseries_ids от обърнатия индекс, който съдържа дадените двойки label=value, или отговарят на дадения регулярен израз.
• След това тя получава всички точки от данни от хранилището на данни в даден интервал от време за намереното timeseries_ids.
• След това базата данни извършва някои изчисления върху тези точки от данни, според заявката на потребителя. И след това връща отговора.

В тази презентация ще ви разкажа за първата част. Това е търсене timeseries_ids чрез обърнат индекс. За втората част и третата част можете да видите по-късно Източници на VictoriaMetrics, или изчакайте, докато подготвя други доклади 🙂

Да започнем с обърнатия индекс. За мнозина това може да изглежда просто. Кой знае какво е обърнат индекс и как работи? О, вече няма толкова много хора. Нека се опитаме да разберем какво е то.

Всъщност всичко е просто. Това е просто речник, който свързва ключ със стойност. Какво е ключ? Тази двойка 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), което ще преобразува низа в slice ints. Линията съдържа label=value.

Реализация на функцията: get metricIDs за начало label=value, след това преминете през всички останали label=value, получаваме metricIDs за тях. И извикайте функцията intersectInts, които ще бъдат разгледани по-долу. И тази функция връща пресечната точка на тези списъци.

Както можете да видите, прилагането на обърнатия индекс не е много сложно. Но това е наивно изпълнение. Какви са нейните недостатъци? Основният недостатък на наивната реализация е, че съхраняваме такъв обърнат индекс в RAM. След рестартиране на приложението губим този индекс. Този индекс не се записва на диск. За база данни такъв обърнат индекс едва ли е подходящ.

Вторият недостатък също е свързан с паметта. Обърнатият индекс трябва да се побере в RAM. Ако надвишава размера на RAM, тогава е очевидно, че ще получим - грешка при липса на памет. И програмата няма да работи.

Този проблем може да бъде решен с помощта на готови решения като напр LevelDBИли RocksDB.

Накратко, имаме нужда от база данни, която ни позволява да правим три неща бързо.

• Първата операция е писането ключ-значение към тази база. Тя прави това много бързо. ключ-значение са произволни низове.
• Втората операция е бързо търсене на стойност по зададен ключ.
• И третата операция е бързо търсене на всички стойности по даден префикс.

LevelDB и RocksDB – Тези бази данни са разработени от Google и Facebook. Първо дойде LevelDB. Тогава момчетата от Facebook взеха LevelDB и започнаха да го подобряват, направиха RocksDB. Сега почти всички вътрешни бази данни работят върху RocksDB във Facebook, включително те са прехвърлени към RocksDB и MySQL. Нарекоха го myrocks.

Обърнат индекс може да бъде реализиран с помощта на 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. Достъпът до C функции от Go не е много бърз. Отнема стотици наносекунди. Това не е много бързо, защото в сравнение с обикновено извикване на функция, написано в go, което отнема 1-5 наносекунди, разликата в производителността е десетки пъти. За VictoriaMetrics това беше фатален недостатък 🙂

Затова написах моя собствена реализация на обърнатия индекс. И я повика mergeset.

Mergeset се основава на структурата на данните MergeTree. Тази структура на данните е заимствана от ClickHouse. Очевидно наборът за сливане трябва да бъде оптимизиран за бързо извличане timeseries_ids по дадения ключ. Mergeset е написан изцяло на Go. Можеш да видиш Източници на VictoriaMetrics в GitHub. Реализацията на mergeset е в папката /lib/mergeset. Можете да опитате да разберете какво се случва там.

API за mergeset е много подобен на LevelDB и RocksDB. Това означава, че ви позволява бързо да запазвате нови записи там и бързо да избирате записи по даден префикс.

Ще говорим за недостатъците на mergeset по-късно. Сега нека поговорим за проблемите с VictoriaMetrics в производството при прилагането на обърнатия индекс.

Защо са възникнали?

Първата причина е високият процент на оттегляне. Преведено на руски, това е честа промяна във времевите редове. Това е моментът, когато времевият ред свършва и започва нов ред или започват много нови времеви редове. И това се случва често.

Втората причина е големият брой времеви редове. В началото, когато мониторингът придоби популярност, броят на времевите серии беше малък. Например, на всеки компютър трябва да наблюдавате натоварването на процесора, паметта, мрежата и диска. 4 времеви серии на компютър. Да приемем, че имате 100 компютъра и 400 времеви серии. Това е много малко.

С течение на времето хората стигнаха до идеята, че може да се измери по-подробна информация. Например да се измери натоварването не на целия процесор, а по отделно на всяко процесорно ядро. Ако имате 40 процесорни ядра, тогава, съответно, имате 40 пъти повече времеви серии за измерване на натоварването на процесора.

Но това не е всичко. Всяко процесорно ядро ​​може да има няколко състояния, като празен ход, когато е неактивен. Както и работа в потребителско пространство, работа в пространство на ядрото и други състояния. И всяко такова състояние може да бъде измерено и като отделен времеви ред. Това допълнително увеличава броя на редовете 7-8 пъти.

От една метрика получихме 40 x 8 = 320 метрики само за един компютър. Умножаваме по 100 и получаваме 32 000 вместо 400.

След това дойде Kubernetes. И това все още го влошава, защото много различни услуги могат да бъдат хоствани в Kubernetes. Всяка услуга в Kubernetes се състои от много подове. И всичко това трябва да се следи. Освен това имаме постоянно внедряване на нови версии на вашите услуги. За всяка нова версия трябва да създадете нов времеви ред. В резултат на това броят на времевите редове нараства експоненциално и се сблъскваме с проблема с голям брой времеви редове, който се нарича висока кардиналност. VictoriaMetrics го прави добре в сравнение с други бази данни с времеви редове.

Нека разгледаме по-отблизо високия процент на отлив. Какво причинява висок процент на оттегляне в производството? Тъй като някои значения на етикетите и етикетите непрекъснато се променят.

Например, нека вземем Kubernetes, който има концепцията deployment, т.е. когато бъде пусната нова версия на вашето приложение. По някаква причина разработчиците на Kubernetes решиха да добавят идентификатора на разполагане към етикета.

До какво доведе? До факта, че с всяко ново внедряване всички стари времеви серии се прекъсват и вместо тях започват нови времеви серии с нова стойност на етикета deployment_id. Може да има стотици хиляди и дори милиони такива редове.

Важна характеристика на всичко това е, че общият брой на времевите редове нараства, но броят на динамичните редове, които са активни в момента, за които идват данни, остава постоянен. Това състояние се нарича висока степен на оттегляне.

Основният проблем на високия процент на отлив е да се осигури постоянна скорост на търсене за всички времеви серии за даден набор от етикети за определен интервал от време. Обикновено това е интервалът от време за последния час или последния ден.

Как да решим този проблем? Ето първия вариант. Това е за разделяне на обърнатия индекс на независими времеви части. Тоест, минава някакъв интервал от време, завършваме работата с инвертирания текущ индекс. И създаваме нов обърнат индекс. Минава още един интервал от време, създаваме още един и още един.

И когато вземаме проби от тези обърнати индекси, намираме набор от обърнати индекси, които попадат в дадения интервал. И съответно от там избираме идентификатора на времевия ред.

Това спестява ресурси, защото не се налага да разглеждаме части, които не попадат в дадения интервал. Тоест, обикновено, ако изберем данни за последния час, пропускаме заявки за предишни времеви интервали.

Има и друго решение на този проблем. Това е за съхраняване за всеки ден на отделен списък с идентификатори на времевите серии, които са настъпили през този ден.

Предимството на това решение пред предишното решение е, че не дублираме информация за времеви серии, която не изчезва с времето. Те са постоянни и не се променят.

Недостатъкът е, че такова решение е по-трудно за изпълнение и по-трудно за отстраняване на грешки. И VictoriaMetrics избра това решение. Така се е случило исторически. Това решение също се показва добре в сравнение с предишното. Тъй като това решение не е приложено поради факта, че трябва да дублирате данни във всеки дял за времеви серии, които не се променят, тоест, които не изчезват с времето. VictoriaMetrics беше основно оптимизиран за потребление на дисково пространство, а предишното внедряване влоши потреблението на дисково пространство. Но тази реализация е по-подходяща за минимизиране на потреблението на дисково пространство, така че беше избрана.

Трябваше да се бия с нея. Борбата беше, че при това изпълнение все още трябва да изберете много по-голямо число timeseries_ids за данни, отколкото когато обърнатият индекс е разделен на време.

Как решихме този проблем? Решихме го по оригинален начин - чрез съхраняване на няколко идентификатора на времеви серии във всеки запис на инвертирания индекс вместо един идентификатор. т.е. имаме ключа label=value, което се среща във всеки времеви ред. И сега спестяваме няколко timeseries_ids в един запис.

Ето един пример. Преди имахме N записа, а сега имаме един запис, който има същия префикс като всички останали. За предишния запис стойността съдържа всички идентификатори на времевия ред.

Това позволи да се увеличи скоростта на сканиране на такъв обърнат индекс до 10 пъти. И позволява да се намали потреблението на памет за кеша, защото сега съхраняваме низа label=value само веднъж в кеша заедно N пъти. И този ред може да бъде голям, ако имате дълги редове, съхранени в тагове и етикети, които Kubernetes обича да пъха там.

Друг вариант за ускоряване на търсенето на обърнат индекс е шардинг. Създаване на няколко обърнати индекса вместо един и разделяне на данни между тях по ключ. Това е комплект key=value пара. Тоест получаваме няколко независими обърнати индекса, които можем да анкетираме паралелно на няколко процесора. Предишни реализации позволяваха само еднопроцесорен режим, т.е. сканиране на данни само на едно ядро. Това решение ви позволява да сканирате данни на няколко ядра наведнъж, както обича да прави ClickHouse. Това планираме да реализираме.

И сега обратно към нашите овни - към функцията на пресичане timeseries_ids. Нека да разгледаме какви реализации могат да бъдат. Тази функция ви позволява да намерите timeseries_ids за даден набор label=value.

Първият вариант е наивно изпълнение. Два вложени цикъла. Тук стигаме до входа на функцията intersectInts две филийки - a и b. На изхода трябва да ни върне пресечната точка на тези резени.

Наивното изпълнение изглежда така. Ние итерираме всички стойности от среза a, вътре в този цикъл преминаваме през всички стойности на slice b. И ги сравняваме. Ако съвпадат, значи сме намерили пресечна точка. И го запазете в result.

Какви са недостатъците? Квадратната сложност е основният му недостатък. Например, ако имате размери на среза a и b по един милион, тогава тази функция никога няма да ви върне отговор. Защото ще трябва да направи един трилион итерации, което е много дори за съвременните компютри.

Второто изпълнение е базирано на карта. Създаваме карта. Поставяме всички стойности от среза в тази карта a. След това преминаваме през отделен цикъл през парче b. И проверете дали тази стойност е от срез b в картата. Ако съществува, добавете го към резултата.

Какви са предимствата? Предимството е, че има само линейна сложност. Това означава, че функцията ще се изпълни много по-бързо за големи парчета. За един милионен срез тази функция ще се изпълнява в 2 милиона итерации, за разлика от трилион итерации, както в предишната функция.

А недостатъкът е, че тази функция изисква повече памет, за да създаде тази карта.

Вторият недостатък е голямото натоварване за хеширане. Този недостатък не е много очевиден. И за нас също не беше много очевидно, така че първоначално във VictoriaMetrics внедряването на пресичането беше чрез карта. Но след това профилирането показа, че времето на основния процесор се изразходва за писане на картата и проверка за наличие на стойност в тази карта.

Защо тези места губят процесорно време? Тъй като в тези редове Go извършва хешираща операция. Тоест, той изчислява хеша от ключа, за да има достъп до него по-късно при дадения индекс в HashMap. Операцията за изчисляване на хеш отнема десетки наносекунди. Това е бавно за VictoriaMetrics.

Реших да внедря битсет, оптимизиран специално за този случай. Ето как изглежда пресечната точка на двата среза сега. Тук създаваме битсет. Към него добавяме елементи от първия срез. След това проверяваме наличието на тези елементи във втория срез. И ги добавете към резултата. Тоест почти не се различава от предишния пример. Единственото нещо е, че сме заменили извикването за картографиране с персонализирани функции тук add и has.

На пръв поглед изглежда, че това трябва да работи по-бавно, ако стандартната карта е била използвана там преди и след това се извикват някои други функции, но профилирането показва, че това нещо е 10 пъти по-бързо от стандартната карта за случая на VictoriaMetrics.

В допълнение, той използва много по-малко памет в сравнение с внедряването на картата. Защото тук съхраняваме битове вместо осембайтови стойности.

Недостатъкът на такова изпълнение е, че не е толкова очевидно, не е тривиално.

Друг недостатък, който мнозина може да не забележат, е, че тази реализация може да не работи добре в някои случаи. Тоест, той е оптимизиран за конкретен случай, за този случай на пресичане на идентификатори на времевия ред на VictoriaMetrics. Това не означава, че е подходящ за всички случаи. Ако се използва неправилно, тогава ще получим не увеличение на производителността, а грешка при липса на памет и забавяне на производителността.

Помислете за изпълнението на тази структура. Ако искате да го видите, той е в източниците на VictoriaMetrics, в папката lib/uint64set. Той е оптимизиран специално за случая на VictoriaMetrics, където timeseries_id е 64-битова стойност, където първите 32 бита са основно постоянни и само последните 32 бита се променят.

Тази структура от данни не се съхранява на диск, тя работи само в паметта.

Ето неговия API. Не е много сложно. API е пригоден специално за конкретния случай на използване на VictoriaMetrics. Тоест, няма допълнителни функции. Ето функциите, които изрично се използват от VictoriaMetrics.

Има функции add, което добавя нови стойности. Има функция has, който проверява за нови стойности. И има функция del, който премахва стойности. Има помощна функция len, който връща размера на набора. функция clone клонира комплекта. И функция appendto преобразува този набор в срез timeseries_ids.

Ето как изглежда изпълнението на тази структура от данни. Комплектът се състои от два елемента:

• ItemsCount е помощно поле за бързо връщане на броя на елементите в набора. Можехме да се справим и без това спомагателно поле, но трябваше да го добавим тук, защото VictoriaMetrics често разпитва дължината на bitset в своите алгоритми.

• Второто поле е 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 идентификационната стойност също и в бита на среза bitmask. Това е маска за тази 64-битова стойност, чрез която можете да проверите за наличието на този бит или да го зададете. Проверяваме дали този бит е зададен и го настройваме и връщаме присъствието. Ето нашата реализация, която ни позволи да ускорим операцията по пресичане на идентификатори на времеви серии с 10 пъти в сравнение с конвенционалните карти.

В допълнение към тази оптимизация, VictoriaMetrics има много други оптимизации. Повечето от тези оптимизации бяха добавени с причина, но след профилиране на кода в производството.

Това е основното правило на оптимизацията - не добавяйте оптимизация, предполагайки, че ще има тясно място, защото може да се окаже, че няма да има тясно място. Оптимизацията обикновено влошава качеството на кода. Следователно си струва да се оптимизира само след профилиране и за предпочитане в производството, така че това да са реални данни. За тези, които се интересуват, можете да разгледате изходния код на VictoriaMetrics и да разгледате други оптимизации, които са там.

Имам въпрос относно bitset. Много подобен на C++ изпълнението на векторен bool, оптимизиран за bitset. От там ли взехте внедряването?

Не, не от там. Когато внедрявах този битсет, бях ръководен от познанията за структурата на тези времеви серии на идентификатори, които се използват във VictoriaMetrics. И тяхната структура е такава, че първите 32 бита са основно постоянни. Долните 32 бита подлежат на промяна. Колкото по-нисък е битът, толкова по-често може да се променя. Следователно тази реализация е оптимизирана за тази структура от данни. Реализацията на C++, доколкото знам, е оптимизирана за общия случай. Ако правите оптимизация за общия случай, това означава, че тя няма да е най-оптималната за конкретен случай.

Съветвам ви да погледнете доклада на Алексей Миловид. Преди около месец той говори за оптимизации в ClickHouse за конкретни специализации. Той просто казва, че в общия случай изпълнението на C ++ или някакво друго изпълнение е пригодено за добра работа средно в болница. Може да работи по-лошо от специализирана реализация за специфични знания, като нашата, когато знаем, че горните 32 бита са предимно постоянни.

Имам втори въпрос. Каква е фундаменталната разлика от InfluxDB?

Има много кардинални разлики. Що се отнася до производителността и консумацията на памет, тогава InfluxDB в тестовете показва 10 пъти повече консумация на памет за времеви серии с висока кардиналност, когато имате много от тях, например милиони. Например VictoriaMetrics консумира 1 GB на милион активни редове, докато InfluxDB консумира 10 GB. И това е голяма разлика.

Втората кардинална разлика е, че InfluxDB има странни езици за заявки - Flux и InfluxQL. Те не са много удобни за работа с времеви редове в сравнение с PromQL, който се поддържа от VictoriaMetrics. PromQL е език за заявки от Prometheus.

Друга разлика е, че InfluxDB има малко странен модел на данни, където всеки ред може да съхранява няколко полета с различен набор от тагове. Тези редове са допълнително разделени на всички видове таблици. Тези допълнителни усложнения усложняват последващата работа с тази база. Трудно е да се поддържа и разбира.

Във VictoriaMetrics всичко е много по-просто. Там всеки времеви ред е ключ-стойност. Стойността е набор от точки − (timestamp, value), а ключът е комплектът label=value. Няма разделение между полета и измервания. Това ви позволява да изберете всякакви данни и след това да ги комбинирате, добавяте, изваждате, умножавате, разделяте, за разлика от InfluxDB, където изчисленията между различни редове все още не се изпълняват, доколкото знам. Дори и да се приложи, е трудно, трябва да напишете куп код.

Имам един уточняващ въпрос. Правилно разбрах, че има някакъв проблем, за който говорихте, че този обърнат индекс не се побира в паметта, така че там се извършва разделяне?

Първо, показах наивна реализация на обърнат индекс върху стандартна карта на Go. Тази реализация не е подходяща за бази данни, защото този обърнат индекс не се записва на диск, а базата данни трябва да се записва на диск, така че тези данни да останат достъпни при рестартиране. При тази реализация, когато рестартирате приложението, вашият обърнат индекс ще изчезне. И ще загубите достъп до всички данни, защото няма да можете да ги намерите.

Здравейте! Благодаря за доклада! Казвам се Павел. Аз съм от Wildberries. Имам няколко въпроса към вас. Въпрос първи. Смятате ли, че ако бяхте избрали различен принцип при изграждането на архитектурата на приложението си и бяхте разделили данните по време, тогава може би бихте могли да направите пресичането на данни при търсене, въз основа само на факта, че един дял съдържа данни за един период от време, т.е. в един интервал от време и няма да се притеснявате от факта, че фигурите ви са разпръснати по различен начин? Въпрос номер 2 - тъй като прилагате подобен алгоритъм с bitset и всичко останало, тогава може би сте опитали да използвате инструкции на процесора? Може би сте опитвали такива оптимизации?

Ще отговоря на второто. Още не сме стигнали. Но ако трябва, ще го направим. Какъв беше първият въпрос?

Вие обсъдихте два сценария. И казаха, че са избрали втория с по-сложно изпълнение. И не предпочетоха първия, където данните са разделени по време.

да В първия случай общият обем на индекса ще бъде по-голям, тъй като във всеки дял ще трябва да съхраняваме дублирани данни за онези времеви серии, които продължават през всички тези дялове. И ако имате малък процент на оттегляне за времеви серии, тоест едни и същи серии се използват постоянно, тогава в първия случай ще загубим много повече по отношение на заето дисково пространство в сравнение с втория случай.

И така - да, разделянето по време е добър вариант. Прометей го използва. Но Prometheus има друг недостатък. Когато обединява тези части от данни, трябва да запази в паметта мета-информация за всички етикети и времеви серии. Следователно, ако частите от данни са големи, които обединява, тогава консумацията на памет нараства много силно при обединяването, за разлика от VictoriaMetrics. При сливане VictoriaMetrics изобщо не консумира памет, там се консумират няколко килобайта, независимо от размера на частите от данни, които се сливат.

Алгоритъмът, който имате, използва памет. Той маркира времеви серии - марки, които имат стойности. И по този начин проверявате наличието на двойки в един масив от данни и в друг. И вие разбирате дали пресичането се е случило или не. Обикновено базите данни прилагат курсори, итератори, които съхраняват текущата си стойност и преминават през сортирани данни, поради простата сложност на тези операции.

Защо не използваме курсори за обхождане на данни?

Да.

В нашия LevelDB или в mergeset се съхраняват само сортирани редове. Можем да вървим с курсора и да намерим пресечката. Защо не го използваме? Защото е бавно. Тъй като курсорите предполагат, че трябва да извикате функция за всеки ред. Извикването на функция е 5 наносекунди. И ако имате 100 000 000 реда, тогава се оказва, че отделяме половин секунда само за извикване на функция.

Има такова нещо, да. И последният ми въпрос. Въпросът може да прозвучи малко странно. Защо по време на пристигането на данните е невъзможно да се преброят всички необходими агрегати и да се запазят в необходимата форма? Защо да спестявате огромни обеми в някои системи като VictoriaMetrics, ClickHouse и др., за да отделите много време за тях по-късно?

Ще дам пример, за да стане по-ясно. Да кажем как работи малка играчка скоростомер? Той записва разстоянието, което сте изминали, като през цялото време го добавя към една стойност, към втори път. И разделя. И получава средна скорост. Можете да направите почти същото. Добавете всички необходими факти в движение.

Добре, разбирам въпроса. Вашият пример има къде да живее. Ако знаете какви агрегати имате нужда, тогава това е най-доброто изпълнение. Но проблемът е, че хората запазват тези показатели, някои данни в ClickHouse, и все още не знаят как ще ги агрегират и филтрират в бъдеще, така че трябва да запазите всички необработени данни. Но ако знаете, че трябва да изчислите нещо, тогава защо не го изчислите, вместо да съхранявате куп необработени стойности там? Но това е само ако знаете точно от какво имате нужда.

Между другото, базите данни за съхраняване на времеви редове поддържат преброяване на агрегати. Например Prometheus поддържа правила за запис. Тоест, може да се направи, ако знаете какви единици са ви необходими. Това все още не е налично във VictoriaMetrics, но обикновено се предхожда от Prometheus, в който можете да направите това в правилата за прекодиране.

Например, в предишна работа трябваше да преброите броя на събитията в плъзгащ се прозорец през последния час. Проблемът е, че трябваше да направя персонализирана имплементация в Go, т.е. услуга за отчитане на това нещо. Тази услуга в крайна сметка беше нетривиална, защото е трудно да се преброи. Изпълнението може да бъде просто, ако трябва да преброите някои агрегати на фиксирани интервали от време. Ако искате да преброите събития в плъзгащ се прозорец, това не е толкова лесно, колкото изглежда. Мисля, че това все още не е приложено в ClickHouse или в бази данни с времеви серии, защото е трудно за прилагане.

И още един въпрос. Тъкмо говорехме за осредняване и си спомних, че някога имаше такова нещо като Graphite с Carbon бекенд. И той знаеше как да изтъни старите данни, т.е. да остави една точка на минута, една точка на час и т.н. По принцип това е доста удобно, ако имаме нужда от сурови данни, сравнително казано, за един месец, а всичко останало може да бъде изтънено навън Но Prometheus, VictoriaMetrics не поддържат тази функционалност. Планира ли се да бъде подкрепено? Ако не, защо не?

благодаря за въпроса Нашите потребители го задават периодично. Те питат кога ще добавим поддръжка за изтъняване (намаляване). Тук има няколко проблема. Първо, всеки потребител разбира downsampling нещо свое: някой иска да получи произволна точка на даден интервал, някой иска максималните, минималните, средните стойности. Ако много системи записват данни във вашата база данни, тогава не можете да ги редите еднакво за всички. Може да откриете, че трябва да използвате различно децимиране за всяка система. И е трудно за изпълнение.

И второто нещо е, че VictoriaMetrics, подобно на ClickHouse, е оптимизиран за работа с голямо количество необработени данни, така че може да премине през милиард редове за по-малко от секунда, ако имате много ядра в системата си. Точково сканиране на времеви серии във VictoriaMetrics - 50 000 000 точки в секунда на ядро. И тази производителност се мащабира до наличните ядра. Тоест, ако имате 20 ядра например, ще сканирате милиард точки в секунда. И това свойство на VictoriaMetrics и ClickHouse намалява необходимостта от понижаване.

Друго предимство е, че VictoriaMetrics компресира тези данни ефективно. Средната компресия за производство е от 0,4 до 0,8 байта на точка. Всяка точка е клеймо за време + стойност. И компресира средно по-малко от един байт.

Сергей. Имам въпрос. Какъв е минималният отрязък от време за запис?

Една милисекунда. Наскоро имахме разговор с други разработчици на бази данни за времеви серии. Минималното им време е една секунда. И в Graphite например също е една секунда. OpenTSDB също има една втора. В InfluxDB, наносекунда точност. VictoriaMetrics има една милисекунда, защото Prometheus има една милисекунда. А VictoriaMetrics първоначално е разработена като отдалечено хранилище за Prometheus. Но сега може да запазва данни и от други системи.

Човекът, с когото говорих, казва, че имат втора точност - това им е достатъчно, защото зависи от вида на данните, които се съхраняват в базата данни с времеви редове. Ако това са данни от DevOps или данни от инфраструктурата, където ги събирате на интервали от 30 секунди на минута, тогава има достатъчно секундна точност, не ви трябва по-малко. И ако събирате тези данни от високочестотни системи за търговия, тогава имате нужда от наносекунда точност.

Точността от милисекунди във VictoriaMetrics също е подходяща за случай на DevOps и може да бъде подходяща за повечето случаи, които споменах в началото на доклада. Единственото нещо, за което може да не е подходящо, са високочестотните системи за търговия.

Благодаря ти! И още един въпрос. Какво е съвместимост в PromQL?

Пълна обратна съвместимост. VictoriaMetrics напълно поддържа PromQL. В допълнение, той добавя още една разширена функционалност към PromQL, която се нарича MetricsQL. В YouTube се говори за тази разширена функционалност. Говорих на Monitoring Meetup през пролетта в Санкт Петербург.

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

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Какво ви пречи да преминете към VictoriaMetrics като дългосрочно хранилище за Prometheus? (Напишете в коментарите, ще добавя към анкетата))

• 71,4%Не използва Prometheus5

• 28,6%Не знаех за VictoriaMetrics2

7 потребители гласуваха. 12 потребители се въздържаха.

Източник: www.habr.com