Kemarahan, tawar-menawar dan depresi ketika bekerja dengan InfluxDB

Jika Anda menggunakan database deret waktu (db deret waktu, wiki) sebagai penyimpanan utama situs dengan statistik, maka alih-alih menyelesaikan masalah, Anda malah malah pusing kepala. Saya sedang mengerjakan proyek yang menggunakan database seperti itu, dan terkadang InfluxDB, yang akan dibahas, menghadirkan kejutan yang sama sekali tidak terduga.

Penolakan tanggung jawab: Masalah yang tercantum berlaku untuk InfluxDB versi 1.7.4.

Mengapa deret waktu?

Proyek ini untuk melacak transaksi di berbagai blockchain dan menampilkan statistik. Secara khusus, kami melihat emisi dan pembakaran stablecoin (wiki). Berdasarkan transaksi ini, Anda perlu membuat grafik dan menampilkan tabel ringkasan.

Saat menganalisis transaksi, muncul ide: menggunakan database deret waktu InfluxDB sebagai penyimpanan utama. Transaksi adalah titik waktu dan cocok dengan model deret waktu.

Fungsi agregasi juga terlihat sangat nyaman - ideal untuk memproses grafik dengan periode yang lama. Pengguna memerlukan bagan selama satu tahun, dan database berisi kumpulan data dengan jangka waktu lima menit. Tidak ada gunanya mengiriminya semua seratus ribu titik - selain pemrosesan yang lama, titik-titik tersebut bahkan tidak muat di layar. Anda dapat menulis implementasi Anda sendiri untuk meningkatkan jangka waktu, atau menggunakan fungsi agregasi yang ada di Influx. Dengan bantuan mereka, Anda dapat mengelompokkan data berdasarkan hari dan mengirimkan 365 poin yang diperlukan.

Agak membingungkan bahwa database seperti itu biasanya digunakan untuk tujuan mengumpulkan metrik. Pemantauan server, perangkat iot, segala sesuatu yang jutaan titiknya berbentuk “aliran”: [<waktu> - <nilai metrik>]. Namun jika database berfungsi dengan baik dengan aliran data yang besar, mengapa volume yang kecil harus menimbulkan masalah? Dengan pemikiran ini, kami menggunakan InfluxDB untuk bekerja.

Apa lagi yang nyaman di InfluxDB

Terlepas dari fungsi agregasi yang disebutkan, ada hal hebat lainnya - pertanyaan berkelanjutan (dermaga). Ini adalah penjadwal yang dibangun ke dalam database yang dapat memproses data sesuai jadwal. Misalnya, setiap 24 jam Anda dapat mengelompokkan semua catatan pada hari itu, menghitung rata-rata, dan mencatat satu poin baru di tabel lain tanpa menulis sepeda Anda sendiri.

Juga ada kebijakan retensi (dermaga)—mengatur penghapusan data setelah jangka waktu tertentu. Hal ini berguna ketika, misalnya, Anda perlu menyimpan beban CPU selama seminggu dengan pengukuran sekali per detik, namun dalam jarak beberapa bulan akurasi seperti itu tidak diperlukan. Dalam situasi seperti ini, Anda dapat melakukan ini:

1. membuat kueri berkelanjutan untuk menggabungkan data ke dalam tabel lain;
2. untuk tabel pertama, tentukan kebijakan untuk menghapus metrik yang lebih lama dari minggu yang sama.

Dan Influx akan secara mandiri mengurangi ukuran data dan menghapus hal-hal yang tidak perlu.

Tentang data yang disimpan

Tidak banyak data yang disimpan: sekitar 70 ribu transaksi dan satu juta poin lainnya dengan informasi pasar. Menambahkan entri baru - tidak lebih dari 3000 poin per hari. Ada juga metrik untuk situs tersebut, tetapi hanya ada sedikit data di sana dan, menurut kebijakan penyimpanan, metrik tersebut disimpan tidak lebih dari sebulan.

Masalah

Selama pengembangan dan pengujian layanan selanjutnya, masalah yang semakin kritis muncul dalam pengoperasian InfluxDB.

1. Menghapus data

Ada serangkaian data dengan transaksi:

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

Hasilnya:

Saya mengirimkan perintah untuk menghapus data:

DELETE FROM transactions WHERE symbol=’USDT’

Selanjutnya saya membuat permintaan untuk menerima data yang sudah dihapus. Dan alih-alih memberikan respons kosong, Influx mengembalikan sebagian data yang harus dihapus.

Saya mencoba menghapus seluruh tabel:

DROP MEASUREMENT transactions

Saya memeriksa penghapusan tabel:

SHOW MEASUREMENTS

Saya tidak melihat tabel dalam daftar, tetapi kueri data baru masih mengembalikan kumpulan transaksi yang sama.

Masalahnya hanya terjadi pada saya satu kali, karena kasus penghapusan adalah kasus yang terisolasi. Namun perilaku database ini jelas tidak sesuai dengan kerangka operasi yang "benar". Kemudian saya menemukannya terbuka di github tiket hampir setahun yang lalu tentang topik ini.

Hasilnya, menghapus dan memulihkan seluruh database membantu.

2. Angka floating point

Perhitungan matematika saat menggunakan fungsi bawaan di InfluxDB memiliki kesalahan akurasi. Bukan berarti ini sesuatu yang tidak biasa, tapi ini tidak menyenangkan.

Dalam kasus saya, datanya memiliki komponen keuangan dan saya ingin memprosesnya dengan akurasi tinggi. Oleh karena itu, kami berencana untuk mengabaikan kueri berkelanjutan.

3. Kueri berkelanjutan tidak dapat disesuaikan dengan zona waktu yang berbeda

Layanan ini memiliki tabel dengan statistik transaksi harian. Untuk setiap hari, Anda perlu mengelompokkan semua transaksi pada hari itu. Namun hari setiap pengguna akan dimulai pada waktu yang berbeda, sehingga rangkaian transaksinya pun akan berbeda. Oleh UTC ya 37 varian shift yang Anda perlukan untuk mengumpulkan data.

Di InfluxDB, saat mengelompokkan berdasarkan waktu, Anda juga dapat menentukan shift, misalnya untuk waktu Moskow (UTC+3):

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

Namun hasil kuerinya salah. Untuk beberapa alasan, data yang dikelompokkan berdasarkan hari akan dimulai sejak 1677 (InfluxDB secara resmi mendukung rentang waktu mulai tahun ini):

Untuk mengatasi masalah ini, kami mengalihkan layanan untuk sementara ke UTC+0.

4. Kinerja

Ada banyak tolok ukur di Internet yang membandingkan InfluxDB dan database lainnya. Pada pandangan pertama, mereka tampak seperti materi pemasaran, tapi sekarang menurut saya ada benarnya.

Saya akan menceritakan kasus saya kepada Anda.

Layanan ini menyediakan metode API yang mengembalikan statistik untuk hari terakhir. Saat melakukan penghitungan, metode ini menanyakan database tiga kali dengan kueri berikut:

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

Penjelasan:

1. Pada permintaan pertama, kami mendapatkan poin terakhir untuk setiap koin dengan data pasar. Delapan poin untuk delapan koin dalam kasus saya.
2. Permintaan kedua mendapatkan salah satu poin terbaru.
3. Yang ketiga meminta daftar transaksi selama XNUMX jam terakhir; mungkin ada beberapa ratus transaksi.

Izinkan saya menjelaskan bahwa InfluxDB secara otomatis membuat indeks berdasarkan tag dan waktu, yang mempercepat kueri. Dalam permintaan pertama simbol adalah sebuah tag.

Saya telah menjalankan stress test pada metode API ini. Untuk 25 RPS, server menunjukkan beban penuh enam CPU:

Pada saat yang sama, proses NodeJs tidak memberikan beban apa pun.

Kecepatan eksekusi telah menurun sebesar 7-10 RPS: jika satu klien dapat menerima respons dalam 200 ms, maka 10 klien harus menunggu sedetik. 25 RPS adalah batas penurunan stabilitas; 500 kesalahan dikembalikan ke klien.

Dengan kinerja seperti itu tidak mungkin menggunakan Influx di proyek kami. Selain itu: dalam proyek di mana pemantauan perlu didemonstrasikan kepada banyak klien, masalah serupa mungkin muncul dan server metrik akan kelebihan beban.

Keluaran

Kesimpulan terpenting dari pengalaman yang diperoleh adalah bahwa Anda tidak dapat memasukkan teknologi yang tidak diketahui ke dalam sebuah proyek tanpa analisis yang memadai. Penyaringan sederhana terhadap masalah terbuka di github dapat memberikan informasi untuk menghindari memilih InfluxDB sebagai penyimpanan data utama.

InfluxDB seharusnya cocok untuk tugas proyek saya, tetapi seperti yang ditunjukkan oleh praktik, database ini tidak memenuhi kebutuhan dan memiliki banyak bug.

Anda sudah dapat menemukan versi 2.0.0-beta di repositori proyek; kami hanya dapat berharap bahwa versi kedua akan mengalami peningkatan yang signifikan. Sementara itu, saya akan mempelajari dokumentasi TimescaleDB.

Sumber: www.habr.com