Amarah, nawar sareng déprési nalika damel sareng InfluxDB

Upami anjeun nganggo database deret waktos (timeseries db, wiki) salaku gudang utama pikeun situs kalayan statistik, lajeng tinimbang ngarengsekeun masalah anjeun bisa meunang loba headaches. Kuring keur dipake dina proyék nu ngagunakeun database misalna, sarta kadangkala InfluxDB, nu bakal dibahas, dibere kejutan lengkep kaduga.

Bantahan: Masalah anu didaptarkeun manglaku ka InfluxDB versi 1.7.4.

Naha runtuyan waktu?

Proyék nyaéta pikeun ngalacak transaksi dina sagala rupa blockchains sareng ningalikeun statistik. Husus, urang ningali émisi sareng ngaduruk koin stabil (wiki). Dumasar kana transaksi ieu, anjeun kedah ngawangun grafik sareng nunjukkeun tabel kasimpulan.

Nalika nganalisa transaksi, muncul ide: ngagunakeun database séri waktos InfluxDB salaku panyimpen utama. Transaksi mangrupikeun titik dina waktos sareng aranjeunna pas kana modél séri waktos.

Fungsi agrégasi ogé katingali saé pisan - idéal pikeun ngolah grafik kalayan waktos anu lami. Pamaké peryogi bagan pikeun sataun, sareng pangkalan data ngandung set data kalayan pigura waktos lima menit. Henteu aya gunana pikeun ngirim anjeunna sadayana saratus rébu titik - sajaba ti ngolah anu panjang, aranjeunna moal pas dina layar. Anjeun tiasa nyerat palaksanaan anjeun nyalira pikeun ningkatkeun waktosna, atanapi nganggo fungsi agrégasi anu diwangun kana Influx. Kalayan bantosanana, anjeun tiasa ngagolongkeun data sadinten sareng ngirim 365 poin anu diperyogikeun.

Éta rada ngabingungkeun yén pangkalan data sapertos kitu biasana dianggo pikeun tujuan ngumpulkeun métrik. Ngawaskeun server, alat iot, sagalana ti mana jutaan titik tina bentuk "ngalir": [<waktu> - <nilai métrik>]. Tapi lamun database gawéna ogé kalayan aliran data badag, lajeng naha volume leutik kudu ngabalukarkeun masalah? Kalayan émut ieu, kami nyandak InfluxDB pikeun damel.

Naon deui anu merenah dina InfluxDB

Salian ti fungsi agrégasi anu disebatkeun, aya deui hal anu hébat - queries kontinyu (doc). Ieu mangrupikeun penjadwal anu diwangun kana pangkalan data anu tiasa ngolah data dina jadwal. Salaku conto, unggal 24 jam anjeun tiasa ngagolongkeun sadaya rékaman sadinten, ngitung rata-rata sareng ngarékam hiji titik énggal dina méja sanés tanpa nyerat sapédah anjeun nyalira.

Ogé ngagaduhan kawijakan ingetan (doc)—nyetél ngahapus data saatos sababaraha waktos. Mangpaat nalika, contona, anjeun kedah nyimpen beban CPU salami saminggu kalayan pangukuran sakali per detik, tapi dina jarak sababaraha bulan akurasi sapertos kitu henteu diperyogikeun. Dina kaayaan kitu, anjeun tiasa ngalakukeun ieu:

1. nyieun query kontinyu pikeun agrégat data kana tabel séjén;
2. pikeun tabel kahiji, nangtukeun kawijakan pikeun mupus metrics anu heubeul ti minggu anu sarua.

Sareng Influx sacara mandiri bakal ngirangan ukuran data sareng mupus hal anu teu perlu.

Ngeunaan data disimpen

Teu pira data disimpen: ngeunaan 70 sarébu transaksi sarta séjén juta titik kalayan informasi pasar. Nambahkeun éntri anyar - henteu langkung ti 3000 poin per dinten. Aya ogé metrics pikeun loka, tapi aya saeutik data aya na, nurutkeun kawijakan ingetan, aranjeunna disimpen pikeun henteu leuwih ti sabulan.

Anu jadi masalah

Salila pamekaran sareng tés salajengna tina jasa, beuki seueur masalah kritis timbul dina operasi InfluxDB.

1. Ngahapus data

Aya runtuyan data sareng transaksi:

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

Hasil:

Kuring ngirim paréntah pikeun mupus data:

DELETE FROM transactions WHERE symbol=’USDT’

Salajengna abdi ngadamel pamundut pikeun nampa data geus dihapus. Jeung tinimbang hiji respon kosong, Influx mulih bagian tina data nu kudu dihapus.

Kuring nyobian mupus sakabéh tabel:

DROP MEASUREMENT transactions

Kuring pariksa ngahapus tabel:

SHOW MEASUREMENTS

Kuring teu ningali tabel dina daptar, tapi query data anyar masih mulih set sarua transaksi.

Masalahna ngan ukur kajantenan sakali, sabab kasus ngahapus mangrupikeun kasus anu terasing. Tapi kabiasaan ieu database jelas teu cocog kana kerangka operasi "bener". Teras kuring mendakan éta dibuka dina github tikét ampir sataun katukang dina topik ieu.

Hasilna, mupus lajeng malikkeun sakabéh database mantuan.

2. angka floating titik

Itungan math nalika ngagunakeun fungsi anu diwangun dina InfluxDB gaduh kasalahan akurasi. Teu yén ieu téh nanaon ilahar, tapi teu pikaresepeun.

Dina hal kuring, datana ngagaduhan komponén kauangan sareng kuring hoyong ngolahna kalayan akurasi anu luhur. Kusabab ieu, urang rencanana abandon queries kontinyu.

3. queries kontinyu teu bisa diadaptasi kana zona waktu béda

jasa ngabogaan tabel kalawan statistik transaksi poean. Pikeun unggal dinten, anjeun kedah ngakelompokkeun sadaya transaksi kanggo dinten éta. Tapi unggal dinten pangguna bakal dimimitian dina waktos anu béda, sareng ku kituna susunan transaksi bakal béda. Ku UTC enya 37 varian shifts nu Anjeun kudu agrégat data.

Dina InfluxDB, nalika ngagolongkeun dumasar kana waktos, anjeun ogé tiasa netepkeun shift, contona pikeun waktos Moscow (UTC+3):

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

Tapi hasil query bakal lepat. Kanggo sababaraha alesan, data anu dikelompokkeun dumasar kana dinten bakal ngamimitian dugi ka 1677 (InfluxDB sacara resmi ngadukung rentang waktos ti taun ieu):

Pikeun ngabéréskeun masalah ieu, kami samentawis ngalihkeun jasa kana UTC+0.

4. Kinerja

Aya seueur tolok ukur dina Internét anu ngabandingkeun InfluxDB sareng pangkalan data sanés. Dina glance kahiji, maranéhanana kasampak kawas bahan pamasaran, tapi ayeuna kuring pikir aya sababaraha bebeneran di aranjeunna.

Kuring gé ngabejaan Anjeun kasus kuring.

Palayanan nyayogikeun metode API anu ngabalikeun statistik pikeun dinten terakhir. Nalika ngalakukeun itungan, metodeu naroskeun pangkalan data tilu kali kalayan patarosan ieu:

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

Katerangan:

1. Dina pamundut kahiji, urang meunang titik panungtungan pikeun tiap koin jeung data pasar. Dalapan titik pikeun dalapan koin bisi kuring.
2. Paménta kadua meunang salah sahiji titik newest.
3. Anu katilu naroskeun daptar transaksi salami XNUMX jam terakhir; meureun aya sababaraha ratus di antarana.

Hayu atuh netelakeun yen InfluxDB otomatis ngawangun hiji indéks dumasar kana tag jeung waktu, nu speeds up queries. Dina pamundut kahiji simbul mangrupa tag.

Kuring geus ngajalankeun test stress on metoda API ieu. Pikeun 25 RPS, server nunjukkeun beban pinuh ku genep CPU:

Dina waktos anu sami, prosés NodeJs henteu masihan beban naon waé.

Laju palaksanaan parantos diturunkeun ku 7-10 RPS: upami hiji klien tiasa nampi réspon dina 200 mdet, maka 10 klien kedah ngantosan sadetik. 25 RPS nyaéta wates dimana stabilitas ngalaman; 500 kasalahan dipulangkeun ka klien.

Kalayan pagelaran sapertos kitu mustahil ngagunakeun Influx dina proyék kami. Sumawona: dina proyék dimana ngawaskeun kedah ditingalikeun ka seueur klien, masalah anu sami tiasa muncul sareng pangladén métrik bakal kabeuratan.

kacindekan

Kacindekan anu paling penting tina pangalaman anu diala nyaéta yén anjeun moal tiasa nyandak téknologi anu teu dipikanyaho kana proyék tanpa analisa anu cekap. Saringan saderhana pikeun masalah kabuka dina github tiasa masihan inpormasi pikeun nyegah milih InfluxDB salaku toko data utama.

InfluxDB kedahna pas pikeun tugas-tugas proyék kuring, tapi sakumaha anu ditingalikeun ku prakték, pangkalan data ieu henteu nyumponan kabutuhan sareng seueur bug.

Anjeun parantos tiasa mendakan versi 2.0.0-beta dina gudang proyék; urang ngan ukur tiasa ngaharepkeun yén versi kadua bakal aya perbaikan anu signifikan. Samentawis éta, kuring badé diajar dokuméntasi TimescaleDB.

sumber: www.habr.com