Jika Anda menggunakan basis data deret waktu (deret waktu db,
wiki ) sebagai repositori utama untuk situs dengan statistik, maka alih-alih menyelesaikan masalah, Anda bisa mendapatkan banyak sakit kepala. Saya sedang mengerjakan proyek di mana basis data seperti itu digunakan, dan kadang-kadang InfluxDB, yang akan didiskusikan, menyajikan kejutan yang tidak terduga secara umum.
Penafian : Masalah-masalah ini untuk InfluxDB 1.7.4.
Mengapa seri waktu?
Proyek ini untuk melacak transaksi di berbagai blockchain dan menampilkan statistik. Secara khusus, kami melihat emisi dan pembakaran koin stabil (
wiki ). Berdasarkan transaksi ini, Anda perlu membuat grafik dan menampilkan tabel pivot.
Ketika menganalisis transaksi, muncul ide: untuk menggunakan basis data time series InfluxDB sebagai penyimpanan utama. Transaksi adalah poin waktu dan cocok dengan model deret waktu.
Juga, fungsi agregasi tampak sangat nyaman - mereka ideal untuk memproses grafik dengan periode yang panjang. Pengguna membutuhkan grafik untuk tahun itu, dan database berisi kumpulan data dengan jangka waktu lima menit. Tidak ada gunanya mengiriminya seratus ribu poin - kecuali untuk pemrosesan yang lama, mereka tidak akan muat di layar. Anda dapat menulis implementasi Anda sendiri untuk meningkatkan kerangka waktu, atau menggunakan fungsi agregasi yang dibangun ke dalam Influx. Dengan bantuan mereka, Anda dapat mengelompokkan data berdasarkan hari dan mengirim 365 poin yang diinginkan.
Agak memalukan bahwa biasanya basis data seperti itu digunakan untuk mengumpulkan metrik. Server pemantauan, perangkat-iot, semua yang darinya jutaan titik bentuk “tuangkan”: [<waktu> - <nilai metrik>]. Tetapi jika database bekerja dengan baik dengan aliran data yang besar, lalu mengapa sejumlah kecil menyebabkan masalah? Dengan pemikiran ini, mereka menggunakan InfluxDB untuk bekerja.
Apa lagi yang nyaman di InfluxDB
Selain fungsi agregasi yang disebutkan, ada hal hebat lainnya -
permintaan terus menerus (
doc ). Ini adalah penjadwal yang dibangun ke dalam basis data yang dapat memproses data sesuai jadwal. Misalnya, Anda dapat mengelompokkan semua catatan selama sehari setiap 24 jam, menghitung rata-rata dan menulis satu titik baru di tabel lain tanpa menulis sepeda motor Anda sendiri.
Ada juga
kebijakan penyimpanan (
doc ) - mengatur penghapusan data setelah suatu periode. Ini berguna ketika, misalnya, Anda perlu menyimpan beban pada CPU selama seminggu dengan pengukuran sekali per detik, tetapi pada jarak beberapa bulan keakuratan ini tidak diperlukan. Dalam situasi ini, Anda dapat melakukan ini:
- membuat kueri berkelanjutan untuk menggabungkan data ke dalam tabel lain;
- Untuk tabel pertama, tetapkan kebijakan untuk menghapus metrik yang lebih lama dari minggu itu.
Dan Influx akan secara independen mengurangi ukuran data dan menghapus 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 di situs, tetapi ada sedikit data di sana dan dengan kebijakan penyimpanan, data tersebut disimpan tidak lebih dari sebulan.
Masalahnya
Selama pengembangan dan pengujian layanan selanjutnya, semakin banyak masalah kritis yang muncul selama pengoperasian InfluxDB.
1. Penghapusan data
Ada serangkaian data dengan transaksi:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'
Hasil:
Saya mengirim perintah untuk menghapus data:
DELETE FROM transactions WHERE symbol='USDT'
Selanjutnya, saya membuat permintaan untuk menerima data yang sudah dihapus. Dan Influx, bukannya respons kosong, mengembalikan bagian dari data yang harus dihapus.
Saya mencoba menghapus seluruh tabel:
DROP MEASUREMENT transactions
Saya memeriksa penghapusan tabel:
SHOW MEASUREMENTS
Saya tidak menonton tabel dalam daftar, tetapi permintaan data baru masih mengembalikan set transaksi yang sama.
Masalahnya hanya terjadi pada saya satu kali, karena kasus penghapusan adalah kasus yang terisolasi. Tetapi perilaku basis data ini jelas tidak cocok dengan kerangka kerja yang "benar". Kemudian di github saya menemukan
tiket terbuka hampir setahun yang lalu tentang topik ini.
Akibatnya, penghapusan dan pemulihan selanjutnya dari seluruh database membantu.
2. Angka titik mengambang
Perhitungan matematis menggunakan fungsi bawaan di InfluxDB memberikan kesalahan akurasi. Bukannya itu sesuatu yang tidak biasa, tetapi tidak menyenangkan.
Dalam kasus saya, data memiliki komponen keuangan dan saya ingin memprosesnya dengan akurasi tinggi. Karena itu, rencana untuk mengabaikan permintaan terus menerus.
3. Kueri berkelanjutan tidak dapat disesuaikan dengan zona waktu yang berbeda
Layanan ini memiliki tabel dengan statistik harian tentang transaksi. Untuk setiap hari, Anda perlu mengelompokkan semua transaksi untuk hari ini. Tetapi hari untuk setiap pengguna akan dimulai pada waktu yang berbeda, oleh karena itu rangkaian transaksi berbeda. UTC memiliki
37 opsi shift yang Anda perlukan untuk mengumpulkan data.
Saat mengelompokkan berdasarkan waktu di InfluxDB, Anda juga dapat menentukan shift, misalnya, untuk waktu Moskow (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)
Tetapi hasil kueri akan salah. Untuk beberapa alasan, data yang dikelompokkan berdasarkan hari akan dimulai pada awal 1677 (InfluxDB secara resmi mendukung periode waktu dari tahun ini):
Untuk mengatasi masalah ini, layanan sementara dipindahkan ke UTC + 0.
4. Kinerja
Ada banyak tolok ukur di Internet dengan perbandingan InfluxDB dan basis data lainnya. Pada kenalan pertama, mereka tampak seperti materi pemasaran, tetapi sekarang saya berpikir bahwa ada beberapa kebenaran di dalamnya.
Saya akan memberi tahu Anda kasus saya.
Layanan ini menyediakan metode API yang mengembalikan statistik untuk hari terakhir. Selama perhitungan, metode ini menanyakan basis data tiga kali dengan permintaan 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
- Dalam kueri pertama, kami mendapatkan poin terakhir untuk setiap koin dengan data pasar. Delapan poin untuk delapan koin dalam kasus saya.
- Permintaan kedua menerima satu poin terbaru.
- Yang ketiga meminta daftar transaksi untuk hari terakhir, mungkin ada beberapa ratus.
Saya akan mengklarifikasi bahwa di InfluxDB, indeks secara otomatis dibangun oleh tag dan waktu, yang mempercepat permintaan. Dalam kueri pertama,
simbol adalah tag.
Saya melakukan tes stres untuk metode API ini. Untuk 25 RPS, server menunjukkan muatan penuh enam CPU:
Pada saat yang sama, proses NodeJs tidak memberikan beban sama sekali.
Kecepatan eksekusi telah menurun 7-10 RPS: jika satu klien dapat menerima respons dalam 200 ms, maka 10 klien harus menunggu satu detik. 25 RPS - perbatasan dengan mana stabilitas menderita, 500 kesalahan dikembalikan ke klien.
Dengan kinerja seperti itu, Influx tidak mungkin digunakan dalam proyek kami. Selain itu: dalam proyek di mana Anda perlu menunjukkan pemantauan ke banyak klien, masalah serupa mungkin muncul dan server metrik akan kelebihan beban.
Kesimpulan
Kesimpulan paling penting dari pengalaman yang diperoleh adalah bahwa Anda tidak dapat mengambil teknologi yang tidak dikenal ke dalam proyek tanpa analisis yang memadai. Penyaringan sederhana tiket terbuka di github dapat memberikan informasi agar tidak menggunakan InfluxDB sebagai gudang data utama.
InfluxDB seharusnya cocok untuk tugas-tugas proyek saya, tetapi seperti yang telah ditunjukkan oleh praktik, basis data ini tidak memenuhi kebutuhan dan banyak mengacaukan.
Anda sudah dapat menemukan versi 2.0.0-beta di repositori proyek, diharapkan di versi kedua akan ada peningkatan yang signifikan. Sementara itu, saya akan mempelajari dokumentasi TimescaleDB.