Hnev, vyjednávanie a depresia pri práci s InfluxDB

Ak používate databázu časových radov (timeseries db, wiki) ako hlavné úložisko pre stránku so štatistikami, potom namiesto vyriešenia problému môžete dostať veľa bolesti hlavy. Pracujem na projekte, ktorý používa takúto databázu a niekedy InfluxDB, o ktorom bude reč, priniesol úplne nečakané prekvapenia.

Vylúčenie zodpovednosti: Uvedené problémy sa týkajú InfluxDB verzie 1.7.4.

Prečo časové rady?

Projekt má sledovať transakcie na rôznych blockchainoch a zobrazovať štatistiky. Konkrétne sa pozrieme na emisiu a spaľovanie stabilných mincí (wiki). Na základe týchto transakcií musíte zostaviť grafy a zobraziť súhrnné tabuľky.

Pri analýze transakcií prišiel nápad: použiť databázu časových radov InfluxDB ako hlavné úložisko. Transakcie sú body v čase a dobre zapadajú do modelu časového radu.

Veľmi pohodlne vyzerali aj agregačné funkcie – ideálne na spracovanie grafov s dlhou periódou. Používateľ potrebuje graf na rok a databáza obsahuje súbor údajov s časovým rámcom piatich minút. Je zbytočné posielať mu všetkých stotisíc bodov - okrem dlhého spracovania sa nezmestia ani na obrazovku. Môžete si napísať vlastnú implementáciu zvýšenia časového rámca alebo použiť agregačné funkcie zabudované do Influxu. S ich pomocou môžete zoskupiť údaje podľa dní a odoslať požadovaných 365 bodov.

Bolo trochu mätúce, že takéto databázy sa zvyčajne používajú na účely zhromažďovania metrík. Monitoring serverov, iot zariadení, všetkého, z čoho „tečú“ milióny bodov vo forme: [<čas> - <metrická hodnota>]. Ale ak databáza funguje dobre s veľkým tokom údajov, prečo by mal malý objem spôsobovať problémy? S ohľadom na to sme použili InfluxDB do práce.

Čo je ešte výhodné v InfluxDB

Okrem spomínaných agregačných funkcií je tu ešte jedna skvelá vec - nepretržité otázky (doc). Ide o plánovač zabudovaný do databázy, ktorý dokáže spracovávať údaje podľa plánu. Napríklad každých 24 hodín môžete zoskupiť všetky záznamy za daný deň, vypočítať priemer a zaznamenať jeden nový bod do inej tabuľky bez toho, aby ste museli zapisovať vlastné bicykle.

Tiež majú zásady uchovávania (doc)—nastavenie vymazania údajov po určitom čase. Je to užitočné, keď napríklad potrebujete uložiť zaťaženie procesora na týždeň s meraním raz za sekundu, ale na vzdialenosť niekoľkých mesiacov takáto presnosť nie je potrebná. V takejto situácii môžete urobiť toto:

1. vytvoriť súvislý dotaz na agregáciu údajov do inej tabuľky;
2. pre prvú tabuľku definujte politiku na odstraňovanie metrík, ktoré sú staršie ako ten istý týždeň.

A Influx nezávisle zníži veľkosť údajov a odstráni nepotrebné veci.

O uložených údajoch

Nie je uložených veľa údajov: asi 70 tisíc transakcií a ďalší milión bodov s informáciami o trhu. Pridávanie nových záznamov - nie viac ako 3000 bodov za deň. Existujú aj metriky pre stránku, ale tam je málo údajov a podľa politiky uchovávania sa uchovávajú maximálne mesiac.

Problémy

Počas vývoja a následného testovania služby sa pri prevádzke InfluxDB objavovali čoraz kritickejšie problémy.

1. Vymazanie údajov

Existuje séria údajov s transakciami:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

Výsledok:

Posielam príkaz na vymazanie údajov:

DELETE FROM transactions WHERE symbol=’USDT’

Ďalej požiadam o prijatie už vymazaných údajov. A namiesto prázdnej odpovede Influx vráti časť údajov, ktoré by mali byť vymazané.

Snažím sa vymazať celú tabuľku:

DROP MEASUREMENT transactions

Kontrolujem vymazanie tabuľky:

SHOW MEASUREMENTS

Nevidím tabuľku v zozname, ale nový dotaz na údaje stále vracia rovnakú množinu transakcií.

Problém sa mi vyskytol iba raz, keďže prípad vymazania bol ojedinelý prípad. Toto správanie databázy však zjavne nezapadá do rámca „správnej“ prevádzky. Neskôr som to našiel otvorené na githube lístok takmer pred rokom na túto tému.

Vo výsledku pomohlo vymazanie a následné obnovenie celej databázy.

2. Čísla s pohyblivou rádovou čiarkou

Matematické výpočty pri použití vstavaných funkcií v InfluxDB majú chyby presnosti. Nie že by to bolo niečo nezvyčajné, ale je to nepríjemné.

V mojom prípade majú údaje finančnú zložku a rád by som ich spracoval s vysokou presnosťou. Z tohto dôvodu plánujeme opustiť nepretržité dopyty.

3. Nepretržité dopyty nemožno prispôsobiť rôznym časovým pásmam

Služba má tabuľku s dennými štatistikami transakcií. Pre každý deň musíte zoskupiť všetky transakcie pre daný deň. Deň každého používateľa sa však začne v inom čase, a preto bude množina transakcií odlišná. Podľa UTC áno 37 variantov zmeny, pre ktoré potrebujete agregovať údaje.

V InfluxDB pri zoskupovaní podľa času môžete dodatočne určiť posun, napríklad pre moskovský čas (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

Ale výsledok dotazu bude nesprávny. Z nejakého dôvodu začnú údaje zoskupené podľa dňa až do roku 1677 (InfluxDB oficiálne podporuje časové rozpätie od tohto roku):

Aby sme tento problém vyriešili, dočasne sme prepli službu na UTC+0.

4. Výkon

Na internete je veľa benchmarkov, ktoré porovnávajú InfluxDB a iné databázy. Na prvý pohľad vyzerali ako marketingové materiály, no teraz si myslím, že je na nich niečo pravdy.

Poviem ti môj prípad.

Služba poskytuje metódu API, ktorá vracia štatistiky za posledný deň. Pri vykonávaní výpočtov metóda vykoná dotaz na databázu trikrát s nasledujúcimi dotazmi:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

vysvetlenie:

1. V prvej požiadavke získame posledné body za každú mincu s údajmi o trhu. V mojom prípade osem bodov za osem mincí.
2. Druhá žiadosť získa jeden z najnovších bodov.
3. Tretí požaduje zoznam transakcií za posledných XNUMX hodín, ktorých môže byť niekoľko stoviek.

Dovoľte mi objasniť, že InfluxDB automaticky vytvára index na základe značiek a času, čo urýchľuje dopyty. V prvej žiadosti symbol je značka.

Spustil som záťažový test tejto metódy API. Pre 25 RPS server demonštroval plné zaťaženie šiestich CPU:

Proces NodeJs zároveň neposkytoval vôbec žiadnu záťaž.

Rýchlosť vykonávania sa už znížila o 7-10 RPS: ak jeden klient mohol dostať odpoveď za 200 ms, potom 10 klientov muselo čakať sekundu. 25 RPS je hranica, pri ktorej utrpela stabilita, klientom sa vrátilo 500 chýb.

Pri takomto výkone nie je možné použiť Influx v našom projekte. Navyše: v projekte, kde je potrebné demonštrovať monitoring mnohým klientom, sa môžu objaviť podobné problémy a server metrík bude preťažený.

Výkon

Najdôležitejším záverom zo získaných skúseností je, že bez dostatočnej analýzy nemôžete do projektu vziať neznámu technológiu. Jednoduchý skríning otvorených problémov na github by mohol poskytnúť informácie, aby ste sa vyhli výberu InfluxDB ako hlavného úložiska údajov.

InfluxDB by mal byť vhodný pre úlohy môjho projektu, ale ako ukázala prax, táto databáza nezodpovedá potrebám a má veľa chýb.

Verziu 2.0.0-beta už nájdete v úložisku projektu, môžeme len dúfať, že druhá verzia bude mať výrazné vylepšenia. Medzitým si pôjdem preštudovať dokumentáciu TimescaleDB.

Zdroj: hab.com