Калі выкарыстоўваць БД часавых шэрагаў (timeseries db, ) як асноўнае сховішча для сайта са статыстыкай, то замест рашэння задачы можна атрымаць шмат галаўнога болю. Я працую над праектам, дзе выкарыстоўваецца такая база, і часам InfluxDB, аб якой пайдзе прамову, падавала наогул нечаканыя неспадзеўкі.
адмова: прыведзеныя праблемы адносяцца да версіі InfluxDB 1.7.4.
Чаму time series?
Праект заключаецца ў удасканаленьні транзакцый у розных блокчейнах і адлюстраванні статыстыкі. Менавіта - глядзім эмісію і спальванне стэйбл-коінаў (). На аснове гэтых транзакцый трэба будаваць графікі і паказваць зводныя табліцы.
Пры аналізе транзакцый прыйшла ідэя: выкарыстоўваць базу дадзеных часовых шэрагаў InfluxDB як асноўнае сховішча. Транзакцыі з'яўляюцца кропкамі ў часе і ў мадэль часавага шэрагу яны добра ўпісваюцца.
Яшчэ функцыі агрэгацыі выглядалі вельмі зручна - для апрацоўкі графікаў з вялікім перыядам ідэальна падыходзяць. Карыстальніку патрэбен графік за год, а ў базе ляжыць набор даных з таймфрэймам у пяць хвілін. Усе сто тысяч кропак яму адпраўляць бессэнсоўна - акрамя доўгай апрацоўкі, яны і на экране не змесцяцца. Можна напісаць сваю рэалізацыю павелічэння таймфрэйму, альбо скарыстацца ўбудаванымі ў Influx функцыямі агрэгацыі. З іх дапамогай можна згрупаваць дадзеныя па днях і адправіць патрэбныя 365 кропак.
Трохі бянтэжыла тое, што звычайна такія базы выкарыстоўваюць з мэтай збору метрык. Маніторынг сервераў, iot-прылады, усё, з чаго "льюцца" мільёны кропак выгляду: [<час> - <значэнне метрыкі>]. Але калі база добра працуе з вялікай плынню дадзеных, то чаму маленькі аб'ём павінен выклікаць праблемы? З гэтай думкай узялі InfluxDB у працу.
Што яшчэ зручнага ў InfluxDB
Акрамя згаданых функцый агрэгацыі ёсць яшчэ адна выдатная рэч - continuous queries (). Гэта ўбудаваны ў БД планавальнік, які можа апрацоўваць дадзеныя па раскладзе. Напрыклад, можна кожныя 24 гадзіны групаваць усе запісы за дзень, лічыць сярэднюю і запісваць адну новую кропку ў іншую табліцу без напісання ўласных ровараў.
таксама ёсць палітыкі ўтрымання () - настройка выдалення дадзеных пасля нейкага перыяду. Карысна, калі, напрыклад, трэба захоўваць нагрузку на CPU за тыдзень з вымярэннямі раз у секунду, а на дыстанцыі ў пару месяцаў такая дакладнасць не патрэбна. У такой сітуацыі можна зрабіць так:
- стварыць continuous query для агрэгацыі дадзеных у іншую табліцу;
- для першай табліцы вызначыць палітыку выдалення метрык, якія старэйшыя за таго самага тыдня.
І Influx будзе самастойна памяншаць памер дадзеных і выдаляць непатрэбнае.
Аб захоўваемых дадзеных
Звестак захоўваецца не шмат: каля 70 тысяч транзакцый і яшчэ адзін мільён кропак з рыначнай інфармацыяй. Даданне новых запісаў - не больш за 3000 кропак у суткі. Таксама ёсць метрыкі па сайце, але там дадзеных мала і па retention policy яны захоўваюцца не больш за месяц.
Праблемы
У працэсе распрацоўкі і наступнага тэсціравання сэрвісу ўзнікалі ўсё больш і больш крытычныя праблемы пры эксплуатацыі InfluxDB.
1. Выдаленне дадзеных
Ёсць серыя дадзеных з транзакцыямі:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Вынік:
Дасылаю каманду на выдаленне дадзеных:
DELETE FROM transactions WHERE symbol=’USDT’Далей раблю запыт на атрыманне ўжо выдаленых даных. І Influx замест пустога адказу вяртае частку дадзеных, якія павінны быць выдалены.
Спрабую выдаліць табліцу цалкам:
DROP MEASUREMENT transactionsПравяраю выдаленне табліцы:
SHOW MEASUREMENTSТабліцу ў спісе не назіраю, але новы запыт даных усё яшчэ вяртае той жа набор транзакцый.
Праблема ўзнікла ў мяне толькі адзін раз, бо кейс з выдаленнем - адзінкавы выпадак. Але такія паводзіны базы відавочна не ўпісваюцца ў рамкі "карэктнай" працы. Пазней на github знайшоў адчынены амаль гадавой даўнасці на гэтую тэму.
У выніку дапамагло выдаленне і наступнае аднаўленне ўсёй базы.
2. Лікі з якая плавае кропкай
Матэматычныя вылічэнні пры выкарыстанні ўбудаваных у InfluxDB функцый даюць памылкі дакладнасці. Не тое, каб гэта было нечым незвычайным, але непрыемна.
У маім выпадку дадзеныя маюць фінансавы складнік і апрацоўваць іх хацелася б з высокай дакладнасцю. Праз гэта ў планах адмовіцца ад continuous queries.
3. Continuous queries нельга адаптаваць да розных часавых зон
На сервісе ёсць табліца з дзённай статыстыкай па транзакцыях. Для кожнага дня трэба згрупаваць усе транзакцыі за гэтыя суткі. Але дзень у кожнага карыстальніка будзе пачынацца ў розны час, такім чынам і набор транзакцый розны. Па UTC ёсць зруху, для якіх трэба агрэгаваць дадзеныя.
У InfluxDB пры групоўцы па часе можна дадаткова паказаць зрух, напрыклад для маскоўскага часу (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Але вынік запыту будзе некарэктным. Па нейкім чынніку згрупаваныя па днях дадзеныя будуць пачынацца аж у 1677 году (InfluxDB афіцыйна падтрымлівае часавы прамежак ад гэтага года):
Для абыходу гэтай праблемы часова перавялі сэрвіс на UTC+0.
4. Прадукцыйнасць
У інтэрнэце ёсць шмат бенчмаркаў з параўнаннямі InfluxDB і іншых БД. Пры першым азнаямленні яны выглядалі маркетынгавымі матэрыяламі, але зараз лічу, што доля праўды ў іх ёсць.
Раскажу свой кейс.
Сэрвіс дае метад API, які вяртае статыстыку за апошнія суткі. Пры разліках метад запытвае базу тройчы з такімі запытамі:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCТлумачэнне:
- У першым запыце атрымліваем апошнія кропкі для кожнай манеты з дадзенымі па рынку. Восем кропак для васьмі манет у маім выпадку.
- Другі запыт атрымлівае адну самую новую кропку.
- Трэці запытвае спіс транзакцый за апошнія суткі, іх можа быць некалькі соцень.
Удакладню, што ў InfluxDB па тэгах і па часе аўтаматычна будуецца азначнік, які паскарае запыты. У першым запыце сімвал - гэта тэг.
Я правёў стрэс-тэст для гэтага метаду API. Для 25 RPS сервер дэманстраваў поўную загрузку шасці CPU:
Пры гэтым працэс NodeJs зусім не даваў нагрузкі.
Хуткасць выканання дэградавала ўжо на 7/10 RPS: калі адзін кліент мог атрымаць адказ за 200 мс, то 10 кліентаў павінны былі чакаць па секундзе. 25 RPS - мяжа, з якой пакутавала стабільнасць, кліентам вярталіся 500 памылкі.
З такой прадукцыйнасцю выкарыстоўваць Influx у нашым праекце немагчыма. Больш за тое: у праекце, дзе маніторынг трэба дэманстраваць мноству кліентаў – могуць з'явіцца падобныя праблемы і сервер метрык будзе перагружаны.
Выснова
Самая галоўная выснова з атрыманага вопыту - нельга браць у праект невядомую тэхналогію без дастатковага аналізу. Просты скрынінг адчыненых тыкетаў на github мог даць інфармацыю, каб не браць InfluxDB у якасці асноўнага сховішчы дадзеных.
InfluxDB павінна была добра падысці пад задачы майго праекту, але як паказала практыка, гэтая БД не адказвае запатрабаванням і шмат касячыць.
У рэпазітары праекту ўжо можна знайсці версію 2.0.0-beta, застаецца спадзявацца, што ў другой версіі будуць значныя паляпшэнні. А я пакуль пайду вывучаць дакументацыю TimescaleDB.
Крыніца: habr.com