Zemërimi, pazaret dhe depresioni kur punoni me InfluxDB

Nëse përdorni një bazë të dhënash të serive kohore (seri kohore db, wiki) si ruajtja kryesore për një faqe me statistika, atëherë në vend që të zgjidhni problemin mund të keni shumë dhimbje koke. Unë jam duke punuar në një projekt që përdor një bazë të dhënash të tillë, dhe ndonjëherë InfluxDB, i cili do të diskutohet, prezantoi surpriza krejtësisht të papritura.

Mohim përgjegjësie: Problemet e listuara vlejnë për versionin 1.7.4 të InfluxDB.

Pse seritë kohore?

Projekti synon të gjurmojë transaksionet në zinxhirë të ndryshëm bllokues dhe të shfaqë statistika. Në mënyrë të veçantë, ne shikojmë emetimin dhe djegien e monedhave të qëndrueshme (wiki). Bazuar në këto transaksione, ju duhet të ndërtoni grafikë dhe të tregoni tabela përmbledhëse.

Gjatë analizimit të transaksioneve, lindi një ide: përdorimi i bazës së të dhënave të serive kohore InfluxDB si ruajtje kryesore. Transaksionet janë pika në kohë dhe përshtaten mirë me modelin e serive kohore.

Funksionet e grumbullimit dukeshin gjithashtu shumë të përshtatshme - ideale për përpunimin e grafikëve me një periudhë të gjatë. Përdoruesit i duhet një grafik për një vit, dhe baza e të dhënave përmban një grup të dhënash me një kornizë kohore prej pesë minutash. Është e kotë t'i dërgosh atij të gjitha njëqind mijë pikat - përveç përpunimit të gjatë, ato as nuk do të futen në ekran. Ju mund të shkruani zbatimin tuaj të rritjes së kornizës kohore ose të përdorni funksionet e grumbullimit të integruara në Influx. Me ndihmën e tyre, ju mund të gruponi të dhënat sipas ditës dhe të dërgoni 365 pikët e kërkuara.

Ishte pak konfuze që baza të të dhënave të tilla zakonisht përdoren për qëllime të mbledhjes së metrikës. Monitorimi i serverëve, pajisjeve iot, gjithçka nga e cila “rrjedhin” miliona pika të formës: [<koha> - <vlera metrike>]. Por nëse baza e të dhënave funksionon mirë me një fluks të madh të dhënash, atëherë pse një vëllim i vogël duhet të shkaktojë probleme? Me këtë në mendje, ne morëm InfluxDB në punë.

Çfarë tjetër është e përshtatshme në InfluxDB

Përveç funksioneve të përmendura të grumbullimit, ekziston një gjë tjetër e mrekullueshme - pyetje të vazhdueshme (doktor). Ky është një planifikues i integruar në bazën e të dhënave që mund të përpunojë të dhëna sipas një plani. Për shembull, çdo 24 orë mund të gruponi të gjitha rekordet për ditën, të llogaritni mesataren dhe të regjistroni një pikë të re në një tabelë tjetër pa shkruar biçikletat tuaja.

Gjithashtu kanë politikat e mbajtjes (doktor)-konfigurimi i fshirjes së të dhënave pas një periudhe të caktuar. Është e dobishme kur, për shembull, duhet të ruani ngarkesën e CPU-së për një javë me matje një herë në sekondë, por në një distancë prej disa muajsh nuk nevojitet një saktësi e tillë. Në një situatë të tillë, ju mund ta bëni këtë:

1. krijoni një pyetje të vazhdueshme për të grumbulluar të dhënat në një tabelë tjetër;
2. për tabelën e parë, përcaktoni një politikë për fshirjen e metrikave që janë më të vjetra se po atë javë.

Dhe Influx do të zvogëlojë në mënyrë të pavarur madhësinë e të dhënave dhe do të fshijë gjërat e panevojshme.

Rreth të dhënave të ruajtura

Nuk ruhen shumë të dhëna: rreth 70 mijë transaksione dhe një milion pika të tjera me informacionin e tregut. Shtimi i hyrjeve të reja - jo më shumë se 3000 pikë në ditë. Ka edhe metrikë për sitin, por ka pak të dhëna atje dhe, sipas politikës së ruajtjes, ato ruhen jo më shumë se një muaj.

Problemet

Gjatë zhvillimit dhe testimit të mëvonshëm të shërbimit, gjithnjë e më shumë probleme kritike u shfaqën në funksionimin e InfluxDB.

1. Fshini të dhënat

Ka një seri të dhënash me transaksione:

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

Rezultati:

Unë po dërgoj një komandë për të fshirë të dhënat:

DELETE FROM transactions WHERE symbol=’USDT’

Më pas bëj një kërkesë për të marrë të dhënat tashmë të fshira. Dhe në vend të një përgjigjeje boshe, Influx kthen një pjesë të të dhënave që duhet të fshihen.

Po përpiqem të fshij të gjithë tabelën:

DROP MEASUREMENT transactions

Unë kontrolloj fshirjen e tabelës:

SHOW MEASUREMENTS

Nuk e shoh tabelën në listë, por pyetja e re e të dhënave përsëri kthen të njëjtin grup transaksionesh.

Problemi më ka ndodhur vetëm një herë, pasi rasti i fshirjes ishte një rast i izoluar. Por kjo sjellje e bazës së të dhënave nuk përshtatet qartë në kuadrin e funksionimit "korrekt". Më vonë e gjeta të hapur në github biletë gati një vit më parë për këtë temë.

Si rezultat, fshirja dhe më pas rivendosja e të gjithë bazës së të dhënave ndihmoi.

2. Numrat me pikë lundruese

Llogaritjet matematikore kur përdoren funksionet e integruara në InfluxDB kanë gabime saktësie. Jo se kjo është diçka e pazakontë, por është e pakëndshme.

Në rastin tim, të dhënat kanë një komponent financiar dhe do të doja t'i përpunoja me saktësi të lartë. Për shkak të kësaj, ne planifikojmë të braktisim pyetjet e vazhdueshme.

3. Pyetjet e vazhdueshme nuk mund të përshtaten në zona të ndryshme kohore

Shërbimi ka një tabelë me statistikat e transaksioneve ditore. Për çdo ditë, ju duhet të gruponi të gjitha transaksionet për atë ditë. Por dita e çdo përdoruesi do të fillojë në një kohë të ndryshme, dhe për këtë arsye grupi i transaksioneve do të jetë i ndryshëm. Nga UTC po 37 variante ndërrimet për të cilat ju duhet të grumbulloni të dhëna.

Në InfluxDB, kur gruponi sipas kohës, mund të specifikoni gjithashtu një zhvendosje, për shembull për kohën e Moskës (UTC+3):

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

Por rezultati i pyetjes do të jetë i pasaktë. Për disa arsye, të dhënat e grupuara sipas ditës do të fillojnë deri në vitin 1677 (InfluxDB mbështet zyrtarisht një hapësirë ​​kohore nga ky vit):

Për të zgjidhur këtë problem, ne e kaluam përkohësisht shërbimin në UTC+0.

4. Performanca

Ka shumë standarde në internet që krahasojnë InfluxDB dhe baza të tjera të të dhënave. Në pamje të parë, ato dukeshin si materiale marketingu, por tani mendoj se ka disa të vërteta në to.

Unë do t'ju tregoj rastin tim.

Shërbimi ofron një metodë API që kthen statistikat për ditën e fundit. Kur kryen llogaritjet, metoda pyet bazën e të dhënave tre herë me pyetjet e mëposhtme:

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

Shpjegim:

1. Në kërkesën e parë marrim pikët e fundit për çdo monedhë me të dhënat e tregut. Tetë pikë për tetë monedha në rastin tim.
2. Kërkesa e dytë merr një nga pikët më të reja.
3. I treti kërkon një listë të transaksioneve për XNUMX orët e fundit; mund të ketë disa qindra prej tyre.

Më lejoni të sqaroj se InfluxDB ndërton automatikisht një indeks bazuar në etiketat dhe kohën, gjë që përshpejton pyetjet. Në kërkesën e parë simbol është një etiketë.

Unë kam kryer një test stresi në këtë metodë API. Për 25 RPS, serveri demonstroi një ngarkesë të plotë prej gjashtë CPU:

Në të njëjtën kohë, procesi NodeJs nuk ofroi fare ngarkesë.

Shpejtësia e ekzekutimit tashmë është degraduar me 7-10 RPS: nëse një klient mund të merrte një përgjigje në 200 ms, atëherë 10 klientë duhej të prisnin një sekondë. 25 RPS është kufiri në të cilin vuajti stabiliteti; 500 gabime iu kthyen klientëve.

Me një performancë të tillë është e pamundur të përdoret Influx në projektin tonë. Për më tepër: në një projekt ku monitorimi duhet t'u demonstrohet shumë klientëve, mund të shfaqen probleme të ngjashme dhe serveri metrikë do të mbingarkohet.

Prodhim

Përfundimi më i rëndësishëm nga përvoja e fituar është se nuk mund të marrësh një teknologji të panjohur në një projekt pa analiza të mjaftueshme. Një shqyrtim i thjeshtë i çështjeve të hapura në github mund të sigurojë informacion për të shmangur zgjedhjen e InfluxDB si dyqanin kryesor të të dhënave.

InfluxDB duhet të ishte një përshtatje e mirë për detyrat e projektit tim, por siç ka treguar praktika, kjo bazë të dhënash nuk i plotëson nevojat dhe ka shumë gabime.

Versionin 2.0.0-beta mund ta gjeni tashmë në depon e projektit; ne mund të shpresojmë vetëm se versioni i dytë do të ketë përmirësime të rëndësishme. Ndërkohë, unë do të shkoj të studioj dokumentacionin TimescaleDB.

Burimi: www.habr.com