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

Представям ви разшифровката на доклада от края на 2019 година на Александър Валялкин "Оптимизации в Go за VictoriaMetrics"

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

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

Слайдове

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

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

Планът на доклада е такъв:

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

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

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

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

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

Както виждате, VictoriaMetrics е бърза база данни, защото не мога да пиша за други. И тя е написана на Go, затова говоря за нея на този митап.

Кой знае какво е времеви ред? И много хора знаят. Времевият ред е серия от двойки (timestamp, стойност), където тези двойки са подредени по време. Стойността представлява число с плаваща запетая – float64.

Всеки времеви ред е уникално идентифициран с ключ. От какво се състои този ключ? Той се състои от непразен набор от двойки ключ-стойност.

Ето пример за времеви ред. Ключът на този ред е списък от двойки: __name__="cpu_usage" – това е името на метриката, instance="my-server" — това е компютърът, на който е събрана тази метрика, datacenter="us-east" — това е датацентърът, където се намира този компютър.

И така, имаме име на времеви ред, състоящо се от три двойки ключ-стойност. На този ключ отговаря списък от двойки (timestamp, стойност). t1, t3, t3, ..., tN — това са времевите печати, 10, 20, 12, ..., 15 — съответстващите стойности. Това е cpu-usage в текущия момент за този ред.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всъщност всичко е просто. Това е просто речник, който съпоставя ключ с значение. Какво е ключ? Тази двойка label=value, където label и стойност — е стринг. А стойностите са набор 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 int-ове. Стрингът съдържа label=value.

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

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

Вторият недостатък също е свързан с паметта. Инвертирания индекс трябва да се помести в оперативната памет. Ако превиши размера на оперативната памет, очевидно ще получим – out of memory error. И програмата няма да работи.

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

Ако накратко, ни е необходима база данни, която позволява бързо извършване на три операции.

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

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

Инвертируем индекс може да бъде реализиран с помощта на LevelDB. Как? Запазваме като ключ label=value. А като стойност - идентификатор на времевия ред, в който присъства двойката label=value.

Ако имаме много времеви редици с тази двойка label=value, ще има много редове в тази база данни с един и същи ключ и различни timeseries_ids. За да получим списък на всички timeseries_ids, които започват с този label=prefix, правим range scan, за който е оптимизирана тази база данни. Т.е. избираме всички редове, които започват с label=prefix и получаваме необходимите timeseries_ids.

Ето един примерен код, как би изглеждал на Go. Имаме инвертиран индекс. Това е LevelDB.

Функцията е същата, както за наивната реализация. Тя почти ред по ред повтаря наивната реализация. Единственото нещо е, че вместо да се обърнем към map , се обръщаме към инвертирания индекс. Получаваме всички стойности за първата label=value. След това преминаваме през всички останали двойки label=value и получаваме съответните набори metricIDs за тях. След това намираме пресечението.

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

Защо? Защото LevelDB е по-бавен от наивната реализация. В наивната реализация по зададен ключ веднага получаваме целия slice metricIDs. Тази операция е много бърза - целият slice е готов за използване.

При LevelDB обаче при всяко извикване на функцията GetValues трябва да преминем през всички редове, които започват с label=value. И за всеки ред да получим стойността timeseries_ids. От тези timeseries_ids събираме slice на тези timeseries_ids. Очевидно е, че това е много по-бавно от просто обръщение към обикновен мап по ключ.

Вторият недостатък е, че LevelDB е написан на C. Обаждането на C функции от Go не е много бързо. Това отнема стотици наносекунди. Не е много бързо, защото в сравнение с обикновеното извикване на функция, написана на Go, която отнема 1-5 наносекунди, разликата в производителността е десетократно. За VictoriaMetrics това беше фатален недостатък 🙂

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

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

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

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

Защо възникнаха?

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

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

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

Но това не е всичко. Всяко ядро на процесора може да има няколко състояния, като idle, когато е в режим на изчакване. Освен това има работа в user space, работа в kernel space и други състояния. И всяко такова състояние също може да бъде измервано като отделна времева серия. Това допълнително увеличава броя на сериите 7-8 пъти.

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

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

Нека разгледаме по-подробно high churn rate. Какво причинява high churn rate на продукция? Защото някои стойности на етикетите и таговете постоянно се променят.

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

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

Важна особеност на всичко това е, че общият брой времеви серии нараства, но броят на времевите серии, които в момента са активни и получават данни, остава постоянен. Такова състояние се нарича – high churn rate.

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

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

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

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

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

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

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

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

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

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

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

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

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

Първият вариант – това е наивната реализация. Два вложени цикъла. Входът на функцията intersectInts са два slices — a и b. На изхода тя трябва да ни върне пресечението на тези slices.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ето как изглежда реализацията на тази структура данни. В сет има два елемента:

ItemsCount – това е помощно поле, за да върнете бързо броя на елементите в сет. Може да се справите и без това помощно поле, но трябваше да го добавим тук, защото VictoriaMetrics често запитва за дължината на bitset в своите алгоритми.
Второто поле е buckets. Това е slice от структурата bucket32. Във всяка структура се съхранява hi поле. Това са горните 32 бита. И два slice — b16his и buckets от bucket16 структури.

Тук се съхраняват горните 16 бита от втората част на 64-битовата структура. А тук се съхраняват bitsets за младшите 16 бита на всеки байт.

Bucket64 се състои от масив uint64. Дължината се изчислява с помощта на тези константи. В един bucket16 максимум може да се съхранява 2^16=65536 бит. Ако го разделим на 8, това е 8 килобайта. Ако го разделим отново на 8, това са 1000 uint64 стойности. Т.е. Bucket16 е 8-килобайтна структура.

Нека разгледаме как е реализиран един от методите на тази структура за добавяне на нова стойност.

Всичко започва с uint64 значения. Изчисляваме горните 32 бита, изчисляваме долните 32 бита. Преминаваме през всички buckets. Сравняваме горните 32 бита в всеки bucket с добавената стойност. И ако те съвпадат, извикваме функцията add в структурата b32 buckets. И добавяме долните 32 бита. И ако това е върнало true, то означава, че сме добавили такава стойност там и такова значение не е имало. Ако тя върне false, то такава стойност вече е имала. След това увеличаваме броя на елементите в структурата.

Ако не сме намерили нужния bucket с нужното hi-значение, то извикваме функцията addAlloc, която заделя нов bucket, добавяйки го в структурата bucket.

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

След това преминаваме през всички горни 16 бита. Намираме съвпадения. И при съвпадение извикваме метода add, който ще разгледаме на следващата страница за bucket16.

И ето най-долното ниво, което трябва да бъде максимално оптимизирано. Изчисляваме за uint64 id стойност в slice bit, а също и bitmask. Това е маска за тази 64-битова стойност, по която можем да проверим наличието на този бит или да го зададем. Проверяваме наличието на този бит, който е зададен, и задаваме го, и връщаме наличието. Ето каква реализация имаме, която е позволила да се ускори операцията на пресичане на ids на временни редици 10 пъти в сравнение с обикновените maps.

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

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

Имам въпрос за bitset. Много наподобява реализацията на C++ vector, оптимизиран bitset. Взели ли сте реализацията от там?

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

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

Имам втори въпрос. В какво е коренното отличие от InfluxDB?

Коренните отличия са много. Ако става въпрос за производителност и потребление на памет, то InfluxDB в тестовете показва 10 пъти повече потребление на памет за high cardinality времеви редове, когато имате много от тях, например милиони. Например, VictoriaMetrics консумира 1 GB на милион активни реда, докато InfluxDB консумира 10 Gb. И това е голяма разлика.

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

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

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

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

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

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

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

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

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

А така – да, партиционирането по време е добър вариант. Той се използва от Prometheus. Но в Prometheus има и друг недостатък. При сливането на тези парчета данни, той трябва да държи в паметта мета-информация за всички label и timeseries. Следователно, ако парчетата данни, които слива, са големи, потреблението на паметта нараства значително по време на сливането, в отличие от VictoriaMetrics. При сливането VictoriaMetrics не потребява никаква памет, там се използват няколко килобайта, независимо от размерите на обединените парчета данни.

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Telegram канал VictoriaMetrics.

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