Hněv, smlouvání a deprese při práci s InfluxDB

Pokud používáte databázi časových řad (timeseries db, wiki) jako hlavní úložiště pro web se statistikami, pak místo řešení problému můžete dostat spoustu bolesti hlavy. Pracuji na projektu, který takovou databázi využívá, a někdy InfluxDB, o kterém bude řeč, představoval obecně nečekaná překvapení.

Odmítnutí odpovědnostiPoznámka: Zobrazené problémy se týkají InfluxDB 1.7.4.

Proč časové řady?

Projekt má sledovat transakce v různých blockchainech a zobrazovat statistiky. Konkrétně se podíváme na emisi a spalování stabilních mincí (wiki). Na základě těchto transakcí musíte sestavit grafy a zobrazit kontingenční tabulky.

Při analýze transakcí přišel nápad: použít databázi časových řad InfluxDB jako hlavní úložiště. Transakce jsou body v čase a dobře zapadají do modelu časové řady.

Velmi pohodlně vypadaly i agregační funkce – jsou ideální pro zpracování grafů s dlouhou periodou. Uživatel potřebuje graf na rok a databáze obsahuje soubor dat s časovým rámcem pět minut. Posílat mu všech sto tisíc bodů je nesmyslné – kromě dlouhého zpracování se na obrazovku nevejdou. Můžete napsat vlastní implementaci zvýšení časového rámce nebo použít agregační funkce zabudované do Influxu. S jejich pomocí můžete seskupit data podle dnů a odeslat požadovaných 365 bodů.

Bylo trochu trapné, že takové databáze se obvykle používají ke sběru metrik. Monitoring serverů, iot zařízení, všeho, z čeho „tečou“ miliony bodů ve tvaru: [<čas> - <metrická hodnota>]. Ale pokud databáze funguje dobře s velkým datovým tokem, proč by měl malý objem způsobovat problémy? S touto myšlenkou vzali InfluxDB do práce.

Co dalšího je v InfluxDB pohodlné

Kromě zmíněných agregačních funkcí je tu ještě jedna skvělá věc - nepřetržité dotazy (doc). Jedná se o plánovač zabudovaný do databáze, který dokáže zpracovávat data podle plánu. Můžete například každých 24 hodin seskupit všechny záznamy za daný den, vypočítat průměr a zapsat jeden nový bod do jiné tabulky, aniž byste museli psát vlastní kola.

je také zásady uchovávání (doc) - nastavení pro mazání dat po určité době. Je to užitečné, když například potřebujete uložit zátěž na CPU na týden s měřením jednou za sekundu, ale taková přesnost není potřeba na vzdálenost několika měsíců. V takové situaci můžete provést toto:

1. vytvořit souvislý dotaz pro agregaci dat do jiné tabulky;
2. pro první tabulku definujte zásady pro mazání metrik, které jsou starší než stejný týden.

A Influx zmenší velikost dat a vymaže nepotřebná data sama.

O uložených datech

Není uloženo mnoho dat: asi 70 tisíc transakcí a další milion bodů s informacemi o trhu. Přidávání nových položek - ne více než 3000 bodů za den. Existují také metriky pro web, ale tam je málo dat a podle zásad uchovávání nejsou uloženy déle než měsíc.

Problémy

Během vývoje a následného testování služby se v provozu InfluxDB objevovaly stále kritičtější problémy.

1. Mazání dat

Existuje řada údajů s transakcemi:

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

Výsledek:

Posílám příkaz k odstranění dat:

DELETE FROM transactions WHERE symbol=’USDT’

Dále žádám o získání již smazaných dat. A Influx místo prázdné odpovědi vrátí část dat, která by měla být odstraněna.

Snažím se smazat celou tabulku:

DROP MEASUREMENT transactions

Kontroluji smazání tabulky:

SHOW MEASUREMENTS

Tabulku v seznamu nevidím, ale nový datový dotaz stále vrací stejnou sadu transakcí.

Problém se mi vyskytl pouze jednou, protože případ smazání je ojedinělý případ. Ale toto chování databáze zjevně nezapadá do rámce "správné" práce. Později byl github nalezen otevřený lístek téměř rok staré na toto téma.

Ve výsledku pomohlo odstranění a následné obnovení celé databáze.

2. Čísla s pohyblivou řádovou čárkou

Matematické výpočty využívající vestavěné funkce InfluxDB poskytují chyby přesnosti. Ne že by to bylo něco neobvyklého, ale nepříjemného.

V mém případě mají data finanční složku a rád bych je zpracoval s vysokou přesností. Z tohoto důvodu plánujeme opustit nepřetržité dotazy.

3. Nepřetržité dotazy nelze přizpůsobit různým časovým pásmům

Služba má tabulku s denními statistikami transakcí. Pro každý den musíte seskupit všechny transakce pro daný den. Den pro každého uživatele však začíná v jinou dobu, a proto je sada transakcí odlišná. UTC je 37 variant směny, pro které chcete agregovat data.

V InfluxDB můžete při seskupování podle času navíc zadat posun, například pro moskevský čas (UTC + 3):

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

Ale výsledek dotazu bude nesprávný. Z nějakého důvodu budou data seskupená podle dne začínat již v roce 1677 (InfluxDB oficiálně podporuje časové rozpětí od tohoto roku):

Aby se tento problém obešel, byla služba dočasně převedena na UTC + 0.

4. Výkon

Na internetu je mnoho benchmarků se srovnáním InfluxDB a dalších databází. Na první pohled vypadaly jako marketingové materiály, ale teď si myslím, že je na nich něco pravdy.

Řeknu vám můj případ.

Služba poskytuje metodu API, která vrací statistiky za posledních XNUMX hodin. Během výpočtů se metoda dotazuje na databázi třikrát s následujícími dotazy:

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

Vysvětlení

1. V první žádosti získáme nejnovější body za každou minci s tržními daty. V mém případě osm teček za osm mincí.
2. Druhá žádost získá jeden nejnovější bod.
3. Třetí požaduje výpis transakcí za posledních XNUMX hodin, může jich být několik stovek.

Dovolte mi objasnit, že v InfluxDB je index automaticky sestavován podle značek a podle času, což urychluje dotazy. V první žádosti symbol je značka.

Pro tuto metodu API jsem provedl zátěžový test. Pro 25 RPS server ukázal plné zatížení šesti CPU:

Zároveň proces NodeJs nedával vůbec žádnou zátěž.

Rychlost provádění se snížila již o 7-10 RPS: pokud jeden klient mohl obdržet odpověď za 200 ms, pak 10 klientů muselo sekundu čekat. 25 RPS - hranice, od které utrpěla stabilita, 500 chyb se vrátilo klientům.

S takovým výkonem je nemožné použít Influx v našem projektu. Navíc v projektu, kde je potřeba předvést monitorování mnoha klientům, se mohou objevit podobné problémy a server metrik bude přetížen.

Výkon

Nejdůležitější závěr ze získaných zkušeností je, že bez dostatečné analýzy nelze do projektu vzít neznámou technologii. Jednoduché prověřování otevřených lístků na githubu by mohlo poskytnout informaci, že InfluxDB není hlavním úložištěm dat.

InfluxDB měl dobře vyhovovat úkolům mého projektu, ale jak ukázala praxe, tato databáze nevyhovuje potřebám a hodně kazí.

Verzi 2.0.0-beta již najdete v repozitáři projektu, nezbývá než doufat, že v druhé verzi dojde k výrazným vylepšením. Mezitím si půjdu prostudovat dokumentaci TimescaleDB.

Zdroj: www.habr.com