🥇Yüksək performanslı TSDB benchmark VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB və InfluxDB-də müqayisə edildi əvvəlki məqalə 40K unikal zaman seriyasına aid bir milyard məlumat nöqtəsi olan verilənlər bazasında.

Bir neçə il əvvəl Zabbix dövrü var idi. Hər bir çılpaq metal serverdə bir neçə göstəricidən çox olmamışdır - CPU istifadəsi, RAM istifadəsi, disk istifadəsi və şəbəkə istifadəsi. Bu yolla, minlərlə serverin ölçüləri 40 min unikal zaman seriyasına sığa bilər və Zabbix MySQL-i zaman seriyası məlumatları üçün backend kimi istifadə edə bilər :)

Hazırda tək node_exporter standart konfiqurasiyaları ilə orta hostda 500-dən çox ölçü təmin edir. Çox var ixracatçılar müxtəlif verilənlər bazaları, veb serverlər, aparat sistemləri və s. üçün. Onların hamısı müxtəlif faydalı ölçüləri təmin edir. Hamısı getdikcə daha çox tətbiq özləri üçün müxtəlif göstəricilər təyin etməyə başlayırlar. Bir çox ölçüləri ifşa edən çoxluqlar və podlar olan Kubernetes var. Bu, serverlərin hər bir host üçün minlərlə unikal ölçüləri ifşa etməsi ilə nəticələnir. Beləliklə, unikal 40K zaman seriyası artıq yüksək güc deyil. O, əsas istiqamətə çevrilir və bir serverdə istənilən müasir TSDB tərəfindən asanlıqla idarə olunmalıdır.

Hazırda çoxlu sayda unikal zaman seriyası nədir? Yəqin ki, 400K və ya 4M? Yoxsa 40 m? Müasir TSDB-ləri bu rəqəmlərlə müqayisə edək.

Benchmarkın quraşdırılması

TSBS TSDB-lər üçün əla müqayisə alətidir. Bu, lazımi sayda vaxt seriyasını 10-a bölünərək ötürməklə ixtiyari sayda ölçülər yaratmağa imkan verir - bayraq -qapaq (keçmiş -scale-var). 10 hər bir host və ya serverdə yaradılan ölçmələrin (ölçmələrin) sayıdır. Aşağıdakı məlumat dəstləri etalon üçün TSBS istifadə edərək yaradılmışdır:

400K unikal vaxt seriyası, məlumat nöqtələri arasında 60 saniyəlik interval, məlumat tam 3 günü əhatə edir, məlumat nöqtələrinin ümumi sayı ~1.7B.
4M unikal vaxt seriyası, 600 saniyə intervalı, məlumat 3 tam günü əhatə edir, məlumat nöqtələrinin ümumi sayı ~1.7B.
40M unikal vaxt seriyası, 1 saat intervalı, məlumat 3 tam günü əhatə edir, məlumat nöqtələrinin ümumi sayı ~2.8B.

Müştəri və server xüsusi instansiyalarda işləyirdi n1-standart-16 Google buludunda. Bu nümunələrin aşağıdakı konfiqurasiyaları var idi:

vCPU-lar: 16
RAM: 60 GB
Yaddaş: Standart 1TB HDD. O, 120 Mbit/s oxu/yazma ötürmə qabiliyyətini, saniyədə 750 oxuma əməliyyatını və saniyədə 1,5K yazmanı təmin edir.

TSDB-lər rəsmi docker təsvirlərindən çıxarılıb və aşağıdakı konfiqurasiyalarla docker-də işə salınıb:

Victoria Metrics:

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

InfluxDB (-e) dəyərləri yüksək gücü dəstəkləmək üçün tələb olunur. Ətraflı məlumatlara baxın sənədləşdirmə):

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 (konfiqurasiya o fayl):

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

Məlumat yükləyicisi 16 paralel iplə işlədilib.

Bu məqalədə yalnız əlavə etalonları üçün nəticələr var. Seçilmiş meyarın nəticələri ayrıca məqalədə dərc olunacaq.

400K unikal zaman seriyası

Sadə elementlərdən başlayaq - 400K. Benchmark nəticələri:

VictoriaMetrics: saniyədə 2,6 milyon məlumat nöqtəsi; RAM istifadəsi: 3 GB; diskdəki son məlumat ölçüsü: 965 MB
InfluxDB: saniyədə 1.2M məlumat nöqtəsi; RAM istifadəsi: 8.5 GB; diskdəki son məlumat ölçüsü: 1.6 GB
Zaman şkalası: saniyədə 849K məlumat nöqtəsi; RAM istifadəsi: 2,5 GB; diskdəki son məlumat ölçüsü: 50 GB

Yuxarıdakı nəticələrdən göründüyü kimi, VictoriaMetrics daxiletmə performansı və sıxılma nisbətində qalib gəlir. Zaman qrafiki RAM istifadəsində qalib gəlir, lakin çoxlu disk sahəsini istifadə edir - məlumat nöqtəsi üçün 29 bayt.

Aşağıda benchmark zamanı TSDB-lərin hər biri üçün CPU istifadə qrafikləri verilmişdir:

Yuxarıda bir ekran görüntüsü var: VictoriaMetrics - unikal 400K metrik üçün daxiletmə testi zamanı CPU yükü.

Yuxarıda bir ekran görüntüsü var: InfluxDB - unikal metrik 400K üçün daxiletmə testi zamanı CPU yükü.

Yuxarıda bir ekran görüntüsü var: TimescaleDB - 400K unikal metrik üçün daxiletmə testi zamanı CPU yükü.

VictoriaMetrics bütün mövcud vCPU-lardan istifadə edir, InfluxDB isə 2 vCPU-dan ~16-dən az istifadə edir.

Zaman şkalası 3 vCPU-dan yalnız 4-16-dən istifadə edir. TimescaleDB zaman şkalası qrafikində iowait və sistemin yüksək nisbətləri giriş/çıxış (I/O) alt sistemində darboğaz olduğunu göstərir. Disk bant genişliyindən istifadə qrafiklərinə baxaq:

Yuxarıda bir ekran görüntüsü var: VictoriaMetrics - Unikal Metriklər 400K üçün Daxiletmə Testində Disk Bant Genişliyi İstifadəsi.

Yuxarıda bir ekran görüntüsü var: InfluxDB - Unikal Metriklər 400K üçün Daxiletmə Testində Disk Bant Genişliyi İstifadəsi.

Yuxarıda bir ekran görüntüsü var: TimescaleDB - Unikal Metriklər 400K üçün Daxiletmə Testində Disk Bant Genişliyi İstifadəsi.

VictoriaMetrics məlumatları 20 Mbit / s sürətlə 45 Mbit / s-ə qədər zirvə ilə qeyd edir. Zirvələr ağacda böyük qismən birləşmələrə uyğundur LSM.

InfluxDB 160 TB sürücü isə 1 MB/s sürətlə məlumat yazır məhdudlaşdırılmalıdır yazma qabiliyyəti 120 MB/s.

TimescaleDB 120 Mbps yazma qabiliyyəti ilə məhdudlaşır, lakin bəzən bu limiti pozur və pik dəyərlərdə 220 Mbps-ə çatır. Bu zirvələr əvvəlki qrafikdə CPU-nun qeyri-kafi istifadə vadilərinə uyğundur.

Gəlin giriş/çıxış (I/O) istifadə qrafiklərinə baxaq:

Yuxarıda bir ekran görüntüsü var: VictoriaMetrics - 400K unikal ölçülər üçün test I/O istifadəsini daxil edin.

Yuxarıda bir ekran görüntüsü var: InfluxDB - 400K unikal ölçülər üçün test I/O istifadəsini daxil edin.

Yuxarıda bir ekran görüntüsü var: TimescaleDB - 400K unikal ölçülər üçün test I/O istifadəsini daxil edin.

İndi aydındır ki, TimescaleDB öz I/O limitinə çatır, ona görə də qalan 12 vCPU-dan istifadə edə bilmir.

4M unikal zaman seriyası

4M zaman seriyası bir az çətin görünür. Amma rəqiblərimiz bu imtahandan uğurla keçirlər. Benchmark nəticələri:

VictoriaMetrics: saniyədə 2,2 milyon məlumat nöqtəsi; RAM istifadəsi: 6 GB; Diskdəki son məlumat ölçüsü: 3 GB.
InfluxDB: saniyədə 330K məlumat nöqtəsi; RAM istifadəsi: 20,5 GB; Diskdəki son məlumat ölçüsü: 18,4 GB.
TimescaleDB: saniyədə 480K məlumat nöqtəsi; RAM istifadəsi: 2,5 GB; Diskdəki son məlumat ölçüsü: 52 GB.

InfluxDB performansı 1,2K zaman seriyası üçün saniyədə 400M məlumat nöqtəsindən 330M zaman seriyası üçün saniyədə 4K məlumat nöqtəsinə düşdü. Bu, digər rəqiblərlə müqayisədə əhəmiyyətli performans itkisidir. Bu itkinin əsas səbəbini anlamaq üçün CPU istifadə qrafiklərinə baxaq:

Yuxarıda bir ekran görüntüsü var: VictoriaMetrics - unikal 4M vaxt seriyası üçün daxiletmə testi zamanı CPU istifadəsi.

Yuxarıda bir ekran görüntüsü var: InfluxDB - unikal 4M vaxt seriyası üçün daxiletmə testi zamanı CPU istifadəsi.

Yuxarıda bir ekran görüntüsü var: TimescaleDB - Unikal 4M vaxt seriyası üçün daxiletmə testi zamanı CPU istifadəsi.

VictoriaMetrics demək olar ki, bütün prosessorun (CPU) gücünü istifadə edir. Sonda düşmə bütün məlumatlar daxil edildikdən sonra qalan LSM birləşmələrinə uyğun gəlir.

InfluxDB 8 vCPU-dan yalnız 16-ni, TimsecaleDB isə 4 vCPU-dan 16-ünü istifadə edir. Onların qrafiklərində ortaq nə var? Yüksək pay iowait, bu, yenidən I/O darboğazını göstərir.

TimescaleDB yüksək paya malikdir system. Güman edirik ki, yüksək gücün çoxlu sistem zəngləri və ya çoxlu olması ilə nəticələndi kiçik səhifə səhvləri.

Disk ötürmə qrafiklərinə baxaq:

Yuxarıda bir ekran görüntüsü var: VictoriaMetrics - 4M unikal ölçüləri daxil etmək üçün disk bant genişliyindən istifadə.

Yuxarıda bir ekran görüntüsü var: InfluxDB - 4M unikal ölçüləri daxil etmək üçün disk bant genişliyindən istifadə.

Yuxarıda bir ekran görüntüsü var: TimescaleDB - 4M unikal ölçüləri daxil etmək üçün disk bant genişliyindən istifadə.

VictoriaMetrics zirvədə 120 MB/s həddinə çatdı, orta yazma sürəti isə 40 MB/s idi. Çox güman ki, pik zamanı bir neçə ağır LSM birləşmələri həyata keçirilib.

InfluxDB yenidən yazma limiti 200 MB/s olan diskdə 340 MB/s-ə qədər zirvələrlə 120 MB/s orta yazma qabiliyyətini sıxışdırır :)

TimescaleDB artıq disk məhdud deyil. Yüksək nisbətlə əlaqəli başqa bir şeylə məhdudlaşdığı görünür системной CPU yükü.

IO istifadə qrafiklərinə baxaq:

Yuxarıda bir ekran görüntüsü var: VictoriaMetrics - Unikal 4M vaxt seriyası üçün daxiletmə testi zamanı I/O-dan istifadə.

Yuxarıda bir ekran görüntüsü var: InfluxDB - Unikal 4M vaxt seriyası üçün daxiletmə testi zamanı I/O-dan istifadə.

Yuxarıda bir ekran görüntüsü var: TimescaleDB - Unikal 4M vaxt seriyası üçün daxiletmə testi zamanı I/O istifadəsi.

IO istifadə nümunələri disk bant genişliyini əks etdirir - InfluxDB IO məhduddur, VictoriaMetrics və TimescaleDB isə ehtiyat IO resurslarına malikdir.

40M unikal zaman seriyası

40M unikal vaxt seriyası InfluxDB üçün çox böyük idi :)

Benchmark nəticələri:

VictoriaMetrics: saniyədə 1,7 milyon məlumat nöqtəsi; RAM istifadəsi: 29 GB; Disk sahəsinin istifadəsi: 17 GB.
InfluxDB: 60 GB-dan çox RAM tələb etdiyi üçün tamamlanmadı.
TimescaleDB: saniyədə 330K məlumat nöqtəsi, RAM istifadəsi: 2,5 GB; Disk sahəsinin istifadəsi: 84 GB.

TimescaleDB 2,5 GB-da olduqca aşağı və sabit RAM istifadəsini göstərir - unikal 4M və 400K ölçüləri ilə eynidir.

VictoriaMetrics, bütün 100M etiketli metrik adlar emal olunana qədər saniyədə 40k məlumat nöqtəsi sürəti ilə yavaş-yavaş böyüdü. Daha sonra o, saniyədə 1,5-2,0 milyon məlumat nöqtəsi kimi davamlı daxiletmə sürətinə nail oldu, beləliklə, son nəticə saniyədə 1,7 milyon məlumat nöqtəsi oldu.

40M unikal zaman seriyası üçün qrafiklər 4M unikal zaman seriyası üçün qrafiklərə bənzəyir, ona görə də onları atlayaq.

Tapıntılar

Müasir TSDB-lər bir serverdə milyonlarla unikal zaman seriyası üçün əlavələri emal etməyə qadirdir. Növbəti məqalədə biz TSDB-lərin milyonlarla unikal zaman seriyası arasında seçimi necə yaxşı yerinə yetirdiyini yoxlayacağıq.
Qeyri-kafi CPU istifadəsi adətən I/O darboğazını göstərir. Bu, həm də bloklamanın çox kobud olduğunu, eyni anda yalnız bir neçə ipin işləyə biləcəyini göstərə bilər.
I/O darboğazı xüsusilə bulud provayderlərinin virtuallaşdırılmış blok cihazları kimi qeyri-SSD yaddaşda mövcuddur.
VictoriaMetrics yavaş, aşağı I/O saxlama üçün ən yaxşı optimallaşdırma təmin edir. Ən yaxşı sürəti və ən yaxşı sıxılma nisbətini təmin edir.

Yükləyin VictoriaMetrics tək server şəkli və məlumatlarınızda sınayın. Müvafiq statik binar burada mövcuddur Github.

VictoriaMetrics haqqında ətraflı oxuyun məqalə.

Yeniləmə: nəşr olundu VictoriaMetrics-in daxiletmə performansını InfluxDB ilə müqayisə edən məqalə təkrarlana bilən nəticələrlə.

Yeniləmə # 2: Həmçinin oxuyun VictoriaMetrics vs InfluxDB vs TimescaleDB arasında şaquli genişlənmə haqqında məqalə.

Yeniləmə #3: VictoriaMetrics indi açıq mənbədir!

Telegram çatı: https://t.me/VictoriaMetrics_ru1

Mənbə: www.habr.com