TStorage – testy wydajnościowe
Na stronie zawarto opis testu wydajności różnych baz danych zaprojektowanych do efektywnego przetwarzania szeregów czasowych. W ramach testu porównujemy:
- TStorage
- InfluxDBv1
- TimescaleDB
Test ma na celu porównanie wydajności zapisu, a także odczytu danych. Źródłem danych jest symulacja pracy serwerów znajdujących się w centrach danych. Wielkością odczytową są różne parametry procesora. Test ten jest przygotowany na podstawie zadań wykorzystywanych przez ogólnodostępny, popularny zestaw wykorzystywany do porównywania wydajności pomiędzy bazami danych szeregów czasowych – TSBS (Time Series Benchmark Suite) „cpu-only”. Więcej informacji na temat tego testu można znaleźć tutaj: https://github.com/timescale/tsbs
Sprzęt wykorzystany do testów
Każdy test został wykonany na tym samym sprzęcie:
- dysk twardy z systemem operacyjnym: HDD 2TB SATA 6Gb/s 512n 7,2 tys. obr./min 3,5″
- dyski twarde przeznaczone na bazę danych oraz źródło rekordów: HDD 4TB SATA 6Gb/s 512n 7,2 tys. obr./min 3,5″
- pamięć RAM: 8 * 16GB pamięci RDIMM, 5600MT/s
- procesor: Intel Xeon Silver 4514Y, 2GHz, 16 rdzeni / 32 wątki, 16GT/s, 30 MB pamięci podręcznej, Turbo, HT (150W) DDR5-4400
- karta sieciowa: Broadcom 57504 Quad Port 10/25 GbE, SFP28, OCP 3.0 NIC
Przygotowanie baz danych do testów:
Test w każdym przypadku został uruchomiony lokalnie, z 1 dyskiem wykorzystywanym na system operacyjny i obsługę testu, 1 dyskiem przechowującym dane testowe oraz 1 dyskiem wykorzystywanym na wyłączność przez testowaną bazę. Jeśli baza danych korzystała z dodatkowych mechanizmów logujących dopuszczona była możliwość generowania ich na dysk systemu operacyjnego. Użyty system plików to XFS dla dysków z danymi testowymi i bazą danych oraz ext4 dla systemu operacyjnego – Debian 12.
TimescaleDB:
W celu przygotowania bazy TimescaleDB korzystamy z udostępnionej instrukcji instalacji najnowszej wersji bazy opisanej tutaj: https://docs.timescale.com/self-hosted/latest/install/installation-linux/
Konfiguracja TimescaleDB została zmodyfikowana tak, aby foldery, które zawierają wrzucone dane znalazły się na oddzielnym dysku, a właścicielem bazy danych był użytkownik „tstorage”. Do zapewnienia zgodności działającej instancji z zaleceniami jej twórców uruchomiony został dodatkowo program „timescaledb-tune”, aby zapewnić odpowiednie dobranie parametrów konfiguracyjnych.
Przebieg testu
Test rozpoczynamy od przygotowania danych wejściowych w formacie zgodnym z mechanizmami wczytywania danej bazy danych. Dane gotowe do wysyłki są następnie kompresowane za pomocą programu „gzip”.
Dane wejściowe dla baz TimescaleDB oraz InfluxDB generowane są za pomocą skryptów udostępnionych przez test TSBS. Do każdej generacji wykorzystujemy tę samą wartość ziarna liczb pseudolosowych, aby zapewnić identyczność wyników. Dokładny opis danych:
- ziarno generatora liczb pseudolosowych (tzw. „seed” ) = 123
- zakres danych – 2 lata (2016-01-01 00:00:00 – 2018-01-01 00:00:00)
- ilość liczników – 30’000
- odległość pomiędzy kolejnymi pomiarami – 5min
- ilość różnych wartości w każdym pomiarze – 10
- format wartości pomiarowej – liczba całkowita
W przypadku TStorage’a do przygotowania danych wejściowych wykonywana jest konwersja formatu bazy TimescaleDB na format danych zgodny z referencyjnym klientem do bazy TStorage za pomocą odpowiedniego skryptu.
Generatory TSBS oprócz opisanych wartości liczbowych generują dodatkowe metadane na temat pomiarów. Są one ignorowane podczas umieszczania rekordów w TStorage’u, ponieważ nie są wykorzystywane podczas trwania testu. TStorage jako baza pomiarowa nie przechowuje nadmiarowych metadanych na temat rekordów.
Format danych przygotowany dla klientów
Baza InfluxDB
cpu,hostname=host_0,region=eu-central-1,datacenter=eu-central-1a,rack=6,os=Ubuntu15.10,arch=x86,team=SF,service=19,service_version=1,service_environment=test usage_user=58i,usage_system=2i,usage_idle=24i,usage_nice=61i,usage_iowait=22i,usage_irq=63i,usage_softirq=6i,usage_steal=44i,usage_guest=80i,usage_guest_nice=38i 1451606400000000000
cpu,hostname=host_1,region=us-west-1,datacenter=us-west-1a,rack=41,os=Ubuntu15.10,arch=x64,team=NYC,service=9,service_version=1,service_environment=staging usage_user=84i,usage_system=11i,usage_idle=53i,usage_nice=87i,usage_iowait=29i,usage_irq=20i,usage_softirq=54i,usage_steal=77i,usage_guest=53i,usage_guest_nice=74i 1451606400000000000
cpu,hostname=host_2,region=sa-east-1,datacenter=sa-east-1a,rack=89,os=Ubuntu16.04LTS,arch=x86,team=LON,service=13,service_version=0,service_environment=staging usage_user=29i,usage_system=48i,usage_idle=5i,usage_nice=63i,usage_iowait=17i,usage_irq=52i,usage_softirq=60i,usage_steal=49i,usage_guest=93i,usage_guest_nice=1i 1451606400000000000
Baza TimescaleDB
tags,hostname string,region string,datacenter string,rack string,os string,arch string,team string,service string,service_version string,service_environment string
cpu,usage_user,usage_system,usage_idle,usage_nice,usage_iowait,usage_irq,usage_softirq,usage_steal,usage_guest,usage_guest_nice
tags,hostname=host_0,region=eu-central-1,datacenter=eu-central-1a,rack=6,os=Ubuntu15.10,arch=x86,team=SF,service=19,service_version=1,service_environment=test
cpu,1451606400000000000,58,2,24,61,22,63,6,44,80,38
Baza TStorage
Za wartość CID przyjęliśmy ID hosta w odpowiadającej mu kolumnie hostname. MID oraz MOID zostały przyjęte jako 0, gdyż każdy z hostów generuje co 5 minut tylko 1 rekord.
0 0 0 473299200000000000 0x0000003a00000002000000180000003d000000160000003f000000060000002c0000005000000026
1 0 0 473299200000000000 0x000000540000000b00000035000000570000001d00000014000000360000004d000000350000004a
2 0 0 473299200000000000 0x0000001d00000030000000050000003f00000011000000340000003c000000310000005d00000001
3 0 0 473299200000000000 0x0000000800000015000000590000004e0000001e0000005100000021000000180000001800000052
4 0 0 473299200000000000 0x000000020000001a0000004000000006000000260000001400000047000000130000002800000036
5 0 0 473299200000000000 0x0000004c000000280000003f0000000700000051000000140000001d00000037000000140000000f
Zapisywanie rekordów
- czyścimy zawartość dysku przechowującego dane, aby zapewnić te same warunki startowe
- uruchamiamy testowaną bazę danych
- uruchamiamy pomiar czasu (za pomocą systemowego narzędzia „time”)
- uruchamiamy skrypt zapisujący dane (narzędzia udostępnione przez TSBS dla baz TimescaleDB i InfluxDB; autorskie narzędzie do umieszczania danych w TStorage’u)
- zatrzymujemy pomiar czasu
Następnie porównujemy otrzymane wyniki. W każdym z przypadków wrzucamy 6’315’840’000 rekordów, gdzie każdy rekord przechowuje 10 pomiarów. Za porównywaną metrykę bierzemy średnią ilość rekordów zapisywanych na sekundę.
Tabela 1: Wyniki wrzucania rekordów do wybranej bazy danych.
| TStorage | TimescaleDB | InfluxDB | |
|---|---|---|---|
| Prędkość zapisywania rekordów | 1571104 rekordów/s | 269217 rekordów/s | 414425 rekordów/s |
| Czas zapisu | 67 min | 391 min | 254 min |
Pobieranie danych
Przygotowaliśmy trzy scenariusze testowe do pobierania danych, wykonywane na jednym wątku. W ramach jednego scenariusza przygotowujemy 100 losowych zapytań. Aby poprawić spójność wyników dla różnych systemów buforowania danych każde zapytanie jest powtarzane, a mierzony zostaje czas wykonania drugiego zapytania. Czasy wykonania są mierzone wewnątrz właściwych skryptów wykonujących pracę. Aby ograniczyć wpływ zewnętrznych czynników na wyniki testów nie wyświetlamy na ekranie rezultatów zapytań (choć każde wykorzystane narzędzie udostępnia taką możliwość do potwierdzenia spójności wyników).
Scenariusze testowe
- Pojedyncze zapytanie polega na losowym wybraniu jednego hosta, jednej metryki oraz 12-godzinnego przedziału czasu, a następnie pobraniu wszystkich pomiarów z tego zakresu.*
- Pojedyncze zapytanie polega na losowym wybraniu jednego hosta oraz 12-godzinnego przedziału czasu, a następnie pobraniu wszystkich pomiarów dla każdej metryki z tego zakresu.*
- Losujemy 12-godzinny przedział czasu i jedną wartość pomiarową. Wyliczamy średnią wartość pomiarową dla godzinnych interwałów dla wszystkich liczników (dla każdego z liczników oddzielnie).
* Podzbiór scenariuszy TSBS zakłada, że dla pobranych wartości z liczników, każdy z interwałów będzie miał wyliczoną wielkość maksymalną. Aby zasymulować pobranie rekordów bez agregacji odstępy pomiędzy pomiarami zostały dobrane w taki sposób, aby w każdym interwale znalazła się tylko jedna wartość.
Wyniki testów
Tabela 2: Średni czas wykonania zapytań testowych dla poszczególnych baz danych.
| Numer scenariusza | TStorage | TimescaleDB | InfluxDB |
|---|---|---|---|
| 1 | 1ms | 135ms | 2ms |
| 2 | 1ms | 176ms | 6.5ms |
| 3 | 397ms | 2090ms | 4277ms |
Podsumowanie
W naszych testach porównywaliśmy wydajność trzech baz danych pod względem zapisywania i odczytywania rekordów generowanych przez duże ilości liczników. W obu przypadkach porównywaliśmy wersje 1-węzłowe zapisujące do 1 dysku. Testy pokazały, że niezależnie od tego czy użytkownik preferuje zapis czy odczyt danych, to dla tak zdefiniowanych scenariuszy pracy TStorage okazał się preferowanym rozwiązaniem.
