Како тестиравме бази на податоци за повеќе временски серии

Во текот на изминатите неколку години, базите на податоци со временски серии се претворија од чудна работа (високо специјализирана користена или во системи за отворен мониторинг (и врзани за конкретни решенија) или во проекти за големи податоци) во „производ за потрошувачи“. На територијата на Руската Федерација, за ова мора да им се додели посебна благодарност на Yandex и ClickHouse. До овој момент, ако требаше да складирате голема количина на податоци од временски серии, или требаше да се помирите со потребата да изградите чудовишен стек Hadoop и да го одржувате, или да комуницирате со протоколи поединечни за секој систем.

Можеби изгледа дека во 2019 година статија за која вреди да се користи TSDB ќе се состои од само една реченица: „само користете ClickHouse“. Но... има нијанси.

Навистина, ClickHouse активно се развива, базата на корисници расте и поддршката е многу активна, но дали станавме заложници на јавниот успех на ClickHouse, кој ги засени другите, можеби поефикасни/сигурни решенија?

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

Проблем изјава

Пред сè, неопходен предговор. Зошто воопшто ни е потребен сопствен систем за следење и како е дизајниран?

Почнавме да обезбедуваме услуги за поддршка во 2008 година, а до 2010 година стана јасно дека стана тешко да се соберат податоци за процесите што се случуваат во клиентската инфраструктура со решенијата што постоеја во тоа време (зборуваме за, боже прости, кактуси, Zabbix и графитот што се појавува).

Нашите главни барања беа:

• поддршка (во тоа време - десетици, а во иднина - стотици) клиенти во еден систем и во исто време присуство на централизиран систем за управување со предупредувања;
• флексибилност во управувањето со системот за предупредување (ескалација на предупредувања меѓу дежурните службеници, распоред, база на знаење);
• способност за длабоко детализирање на графиконите (Забикс во тоа време ги прикажуваше графиконите во форма на слики);
• долгорочно складирање на голема количина на податоци (една година или повеќе) и можност за брзо враќање.

Во оваа статија ние сме заинтересирани за последната точка.

Зборувајќи за складирање, барањата беа како што следува:

• системот мора да работи брзо;
• пожелно е системот да има SQL интерфејс;
• системот мора да биде стабилен и да има активна корисничка база и поддршка (еднаш се соочивме со потребата да поддржуваме системи како што е MemcacheDB, кој повеќе не беше развиен, или дистрибуираното складирање MooseFS, чијшто трагач за грешки се чуваше на кинески: ја повторуваме оваа приказна за нашиот проект не сакаше);
• усогласеност со теоремата CAP: Конзистентност (задолжително) - податоците мора да бидат ажурирани, не сакаме системот за управување со предупредувања да не прима нови податоци и да плука предупредувања за непристигнување на податоци за сите проекти; Толеранција на партиции (задолжително) - не сакаме да добиеме систем на Сплит Мозок; Достапност (не е критична, ако има активна реплика) - можеме сами да се префрлиме на резервниот систем во случај на несреќа, користејќи код.

Доволно чудно, но во тоа време MySQL се покажа како идеално решение за нас. Нашата структура на податоци беше исклучително едноставна: идентификатор на серверот, бројач, временски печат и вредност; брзото земање примероци на жешките податоци беше обезбедено со голем бафер, а земање примероци од историски податоци беше обезбедено со SSD.

Така, постигнавме примерок од свежи двонеделни податоци, со детали до секунда 200 ms пред податоците да бидат целосно рендерирани и живеевме во овој систем доста долго време.

Во меѓувреме, времето минуваше и количината на податоци растеше. До 2016 година, обемот на податоци достигна десетици терабајти, што беше значителен трошок во контекст на изнајменото складирање на SSD.

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

Сепак, клучниот систем на компанијата продолжи да работи стабилно и не сакав да експериментирам со префрлање на нешто друго.

Во 2017 година, на конференцијата Percona Live во Сан Хозе, програмерите на Clickhouse веројатно се најавија за прв пат. На прв поглед, системот беше подготвен за производство (добро, Yandex.Metrica е суров производствен систем), поддршката беше брза и едноставна, и што е најважно, работата беше едноставна. Од 2018 година го започнавме процесот на транзиција. Но, до тоа време, имаше многу „возрасни“ и временски тестирани TSDB системи, и решивме да посветиме значително време и да ги споредиме алтернативите за да се увериме дека нема алтернативни решенија за Clickhouse, според нашите барања.

Покрај веќе наведените барања за складирање, се појавија и нови:

• новиот систем треба да обезбеди барем исти перформанси како MySQL на иста количина на хардвер;
• складирањето на новиот систем треба да зазема значително помалку простор;
• Со DBMS сè уште мора да биде лесен за управување;
• Сакав минимално да ја сменам апликацијата при промена на DBMS.

Кои системи почнавме да ги разгледуваме?

Apache Hive/Apache Impala
Стар, борбено тестиран Hadoop стек. Во суштина, тоа е SQL интерфејс изграден врз складирање на податоци во мајчин формати на HDFS.

Добрите.

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

Конс

• Тоа е Hadoop, и тешко е да се користи. Ако не сме подготвени да преземеме готово решение во облакот (а не сме подготвени во однос на трошоците), целиот стек ќе треба да се состави и поддржи од рацете на администраторите, а ние навистина не сакаме ова.
• Податоците се собираат навистина брзо.

Сепак:

Брзината се постигнува со скалирање на бројот на компјутерски сервери. Едноставно кажано, ако сме голема компанија, ангажирана во аналитика и од клучно значење е бизнисот да ги собере информациите што е можно побрзо (дури и по цена на користење на голема количина на компјутерски ресурси), ова може да биде наш избор. Но, не бевме подготвени да ја умножиме хардверската флота за да ги забрзаме задачите.

Друид/Пино

Има многу повеќе за TSDB конкретно, но повторно, стекот Hadoop.

Постои одлична статија која ги споредува добрите и лошите страни на Друид и Пино наспроти ClickHouse .

Со неколку зборови: Druid/Pinot изгледаат подобро од Clickhouse во случаи кога:

• Имате хетерогена природа на податоците (во нашиот случај, ние снимаме само временски серии на метрика на серверот и, всушност, ова е една табела. Но, може да има и други случаи: временски серии на опрема, економски временски серии итн. - секој со сопствена структура, која треба да се собере и обработи).
• Покрај тоа, има многу од овие податоци.
• Табелите и податоците со временски серии се појавуваат и исчезнуваат (односно, одреден сет на податоци пристигна, беше анализиран и избришан).
• Не постои јасен критериум според кој податоците може да се поделат.

Во спротивни случаи, ClickHouse работи подобро, и ова е нашиот случај.

Кликни куќа

• Слично на SQL
• Лесно за управување.
• Луѓето велат дека тоа функционира.

Влегува во потесен избор за тестирање.

InfluxDB

Странска алтернатива на ClickHouse. Од минусите: Високата достапност е присутна само во комерцијалната верзија, но треба да се спореди.

Влегува во потесен избор за тестирање.

Касандра

Од една страна, знаеме дека се користи за складирање на метрички временски серии од такви системи за следење како, на пример, SignalFX или OkMeter. Сепак, постојат специфики.

Касандра не е колонообразна база на податоци во традиционална смисла. Изгледа повеќе како приказ на ред, но секоја линија може да има различен број на колони, што го олеснува организирањето на колонообразен приказ. Во оваа смисла, јасно е дека со ограничување од 2 милијарди колони, можно е да се складираат некои податоци во колони (и истите временски серии). На пример, во MySQL има ограничување од 4096 колони и лесно е да се сопнете на грешка со кодот 1117 ако се обидете да го сторите истото.

Моторот на Касандра е фокусиран на складирање на големи количини на податоци во дистрибуиран систем без главен, а гореспоменатата теорема на Касандра CAP е повеќе за AP, односно за достапноста на податоците и отпорноста на партиционирање. Така, оваа алатка може да биде одлична ако треба само да пишувате во оваа база на податоци и ретко да читате од неа. И тука е логично да се користи Касандра како „ладно“ складиште. Односно, како долгорочно, сигурно место за складирање на големи количини историски податоци кои ретко се потребни, но може да се повлечат доколку е потребно. Сепак, заради комплетноста, и ние ќе го тестираме. Но, како што реков претходно, нема желба активно да се препишува кодот за избраното решение за базата на податоци, така што ќе го тестираме малку ограничено - без да ја прилагодиме структурата на базата на податоци на спецификите на Касандра.

Прометеј

Па, од љубопитност, решивме да ги тестираме перформансите на складирањето Prometheus - само за да разбереме дали сме побрзи или побавни од сегашните решенија и за колку.

Методологија и резултати на тестирање

Така, тестиравме 5 бази на податоци во следните 6 конфигурации: ClickHouse (1 јазол), ClickHouse (дистрибуирана табела за 3 јазли), InfluxDB, Mysql 8, Cassandra (3 јазли) и Prometheus. Планот за тестирање е како што следува:

1. поставете историски податоци за една недела (840 милиони вредности дневно; 208 илјади метрика);
2. ние генерираме оптоварување за снимање (6 режими на оптоварување беа разгледани, видете подолу);
3. Паралелно со снимањето, ние периодично правиме селекции, емулирајќи ги барањата на корисникот кој работи со графикони. За да не ги комплицираме работите премногу, избравме податоци за 10 метрики (точно толку има на графикот на процесорот) за една недела.

Вчитуваме со емулирање на однесувањето на нашиот агент за следење, кој испраќа вредности до секоја метрика еднаш на секои 15 секунди. Во исто време, ние сме заинтересирани да варираме:

• вкупниот број на метрики во кои се запишуваат податоците;
• интервал за испраќање вредности до една метрика;
• големина на серијата.

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

Исто така, за подобро да разбереме како потоа да ги толкуваме добиените податоци, да замислиме дека не испраќаме само еден куп метрика, туку метриката е организирана во сервери - 125 метрика по сервер. Овде серверот е едноставно виртуелен ентитет - само за да се разбере дека, на пример, 10000 метрика одговараат на околу 80 сервери.

И тука, земајќи го сето ова предвид, се нашите 6 режими на оптоварување за пишување на базата на податоци:

Тука има две точки. Прво, за Касандра овие големини на серии се покажаа премногу големи, таму користевме вредности од 50 или 100. И второ, бидејќи Прометеј работи строго во режим на повлекување, т.е. самиот оди и собира податоци од извори на метрика (па дури и pushgateway, и покрај името, фундаментално не ја менува ситуацијата), соодветните оптоварувања беа имплементирани со помош на комбинација на статички конфигурации.

Резултатите од тестот се како што следува:

Она што вреди да се забележи: фантастично брзи примероци од Прометеј, ужасно бавни примероци од Касандра, неприфатливо бавни примероци од InfluxDB; Во однос на брзината на снимање, ClickHouse ги освои сите, а Prometheus не учествува на натпреварот, бидејќи сам прави инсерти и ништо не мериме.

Како резултат на тоа,: ClickHouse и InfluxDB се покажаа како најдобри, но кластер од Influx може да се изгради само врз основа на верзијата Enterprise, која чини пари, додека ClickHouse не чини ништо и е направен во Русија. Логично е дека во САД изборот е веројатно во корист на inInfluxDB, а кај нас е во корист на ClickHouse.

Извор: www.habr.com