🥇Jeza, pogajanja in depresija pri delu z InfluxDB

Če uporabljate podatkovno bazo časovnih vrst (timeseries db, wiki) kot glavno shrambo za spletno mesto s statistiko, potem lahko namesto rešitve težave dobite veliko glavobolov. Delam na projektu, ki uporablja takšno bazo podatkov, in včasih je InfluxDB, o katerem bomo razpravljali, predstavil popolnoma nepričakovana presenečenja.

Zavrnitev odgovornosti: Navedene težave veljajo za različico InfluxDB 1.7.4.

Zakaj časovne vrste?

Projekt je namenjen sledenju transakcijam na različnih verigah blokov in prikazovanju statistike. Natančneje, gledamo na emisijo in sežiganje stabilnih kovancev (wiki). Na podlagi teh transakcij morate zgraditi grafe in prikazati tabele povzetkov.

Pri analizi transakcij se je porodila ideja: uporabiti podatkovno bazo časovnih vrst InfluxDB kot glavno shrambo. Transakcije so točke v času in se dobro ujemajo z modelom časovne vrste.

Tudi funkcije združevanja so bile videti zelo priročne - idealne za obdelavo grafikonov z dolgim obdobjem. Uporabnik potrebuje grafikon za eno leto, baza podatkov pa vsebuje nabor podatkov s časovnim okvirom petih minut. Nesmiselno mu je pošiljati vseh sto tisoč pik - razen dolge obdelave ne bodo prišle niti na zaslon. Napišete lahko lastno implementacijo povečanja časovnega okvira ali uporabite funkcije združevanja, vgrajene v Influx. Z njihovo pomočjo lahko združite podatke po dnevih in pošljete zahtevanih 365 točk.

Nekoliko zmedeno je bilo, da se takšne baze podatkov običajno uporabljajo za zbiranje metrik. Spremljanje strežnikov, iot naprav, vsega iz česar “teče” na milijone točk oblike: [<čas> - <metrična vrednost>]. Toda če zbirka podatkov dobro deluje z velikim pretokom podatkov, zakaj bi potem majhna količina povzročala težave? S tem v mislih smo vzeli InfluxDB za delo.

Kaj je še priročno v InfluxDB

Poleg omenjenih agregacijskih funkcij obstaja še ena odlična stvar – neprekinjene poizvedbe (doc). To je razporejevalnik, vgrajen v bazo podatkov, ki lahko obdeluje podatke po razporedu. Na primer, vsakih 24 ur lahko združite vse rekorde za dan, izračunate povprečje in zabeležite eno novo točko v drugo tabelo, ne da bi pisali svoja kolesa.

obstaja tudi politike hrambe (doc)—nastavitev brisanja podatkov po določenem času. Uporabno je, ko morate na primer shraniti obremenitev procesorja za en teden z meritvami enkrat na sekundo, na razdalji nekaj mesecev pa takšna natančnost ni potrebna. V takšni situaciji lahko storite to:

ustvarite neprekinjeno poizvedbo za združevanje podatkov v drugo tabelo;
za prvo tabelo določite pravilnik za brisanje meritev, ki so starejše od istega tedna.

In Influx bo samostojno zmanjšal velikost podatkov in izbrisal nepotrebne stvari.

O shranjenih podatkih

Shranjenih ni veliko podatkov: okoli 70 tisoč transakcij in še milijon točk s tržnimi informacijami. Dodajanje novih vnosov - ne več kot 3000 točk na dan. Obstajajo tudi meritve za spletno mesto, vendar je tam malo podatkov in se v skladu s politiko hrambe hranijo največ en mesec.

Težave

Med razvojem in kasnejšim testiranjem storitve se je pojavljalo vedno več kritičnih težav pri delovanju InfluxDB.

1. Brisanje podatkov

Obstaja vrsta podatkov s transakcijami:

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

Rezultat:

Pošiljam ukaz za brisanje podatkov:

DELETE FROM transactions WHERE symbol=’USDT’

Nato podam zahtevo za prejem že izbrisanih podatkov. In namesto praznega odgovora Influx vrne del podatkov, ki jih je treba izbrisati.

Poskušam izbrisati celotno tabelo:

DROP MEASUREMENT transactions

Preverim brisanje tabele:

SHOW MEASUREMENTS

Na seznamu ne vidim tabele, vendar nova podatkovna poizvedba še vedno vrne isti niz transakcij.

Težava se mi je pojavila samo enkrat, saj je bil primer izbrisa osamljen primer. Toda to vedenje baze podatkov očitno ne sodi v okvir "pravilnega" delovanja. Kasneje sem ga našel odprtega na githubu vstopnica pred skoraj enim letom na to temo.

Posledično je pomagalo brisanje in nato obnovitev celotne baze podatkov.

2. Številke s plavajočo vejico

Matematični izračuni pri uporabi vgrajenih funkcij v InfluxDB imajo napake v točnosti. Ne da je to kaj nenavadnega, je pa neprijetno.

V mojem primeru imajo podatki finančno komponento in bi jih rad obdelal z visoko natančnostjo. Zaradi tega nameravamo opustiti neprekinjene poizvedbe.

3. Neprekinjene poizvedbe ni mogoče prilagoditi različnim časovnim pasom

Storitev ima tabelo z dnevno statistiko transakcij. Za vsak dan morate združiti vse transakcije za ta dan. Vendar se bo dan vsakega uporabnika začel ob drugem času, zato bo nabor transakcij drugačen. Po UTC ja 37 variant izmene, za katere morate združiti podatke.

V InfluxDB lahko pri združevanju po času dodatno določite premik, na primer za moskovski čas (UTC+3):

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

Toda rezultat poizvedbe bo napačen. Iz neznanega razloga se bodo podatki, razvrščeni po dnevih, začeli vse do leta 1677 (InfluxDB uradno podpira časovni razpon od tega leta):

Da bi se izognili tej težavi, smo storitev začasno preklopili na UTC+0.

4. Zmogljivost

Na internetu je veliko meril uspešnosti, ki primerjajo InfluxDB in druge baze podatkov. Na prvi pogled so bili videti kot marketinški materiali, zdaj pa mislim, da je v njih nekaj resnice.

Povedal vam bom svoj primer.

Storitev ponuja metodo API, ki vrne statistiko za zadnji dan. Pri izvajanju izračunov metoda trikrat poizveduje po bazi podatkov z naslednjimi poizvedbami:

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

Pojasnilo:

V prvi zahtevi dobimo zadnje točke za vsak kovanec s tržnimi podatki. Osem točk za osem kovancev v mojem primeru.
Druga zahteva dobi eno najnovejših točk.
Tretji zahteva seznam transakcij za zadnjih XNUMX ur, lahko jih je več sto.

Naj pojasnim, da InfluxDB samodejno zgradi indeks na podlagi oznak in časa, kar pospeši poizvedbe. V prvi zahtevi Simbol je oznaka.

Izvedel sem stresni test te metode API. Za 25 RPS je strežnik pokazal polno obremenitev šestih CPU-jev:

Hkrati postopek NodeJs sploh ni zagotovil nobene obremenitve.

Hitrost izvajanja se je že zmanjšala za 7-10 RPS: če je en odjemalec lahko prejel odgovor v 200 ms, je moralo 10 odjemalcev čakati sekundo. 25 RPS je meja, pri kateri je trpela stabilnost, strankam je bilo vrnjenih 500 napak.

S takšno zmogljivostjo je nemogoče uporabiti Influx v našem projektu. Še več: v projektu, kjer je treba spremljanje prikazati številnim strankam, se lahko pojavijo podobne težave in strežnik metrik bo preobremenjen.

Izhod

Najpomembnejša ugotovitev iz pridobljenih izkušenj je, da neznane tehnologije ne morete sprejeti v projekt brez zadostne analize. Preprost pregled odprtih vprašanj na githubu bi lahko zagotovil informacije, da se izognete izbiri InfluxDB kot glavnega pomnilnika podatkov.

InfluxDB bi moral biti primeren za naloge mojega projekta, a kot je praksa pokazala, ta zbirka podatkov ne ustreza potrebam in ima veliko napak.

V repozitoriju projekta že najdete različico 2.0.0-beta, le upamo lahko, da bo druga različica imela pomembne izboljšave. Medtem bom šel preučiti dokumentacijo TimescaleDB.

Vir: www.habr.com

Jeza, barantanje in depresija pri delu z InfluxDB