Nëse përdoret një DB e serive kohore (timeseries db, ) si ruajtja kryesore për një faqe me statistika, atëherë në vend të zgjidhjes së problemit mund të përfitosh shumë dhimbje koke. Po punoj në një projekt ku përdoret një bazë e tillë dhe nganjëherë InfluxDB, për të cilën do të flasim, sillte surpriza krejt të papritura.
Kufizimi: problemet e përmendura më poshtë i përkasin versionit InfluxDB 1.7.4.
Pse time series?
Projekti konsiston në gjurmimin e transaksioneve në blockchain-e të ndryshme dhe paraqitjen e statistikave. Më saktë, ndjekim emetimin dhe djegien e stablecoin-eve (). Në bazë të këtyre transaksioneve duhet të ndërtohen grafikë dhe të shfaqen tabela përmbledhëse.
Gjatë analizës së transaksioneve lindi ideja: të përdorim bazën e të dhënave të serive kohore InfluxDB si ruajtjen kryesore. Transaksionet janë pika në kohë dhe përshtaten shumë mirë me modelin e serive kohore.
Edhe funksionet e agregimit dukeshin mjaft tĂ« pĂ«rshtatshme â ideale pĂ«r pĂ«rpunimin e grafikĂ«ve me periudha tĂ« gjata. PĂ«rdoruesit i duhet njĂ« grafik pĂ«r njĂ« vit, ndĂ«rsa nĂ« bazĂ« ndodhet njĂ« grup tĂ« dhĂ«nash me timeframe prej pesĂ« minutash. Tâi dĂ«rgosh tĂ« gjitha ato njĂ«qind mijĂ« pika nuk ka kuptim â pĂ«rveç pĂ«rpunimit tĂ« gjatĂ«, ato as nuk do tĂ« pĂ«rshtaten nĂ« ekran. Mund tĂ« shkruhet njĂ« implementim i vet pĂ«r rritjen e timeframe-it, ose tĂ« pĂ«rdoren funksionet e integruara tĂ« agregimit nĂ« Influx. Me ndihmĂ«n e tyre, tĂ« dhĂ«nat mund tĂ« grupohen sipas ditĂ«ve dhe tĂ« dĂ«rgohen 365 pikat e nevojshme.
Paksa shqetĂ«sues ishte fakti qĂ« zakonisht baza tĂ« tilla pĂ«rdoren pĂ«r mbledhjen e metrikeve. Monitorimi i serverĂ«ve, pajisjet IoT, gjithçka nga ku âderdhenâ miliona pika tĂ« formĂ«s: [ â ]. Por nĂ«se baza punon mirĂ« me rrjedha tĂ« mĂ«dha tĂ« dhĂ«nash, pse vĂ«llimi i vogĂ«l duhet tĂ« shkaktojĂ« probleme? Me kĂ«tĂ« mendim, vendosĂ«m ta pĂ«rdorim InfluxDB.
ĂfarĂ« tjetĂ«r Ă«shtĂ« e pĂ«rshtatshme nĂ« InfluxDB
PĂ«rveç funksioneve tĂ« agregimit tĂ« pĂ«rmendura, ka edhe njĂ« gjĂ« tjetĂ«r tĂ« shkĂ«lqyer â continuous queries (). Ky Ă«shtĂ« njĂ« planifikues i integruar nĂ« DB, i cili mund tĂ« pĂ«rpunojĂ« tĂ« dhĂ«nat sipas orarit. PĂ«r shembull, mund tĂ« grupohen çdo 24 orĂ« tĂ« gjitha regjistrimet e ditĂ«s, tĂ« llogaritet mesatarja dhe tĂ« shkruhet njĂ« pikĂ« e re nĂ« njĂ« tabelĂ« tjetĂ«r, pa krijuar zgjidhje tĂ« improvizuara vetjake.
Gjithashtu ka retention policies () â konfigurimi i fshirjes sĂ« tĂ« dhĂ«nave pas njĂ« periudhe tĂ« caktuar. Kjo Ă«shtĂ« e dobishme, pĂ«r shembull, kur duhet tĂ« ruani ngarkesĂ«n e CPU pĂ«r njĂ« javĂ« me matje çdo sekondĂ«, por nĂ« njĂ« interval prej disa muajsh njĂ« saktĂ«si e tillĂ« nuk nevojitet. NĂ« kĂ«tĂ« rast mund tĂ« veproni kĂ«shtu:
- të krijoni një continuous query për agregimin e të dhënave në një tabelë tjetër;
- për tabelën e parë të përcaktoni një politikë fshirjeje për metrikat më të vjetra se ajo javë.
Dhe Influx do ta zvogëlojë vetë vëllimin e të dhënave dhe do të fshijë atë që nuk nevojitet.
Për të dhënat e ruajtura
Nuk ruhen shumë të dhëna: rreth 70 mijë transaksione dhe edhe një milion pika me informacion tregu. Shtimi i regjistrimeve të reja nuk kalon 3000 pika në ditë. Ka gjithashtu metrika për faqen, por aty të dhënat janë të pakta dhe sipas retention policy ruhen jo më shumë se një muaj.
Problemet
Gjatë zhvillimit dhe testimit të mëvonshëm të shërbimit, gjatë përdorimit të InfluxDB nisën të shfaqeshin probleme gjithnjë e më kritike.
1. Fshirja e të dhënave
Ekziston një seri të dhënash me transaksione:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Rezultati:
Dërgoj komandën për fshirjen e të dhënave:
DELETE FROM transactions WHERE symbol=âUSDTâMĂ« pas bĂ«j njĂ« kĂ«rkesĂ« pĂ«r tĂ« marrĂ« tĂ« dhĂ«nat qĂ« tashmĂ« janĂ« fshirĂ«. Por Influx, nĂ« vend tĂ« njĂ« pĂ«rgjigjeje bosh, kthen njĂ« pjesĂ« tĂ« tĂ« dhĂ«nave qĂ« duhej tĂ« ishin fshirĂ«.
Provoj ta fshij të gjithë tabelën:
DROP MEASUREMENT transactionsVerifikoj fshirjen e tabelës:
SHOW MEASUREMENTSTabela nuk shfaqet në listë, por një kërkesë e re për të dhëna ende kthen të njëjtin grup transaksionesh.
Problemi mĂ« ndodhi vetĂ«m njĂ« herĂ«, pasi rasti i fshirjes Ă«shtĂ« i vetmuar. MegjithatĂ«, njĂ« sjellje e tillĂ« e bazĂ«s sĂ« tĂ« dhĂ«nave qartazi nuk hyn nĂ« kufijtĂ« e funksionimit âtĂ« saktĂ«â. MĂ« vonĂ« nĂ« GitHub gjeta njĂ« tĂ« hapur pothuajse prej njĂ« viti pĂ«r kĂ«tĂ« çështje.
Në fund, zgjidhja ishte fshirja dhe më pas rikthimi i gjithë bazës së të dhënave.
2. Numrat me presje lëvizëse
Llogaritjet matematikore gjatë përdorimit të funksioneve të integruara të InfluxDB japin gabime saktësie. Nuk është se kjo është diçka e pazakontë, por është e pakëndshme.
NĂ« rastin tim, tĂ« dhĂ«nat kanĂ« pĂ«rbĂ«rĂ«s financiar dhe do tĂ« doja tâi pĂ«rpunoja me saktĂ«si tĂ« lartĂ«. PĂ«r kĂ«tĂ« arsye, kam nĂ« plan tĂ« heq dorĂ« nga continuous queries.
3. Continuous queries nuk mund të përshtaten për zona të ndryshme kohore
Shërbimi ka një tabelë me statistika ditore për transaksionet. Për çdo ditë duhet të grupohen të gjitha transaksionet e atyre 24 orëve. Por dita për çdo përdorues fillon në kohë të ndryshme, prandaj edhe grupi i transaksioneve është i ndryshëm. Sipas UTC ka zhvendosjeje, për të cilat duhen agreguar të dhënat.
Në InfluxDB, gjatë grupimit sipas kohës mund të specifikohet edhe një zhvendosje, për shembull për orën e Moskës (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Por rezultati i kërkesës do të jetë i pasaktë. Për ndonjë arsye, të dhënat e grupuara sipas ditëve do të fillojnë që në vitin 1677 (InfluxDB zyrtarisht mbështet intervalin kohor duke nisur nga ky vit):
Për ta anashkaluar këtë problem, përkohësisht e kaluam shërbimin në UTC+0.
4. Performanca
Në internet ka shumë benchmark-e me krahasime mes InfluxDB dhe DB-ve të tjera. Në fillim dukeshin si materiale marketingu, por tani mendoj se ka një pjesë të së vërtetës në to.
Po tregoj rastin tim.
Shërbimi ofron një metodë API që kthen statistikat për 24 orët e fundit. Gjatë llogaritjeve, metoda e pyet bazën tri herë me këto kërkesa:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCShpjegim:
- Në kërkesën e parë marrim pikat më të fundit për secilën monedhë me të dhëna të tregut. Në rastin tim, tetë pika për tetë monedha.
- Kërkesa e dytë merr një pikë të vetme, më të fundit.
- E treta kërkon listën e transaksioneve për 24 orët e fundit; ato mund të jenë disa qindra.
Sqaroj se nĂ« InfluxDB ndĂ«rtohet automatikisht njĂ« indeks sipas tag-eve dhe sipas kohĂ«s, i cili i pĂ«rshpejton kĂ«rkesat. NĂ« kĂ«rkesĂ«n e parĂ« symbol â Ă«shtĂ« tag.
Kam kryer një stress-test për këtë metodë API. Me 25 RPS, serveri tregonte ngarkesë të plotë në gjashtë CPU:
Ndërkohë, procesi NodeJs nuk krijonte pothuajse fare ngarkesë.
ShpejtĂ«sia e ekzekutimit degradonte qĂ« nĂ« 7â10 RPS: nĂ«se njĂ« klient mund tĂ« merrte pĂ«rgjigje pĂ«r 200 ms, atĂ«herĂ« 10 klientĂ« duhej tĂ« prisnin nga njĂ« sekondĂ« secili. 25 RPS ishte kufiri ku stabiliteti fillonte tĂ« vuante dhe klientĂ«ve u ktheheshin gabime 500.
Me kĂ«tĂ« performancĂ«, pĂ«rdorimi i Influx nĂ« projektin tonĂ« Ă«shtĂ« i pamundur. Madje edhe nĂ« njĂ« projekt ku monitorimi duhet tâu shfaqet shumĂ« klientĂ«ve, mund tĂ« shfaqen probleme tĂ« ngjashme dhe serveri i metrikave tĂ« mbingarkohet.
PĂ«rfundimi
Përfundimi më i rëndësishëm nga kjo përvojë është se nuk duhet të fusni në projekt një teknologji të panjohur pa analizë të mjaftueshme. Edhe një kontroll i thjeshtë i ticket-eve të hapura në github mund të kishte dhënë informacion të mjaftueshëm për të mos zgjedhur InfluxDB si depo kryesore të të dhënave.
InfluxDB duhej tâu pĂ«rshtatej mirĂ« nevojave tĂ« projektit tim, por praktika tregoi se kjo bazĂ« tĂ« dhĂ«nash nuk i plotĂ«son kĂ«rkesat dhe ka shumĂ« mangĂ«si.
Në repository-n e projektit tashmë mund të gjendet versioni 2.0.0-beta; mbetet vetëm të shpresojmë që versioni i dytë të sjellë përmirësime domethënëse. Ndërkohë, unë do të merrem me studimin e dokumentacionit të TimescaleDB.
Burimi: habr.com
