🥇Nesu, tawar menawar lan depresi nalika nggarap InfluxDB

Yen sampeyan nggunakake database seri wektu (timeseries db, wiki) minangka panyimpenan utama kanggo situs kanthi statistik, banjur tinimbang ngrampungake masalah sampeyan bisa ngelu. Aku nggarap proyek sing nggunakake database kuwi, lan kadhangkala InfluxDB, kang bakal rembugan, presented surprises rampung sing ora dikarepke.

Nolak tanggung jawab: Masalah sing kadhaptar ditrapake kanggo InfluxDB versi 1.7.4.

Kenapa time series?

Proyèk iki kanggo nglacak transaksi ing macem-macem pamblokiran lan nampilake statistik. Secara khusus, kita ndeleng emisi lan kobong koin stabil (wiki). Adhedhasar transaksi kasebut, sampeyan kudu nggawe grafik lan nuduhake tabel ringkesan.

Nalika nganalisa transaksi, ana ide: nggunakake database seri wektu InfluxDB minangka panyimpenan utama. Transaksi minangka titik ing wektu lan pas karo model seri wektu.

Fungsi agregasi uga katon trep banget - cocog kanggo ngolah grafik kanthi wektu sing suwe. Pangguna mbutuhake grafik kanggo setahun, lan database ngemot set data kanthi pigura wektu limang menit. Ora ana gunane ngirim kabeh satus ewu titik - kajaba proses dawa, malah ora bakal pas ing layar. Sampeyan bisa nulis implementasine dhewe kanggo nambah wektu, utawa nggunakake fungsi agregasi dibangun ing Influx. Kanthi bantuan, sampeyan bisa nglumpukake data saben dina lan ngirim 365 poin sing dibutuhake.

Iku rada mbingungake manawa database kasebut biasane digunakake kanggo tujuan ngumpulake metrik. Ngawasi server, piranti iot, kabeh saka ngendi mayuta-yuta titik "aliran": [<wektu> - <nilai metrik>]. Nanging yen basis data bisa dianggo kanthi apik karo aliran data sing gedhe, mula kenapa volume cilik kudu nyebabake masalah? Kanthi pikiran iki, kita njupuk InfluxDB kanggo kerja.

Apa maneh sing trep ing InfluxDB

Kajaba saka fungsi agregasi kasebut, ana liyane sing apik - pitakon terus-terusan (doc). Iki minangka panjadwal sing dibangun ing basis data sing bisa ngolah data kanthi jadwal. Contone, saben 24 jam sampeyan bisa nglumpukake kabeh cathetan kanggo dina, ngetung rata-rata lan ngrekam siji titik anyar ing meja liyane tanpa nulis pit dhewe.

Uga duwe kawicaksanan penylametan (doc) - nyiyapake pambusakan data sawise wektu tartamtu. Migunani yen, contone, sampeyan kudu nyimpen beban CPU sajrone seminggu kanthi pangukuran sapisan saben detik, nanging sajrone sawetara wulan, akurasi kasebut ora dibutuhake. Ing kahanan kaya mengkono, sampeyan bisa nindakake iki:

nggawe pitakon terus-terusan kanggo nglumpukake data menyang tabel liyane;
kanggo tabel pisanan, nemtokake kabijakan kanggo mbusak metrik sing luwih lawas tinimbang minggu sing padha.

Lan Influx bakal nyuda ukuran data kanthi mandiri lan mbusak barang sing ora perlu.

Babagan data sing disimpen

Ora akeh data sing disimpen: udakara 70 ewu transaksi lan yuta poin liyane kanthi informasi pasar. Nambahake entri anyar - ora luwih saka 3000 poin saben dina. Ana uga metrik kanggo situs kasebut, nanging ana data sing sithik lan, miturut kabijakan retensi, disimpen ora luwih saka sasi.

Masalah

Sajrone pangembangan lan uji coba layanan kasebut, masalah sing luwih kritis muncul ing operasi InfluxDB.

1. Mbusak data

Ana seri data karo transaksi:

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

Asil:

Aku ngirim prentah kanggo mbusak data:

DELETE FROM transactions WHERE symbol=’USDT’

Sabanjure aku njaluk panjaluk kanggo nampa data sing wis dibusak. Lan tinimbang respon kosong, Influx ngasilake bagean saka data sing kudu dibusak.

Aku nyoba mbusak kabeh tabel:

DROP MEASUREMENT transactions

Aku mriksa pambusakan tabel:

SHOW MEASUREMENTS

Aku ora weruh tabel ing dhaftar, nanging pitakonan data anyar isih ngasilake pesawat padha transaksi.

Masalah kasebut mung kedadeyan sepisan, amarga kasus pambusakan minangka kasus sing ora ana. Nanging prilaku database iki cetha ora pas karo framework saka operasi "bener". Mengko aku ketemu mbukak ing github tiket meh setahun kepungkur babagan topik iki.

Akibaté, mbusak banjur mulihake kabeh database mbantu.

2. Angka floating point

Petungan matematika nalika nggunakake fungsi sing dibangun ing InfluxDB duwe kesalahan akurasi. Ora iki apa-apa mboten umum, nanging ora nyenengake.

Ing kasusku, data kasebut nduweni komponen finansial lan aku pengin ngolah kanthi akurasi sing dhuwur. Amarga iki, kita rencana kanggo ninggalake pitakon terus-terusan.

3. Pitakonan terus-terusan ora bisa diadaptasi menyang zona wektu sing beda

Layanan kasebut duwe tabel kanthi statistik transaksi saben dina. Kanggo saben dina, sampeyan kudu nglumpukake kabeh transaksi kanggo dina kasebut. Nanging saben dina pangguna bakal diwiwiti ing wektu sing beda, lan mulane set transaksi bakal beda. Miturut UTC ya 37 jinis owah-owahan sing sampeyan kudu nglumpukake data.

Ing InfluxDB, nalika dikelompokake miturut wektu, sampeyan bisa uga nemtokake shift, contone kanggo wektu Moskow (UTC+3):

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

Nanging asil pitakon bakal salah. Kanggo sawetara alasan, data sing diklompokake miturut dina bakal diwiwiti kabeh bali menyang 1677 (InfluxDB resmi ndhukung rentang wektu wiwit taun iki):

Kanggo ngatasi masalah iki, kita sementara ngalih layanan menyang UTC+0.

4. Kinerja

Ana akeh benchmark ing Internet sing mbandhingake InfluxDB lan database liyane. Ing kawitan marketing, padha katon kaya materi marketing, nanging saiki aku ana sawetara bebener ing wong.

Aku bakal ngandhani kasusku.

Layanan kasebut nyedhiyakake cara API sing ngasilake statistik kanggo dina pungkasan. Nalika nglakokake petungan, metode kasebut takon database kaping telu kanthi pitakon ing ngisor iki:

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

Panjelasan

Ing panjalukan pisanan, kita entuk poin pungkasan kanggo saben koin kanthi data pasar. Wolung poin kanggo wolung dhuwit recehan ing kasusku.
Panyuwunan kapindho entuk salah sawijining poin paling anyar.
Sing nomer telu njaluk dhaptar transaksi sajrone XNUMX jam pungkasan; bisa uga ana sawetara atus.

Ayo kula njlentrehake manawa InfluxDB kanthi otomatis nggawe indeks adhedhasar tag lan wektu, sing nyepetake pitakon. Ing panjalukan pisanan simbol iku tag.

Aku wis mbukak test kaku ing cara API iki. Kanggo 25 RPS, server nuduhake beban lengkap enem CPU:

Ing wektu sing padha, proses NodeJs ora nyedhiyakake beban apa wae.

Kacepetan eksekusi wis mudhun 7-10 RPS: yen siji klien bisa nampa respon ing 200 ms, banjur 10 klien kudu ngenteni detik. 25 RPS minangka watesan sing nandhang stabilitas; 500 kesalahan bali menyang klien.

Kanthi kinerja kasebut, ora mungkin nggunakake Influx ing proyek kita. Kajaba iku: ing proyek ing ngendi pemantauan kudu dituduhake menyang akeh klien, masalah sing padha bisa uga katon lan server metrik bakal kakehan.

kesimpulan

Kesimpulan sing paling penting saka pengalaman sing dipikolehi yaiku sampeyan ora bisa njupuk teknologi sing ora dingerteni menyang proyek tanpa analisa sing cukup. Saringan prasaja masalah mbukak ing github bisa menehi informasi supaya ora milih InfluxDB minangka nyimpen data utama.

InfluxDB mesthine cocog kanggo tugas proyekku, nanging kaya sing dituduhake praktik, database iki ora nyukupi kabutuhan lan akeh kewan omo.

Sampeyan wis bisa nemokake versi 2.0.0-beta ing repositori proyek; kita mung bisa ngarep-arep yen versi kapindho bakal ngalami dandan sing signifikan. Ing sawetoro wektu, aku bakal sinau dokumentasi TimescaleDB.

Source: www.habr.com

Nesu, tawar-menawar lan depresi nalika nggarap InfluxDB