TDengine 和 InfluxDB 查询性能对比测试报告

我们之前已经发布了 TDengine 和 InfluxDB 的写入性能测试报告，今天我们再来对比一下两款时序数据库产品的查询性能。

1. 前言

本报告包含了基础测试部分内容，并根据具体的场景，增加了部分扩展测试场景，以便更加全面、准确地呈现两款数据库产品在不同应用场景下的查询性能表现。

1.1 硬件环境

为便于大家复现该测试，我们在 Microsoft Azure 云服务上搭建了测试环境。测试中用到了两台服务器，分别部署客户端和服务器，客户端与服务器通过云服务的内网连接。

两台服务器的具体配置如下。

客户端	8C，Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz	16 GB	64 GB SSD，无写入情况下，4k 随机读取 IOPS 5000
服务端	16C， AMD EPYC 7452 32-Core Processor	128 GB	1 TB SSD，无写入情况下，4k 随机读取 IOPS 25000

操作系统均为 Ubuntu 20.10 Linux。使用的 Go 版本为 1.16。

1.2 软件安装

TDengine 2.1.7.2 社区版，可以在涛思官网下载。也可以通过 clone GitHub 上的代码自行编译生成。该版本的 git 的信息如下：

community version: 2.1.7.2 compatible_version: 2.0.0.0

gitinfo: c6be1bb809536182f7d4f27c0d8267b3b25c9354

InfluxDB 1.8.4（由于该性能测试框架最高只能适配到 1.8 版本，所以这里选取了 InfluxDB 1.8 版本进行对比），可以在 InfluxData 官网下载。

1.3 运行脚本生成查询用数据

1.3.1 安装准备

部署完 TDengine、InfluxDB 与 Go 语言环境，确保两台服务器的数据库也连接正常使用正常（建库删库写入查询功能均需测试，建库之后立即删除，如有问题立刻排查）

此外，在测试中应该注意以下几点（ TDengine 的默认配置文件为 /etc/taos/taos.cfg ）：

1）fsync 的设置要保持同步，InfluxDB 默认是无延时的 fsync，需要修改 TDengine 的这两个参数：walLevel=2 ，fsync=0 才能达到相同的配置环境。后续的一切测试均是在这个设置条件下完成。

2）TDengine 的客户端要把 maxSQLLength 开到最大 1048576。

3）客户端服务器要安装 TDengine 的客户端。（注意：bulk_load_tdengine 编译需要依赖 TDengine 客户端）

1.3.2 从 GitHub 取下代码,在客户端服务器执行：

git clone https://github.com/taosdata/timeseriesdatabase-comparisons

1.3.3 准备编译环境，生成写入程序，timeseriesdatabase-comparisons 的根目录为工作目录：

cd timeseriesdatabase-comparisons/build/tsdbcompare/
./compilation.sh

1.3.4 切换到build/tsdbcompare目录下，产生测试数据集合并写入数据库。

在build/tsdbcompare下执行./writ_to_server.sh -a "test217"
# 本次测试的服务端 hostname 是"test217"，./writ_to_server.sh -h 可以查看对应参数:
生成数据参数（总记录数=（t-e)*24*3600/ i * s）
i : 数据间隔，默认10s
s : 样本数量，默认100
t : 数据起始时间，默认'2018-01-01T00:00:00Z'
e : 数据终止时间，默认'2018-01-02T00:00:00Z'
g : 是否生成数据，默认1（1：生成数据，0：不生成数据）
T : TDengine的默认数据目录路径，默认为"/var/lib/taos"
I : InfluxDB默认数据目录路径，默认为"/var/lib/influxdb"
写入参数
b ： batchsize(默认5000）
w : workers(默认16）
n : TDengine写入方式(false:cgo,true:rest,默认false)
a : TDengine 和 InfluxDB 的 hostname 或者ip地址，默认为127.0.0.1
如果希望自定义更多参数值，可以查看 write_to_server.sh 脚本代码

1.3.5 生成查询文件，并进行查询测试，在build/tsdbcompare下运行脚本：

./read_all.sh -a "test217"
脚本参数和 write_to_server.sh 一致。

2. 测试运行

运行该测试要求关闭 TDengine 系统日志，然后自动执行脚本即可。

在不同的场景之间切换时，会重启数据库后台服务（Influxd/taosd），并清除 Linux 系统的全部缓存。

3. 对比测试结果

本小节说明运行测试脚本获得的对比测试结果，并对结果进行了初步的分析。

对于测试结果，所有的响应是测试脚本自动记录的时间，即该时间并不是单次查询执行的响应时间，而是完成 1,000 次重复查询最后获得的时间。需要说明的是，由于整个测试持续时间较长，测试获得的数据并非同一个时刻。不同的时间，测试程序运行过程中会受到云服务器所能发挥的最大性能影响，获得的结果数据能看到有轻微的抖动，但是整体趋势是一致的。

100 台设备模拟生成的 1 天的数据集，在 TDengine 中生成了 900 个子表，每个设备间隔 10 s 生成一条数据，总记录数是 7,776,000。

1,000 台设备在 TDengine 中生成了 9,000 个子表，每个设备间隔 10 s 生成一条记录，总记录数是 77,760,000。

测试主要包括四个测试场景，分别是：

场景一：通过标签过滤随机筛选出 8 个时间线后，取其中的最大值。
场景二：随机选取 1 h 时间区间，通过标签随机筛选出 8 个时间线，取其中的最大值。
场景三：随机选取 12 h 的时间区间，通过标签随机筛选出 8 个时间线，使用 10 min 作为一个时间窗口，获取每个时间窗口的最大值。
场景四：随机选取 1 h 时间区间，通过标签过滤随机筛选出 8 个时间线，使用 1 min 为一个时间窗口，获取每个时间窗口的最大值。

通过测试结果可以看出：整体来看，TDengine 在多种场景下（单线程、多线程）的性能均优于 InfluxDB。在极少的几个情况下，TDengine 与 InfluxDB 的差异非常小。在更多的场景下，TDengine 拥有数倍的性能优势，部分场景的性能优势能达到 40 倍。

3.1 100 台设备数据集查询结果对比

本部分呈现的是，在 100 台设备上模拟 1 天的数据生成的结果集上，运行测试程序所获得的性能对比测试结果。

图 1. 100 台设备数据集上的查询结果对比

由图 1 可以看到，在所有的场景中，只有第三个测试场景单线程的时候 TDengine 查询响应时间超过 InfluxDB，其他的场景均优于 InfluxDB，并且部分场景（场景二）下其查询性能有着 40 倍的巨大优势。具体的测试响应数据见附录表 1。

图 2. 不同场景下调整查询线程获得最终响应时间

在 1,000 个设备上测试结果显示出 TDengine 仍然展现出较大的性能优势，即使部分相对于 InfluxDB 较慢的场景（多线程场景下的场景四），其差距也非常小。而领先的部分，则仍然有巨大的性能优势，最高的性能差达到近 20 倍，具体的查询响应数据见附录表 2。

3.2 扩展测试

在上述的两个标准测试之外，我们基于现有的数据集合设计了一系列扩展测试，以期更全面准确地评估两个数据库产品在不同场景下的性能表现。在以下测试中，我们只使用 cgo 的运行测试结果。

3.2.1 标签筛选量对查询性能的影响

调整过滤 host 的数量，设定并行执行的 work 为 16，使用 1,000 个设备的数据集合执行全部查询，所获得的结果如下表所示。查询响应时间单位为秒，数值越小越好。

图 3. 不同场景下改变筛选时间线查询响应时间

可以看到，随着筛选的时间线的增加，InfluxDB 的查询响应时间在四个测试场景均呈现快速增加的趋势，而 TDengine 对于数据筛选规模的变大则呈现出相对稳定的查询响应时间，并且随着时间线筛选规模的扩大呈现出更大的优势。由此可以推断，随着查询规模的继续扩大，InfluxDB 的查询响应时间还会继续快速增加。各种场景下的查询响应具体时间见表 3。

3.2.2 查询时间窗口对查询性能的影响

为了评估不同长度的时间窗口对查询性能的影响，我们选取了第四个查询场景，设定并行执行的 work 数量 16，时间区间是随机选取的 1 h / 2 h / 4 h / 8 h / 12 h 等连续时间段，单个聚合时间窗口维持在 1 min 不变。获得的查询响应时间如图 4 所示。

图 4. 改变查询时间区间范围对查询响应的影响

由上图可见，TDengine 相对于 InfluxDB 有更好的查询性能，并且，随着查询时间区间的增加，TDengine 的领先优势持续扩大，当查询时间区间是 1 小时的时候，TDengine 只比 InfluxDB 快约 8%。但是当查询区间增加到 12 小时的时候，TDengine 的查询优势已经扩大到近 2 倍。具体查询响应时间见表 4。

3.2.3 复杂查询性能表现

考虑到标准测试中只使用了较为简单的查询函数，我们使用多个查询函数组合的复杂查询，评估查询性能。我们选取了第四个运行场景，随机选取 1 h 的时间段，聚合时间窗口为 1 min，过滤筛选 8 个时间线进行查询处理。

三个场景分别是：

max(value), count(value),first(value),last(value)
top(value, 10)
max(value),count(value),first(value),last(value),integral(value1)*spread(ts)/1000 在该场景中，TDengine 中没有 integral 函数，因此采用 TWA(value) * Spread(value) / 1000 的计算方式进行了等效替代。此外，integral 函数查询的是另一个列 value1，而不是 value。

图 5. 不同查询场景下的响应时间对比

由上图的结果可以看到，在三种复杂函数组合的查询条件下，TDengine 查询性能均优于 InfluxDB。特别是在第一种组合场景中，TDengine 的性能是 InfluxDB 的 2.5 倍。具体的查询响应时间见表 5。

3.2.4 数据读取测试

在这个场景测试中，我们测试了 TDengine 和 InfluxDB 的数据读取表现。针对全部数据集，不限定查询时间范围，调整标签的过滤条件，投影查询来获取全部的数据内容。其结果如图 6 所示。

图 6. 不同数据规模的投影查询响应时间

可以看到，在提取不同比例的情况下，TDengine 的总的时间开销稳定在 InfluxDB 的 11% 左右，即该项测试的性能，TDengine 是 InfluxDB 的 8.78 倍，并且该优势随着时间线数量的增加而得到扩大，在 128 个时间线的时候，达到了 9.37 倍。即在更大数据规模的情况下，TDengine 展现出了更好的性能优势。在时间线为 256 的时候，InfluxDB 最终未能完成测试运行，服务端出现了连接拒绝的问题，而TDengine也仅用时 365.61 s 就跑完该项测试。