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

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

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

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

Слајдови

Кажи ни за себе. Јас сум Александар Ваљалкин. Еве мојата сметка на GitHub. Јас сум страстен за Go и оптимизација на перформансите. Напишав многу корисни и не многу корисни библиотеки. Тие започнуваат со било кое fast, или со quick префикс.

Моментално работам на VictoriaMetrics. Што е тоа и што правам таму? Ќе зборувам за ова во оваа презентација.

Прегледот на извештајот е како што следува:

• Прво, ќе ви кажам што е VictoriaMetrics.
• Потоа ќе ви кажам што се временски серии.
• Потоа ќе ви кажам како функционира базата на податоци со временски серии.
• Следно, ќе ви кажам за архитектурата на базата на податоци: од што се состои.
• А потоа да преминеме на оптимизациите што ги има VictoriaMetrics. Ова е оптимизација за превртен индекс и оптимизација за имплементација на битови во 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, можете да измерите процесор, RAM, мрежа, rps, број на грешки итн.
• IoT - можеме да измериме температура, притисок, геокоординати и нешто друго.
• Исто така финансии - можеме да ги следиме цените за сите видови акции и валути.
• Покрај тоа, временските серии може да се користат за следење на производните процеси во фабриките. Имаме корисници кои користат VictoriaMetrics за следење на турбините на ветер, за роботи.
• Временските серии се исто така корисни за собирање информации од сензори на различни уреди. На пример, за мотор; за мерење на притисокот во гумите; за мерење на брзина, растојание; за мерење на потрошувачката на бензин и сл.
• Временските серии може да се користат и за следење на авионите. Секој авион има црна кутија која собира временски серии за различни параметри на здравјето на авионот. Временските серии се користат и во воздушната индустрија.
• Здравството е крвен притисок, пулс итн.

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

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

Бидејќи временските серии обично содржат голема количина на информации, кои тешко се складираат и обработуваат во конвенционалните бази на податоци. Затоа се појавија специјализирани бази на податоци за временски серии. Овие бази ефикасно складираат поени (timestamp, value) со дадениот клуч. Тие обезбедуваат API за читање зачувани податоци по клуч, со еден пар клуч-вредност или со повеќе парови клуч-вредност или со regexp. На пример, сакате да го пронајдете оптоварувањето на процесорот на сите ваши услуги во центарот за податоци во Америка, тогаш треба да го користите ова псевдо-прашање.

Вообичаено, базите на податоци за временски серии обезбедуваат специјализирани јазици за прашања, бидејќи временските серии SQL не се многу прилагодени. Иако постојат бази на податоци кои поддржуваат SQL, тој не е многу погоден. Јазици за пребарување како што се PromQL, InfluxQL, Флукс, Q. Се надевам дека некој слушнал барем еден од овие јазици. Многу луѓе веројатно слушнале за PromQL. Ова е јазикот на барањето Прометеј.

Вака изгледа архитектурата на базата на податоци со модерна временски серии со користење на 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), што ќе ја мапира низата за да ги исече интите. Линијата содржи label=value.

Имплементација на функцијата: се metricIDs за првиот label=value, потоа поминуваме низ се останато label=value, го разбираме metricIDs за нив. И повикајте ја функцијата intersectInts, за што ќе се дискутира подолу. И оваа функција го враќа пресекот на овие списоци.

Како што можете да видите, спроведувањето на превртен индекс не е многу комплицирано. Но, ова е наивна имплементација. Какви недостатоци има? Главниот недостаток на наивната имплементација е тоа што таков превртен индекс е зачуван во RAM меморија. По рестартирање на апликацијата го губиме овој индекс. Нема зачувување на овој индекс на дискот. Таков превртен индекс веројатно нема да биде соодветен за база на податоци.

Вториот недостаток е исто така поврзан со меморијата. Превртениот индекс мора да се вклопи во RAM меморијата. Ако ја надмине големината на RAM меморијата, тогаш очигледно ќе добиеме грешка - надвор од меморијата. И програмата нема да работи.

Овој проблем може да се реши со помош на готови решенија како на пр LevelDBИли RocksDB.

Накратко, потребна ни е база на податоци што ни овозможува брзо да направиме три операции.

• Првата операција е снимање ключ-значение на оваа база на податоци. Таа го прави тоа многу брзо, каде ключ-значение се произволни жици.
• Втората операција е брзо пребарување на вредност користејќи даден клуч.
• И третата операција е брзо пребарување на сите вредности со даден префикс.

LevelDB и RocksDB - овие бази на податоци беа развиени од Google и Facebook. Прво дојде LevelDB. Потоа момците од Фејсбук го земаа 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 и да ги добиете соодветните множества на metricIDs за нив. Потоа ја наоѓаме раскрсницата.

Се чини дека сè е во ред, но има недостатоци на ова решение. VictoriaMetrics првично имплементираше превртен индекс заснован на LevelDB. Но, на крајот морав да се откажам од тоа.

Зошто? Бидејќи LevelDB е побавен од наивната имплементација. Во наивна имплементација, со даден клуч, веднаш го враќаме целото парче metricIDs. Ова е многу брза операција - целото парче е подготвено за употреба.

Во LevelDB, секој пат кога се повикува функција GetValues треба да ги поминете сите линии што почнуваат со label=value. И добијте ја вредноста за секоја линија timeseries_ids. Од таквите timeseries_ids соберете парче од нив timeseries_ids. Очигледно, ова е многу побавно отколку едноставно пристапување до обична мапа со клуч.

Вториот недостаток е тоа што LevelDB е напишано во C. Повикувањето на функциите C од Go не е многу брзо. Потребни се стотици наносекунди. Ова не е многу брзо, бидејќи во споредба со редовен повик на функција напишан во движење, кој трае 1-5 наносекунди, разликата во перформансите е десетици пати. За VictoriaMetrics ова беше фатален недостаток :)

Така напишав сопствена имплементација на превртениот индекс. И тој и се јави спојување.

Mergeset се базира на структурата на податоци MergeTree. Оваа структура на податоци е позајмена од ClickHouse. Очигледно, mergeset треба да се оптимизира за брзо пребарување timeseries_ids според дадениот клуч. Mergeset е целосно напишан во Go. Можете да видите Извори на VictoriaMetrics на GitHub. Имплементацијата на mergeset е во папката /lib/mergeset. Може да се обидете да сфатите што се случува таму.

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

Подоцна ќе зборуваме за недостатоците на mergeset. Сега да разговараме за тоа какви проблеми се појавија со VictoriaMetrics во производството при спроведување на превртен индекс.

Зошто се појавија?

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

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

Со текот на времето, луѓето сфатија дека можат да измерат повеќе грануларни информации. На пример, измерете го оптоварувањето не на целиот процесор, туку одделно на секое јадро на процесорот. Ако имате 40 процесорски јадра, тогаш имате 40 пати повеќе временски серии за мерење на оптоварувањето на процесорот.

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

Од една метрика добивме 40 x 8 = 320 метрика за само еден компјутер. Помножете се со 100, добиваме 32 наместо 000.

Потоа дојде Кубернетес. И се влоши бидејќи Кубернетс може да биде домаќин на многу различни услуги. Секоја услуга во Кубернетес се состои од многу подлоги. И сето тоа треба да се следи. Покрај тоа, имаме постојано распоредување на нови верзии на вашите услуги. За секоја нова верзија, мора да се креираат нови временски серии. Како резултат на тоа, бројот на временски серии расте експоненцијално и се соочуваме со проблемот на голем број временски серии, кој се нарекува висока кардиналност. VictoriaMetrics успешно се справува со тоа во споредба со другите бази на податоци за временски серии.

Ајде внимателно да ја разгледаме високата стапка на отповикување. Што предизвикува висока стапка на отповикување во производството? Бидејќи некои значења на етикетите и ознаките постојано се менуваат.

На пример, земете го Кубернетес, кој го има концептот deployment, т.е. кога ќе се појави нова верзија на вашата апликација. Поради некоја причина, програмерите на Kubernetes одлучија да го додадат идентификаторот за распоредување на етикетата.

До што доведе ова? Покрај тоа, со секое ново распоредување, сите стари временски серии се прекинуваат, а наместо нив, започнуваат нови временски серии со нова вредност на ознаката deployment_id. Може да има стотици илјади, па дури и милиони такви редови.

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

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

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

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

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

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

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

Недостаток е што ваквото решение е потешко да се имплементира и потешко да се дебагира. И VictoriaMetrics го избра ова решение. Така се случувало историски. Ова решение исто така функционира добро во споредба со претходното. Бидејќи ова решение не беше имплементирано поради фактот што е неопходно да се дуплираат податоци во секоја партиција за временски серии кои не се менуваат, односно кои не исчезнуваат со текот на времето. VictoriaMetrics беше првенствено оптимизирана за потрошувачка на простор на дискот, а претходната имплементација ја влоши потрошувачката на простор на дискот. Но, оваа имплементација е подобро прилагодена за минимизирање на потрошувачката на простор на дискот, па затоа беше избрана.

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

Како го решивме овој проблем? Го решивме на оригинален начин - со зачувување на неколку идентификатори на временски серии во секој запис на превртен индекс наместо еден идентификатор. Тоа е, ние имаме клуч label=value, што се јавува во секоја временска серија. И сега спасуваме неколку timeseries_ids во еден запис.

Еве еден пример. Претходно имавме N записи, но сега имаме еден запис чиј префикс е ист како и сите други. За претходниот запис, вредноста ги содржи идентификаторите на сите временски серии.

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

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

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

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

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

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

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

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

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

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

Зошто се троши времето на процесорот на овие места? Бидејќи 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 често ја бара должината на битови во своите алгоритми.

• Второто поле е 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 со потребната hi-вредност, тогаш ја повикуваме функцијата addAlloc, кој ќе произведе нов bucket, додавајќи го во структурата на корпата.

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

Потоа поминуваме низ сите горни 16 бита. Наоѓаме натпревари. И ако има совпаѓање, го нарекуваме методот за додавање, кој ќе го разгледаме на следната страница bucket16.

И тука е најниското ниво, кое треба да се оптимизира што е можно повеќе. Пресметуваме за uint64 id вредност во парче бит и исто така bitmask. Ова е маска за дадена 64-битна вредност, која може да се користи за да се провери присуството на овој бит или да се постави. Проверуваме дали овој бит е поставен и го поставуваме и враќаме присуство. Ова е нашата имплементација, која ни овозможи да ја забрзаме операцијата на вкрстени идентификатори на временски серии за 10 пати во споредба со конвенционалните карти.

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

Ова е главното правило за оптимизација - не додавајте оптимизација под претпоставка дека ќе има тесно грло овде, бидејќи може да испадне дека таму нема да има тесно грло. Оптимизацијата обично го намалува квалитетот на кодот. Затоа, вреди да се оптимизира само по профилирањето и по можност во производството, така што ова се вистински податоци. Ако некој е заинтересиран, може да го погледне изворниот код на VictoriaMetrics и да истражи други оптимизации што се таму.

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

Не, не од таму. Кога го имплементирав овој бит-сет, бев воден од знаењето за структурата на овие временски серии за идентификација, кои се користат во 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 - бидејќи имплементирате сличен алгоритам со битови и сè друго, тогаш можеби сте се обиделе да користите инструкции за процесорот? Можеби сте пробале такви оптимизации?

Веднаш ќе одговорам на второто. Сè уште не сме стигнале до таа точка. Но, ако треба, ќе стигнеме таму. И првото, кое беше прашањето?

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

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

И така - да, временската партиција е добра опција. Прометеј го користи. Но, Прометеј има уште еден недостаток. Кога се спојуваат овие делови од податоци, треба да се чуваат мета информации во меморијата за сите етикети и временски серии. Затоа, ако деловите од податоците што ги спојува се големи, тогаш потрошувачката на меморија многу се зголемува за време на спојувањето, за разлика од VictoriaMetrics. Кога се спојува, VictoriaMetrics воопшто не троши меморија; се трошат само неколку килобајти, без оглед на големината на споените податоци.

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

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

Да.

Ги складираме подредените редови во LevelDB или mergeset. Можеме да го поместиме курсорот и да го најдеме пресекот. Зошто не го користиме? Затоа што е бавно. Бидејќи курсорите значат дека треба да повикате функција за секоја линија. Повикот на функцијата е 5 наносекунди. И ако имате 100 линии, тогаш излегува дека поминуваме половина секунда само повикувајќи ја функцијата.

Има такво нешто, да. И моето последно прашање. Можеби прашањето звучи малку чудно. Зошто не е можно да се прочитаат сите потребни агрегати во моментот на пристигнување на податоците и да се зачуваат во потребната форма? Зошто да заштедите огромни количини во некои системи како VictoriaMetrics, ClickHouse итн., а потоа да потрошите многу време на нив?

Ќе дадам пример за да биде појасно. Да речеме како работи малиот брзиномер за играчки? Го запишува растојанието што сте го поминале, цело време додавајќи го на една вредност, а втората - времето. И дели. И добива просечна брзина. Можете да го направите истото. Соберете ги сите потребни факти во лет.

Добро, го разбирам прашањето. Вашиот пример има свое место. Ако знаете какви агрегати ви се потребни, тогаш ова е најдобрата имплементација. Но, проблемот е што луѓето ги зачувуваат овие метрики, некои податоци во ClickHouse и сè уште не знаат како ќе ги соберат и филтрираат во иднина, па мора да ги зачуваат сите необработени податоци. Но, ако знаете дека треба да пресметате нешто во просек, тогаш зошто да не го пресметате наместо да складирате куп сурови вредности таму? Но, ова е само ако точно знаете што ви треба.

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

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

И уште едно прашање. Зборувавме само за просекување и се сетив дека некогаш постоеше такво нешто како Графит со карбон заднина. И знаеше да ги истенчи старите податоци, односно да остави една точка во минута, една точка на час итн. Во принцип, ова е сосема погодно ако ни требаат необработени податоци, релативно кажано, за еден месец, а се друго може биде разредена. Но, Prometheus и VictoriaMetrics не ја поддржуваат оваа функционалност. Дали се планира да се поддржи? Ако не, зошто да не?

Фала за прашањето. Нашите корисници периодично го поставуваат ова прашање. Тие прашуваат кога ќе додадеме поддршка за намалување на примерокот. Тука има неколку проблеми. Прво, секој корисник разбира downsampling нешто различно: некој сака да добие произволна точка на даден интервал, некој сака максимални, минимални, просечни вредности. Ако многу системи пишуваат податоци во вашата база на податоци, тогаш не можете да ги соберете сите заедно. Можеби секој систем бара различно разредување. И ова е тешко да се спроведе.

И втората работа е што VictoriaMetrics, како ClickHouse, е оптимизирана за работа со големи количини на необработени податоци, така што може да откопа милијарда линии за помалку од секунда ако имате многу јадра во вашиот систем. Скенирање точки на временски серии во VictoriaMetrics – 50 поени во секунда по јадро. И оваа изведба се скали на постоечките јадра. Односно, ако имате 000 јадра, на пример, ќе скенирате милијарда поени во секунда. И ова својство на VictoriaMetrics и ClickHouse ја намалува потребата за симнување на симнување.

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

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

Една милисекунда. Неодамна имавме разговор со други развивачи на бази на податоци за временски серии. Нивното минимално временско парче е една секунда. И во графитот, на пример, тоа е исто така една секунда. Во OpenTSDB исто така е една секунда. InfluxDB има прецизност од наносекунда. Во Викторија Метрикс е една милисекунда, бидејќи во Прометеј е една милисекунда. И VictoriaMetrics првично беше развиена како далечинско складирање за Prometheus. Но, сега може да зачува податоци од други системи.

Лицето со кое разговарав вели дека има точност од секунда до секунда - тоа е доволно за нив бидејќи зависи од типот на податоците што се складираат во базата на податоци за временски серии. Ако ова се податоци за DevOps или податоци од инфраструктура, каде што ги собирате во интервали од 30 секунди во минута, тогаш е доволна точност од секунда, не ви треба ништо помалку. И ако ги собирате овие податоци од системи за тргување со висока фреквенција, тогаш ви треба точност од наносекунда.

Точноста од милисекунда во VictoriaMetrics е исто така погодна за случајот DevOps и може да биде погодна за повеќето случаи што ги споменав на почетокот на извештајот. Единственото нешто за кое можеби не е погодно се системите за тргување со висока фреквенција.

Ви благодарам! И уште едно прашање. Што е компатибилност во PromQL?

Целосна компатибилност наназад. VictoriaMetrics целосно го поддржува PromQL. Покрај тоа, додава дополнителна напредна функционалност во PromQL, која се нарекува MetricsQL. На YouTube се зборува за оваа проширена функционалност. Зборував на состанокот за мониторинг пролетта во Санкт Петербург.

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

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

Што ве спречува да се префрлите на VictoriaMetrics како ваше долгорочно складирање за Prometheus? (Напишете во коментар, ќе го додадам во анкетата))

• 71,4%Не користам Prometheus5

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

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

Извор: www.habr.com