VictoriaMetrics, TimescaleDB och InfluxDB jämfördes i på en datauppsättning med en miljard datapunkter som tillhör 40K unika tidsserier.
För några år sedan var det en era av Zabbix. Varje barmetallserver hade inte mer än några få indikatorer - CPU-användning, RAM-användning, diskanvändning och nätverksanvändning. På så sätt kan mätvärden från tusentals servrar passa in i 40 tusen unika tidsserier, och Zabbix kan använda MySQL som backend för tidsseriedata :)
För närvarande ensam med standardkonfigurationer ger över 500 mätvärden på den genomsnittliga värden. Det är många för olika databaser, webbservrar, hårdvarusystem, etc. De tillhandahåller alla en mängd användbara mätvärden. Allt börja sätta olika indikatorer för sig själva. Det finns Kubernetes med kluster och poddar som exponerar många mätvärden. Detta resulterar i att servrar exponerar tusentals unika mätvärden per värd. Så den unika 40K-tidsserien har inte längre hög effekt. Det håller på att bli mainstream och bör enkelt hanteras av alla moderna TSDB på en enda server.
Vad är det stora antalet unika tidsserier för tillfället? Förmodligen 400K eller 4M? Eller 40m? Låt oss jämföra moderna TSDB med dessa siffror.
Installera ett riktmärke
är ett utmärkt benchmarkingverktyg för TSDB:er. Det låter dig generera ett godtyckligt antal mätvärden genom att skicka det erforderliga antalet tidsserier dividerat med 10 - flagga (före detta -scale-var). 10 är antalet mätningar (metrics) som genereras på varje värd eller server. Följande datauppsättningar genererades med TSBS för riktmärket:
- 400K unika tidsserier, 60 sekunders intervall mellan datapunkter, data sträcker sig över hela 3 dagar, ~1.7B totalt antal datapunkter.
- 4M unika tidsserier, 600 sekunders intervall, data sträcker sig över 3 hela dagar, ~1.7B totalt antal datapunkter.
- 40 miljoner unika tidsserier, 1 timmes intervall, data spänner över hela 3 dagar, ~2.8B totalt antal datapunkter.
Klienten och servern kördes på dedikerade instanser i Google moln. Dessa instanser hade följande konfigurationer:
- vCPU:er: 16
- RAM: 60 GB
- Lagring: Standard 1TB hårddisk. Den ger 120 Mbps läs/skrivgenomströmning, 750 läsoperationer per sekund och 1,5K skrivningar per sekund.
TSDB extraherades från officiella docker-bilder och kördes i docker med följande konfigurationer:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
InfluxDB (-e)-värden krävs för att stödja hög effekt. Se detaljer i ):
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 (konfiguration hämtad från fil):
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=100Dataladdaren kördes med 16 parallella trådar.
Den här artikeln innehåller endast resultat för riktmärken för infogning. Resultaten av det selektiva riktmärket kommer att publiceras i en separat artikel.
400K unik tidsserie
Låt oss börja med enkla element - 400K. Benchmarkresultat:
- VictoriaMetrics: 2,6 miljoner datapunkter per sekund; RAM-användning: 3 GB; slutlig datastorlek på disk: 965 MB
- InfluxDB: 1.2 miljoner datapunkter per sekund; RAM-användning: 8.5 GB; slutlig datastorlek på disk: 1.6 GB
- Tidsskala: 849K datapunkter per sekund; RAM-användning: 2,5 GB; slutlig datastorlek på disk: 50 GB
Som du kan se från resultaten ovan vinner VictoriaMetrics i insättningsprestanda och kompressionsförhållande. Tidslinjen vinner i RAM-användning, men den använder mycket diskutrymme - 29 byte per datapunkt.
Nedan är CPU-användningsdiagrammen för var och en av TSDB:erna under benchmark:
Ovan är en skärmdump: VictoriaMetrics - CPU-belastning under insättningstest för ett unikt 400K-mått.
Ovan är en skärmdump: InfluxDB - CPU-belastning under insättningstest för unikt metriskt 400K.
Ovan är en skärmdump: TimescaleDB - CPU-belastning under insättningstest för ett unikt mått på 400K.
VictoriaMetrics använder alla tillgängliga vCPU:er, medan InfluxDB underutnyttjar ~2 av 16 vCPU:er.
Tidsskalan använder bara 3-4 av de 16 vCPU:erna. Höga proportioner av iowait och system i TimescaleDB-tidsskalegrafen indikerar en flaskhals i in-/utgångssystemet (I/O). Låt oss titta på diagrammet för användning av diskbandbredd:
Ovan är en skärmdump: VictoriaMetrics - Disk Bandwidth Usage in Insertion Test for Unique Metrics 400K.
Ovan är en skärmdump: InfluxDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
Ovan är en skärmdump: TimescaleDB - Disk Bandwidth Usage on Insertion Test for Unique Metrics 400K.
VictoriaMetrics registrerar data med 20 Mbps med toppar upp till 45 Mbps. Toppar motsvarar stora partiella sammanslagningar i trädet .
InfluxDB skriver data med 160 MB/s, medan en 1 TB-enhet skrivkapacitet 120 MB/s.
TimescaleDB är begränsad till skrivkapacitet på 120 Mbps, men ibland bryter den denna gräns och når 220 Mbps i toppvärden. Dessa toppar motsvarar dalarna med otillräckligt CPU-utnyttjande i föregående graf.
Låt oss titta på användningsdiagrammen för input/output (I/O):
Ovan är en skärmdump: VictoriaMetrics - Infoga test I/O-användning för 400K unika mätvärden.
Ovan är en skärmdump: InfluxDB - Infoga test I/O-användning för 400K unika mätvärden.
Ovan är en skärmdump: TimescaleDB - Infoga test I/O-användning för 400K unika mätvärden.
Det är nu klart att TimescaleDB når sin I/O-gräns, så den kan inte använda de återstående 12 vCPU:erna.
4M unik tidsserie
4M tidsserier ser lite utmanande ut. Men våra konkurrenter klarar detta prov med framgång. Benchmarkresultat:
- VictoriaMetrics: 2,2 miljoner datapunkter per sekund; RAM-användning: 6 GB; slutlig datastorlek på disk: 3 GB.
- InfluxDB: 330K datapunkter per sekund; RAM-användning: 20,5 GB; slutlig datastorlek på disk: 18,4 GB.
- TimescaleDB: 480K datapunkter per sekund; RAM-användning: 2,5 GB; slutlig datastorlek på disk: 52 GB.
InfluxDB-prestandan sjönk från 1,2 miljoner datapunkter per sekund för en 400K tidsserie till 330K datapunkter per sekund för en 4M tidsserie. Detta är en betydande prestandaförlust jämfört med andra konkurrenter. Låt oss titta på graferna för CPU-användning för att förstå grundorsaken till denna förlust:
Ovan är en skärmdump: VictoriaMetrics - CPU-användning under insättningstest för en unik 4M tidsserie.
Ovan är en skärmdump: InfluxDB - CPU-användning under insättningstest för unika 4M tidsserier.
Ovan är en skärmdump: TimescaleDB - CPU-användning under insättningstest för en unik 4M tidsserie.
VictoriaMetrics använder nästan all processorkraft (CPU). Nedgången i slutet motsvarar den återstående LSM sammanslagningen efter att all data har infogats.
InfluxDB använder endast 8 av 16 vCPU:er, medan TimsecaleDB använder 4 av 16 vCPU:er. Vad har deras grafer gemensamt? Hög andel iowait, vilket återigen indikerar en I/O-flaskhals.
TimescaleDB har en hög andel system. Vi antar att hög effekt resulterade i många systemsamtal eller många .
Låt oss titta på diskens genomströmningsdiagram:
Ovan är en skärmdump: VictoriaMetrics - Använder diskbandbredd för att infoga 4M unika mätvärden.
Ovan är en skärmdump: InfluxDB - Använder diskbandbredd för att infoga 4M unika mätvärden.
Ovan är en skärmdump: TimescaleDB - Använder diskbandbredd för att infoga 4M unika mätvärden.
VictoriaMetrics nådde en gräns på 120 MB/s vid topp, medan den genomsnittliga skrivhastigheten var 40 MB/s. Det är troligt att flera tunga LSM-fusioner utfördes under toppen.
InfluxDB pressar återigen ut en genomsnittlig skrivkapacitet på 200 MB/s med toppar på upp till 340 MB/s på en disk med en skrivgräns på 120 MB/s :)
TimescaleDB är inte längre diskbegränsad. Det verkar vara begränsat av något annat relaterat till hög andel системной CPU-belastning.
Låt oss titta på graferna för IO-användning:
Ovan är en skärmdump: VictoriaMetrics - Använda I/O under insättningstest för en unik 4M tidsserie.
Ovan är en skärmdump: InfluxDB - Använder I/O under insättningstest för en unik 4M tidsserie.
Ovan är en skärmdump: TimescaleDB - I/O-användning under insättningstest för unika 4M tidsserier.
IO-användningsmönster speglar diskbandbredden - InfluxDB är IO-begränsad, medan VictoriaMetrics och TimescaleDB har lediga IO-resurser.
40 miljoner unika tidsserier
40 miljoner unika tidsserier var för stora för InfluxDB :)
Benchmarkresultat:
- VictoriaMetrics: 1,7 miljoner datapunkter per sekund; RAM-användning: 29 GB; Diskutrymmesanvändning: 17 GB.
- InfluxDB: Slutfördes inte eftersom det krävde mer än 60 GB RAM.
- TimescaleDB: 330K datapunkter per sekund, RAM-användning: 2,5 GB; Diskutrymmesanvändning: 84GB.
TimescaleDB visar exceptionellt låg och stabil RAM-användning på 2,5 GB - samma som för de unika 4M- och 400K-måtten.
VictoriaMetrics skalade långsamt upp med en hastighet av 100 40 datapunkter per sekund tills alla 1,5 miljoner taggade metriska namn bearbetades. Han uppnådde sedan en ihållande insättningshastighet på 2,0-1,7 miljoner datapunkter per sekund, så slutresultatet blev XNUMX miljoner datapunkter per sekund.
Graferna för 40 miljoner unika tidsserier liknar graferna för 4 miljoner unika tidsserier, så låt oss hoppa över dem.
Resultat
- Moderna TSDB:er kan bearbeta inlägg för miljontals unika tidsserier på en enda server. I nästa artikel kommer vi att testa hur väl TSDBs utför urval över miljontals unika tidsserier.
- Otillräckligt CPU-användning indikerar vanligtvis en I/O-flaskhals. Det kan också tyda på att blockeringen är för grov, med endast ett fåtal trådar som kan löpa åt gången.
- I/O-flaskhalsen finns, särskilt i icke-SSD-lagring som molnleverantörers virtualiserade blockenheter.
- VictoriaMetrics ger den bästa optimeringen för långsam, låg I/O-lagring. Det ger den bästa hastigheten och det bästa kompressionsförhållandet.
Ladda ner och prova det på din data. Motsvarande statiska binär är tillgänglig på .
Läs mer om VictoriaMetrics i denna .
Uppdatering: publicerad med reproducerbara resultat.
Uppdatering #2: Läs också .
Uppdatering #3: !
Telegramchatt:
Källa: will.com