🥇Tolok ukur TSDB berkinerja tinggi VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB dan InfluxDB dibandingkan Artikel sebelumnya pada kumpulan data dengan satu miliar titik data yang termasuk dalam 40 ribu rangkaian waktu unik.

Beberapa tahun yang lalu ada era Zabbix. Setiap server bare metal hanya memiliki beberapa indikator - penggunaan CPU, penggunaan RAM, penggunaan disk, dan penggunaan jaringan. Dengan cara ini, metrik dari ribuan server dapat dimasukkan ke dalam 40 ribu rangkaian waktu unik, dan Zabbix dapat menggunakan MySQL sebagai backend untuk data rangkaian waktu :)

Saat ini sendirian node_eksportir dengan konfigurasi default menyediakan lebih dari 500 metrik pada rata-rata host. ada banyak eksportir untuk berbagai database, server web, sistem perangkat keras, dll. Semuanya menyediakan berbagai metrik yang berguna. Semua semakin banyak aplikasi mulai menetapkan berbagai indikator untuk diri mereka sendiri. Ada Kubernetes dengan cluster dan pod yang mengekspos banyak metrik. Hal ini menyebabkan server menampilkan ribuan metrik unik per host. Jadi deret waktu 40K yang unik tidak lagi berdaya tinggi. Ini sudah menjadi arus utama dan seharusnya mudah ditangani oleh TSDB modern mana pun di satu server.

Berapa banyak rangkaian waktu unik yang ada saat ini? Mungkin 400K atau 4M? Atau 40m? Mari kita bandingkan TSDB modern dengan angka-angka ini.

Memasang patokan

TSBS adalah alat pembandingan yang sangat baik untuk TSDB. Ini memungkinkan Anda menghasilkan sejumlah metrik yang berubah-ubah dengan meneruskan jumlah deret waktu yang diperlukan dibagi 10 - tandai -skala (mantan -scale-var). 10 adalah jumlah pengukuran (metrik) yang dihasilkan pada setiap host atau server. Kumpulan data berikut dihasilkan menggunakan TSBS sebagai benchmark:

Rangkaian waktu unik 400 ribu, interval 60 detik antar titik data, rentang data selama 3 hari penuh, ~1.7 miliar total jumlah titik data.
Rangkaian waktu unik 4 juta, interval 600 detik, rentang data 3 hari penuh, ~1.7 miliar total jumlah titik data.
Rangkaian waktu unik 40 juta, interval 1 jam, rentang data 3 hari penuh, ~2.8 miliar total jumlah titik data.

Klien dan server berjalan pada instans khusus n1-standar-16 di awan Google. Instans ini memiliki konfigurasi berikut:

vCPU: 16
RAM: 60 GB
Penyimpanan: HDD Standar 1TB. Ini memberikan throughput baca/tulis 120 Mbps, 750 operasi baca per detik, dan 1,5 ribu tulis per detik.

TSDB diekstraksi dari image buruh pelabuhan resmi dan dijalankan di buruh pelabuhan dengan konfigurasi berikut:

Metrik Victoria:

docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics

Nilai InfluxDB (-e) diperlukan untuk mendukung daya tinggi. Lihat detailnya di dokumentasi):

docker run -it --rm -p 8086:8086 
-e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 
-e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g 
-e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 
-v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb

TimescaleDB (konfigurasi diambil dari ini mengajukan):

MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432 
--shm-size=${SHARED}MB 
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data 
timescale/timescaledb:latest-pg10 postgres 
-cmax_wal_size=${WAL}MB 
-clog_line_prefix="%m [%p]: [%x] %u@%d" 
-clogging_collector=off 
-csynchronous_commit=off 
-cshared_buffers=${SHARED}MB 
-ceffective_cache_size=${CACHE}MB 
-cwork_mem=${WORK}MB 
-cmaintenance_work_mem=${MAINT}MB 
-cmax_files_per_process=100

Pemuat data dijalankan dengan 16 thread paralel.

Artikel ini hanya berisi hasil untuk tolok ukur penyisipan. Hasil benchmark selektif akan dipublikasikan dalam artikel tersendiri.

Rangkaian waktu unik 400K

Mari kita mulai dengan elemen sederhana - 400K. Hasil tolok ukur:

VictoriaMetrics: 2,6 juta titik data per detik; Penggunaan RAM: 3 GB; ukuran data akhir pada disk: 965 MB
InfluxDB: 1.2 juta titik data per detik; Penggunaan RAM: 8.5 GB; ukuran data akhir pada disk: 1.6 GB
Skala waktu: 849 ribu titik data per detik; Penggunaan RAM: 2,5 GB; ukuran data akhir pada disk: 50 GB

Seperti yang Anda lihat dari hasil di atas, VictoriaMetrics unggul dalam performa penyisipan dan rasio kompresi. Timeline unggul dalam penggunaan RAM, namun menggunakan banyak ruang disk - 29 byte per titik data.

Di bawah ini adalah grafik penggunaan CPU untuk masing-masing TSDB selama benchmark:

Di atas adalah tangkapan layar: VictoriaMetrics - beban CPU selama uji penyisipan untuk metrik 400K unik.

Di atas adalah tangkapan layar: InfluxDB - Beban CPU selama uji penyisipan untuk metrik unik 400K.

Di atas adalah tangkapan layar: TimescaleDB - Beban CPU selama uji penyisipan untuk metrik unik 400K.

VictoriaMetrics menggunakan semua vCPU yang tersedia, sementara InfluxDB kurang memanfaatkan ~2 dari 16 vCPU.

Skala waktu hanya menggunakan 3-4 dari 16 vCPU. Proporsi iowait dan sistem yang tinggi dalam grafik skala waktu TimescaleDB menunjukkan adanya hambatan dalam subsistem input/output (I/O). Mari kita lihat grafik penggunaan bandwidth disk:

Di atas adalah tangkapan layar: VictoriaMetrics - Penggunaan Bandwidth Disk dalam Uji Penyisipan untuk Metrik Unik 400K.

Tangkapan layar di atas: InfluxDB - Penggunaan Bandwidth Disk pada Uji Penyisipan untuk Metrik Unik 400K.

Di atas adalah tangkapan layar: TimescaleDB - Penggunaan Bandwidth Disk pada Uji Penyisipan untuk Metrik Unik 400K.

VictoriaMetrics mencatat data pada 20 Mbps dengan puncak hingga 45 Mbps. Puncak berhubungan dengan penggabungan sebagian besar pada pohon LSM.

InfluxDB menulis data dengan kecepatan 160 MB/s, sedangkan drive 1 TB harus dibatasi throughput tulis 120 MB/s.

TimescaleDB dibatasi untuk throughput tulis sebesar 120 Mbps, namun terkadang melampaui batas ini dan mencapai nilai puncak 220 Mbps. Puncak ini sesuai dengan lembah penggunaan CPU yang tidak mencukupi pada grafik sebelumnya.

Mari kita lihat grafik penggunaan input/output (I/O):

Di atas adalah tangkapan layar: VictoriaMetrics - Masukkan penggunaan I/O pengujian untuk 400 ribu metrik unik.

Di atas adalah tangkapan layar: InfluxDB - Masukkan penggunaan I/O pengujian untuk 400 ribu metrik unik.

Di atas adalah tangkapan layar: TimescaleDB - Masukkan penggunaan I/O pengujian untuk 400 ribu metrik unik.

Sekarang jelas bahwa TimescaleDB mencapai batas I/O, sehingga tidak dapat menggunakan 12 vCPU yang tersisa.

Rangkaian waktu unik 4M

Deret waktu 4M terlihat sedikit menantang. Namun pesaing kami berhasil lulus ujian ini. Hasil tolok ukur:

VictoriaMetrics: 2,2 juta titik data per detik; Penggunaan RAM: 6 GB; ukuran data akhir pada disk: 3 GB.
InfluxDB: 330 ribu titik data per detik; Penggunaan RAM: 20,5 GB; ukuran data akhir pada disk: 18,4 GB.
TimescaleDB: 480 ribu titik data per detik; Penggunaan RAM: 2,5 GB; ukuran data akhir pada disk: 52 GB.

Performa InfluxDB turun dari 1,2 juta titik data per detik untuk rangkaian waktu 400 ribu menjadi 330 ribu titik data per detik untuk rangkaian waktu 4 juta. Ini merupakan penurunan kinerja yang signifikan dibandingkan pesaing lainnya. Mari kita lihat grafik penggunaan CPU untuk memahami penyebab utama hilangnya ini:

Di atas adalah tangkapan layar: VictoriaMetrics - Penggunaan CPU selama uji penyisipan untuk rangkaian waktu 4M yang unik.

Di atas adalah tangkapan layar: InfluxDB - Penggunaan CPU selama uji penyisipan untuk rangkaian waktu 4M yang unik.

Di atas adalah tangkapan layar: TimescaleDB - Penggunaan CPU selama uji penyisipan untuk rangkaian waktu 4M yang unik.

VictoriaMetrics menggunakan hampir seluruh daya unit pemrosesan (CPU). Penurunan di akhir sesuai dengan sisa gabungan LSM setelah semua data dimasukkan.

InfluxDB hanya menggunakan 8 dari 16 vCPU, sedangkan TimsecaleDB menggunakan 4 dari 16 vCPU. Apa persamaan grafiknya? Bagian yang tinggi iowait, yang sekali lagi menunjukkan kemacetan I/O.

TimescaleDB memiliki pangsa yang tinggi system. Kami berasumsi bahwa daya tinggi mengakibatkan banyak atau banyak panggilan sistem kesalahan halaman kecil.

Mari kita lihat grafik throughput disk:

Di atas adalah tangkapan layar: VictoriaMetrics - Menggunakan bandwidth disk untuk memasukkan metrik unik 4M.

Di atas adalah tangkapan layar: InfluxDB - Menggunakan bandwidth disk untuk memasukkan metrik unik 4M.

Di atas adalah tangkapan layar: TimescaleDB - Menggunakan bandwidth disk untuk memasukkan metrik unik 4M.

VictoriaMetrics mencapai batas puncaknya 120 MB/dtk, sedangkan kecepatan tulis rata-rata adalah 40 MB/dtk. Kemungkinan besar beberapa fusi LSM berat dilakukan selama puncaknya.

InfluxDB kembali menghasilkan throughput tulis rata-rata 200 MB/s dengan puncak hingga 340 MB/s pada disk dengan batas tulis 120 MB/s :)

TimescaleDB tidak lagi terbatas pada disk. Tampaknya dibatasi oleh hal lain yang terkait dengan proporsi yang tinggi системной beban CPU.

Mari kita lihat grafik penggunaan IO:

Di atas adalah tangkapan layar: VictoriaMetrics - Menggunakan I/O selama uji penyisipan untuk rangkaian waktu 4M yang unik.

Di atas adalah tangkapan layar: InfluxDB - Menggunakan I/O selama uji penyisipan untuk rangkaian waktu 4M yang unik.

Di atas adalah tangkapan layar: TimescaleDB - Penggunaan I/O selama uji penyisipan untuk rangkaian waktu 4M yang unik.

Pola penggunaan IO mencerminkan bandwidth disk - InfluxDB terbatas pada IO, sedangkan VictoriaMetrics dan TimescaleDB memiliki sumber daya IO cadangan.

Rangkaian waktu unik 40 juta

Rangkaian waktu unik 40 juta terlalu besar untuk InfluxDB :)

Hasil tolok ukur:

VictoriaMetrics: 1,7 juta titik data per detik; Penggunaan RAM: 29GB; Penggunaan ruang disk: 17 GB.
InfluxDB: Tidak selesai karena membutuhkan RAM lebih dari 60GB.
TimescaleDB: 330 ribu titik data per detik, penggunaan RAM: 2,5 GB; Penggunaan ruang disk: 84GB.

TimescaleDB menunjukkan penggunaan RAM yang sangat rendah dan stabil pada 2,5 GB - sama seperti metrik unik 4M dan 400K.

VictoriaMetrics secara perlahan meningkatkan skalanya dengan kecepatan 100 ribu titik data per detik hingga 40 juta nama metrik yang diberi tag diproses. Dia kemudian mencapai tingkat penyisipan berkelanjutan sebesar 1,5-2,0 juta titik data per detik, sehingga hasil akhirnya adalah 1,7 juta titik data per detik.

Grafik untuk deret waktu unik 40M mirip dengan grafik untuk deret waktu unik 4M, jadi lewati saja.

Temuan

TSDB modern mampu memproses sisipan jutaan rangkaian waktu unik di satu server. Pada artikel berikutnya, kami akan menguji seberapa baik TSDB melakukan seleksi di jutaan rangkaian waktu unik.
Pemanfaatan CPU yang tidak mencukupi biasanya menunjukkan adanya hambatan I/O. Ini mungkin juga menunjukkan bahwa pemblokiran terlalu kasar, dengan hanya beberapa thread yang dapat dijalankan pada satu waktu.
Kemacetan I/O memang ada, terutama pada penyimpanan non-SSD seperti perangkat blok tervirtualisasi penyedia cloud.
VictoriaMetrics memberikan pengoptimalan terbaik untuk penyimpanan I/O yang lambat dan rendah. Ini memberikan kecepatan terbaik dan rasio kompresi terbaik.

Unduh Gambar server tunggal VictoriaMetrics dan mencobanya pada data Anda. Biner statis yang sesuai tersedia di GitHub.

Baca lebih lanjut tentang VictoriaMetrics di sini Artikel.

Pembaruan: diterbitkan artikel membandingkan kinerja penyisipan VictoriaMetrics dengan InfluxDB dengan hasil yang dapat direproduksi.

Pembaruan #2: Baca juga artikel tentang skalabilitas vertikal VictoriaMetrics vs InfluxDB vs TimescaleDB.

Pembaruan #3: VictoriaMetrics sekarang menjadi sumber terbuka!

елеграм ат: https://t.me/VictoriaMetrics_ru1

Sumber: www.habr.com