Kolero, marĉandado kaj deprimo kiam vi laboras kun InfluxDB

Se vi uzas tempserian datumbazon (temposerio db, vikio) kiel la ĉefa stokado por retejo kun statistiko, tiam anstataŭ solvi la problemon, vi povas akiri multajn kapdolorojn. Mi laboras pri projekto, kiu uzas tian datumbazon, kaj foje InfluxDB, kiu estos priparolata, prezentis ĝenerale neatenditajn surprizojn.

malgarantioNoto: La montritaj aferoj estas por InfluxDB 1.7.4.

Kial temposerio?

La projekto estas spuri transakciojn en diversaj blokĉenoj kaj montri statistikojn. Specife, ni rigardas la emision kaj bruladon de stabilaj moneroj (vikio). Surbaze de ĉi tiuj transakcioj, vi devas konstrui grafikaĵojn kaj montri pivotajn tabelojn.

Kiam oni analizis transakciojn, aperis ideo: uzi la datumbazon de temposerio InfluxDB kiel ĉefa stokado. Transakcioj estas punktoj en tempo kaj ili bone konvenas al la temposeriomodelo.

La agregaciaj funkcioj ankaŭ aspektis tre oportunaj - ili estas idealaj por prilabori leterojn kun longa periodo. La uzanto bezonas diagramon por jaro, kaj la datumbazo enhavas datuman aron kun tempokadro de kvin minutoj. Estas senutile sendi ĉiujn cent mil poentojn al li - krom longa prilaborado, ili ne taŭgas sur la ekrano. Vi povas skribi vian propran efektivigon de pliigo de la tempokadro, aŭ uzi la agregaciajn funkciojn konstruitajn en Influx. Kun ilia helpo, vi povas grupigi datumojn tage kaj sendi la deziratajn 365 poentojn.

Estis iom embarase, ke tiaj datumbazoj kutime estas uzataj por kolekti metrikojn. Monitorado de serviloj, iot-aparatoj, ĉio el kio milionoj da punktoj de la formo "fluas": [<tempo> - <metrika valoro>]. Sed se la datumbazo funkcias bone kun granda datumfluo, tiam kial malgranda volumo devus kaŭzi problemojn? Kun ĉi tiu penso, ili ekfunkciigis InfluxDB.

Kio alia estas oportuna en InfluxDB

Krom la menciitaj agregaciaj funkcioj, estas alia bonega afero - kontinuaj demandoj (dokumento). Ĉi tio estas planilo konstruita en la datumbazon, kiu povas prilabori datumojn laŭ horaro. Ekzemple, vi povas grupigi ĉiujn rekordojn de la tago ĉiujn 24 horojn, kalkuli la mezumon kaj skribi novan punkton al alia tabelo sen skribi viajn proprajn biciklojn.

Ankaŭ havas retenpolitikoj (dokumento) - agordo por forigi datumojn post certa periodo. Ĝi estas utila kiam, ekzemple, vi devas konservi la ŝarĝon sur la CPU dum semajno kun mezuradoj unufoje por sekundo, sed je distanco de kelkaj monatoj, tia precizeco ne bezonas. En tia situacio, vi povas fari ĉi tion:

1. krei kontinuan demandon por aldoni datumojn en alian tabelon;
2. por la unua tabelo, difinu politikon por forigi metrikojn, kiuj estas pli malnovaj ol tiu sama semajno.

Kaj Influx reduktos la grandecon de la datumoj kaj forigos nenecesajn datumojn per si mem.

Pri konservitaj datumoj

Ne multe da datumoj estas stokitaj: ĉirkaŭ 70 mil transakcioj kaj alia miliono da punktoj kun merkataj informoj. Aldonante novajn enskribojn - ne pli ol 3000 poentoj tage. Ankaŭ ekzistas metrikoj por la retejo, sed estas malmulte da datumoj tie kaj, laŭ la retenpolitiko, ili estas konservitaj dum ne pli ol unu monato.

Problemoj

Dum la evoluo kaj posta testado de la servo, pli kaj pli da kritikaj problemoj ekestis en la funkciado de InfluxDB.

1. Forigo de datumoj

Estas serio de datumoj kun transakcioj:

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

Rezulto:

Mi sendas komandon por forigi datumojn:

DELETE FROM transactions WHERE symbol=’USDT’

Krome mi petas akiri jam forigitajn datumojn. Kaj Influx, anstataŭ malplena respondo, resendas datumon, kiu devus esti forigita.

Mi provas forigi la tutan tabelon:

DROP MEASUREMENT transactions

Mi kontrolas la forigon de la tabelo:

SHOW MEASUREMENTS

Mi ne vidas la tabelon en la listo, sed la nova datumdemando ankoraŭ resendas la saman aron da transakcioj.

La problemo aperis por mi nur unufoje, ĉar la foriga kazo estas izolita kazo. Sed ĉi tiu konduto de la datumbazo klare ne konvenas en la kadron de "ĝusta" laboro. Poste github trovis malfermita bileto preskaŭ jaraĝa pri ĉi tiu temo.

Kiel rezulto, la forigo kaj posta restarigo de la tuta datumbazo helpis.

2. Flotkomaj nombroj

Matematikaj kalkuloj uzantaj la enkonstruitajn funkciojn de InfluxDB donas precizecajn erarojn. Ne ke ĝi estis io nekutima, sed malagrabla.

En mia kazo, la datumoj havas financan komponanton kaj mi ŝatus prilabori ĝin kun alta precizeco. Pro tio, ni planas forlasi daŭrajn demandojn.

3. Daŭraj demandoj ne povas esti adaptitaj al malsamaj horzonoj

La servo havas tabelon kun ĉiutagaj transakciaj statistikoj. Por ĉiu tago, vi devas grupigi ĉiujn transakciojn por tiu tago. Sed la tago por ĉiu uzanto komenciĝos en malsama tempo, tial la aro de transakcioj estas malsama. UTC estas 37 variantoj deĵoroj por kiuj vi volas aldoni datumojn.

En InfluxDB, dum grupiĝo laŭ tempo, vi povas aldone specifi ŝanĝon, ekzemple por Moskva tempo (UTC + 3):

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

Sed la serĉrezulto estos malĝusta. Ial, la datumoj grupigitaj tage komenciĝos jam en 1677 (InfluxDB oficiale subtenas tempoperiodon de ĉi tiu jaro):

Por eviti ĉi tiun problemon, la servo estis provizore translokigita al UTC + 0.

4. Agado

Estas multaj komparnormoj en la Interreto kun komparoj de InfluxDB kaj aliaj datumbazoj. Unuavide, ili aspektis kiel merkatmaterialoj, sed nun mi pensas, ke estas iom da vero en ili.

Lasu min rakonti al vi mian kazon.

La servo disponigas API-metodon, kiu resendas statistikojn pri la lastaj XNUMX horoj. Dum kalkuloj, la metodo pridemandas la datumbazon tri fojojn kun la sekvaj demandoj:

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

Klarigo:

1. En la unua peto, ni ricevas la plej novajn poentojn por ĉiu monero kun merkataj datumoj. Ok punktoj por ok moneroj en mia kazo.
2. La dua peto ricevas unu plej novan poenton.
3. La tria petas liston de transakcioj por la lastaj XNUMX horoj, povas esti pluraj centoj da ili.

Mi klarigu, ke en InfluxDB, indekso estas aŭtomate konstruita per etikedoj kaj laŭ tempo, kio plirapidigas demandojn. En la unua peto simbolo estas etikedo.

Mi faris streĉan provon por ĉi tiu API-metodo. Por 25 RPS, la servilo montris plenan ŝarĝon de ses CPUoj:

Samtempe, la procezo de NodeJs tute ne donis ŝarĝon.

La ekzekutrapideco degradis jam per 7-10 RPS: se unu kliento povis ricevi respondon en 200 ms, tiam 10 klientoj devis atendi sekundon. 25 RPS - la limo de kiu stabileco suferis, 500 eraroj estis resenditaj al klientoj.

Kun tia agado, estas neeble uzi Influx en nia projekto. Krome, en projekto kie monitorado devas esti pruvita al multaj klientoj, similaj problemoj povas aperi kaj la metrika servilo estos troŝarĝita.

konkludo

La plej grava konkludo de la sperto akirita estas, ke oni ne povas preni nekonatan teknologion en projekton sen sufiĉa analizo. Simpla rastrumo de malfermitaj biletoj sur github povus provizi informojn por ne preni InfluxDB kiel la ĉefa datumvendejo.

InfluxDB devis bone konveni al la taskoj de mia projekto, sed kiel praktiko montris, ĉi tiu datumbazo ne plenumas la bezonojn kaj multe fuŝas.

Vi jam povas trovi version 2.0.0-beta en la projekta deponejo, restas esperi, ke estos gravaj plibonigoj en la dua versio. Intertempe mi iros studi la dokumentaron de TimescaleDB.

fonto: www.habr.com