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

През последните няколко години базите данни с времеви серии се превърнаха от необичайно нещо (силно специализирано, използвано или в отворени системи за наблюдение (и обвързани с конкретни решения) или в проекти за големи данни) в „потребителски продукт“. На територията на Руската федерация трябва да благодарим специално на Yandex и ClickHouse за това. До този момент, ако трябваше да съхранявате голямо количество данни от времеви серии, трябваше или да се примирите с необходимостта да изградите чудовищен Hadoop стек и да го поддържате, или да комуникирате с протоколи, индивидуални за всяка система.

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

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

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

Проблем изявление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Професионалистите.

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

Минуси.

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

Но:

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

Друид/Пино

Има много повече за TSDB специално, но отново стека Hadoop.

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

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

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

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

Щракнете върху Къща

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

Попада в краткия списък за тестване.

InfluxDB

Чужда алтернатива на ClickHouse. От минусите: Висока наличност присъства само в търговската версия, но трябва да се сравни.

Попада в краткия списък за тестване.

Касандра

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

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

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

Прометей

Е, от любопитство решихме да тестваме производителността на съхранението на 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 показателя съответстват на около XNUMX сървъра.

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

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

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

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

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

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