Reiði, samningaviðræður og þunglyndi þegar unnið er með InfluxDB

Ef þú notar tímaröð gagnagrunn (tímaröð db, Wiki) sem aðal geymsla fyrir síðu með tölfræði, þá geturðu fengið mikinn höfuðverk í stað þess að leysa vandamálið. Ég er að vinna að verkefni sem notar slíkan gagnagrunn og stundum kom InfluxDB, sem fjallað verður um, algjörlega óvænt á óvart.

Afneitun ábyrgðar: Málin sem talin eru upp eiga við um InfluxDB útgáfu 1.7.4.

Hvers vegna tímaraðir?

Verkefnið er að fylgjast með viðskiptum á ýmsum blockchains og sýna tölfræði. Nánar tiltekið skoðum við losun og brennslu stöðugra mynta (Wiki). Byggt á þessum viðskiptum þarftu að búa til línurit og sýna yfirlitstöflur.

Við greiningu á viðskiptum kom upp hugmynd: að nota InfluxDB tímaraðargagnagrunninn sem aðalgeymslu. Viðskipti eru tímapunktar og passa vel inn í tímaraðarlíkanið.

Söfnunaraðgerðirnar virtust líka mjög þægilegar - tilvalið til að vinna töflur með langan tíma. Notandinn þarf töflu fyrir eitt ár og gagnagrunnurinn inniheldur gagnasett með tímaramma upp á fimm mínútur. Það er tilgangslaust að senda honum alla hundrað þúsund punkta - fyrir utan langa vinnslu passa þeir ekki einu sinni á skjáinn. Þú getur skrifað þína eigin útfærslu til að auka tímaramma, eða notað samansafnunaraðgerðirnar sem eru innbyggðar í innflæði. Með hjálp þeirra geturðu flokkað gögn eftir degi og sent nauðsynleg 365 stig.

Það var svolítið ruglingslegt að slíkir gagnagrunnar eru venjulega notaðir í þeim tilgangi að safna mæligildum. Vöktun á netþjónum, IOT tækjum, allt þaðan sem milljónir punkta af forminu „flæða“: [<tími> - <mæligildi>]. En ef gagnagrunnurinn virkar vel með miklu gagnaflæði, hvers vegna ætti lítið magn þá að valda vandamálum? Með þetta í huga tókum við InfluxDB til vinnu.

Hvað annað er þægilegt í InfluxDB

Burtséð frá nefndum samansafnunaraðgerðum, þá er annar frábær hlutur - stöðugar fyrirspurnir (doc). Þetta er tímaáætlun innbyggður í gagnagrunninn sem getur unnið úr gögnum á áætlun. Til dæmis, á sólarhrings fresti geturðu flokkað allar færslur dagsins, reiknað meðaltalið og skráð einn nýjan punkt í aðra töflu án þess að skrifa eigin reiðhjól.

Hef líka varðveislustefnur (doc) — setja upp eyðingu gagna eftir ákveðinn tíma. Það er gagnlegt þegar þú þarft til dæmis að geyma örgjörvahleðsluna í viku með mælingum einu sinni á sekúndu, en á nokkra mánaða vegalengd er ekki þörf á slíkri nákvæmni. Í slíkum aðstæðum geturðu gert þetta:

1. búa til samfellda fyrirspurn til að safna gögnum í aðra töflu;
2. fyrir fyrstu töflu, skilgreindu stefnu til að eyða mælingum sem eru eldri en sömu vikuna.

Og Influx mun sjálfstætt draga úr stærð gagna og eyða óþarfa hlutum.

Um vistuð gögn

Ekki eru geymd mikil gögn: um 70 þúsund færslur og á aðra milljón punkta með markaðsupplýsingum. Að bæta við nýjum færslum - ekki meira en 3000 stig á dag. Það eru líka til mælikvarðar fyrir síðuna, en lítil gögn eru þar og samkvæmt varðveislustefnu eru þau geymd í ekki meira en mánuð.

Vandamál

Við þróun og síðari prófun þjónustunnar komu upp fleiri og mikilvægari vandamál í rekstri InfluxDB.

1. Eyða gögnum

Það er röð af gögnum með viðskiptum:

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

Niðurstaða:

Ég er að senda skipun til að eyða gögnum:

DELETE FROM transactions WHERE symbol=’USDT’

Næst bið ég um að fá gögnin sem þegar hefur verið eytt. Og í stað þess að vera innantómt svar skilar Influx hluta af gögnunum sem ætti að eyða.

Ég er að reyna að eyða allri töflunni:

DROP MEASUREMENT transactions

Ég athuga eyðingu töflunnar:

SHOW MEASUREMENTS

Ég sé ekki töfluna á listanum, en ný gagnafyrirspurn skilar samt sömu færslum.

Vandamálið kom aðeins einu sinni fyrir mig þar sem eyðingarmálið var einstakt tilvik. En þessi hegðun gagnagrunnsins passar greinilega ekki inn í ramma „réttar“ aðgerða. Seinna fann ég það opið á github miða fyrir tæpu ári um þetta efni.

Þess vegna hjálpaði það að eyða og endurheimta allan gagnagrunninn.

2. Flottölur

Stærðfræðiútreikningar þegar innbyggðar aðgerðir eru notaðar í InfluxDB hafa nákvæmnisvillur. Ekki það að þetta sé eitthvað óvenjulegt, en það er óþægilegt.

Í mínu tilviki hafa gögnin fjárhagslegan þátt og mig langar að vinna úr þeim af mikilli nákvæmni. Vegna þessa ætlum við að hætta við stöðugar fyrirspurnir.

3. Ekki er hægt að laga stöðugar fyrirspurnir að mismunandi tímabeltum

Þjónustan er með töflu með daglegum viðskiptatölfræði. Fyrir hvern dag þarftu að flokka allar færslur fyrir þann dag. En dagur hvers notanda mun byrja á öðrum tíma og því verður færslusafnið öðruvísi. Með UTC já 37 afbrigði vaktir sem þú þarft að safna gögnum fyrir.

Í InfluxDB, þegar þú flokkar eftir tíma, geturðu auk þess tilgreint vakt, til dæmis fyrir Moskvutíma (UTC+3):

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

En niðurstaða fyrirspurnarinnar verður röng. Af einhverjum ástæðum munu gögn flokkuð eftir degi hefjast allt aftur til 1677 (InfluxDB styður opinberlega tímabil frá þessu ári):

Til að vinna í kringum þetta vandamál skiptum við þjónustunni tímabundið yfir í UTC+0.

4. Frammistaða

Það eru mörg viðmið á netinu sem bera saman InfluxDB og aðra gagnagrunna. Við fyrstu sýn litu þau út eins og markaðsefni en nú held ég að það sé einhver sannleikur í þeim.

Ég skal segja þér mál mitt.

Þjónustan býður upp á API aðferð sem skilar tölfræði fyrir síðasta dag. Þegar útreikningar eru framkvæmdir spyr aðferðin þrisvar sinnum í gagnagrunninn með eftirfarandi fyrirspurnum:

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

Skýring:

1. Í fyrstu beiðninni fáum við síðustu stigin fyrir hverja mynt með markaðsgögnum. Átta stig fyrir átta mynt í mínu tilfelli.
2. Önnur beiðnin fær einn af nýjustu punktunum.
3. Sá þriðji biður um lista yfir færslur síðasta sólarhringinn; þær geta verið nokkur hundruð.

Leyfðu mér að skýra að InfluxDB byggir sjálfkrafa vísitölu byggða á merkjum og tíma, sem flýtir fyrir fyrirspurnum. Í fyrstu beiðni tákn er merki.

Ég hef keyrt álagspróf á þessari API aðferð. Fyrir 25 RPS sýndi þjónninn fullt álag af sex örgjörvum:

Á sama tíma veitti NodeJs ferlið alls ekki álag.

Framkvæmdarhraði hefur þegar minnkað um 7-10 RPS: ef einn viðskiptavinur gat fengið svar á 200 ms, þá þurftu 10 viðskiptavinir að bíða í sekúndu. 25 RPS eru mörkin sem stöðugleiki varð fyrir; 500 villum var skilað til viðskiptavina.

Með slíkri frammistöðu er ómögulegt að nota Influx í verkefninu okkar. Þar að auki: í verkefni þar sem sýna þarf eftirlit fyrir mörgum viðskiptavinum, geta svipuð vandamál komið upp og mælingaþjónninn verður ofhlaðinn.

Output

Mikilvægasta niðurstaðan af fenginni reynslu er sú að ekki er hægt að taka óþekkta tækni inn í verkefni án nægrar greiningar. Einföld skimun á opnum málum á github gæti veitt upplýsingar til að forðast að velja InfluxDB sem aðalgagnageymslu.

InfluxDB hefði átt að passa vel við verkefni verkefnisins míns, en eins og æfingin hefur sýnt þá uppfyllir þessi gagnagrunnur ekki þarfir og hefur mikið af villum.

Þú getur nú þegar fundið útgáfu 2.0.0-beta í verkefnageymslunni; við getum aðeins vonað að seinni útgáfan muni hafa verulegar endurbætur. Í millitíðinni mun ég fara að kynna mér TimescaleDB skjölin.

Heimild: www.habr.com