Hasira, majadiliano na unyogovu wakati wa kufanya kazi na InfluxDB

Ikiwa unatumia hifadhidata ya mfululizo wa wakati (timeseries db, wiki) kama hifadhi kuu ya tovuti iliyo na takwimu, basi badala ya kutatua tatizo unaweza kupata maumivu ya kichwa mengi. Ninafanya kazi kwenye mradi unaotumia hifadhidata kama hiyo, na wakati mwingine InfluxDB, ambayo itajadiliwa, iliwasilisha mshangao usiotarajiwa kabisa.

Onyo: Masuala yaliyoorodheshwa yanatumika kwa toleo la InfluxDB 1.7.4.

Kwa nini mfululizo wa saa?

Mradi ni kufuatilia shughuli kwenye blockchains mbalimbali na kuonyesha takwimu. Hasa, tunaangalia utoaji na uchomaji wa sarafu thabiti (wiki) Kulingana na shughuli hizi, unahitaji kujenga grafu na kuonyesha majedwali ya muhtasari.

Wakati wa kuchanganua miamala, wazo lilikuja: kutumia hifadhidata ya mfululizo wa saa ya InfluxDB kama hifadhi kuu. Shughuli za malipo ni pointi kwa wakati na zinafaa katika muundo wa mfululizo wa saa.

Kazi za kujumlisha pia zilionekana kuwa rahisi sana - bora kwa usindikaji wa chati zilizo na muda mrefu. Mtumiaji anahitaji chati ya mwaka mmoja, na hifadhidata ina seti ya data iliyo na muda wa dakika tano. Haina maana kumtumia dots zote laki moja - kando na usindikaji mrefu, hazitatoshea kwenye skrini. Unaweza kuandika utekelezaji wako mwenyewe wa kuongeza muda, au utumie vipengele vya kukokotoa vilivyojumuishwa katika Utitiri. Kwa msaada wao, unaweza kupanga data kwa siku na kutuma pointi 365 zinazohitajika.

Ilikuwa ya kutatanisha kidogo kwamba hifadhidata kama hizo kawaida hutumiwa kwa madhumuni ya kukusanya vipimo. Ufuatiliaji wa seva, vifaa vya iot, kila kitu ambacho mamilioni ya pointi za fomu ya "mtiririko": [ - ]. Lakini ikiwa hifadhidata inafanya kazi vizuri na mtiririko mkubwa wa data, basi kwa nini kiasi kidogo kinapaswa kusababisha shida? Kwa kuzingatia hili, tulichukua InfluxDB kufanya kazi.

Nini kingine ni rahisi katika InfluxDB

Kando na kazi za kujumlisha zilizotajwa, kuna jambo lingine kubwa - maswali yanayoendelea (doc) Hiki ni kipanga ratiba kilichojengwa ndani ya hifadhidata inayoweza kuchakata data kwa ratiba. Kwa mfano, kila saa 24 unaweza kupanga rekodi zote za siku, kuhesabu wastani na kurekodi nukta moja mpya kwenye jedwali lingine bila kuandika baiskeli zako mwenyewe.

Pia uwe sera za uhifadhi (doc)—kuanzisha ufutaji data baada ya muda fulani. Ni muhimu wakati, kwa mfano, unahitaji kuhifadhi mzigo wa CPU kwa wiki na vipimo mara moja kwa sekunde, lakini kwa umbali wa miezi michache usahihi huo hauhitajiki. Katika hali kama hiyo, unaweza kufanya hivi:

1. tengeneza swala endelevu ili kujumlisha data kwenye jedwali lingine;
2. kwa jedwali la kwanza, fafanua sera ya kufuta vipimo ambavyo ni vya zamani zaidi ya wiki hiyo hiyo.

Na Influx itapunguza kwa uhuru ukubwa wa data na kufuta mambo yasiyo ya lazima.

Kuhusu data iliyohifadhiwa

Hakuna data nyingi iliyohifadhiwa: kuhusu shughuli elfu 70 na pointi milioni nyingine na taarifa ya soko. Kuongeza maingizo mapya - si zaidi ya pointi 3000 kwa siku. Pia kuna vipimo vya tovuti, lakini kuna data kidogo huko na, kulingana na sera ya uhifadhi, huhifadhiwa kwa si zaidi ya mwezi.

Shida

Wakati wa ukuzaji na upimaji uliofuata wa huduma, shida zaidi na muhimu zaidi ziliibuka katika uendeshaji wa InfluxDB.

1. Kufuta data

Kuna mfululizo wa data na shughuli:

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

Matokeo:

Ninatuma amri ya kufuta data:

DELETE FROM transactions WHERE symbol=’USDT’

Ifuatayo, ninatuma ombi la kupokea data iliyofutwa tayari. Na badala ya jibu tupu, Utitiri hurejesha sehemu ya data ambayo inapaswa kufutwa.

Ninajaribu kufuta meza nzima:

DROP MEASUREMENT transactions

Ninaangalia ufutaji wa jedwali:

SHOW MEASUREMENTS

Sioni jedwali kwenye orodha, lakini hoja mpya ya data bado inarudisha seti sawa ya shughuli.

Shida ilitokea kwangu mara moja tu, kwani kesi ya kufutwa ilikuwa kesi ya pekee. Lakini tabia hii ya hifadhidata kwa uwazi haifai katika mfumo wa uendeshaji "sahihi". Baadaye nilipata wazi kwenye github tiketi karibu mwaka mmoja uliopita juu ya mada hii.

Kama matokeo, kufuta na kurejesha hifadhidata nzima ilisaidia.

2. Nambari za uhakika zinazoelea

Hesabu za hesabu unapotumia vitendakazi vilivyojengewa ndani katika InfluxDB vina hitilafu za usahihi. Sio kwamba hii sio kawaida, lakini haifurahishi.

Kwa upande wangu, data ina sehemu ya kifedha na ningependa kuichakata kwa usahihi wa hali ya juu. Kwa sababu hii, tunapanga kuachana na maswali yanayoendelea.

3. Hoja zinazoendelea haziwezi kubadilishwa kwa saa za eneo tofauti

Huduma ina meza yenye takwimu za miamala ya kila siku. Kwa kila siku, unahitaji kupanga miamala yote ya siku hiyo. Lakini siku ya kila mtumiaji itaanza kwa wakati tofauti, na kwa hiyo seti ya shughuli itakuwa tofauti. Kwa UTC ndio 37 tofauti mabadiliko ambayo unahitaji kujumlisha data.

Katika InfluxDB, unapoweka kikundi kulingana na wakati, unaweza kutaja zaidi mabadiliko, kwa mfano kwa wakati wa Moscow (UTC+3):

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

Lakini matokeo ya swali yatakuwa sahihi. Kwa sababu fulani, data iliyopangwa kwa siku itaanza hadi 1677 (InfluxDB inasaidia rasmi muda kutoka mwaka huu):

Ili kutatua tatizo hili, tulibadilisha huduma kwa UTC+0 kwa muda.

4. Utendaji

Kuna alama nyingi kwenye Mtandao zinazolinganisha InfluxDB na hifadhidata zingine. Kwa mtazamo wa kwanza, zilionekana kama nyenzo za uuzaji, lakini sasa nadhani kuna ukweli ndani yao.

Nitakuambia kesi yangu.

Huduma hutoa mbinu ya API ambayo inarudisha takwimu za siku ya mwisho. Wakati wa kufanya mahesabu, njia huuliza hifadhidata mara tatu na maswali yafuatayo:

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

Ufafanuzi:

1. Katika ombi la kwanza, tunapata pointi za mwisho kwa kila sarafu iliyo na data ya soko. Pointi nane kwa sarafu nane katika kesi yangu.
2. Ombi la pili linapata mojawapo ya pointi mpya zaidi.
3. Ya tatu inaomba orodha ya miamala kwa saa XNUMX zilizopita; kunaweza kuwa na mamia kadhaa kati yao.

Acha nifafanue kuwa InfluxDB huunda faharasa kiotomatiki kulingana na vitambulisho na wakati, ambayo huharakisha maswali. Katika ombi la kwanza ishara ni tagi.

Nimeendesha mtihani wa mafadhaiko kwenye njia hii ya API. Kwa RPS 25, seva ilionyesha mzigo kamili wa CPU sita:

Wakati huo huo, mchakato wa NodeJs haukutoa mzigo wowote.

Kasi ya utekelezaji tayari imepungua kwa 7-10 RPS: ikiwa mteja mmoja angeweza kupokea jibu katika 200 ms, basi wateja 10 walipaswa kusubiri pili. RPS 25 ni kikomo ambacho utulivu uliteseka; makosa 500 yalirudishwa kwa wateja.

Kwa utendaji kama huo haiwezekani kutumia Influx katika mradi wetu. Zaidi ya hayo: katika mradi ambapo ufuatiliaji unahitaji kuonyeshwa kwa wateja wengi, matatizo sawa yanaweza kuonekana na seva ya vipimo itapakiwa kupita kiasi.

Pato

Hitimisho muhimu zaidi kutokana na uzoefu uliopatikana ni kwamba huwezi kuchukua teknolojia isiyojulikana kwenye mradi bila uchambuzi wa kutosha. Uchunguzi rahisi wa maswala wazi kwenye github unaweza kutoa habari ili kuzuia kuchagua InfluxDB kama duka kuu la data.

InfluxDB inapaswa kuwa inafaa kwa kazi za mradi wangu, lakini kama mazoezi yameonyesha, hifadhidata hii haikidhi mahitaji na ina hitilafu nyingi.

Tayari unaweza kupata toleo la 2.0.0-beta kwenye hazina ya mradi; tunaweza tu kutumaini kwamba toleo la pili litakuwa na maboresho makubwa. Wakati huo huo, nitaenda kusoma nyaraka za TimescaleDB.

Chanzo: mapenzi.com