Pyktis, derybos ir depresija dirbant su InfluxDB

Jei naudojate laiko eilučių duomenų bazę (laikoseries db, wiki) kaip pagrindinė svetainės su statistika saugykla, užuot išsprendę problemą, galite sulaukti daug galvos skausmo. Dirbu su projektu, kuriame naudojama tokia duomenų bazė, o kartais InfluxDB, apie kurį bus kalbama, pateikdavo visiškai netikėtų staigmenų.

Atsakomybės neigimas: išvardytos problemos taikomos InfluxDB 1.7.4 versijai.

Kodėl laiko eilutės?

Projektas skirtas sekti operacijas įvairiose blokų grandinėse ir rodyti statistiką. Konkrečiai, mes žiūrime į stabilių monetų išmetimą ir deginimą (wiki). Remdamiesi šiomis operacijomis, turite sudaryti grafikus ir rodyti suvestinės lenteles.

Analizuojant sandorius kilo mintis: kaip pagrindinę saugyklą naudoti InfluxDB laiko eilučių duomenų bazę. Sandoriai yra laiko momentai ir jie gerai dera į laiko eilučių modelį.

Agregavimo funkcijos taip pat atrodė labai patogios – idealiai tinka apdoroti ilgo laikotarpio diagramas. Vartotojui reikia metų diagramos, o duomenų bazėje yra duomenų rinkinys, kurio trukmė yra penkios minutės. Beprasmiška jam siųsti visus šimtą tūkstančių taškų – be ilgo apdorojimo, jie net netilps ekrane. Galite parašyti savo diegimą, kaip padidinti laiko tarpą, arba naudoti „Influx“ integruotas agregavimo funkcijas. Jų pagalba galite grupuoti duomenis pagal dieną ir išsiųsti reikiamus 365 taškus.

Šiek tiek glumino tai, kad tokios duomenų bazės dažniausiai naudojamos metrikos rinkimo tikslu. Serverių, iot įrenginių, visko, iš kurio „teka“ milijonai taškų, stebėjimas: [<time> - <metric value>]. Bet jei duomenų bazė gerai veikia esant dideliam duomenų srautui, kodėl dėl mažo kiekio turėtų kilti problemų? Turėdami tai omenyje, „InfluxDB“ pradėjome dirbti.

Kas dar patogu InfluxDB

Be minėtų agregavimo funkcijų, yra dar vienas puikus dalykas – nuolatinės užklausos (doc). Tai duomenų bazėje įmontuotas planuoklis, galintis apdoroti duomenis pagal tvarkaraštį. Pavyzdžiui, kas 24 valandas galite sugrupuoti visus dienos rekordus, apskaičiuoti vidurkį ir įrašyti vieną naują tašką kitoje lentelėje, nerašydami savo dviračių.

taip pat yra saugojimo politika (doc) – duomenų ištrynimo po tam tikro laikotarpio nustatymas. Tai naudinga, kai, pavyzdžiui, reikia laikyti CPU apkrovą savaitę su matavimais kartą per sekundę, tačiau per poros mėnesių atstumą toks tikslumas nereikalingas. Esant tokiai situacijai, galite tai padaryti:

1. sukurti nuolatinę užklausą duomenims kaupti į kitą lentelę;
2. pirmoje lentelėje apibrėžkite senesnės nei tą pačią savaitę metrikos ištrynimo politiką.

O „Influx“ savarankiškai sumažins duomenų dydį ir ištrins nereikalingus dalykus.

Apie saugomus duomenis

Duomenų saugoma nedaug: apie 70 tūkstančių sandorių ir dar milijonas taškų su rinkos informacija. Naujų įrašų įtraukimas - ne daugiau kaip 3000 taškų per dieną. Taip pat yra svetainės metrikos, tačiau ten mažai duomenų ir pagal saugojimo politiką jie saugomi ne ilgiau kaip mėnesį.

Problemos

Kuriant ir vėliau bandant paslaugą InfluxDB veikloje iškilo vis daugiau kritinių problemų.

1. Duomenų trynimas

Yra keletas duomenų apie operacijas:

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

Rezultatas:

Siunčiu komandą ištrinti duomenis:

DELETE FROM transactions WHERE symbol=’USDT’

Toliau pateikiu prašymą gauti jau ištrintus duomenis. Vietoj tuščio atsakymo „Influx“ grąžina dalį duomenų, kuriuos reikėtų ištrinti.

Bandau ištrinti visą lentelę:

DROP MEASUREMENT transactions

Aš patikrinu lentelės ištrynimą:

SHOW MEASUREMENTS

Sąraše nematau lentelės, bet nauja duomenų užklausa vis tiek pateikia tą patį operacijų rinkinį.

Problema man iškilo tik vieną kartą, nes ištrynimo atvejis buvo pavienis. Tačiau toks duomenų bazės elgesys akivaizdžiai netelpa į „teisingo“ veikimo rėmus. Vėliau radau jį atidarytą „github“. bilietas beveik prieš metus šia tema.

Dėl to padėjo visos duomenų bazės ištrynimas ir atkūrimas.

2. Slankaus kablelio skaičiai

Matematiniai skaičiavimai naudojant InfluxDB integruotas funkcijas turi tikslumo klaidų. Ne tai, kad tai kažkas neįprasta, bet tai nemalonu.

Mano atveju duomenys turi finansinį komponentą ir aš norėčiau juos apdoroti labai tiksliai. Dėl šios priežasties planuojame atsisakyti nuolatinių užklausų.

3. Nuolatinių užklausų negalima pritaikyti skirtingoms laiko juostoms

Paslauga turi lentelę su dienos operacijų statistika. Kiekvieną dieną turite sugrupuoti visas tos dienos operacijas. Tačiau kiekvieno vartotojo diena prasidės skirtingu laiku, todėl operacijų rinkinys skirsis. Pagal UTC taip 37 variantų pamainos, kurių duomenis reikia apibendrinti.

InfluxDB, grupuodami pagal laiką, galite papildomai nurodyti poslinkį, pavyzdžiui, Maskvos laiku (UTC+3):

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

Tačiau užklausos rezultatas bus neteisingas. Dėl tam tikrų priežasčių duomenys, sugrupuoti pagal dienas, prasidės iki 1677 m. (InfluxDB oficialiai palaiko laikotarpį nuo šių metų):

Norėdami išspręsti šią problemą, laikinai perjungėme paslaugą į UTC+0.

4. Atlikimas

Internete yra daug etalonų, kurie lygina InfluxDB ir kitas duomenų bazes. Iš pirmo žvilgsnio jie atrodė kaip rinkodaros medžiaga, bet dabar manau, kad jose yra dalis tiesos.

Aš tau papasakosiu savo atvejį.

Paslauga teikia API metodą, kuris pateikia paskutinės dienos statistiką. Atliekant skaičiavimus, metodas pateikia duomenų bazės užklausas tris kartus su šiomis užklausomis:

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

Paaiškinimas

1. Pirmoje užklausoje už kiekvieną monetą su rinkos duomenimis gauname paskutinius taškus. Mano atveju aštuoni taškai už aštuonias monetas.
2. Antrasis prašymas gauna vieną iš naujausių taškų.
3. Trečiasis prašo paskutinių XNUMX valandų operacijų sąrašo, jų gali būti keli šimtai.

Leiskite paaiškinti, kad InfluxDB automatiškai sukuria indeksą pagal žymas ir laiką, o tai pagreitina užklausas. Pirmajame prašyme simbolis yra žyma.

Atlikau šio API metodo testavimą nepalankiausiomis sąlygomis. Esant 25 RPS, serveris demonstravo visą šešių procesorių apkrovą:

Tuo pačiu metu NodeJ procesas visiškai nesuteikė jokios apkrovos.

Vykdymo greitis jau sumažėjo 7-10 RPS: jei vienas klientas gaudavo atsakymą per 200 ms, tai 10 klientų turėjo palaukti sekundę. 25 RPS yra riba, nuo kurios nukentėjo stabilumas; klientams buvo grąžinta 500 klaidų.

Esant tokiam našumui, mūsų projekte neįmanoma naudoti Influx. Be to: projekte, kur stebėjimą reikia demonstruoti daugeliui klientų, gali atsirasti panašių problemų ir metrikos serveris bus perkrautas.

Produkcija

Svarbiausia išvada iš įgytos patirties yra ta, kad neįtrauksite į projektą nežinomos technologijos be pakankamos analizės. Paprastas „github“ neišspręstų problemų patikrinimas gali suteikti informacijos, kad „InfluxDB“ nebūtų pasirinkta kaip pagrindinė duomenų saugykla.

InfluxDB turėjo puikiai tikti mano projekto užduotims, tačiau, kaip parodė praktika, ši duomenų bazė neatitinka poreikių ir turi daug klaidų.

2.0.0-beta versiją jau galite rasti projekto saugykloje, belieka tikėtis, kad antroji versija turės reikšmingų patobulinimų. Tuo tarpu aš studijuosiu TimescaleDB dokumentaciją.

Šaltinis: www.habr.com