Dicter, bargeinio ac iselder wrth weithio gydag InfluxDB

Os ydych yn defnyddio cronfa ddata cyfres amser (cyfres amser db, wiki) fel y prif storfa ar gyfer safle gydag ystadegau, yna yn lle datrys y broblem gallwch gael llawer o gur pen. Rwy'n gweithio ar brosiect sy'n defnyddio cronfa ddata o'r fath, ac weithiau roedd InfluxDB, a fydd yn cael ei drafod, yn cyflwyno syrpreisys cwbl annisgwyl.

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 (wiki). Yn seiliedig ar y trafodion hyn, mae angen i chi adeiladu graffiau a dangos tablau crynodeb.

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 (doc). Trefnydd yw hwn sydd wedi'i gynnwys yn y gronfa ddata a all brosesu data ar amserlen. Er enghraifft, bob 24 awr gallwch chi grwpio'r holl gofnodion ar gyfer y diwrnod, cyfrifo'r cyfartaledd a chofnodi un pwynt newydd mewn tabl arall heb ysgrifennu eich beiciau eich hun.

Hefyd wedi polisïau cadw (doc) - sefydlu dileu data ar ôl cyfnod penodol. Mae'n ddefnyddiol, er enghraifft, pan fydd angen i chi storio'r llwyth CPU am wythnos gyda mesuriadau unwaith yr eiliad, ond dros bellter o ychydig fisoedd nid oes angen cywirdeb o'r fath. Mewn sefyllfa o'r fath, gallwch chi wneud hyn:

1. creu ymholiad parhaus i agregu data i dabl arall;
2. 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 tocyn bron i flwyddyn yn ôl ar y pwnc hwn.

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 37 amrywiad sifftiau y mae angen i chi agregu data ar eu cyfer.

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:

1. 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.
2. Mae'r ail gais yn cael un o'r pwyntiau mwyaf newydd.
3. 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