VictoriaMetrics，TimescaleDB，InfluxDB

介绍

在上一篇文章中，VictoriaMetrics，TimescaleDB和InfluxDB已在具有10万个数据点（属于40K唯一时间序列）的数据集上进行了基准测试。

几年前有Zabbix时代。每个裸机服务器只有几个指标-CPU使用率，RAM使用率，磁盘使用率和网络使用率。因此，来自数千个服务器的指标可以适应40K个唯一的时间序列，而Zabbix可以使用MySQL作为时间序列数据的后端：）

当前，具有默认配置的单个node_exporter在一个平均主机上公开500多个指标。存在用于各种数据库，Web服务器，硬件系统等的许多导出器。它们都公开了许多有用的指标。越来越多的应用程序开始公开自身的各种指标。有一个带有集群和Pod的Kubernetes公开了许多指标。这导致服务器每台主机公开数千个唯一指标。因此40K独特的时间序列不再是高基数。它已成为主流，任何现代TSDB都必须在单服务器上轻松对其进行处理。

目前有多少独特的时间序列？大概是400K还是4M？还是40M？让我们用这些数字作为现代TSDB的基准。

基准设定

TSBS是TSDB的出色基准测试工具。它允许通过将所需的时间序列数除以10到-scale标志（以前的-scale-var）来生成任意数量的度量。10是每个秤主机生成的测量（度量）数。TSBS已为基准生成以下数据集：

· 独特的时间序列400K，数据点之间的间隔为60秒，数据涵盖了整整3天，数据点总数约为1.7B。

· 4M独特的时间序列，间隔600秒，数据涵盖整整3天，数据点总数约为1.7B。

· 独特的时间序列40M，间隔1小时，数据涵盖整整3天，数据点总数约为2.8B。

客户端和服务器在Google Cloud中专用的n1-standard-16实例上运行。这些实例具有以下配置：

· vCPU：16

· 内存：60GB

· 存储：1TB标准HDD磁盘。它提供120MB / s的读/写吞吐量，每秒750次读操作和每秒1.5K写操作。

TSDB是从官方docker映像中提取的，并在docker中使用以下配置运行：

· 维多利亚指标：

docker运行-it –rm -v / mnt / disks / storage / vmetrics-data：/ victoria-metrics-data -p 8080：8080 valyala / victoria-metrics

· InfluxDB（高基数支持需要-e值。有关详细信息，请参阅文档）：

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-dataInfluxdb

· TimescaleDB（此文件采用了配置）：

MEM=free -m |grep" Mem" |awk’{print $ 7}’

让" SHARED=$ MEM / 4"让" CACHE=2 * $ MEM / 3"让" WORK=（$ MEM- $ SHARED）/ 30"让" MAINT=$ MEM / 16"让" 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：最新的pg10 postgres -cmax_wal_size=$ {WAL} MB -clog_line_prefix="％m [％p]：[％x]％u @％d" -clogging_collector=off -csynchronous_commit=off -cshared_buffers=$SHAREDMB-ceffectiv{e}_{c}ach{e}_{s}ize=$ {CACHE} MB -cwork_mem=$ {WORK} MB -cmaintenance_work_mem=$ {MAINT} MB -cmax_files_per_process=100

数据加载器以16个并发线程运行。

本文仅包含插入基准测试的结果。选择的基准测试结果将在另一篇文章中发布。

400K独特的时间序列

让我们从简单的基数开始-40万。基准结果：

· VictoriaMetrics：260万个数据点/秒；内存使用量：3GB；磁盘上的最终数据大小：965MB

· InfluxDB：120万个数据点/秒；内存使用量：8.5GB;磁盘上的最终数据大小：1.6GB

· 时标：849K个数据点/秒；内存使用量：2.5GB；磁盘上的最终数据大小：50GB

从上面的结果可以看出，VictoriaMetrics在插入性能和压缩比方面均胜出。时间刻度可以提高RAM的使用率，但它会占用大量磁盘空间-每个数据点29字节。

以下是基准测试期间每个TSDB的CPU使用率图：

> VictoriaMetrics — CPU usage during insert benchmark for 400K unique metrics

> InfluxDB — CPU usage during insert benchmark for 400K unique metrics

> TimescaleDB — CPU usage during insert benchmark for 400K unique metrics

VictoriaMetrics利用所有可用的vCPU，而InfluxDB在16个vCPU中利用不足2个。

时间刻度在16个vCPU中仅利用3-4个。iowait和TimescaleDB图上的系统份额较高，这是I / O子系统的瓶颈。让我们看一下磁盘带宽使用情况图：

> VictoriaMetrics — disk bandwidth usage during insert benchmark for 400K unique metrics

> InfluxDB — disk bandwidth usage during insert benchmark for 400K unique metrics

> TimescaleDB — disk bandwidth usage during insert benchmark for 400K unique metrics

VictoriaMetrics以20MB / s的速度写入数据，峰值速度高达45MB / s。峰值对应于LSM树中的大部分合并。

根据文档，InfluxDB以160MB / s的速度写入数据，而1TB磁盘的写入吞吐量应限制为120MB / s。

TimescaleDB受120MB / s的写入吞吐量限制，但有时会突破限制并达到220MB / s的峰值。这些峰值对应于上图中的CPU使用不足下降。

让我们看一下I / O使用情况图表：

> VictoriaMetrics — I/O usage during insert benchmark for 400K unique metrics

> InfluxDB — I/O usage during insert benchmark for 400K unique metrics

> TimescaleDB — I/O usage during insert benchmark for 400K unique metrics

现在很清楚，TimescaleDB达到了I / O限制，因此它无法利用剩余的12个vCPU。

4M独特的时间序列

4M时间序列看起来有些挑战。但是我们的学历提升竞争对手成功通过了这项考试。基准结果：

· VictoriaMetrics：每秒220万个数据点；内存使用量：6GB；磁盘上的最终数据大小：3GB。

· InfluxDB：330K数据点/秒；内存使用量：20.5GB;磁盘上的最终数据大小：18.4GB。

· TimescaleDB：480K数据点/秒；内存使用量：2.5GB；磁盘上的最终数据大小：52GB。

InfluxDB性能从400K时间序列的1.2M数据点/秒下降到4M时间序列的330K数据点/秒。与其他竞争对手相比，这是严重的性能损失。让我们看一下CPU使用率图表，以了解造成这种损失的根本原因：

> VictoriaMetrics — CPU usage during insert benchmark for 4M unique time series

> InfluxDB — CPU usage during insert benchmark for 4M unique time series

> TimescaleDB — CPU usage during insert benchmark for 4M unique time series

VictoriaMetrics几乎利用了所有CPU能力。最后的下降对应于在插入所有数据后剩余的LSM合并。

InfluxDB仅使用16个vCPU中的8个，而TimsecaleDB使用16个vCPU中的4个。他们的图有什么共同点？较高的iowait份额，这再次表明了I / O瓶颈。

TimescaleDB具有较高的系统份额。猜猜基数高会导致许多系统调用或许多较小的页面错误。

让我们看一下磁盘带宽图：

> VictoriaMetrics — disk bandwidth usage for insert benchmark 4M unique metrics

> InfluxDB — disk bandwidth usage for insert benchmark 4M unique metrics

> TimescaleDB — disk bandwidth usage for insert benchmark 4M unique metrics

VictoriaMetrics最高达到120MB / s的限制，而平均写入速度为40MB / s。高峰期间可能执行了多次重LSM合并。

InfluxDB再次压缩了200MB / s的平均写入吞吐量，在具有120MB / s的写入限制的磁盘上，峰值达到了340MB / s ：)

TimescaleDB不再受磁盘限制。看起来它受到与高系统CPU份额相关的其他限制。

让我们看一下IO使用情况图表：

> VictoriaMetrics — IO usage during insert test for 4M unique time series

> InfluxDB — IO usage during insert test for 4M unique time series

> TimescaleDB — IO usage during insert test for 4M unique time series

IO使用情况图表重复了磁盘带宽使用情况图表-InfluxDB受IO限制，而VictoriaMetrics和TimescaleDB具有备用IO资源。

40M独特的时间序列

对于InfluxDB而言，40M独特的时间序列实在太多了：(

基准结果：

· VictoriaMetrics：170万个数据点/秒；内存使用量：29GB；磁盘空间使用量：17GB。

· InfluxDB：尚未完成，因为它需要60GB以上的RAM。

· TimescaleDB：330K数据点/秒；内存使用量：2.5GB；磁盘空间使用量：84GB。

TimescaleDB显示出非常低且稳定的RAM使用量-2.5GB-与4M和400K唯一度量标准相同。

VictoriaMetrics以10万个数据点/秒的速度缓慢增长，直到处理了所有带有标签的40M度量标准名称。然后达到了1.5M–2.0M数据点/秒的稳定插入速度，因此最终结果为1.7M数据点/秒。

40M独特时间序列的图形与4M独特时间序列的图形相似，因此我们跳过它们。

结论

· 现代TSDB能够在单个服务器上处理数百万个唯一时间序列的插入。我们将在下一篇文章中检查TSDB在数百万个唯一时间序列中执行选择的效果如何。

· CPU利用率不足通常指向I / O瓶颈。另外，当只有几个线程可以同时运行时，这可能表明锁定过于粗糙。

· I / O瓶颈确实存在，尤其是在非SSD存储（例如云提供商的虚拟块设备）上。

· VictoriaMetrics为低iops的慢速存储提供了最佳的优化。它提供了最佳速度和最佳压缩比。

下载单服务器VictoriaMetrics映像，然后对数据进行尝试。相应的静态二进制文件在GitHub上可用。

在本文中阅读有关VictoriaMetrics的更多信息。

更新：发表了一篇文章，比较了VictoriaMetrics与InfluxDB的插入性能以及可重复的结果。

更新＃2：另请阅读有关VictoriaMetrics与InfluxDB与TimescaleDB的垂直可伸缩性的文章。

更新3：VictoriaMetrics现在是开源的！