Wydajny benchmark TSDB VictoriaMetrics vs TimescaleDB vs InfluxDB

VictoriaMetrics, TimescaleDB i InfluxDB zostały porównane w poprzedniej artykule o zbiorze danych z miliardem punktów danych, należących do 40k unikalnych szeregów czasowych.

Kilka lat temu nastała era Zabbix. Każdy serwer bare metal miał nie więcej niż kilka wskaźników – zużycie CPU, zużycie pamięci RAM, zużycie dysku i zużycie sieci. Tak więc metryki z tysięcy serwerów mogą pomieścić się w 40 tysiącach unikalnych szeregów czasowych, a Zabbix może używać MySQL jako backendu dla tych danych 🙂

Obecnie jeden node_exporter z domyślnymi konfiguracjami dostarcza ponad 500 metryk na średnim hoście. Istnieje wiele eksporterów dla różnych baz danych, serwerów WWW, systemów sprzętowych itd. Wszystkie one dostarczają wiele przydatnych wskaźników. Wszystkie coraz więcej aplikacji zaczyna wystawiać różne wskaźniki na siebie. Istnieje Kubernetes z klastrami i podami, ujawniającymi wiele metryk. To prowadzi do sytuacji, w której serwery wystawiają tysiące unikalnych metryk na hoście. Tak więc, unikalny szereg czasowy 40k przestał być wysoką mocą. Staje się mainstreamem, który musi być łatwo przetwarzany przez każdą nowoczesną TSDB na jednym serwerze.

Co to jest duża ilość unikalnych szeregów czasowych obecnie? Pewnie 400k lub 4M? Albo 40M? Porównajmy współczesne TSDB z tymi liczbami.

Ustalanie benchmarku

TSBS to doskonałe narzędzie do benchmarkingu dla TSDB. Umożliwia generowanie dowolnej ilości metryk, przekazując wymaganą liczbę szeregów czasowych, podzielonych przez 10 – flaga -scale (wcześniej -scale-var). 10 to liczba wymiarów (metryk), generowanych na każdym hoście, serwerze. Następujące zbiory danych zostały stworzone za pomocą TSBS dla benchmarku:

• 400k unikalny szereg czasowy, interwał 60 sekund między punktami danych, dane obejmują pełne 3 dni, ~1.7B całkowitej liczby punktów danych.
• 4M unikalny szereg czasowy, interwał 600 sekund, dane obejmują pełne 3 dni, ~1.7B całkowitej liczby punktów danych.
• 40M unikalny szereg czasowy, interwał 1 godzina, dane obejmują pełne 3 dni, ~2.8B całkowitej liczby punktów danych.

Klient i serwer zostały uruchomione na dedykowanych instancjach n1-standard-16 w chmurze Google. Te instancje miały następujące konfiguracje:

• vCPU: 16
• RAM: 60 GB
• Przechowywanie: standardowy dysk twardy o pojemności 1 TB. Zapewnia przepustowość odczytu/zapisu 120 Mb/s, 750 operacji odczytu na sekundę i 1,5K operacji zapisu na sekundę.

TSDB zostały pobrane z oficjalnych obrazów dockera i uruchomione w dockerze z następującymi konfiguracjami:

• VictoriaMetrics:

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

• Wartości InfluxDB (- e są wymagane dla wsparcia wysokiej mocy. Szczegóły znajdziesz w dokumentacji):

  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 (konfiguracja została przyjęta z tego pliku):

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

Ładowarka danych została uruchomiona z 16 równoległymi wątkami.

Ten artykuł zawiera tylko wyniki dla wskaźników wydajności wstawiania. Wyniki losowego benchmarku zostaną opublikowane w osobnym artykule.

400K unikalnych szeregów czasowych

Zacznijmy od prostych elementów — 400K. Wyniki benchmarku:

• VictoriaMetrics: 2,6M punktów danych na sekundę; użycie pamięci RAM: 3 GB; końcowy rozmiar danych na dysku: 965 MB
• InfluxDB: 1.2M punktów danych na sekundę; użycie pamięci RAM: 8.5 GB; końcowy rozmiar danych na dysku: 1.6 GB
• Timescale: 849K punktów danych na sekundę; użycie pamięci RAM: 2,5 GB; końcowy rozmiar danych na dysku: 50 GB

Jak widać z powyższych wyników, VictoriaMetrics wygrywa w szybkości wstawiania i stopniu kompresji. Timescale wygrywa w użyciu pamięci RAM, ale wykorzystuje dużo miejsca na dysku — 29 bajtów na punkt danych.

Poniżej przedstawiono wykresy użycia procesora (CPU) dla każdego z TSDB podczas benchmarku:

Powyżej zrzut ekranu: VictoriaMetrics — Obciążenie CPU podczas testu wstawiania dla unikalnej metryki 400K.

Powyżej zrzut ekranu: InfluxDB — Obciążenie CPU podczas testu wstawiania dla unikalnej metryki 400K.

Powyżej zrzut ekranu: TimescaleDB — Obciążenie CPU podczas testu wstawiania dla unikalnej metryki 400K.

VictoriaMetrics wykorzystuje wszystkie dostępne vCPUs, podczas gdy InfluxDB wystarczająco nie angażuje ~2 z 16 vCPUs.

Timescale wykorzystuje tylko 3-4 z 16 vCPUs. Wysokie udziały iowait i system na wykresie TimescaleDB wskazują na wąskie gardło w subsystemie wejścia-wyjścia (I/O). Przyjrzyjmy się wykresom wykorzystania pasma dyskowego:

Powyżej zrzut ekranu: VictoriaMetrics — Wykorzystanie pasma dyskowego podczas testu wstawiania dla unikalnych metryk 400K.

Powyżej zrzut ekranu: InfluxDB — Wykorzystanie pasma dyskowego podczas testu wstawiania dla unikalnych metryk 400K.

Powyżej zrzut ekranu: TimescaleDB — Wykorzystanie pasma dyskowego podczas testu wstawiania dla unikalnych metryk 400K.

VictoriaMetrics zapisuje dane z szybkością 20 Mb/s z szczytami do 45 Mb/s. Szczyty odpowiadają dużym częściowym scaleniom w drzewie. LSM.

InfluxDB zapisuje dane z szybkością 160 MB/s, podczas gdy dysk 1 TB musi być ograniczony wydajnością zapisu 120 MB/s.

TimescaleDB jest ograniczona do wydajności zapisu 120 Mbit/s, ale czasami przekracza ten limit i osiąga 220 Mbit/s podczas szczytów. Te szczyty odpowiadają spadkom niewystarczającego obciążenia procesora na poprzednim wykresie.

Przyjrzyjmy się wykresom wykorzystania wejścia-wyjścia (I/O):

Powyżej zrzut ekranu: VictoriaMetrics — Wykorzystanie wejścia-wyjścia podczas testu wstawiania dla 400K unikalnych metryk.

Powyżej zrzut ekranu: InfluxDB — Wykorzystanie wejścia-wyjścia podczas testu wstawiania dla 400K unikalnych metryk.

Powyżej zrzut ekranu: TimescaleDB — Wykorzystanie wejścia-wyjścia podczas testu wstawiania dla 400K unikalnych metryk.

Teraz jest jasne, że TimescaleDB osiąga limit wejścia-wyjścia, więc nie może wykorzystać pozostałych 12 vCPUs.

4M unikalnych szeregów czasowych

4M szeregów czasowych wydaje się nieco wyzywająco. Ale nasi konkurenci z powodzeniem zdają ten egzamin. Wyniki benchmarku:

• VictoriaMetrics: 2,2M punktów danych na sekundę; zużycie pamięci RAM: 6 GB; ostateczny rozmiar danych na dysku: 3 GB.
• InfluxDB: 330K punktów danych na sekundę; zużycie pamięci RAM: 20,5 GB; ostateczny rozmiar danych na dysku: 18,4 GB.
• TimescaleDB: 480K punktów danych na sekundę; użycie pamięci RAM: 2,5 GB; ostateczny rozmiar danych na dysku: 52 GB.

Wydajność InfluxDB spadła z 1,2 mln punktów danych na sekundę dla 400K szeregów czasowych do 330 tys. punktów danych na sekundę dla 4M szeregów czasowych. To znacząca utrata wydajności w porównaniu do innych konkurentów. Spójrzmy na wykresy użycia CPU, aby zrozumieć przyczynę tej utraty:

Powyżej zrzut ekranu: VictoriaMetrics — Użycie CPU podczas testu wstawiania dla unikalnego szeregu czasowego 4M.

Powyżej zrzut ekranu: InfluxDB — Użycie CPU podczas testu wstawiania dla unikalnego szeregu czasowego 4M.

Powyżej zrzut ekranu: TimescaleDB — Użycie CPU podczas testu wstawiania dla unikalnego szeregu czasowego 4M.

VictoriaMetrics wykorzystuje niemal całą moc procesora (CPU). Spadek na końcu odpowiada pozostałym zjawiskom LSM po wstawieniu wszystkich danych.

InfluxDB wykorzystuje tylko 8 z 16 vCPU, podczas gdy TimescaleDB wykorzystuje 4 z 16 vCPU. Co łączy ich wykresy? Wysoki udział iowait, co ponownie wskazuje na wąskie gardło wejścia-wyjścia.

TimescaleDB ma wysoki udział system. Przypuszczamy, że wysoka moc spowodowała wiele wywołań systemowych lub wiele minor page faults.

Spójrzmy na wykresy przepustowości dysku:

Powyżej zrzut ekranu: VictoriaMetrics — Użycie przepustowości dysku podczas wstawiania 4M unikalnych metryk.

Powyżej zrzut ekranu: InfluxDB — Użycie przepustowości dysku podczas wstawiania 4M unikalnych metryk.

Powyżej zrzut ekranu: TimescaleDB — Użycie przepustowości dysku podczas wstawiania 4M unikalnych metryk.

VictoriaMetrics osiągało limit 120 MB/s w szczycie, podczas gdy średnia prędkość zapisu wynosiła 40 MB/s. Prawdopodobnie podczas szczytu przeprowadzono kilka ciężkich zjawisk LSM.

InfluxDB znowu wyciska średnią przepustowość zapisu 200 MB/s z szczytami do 340 MB/s na dysku z limitem zapisu 120 MB/s 🙂

TimescaleDB nie jest już ograniczona przez dysk. Wydaje się, że jest ograniczona przez coś innego, co wiąże się z wysokim udziałem obciążenia CPU.

Spójrzmy na wykresy użycia IO:

Powyżej zrzut ekranu: VictoriaMetrics — Użycie wejścia-wyjścia podczas testu wstawiania dla unikalnego szeregu czasowego 4M.

Powyżej zrzut ekranu: InfluxDB — Użycie wejścia-wyjścia podczas testu wstawiania dla unikalnego szeregu czasowego 4M.

Powyżej zrzut ekranu: TimescaleDB — Wykorzystanie I/O podczas testu wstawiania dla unikalnej serii czasowej 4M.

Wykresy wykorzystania I/O odzwierciedlają wykresy wykorzystania przepustowości dysku — InfluxDB ogranicza I/O, podczas gdy VictoriaMetrics i TimescaleDB mają zapasowe zasoby I/O.

40M unikalnych serii czasowych

40M unikalnych serii czasowych okazało się zbyt dużym obciążeniem dla InfluxDB 🙁

Wyniki benchmarków:

• VictoriaMetrics: 1,7M punktów danych na sekundę; zużycie pamięci: 29 GB; zużycie przestrzeni dyskowej: 17 GB.
• InfluxDB: nie ukończono, ponieważ wymagało to ponad 60 GB pamięci operacyjnej.
• TimescaleDB: 330K punktów danych na sekundę, zużycie pamięci: 2,5 GB; zużycie przestrzeni dyskowej: 84 GB.

TimescaleDB pokazuje wyjątkowo niski i stabilny poziom wykorzystania pamięci — 2,5 GB — tyle samo, co dla 4M i 400K unikalnych metryk.

VictoriaMetrics stopniowo zwiększał wydajność o 100 tysięcy punktów danych na sekundę, aż przetworzono wszystkie 40M nazw metryk z etykietami. Następnie osiągnął stabilną prędkość wstawiania 1,5-2,0M punktów danych na sekundę, co dało ostateczny wynik 1,7M punktów danych na sekundę.

Wykresy dla 40M unikalnych serii czasowych są analogiczne do wykresów dla 4M unikalnych serii czasowych, więc je pominiemy.

Wnioski

• Nowoczesne TSDB są w stanie przetwarzać wstawienia dla milionów unikalnych serii czasowych na jednym serwerze. W następnym artykule sprawdzimy, jak dobrze TSDB obsługują zapytania dla milionów unikalnych serii czasowych.
• Niewystarczające obciążenie procesora zazwyczaj wskazuje na wąskie gardło I/O. Ponadto może to wskazywać na zbyt dużą blokadę, gdy tylko kilka wątków może działać jednocześnie.
• Wąskie gardło I/O rzeczywiście istnieje, zwłaszcza w magazynach bez SSD, takich jak wirtualizowane bloki urządzeń dostawców chmury.
• VictoriaMetrics zapewnia najlepszą optymalizację dla wolnych magazynów o niskim poziomie I/O. Oferuje najlepszą prędkość i najwyższy stopień kompresji.

Pobierz obraz jednego serwera VictoriaMetrics i przetestuj go na swoich danych. Odpowiedni statyczny plik binarny dostępny jest na GitHub.

Więcej informacji o VictoriaMetrics znajdziesz w tym artykuł.

Aktualizacja: opublikowano artykuł porównujący wydajność wstawiania VictoriaMetrics z InfluxDB z powtarzalnymi wynikami.

Aktualizacja #2: Przeczytaj także artykuł o pionowej skalowalności VictoriaMetrics vs InfluxDB vs TimescaleDB.

Aktualizacja #3: VictoriaMetrics teraz z otwartym kodem źródłowym!

Czat na Telegramie: https://t.me/VictoriaMetrics_ru1

Źródło: habr.com