Ако користите базу података временских серија (тимесериес дб, ) као главно складиште за сајт са статистиком, онда уместо решавања проблема можете добити много главобоље. Радим на пројекту који користи такву базу података, а понекад ИнфлукДБ, о чему ће бити речи, представља потпуно неочекивана изненађења.
Одрицање од одговорности: Наведени проблеми се односе на ИнфлукДБ верзију 1.7.4.
Зашто временске серије?
Пројекат је да прати трансакције на различитим блок-чејновима и приказује статистику. Конкретно, посматрамо емисију и сагоревање стабилних кованица (). На основу ових трансакција, потребно је да направите графиконе и прикажете збирне табеле.
Док смо анализирали трансакције, дошла је идеја: користити базу података временских серија ИнфлукДБ као главно складиште. Трансакције су тачке у времену и добро се уклапају у модел временске серије.
Функције агрегације су такође изгледале веома згодно - идеално за обраду графикона са дугим периодом. Кориснику је потребан графикон за годину дана, а база података садржи скуп података са временским оквиром од пет минута. Бесмислено је слати му свих сто хиљада тачака - осим дуге обраде, неће стати ни на екран. Можете написати сопствену имплементацију повећања временског оквира или користити функције агрегације уграђене у Инфлук. Уз њихову помоћ можете груписати податке по данима и послати потребних 365 поена.
Било је мало збуњујуће што се такве базе података обично користе у сврху прикупљања метрике. Надгледање сервера, иот уређаја, свега из чега „теку” милиони тачака облика: [<време> - <метричка вредност>]. Али ако база података добро функционише са великим протоком података, зашто би онда мали волумен стварао проблеме? Имајући ово на уму, узели смо ИнфлукДБ на посао.
Шта је још згодно у ИнфлукДБ-у
Осим поменутих функција агрегације, постоји још једна сјајна ствар - континуирани упити (). Ово је планер уграђен у базу података који може да обрађује податке по распореду. На пример, свака 24 сата можете груписати све записе за дан, израчунати просек и забележити једну нову тачку у другој табели без писања сопствених бицикала.
Такође је политике задржавања ()—подешавање брисања података након одређеног периода. Корисно је када, на пример, морате да ускладиштите оптерећење ЦПУ-а недељу дана са мерењима једном у секунди, али на удаљености од неколико месеци таква тачност није потребна. У таквој ситуацији можете урадити следеће:
- креирајте непрекидан упит за агрегирање података у другу табелу;
- за прву табелу дефинишите политику за брисање показатеља који су старији од исте недеље.
А Инфлук ће самостално смањити величину података и избрисати непотребне ствари.
О сачуваним подацима
Не чува се много података: око 70 хиљада трансакција и још милион тачака са тржишним информацијама. Додавање нових уноса - не више од 3000 поена дневно. Постоје и метрике за сајт, али тамо има мало података и, према политици задржавања, они се чувају не више од месец дана.
Проблеми
Током развоја и накнадног тестирања сервиса, све више критичних проблема настајало је у раду ИнфлукДБ-а.
1. Брисање података
Постоји низ података са трансакцијама:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Резултат:
Шаљем команду за брисање података:
DELETE FROM transactions WHERE symbol=’USDT’Затим постављам захтев да добијем већ избрисане податке. И уместо празног одговора, Инфлук враћа део података које треба избрисати.
Покушавам да избришем целу табелу:
DROP MEASUREMENT transactionsПроверавам брисање табеле:
SHOW MEASUREMENTSНе видим табелу на листи, али нови упит података и даље враћа исти скуп трансакција.
Проблем ми се јавио само једном, пошто је случај брисања био изолован случај. Али овакво понашање базе података очигледно се не уклапа у оквир „исправног“ рада. Касније сам га нашао отворен на гитхубу пре скоро годину дана на ову тему.
Као резултат тога, помогло је брисање, а затим враћање целе базе података.
2. Бројеви са покретним зарезом
Математичка израчунавања када се користе уграђене функције у ИнфлукДБ-у имају грешке у тачности. Није да је ово нешто необично, али је непријатно.
У мом случају, подаци имају финансијску компоненту и желео бих да их обрадим са великом прецизношћу. Због тога планирамо да напустимо непрекидне упите.
3. Континуирани упити се не могу прилагодити различитим временским зонама
Услуга има табелу са дневном статистиком трансакција. За сваки дан морате груписати све трансакције за тај дан. Али дан сваког корисника почиње у различито време, па ће стога скуп трансакција бити другачији. До УТЦ да смене за које треба да агрегирате податке.
У ИнфлукДБ-у, када групишете по времену, можете додатно навести смену, на пример за московско време (УТЦ+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Али резултат упита ће бити нетачан. Из неког разлога, подаци групирани по данима почеће све до 1677. (ИнфлукДБ званично подржава временски период од ове године):
Да бисмо заобишли овај проблем, привремено смо пребацили услугу на УТЦ+0.
4. Перформансе
На Интернету постоји много мерила која упоређују ИнфлукДБ и друге базе података. На први поглед су изгледали као маркетиншки материјали, али сада мислим да у њима има истине.
Рећи ћу вам свој случај.
Услуга пружа АПИ метод који враћа статистику за последњи дан. Приликом израчунавања, метода три пута испитује базу података са следећим упитима:
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 сата, може их бити неколико стотина.
Дозволите ми да појасним да ИнфлукДБ аутоматски гради индекс на основу ознака и времена, што убрзава упите. У првом захтеву симбол је ознака.
Извршио сам стрес тест за ову АПИ методу. За 25 РПС, сервер је показао пуно оптерећење од шест ЦПУ-а:
У исто време, НодеЈс процес уопште није обезбедио никакво оптерећење.
Брзина извршавања је већ смањена за 7-10 РПС: ако је један клијент могао да добије одговор за 200 мс, онда је 10 клијената морало да чека секунду. 25 РПС је граница на којој је стабилност претрпела; 500 грешака је враћено клијентима.
Са таквим перформансама немогуће је користити Инфлук у нашем пројекту. Штавише: у пројекту где праћење треба да се демонстрира многим клијентима, могу се појавити слични проблеми и сервер метрике ће бити преоптерећен.
Излаз
Најважнији закључак из стеченог искуства је да непознату технологију не можете узети у пројекат без довољне анализе. Једноставан преглед отворених проблема на гитхуб-у могао би да пружи информације да се избегне одабир ИнфлукДБ-а као главног складишта података.
ИнфлукДБ је требало да одговара задацима мог пројекта, али као што је пракса показала, ова база података не задовољава потребе и има много грешака.
Верзију 2.0.0-бета већ можете пронаћи у репозиторијуму пројекта; можемо само да се надамо да ће друга верзија имати значајна побољшања. У међувремену ћу проучити ТимесцалеДБ документацију.
Извор: ввв.хабр.цом