Porównano VictoriaMetrics, TimescaleDB i InfluxDB na zbiorze danych zawierającym miliard punktów danych należących do 40 tys. unikalnych szeregów czasowych.
Kilka lat temu była era Zabbixa. Każdy serwer typu bare metal miał nie więcej niż kilka wskaźników – wykorzystanie procesora, wykorzystanie pamięci RAM, wykorzystanie dysku i wykorzystanie sieci. W ten sposób metryki z tysięcy serwerów można zmieścić w 40 tysiącach unikalnych szeregów czasowych, a Zabbix może używać MySQL jako backendu dla danych szeregów czasowych :)
Obecnie sam z konfiguracjami domyślnymi zapewnia ponad 500 wskaźników na przeciętnym hoście. Jest wiele dla różnych baz danych, serwerów WWW, systemów sprzętowych itp. Wszystkie one dostarczają szeregu przydatnych wskaźników. Wszystko zaczynają ustalać dla siebie różne wskaźniki. Istnieje Kubernetes z klastrami i zasobnikami, które udostępniają wiele metryk. Powoduje to, że serwery udostępniają tysiące unikalnych wskaźników na hosta. Zatem unikalny szereg czasowy 40 tys. nie jest już dużą mocą. Staje się głównym nurtem i powinien być łatwo obsługiwany przez dowolną nowoczesną bazę danych TSDB na jednym serwerze.
Jaka jest obecnie duża liczba unikalnych szeregów czasowych? Prawdopodobnie 400 tys. lub 4 mln? Albo 40m? Porównajmy współczesne bazy danych TSDB z tymi liczbami.
Instalowanie benchmarku
jest doskonałym narzędziem do analizy porównawczej baz danych TSDB. Pozwala wygenerować dowolną liczbę metryk poprzez przekazanie wymaganej liczby szeregów czasowych podzielonej przez 10 - flaga (dawny -scale-var). 10 to liczba pomiarów (metryk) wygenerowanych na każdym hoście lub serwerze. Następujące zbiory danych zostały wygenerowane przy użyciu TSBS na potrzeby testu porównawczego:
- 400 tys. unikalnych szeregów czasowych, 60-sekundowy odstęp między punktami danych, dane obejmują pełne 3 dni, całkowita liczba punktów danych ~1.7B.
- Unikalne serie czasowe 4M, interwał 600 sekund, dane obejmują 3 pełne dni, całkowita liczba punktów danych ~1.7B.
- 40M unikalnych szeregów czasowych, interwał 1-godzinny, dane obejmują 3 pełne dni, całkowita liczba punktów danych ~2.8B.
Klient i serwer działały na dedykowanych instancjach w chmurze Google'a. Instancje te miały następujące konfiguracje:
- vCPU: 16
- RAM: 60 GB
- Pamięć: Standardowy dysk twardy o pojemności 1 TB. Zapewnia przepustowość odczytu/zapisu 120 Mb/s, 750 operacji odczytu na sekundę i 1,5 tys. zapisów na sekundę.
Bazy TSDB zostały wyodrębnione z oficjalnych obrazów dokowanych i uruchomione w oknie dokowanym w następujących konfiguracjach:
-
WiktoriaMetryka:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Do obsługi dużej mocy wymagane są wartości InfluxDB (-e).Szczegóły w ):
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 zaczerpnięta z plik):
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=100Moduł ładujący dane został uruchomiony z 16 równoległymi wątkami.
Ten artykuł zawiera wyłącznie wyniki testów porównawczych wstawiania. Wyniki selektywnego benchmarku zostaną opublikowane w osobnym artykule.
400 tys. unikalnych szeregów czasowych
Zacznijmy od prostych elementów – 400 tys. Wyniki testów porównawczych:
- VictoriaMetrics: 2,6 mln punktów danych na sekundę; Użycie pamięci RAM: 3 GB; ostateczny rozmiar danych na dysku: 965 MB
- InfluxDB: 1.2 mln punktów danych na sekundę; Zużycie pamięci RAM: 8.5 GB; ostateczny rozmiar danych na dysku: 1.6 GB
- Skala czasu: 849 tys. punktów danych na sekundę; Zużycie pamięci RAM: 2,5 GB; ostateczny rozmiar danych na dysku: 50 GB
Jak widać z powyższych wyników, VictoriaMetrics wygrywa pod względem wydajności wstawiania i współczynnika kompresji. Oś czasu wygrywa pod względem wykorzystania pamięci RAM, ale zajmuje dużo miejsca na dysku - 29 bajtów na punkt danych.
Poniżej znajdują się wykresy wykorzystania procesora dla każdej bazy TSDB podczas testu porównawczego:
Powyżej znajduje się zrzut ekranu: VictoriaMetrics — obciążenie procesora podczas testu wstawiania dla unikalnej metryki 400 KB.
Powyżej znajduje się zrzut ekranu: InfluxDB - obciążenie procesora podczas testu wstawiania dla unikalnej metryki 400K.
Powyżej znajduje się zrzut ekranu: TimescaleDB — obciążenie procesora podczas testu wstawiania dla unikalnej metryki 400 KB.
VictoriaMetrics wykorzystuje wszystkie dostępne vCPU, podczas gdy InfluxDB nie wykorzystuje w pełni ~2 z 16 vCPU.
Skala czasu wykorzystuje tylko 3–4 z 16 procesorów wirtualnych. Wysokie proporcje iowait i systemu na wykresie skali czasu TimescaleDB wskazują na wąskie gardło w podsystemie wejścia/wyjścia (I/O). Przyjrzyjmy się wykresom wykorzystania przepustowości dysku:
Powyżej znajduje się zrzut ekranu: VictoriaMetrics — wykorzystanie przepustowości dysku w teście wstawiania dla unikalnych metryk 400 KB.
Powyżej znajduje się zrzut ekranu: InfluxDB — wykorzystanie przepustowości dysku podczas testu wstawiania dla unikalnych wskaźników 400 KB.
Powyżej znajduje się zrzut ekranu: TimescaleDB — wykorzystanie przepustowości dysku podczas testu wstawiania dla unikalnych metryk 400 KB.
VictoriaMetrics rejestruje dane z szybkością 20 Mb/s, a szczytowo do 45 Mb/s. Szczyty odpowiadają dużym częściowym połączeniom w drzewie .
InfluxDB zapisuje dane z szybkością 160 MB/s, natomiast dysk ma pojemność 1 TB przepustowość zapisu 120 MB/s.
TimescaleDB jest ograniczony do przepustowości zapisu 120 Mb/s, ale czasami przekracza ten limit i osiąga wartości szczytowe 220 Mb/s. Piki te odpowiadają dolinom niewystarczającego wykorzystania procesora na poprzednim wykresie.
Przyjrzyjmy się wykresom wykorzystania wejść/wyjść (I/O):
Powyżej znajduje się zrzut ekranu: VictoriaMetrics — wstaw testowe użycie we/wy dla 400 tys. unikalnych metryk.
Powyżej znajduje się zrzut ekranu: InfluxDB — wstaw testowe użycie we/wy dla 400 tys. unikalnych metryk.
Powyżej znajduje się zrzut ekranu: TimescaleDB — wstaw testowe użycie we/wy dla 400 tys. unikalnych metryk.
Teraz jest jasne, że TimescaleDB osiąga limit operacji we/wy, więc nie może wykorzystać pozostałych 12 procesorów wirtualnych.
Unikalne szeregi czasowe 4M
Szeregi czasowe 4M wyglądają na nieco wymagające. Ale nasi konkurenci pomyślnie zdają ten egzamin. Wyniki testów porównawczych:
- VictoriaMetrics: 2,2 mln punktów danych na sekundę; Zużycie pamięci RAM: 6 GB; ostateczny rozmiar danych na dysku: 3 GB.
- InfluxDB: 330 tys. punktów danych na sekundę; Zużycie pamięci RAM: 20,5 GB; ostateczny rozmiar danych na dysku: 18,4 GB.
- TimescaleDB: 480 tys. punktów danych na sekundę; Zuż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ę w przypadku szeregów czasowych o długości 400 tys. do 330 tys. punktów danych na sekundę w przypadku szeregów czasowych o długości 4 mln. Stanowi to znaczną utratę wydajności w porównaniu do innych konkurentów. Przyjrzyjmy się wykresom użycia procesora, aby zrozumieć pierwotną przyczynę tej straty:
Powyżej znajduje się zrzut ekranu: VictoriaMetrics — użycie procesora podczas testu wstawiania dla unikalnej serii czasowej 4M.
Powyżej znajduje się zrzut ekranu: InfluxDB - użycie procesora podczas testu wstawiania dla unikalnych szeregów czasowych 4M.
Powyżej znajduje się zrzut ekranu: TimescaleDB - użycie procesora podczas testu wstawiania dla unikalnej serii czasowej 4M.
VictoriaMetrics wykorzystuje prawie całą moc jednostki przetwarzającej (CPU). Spadek na końcu odpowiada pozostałym połączeniom LSM po wstawieniu wszystkich danych.
InfluxDB wykorzystuje tylko 8 z 16 vCPU, podczas gdy TimsecaleDB wykorzystuje 4 z 16 vCPU. Co łączy ich wykresy? Wysoki udział iowait, co ponownie wskazuje na wąskie gardło we/wy.
TimescaleDB ma wysoki udział system. Zakładamy, że duża moc spowodowała wiele lub wiele wywołań systemowych .
Przyjrzyjmy się wykresom przepustowości dysku:
Powyżej znajduje się zrzut ekranu: VictoriaMetrics — wykorzystanie przepustowości dysku do wstawienia unikalnych metryk 4M.
Powyżej znajduje się zrzut ekranu: InfluxDB — wykorzystanie przepustowości dysku do wstawienia unikalnych metryk 4M.
Powyżej znajduje się zrzut ekranu: TimescaleDB — wykorzystanie przepustowości dysku do wstawienia unikalnych metryk 4M.
VictoriaMetrics osiągnęła w szczycie limit 120 MB/s, podczas gdy średnia prędkość zapisu wyniosła 40 MB/s. Jest prawdopodobne, że w szczycie doszło do kilku ciężkich fuzji LSM.
InfluxDB znowu wyciska średnią przepustowość zapisu na poziomie 200 MB/s ze szczytami do 340 MB/s na dysku z limitem zapisu 120 MB/s :)
TimescaleDB nie jest już ograniczony dyskiem. Wydaje się, że jest ono ograniczone przez coś innego, związanego z wysokimi proporcjami системной Obciążenie procesora.
Spójrzmy na wykresy wykorzystania IO:
Powyżej znajduje się zrzut ekranu: VictoriaMetrics - Używanie wejść/wyjść podczas testu wstawiania dla unikalnej serii czasowej 4M.
Powyżej znajduje się zrzut ekranu: InfluxDB - Używanie wejść/wyjść podczas testu wstawiania dla unikalnej serii czasowej 4M.
Powyżej znajduje się zrzut ekranu: TimescaleDB - użycie we/wy podczas testu wstawiania dla unikalnych szeregów czasowych 4M.
Wzorce wykorzystania operacji we/wy odzwierciedlają wzorce przepustowości dysku — InfluxDB ma ograniczone operacje we/wy, podczas gdy VictoriaMetrics i TimescaleDB mają zapasowe zasoby we/wy.
40M unikalnych szeregów czasowych
40M unikalnych szeregów czasowych było za duże dla InfluxDB :)
Wyniki testów porównawczych:
- VictoriaMetrics: 1,7 mln punktów danych na sekundę; Zużycie pamięci RAM: 29 GB; Wykorzystanie miejsca na dysku: 17 GB.
- InfluxDB: Nie ukończono, ponieważ wymagało więcej niż 60 GB pamięci RAM.
- TimescaleDB: 330 tys. punktów danych na sekundę, wykorzystanie pamięci RAM: 2,5 GB; Wykorzystanie miejsca na dysku: 84 GB.
TimescaleDB pokazuje wyjątkowo niskie i stabilne użycie pamięci RAM przy 2,5 GB - takie samo jak w przypadku unikalnych wskaźników 4M i 400K.
Rozwiązanie VictoriaMetrics powoli zwiększało skalę z szybkością 100 tys. punktów danych na sekundę, aż do przetworzenia wszystkich 40 mln oznaczonych nazw metryk. Następnie osiągnął stałą szybkość wstawiania wynoszącą 1,5–2,0 mln punktów danych na sekundę, więc ostateczny wynik wyniósł 1,7 mln punktów danych na sekundę.
Wykresy dla unikalnych szeregów czasowych 40M są podobne do wykresów dla unikalnych szeregów czasowych 4M, więc je pomińmy.
odkrycia
- Nowoczesne bazy danych TSDB są w stanie przetwarzać wstawki dla milionów unikalnych szeregów czasowych na jednym serwerze. W następnym artykule sprawdzimy, jak dobrze bazy danych TSDB przeprowadzają selekcję w milionach unikalnych szeregów czasowych.
- Niewystarczające wykorzystanie procesora zwykle wskazuje na wąskie gardło we/wy. Może to również wskazywać, że blokowanie jest zbyt grube i tylko kilka wątków może działać jednocześnie.
- Wąskie gardło we/wy istnieje, szczególnie w przypadku pamięci masowej innej niż SSD, takiej jak zwirtualizowane urządzenia blokowe dostawców usług w chmurze.
- VictoriaMetrics zapewnia najlepszą optymalizację w przypadku powolnej pamięci masowej o małej liczbie operacji we/wy. Zapewnia najlepszą prędkość i najlepszy stopień kompresji.
Pobierać i wypróbuj to na swoich danych. Odpowiedni statyczny plik binarny jest dostępny pod adresem .
Przeczytaj więcej o VictoriaMetrics w tym .
Aktualizacja: opublikowano z powtarzalnymi wynikami.
Aktualizacja nr 2: Przeczytaj także .
Aktualizacja nr 3: !
Czat telegramowy:
Źródło: www.habr.com