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

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

Може да изглежда, че през 2019-та година статията относно избора на TSDB ще се състои само от едно изречение: "просто използвайте ClickHouse". Но... има детайли.

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

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

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

Преди всичко – необходимо предисловие. Защо изобщо ни е собствена система за мониторинг и как я устроихме?

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

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

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

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

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

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

Странно, но по това време идеалното решение за нас бе MySQL. Нашата структура на данни беше изключително проста: id на сървъра, id на метъра, timestamp и стойност; бързото извличане на активни данни се осигуряваше от голям размер на буфериращия пул, а извличането на исторически данни — от 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 метрики на сървър. Тук сървърът е просто виртуална същност — просто за да разберем, че, например, 10 000 метрики отговарят на приблизително 80 сървъра.

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

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

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

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

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

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