Ако използвате база данни с времеви серии (timeseries db, ) като основно хранилище за сайт със статистика, тогава вместо да решите проблема, можете да получите много главоболия. Работя по проект, който използва такава база данни и понякога InfluxDB, за която ще стане дума, поднесе като цяло неочаквани изненади.
Отказ от отговорностЗабележка: Показаните проблеми са за InfluxDB 1.7.4.
Защо времеви серии?
Проектът е да проследява транзакциите в различни блокчейни и да показва статистики. По-конкретно, ние разглеждаме емисиите и изгарянето на стабилни монети (). Въз основа на тези транзакции трябва да изградите графики и да покажете осеви таблици.
При анализирането на транзакциите се появи идея: да се използва базата данни с времеви серии InfluxDB като основно хранилище. Транзакциите са точки във времето и се вписват добре в модела на времевия ред.
Функциите за агрегиране също изглеждаха много удобни - те са идеални за обработка на диаграми с дълъг период. Потребителят се нуждае от диаграма за една година, а базата данни съдържа набор от данни с времева рамка от пет минути. Безсмислено е да му изпратите всичките сто хиляди точки - освен при дълга обработка, те няма да се поберат на екрана. Можете да напишете своя собствена реализация за увеличаване на времевата рамка или да използвате функциите за агрегиране, вградени в Influx. С тяхна помощ можете да групирате данните по дни и да изпратите желаните 365 точки.
Беше малко смущаващо, че такива бази данни обикновено се използват за събиране на показатели. Мониторинг на сървъри, iot устройства, всичко, от което “изтичат” милиони точки във формата: [<време> - <метрична стойност>]. Но ако базата данни работи добре с голям поток от данни, защо тогава малък обем трябва да създава проблеми? С тази мисъл те взеха InfluxDB на работа.
Какво друго е удобно в InfluxDB
В допълнение към споменатите функции за агрегиране има още едно страхотно нещо - непрекъснати заявки (). Това е планировчик, вграден в базата данни, който може да обработва данни по график. Например, можете да групирате всички записи за деня на всеки 24 часа, да изчислявате средната стойност и да записвате една нова точка в друга таблица, без да записвате вашите собствени велосипеди.
има и политики за задържане () - настройка за изтриване на данни след определен период. Полезно е, когато например трябва да съхранявате натоварването на процесора за една седмица с измервания веднъж в секунда, но на разстояние от няколко месеца такава точност не е необходима. В такава ситуация можете да направите следното:
- създаване на непрекъсната заявка за агрегиране на данни в друга таблица;
- за първата таблица дефинирайте политика за изтриване на показатели, които са по-стари от същата седмица.
И Influx ще намали размера на данните и ще изтрие ненужните данни сам.
Относно съхранените данни
Не се съхраняват много данни: около 70 хиляди транзакции и още един милион точки с пазарна информация. Добавяне на нови записи - не повече от 3000 точки на ден. Има и показатели за сайта, но там има малко данни и според политиката за съхранение те се съхраняват за не повече от месец.
Проблеми
По време на разработването и последващото тестване на услугата възникват все повече и повече критични проблеми в работата на 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, дават грешки при прецизност. Не че беше нещо необичайно, но неприятно.
В моя случай данните имат финансов компонент и бих искал да ги обработвам с висока точност. Поради това планираме да изоставим непрекъснатите заявки.
3. Непрекъснатите заявки не могат да бъдат адаптирани към различни часови зони
Услугата разполага с таблица с ежедневна статистика на транзакциите. За всеки ден трябва да групирате всички транзакции за този ден. Но денят за всеки потребител ще започне по различно време, следователно наборът от транзакции е различен. UTC е смени, за които искате да обобщите данни.
В InfluxDB, когато групирате по време, можете допълнително да посочите смяна, например за московско време (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Но резултатът от заявката ще бъде неправилен. По някаква причина данните, групирани по дни, ще започнат още през 1677 г. (InfluxDB официално поддържа времеви интервал от тази година):
За да се заобиколи този проблем, услугата беше временно прехвърлена към UTC + 0.
4. Изпълнение
В интернет има много бенчмаркове със сравнения на InfluxDB и други бази данни. На пръв поглед изглеждаха като маркетингови материали, но сега си мисля, че има доза истина в тях.
Нека ви разкажа моя случай.
Услугата предоставя API метод, който връща статистика за последните XNUMX часа. По време на изчисленията методът отправя заявки към базата данни три пъти със следните заявки:
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Обяснение:
- При първата заявка получаваме най-новите точки за всяка монета с пазарни данни. Осем точки за осем монети в моя случай.
- Втората заявка получава една най-нова точка.
- Третият изисква списък с транзакции за последните XNUMX часа, може да има няколкостотин от тях.
Позволете ми да поясня, че в InfluxDB индексът се изгражда автоматично по тагове и по време, което ускорява заявките. В първото искане символ е етикет.
Направих стрес тест за този API метод. За 25 RPS сървърът показа пълно натоварване на шест процесора:
В същото време процесът NodeJs изобщо не даде никакво натоварване.
Скоростта на изпълнение се понижи вече със 7-10 RPS: ако един клиент можеше да получи отговор за 200 ms, тогава 10 клиента трябваше да изчакат секунда. 25 RPS - границата, от която пострада стабилността, 500 грешки бяха върнати на клиентите.
С такава производителност е невъзможно да използваме Influx в нашия проект. Освен това, в проект, където мониторингът трябва да бъде демонстриран на много клиенти, могат да се появят подобни проблеми и сървърът за показатели ще бъде претоварен.
Продукция
Най-важният извод от натрупания опит е, че не можете да включите непозната технология в проект без достатъчно анализ. Един прост скрининг на отворени билети в github може да предостави информация да не приемате InfluxDB като основно хранилище на данни.
InfluxDB трябваше да отговаря добре на задачите на моя проект, но както показа практиката, тази база данни не отговаря на нуждите и бърка много.
Вече можете да намерите версия 2.0.0-beta в хранилището на проекта, остава да се надяваме, че ще има значителни подобрения във втората версия. Междувременно ще отида да проуча документацията на TimescaleDB.
Източник: www.habr.com