Os ydych yn defnyddio cronfa ddata cyfres amser (cyfres amser db,
Ymwadiad: Mae'r materion a restrir yn berthnasol i fersiwn InfluxDB 1.7.4.
Pam cyfres amser?
Bwriad y prosiect yw olrhain trafodion ar amrywiol blockchains ac arddangos ystadegau. Yn benodol, edrychwn ar allyrru a llosgi darnau arian sefydlog (
Wrth ddadansoddi trafodion, daeth syniad i'r amlwg: defnyddio cronfa ddata cyfres amser InfluxDB fel y prif storfa. Pwyntiau amser yw trafodion ac maent yn cyd-fynd yn dda â'r model cyfres amser.
Roedd y swyddogaethau agregu hefyd yn edrych yn gyfleus iawn - yn ddelfrydol ar gyfer prosesu siartiau gyda chyfnod hir. Mae angen siart ar y defnyddiwr am flwyddyn, ac mae'r gronfa ddata yn cynnwys set ddata gyda ffrâm amser o bum munud. Mae'n ddibwrpas anfon can mil o ddotiau ato - ar wahân i brosesu hir, ni fyddant hyd yn oed yn ffitio ar y sgrin. Gallwch ysgrifennu eich gweithrediad eich hun o gynyddu'r amserlen, neu ddefnyddio'r swyddogaethau agregu sydd wedi'u cynnwys yn Mewnlifiad. Gyda'u cymorth, gallwch chi grwpio data yn ystod y dydd ac anfon y 365 pwynt gofynnol.
Roedd ychydig yn ddryslyd bod cronfeydd data o'r fath yn cael eu defnyddio fel arfer at ddiben casglu metrigau. Monitro gweinyddwyr, dyfeisiau iot, popeth y mae miliynau o bwyntiau o'r ffurflen yn “llifo” ohono: [ - ]. Ond os yw'r gronfa ddata yn gweithio'n dda gyda llif data mawr, yna pam ddylai cyfaint bach achosi problemau? Gyda hyn mewn golwg, aethom ag InfluxDB i weithio.
Beth arall sy'n gyfleus yn InfluxDB
Ar wahân i'r swyddogaethau agregu a grybwyllwyd, mae peth gwych arall - ymholiadau parhaus (
Hefyd wedi polisïau cadw (
- creu ymholiad parhaus i agregu data i dabl arall;
- ar gyfer y tabl cyntaf, diffiniwch bolisi ar gyfer dileu metrigau sy'n hŷn na'r un wythnos.
A bydd Mewnlifiad yn lleihau maint y data yn annibynnol ac yn dileu pethau diangen.
Ynglŷn â data sydd wedi'i storio
Nid oes llawer o ddata yn cael ei storio: tua 70 mil o drafodion a miliwn arall o bwyntiau gyda gwybodaeth am y farchnad. Ychwanegu cofnodion newydd - dim mwy na 3000 o bwyntiau'r dydd. Mae yna fetrigau ar gyfer y safle hefyd, ond ychydig o ddata sydd yno ac, yn ôl y polisi cadw, maent yn cael eu storio am ddim mwy na mis.
Problemau
Yn ystod datblygiad a phrofion dilynol y gwasanaeth, cododd mwy a mwy o broblemau critigol yng ngweithrediad InfluxDB.
1. Dileu data
Mae cyfres o ddata gyda thrafodion:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'
Canlyniad:
Rwy'n anfon gorchymyn i ddileu data:
DELETE FROM transactions WHERE symbol=’USDT’
Nesaf rwy'n gwneud cais i dderbyn y data sydd eisoes wedi'i ddileu. Ac yn lle ymateb gwag, mae Influx yn dychwelyd rhan o'r data y dylid ei ddileu.
Rwy'n ceisio dileu'r tabl cyfan:
DROP MEASUREMENT transactions
Rwy'n gwirio'r dileu tabl:
SHOW MEASUREMENTS
Dydw i ddim yn gweld y tabl yn y rhestr, ond mae ymholiad data newydd yn dal i ddychwelyd yr un set o drafodion.
Dim ond unwaith y digwyddodd y broblem i mi, gan fod yr achos dileu yn achos unigol. Ond mae'n amlwg nad yw ymddygiad y gronfa ddata yn cyd-fynd â'r fframwaith gweithredu "cywir". Yn ddiweddarach cefais ei fod yn agored ar github
O ganlyniad, helpodd dileu ac yna adfer y gronfa ddata gyfan.
2. Rhifau pwynt arnawf
Mae gwallau cywirdeb mewn cyfrifiadau mathemateg wrth ddefnyddio ffwythiannau adeiledig yn InfluxDB. Nid bod hyn yn unrhyw beth anarferol, ond mae'n annymunol.
Yn fy achos i, mae gan y data elfen ariannol a hoffwn ei brosesu gyda chywirdeb uchel. Oherwydd hyn, rydym yn bwriadu rhoi'r gorau i ymholiadau parhaus.
3. Ni ellir addasu ymholiadau parhaus i barthau amser gwahanol
Mae gan y gwasanaeth dabl gydag ystadegau trafodion dyddiol. Ar gyfer pob diwrnod, mae angen i chi grwpio'r holl drafodion ar gyfer y diwrnod hwnnw. Ond bydd diwrnod pob defnyddiwr yn dechrau ar amser gwahanol, ac felly bydd y set o drafodion yn wahanol. Gan UTC ie
Yn InfluxDB, wrth grwpio yn ôl amser, gallwch hefyd nodi shifft, er enghraifft ar gyfer amser Moscow (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)
Ond bydd canlyniad yr ymholiad yn anghywir. Am ryw reswm, bydd data wedi'u grwpio fesul dydd yn cychwyn yr holl ffordd yn ôl i 1677 (mae InfluxDB yn cefnogi cyfnod amser o eleni yn swyddogol):
I ddatrys y broblem hon, fe wnaethom newid y gwasanaeth dros dro i UTC+0.
4. Perfformiad
Mae yna lawer o feincnodau ar y Rhyngrwyd sy'n cymharu InfluxDB a chronfeydd data eraill. Ar yr olwg gyntaf, roeddent yn edrych fel deunyddiau marchnata, ond nawr rwy'n credu bod rhywfaint o wirionedd ynddynt.
Fe ddywedaf fy achos wrthych.
Mae'r gwasanaeth yn darparu dull API sy'n dychwelyd ystadegau ar gyfer y diwrnod olaf. Wrth wneud cyfrifiadau, mae'r dull yn holi'r gronfa ddata deirgwaith gyda'r ymholiadau canlynol:
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
Esboniad:
- Yn y cais cyntaf, rydym yn cael y pwyntiau olaf ar gyfer pob darn arian gyda data'r farchnad. Wyth pwynt am wyth darn arian yn fy achos i.
- Mae'r ail gais yn cael un o'r pwyntiau mwyaf newydd.
- Mae'r trydydd yn gofyn am restr o drafodion ar gyfer y 24 awr ddiwethaf; efallai y bydd rhai cannoedd ohonynt.
Gadewch imi egluro bod InfluxDB yn adeiladu mynegai yn awtomatig yn seiliedig ar dagiau ac amser, sy'n cyflymu ymholiadau. Yn y cais cyntaf symbol yn dag.
Rwyf wedi cynnal prawf straen ar y dull API hwn. Ar gyfer 25 RPS, dangosodd y gweinydd lwyth llawn o chwe CPUs:
Ar yr un pryd, ni ddarparodd proses NodeJs unrhyw lwyth o gwbl.
Mae'r cyflymder gweithredu eisoes wedi diraddio gan 7-10 RPS: pe gallai un cleient dderbyn ymateb mewn 200 ms, yna bu'n rhaid i 10 cleient aros eiliad. 25 RPS yw’r terfyn ar gyfer sefydlogrwydd; dychwelwyd 500 o wallau i gleientiaid.
Gyda pherfformiad o'r fath mae'n amhosibl defnyddio Mewnlifiad yn ein prosiect. Ar ben hynny: mewn prosiect lle mae angen dangos monitro i lawer o gleientiaid, gall problemau tebyg ymddangos a bydd y gweinydd metrigau yn cael ei orlwytho.
Allbwn
Y casgliad pwysicaf o'r profiad a gafwyd yw na allwch fynd â thechnoleg anhysbys i mewn i brosiect heb ddadansoddiad digonol. Gallai sgrinio syml o faterion agored ar github ddarparu gwybodaeth i osgoi dewis InfluxDB fel y brif storfa ddata.
Dylai InfluxDB fod wedi ffitio'n dda ar gyfer tasgau fy mhrosiect, ond fel y dangosodd arfer, nid yw'r gronfa ddata hon yn bodloni'r anghenion ac mae ganddi lawer o fygiau.
Gallwch chi eisoes ddod o hyd i fersiwn 2.0.0-beta yn ystorfa'r prosiect; ni allwn ond gobeithio y bydd gan yr ail fersiwn welliannau sylweddol. Yn y cyfamser, af i astudio dogfennaeth TimescaleDB.
Ffynhonnell: hab.com