За апошнія некалькі гадоў базы дадзеных часавых шэрагаў (Time-series databases) ператварыліся з дзіўнай штукі (вузкаспецыялізавана прымяняецца альбо ў адкрытых сістэмах маніторынгу (і прывязанай да канкрэтных рашэнняў), альбо ў Big Data праектах) у "тавар народнага спажывання". На тэрыторыі РФ асобнае дзякуй за гэта трэба сказаць Яндэксу і ClickHouse'у. Да гэтага моманту, калі вам было неабходна захаваць вялікую колькасць time-series дадзеных, прыходзілася або змірыцца з неабходнасцю падняць монструозны Hadoop-стэк і суправаджаць яго, або мець зносіны з пратаколамі, індывідуальнымі для кожнай сістэмы.
Можа здацца, што ў 2019-м годзе артыкул пра тое, якую TSDB варта выкарыстоўваць, будзе складацца толькі з адной прапановы: "проста выкарыстоўвайце ClickHouse". Але… ёсць нюансы.
Сапраўды, ClickHouse актыўна развіваецца, карыстацкая база расце, а падтрымка вядзецца вельмі актыўна, але ці не сталі мы закладнікамі публічнай паспяховасці ClickHouse'а, якая засланіла іншыя, магчыма, больш эфектыўныя/надзейныя рашэнні?
У пачатку мінулага года мы заняліся перапрацоўкай нашай уласнай сістэмы маніторынгу, у працэсе якой паўстала пытанне аб выбары прыдатнай базы для захоўвання дадзеных. Пра гісторыю гэтага выбару я і хачу тут расказаць.
Пастаноўка задачы
Перш за ўсё - неабходная прадмова. Навошта нам увогуле ўласная сістэма маніторынгу і як яна была ўладкованая?
Мы пачалі аказваць паслугі падтрымкі ў 2008 годзе, і да 2010-га стала зразумела, што агрэгаваць дадзеныя аб адбывалых у кліенцкай інфраструктуры працэсах рашэннямі, якія існавалі на той момант, стала складана (мы кажам пра, прабач божа, Cacti, Zabbix-е і зараджаецца Graphite).
Асноўнымі нашымі патрабаваннямі былі:
- суправаджэнне (на той момант - дзясяткаў, а ў перспектыве - сотняў) кліентаў у межах адной сістэмы і пры гэтым наяўнасць цэнтралізаванай сістэмы кіравання абвесткамі;
- гнуткасць у кіраванні сістэмай абвестак (эскалацыя абвестак паміж дзяжурнымі, улік раскладу, база ведаў);
- магчымасць глыбокай дэталізацыі графікаў (Zabbix на той момант адмалёўваў графікі ў выглядзе карцінак);
- працяглае захоўванне вялікай колькасці дадзеных (год і больш) і магчымасць іх хуткай выбаркі.
У дадзеным артыкуле нас цікавіць апошні пункт.
Гаворачы аб сховішчы, патрабаванні былі наступныя:
- сістэма павінна хутка працаваць;
- пажадана, каб сістэма мела SQL-інтэрфейс;
- сістэма павінна быць стабільнай і мець актыўную карыстацкую базу і падтрымку (калісьці мы сутыкнуліся з неабходнасцю падтрымліваць такія сістэмы, як напрыклад MemcacheDB, якую перасталі развіваць, ці размеркаванае сховішча MooseFS, багтрэкер якога вёўся на кітайскай мове: паўторы гэтай гісторыі для свайго праекту нам не хацелася);
- адпаведнасць CAP-тэарэме: Consitency (неабходна) - дадзеныя павінны быць актуальнымі, мы не жадаем, каб сістэма кіравання абвесткамі не атрымала новых дадзеных і плюнулася алертамі аб непрыходзе дадзеных па ўсіх праектах; Partition Tolerance (неабходна) - мы не жадаем атрымаць Split Brain сістэмы; Availability (не крытычна, у выпадку існавання актыўнай рэплікі) - можам самі пераключыцца на рэзервовую сістэму ў выпадку аварыі, кодам.
Як ні дзіўна, на той момант ідэальным рашэннем для нас аказаўся MySQL. Наша структура дадзеных была вельмі простая: id сервера, id лічыльніка, timestamp і значэнне; хуткая выбарка гарачых дадзеных забяспечвалася вялікім памерам buffer pool, а выбарка гістарычных дадзеных - SSD.
Такім чынам, мы дабіліся выбаркі свежых двухтыднёвых дадзеных, з дэталізацыяй да секунды за 200 мс да моманту поўнай адмалёўкі дадзеных, і жылі ў гэтай сістэме даволі доўга.
Між тым, час ішоў і колькасць звестак расла. Да 2016-га года аб'ёмы дадзеных дасягалі дзясяткаў тэрабайт, што ва ўмовах арандуюцца SSD-сховішчаў было істотным выдаткам.
Да гэтага моманту актыўны распаўсюд атрымалі калоначныя базы дадзеных, пра якія мы сталі актыўна думаць: у калонкавых БД дадзеныя захоўваюцца, як гэта можна зразумець, калонкамі, і калі паглядзець на нашы дадзеныя, то лёгка ўбачыць вялікую колькасць дубляў, якія можна было б, у выпадку выкарыстанні калоначнай БД, сціснуць кампрэсіяй.
Аднак ключавая для працы кампаніі сістэма працягвала працаваць стабільна, і эксперыментаваць з пераходам на нешта іншае не хацелася.
У 2017-м годзе на канферэнцыі Percona Live у Сан-Хасэ, напэўна, упершыню аб сабе заявілі распрацоўшчыкі Clickhouse. На першы погляд, сістэма была production-ready (ну, Яндекс.Метрика - гэта суровы прадакшн), падтрымка была хуткай і простай, і, галоўнае, эксплуатацыя была простай. З 2018-га года мы задумалі працэс пераходу. Але да таго часу дарослых і правераных часам сістэм TSDB стала шмат, і мы вырашылі вылучыць значны час і параўнаць альтэрнатывы, для таго каб пераканацца, што альтэрнатыўных Clickhouse-у рашэнняў, паводле нашых патрабаванняў, няма.
У дадатку да ўжо ўказаных патрабаванняў да сховішча з'явіліся свежыя:
- новая сістэма павінна забяспечваць, прынамсі, такую ж прадукцыйнасць, што і MySQL, на той жа самай колькасці жалеза;
- сховішча новай сістэмы павінна займаць значна менш месцы;
- СКБД па-ранейшаму павінна быць простай у кіраванні;
- хацелася мінімальна мяняць прыкладанне пры змене СКБД.
Якія сістэмы мы сталі разглядаць
Apache Hive/Apache Impala
Стары правераны баямі Hadoop-стэк. Па сутнасці, гэта SQL-інтэрфейс, пабудаваны па-над захоўваннем дадзеных ва ўласных фарматах на HDFS.
Плюсы.
- Пры стабільнай эксплуатацыі вельмі проста маштабаваць дадзеныя.
- Ёсць калоначныя рашэнні па захоўванні дадзеных (менш месца).
- Вельмі хуткае выкананне распаралеленых задач пры наяўнасці рэсурсаў.
Мінусы.
- Гэта Hadoop, і ён складзены ў эксплуатацыі. Калі мы не гатовыя браць гатовае рашэнне ў воблаку (а мы не гатовыя па кошце), увесь стэк давядзецца збіраць і падтрымліваць рукамі адмінаў, а гэтага вельмі не хочацца.
- Дадзеныя агрэгуюцца .
аднак:
Хуткасць дасягаецца маштабаваннем колькасці вылічальных сервераў. Прасцей кажучы, калі мы вялікая кампанія, займаемся аналітыкай і бізнэсу крытычна важна максімальна хутка агрэгаваць інфармацыю (хай нават коштам выкарыстання вялікай колькасці вылічальных рэсурсаў), - гэта можа быць нашым выбарам. Але мы не былі гатовы кратна павялічваць парк жалеза для хуткасці выканання задач.
Druid/Pinot
Ужо значна больш пра менавіта TSDB, аднак ізноў жа – Hadoop-стэк.
Ёсць .
Калі ў некалькіх словах: Druid/Pinot выглядаюць лепш Clickhouse'а ў выпадках, калі:
- У вас гетэрагенны характар дадзеных (у нашым выпадку мы запісваем толькі таймсерыі серверных метрык, і, па сутнасці, гэта адна табліца. Але могуць быць і іншыя кейсы: часовыя шэрагі абсталявання, эканамічныя часовыя шэрагі і г.д. — кожны са сваёй структурай, якія трэба агрэгаваць і апрацоўваць).
- Пры гэтым гэтых звестак вельмі шмат.
- Табліцы і дадзеныя з часовымі шэрагамі з'яўляюцца і знікаюць (гэта значыць нейкі набор дадзеных прыйшоў, яго прааналізавалі і выдалілі).
- Няма дакладнага крытэра, па якім дадзеныя могуць быць партыцыянаваны.
У супрацьлеглых выпадках лепш сябе паказвае ClickHouse, а гэта наш выпадак.
ClickHouse
- SQL-like.
- Просты ва ўпраўленні.
- Людзі гавораць, што ён працуе.
Пападае ў шорт-ліст тэставання.
InfluxDB
Замежная альтэрнатыва ClickHouse'у. З мінусаў: High Availability прысутнічае толькі ў камерцыйнай версіі, але трэба параўнаць.
Пападае ў шорт-ліст тэставання.
Касандра
З аднаго боку, мы ведаем, што яе выкарыстоўваюць для захоўвання метрычных таймсерый такія сістэмы маніторынгу, як, напрыклад, ці OkMeter. Аднак ёсць спецыфіка.
Cassandra не з'яўляецца калоначнай базай дадзеных у звыклым яе разуменні. Выглядае яна больш як маленькая, але ў кожным радку можа быць розная колькасць слупкоў, за кошт чаго лёгка арганізаваць калонкавы паказ. У гэтым сэнсе зразумела, што пры абмежаванні ў 2 мільярды слупкоў можна захоўваць нейкія дадзеныя менавіта ў слупках (ды тыя ж часовыя шэрагі). Напрыклад, у MySQL варта абмежаванне на 4096 слупкоў і тамака лёгка натыкнуцца на памылку з кодам 1117, калі паспрабаваць зрабіць тое ж самае.
Рухавічок Cassandra арыентаваны на захоўванне вялікіх аб'ёмаў дадзеных у размеркаванай сістэме без майстра, і ў вышэйзгаданай CAP-тэарэме Cassandra больш пра AP, гэта значыць пра даступнасць дадзеных і ўстойлівасць да падзелу партыцый. Такім чынам, гэтая прылада можа выдатна падысці, калі трэба толькі пісаць у гэтую базу і досыць рэдка з яе чытаць. І тут лагічна выкарыстоўваць Cassandra у якасці "халоднага" сховішчы. Гэта значыць, у якасці доўгачасовага надзейнага месца захоўвання вялікіх масіваў гістарычных дадзеных, якія рэдка патрабуюцца, але пры неабходнасці іх можна дастаць. Тым не менш, дзеля паўнаты карціны, пратэстуем і яе. Але, як я раней казаў, няма жадання актыўна перапісваць код пад абранае БД-рашэнне, таму тэставаць мы яе будзем некалькі абмежавана без адаптацыі структуры базы пад спецыфіку Cassandra.
Праметэй
Ну, і ўжо з цікавасці мы вырашылі пратэставаць прадукцыйнасць вартаўніка Prometheus - проста для таго, каб зразумець, хутчэй мы бягучых рашэнняў або павольней і наколькі.
Методыка і вынікі тэсціравання
Такім чынам, мы пратэставалі 5 баз дадзеных у наступных 6 канфігурацыях: ClickHouse (1 нода), ClickHouse (размеркаваная табліца на 3 ноды), InfluxDB, Mysql 8, Cassandra (3 ноды) і Prometheus. План тэсціравання такі:
- заліваем гістарычныя дадзеныя за тыдзень (840 млн значэнняў у суткі; 208 тысяч метрык);
- генеруемы нагрузку на запіс (разглядалі 6 рэжымаў нагрузкі, гл. ніжэй);
- паралельна з запісам перыядычна які робіцца выбаркі, эмулюючы запыты карыстача, які працуе з графікамі. Каб не занадта ўскладняць, выбіралі дадзеныя па 10 метрыках (як раз столькі іх на графіцы CPU) за тыдзень.
Нагружаем, эмулюючы паводзіны агента нашага маніторынгу, які адпраўляе ў кожную метрыку значэння раз у 15 секунд. Пры гэтым нам цікава вар'іраваць:
- агульная колькасць метрык, у якія пішуцца дадзеныя;
- інтэрвал адпраўкі значэнняў у адну метрыку;
- памер батча.
Пра памер батча. Паколькі амаль усе нашы паддоследныя базы не рэкамендуецца нагружаць адзінкавымі інсэртамі, нам патрэбен будзе рэляў, які збірае прыходныя метрыкі і групуе іх па колькі-небудзь і піша ў базу пакетным інсертам.
Таксама, каб лепш разумець, як потым інтэрпрэтаваць атрыманыя дадзеныя, уявім, што мы не проста шлем кучу метрык, а метрыкі арганізаваны ў серверы - па 125 метрык на сервер. Тут сервер проста віртуальная сутнасць - проста каб разумець, што, напрыклад, 10000 метрык адпавядаюць прыкладна 80 серверам.
І вось, з улікам гэтага ўсяго, нашы 6 рэжымаў нагрузкі базы на запіс:
Тут ёсць два моманты. Па-першае, для касандры такія памеры батчоў апынуліся занадта вялікімі, тамака мы выкарыстоўвалі значэнні 50 ці 100. А па-другое, паколькі прометеус працуе строга ў рэжыме pull, г.зн. сам ходзіць і забірае дадзеныя з крыніц метрык (і нават pushgateway, нягледзячы на назву, у корані сітуацыю не мяняе), адпаведныя нагрузкі былі рэалізаваны з дапамогай камбінацыі static configs.
Вынікі тэсціравання такія:
Што варта адзначыць: фантастычна хуткія выбаркі з Prometheus'a, жудасна павольныя выбаркі з Cassandra, непрымальна павольныя выбаркі з InfluxDB; па хуткасці запісу ўсіх перамог ClickHouse, а Prometheus у конкурсе не ўдзельнічае, таму што ён робіць інсерты сам унутры сябе і мы нічога не замяраем.
У выніку: лепш за ўсіх сябе паказалі ClickHouse і InfluxDB, але кластар з Influx'а можна пабудаваць толькі на аснове Enterprise-версіі, якая каштуе грошай, а ClickHouse нічога не варта і зроблены ў Расіі. Лагічна, што ў ЗША выбар, мабыць, на карысць inInfluxDB, а ў нас – на карысць ClickHouse'а.
Крыніца: habr.com