Woede, ûnderhanneljen en depresje by it wurkjen mei InfluxDB

As jo ​​​​in tiidreeksdatabase brûke (timeseries db, wiki) as de wichtichste opslach foar in side mei statistiken, dan kinne jo ynstee fan it probleem op te lossen in protte hoofdpijn krije. Ik bin dwaande mei in projekt dat sa'n databank brûkt, en soms presintearre InfluxDB, dêr't sil wurde besprutsen, folslein ûnferwachte ferrassingen.

Disclaimer: De neamde problemen jilde foar InfluxDB ferzje 1.7.4.

Wêrom tiid rige?

It projekt is om transaksjes op ferskate blockchains te folgjen en statistiken te werjaan. Spesifyk sjogge wy nei de útstjit en ferbaarning fan stabile munten (wiki). Op grûn fan dizze transaksjes moatte jo grafiken bouwe en gearfettingstabellen sjen litte.

By it analysearjen fan transaksjes kaam in idee op: de InfluxDB-tiidreeksdatabase brûke as de haadopslach. Transaksjes binne punten yn 'e tiid en se passe goed yn' e tiidseriemodel.

De aggregaasjefunksjes liken ek heul handich - ideaal foar it ferwurkjen fan charts mei in lange perioade. De brûker hat in diagram foar in jier nedich, en de databank befettet in gegevensset mei in tiidframe fan fiif minuten. It hat gjin sin om him alle hûnderttûzen stippen te stjoeren - útsein lange ferwurking passe se net iens op it skerm. Jo kinne jo eigen ymplemintaasje skriuwe om it tiidframe te fergrutsjen, of de aggregaasjefunksjes brûke ynboud yn Influx. Mei har help kinne jo gegevens per dei groepearje en de fereaske 365 punten stjoere.

It wie in bytsje betiizjend dat sokke databases meastentiids brûkt wurde foar it sammeljen fan metriken. Monitoring fan servers, iot-apparaten, alles wêrfan miljoenen punten fan 'e foarm "streame": [<tiid> - <metryske wearde>]. Mar as de databank goed wurket mei in grutte gegevensstream, wêrom soe dan in lyts folume problemen feroarsaakje? Mei dit yn gedachten namen wy InfluxDB oan it wurk.

Wat oars is handich yn InfluxDB

Neist de neamde aggregaasjefunksjes is d'r in oar geweldich ding - trochgeande queries (doc). Dit is in planner ynboud yn 'e databank dy't gegevens kin ferwurkje op in skema. Bygelyks, elke 24 oeren kinne jo alle records foar de dei groepearje, it gemiddelde berekkenje en ien nij punt opnimme yn in oare tabel sûnder jo eigen fytsen te skriuwen.

Hast ek behâld belied (doc) - it ynstellen fan wiskjen fan gegevens nei in bepaalde perioade. It is nuttich as jo bygelyks de CPU-lading foar in wike moatte opslaan mei mjittingen ien kear per sekonde, mar oer in ôfstân fan in pear moannen is sa'n krektens net nedich. Yn sa'n situaasje kinne jo dit dwaan:

1. meitsje in trochgeande query om gegevens te aggregearjen yn in oare tabel;
2. foar de earste tabel, definiearje in belied foar it wiskjen fan metriken dy't âlder binne as deselde wike.

En Influx sil selsstannich de grutte fan 'e gegevens ferminderje en ûnnedige dingen wiskje.

Oer bewarre gegevens

Net folle gegevens wurde opslein: sa'n 70 tûzen transaksjes en noch in miljoen punten mei merkynformaasje. Nije yngongen tafoegje - net mear as 3000 punten per dei. Der binne ek metriken foar de side, mar d'r binne net folle gegevens en, neffens it behâldbelied, wurde se net mear as in moanne bewarre.

Problemen

Tidens de ûntwikkeling en folgjende testen fan 'e tsjinst ûntstiene hieltyd mear krityske problemen yn' e wurking fan InfluxDB.

1. Wiskje gegevens

D'r is in searje gegevens mei transaksjes:

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

Resultaat:

Ik stjoer in kommando om gegevens te wiskjen:

DELETE FROM transactions WHERE symbol=’USDT’

Dêrnei set ik in fersyk om de al wiske gegevens te ûntfangen. En ynstee fan in lege antwurd jout Influx in diel fan 'e gegevens werom dy't wiske wurde moatte.

Ik besykje de hiele tabel te wiskjen:

DROP MEASUREMENT transactions

Ik kontrolearje it wiskjen fan 'e tabel:

SHOW MEASUREMENTS

Ik sjoch net de tabel yn de list, mar in nije gegevens query noch jout deselde set fan transaksjes.

It probleem kaam my mar ien kear op, om't de wiskfal in isolearre gefal wie. Mar dit gedrach fan 'e databank past dúdlik net yn it ramt fan "korrekte" operaasje. Letter fûn ik it iepen op github kaartsje hast in jier lyn oer dit ûnderwerp.

As resultaat holp it wiskjen en dan werstelle fan de folsleine databank.

2. Floating point nûmers

Math berekkeningen by it brûken fan ynboude funksjes yn InfluxDB hawwe krektens flaters. Net dat dit wat ûngewoan is, mar it is onaangenaam.

Yn myn gefal hawwe de gegevens in finansjele komponint en ik wol it mei hege krektens ferwurkje. Hjirtroch binne wy ​​fan plan trochgeande fragen te ferlitten.

3. Trochrinnende queries kinne net oanpast wurde oan ferskate tiidsônes

De tsjinst hat in tabel mei deistige transaksjestatistiken. Foar elke dei moatte jo alle transaksjes foar dy dei groepearje. Mar de dei fan elke brûker sil begjinne op in oare tiid, en dêrom sil de set fan transaksjes oars wêze. By UTC ja 37 farianten ferskowings wêrfoar jo moatte aggregearje gegevens.

Yn InfluxDB kinne jo by groepearjen op tiid ek in ferskowing opjaan, bygelyks foar Moskou-tiid (UTC+3):

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

Mar it resultaat fan 'e query sil ferkeard wêze. Om ien of oare reden sille gegevens groepeare per dei hielendal werom begjinne oant 1677 (InfluxDB stipet offisjeel in tiidspanne fan dit jier):

Om dit probleem om te gean, hawwe wy de tsjinst tydlik oerskeakele nei UTC + 0.

4. Prestaasje

D'r binne in protte benchmarks op it ynternet dy't InfluxDB en oare databases fergelykje. Op it earste each seagen se út as marketingmateriaal, mar no tink ik dat der wat wierheid yn sit.

Ik sil dy myn saak fertelle.

De tsjinst leveret in API-metoade dy't statistiken foar de lêste dei werombringt. By it útfieren fan berekkeningen freget de metoade trije kear de database mei de folgjende fragen:

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

Ferklearring:

1. Yn it earste fersyk krije wy de lêste punten foar elke munt mei merkgegevens. Acht punten foar acht munten yn myn gefal.
2. It twadde fersyk krijt ien fan de nijste punten.
3. De tredde freget in list mei transaksjes foar de lêste XNUMX oeren; d'r kinne ferskate hûnderten fan wêze.

Lit my ferdúdlikje dat InfluxDB automatysk in yndeks bouwt op basis fan tags en tiid, wat queries fersnelt. Yn it earste fersyk symboal is in tag.

Ik haw rinne in stress test op dizze API metoade. Foar 25 RPS toande de server in folsleine lading fan seis CPU's:

Tagelyk levere it NodeJs-proses hielendal gjin lading.

De útfieringssnelheid is al degradearre troch 7-10 RPS: as ien kliïnt in antwurd koe krije yn 200 ms, dan moasten 10 kliïnten in twadde wachtsje. 25 RPS is de limyt wêrop stabiliteit te lijen hat; 500 flaters waarden weromjûn oan kliïnten.

Mei sokke prestaasjes is it ûnmooglik om Influx te brûken yn ús projekt. Boppedat: yn in projekt dêr't tafersjoch moat wurde oantoand oan in protte kliïnten, kinne ferlykbere problemen ferskine en de metrike tsjinner wurdt oerladen.

konklúzje

De wichtichste konklúzje út de opdien ûnderfining is dat jo in ûnbekende technology net yn in projekt kinne nimme sûnder genôch analyze. In ienfâldige screening fan iepen problemen op github koe ynformaasje leverje om foar te kommen dat jo InfluxDB kieze as de haadgegevenswinkel.

InfluxDB soe in goede fit wêze moatte foar de taken fan myn projekt, mar lykas de praktyk hat bliken dien, foldocht dizze databank net oan 'e behoeften en hat in protte bugs.

Jo kinne ferzje 2.0.0-beta al fine yn it projektrepository; wy kinne allinich hoopje dat de twadde ferzje signifikante ferbetterings sil hawwe. Yn 'e tuskentiid sil ik de TimescaleDB-dokumintaasje studearje.

Boarne: www.habr.com