Denbora serieen datu-base bat erabiltzen baduzu (timeseries db, ) estatistikak dituen gune baten biltegiratze nagusi gisa, orduan arazoa konpondu beharrean, buruhauste asko sor ditzakezu. Horrelako datu-base bat erabiltzen duen proiektu batean ari naiz lanean, eta batzuetan eztabaidatuko den InfluxDB-k ustekabeko sorpresak aurkeztu zituen.
Lege-oharraOharra: erakusten diren arazoak InfluxDB 1.7.4rako dira.
Zergatik denbora seriea?
Proiektua hainbat blockchain-en transakzioak jarraitzea eta estatistikak bistaratzea da. Zehazki, txanpon egonkorren igorpena eta erretzea aztertzen dugu (). Transakzio horietan oinarrituta, grafikoak eraiki eta taula dinamikoak erakutsi behar dituzu.
Transakzioak aztertzean, ideia bat sortu zen: InfluxDB denbora serieen datu-basea biltegiratze nagusi gisa erabiltzea. Transakzioak denbora-puntuak dira eta denbora-seriearen ereduan ondo sartzen dira.
Agregazio-funtzioak ere oso erosoak ziren: epe luzeko diagramak prozesatzeko aproposa dira. Erabiltzaileak urtebeterako diagrama bat behar du, eta datu-baseak bost minutuko denbora-tarte bat dauka. Alferrikakoa da ehun mila puntu guztiak hari bidaltzea - ββprozesamendu luze bat izan ezik, ez dira pantailan sartuko. Epea handitzeko zure inplementazioa idatzi dezakezu edo Influx-en integratutako agregazio-funtzioak erabil ditzakezu. Haien laguntzarekin, datuak egunez taldeka ditzakezu eta eskatutako 365 puntuak bidali.
Pixka bat lotsagarria zen normalean horrelako datu-baseak neurriak biltzeko erabiltzen direla. Zerbitzarien monitorizazioa, iot gailuak, zeinetatik "fluxua" formako milioika puntuak: [<denbora> - <balio metrikoa>]. Baina datu-baseak datu-korronte handi batekin ondo funtzionatzen badu, zergatik eragin beharko lituzke bolumen txiki batek arazoak? Pentsamendu horrekin, InfluxDB eraman zuten lanera.
Zer gehiago komeni da InfluxDB-n
Aipatutako agregazio-funtzioez gain, beste gauza handi bat dago - etengabeko kontsultak (). Datu-basean txertatutako programatzaile bat da, eta programazio batean datuak prozesatu ditzake. Adibidez, eguneko erregistro guztiak 24 orduz behin taldeka ditzakezu, batez bestekoa kalkulatu eta puntu berri bat beste taula batean idatzi zure bizikletak idatzi gabe.
ez dago bat ere atxikipen politikak () - epe jakin baten ondoren datuak ezabatzeko ezarpena. Baliagarria da, adibidez, PUZaren karga astebetez gorde behar duzunean segundoko neurketekin, baina pare bat hilabeteko distantziara ez da beharrezkoa halako zehaztasuna. Egoera horretan, hau egin dezakezu:
- sortu etengabeko kontsulta bat datuak beste taula batean batzeko;
- lehenengo taularako, zehaztu aste bera baino zaharragoak diren neurketak ezabatzeko politika.
Eta Influx-ek datuen tamaina murriztuko du eta beharrezkoak ez diren datuak bere kabuz ezabatuko ditu.
Biltegiratutako datuei buruz
Ez da datu asko gordetzen: 70 mila transakzio inguru eta beste milioi puntu merkatuko informazioarekin. Sarrera berriak gehitzea - ββegunean 3000 puntu baino gehiago. Gunearen neurketak ere badaude, baina datu gutxi daude bertan eta, atxikipen politikaren arabera, hilabete baino gehiago ez dira gordetzen.
Problems
Zerbitzuaren garapenean eta ondorengo probetan, gero eta arazo larriagoak sortu ziren InfluxDBren funtzionamenduan.
1. Datuak ezabatzea
Transakzioekin datu batzuk daude:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Emaitza:
Datuak ezabatzeko komando bat bidaltzen dut:
DELETE FROM transactions WHERE symbol=βUSDTβGainera, dagoeneko ezabatutako datuak lortzeko eskatzen dut. Eta Influx-ek, erantzun huts baten ordez, kendu beharreko datu bat itzultzen du.
Taula osoa ezabatzen saiatzen ari naiz:
DROP MEASUREMENT transactionsTaularen ezabaketa egiaztatzen dut:
SHOW MEASUREMENTSEz dut zerrendan taula ikusten, baina datu-kontsulta berriak transakzio multzo bera itzultzen du oraindik.
Arazoa behin bakarrik sortu zitzaidan, ezabatze kasua kasu isolatua baita. Baina datu-basearen portaera hori argi eta garbi ez dator bat lan "zuzenaren" esparruan. Geroago github irekita aurkitu da ia urte bat gai honi buruz.
Ondorioz, datu-base osoa kentzeak eta ondorengo zaharberritzeak lagundu zuen.
2. Koma mugikorreko zenbakiak
InfluxDBren funtzio integratuak erabiliz kalkulu matematikoek zehaztasun akatsak ematen dituzte. Ez da arraroa den ezer, desatsegina baizik.
Nire kasuan, datuek finantza-osagai bat dute eta zehaztasun handiz prozesatu nahiko nuke. Horregatik, etengabeko kontsultak bertan behera uzteko asmoa dugu.
3. Etengabeko kontsultak ezin dira egokitu ordu-eremu ezberdinetara
Zerbitzuak eguneroko transakzioen estatistikak dituen taula bat du. Egun bakoitzeko, egun horretako transakzio guztiak taldekatu behar dituzu. Baina erabiltzaile bakoitzaren eguna ordu ezberdin batean hasiko da, beraz, transakzio multzoa ezberdina da. UTC da datuak batu nahi dituzun txandak.
InfluxDB-n, orduaren arabera taldekatzean, aldaketa bat ere zehaztu dezakezu, adibidez, Moskuko ordurako (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Baina kontsultaren emaitza okerra izango da. Arrazoiren batengatik, egunaren arabera taldekatuta dauden datuak 1677an hasiko dira (InfluxDB-k urte honetako denbora tarte bat onartzen du ofizialki):
Arazo hau saihesteko, zerbitzua UTC + 0ra transferitu zen aldi baterako.
4. Errendimendua
Interneten erreferentzia ugari daude InfluxDB eta beste datu-baseen konparaketarekin. Lehen begiratuan, marketin-materialak ziruditen, baina orain uste dut badela egiaren bat.
Utzidazu nire kasua kontatzen.
Zerbitzuak azken XNUMX orduetako estatistikak itzultzen dituen API metodo bat eskaintzen du. Kalkuluetan, metodoak hiru aldiz kontsultatzen du datu-basea honako kontsulta hauekin:
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 DESCAzalpena:
- Lehenengo eskaeran, merkatuko datuekin txanpon bakoitzeko azken puntuak lortzen ditugu. Zortzi puntu zortzi txanpontarako nire kasuan.
- Bigarren eskaerak puntu berriena lortzen du.
- Hirugarrenak azken XNUMX orduetako transakzioen zerrenda eskatzen du, ehunka izan daitezke.
Argitu dezadan InfluxDB-n indize bat automatikoki eraikitzen dela etiketen eta denboraren arabera, eta horrek kontsultak bizkortzen ditu. Lehenengo eskaeran sinboloa etiketa bat da.
API metodo honetarako estres proba bat egin nuen. 25 RPS-rako, zerbitzariak sei CPUren karga osoa erakutsi zuen:
Aldi berean, NodeJs prozesuak ez zuen inolako kargarik eman.
Exekuzio-abiadura jada 7-10 RPS-rekin degradatu zen: bezero batek 200 ms-tan erantzuna jaso zezakeen, orduan 10 bezerok segundo bat itxaron behar zuten. 25 RPS - egonkortasuna jasan zuen muga, 500 akats itzuli zitzaizkien bezeroei.
Horrelako errendimenduarekin, ezinezkoa da gure proiektuan Influx erabiltzea. Gainera, monitorizazioa bezero askori frogatu behar den proiektu batean, antzeko arazoak ager daitezke eta metrika zerbitzaria gainkargatu egingo da.
Irteera
Lortutako esperientziatik ateratako ondoriorik garrantzitsuena da ezin dela teknologia ezezagun bat proiektu batean hartu behar adina analisirik gabe. Github-en irekitako txartelen emanaldia sinple batek InfluxDB datu biltegi nagusi gisa ez hartzeko informazioa eman lezake.
InfluxDB nire proiektuko zereginetara ondo egokitu behar zen, baina praktikak erakutsi duenez, datu-base honek ez ditu beharrak asetzen eta asko nahasten ditu.
Dagoeneko 2.0.0-beta bertsioa aurki dezakezu proiektuaren biltegian, bigarren bertsioan hobekuntza nabarmenak izango direla espero da. Bitartean, TimescaleDB dokumentazioa aztertzen joango naiz.
Iturria: www.habr.com