Как тествахме няколко бази данни с времеви редици

През последните няколко години базите данни за времеви серии (Time-series databases) преминаха от странно явление (с които се работеше само в специфични системи за мониторинг (и свързани с конкретни решения), или в Big Data проекти) до „търговски продукт“. На територията на Русия трябва да благодарим на Яндекс и ClickHouse за това. Преди този момент, ако ви беше необходимо да съхранявате голямо количество времеви серии, се налагаше или да се примирите с необходимостта да разположите монструозен Hadoop стек и да го поддържате, или да работите с индивидуални протоколи за всяка система.

Може да изглежда, че през 2019 година статията за това коя TSDB да се използва ще се състои само от едно изречение: „просто използвайте ClickHouse“. Но… има нюанси.

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

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

Формулиране на задачата

Най-напред—необходимо предисловие. Защо изобщо ни е нужна собствена система за мониторинг и как беше изградена тя?

Започнахме да предлагаме услуги по поддръжка през 2008 година и до 2010 стана ясно, че е трудно да се агрегира информация за процесите, които се случват в клиентската инфраструктура с решенията, които съществуваха тогава (говорим за, прости ни, Cacti, Zabbix и зародишния Graphite).

Основните ни изисквания бяха:

• поддръжка на (тогава — десетки, а в перспектива — стотици) клиенти в рамките на една система и същевременно наличие на централизирана система за управление на известията;
• гъвкавост в управлението на системата за известия (ескалация на известия между дежурни, отчитане на разписания, база знания);
• възможност за дълбочинно визуализиране на графики (Zabbix тогава визуализираше графики като изображения);
• дългосрочно съхранение на голямо количество данни (година и повече) и възможност за бързо извличане.

В тази статия ни интересува последният пункт.

Говорейки за съхранение, изискванията бяха следните:

• системата трябва да работи бързо;
• желателно е системата да има SQL интерфейс;
• системата трябва да бъде стабилна и да има активна потребителска база и поддръжка (някога сме се сблъсквали с необходимостта да поддържаме такива системи като MemcacheDB, която спря да се развива, или разпределеното хранилище MooseFS, чийто багтракър беше на китайски: не искахме повторение на тази история за нашия проект);
• спазване на CAP теоремата: Consistency (необходимо) — данните трябва да бъдат актуални, не искаме системата за управление на уведомленията да не получава нови данни и да изстрелва аларми за неприхода на данни по всички проекти; Partition Tolerance (необходимо) — не искаме да получим Split Brain система; Availability (не критично, в случай че съществува активен реплика) — можем сами да преминем на резервната система в случай на авария, с код.

Както и да е, в този момент идеалното решение за нас се оказа MySQL. Нашата структура на данните беше изключително проста: id на сървъра, id на брояча, timestamp и стойност; бързото извличане на горещи данни се осигуряваше от голям размер на buffer pool, а извличането на исторически данни — от SSD.

По този начин постигнахме извличане на свежи данни от последните две седмици, с детайлност до секунда за 200 мс до момента на пълно визуализиране на данните, и живеехме в тази система доста дълго.

Междувременно, времето минаваше и количеството данни нарастваше. Към 2016 година обемите данни достигнаха десетки терабайта, което в условията на наемани SSD хранилища беше значителен разход.

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

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

През 2017 г. на конференцията Percona Live в Сан Хосе разработчиците на Clickhouse за първи път представиха себе си. На пръв поглед системата беше готова за продукция (все пак, Яндекс.Метрика е суров продакшън), поддръжката беше бърза и лесна, и най-важното, експлоатацията беше проста. От 2018 г. започнахме процеса на преход. Но по това време имаше много "възрастни" и доказани TSDB системи, и решихме да отделим значително време, за да сравним алтернативите и да се уверим, че няма алтернативни решения на Clickhouse, отговарящи на нашите изисквания.

В допълнение към вече посочените изисквания към хранилището се появиха нови:

• новата система трябва да осигурява поне същата производителност като MySQL, на същото количество хардуер;
• хранилището на новата система трябва да заема значително по-малко място;
• СУБД все още трябва да бъде лесна за управление;
• искахме минимално да променяме приложението при смяна на СУБД.

Кои системи започнахме да разглеждаме

Apache Hive/Apache Impala
Стара, проверена платформа с Hadoop. По същество, това е SQL интерфейс, построен върху хранилище на данни в собствени формати на HDFS.

Плюсове.

• При стабилна експлоатация е много лесно да се мащабират данните.
• Има колоночни решения за съхраняване на данни (по-малко място).
• Много бързо изпълнение на паралелизирани задачи при наличие на ресурси.

Недостатъци.

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

Въпреки това:

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

Druid/Pinot

Вече значително повече специфично за TSDB, но отново — стек с Hadoop.

Има Отлична статия, сравняваща плюсовете и минусите на Druid и Pinot в сравнение с ClickHouse. .

Ако в няколко думи: Druid/Pinot изглеждат по-добре от Clickhouse в случаи, когато:

• Имате хетерогенен характер на данните (в нашия случай записваме само времеви серии от сървърни метрики, и всъщност това е една таблица. Но могат да съществуват и други случаи: времеви редове на оборудване, икономически времеви редове и т.н. — всеки със своя структура, която трябва да се агрегира и обработва).
• В същото време тези данни са много.
• Таблиците и данните с времеви редове се появяват и изчезват (т.е. някакъв набор данни идва, анализира се и след това се изтрива).
• Няма ясни критерии, по които данните могат да бъдат партиционирани.

В противоположни случаи ClickHouse показва по-добри резултати, а това е нашият случай.

ClickHouse

• SQL-подобен.
• Лесен за управление.
• Хората казват, че работи.

Попада в шорт-листа за тестване.

InfluxDB

Външна алтернатива на ClickHouse. Недостатъци: High Availability е налична само в търговската версия, но трябва да се сравни.

Попада в шорт-листа за тестване.

Cassandra

От една страна, знаем, че за съхранение на метрики от времеви серии се използват такива системи за мониторинг, като например, SignalFX или OkMeter. Въпреки това, има специфика.

Cassandra не е колоночна база данни в традиционния смисъл. Изглежда по-скоро като редова, но в различни редове може да има различен брой колонки, което позволява лесна организация на колоночен изглед. В това отношение е разбираемо, че при ограничение от 2 милиарда колони може да се съхраняват определени данни именно в колоните (като същите времеви редове). Например, в MySQL има ограничение от 4096 колони и там лесно може да се сблъскате с грешка с код 1117, ако опитате да направите същото.

Двигателят Cassandra е насочен към съхранение на големи количества данни в разпределена система без главен, и в гореспоменатата CAP теория, Cassandra е повече за AP, т.е. за достъпността на данните и устойчивостта на разделение на партициите. Така че този инструмент може да е отлично решение, ако е нужно само да се записва в тази база и сравнително рядко да се чете от нея. Логично е да използваме Cassandra като "студено" хранилище — тоест, като дългосрочно надеждно място за съхранение на големи масиви исторически данни, които рядко се изискват, но могат да бъдат извлечени при нужда. Въпреки това, за пълнота на картината, нека я тестваме и нея. Но, както казах по-рано, нямам желание активно да пренаписвам кода за избраното решение за база данни, така че тестовете ще бъдат ограничени — без адаптиране на структурата на базата под спецификата на Cassandra.

Prometheus

Ами, от интерес решихме да тестваме производителността на хранилището Prometheus — просто за да разберем дали сме по-бързи от текущите решения или по-бавни и в каква степен.

Методология и резултати от тестовете

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

1. въвеждаме исторически данни за седмица (840 млн стойности на ден; 208 хиляди метрики);
2. генерираме натоварване на запис (разглеждаме 6 режима на натоварване, вижте по-долу);
3. паралелно с записите периодично правим извлечения, емулирайки запитвания на потребителя, който работи с графики. За да не усложняваме прекалено много, избирахме данни за 10 метрики (точно толкова са на графика CPU) за седмица.

Натоварваме, емулирайки поведението на агента на нашето наблюдение, който изпраща стойности в всяка метрика на всеки 15 секунди. Интересно ни е да променяме:

• общото количество метрики, в които се записват данни;
• интервалът на изпращане на стойности в една метрика;
• размера на партидата.

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

Също така, за да разберем по-добре как впоследствие да интерпретираме получените данни, да си представим, че не просто изпращаме куп метрики, а метриките са организирани в сървъри — по 125 метрики на сървър. Тук сървърът е просто виртуална същност — просто за да разберем, че, например, 10000 метрики отговарят на приблизително 80 сървъра.

И така, вземайки предвид всичко това, нашите 6 режима на натоварване на базата за запис:

Тук има два момента. Първо, за Cassandra размерите на партидите се оказаха твърде големи, там използвахме стойности от 50 или 100. А второ, тъй като Prometheus работи строго в режим на извличане, т.е. сам идва и взима данни от източниците на метрики (даже pushgateway, въпреки името си, не променя ситуацията), съответните натоварвания бяха реализирани с помощта на комбинация от статични конфигурации.

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

Важно е да се отбележи: фантастично бързи извлечения от Prometheus, ужасно бавни извлечения от Cassandra, неприемливо бавни извлечения от InfluxDB; по скорост на запис ClickHouse победи всички, а Prometheus не участва в конкурса, защото прави вмъквания сам вътре в себе си и ние не измерваме нищо.

В крайна сметка: най-добре се представиха ClickHouse и InfluxDB, но клъстерът на Influx може да бъде построен само на база Enterprise версията, която струва пари, а ClickHouse е безплатен и е създаден в Русия. Логично е, че в САЩ изборът е, вероятно, в полза на InfluxDB, а у нас — в полза на ClickHouse.

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