Viha, kauplemine ja depressioon InfluxDB kasutamisel

Kui kasutada ajaseeria andmebaasi (timeseries db, wiki) peamise hoidlana statistika veebisaidi jaoks, siis võib probleemi lahendamise asemel tekkida palju peavalu. Töötab projekti kallal, kus kasutatakse sellist andmebaasi, ja mõnikord on InfluxDB, millest jutt, esitanud täiesti ootamatuid üllatusi.

Märkus: esitatud probleemid puudutavad InfluxDB versiooni 1.7.4.

Miks ajaseeria?

Projekti eesmärk on jälgida tehingute toimumist erinevates plokiahelates ja kuvada statistikat. Konkreetsemalt — vaatame stabiilsete müntide (wiki) emissiooni ja hävitamist. Nende tehingute põhjal on vaja koostada graafikud ja esitada kokkuvõtte tabelid.

Tehingute analüüsimisel tuli mõte: kasutada InfluxDB ajaseeria andmebaasi peamise hoidlana. Tehingud on ajapunktid ja ajaseeria mudelisse sobivad nad hästi.

Samuti olid agregatsiooni funktsioonid väga mugavad — need sobivad ideaalselt pika perioodi graafikute töötlemiseks. Kasutajale on vajalik graafik aasta kohta, kuid andmebaasis on andmekogum viie minuti ajavahemikku. Tuhandeid punkte saatmine on mõttetu — peale pika töötlemise ei mahuks need ka ekraanile. Saab kirjutada oma ajavahemiku suurendamise rakenduse või kasutada Influxis sisseehitatud agregatsiooni funktsioone. Nende abil saab andmed rühmitada päevade kaupa ja saata vajalikud 365 punkti.

Natuke häiris see, et tavaliselt kasutatakse selliseid andmebaase mõõdikute kogumiseks. Serverite jälgimine, IoT-seadmed, kõik, kust tuleb miljoneid punkte vormis: [ — ]. Kuid kui andmebaas töötab hästi suure andmevoo korral, siis miks peaks väiksem maht probleeme põhjustama? Selle mõttega hakkasime InfluxDB-d kasutama.

Mis muud head on InfluxDB-s

Lisaks mainitud agregatsiooni funktsioonidele on veel üks suurepärane asi — jätkuvad päringud (doc). See on andmebaasis sisseehitatud ajakava, mis saab andmeid töödelda vastavalt ajakavale. Näiteks saab iga 24 tunni tagant rühmitada kõik päevased kirjed, arvutada keskmise ja salvestada ühe uue punkti teise tabelisse ilma oma rattaga tegelema.

Seal on ka hoidmisreeglid (doc) — andmete kustutamise poliitika seadistamine teatud perioodi pärast. See on kasulik, kui näiteks tuleb säilitada CPU koormuse andmeid nädalas, mõõtes iga sekundi tagant, samas kui paarikuu jooksul selline täpsus pole vajalik. Sellises olukorras saab teha järgmist:

1. luua pidev päring andmete kogumiseks teise tabelisse;
2. esimese tabeli puhul määrata poliitika meeetrikate kustutamiseks, mis on vanemad kui see nädal.

Ja Influx hakkab automaatselt andmete suurust vähendama ja ebavajalikku eemaldama.

Salvestatud andmetest

Andmeid on mitte palju: umbes 70 tuhat tehingut ja veel miljon punkti turuinfo kohta. Uute kirjade lisamine — mitte rohkem kui 3000 punkti päevas. Samuti on olemas saidi mõõdikud, kuid seal on andmeid vähe ja retention policy järgi säilitatakse neid mitte rohkem kui kuu.

Probleemid

Teenuse arendamise ja sellele järgnenud testimise käigus tekkis üha rohkem kriitilisi probleeme InfluxDB kasutamisel.

1. Andmete kustutamine

On tehingute andmete seeria:

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

Tulemus:

Saadan käsu andmete kustutamiseks:

DELETE FROM transactions WHERE symbol=’USDT’

Seejärel teen päringu juba kustutatud andmete saamiseks. Ja Influx tagastab osade andmete asemel, mis peaksid olema kustutatud, osad andmed.

Proovin kustutada tabeli täielikult:

DROP MEASUREMENT transactions

Kontrollin tabeli kustutamist:

SHOW MEASUREMENTS

Tabelit nimekirjas ei näe, kuid uus andmete päring tagastab ikka sama tehingute komplekti.

Probleem tekkis mul ainult üks kord, kuna kustutamise juhtum on ainus. Kuid selline käitumine ei sobi ilmselgelt «korrektse» töö raamidesse. Hiljem leidsin GitHubist avatud pilet peaaegu aasta tagasi selle teema kohta.

Tulemuseks aitas andmete kustutamine ja kogu andmebaasi taastamine.

2. Ujuva komaga arvud

Matemaatiliste arvutuste tegemine InfluxDB sisseehitatud funktsioonide abil toob kaasa täpsusvead. See ei ole midagi ebatavalist, kuid ebameeldiv.

Minu juhul on andmed rahalise komponendiga ja sooviks neid töödelda kõrge täpsusega. Seetõttu plaanin loobuda pidevatest päringutest.

3. Pidevaid päringuid ei saa kohandada erinevatesse ajavöönditesse

Teenuses on tabel päevase statistika kohta tehingute kohta. Iga päev tuleb rühmitada kõik tehingud selle päeva jooksul. Kuid igaühe päev algab erineval ajal, seega on ka tehingute kogum erinev. UTC järgi on 37 varianti nihe, mille jaoks tuleb andmeid koguda.

InfluxDB-s, kui rühmitada ajaperioodi järgi, saab lisaks määrata nihke, näiteks Moskva aja (UTC+3) puhul:

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

Kuid päringu tulemus on vale. Ühel või teisel põhjusel rühmitatud päevased andmed algavad lausa 1677. aastast (InfluxDB toetab ametlikult ajavahemikku alates sellest aastast):

Selle probleemi vältimiseks oleme teenuse ajutiselt viinud UTC+0.

4. Jõudlus

Internetis on palju võrdlusi InfluxDB ja teiste andmebaaside kohta. Esmasel tutvumisel tundusid need turundusmaterjalidena, kuid nüüd arvan, et neis on tõde.

Kannan enda juhtumi.

Teenuses on API meetod, mis tagastab statistika viimase 24 tunni kohta. Arvutuste käigus teeb meetod kolm korda andmebaasi päringud järgmiste päringutega:

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

Selgitus:

1. Esimeses päringus saame iga mündi viimased punktid turu andmetega. Minu puhul kaheksa punkti kaheksale mündile.
2. Teine päring saab ühe kõige uuema punkti.
3. Kolmas päring küsib viimase 24 tunni tehingute nimekirja, neid võib olla mitu sada.

Selgitan, et InfluxDB-s luuakse automaatselt indeks ning see suurendab päringute kiirus, kui nitse ja ajaga. Esimeses päringus symbol — see on nihe.

Tehtud on stressitest selle API meetodi kohta. 25 RPS korral näitas server kõigi kuue CPU täitumist:

Samal ajal ei andnud NodeJs protsess mingeid koormusi.

Täitmise kiirus halvenes juba 7-10 RPS juures: kui üks klient suutis vastuse saada 200 ms jooksul, pidid 10 klienti ootama ühe sekundi. 25 RPS on piir, mille juures kannatas stabiilsus, klientidele tagastati 500 vead.

Sellise jõudlusega ei ole Influxi kasutamine meie projektis võimalik. Veelgi enam: projektis, kus jälgimist tuleb demonstreerida paljudele klientidele — võivad tekkida sarnased probleemid ja mõõtmete server saab üle koormatud.

Kokkuvõte

Oluline järeldus saadud kogemusest on see, et projekti ei tohi tuua tundmatuid tehnoloogiaid ilma piisava analüüsita. Lihtne avatud piletite skaneerimine GitHubis oleks andnud teavet, et mitte valida InfluxDB põhivaatage andmete salvestamiseks.

InfluxDB pidi olema oma projekti vajaduste jaoks sobiv, kuid praktika on näidanud, et see andmebaas ei vasta nõudmistele ja teeb palju vigu.

Projektirepositooriumis on juba saadaval versioon 2.0.0-beta, jääb vaid lo hope, et teises versioonis on olulisi parandusi. Samas hakkan uurima TimescaleDB dokumentatsiooni.

Allikas: habr.com