Jika anda menggunakan pangkalan data siri masa (siri masa db, ) sebagai storan utama untuk tapak dengan statistik, maka bukannya menyelesaikan masalah anda boleh mendapat banyak sakit kepala. Saya sedang mengusahakan projek yang menggunakan pangkalan data sedemikian, dan kadangkala InfluxDB, yang akan dibincangkan, memberikan kejutan yang sama sekali tidak dijangka.
Penafian: Isu yang disenaraikan digunakan untuk InfluxDB versi 1.7.4.
Kenapa siri masa?
Projek ini adalah untuk menjejaki urus niaga pada pelbagai rantaian blok dan memaparkan statistik. Secara khusus, kita melihat pelepasan dan pembakaran syiling stabil (). Berdasarkan urus niaga ini, anda perlu membina graf dan menunjukkan jadual ringkasan.
Semasa menganalisis urus niaga, idea muncul: untuk menggunakan pangkalan data siri masa InfluxDB sebagai storan utama. Transaksi ialah titik dalam masa dan ia sesuai dengan model siri masa.
Fungsi pengagregatan juga kelihatan sangat mudah - sesuai untuk memproses carta dengan tempoh yang panjang. Pengguna memerlukan carta selama setahun, dan pangkalan data mengandungi set data dengan jangka masa lima minit. Tidak ada gunanya menghantar semua seratus ribu titik kepadanya - selain daripada pemprosesan yang lama, ia tidak akan muat pada skrin. Anda boleh menulis pelaksanaan anda sendiri untuk meningkatkan jangka masa, atau menggunakan fungsi pengagregatan yang terbina dalam Influx. Dengan bantuan mereka, anda boleh mengumpulkan data mengikut hari dan menghantar 365 mata yang diperlukan.
Agak mengelirukan bahawa pangkalan data sedemikian biasanya digunakan untuk tujuan mengumpul metrik. Pemantauan pelayan, peranti iot, segala-galanya dari mana berjuta-juta titik dalam bentuk "aliran": [<masa> - <nilai metrik>]. Tetapi jika pangkalan data berfungsi dengan baik dengan aliran data yang besar, maka mengapa jumlah yang kecil harus menimbulkan masalah? Dengan mengambil kira perkara ini, kami mengambil InfluxDB untuk bekerja.
Apa lagi yang mudah dalam InfluxDB
Selain daripada fungsi pengagregatan yang disebutkan, terdapat satu lagi perkara yang hebat - pertanyaan berterusan (). Ini ialah penjadual terbina dalam pangkalan data yang boleh memproses data pada jadual. Sebagai contoh, setiap 24 jam anda boleh mengumpulkan semua rekod untuk hari itu, mengira purata dan merekodkan satu mata baharu dalam jadual lain tanpa menulis basikal anda sendiri.
Juga ada dasar pengekalan ()βmenetapkan pemadaman data selepas tempoh tertentu. Ia berguna apabila, sebagai contoh, anda perlu menyimpan beban CPU selama seminggu dengan pengukuran sekali sesaat, tetapi dalam jarak beberapa bulan ketepatan sedemikian tidak diperlukan. Dalam keadaan sedemikian, anda boleh melakukan ini:
- buat pertanyaan berterusan untuk mengagregat data ke dalam jadual lain;
- untuk jadual pertama, tentukan dasar untuk memadamkan metrik yang lebih lama daripada minggu yang sama.
Dan Influx akan mengurangkan saiz data secara bebas dan memadamkan perkara yang tidak perlu.
Mengenai data yang disimpan
Tidak banyak data disimpan: kira-kira 70 ribu transaksi dan satu juta mata lagi dengan maklumat pasaran. Menambah entri baharu - tidak lebih daripada 3000 mata setiap hari. Terdapat juga metrik untuk tapak, tetapi terdapat sedikit data di sana dan, mengikut dasar pengekalan, ia disimpan selama tidak lebih daripada sebulan.
Masalah
Semasa pembangunan dan ujian perkhidmatan seterusnya, semakin banyak masalah kritikal timbul dalam pengendalian InfluxDB.
1. Memadam data
Terdapat satu siri data dengan transaksi:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Keputusan:
Saya menghantar arahan untuk memadam data:
DELETE FROM transactions WHERE symbol=βUSDTβSeterusnya saya membuat permintaan untuk menerima data yang telah dipadam. Dan bukannya respons kosong, Influx mengembalikan sebahagian daripada data yang harus dipadamkan.
Saya cuba memadam keseluruhan jadual:
DROP MEASUREMENT transactionsSaya menyemak pemadaman jadual:
SHOW MEASUREMENTSSaya tidak melihat jadual dalam senarai, tetapi pertanyaan data baharu masih mengembalikan set transaksi yang sama.
Masalahnya hanya berlaku kepada saya sekali, kerana kes pemadaman adalah kes terpencil. Tetapi tingkah laku pangkalan data ini jelas tidak sesuai dengan rangka kerja operasi "betul". Kemudian saya mendapati ia dibuka pada github hampir setahun yang lalu mengenai topik ini.
Akibatnya, memadam dan kemudian memulihkan keseluruhan pangkalan data membantu.
2. Nombor titik terapung
Pengiraan matematik apabila menggunakan fungsi terbina dalam InfluxDB mempunyai ralat ketepatan. Bukannya ini sesuatu yang luar biasa, tetapi ia tidak menyenangkan.
Dalam kes saya, data mempunyai komponen kewangan dan saya ingin memprosesnya dengan ketepatan yang tinggi. Oleh sebab itu, kami bercadang untuk meninggalkan pertanyaan berterusan.
3. Pertanyaan berterusan tidak boleh disesuaikan dengan zon waktu yang berbeza
Perkhidmatan ini mempunyai jadual dengan statistik transaksi harian. Untuk setiap hari, anda perlu mengumpulkan semua transaksi untuk hari itu. Tetapi hari setiap pengguna akan bermula pada masa yang berbeza, dan oleh itu set transaksi akan berbeza. Menjelang UTC ya anjakan yang anda perlukan untuk mengagregatkan data.
Dalam InfluxDB, apabila mengumpulkan mengikut masa, anda juga boleh menentukan anjakan, contohnya untuk waktu Moscow (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Tetapi hasil pertanyaan akan menjadi salah. Atas sebab tertentu, data yang dikumpulkan mengikut hari akan bermula sepanjang perjalanan kembali ke 1677 (InfluxDB secara rasmi menyokong jangka masa dari tahun ini):
Untuk mengatasi masalah ini, kami menukar perkhidmatan kepada UTC+0 buat sementara waktu.
4. Prestasi
Terdapat banyak penanda aras di Internet yang membandingkan InfluxDB dan pangkalan data lain. Pada pandangan pertama, mereka kelihatan seperti bahan pemasaran, tetapi sekarang saya fikir ada kebenarannya.
Saya akan memberitahu anda kes saya.
Perkhidmatan ini menyediakan kaedah API yang mengembalikan statistik untuk hari terakhir. Apabila melakukan pengiraan, kaedah menanyakan pangkalan data tiga kali dengan pertanyaan berikut:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCPenjelasan:
- Dalam permintaan pertama, kami mendapat mata terakhir untuk setiap syiling dengan data pasaran. Lapan mata untuk lapan syiling dalam kes saya.
- Permintaan kedua mendapat salah satu mata terbaharu.
- Yang ketiga meminta senarai transaksi untuk XNUMX jam terakhir; mungkin terdapat beberapa ratus daripadanya.
Biar saya jelaskan bahawa InfluxDB membina indeks secara automatik berdasarkan teg dan masa, yang mempercepatkan pertanyaan. Dalam permintaan pertama lambang ialah tag.
Saya telah menjalankan ujian tekanan pada kaedah API ini. Untuk 25 RPS, pelayan menunjukkan muatan penuh enam CPU:
Pada masa yang sama, proses NodeJs tidak memberikan sebarang beban sama sekali.
Kelajuan pelaksanaan telah menurun sebanyak 7-10 RPS: jika seorang pelanggan boleh menerima respons dalam 200 ms, maka 10 pelanggan terpaksa menunggu sebentar. 25 RPS ialah had di mana kestabilan dialami; 500 ralat telah dikembalikan kepada pelanggan.
Dengan prestasi sedemikian adalah mustahil untuk menggunakan Influx dalam projek kami. Selain itu: dalam projek di mana pemantauan perlu ditunjukkan kepada banyak pelanggan, masalah yang sama mungkin muncul dan pelayan metrik akan terlebih beban.
Output
Kesimpulan yang paling penting daripada pengalaman yang diperoleh ialah anda tidak boleh mengambil teknologi yang tidak diketahui ke dalam projek tanpa analisis yang mencukupi. Saringan mudah isu terbuka pada github boleh memberikan maklumat untuk mengelak daripada memilih InfluxDB sebagai stor data utama.
InfluxDB sepatutnya sesuai untuk tugasan projek saya, tetapi seperti yang ditunjukkan oleh amalan, pangkalan data ini tidak memenuhi keperluan dan mempunyai banyak pepijat.
Anda sudah boleh mencari versi 2.0.0-beta dalam repositori projek; kami hanya boleh berharap bahawa versi kedua akan mempunyai peningkatan yang ketara. Sementara itu, saya akan pergi mengkaji dokumentasi TimescaleDB.
Sumber: www.habr.com