Ha idősoros adatbázist használ (idősor db, ), mint a fő tárhely egy statisztikát tartalmazó oldalhoz, akkor a probléma megoldása helyett sok fejfájást kaphat. Egy ilyen adatbázist használó projekten dolgozom, és olykor az InfluxDB, amiről szó lesz, teljesen váratlan meglepetéseket hozott.
A felelősség megtagadása: A felsorolt problémák az InfluxDB 1.7.4-es verziójára vonatkoznak.
Miért idősor?
A projekt célja a tranzakciók nyomon követése különböző blokkláncokon és statisztikák megjelenítése. Konkrétan a stabil érmék kibocsátását és elégetését nézzük (). Ezen tranzakciók alapján grafikonokat kell felépítenie és összefoglaló táblázatokat kell megjelenítenie.
A tranzakciók elemzése közben felmerült egy ötlet: az InfluxDB idősor adatbázisát használjuk fő tárolóként. A tranzakciók időpontok, és jól illeszkednek az idősoros modellbe.
Az aggregációs függvények is nagyon kényelmesnek tűntek – ideálisak hosszú periódusú diagramok feldolgozásához. A felhasználónak szüksége van egy évre szóló diagramra, az adatbázisban öt perces időkeretű adatsor található. Felesleges neki küldeni mind a százezer pontot – a hosszú feldolgozástól eltekintve nem is férnek el a képernyőn. Megírhatja saját megvalósítását az időkeret növelésére, vagy használhatja az Influxba beépített összesítő függvényeket. Segítségükkel napok szerint csoportosíthatja az adatokat, és elküldheti a szükséges 365 pontot.
Kicsit zavaró volt, hogy az ilyen adatbázisokat általában mérőszámok gyűjtésére használják. Szerverek, iot eszközök figyelése, minden, ahonnan több millió pont „folyik” formában: [<idő> - <metrikus érték>]. De ha az adatbázis jól működik nagy adatfolyam mellett, akkor miért okozhat problémát egy kis mennyiség? Ezt szem előtt tartva indítottuk el az InfluxDB-t.
Mi más kényelmes az InfluxDB-ben
Az említett aggregációs funkciókon kívül van még egy nagyszerű dolog - folyamatos lekérdezések (). Ez az adatbázisba épített ütemező, amely ütemezett adatokat tud feldolgozni. Például 24 óránként csoportosíthatja a nap összes rekordját, kiszámíthatja az átlagot, és egy új pontot rögzíthet egy másik táblázatban anélkül, hogy saját kerékpárokat írna.
Van még megőrzési politikák () — adattörlés beállítása egy bizonyos idő elteltével. Akkor hasznos, ha például egy hétig kell tárolni a CPU-terhelést, másodpercenként egyszeri méréssel, de néhány hónapos távolságon belül nincs szükség ilyen pontosságra. Ilyen helyzetben a következőket teheti:
- folyamatos lekérdezés létrehozása az adatok egy másik táblába történő összesítéséhez;
- az első táblázathoz határozzon meg egy házirendet az ugyanazon a héten régebbi mutatók törlésére.
Az Influx pedig önállóan csökkenti az adatok méretét, és törli a felesleges dolgokat.
A tárolt adatokról
Nem sok adatot tárolnak: körülbelül 70 ezer tranzakció és további millió pont piaci információkkal. Új bejegyzések hozzáadása - nem több, mint 3000 pont naponta. Az oldalhoz vannak mérőszámok is, de ott kevés az adat, és a megőrzési szabályzat szerint legfeljebb egy hónapig tárolódnak.
Problémák
A szolgáltatás fejlesztése és utólagos tesztelése során egyre több kritikus probléma merült fel az InfluxDB működésében.
1. Adatok törlése
A tranzakciókhoz egy sor adat tartozik:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Eredmény:
Adattörlési parancsot küldök:
DELETE FROM transactions WHERE symbol=’USDT’Ezután kérem a már törölt adatok átvételét. És az üres válasz helyett az Influx visszaadja a törölni kívánt adatok egy részét.
Megpróbálom törölni a teljes táblázatot:
DROP MEASUREMENT transactionsEllenőrzöm a táblázat törlését:
SHOW MEASUREMENTSNem látom a táblát a listában, de egy új adatlekérdezés továbbra is ugyanazt a tranzakciókészletet adja vissza.
A probléma csak egyszer fordult elő, mivel a törlés esete elszigetelt eset volt. De az adatbázisnak ez a viselkedése nyilvánvalóan nem illeszkedik a „helyes” működés keretei közé. Később megnyitva találtam a githubon közel egy éve ebben a témában.
Ennek eredményeként a teljes adatbázis törlése, majd visszaállítása segített.
2. Lebegőpontos számok
Az InfluxDB beépített függvényeinek használatakor a matematikai számítások pontossági hibákat tartalmaznak. Nem mintha ez valami szokatlan lenne, de kellemetlen.
Az én esetemben az adatoknak van egy pénzügyi összetevője, és azt szeretném nagy pontossággal feldolgozni. Emiatt a folyamatos lekérdezések elhagyását tervezzük.
3. A folyamatos lekérdezések nem illeszthetők különböző időzónákhoz
A szolgáltatásnak van egy táblázata a napi tranzakciós statisztikákkal. Minden naphoz csoportosítania kell az adott nap összes tranzakcióját. De minden felhasználó napja más időpontban kezdődik, és ezért a tranzakciók halmaza eltérő lesz. UTC szerint igen műszakok, amelyekhez adatokat kell összesíteni.
Az InfluxDB-ben az idő szerinti csoportosításkor további eltolódást is megadhat, például moszkvai időre (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)De a lekérdezés eredménye helytelen lesz. Valamilyen oknál fogva a napok szerint csoportosított adatok egészen 1677-ig kezdődnek (az InfluxDB hivatalosan egy idei időszakot támogat):
A probléma megkerülésére ideiglenesen átállítottuk a szolgáltatást UTC+0-ra.
4. Teljesítmény
Az interneten számos benchmark található, amelyek összehasonlítják az InfluxDB-t és más adatbázisokat. Első pillantásra marketing anyagoknak tűntek, de most már azt hiszem, van bennük igazság.
Elmondom az esetemet.
A szolgáltatás olyan API-módszert biztosít, amely az utolsó nap statisztikáit adja vissza. Számítások végzésekor a metódus háromszor lekérdezi az adatbázist a következő lekérdezésekkel:
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 DESCMagyarázat:
- Az első kérésben minden egyes érméért az utolsó pontokat kapjuk piaci adatokkal. Nyolc érméért nyolc pont az én esetemben.
- A második kérés az egyik legújabb pontot kapja.
- A harmadik az elmúlt XNUMX óra tranzakcióinak listáját kéri, több száz is lehet.
Hadd tisztázzam, hogy az InfluxDB automatikusan létrehoz egy indexet a címkék és az idő alapján, ami felgyorsítja a lekérdezéseket. Az első kérésben szimbólum egy címke.
Lefuttattam egy stressztesztet ezen az API-módszeren. 25 RPS esetén a szerver hat CPU teljes terhelését mutatta be:
Ugyanakkor a NodeJs folyamat egyáltalán nem biztosított terhelést.
A végrehajtási sebesség már 7-10 RPS-sel leromlott: ha egy kliens 200 ms alatt tudott választ kapni, akkor 10 kliensnek másodpercet kellett várnia. A 25 RPS az a határ, amelynél a stabilitás szenvedett; 500 hiba érkezett vissza az ügyfeleknek.
Ilyen teljesítménnyel lehetetlen az Influxot projektünkben használni. Sőt: egy olyan projektben, ahol a monitorozást sok kliensnek kell bemutatni, hasonló problémák jelentkezhetnek, és a metrika szerver túlterhelődik.
Teljesítmény
A megszerzett tapasztalatok legfontosabb következtetése az, hogy kellő elemzés nélkül nem lehet ismeretlen technológiát bevinni egy projektbe. A nyitott problémák egyszerű átvizsgálása a githubon információkat szolgáltathat annak elkerülésére, hogy az InfluxDB-t válasszuk fő adattárként.
Az InfluxDB-nek jól kellett volna illeszkednie a projektem feladataihoz, de ahogy a gyakorlat azt mutatja, ez az adatbázis nem felel meg az igényeknek, és sok hibát tartalmaz.
A 2.0.0-béta verzió már megtalálható a projekttárban, csak remélni tudjuk, hogy a második verzió jelentős fejlesztéseket fog elérni. Addig is áttanulmányozom a TimescaleDB dokumentációját.
Forrás: will.com