Viha, kaubandus ja masendus InfluxDB kasutamisel

Kui kasutada ajareal põhinevat andmebaasi (timeseries db, wiki) peamise salvestusena statistika veebisaidile, võib ülesande lahendamise asemel tekkida palju peavalu. Töödan projektiga, kus kasutatakse sellist andmebaasi, ja mõnikord on InfluxDB, millest jutt, toonud kaasa ootamatuid üllatusi.

Märkus: esitatud probleemid kuuluvad versioonile InfluxDB 1.7.4.

Miks ajaread?

Projekt seisneb tehingute jälgimises erinevates plokiahelates ja statistika kuvamises. Konkreetsemalt jälgime stabiilsete virtuaalsete coinide emissiooni ja põletamist (wiki). Nende tehingute põhjal on vaja koostada diagramme ja esitada kokkuvõtteid.

Tehingute analüüsimise käigus tuli idee: kasutada ajareal põhinevat andmebaasi InfluxDB peamise salvestusena. Tehingud on ajamomendid ja sobivad hästi ajarealise mudeli sisse.

Veel funktsioone koondamise osas tundusid väga mugavad — pika perioodi jooksul graafikute töötlemiseks on need ideaalsed. Kasutajale on vajalik aastane graafik, kuid andmebaasis on komplektandmeid viie minuti ajaraami kohta. Terve sada tuhat punkti temale saatmine on mõttetuks — peale pika töötlemise ei mahuks need ka ekraanile. Saab kirjutada oma ajaraami suurendamise rakenduse või kasutada Influxi sisseehitatud koondamisfunktsioone. Nende abil saab andmeid rühmadesse koondada päevade kaupa ja saata vajalikud 365 punkti.

Natuke segadust tekitas see, et tavaliselt kasutatakse selliseid andmebaase mõõdikute kogumiseks. Serverite jälgimine, IoT-seadmed, kõik, kust voolab miljoneid punkte, mis näevad välja: [<aeg> — <mõõdiku väärtus>]. Kuid kui andmebaas töötab hästi suure andmevooga, siis miks peaks väikse koguse puhul probleeme tekkima? Selle mõttega võtsime InfluxDB tööle.

Mis veel on InfluxDB-s mugav

Lisaks mainitud koondamisfunktsioonidele on veel üks suurepärane asi — tõukeküsimused (dok). See, it's a built-in scheduler in the database that can handle data on a schedule. For instance, you can group all entries for the day every 24 hours, calculate the average, and record a new point in another table without writing your own cycles.

Samuti on olemas retention policies (dok) — setting up data deletion after a certain period. This is useful when, for example, you need to keep CPU load data for a week with measurements every second, but such precision isn't necessary over a couple of months. In such a situation, you can do the following:

1. create a continuous query to aggregate data into another table;
2. define a deletion policy for metrics older than that week for the first table.

And Influx will automatically reduce the data size and delete unnecessary records.

About stored data

There's not a lot of data stored: about 70,000 transactions and another million points with market information. New records are added at a rate of no more than 3,000 points per day. There are also metrics on the site, but there’s not much data there, and according to the retention policy, they are stored for no longer than a month.

Probleemid

Teenuse arendamise ja järgneva testimise käigus tekkis üha kriitilisemaid probleeme InfluxDB kasutamisel.

1. Andmete kustutamine

On olemas andmesari tehingutega:

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

Tulemus:

Saadan käsu andmete kustutamiseks:

DELETE FROM transactions WHERE symbol='USDT'

Pärast seda teen päringu juba kustutatud andmete saamiseks. Influx tagastab tühja vastuse asemel osa andmetest, mis pidid olema kustutatud.

Proovin kustutada terve tabeli:

DROP MEASUREMENT transactions

Kontrollin tabeli kustutamist:

SHOW MEASUREMENTS

Tabelit loendis ei näe, kuid uus andmepäring tagastab endiselt sama tehingute kogumi.

Probleem tekkis mul vaid üks kord, kuna kustutamise juhtum oli harv. Kuid selline käitumine andmebaasis ei vasta selgelt "korrektse" töö raamistikule. Hiljem leidsin githubist avatud ticketi peaaegu aasta taguse selle teema kohta.

Kokkuvõttes aitas andmete eemaldamine ja kogu andmebaasi taastamine.

2. Ujuvkoma numbrid

Matemaatilised arvutused InfluxDB sisseehitatud funktsioone kasutades toovad esile täpsusvead. See ei ole just midagi ebatavalist, kuid ebameeldiv.

Minu puhul on andmed rahaga seotud, ning soovin neid töötleda kõrge täpsusega. Selle tõttu on plaanis loobuda pidevatest päringutest.

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

Teenuses on tabel päevast statistikat tehingute kohta. Iga päeva jaoks tuleb rühmitada kõik tehingud nende ööpäeva jooksul. Kuid iga kasutaja jaoks algab päev erineval ajal, seega on ka tehingute kogum erinev. UTC järgi on olemas 37 varianti nihet, mille jaoks tuleb andmeid agregatsiooni võtta.

InfluxDB-s, kui ajaperioodi järgi rühmitatakse, saab täiendavalt määrata nihke, näiteks Moskva aja (UTC+3) jaoks:

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

Kuid päringu tulemus saab olema vale. Ühel või teisel põhjusel rühmitatud päevaste andmete algus kuupäev on lausa 1677. aasta (InfluxDB toetab ametlikult ajavahemikku alates sellest aastast):

Selle probleemi vältimiseks viidi teenus ajutiselt üle UTC+0-le.

4. Jõudlus

Internetis on palju bänkmärke, mis võrdlevad InfluxDB-d ja teisi andmebaase. Esimese tutvustuse ajal tundusid need turundusmaterjalidena, kuid nüüd arvan, et neis on tõetera.

Jagage oma juhtumit.

Teenusel on API meetod, mis tagastab statistika viimase 24 tunni jooksul. Arvutuste käigus küsib meetod andmebaasi kolm korda 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 viimased punktid iga mündi kohta turuandmetega. Minu puhul oli kaheksa punkti kaheksa mündi kohta.
2. Teine päring saab kõige uueima punkti.
3. Kolmas päring küsib viimase 24 tunni tehingute loendi, neid võib olla mitusada.

Täpsustan, et InfluxDB-s luuakse siltide ja aja järgi automaatselt indeks, mis kiirendab päringuid. Esimeses päringus symbol — see on silt.

Tegin selle API meetodi jaoks stressitesti. 25 RPS juures näitas server täielikku kuue CPU koormust:

Samal ajal ei avaldanud NodeJs protsess mingit koormust.

Täideviimise kiirus langes 7-10 RPS: kui üks klient sai vastuse 200 ms jooksul, pidid 10 klienti ootama ühe sekundi. 25 RPS – piir, mille puhul kannatas stabiilsus, kliendid said tagasi 500 veateateid.

Sellise jõudlusega on meie projektis Influxi kasutamine võimatu. Veelgi enam: projektis, kus jälgimist tuleb näidata paljudele klientidele, võivad tekkida sarnased probleemid ja mõõtmete server koormatakse üle.

Kokkuvõte

Peamine järeldus saadud kogemusest on see, et ei tohiks võtta projekti tundmatut tehnoloogiat ilma piisava analüüsita. Lihtne avatud piletite skaneerimine GitHubis oleks võinud anda teavet, et mitte võtta InfluxDB-d põhivaatamisruumina.

InfluxDB pidi hästi sobima minu projekti ülesannete jaoks, kuid praktika on näidanud, et see andmebaas ei vasta vajadustele ja tekitab palju vigu.

Projektirepos on juba saadaval versioon 2.0.0-beta, jääb loota, et teises versioonis on olulised täiustused. Senikaua õpin TimescaleDB dokumentatsiooni.

Allikas: habr.com