Kui kasutate aegridade andmebaasi (aegridad db, ) kui statistikaga saidi põhimälu, siis võib probleemi lahendamise asemel hoopis peavalu saada. Töötan projekti kallal, mis kasutab sellist andmebaasi ja mõnikord esitas InfluxDB, millest juttu tuleb, üldiselt ootamatuid üllatusi.
KaebusedMärkus. Kuvatud probleemid puudutavad InfluxDB 1.7.4.
Miks aegread?
Projekti eesmärk on jälgida tehinguid erinevates plokiahelates ja kuvada statistikat. Täpsemalt vaatleme stabiilsete müntide emissiooni ja põlemist (). Nende tehingute põhjal peate koostama graafikud ja kuvama pivot-tabeleid.
Tehinguid analüüsides tekkis mõte: kasutada põhimäluna InfluxDB aegridade andmebaasi. Tehingud on ajapunktid ja sobivad hästi aegrea mudelisse.
Agregeerimisfunktsioonid tundusid samuti väga mugavad - need sobivad ideaalselt pika perioodiga diagrammide töötlemiseks. Kasutajal on vaja aasta diagrammi ja andmebaasis on andmekogum, mille ajavahemik on viis minutit. Kõiki sada tuhat punkti on mõttetu talle saata – peale pika töötlemise need ei mahu ekraanile. Saate ajakava pikendamiseks ise kirjutada või kasutada Influxi sisseehitatud koondamisfunktsioone. Nende abiga saate andmeid rühmitada päevade kaupa ja saata soovitud 365 punkti.
Natuke piinlik oli, et selliseid andmebaase tavaliselt kasutatakse mõõdikute kogumiseks. Serverite, iot-seadmete, kõige muu jälgimine, millest “vooguvad” miljonid punktid: [<aeg> - <meetriline väärtus>]. Aga kui andmebaas töötab hästi suure andmevooga, siis miks peaks väike maht probleeme tekitama? Selle mõttega võtsid nad InfluxDB tööle.
Mis veel on InfluxDB-s mugav
Lisaks mainitud liitmisfunktsioonidele on veel üks suurepärane asi - pidevad päringud (). See on andmebaasi sisseehitatud planeerija, mis suudab andmeid ajakava alusel töödelda. Näiteks saate grupeerida kõik päeva rekordid iga 24 tunni järel, arvutada keskmise ja kirjutada ühe uue punkti teise tabelisse ilma oma rattaid kirjutamata.
On olemas ka säilitamispoliitika () - seadistus andmete kustutamiseks pärast teatud perioodi. See on kasulik, kui on vaja näiteks nädalaks CPU-le koormust salvestada mõõtmistega kord sekundis, kuid paari kuu kaugusel pole sellist täpsust vaja. Sellises olukorras saate teha järgmist.
- luua pidev päring andmete koondamiseks teise tabelisse;
- esimese tabeli jaoks määrake poliitika sama nädala vanemate mõõdikute kustutamiseks.
Ja Influx vähendab andmete suurust ja kustutab mittevajalikud andmed ise.
Teave salvestatud andmete kohta
Andmeid ei salvestata palju: umbes 70 tuhat tehingut ja veel miljon punkti turuinfoga. Uute kirjete lisamine - mitte rohkem kui 3000 punkti päevas. Saidil on ka mõõdikud, kuid seal on vähe andmeid ja säilitamispoliitika kohaselt ei säilitata neid kauem kui kuu.
Probleemid
Teenuse arendamise ja hilisema testimise käigus tekkis InfluxDB töös üha kriitilisemaid probleeme.
1. Andmete kustutamine
Tehingute kohta on rida andmeid:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Tulemus:
Saadan käsu andmete kustutamiseks:
DELETE FROM transactions WHERE symbol=’USDT’Lisaks taotlen juba kustutatud andmete saamist. Ja Influx tagastab tühja vastuse asemel andmed, mis tuleks eemaldada.
Proovin kustutada kogu tabeli:
DROP MEASUREMENT transactionsKontrollin tabeli kustutamist:
SHOW MEASUREMENTSMa ei näe loendis tabelit, kuid uus andmepäring tagastab endiselt sama tehingute komplekti.
Probleem tekkis minu jaoks vaid korra, kuna kustutamise juhtum on üksikjuhtum. Kuid selline andmebaasi käitumine ei mahu selgelt "õige" töö raamidesse. Hiljem leiti github avatuna peaaegu aastane sellel teemal.
Selle tulemusena aitas kogu andmebaasi eemaldamine ja hilisem taastamine.
2. Ujukomanumbrid
InfluxDB sisseehitatud funktsioone kasutavad matemaatilised arvutused annavad täpsusvigu. Mitte et see midagi ebatavalist oleks olnud, aga ebameeldiv.
Minu puhul on andmetel finantskomponent ja ma tahaksin neid suure täpsusega töödelda. Seetõttu plaanime pidevatest päringutest loobuda.
3. Pidevaid päringuid ei saa kohandada erinevatele ajavöönditele
Teenuses on tabel igapäevase tehingustatistikaga. Iga päeva kohta peate rühmitama kõik selle päeva tehingud. Kuid iga kasutaja päev algab erineval ajal, seetõttu on tehingute komplekt erinev. UTC on vahetused, mille kohta soovite andmeid koondada.
InfluxDB-s saate aja järgi rühmitamisel lisaks määrata nihke, näiteks Moskva aja jaoks (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Kuid päringu tulemus on vale. Mingil põhjusel algavad päevade kaupa rühmitatud andmed juba 1677. aastast (InfluxDB toetab ametlikult ajavahemikku sellest aastast):
Sellest probleemist möödahiilimiseks viidi teenus ajutiselt üle UTC + 0-le.
4. Esitus
Internetis on palju võrdlusaluseid InfluxDB ja teiste andmebaaside võrdlustega. Esmapilgul tundusid need nagu turundusmaterjalid, kuid nüüd arvan, et neis on tõtt.
Las ma räägin teile oma juhtumist.
Teenus pakub API-meetodit, mis tagastab viimase XNUMX tunni statistika. Arvutuste käigus küsib meetod andmebaasist kolm korda järgmiste päringutega:
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 DESCSelgitus:
- Esimeses päringus saame iga mündi eest uusimad punktid koos turuandmetega. Minu puhul kaheksa punkti kaheksa mündi kohta.
- Teine taotlus saab ühe uusima punkti.
- Kolmas küsib viimase XNUMX tunni tehingute nimekirja, neid võib olla mitusada.
Lubage mul selgitada, et InfluxDB-s koostatakse indeks automaatselt siltide ja aja järgi, mis kiirendab päringuid. Esimeses palves sümbol on silt.
Tegin selle API meetodi jaoks stressitesti. 25 RPS-i korral näitas server kuue protsessori täiskoormust:
Samal ajal ei andnud NodeJ-protsess üldse koormust.
Täitmise kiirus langes juba 7-10 RPS võrra: kui üks klient sai vastuse 200 ms jooksul, siis 10 klienti pidid sekundi ootama. 25 RPS - piir, millest kannatas stabiilsus, klientidele tagastati 500 viga.
Sellise jõudlusega on Influxi meie projektis võimatu kasutada. Veelgi enam, projektis, kus monitooringut tuleb paljudele klientidele demonstreerida, võivad ilmneda sarnased probleemid ja mõõdikuserver on ülekoormatud.
Väljund
Kõige olulisem järeldus saadud kogemusest on see, et ilma piisava analüüsita ei saa projekti võtta tundmatut tehnoloogiat. Githubis avatud piletite lihtne sõelumine võib anda teavet, et mitte võtta InfluxDB-d peamise andmehoidlana.
InfluxDB pidi minu projekti ülesannetega hästi sobima, kuid nagu praktika on näidanud, ei vasta see andmebaas vajadustele ja ajab palju sassi.
Projektihoidlast leiab juba versiooni 2.0.0-beeta, jääb üle loota, et teises versioonis tehakse olulisi täiustusi. Vahepeal lähen uurin TimescaleDB dokumentatsiooni.
Allikas: www.habr.com