Ако користите база на податоци за временски серии (временска серија db, ) како главно складирање за сајт со статистика, тогаш наместо да го решите проблемот, може да добиете многу главоболки. Работам на проект кој користи таква база на податоци, а понекогаш и InfluxDB, за кој ќе се дискутира, претставуваше сосема неочекувани изненадувања.
Општи услови: Наведените проблеми се однесуваат на верзијата 1.7.4 на InfluxDB.
Зошто временски серии?
Проектот е да ги следи трансакциите на различни блокчејн и да прикажува статистика. Поточно, гледаме на емисијата и согорувањето на стабилните монети (). Врз основа на овие трансакции, треба да изградите графикони и да прикажете збирни табели.
Додека се анализираа трансакциите, се појави идеја: да се користи базата на податоци за временските серии 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 метод што враќа статистика за последниот ден. При извршувањето на пресметките, методот ја бара базата на податоци три пати со следниве прашања:
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-бета во складиштето на проектот; можеме само да се надеваме дека втората верзија ќе има значителни подобрувања. Во меѓувреме, ќе одам да ја проучувам документацијата TimescaleDB.
Извор: www.habr.com