基于 TSBS 标准数据集时序数据库 TimescaleDB、InfluxDB 与 TDengine 在 IoT 场景性能对比测试

上期 TDengine 团队发布了《基于 TSBS 在DevOps 场景下的对比测试报告》，本期我们探寻下 IoT 场景，时序数据库 TDengine 对比 TimescaleDB、InfluxDB，写入和查询的性能表现。

在 TSBS 的 IoT场景，预设五种规模的卡车车队场景，TDengine 写入性能均优于 TimescaleDB 和 InfluxDB。相对于 TimescaleDB，TDengine 写入速度最领先的场景达到其 3.3 倍（场景一），最小的为 1.04倍（场景四）；且对于场景四，如果将每个采集点的记录条数由 18 条增加到 576 条，且 vgroups=24 时，TDengine 写入速度是 TimescaleDB 的 7 倍。相对于 InfluxDB，TDengine 写入速度最领先的场景达到其 16.2 倍（场景五），最小为 1.82 倍（场景三)。

磁盘空间占用方面，TimescaleDB 在所有五个场景下数据规模均显著地大于 InfluxDB 和 TDengine，并且这种差距随着数据规模增加快速变大。TimescaleDB 在场景四和场景五中占用磁盘空间是 TDengine 的 11.6 倍和 12.2 倍。在前面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 非常接近，但是在大数据规模的场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间是 TDengine 的 2.6 倍和 2.8 倍。

查询方面，在场景一（只包含 4 天的数据）与场景二的 15 个不同类型的查询中，TDengine 的查询平均响应时间全面优于 InfluxDB 和 TimescaleDB，而且在复杂查询上优势更为明显，同时具有最小的计算资源开销。

相对于 InfluxDB，场景一，TDengine查询性能是其 2.4 倍到 155.9 倍，平均 21.2 倍，场景二，TDengine 查询性能是其 6.3 到 426.3 倍，平均是 68.7 倍。

相对于 TimescaleDB，场景一，TDengine 查询性能是其 1.1 到 16.4 倍，平均 5.1 倍，场景二，TDengine 查询性能是其 1.02 倍到 87 倍，平均 23.3 倍。

本测试报告中的数据在准备好物理环境后，可以由脚本一键执行生成。

点击这里，下载完整测试报告。

一、测试背景

1.1 测试场景介绍

我们使用了 IoT 场景作为基础数据集。TSBS 框架模拟虚拟货运公司车队的一组卡车的时序数据，针对每个卡车的诊断数据（diagnostics）记录包含 3 个测量值和 1 个（纳秒分辨率）时间戳，8 个标签值；卡车的指标信息（readings）记录包含 7 个测量值和 1 个（纳秒分辨率）时间戳，8 个标签值。数据模式（schema）见下图 1。生成的数据每 10 秒一条记录，IoT 场景引入了环境因素，所以每个卡车存在无序和缺失的时间序列数据。

在整个基准性能评估中，涉及以下五个场景，每个场景的具体数据规模和特点见下表，由于存在数据缺失，所以单个卡车数据记录取记录均值：

**表 1. 场景数据集说明**
	场景一 100 devices × 10 metrics	场景二 4,000 devices × 10 metrics	场景三 100,000 devices × 10 metrics	场景四 1,000,000 devices × 10 metrics	场景五 10,000,000 devices × 10 metrics
数据间隔	10 秒	10 秒	10 秒	10 秒	10 秒
持续时间	31 天	4 天	3 小时	3 分钟	3 分钟
卡车数目	100	4000	100,000	1,000,000	10,000,000
单个卡车记录数	241,145	31,118	972	16	16
数据集记录数	48,229,186	248,944,316	194,487,997	32,414,619	324,145,090

可以看到，五个场景的区别主要在于数据集所包含的单个卡车记录数量，卡车总数的差异。数据时间间隔均维持在 10 秒。整体上看，五个场景的数据规模都不大，数据规模最大的是场景五，数据规模最小的场景四只有 32,414,619 条记录。在场景四和场景五中，由于卡车数量相对较多，所以数据集仅覆盖了 3 分钟的时间跨度。

1.2 数据建模

在 TSBS 框架中， TimescaleDB 和 InfluxDB 会自动创建相应的数据模型并生成对应格式的数据。本文不再赘述其具体的数据建模方式，只介绍 TDengine 的数据建模的策略。

TDengine 一个重要的创新是其独特的数据模型——为每个设备创建独立的数据表（子表），并通过超级表（Super Table）在逻辑上和语义上对同一采集类型的设备进行统一管理。针对 IoT 场景的数据内容，我们为每个卡车创建了两张表（后文中设备和卡车同义），用来存储诊断信息和指标信息的时序数据。在 1.1 章节数据记录中，我们看到 truck name 可以作为每个卡车的标识 Id，因为有两张超级表，因此我们在 TDengine 中使用 truck name 拼接 d（r）作为子表的名称。我们使用如下的语句创建名为 diagnostics 和 readings 的超级表，分别包含 3 、7 个测量值和 8 个标签。

CREATE STABLE `readings` (`ts` TIMESTAMP, `latitude` DOUBLE, `longitude` DOUBLE, `elevation` DOUBLE, `velocity` DOUBLE, `heading` DOUBLE, `grade` DOUBLE, `fuel_consumption` DOUBLE) TAGS (`name` VARCHAR(30), `fleet` VARCHAR(30), `driver` VARCHAR(30), `model` VARCHAR(30), `device_version` VARCHAR(30), `load_capacity` DOUBLE, `fuel_capacity` DOUBLE, `nominal_fuel_consumption` DOUBLE)
 
CREATE STABLE `diagnostics` (`ts` TIMESTAMP, `fuel_state` DOUBLE, `current_load` DOUBLE, `status` BIGINT) TAGS (`name` VARCHAR(30), `fleet` VARCHAR(30), `driver` VARCHAR(30), `model` VARCHAR(30), `device_version` VARCHAR(30), `load_capacity` DOUBLE, `fuel_capacity` DOUBLE, `nominal_fuel_consumption` DOUBLE)

然后，我们使用如下语句创建名为 r_truck_1和 d_truck_1 的子表：

CREATE TABLE `r_truck_1` USING `readings` (`name`, `fleet`, `driver`, `model`, `device_version`, `load_capacity`, `fuel_capacity`, `nominal_fuel_consumption`) TAGS ("truck_1", "South", "Albert", "F-150", "v1.5", 2.000000e+03, 2.000000e+02, 1.500000e+01)
 
CREATE TABLE `d_truck_1` USING `diagnostics` (`name`, `fleet`, `driver`, `model`, `device_version`, `load_capacity`, `fuel_capacity`, `nominal_fuel_consumption`) TAGS ("truck_1", "South", "Albert", "F-150", "v1.5", 2.000000e+03, 2.000000e+02, 1.500000e+01)

上述语句创建了一个子表。由此可知，对于 100 个设备（CPU）的场景一，我们将会建立 100 个子表。对于 4000 个设备的场景二，系统中将会建立 4000 个子表用以存储各自对应的数据。在 TSBS 的框架生成的数据中，我们发现存在标签信息 truck 为 null 的数据内容，对于这部分数据，我们建立了 d_truck_null(r_truck_null)的表，用以存储所有未能标识 truck 的数据。

1.3 软件版本和配置

本报告比较 TDengine, InfluxDB 与 TimeScaleDB 三种类型的时序数据库，下面对使用的版本和配置做出说明。

1.3.1 TDengine

我们直接采用 TDengine 3.0 版，从 GitHub 克隆 TDengine 代码编译版本作为性能对比的版本。

gitinfo: 1bea5a53c27e18d19688f4d38596413272484900

在服务器上编译安装运行。

cmake .. -DDISABLE_ASSERT=true -DSIMD_SUPPORT=true -DCMAKE_BUILD_TYPE=Release  -DBUILD_TOOLS=false

在 TDengine 的配置文件中设置了六个涉及查询的配置参数。

numOfVnodeFetchThreads   4

queryRspPolicy           1

compressMsgSize          128000

SIMD-builtins            1

tagFilterCache           1

numOfTaskQueueThreads    24

第一个参数 numOfVnodeFetchThreads 设置 Vnode 的Fetch 线程数量为 4个，第二个参数 queryRspPolicy 打开 query response 快速返回机制，第三个参数 compressMsgSize 让TDengine 在传输层上大于 128000 bytes的消息自动进行压缩，第四个参数是如果 CPU支持，启用内置的 FMA/AVX/AVX2 硬件加速。第五个参数开启tag 列的过滤缓存。第六个参数是设置任务队列的线程数量为 24。

对于 IoT 场景，表数目是卡车规模数的二倍，所以 TDengine 建库默认创建 12 个 vnodes，即创建的表会按照表名随机分配到 12 个虚拟节点（virtual node, VNode) 中。打开 LRU 缓存，设置为 last_row 缓存模式。对于场景一和场景二，stt_trigger 设置为 1，此时 TDengine 会准备一个 Sorted Time-series Table (STT) 文件，用于容纳单表写入量小于 minimum rows 的时候，数据直接保存在 STT 文件中，当 STT 文件中无法容纳新数据的时候，会将 STT 中的数据整理，再写入到数据文件中。对于场景三配置 stt_trigger 为 8，场景四和五，stt_trigger 设置为 16 ，即允许最多生成 16 个 STT 文件。针对低频表多的场景，需要适度增加 STT 的值，以此来获得更好的写入性能。

1.3.2 TimescaleDB

为确保结果具有可比性，我们选用 TimescaleDB 版本 version 2.10.1。为获得较好的性能，TimescaleDB 需要针对不同的场景设置不同的 Chunk 参数，不同场景下参数的设置如下表所示。

**表 2. 不同场景下 TimescaleDB 的 chunk 配置**
	场景一	场景二	场景三	场景四	场景五
设备数目	100	4000	100,000	1,000,000	10,000,000
Chunk 数目	12	12	12	12	12
Chunk 持续时间	2.58 天	8 小时	15 分	15 秒	15 秒
Chunk 内记录数	2,009,550	10,372,680	8,103,667	1,350,610	13,506,045

上述参数的设置，充分参考了对比报告[7]中推荐的配置参数设置，以确保能够最大化写入性能指标。

1.3.3 InfluxDB

我们选择 InfluxDB version 1.8.10。这里没有使用 InfluxDB 最新的 2.x 版本是因为 TSBS 没有对其进行适配，所以选用了能够运行 TSBS 框架的 InfluxDB 最新版本。

我们采用对比报告[7]中推荐的方式配置 InfluxDB，将缓冲区配置为 80G，以便 1000w 设备写入时能够顺利进行，同时开启 Time Series Index（TSI）。

配置系统在系统插入数据完成 30s 后开始数据压缩。

cache-max-memory-size = "80g"
max-values-per-tag = 0
index-version = "tsi1"
compact-full-write-cold-duration = "30s"

二、测试步骤

2.1 硬件准备

为与对比报告[7]的环境高度接近，我们使用亚马逊 AWS 的 EC2 提供的 r4.8xlarge 类型实例作为基础运行平台，包括 1 台服务器、1 台客户端共两个节点构成的环境。客户端与服务器硬件配置完全相同，客户端与服务器使用 10 Gbps 网络连接。配置简表如下：

**表 3. 物理节点配置**
	CPU	Memory	Disk
服务器	Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz 32vCPU	244GiB	800G SSD，3000 IOPS. 吞吐量上限是 125 MiB/Sec
客户端	Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz 32vCPU	244GiB	800G SSD，3000 IOPS. 吞吐量上限是 125 MiB/Sec

2.2 服务器环境准备

为运行测试脚本，服务器 OS 需要是 ubuntu20.04 以上的系统。AWS EC2 的服务器系统信息如下：

OS： Linux tv5931 5.15.0-1028-aws #32~20.04.1-Ubuntu SMP Mon Jan 9 18:02:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Gcc：gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)
基础环境，版本信息为：Go1.16.9 , python3.8 , pip20.0.2 (无需手动安装，测试脚本将自动安装）
编译依赖：gcc , cmake, build-essential, git, libssl-dev (无需手动安装，测试脚本将自动安装）

但请做两个配置：

client 和 server 配置 ssh 访问免密，以便脚本可不暴露密码，可参考文档：免密配置。
保证 client 和 server 之间所有端口开放。

2.3 获取测试脚本

为便于重复测试，隐藏繁琐的下载、安装、配置、启动、汇总结果等细节，整个 TSBS 的测试过程被封装成一个测试脚本。重复本测试报告，需要先下载该测试脚本，脚本暂支持 ubuntu20.04 的系统。以下操作要求具有 root 权限。

在客户端机器，进入测试目录拉取代码，默认进入 /usr/local/src/ 目录，

cd /usr/local/src/ && apt install git && git clone https://github.com/taosdata/tsbs.git && cd tsbs/scripts/tsdbComp

修改配置文件 test.ini 中服务端和客户端的 IP 地址（这里配置 AWS 的私网地址即可）和 hostname，如果服务器未配置免密，还需要配置服务器端的 root 密码，本次测试 IoT 场景，故修改 caseType 为 iot。

clientIP="192.168.0.203"   #client ip
clientHost="trd03"         #client hostname
serverIP="192.168.0.204"   #server ip
serverHost="trd04"         #server hostname
serverPass="taosdata123"   #server root password
caseType="iot"             #testcase

2.4 一键执行对比测试

执行以下命令：

nohup bash tsdbComparison.sh > test.log &

测试脚本将自动安装 TDengine, InfluxDB, TimeScaleDB 等软件，并自动运行各种对比测试项。在目前的硬件配置下，整个测试跑完需要大约三天的时间。测试结束后，将自动生成 CSV 格式的对比测试报告，并存放在客户端的 /data2 目录，对应 load 和 query 前缀的文件夹下。

三、写入性能对比

3.1 不同场景下写入性能对比

基于 TSBS 标准数据集时序数据库 TimescaleDB、InfluxDB 与 TDengine 在 IoT 场景性能对比测试 - TDengine Database 时序数据库 — **图 2. 不同场景下写入性能的对比（metrics/sec. 数值越大越好）**

可以看到在全部五个场景中，TDengine 的写入性能全面超越 TimescaleDB 和 InfluxDB。在场景二中 TDengine 写入性能是 TimescaleDB 的最大达到 3.3倍，在差距最小场景五中，是 TimescaleDB 写入性能的 1.04 倍。相对于 InfluxDB，TDengine在场景五中写入性能是 InfluxDB 的 16 倍，在差距最小的场景三中也有 1.8 倍。

我们还注意到，随着设备数规模的增加，所有系统写入基本上呈现下降趋势。TimescaleDB 在小规模数据情况下写入性能不及 InfluxDB，但是随着设备数量的增加，其写入性能超过了 InfluxDB，这点上与对比报告[7]中的结论一致。

**表 4. TDengine 相对于 InfluxDB 与TimescaleDB 写入性能**
	TDengine/InfluxDB	TDengine/TimescaleDB
100 devices × 10 metrics	196.42%	332.21%
4,000 devices × 10 metrics	327.26%	320.90%
100,000 devices × 10 metrics	182.91%	245.73%
1,000,000 devices × 10 metrics	272.08%	125.85%
10,000,000 devices × 10 metrics	1620.21%	104.40%

3.2 写入过程资源消耗对比

数据写入速度并不能够全面的反映三个系统在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics （场景四）为例，检查数据写入过程中的服务器和客户端（包括客户端与服务器）的整体负载状况，并以此来对比三个系统在写入过程中服务器/客户端节点的资源占用情况，这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。

3.2.1 服务端 CPU 开销

图四展示了在场景四写入过程之中服务器端 CPU 负载状况。可以看到，三个系统在返回给客户端写入完成消息以后，都还继续使用服务器的资源进行相应的处理工作，这点上，TimescaleDB 尤为明显，TimescaleDB 在 7X 秒的时候即反馈客户端写入完成，但是其服务器端仍然调用 CPU 资源进行了数据压缩和整理工作，当然整个工作带来的 CPU 负载相对而言并不高，只有其峰值 CPU 开销的一半左右，但是其持续时间相当长，接近其净写入时间的 4 倍。InfluxDB 则使用相当多的 CPU 资源，瞬时峰值使用了全部的 CPU 资源，其写入负载较高，并且其持续时间比 TimescaleDB 更长，当然远长于 TDengine。三个系统对比，TDengine 对服务器的 CPU 需求最小，峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见，TDengine 独特的数据模型对于时序数据写入不仅在性能上，在整体的资源开销上也具有非常大的优势。

3.2.2 磁盘 I/O 对比

图 4 展示了 1,000,000 devices × 10 metrics （场景四）数据写入过程中服务器端磁盘写入状态。可以看到，结合着服务器端 CPU 开销表现，其 IO 动作与 CPU 呈现同步的活跃状态。

写入相同规模的数据集，TDengine 在写入过程中对于磁盘写入能力的占用远小于 TimescaleDB 和 InfluxDB，写入过程只占用了部分磁盘写入能力（125MiB/Sec. 3000IOPS）。从图上能看到，数据写入过程中磁盘的 IO 瓶颈是确实存在的。InfluxDB 长时间消耗完全部的磁盘写入能力，TimescaleDB 写入过程对于写入的消耗相对 InfluxDB来说要更具优势，但是仍然远超过了 TDengine 对磁盘写入能力的需求。

3.2.3 客户端 CPU 开销

从图 5 可以看到，客户端上 TDengine 对 CPU 的需求大于 TimescaleDB 和 InfluxDB，而 InfluxDB 在整个写入过程中，客户端负载整体上来说，三个系统中计算资源占用最低，对客户端压力最小，其写入的压力基本上完全集中在服务端。这种模式很容易导致服务端成为瓶颈，TimescaleDB 相对于 InfluxDB 而言，对于客户端压力更大，CPU 峰值达到 20% 左右。TDengine 在客户端的开销最大，峰值瞬间达到了 70%，然后快速回落。TDengine 在客户端的开销相比于 TimescaleDB 多了 1 倍。综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在系统整体 CPU 开销上TDengine 仍然具有优势。

3.3 写入性能对比总结

在全部的场景中，TDengine 的写入性能超过 TimescaleDB 和 InfluxDB。在整个写入过程中，TDengine 除了在提供了更高的写入能力的前提下，在服务器的 CPU 和 IO 上，也均远优于 TimescaleDB 和 InfluxDB。对于服务器的磁盘 IO 开销远小于 TimescaleDB 和 InfluxDB。即使加上客户端的开销统计，TDengine 在写入开销上远优于 TimescaleDB 和 InfluxDB。

3.4 磁盘空间占用

三个系统数据完全落盘以后，比较了三个系统在不同场景下的磁盘空间占用比较。

从图 6 可以看到，TimescaleDB 在所有的场景下数据规模均显著地大于 InfluxDB 和 TDengine，并且这种差距随着数据规模增加快速变大。TimescaleDB 在场景四和场景五中占用磁盘空间超过了 TDengine 的 11 倍。在前面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 比较接近。但是在场景四/五两个场景中，InfluxDB 落盘后文件占用的磁盘空间是 TDengine 的 2 倍以上。

这里还有个小插曲，表 5 反应了 TimescaleDB 的压缩比率，TimescaleDB 在小数剧规模的情况下，压缩比正常。但是在大数据规模场景四和场景五中，压缩以后的磁盘空间占用比例反而增大了 3.4 倍左右，疑似 bug。

**表 5. TimescaleDB 写入后压缩磁盘空间占用比例**
压缩后磁盘空间占用（KB）	压缩前磁盘空间占用（KB）	压缩比率
998312	6907312	14%
4246528	36490408	12%
6035528	26290904	23%
16612380	4841552	343%
165769964	48305396	343%

3.5 性能基准评估扩展部分

为了更全面地评估 TDengine 在默认参数下写入性能，我们在下面的性能评估中调整可能会影响写入性能的两个参数，进行评估测试。

3.5.1 虚拟节点（vnodes）数量

我们调整数据库中虚拟节点数量（默认是 12）为 12，18， 24，并衡量不同 vnode 数量情况下 TDengine 写入性能。

**表 6. 不同虚拟节点数据量情况写入性能变化**
	scale=1,000,000 场景四		scale=10,000,000 场景五
vnodes=12	1,867,506.54	100%	1,404,185.26	100%
vnodes=18	2,052,924.52	109.9%	1,556,203.18	103.6%
vnodes=24	2,100,190.87	112.4%	1,612,303.67	114.8%

我们看到，在较多的设备的场景（场景四、五）中，增加 vnodes 的数量，TDengine 写入性能提升明显。可见在不同规模的场景中，可以通过调整虚拟节点的数量来获得更好的写入性能。

3.5.2 设备记录数量

TDengine 为一个设备一张表的数据模型，需要在数据写入时创建表，建表操作对每个设备只执行一次，但这使得 TDengine 在数据写入的准备阶段时间耗时较多。当单个表中数据量增加以后，数据准备（建表）的开销被分摊到更多的数据写入的整体开销中，以场景四（1,000,000 devices × 10 metrics）为例，单个设备的数据量仅有 18 条。当我们调整参数，将单个设备记录数据增加到 36、72、144 条时，整体写入时间更长，因此表现出来就是建表开销被分摊到更多的数据写入过程中，建表的开销相对于数据写入的耗时占比越来越小，相应的整体写入速度也越来越快。因此可以看到，TDengine 表现出了更加明显的写入优势。（这里每张表的记录数忽略了 IoT 场景中丢失的记录。所以单个设备记录数据这个值并非百分百准确）

我们调整 vnodes 数量配置，同时测试两个不同 vnodes 数量情况下的写入性能指标。如图 7 所示，随着表中记录数的增加，vgroups=12 和 vgroups=24，TDengine 写入性能均呈现出持续增加的趋势。当设备记录数达到 576 行（此时数据集规模约等于 32,414,619 x 32 = 10.37 亿行数据记录）的时候，vgroups=12 时，写入性能达到 2,827,696.64 metrics/sec，性能均大幅领先 TimescaleDB 与 InfluxDB，是 TimescaleDB 的6.1 倍， InfluxDB 的 4.6 倍。

TimescaleDB 写入性能在单表记录数量大于 72 行以后出现了快速衰减。InfluxDB 在单设备记录增加过程中，写入性能有衰减，但衰减趋势非常缓慢。

3.5.3 总结

通过调整不同的数据库参数(vgroups)，以及设置不同的数据规模（增加每个设备包含记录数）方式，我们在更多的方面评估了 TDengine 在 TSBS 基准数据集上的写入性能。通过这一系列深入的对比可以看到，针对更大规模（设备数量和每个设备记录数量）数据集，TDengine 可以通过简单调整虚拟节点数量的方式，获得更高的写入性能，并且 TDengine 在针对大数据集写入场景下展现出更好的性能优势，同时具有远低于 TimescaleDB 和 InfluxDB 对服务端资源（服务器 CPU 和磁盘 IO、内存等）的开销。

四、查询性能对比

在查询性能评估部分，我们使用场景一（只包含4天数据，这个修改与[7]中要求一致）和场景二作为基准数据集，具体基础数据集的特点，请参加本文前面1.2章节。在查询性能评估之前，对于 TimescaleDB, 我们采用[7]中推荐配置，设置为 8 个 Chunk ，以确保其充分发挥查询性能。对于 lInfluxDB，我们开启 InfluxDB 的 TSI (time series index)。在整个查询对比中，TDengine 数据库的虚拟节点数量（vnodes）保持为默认的 6 个（scale=100 时配置 1 个），其他的数据库参数配置为默认值。

4.1 4,000 devices × 10 metrics 查询性能对比

由于大部分类型单次查询响应时间过长，为了更加准确地测量每个查询场景的较为稳定的响应时间，我们依据卡车数量规模，将单个查询运行次数分别提升到 2,000 次（场景一）和 500 次（场景二），然后使用 TSBS 自动统计并输出结果，最后结果是多次查询的算数平均值，使用并发客户端 Workers 数量为 4。首先我们提供场景二（4,000 设备）的查询性能对比结果。

**表7. 4,000 devices × 10 metrics（场景二）查询性能对比表（单位：ms）**
查询类型	TDengine	InfluxDB	InfluxDB/TDengine	TimescaleDB	TimescaleDB/TDengine
last-loc	11.52	562.86	4885.94%	11.77	102.17%
low-fuel	30.72	635	2067.06%	416.75	1356.61%
high-load	10.74	861.13	8017.97%	11.62	108.19%
stationary-trucks	23.9	3156.65	13207.74%	195.46	817.82%
long-driving-sessions	59.44	374.98	630.85%	2938.54	4943.71%
long-daily-sessions	218.97	1439.19	657.25%	19080.95	8713.96%
avg-vs-projected-fuel-consumption	3111.18	40842.05	1312.75%	37127.24	1193.35%
avg-daily-driving-duration	4402.15	43588.02	990.15%	73781.97	1676.04%
avg-daily-driving-session	4034.09	84494.79	2094.52%	80765.04	2002.06%
avg-load	1295.97	552493.78	42631.68%	30452.26	2349.77%
daily-activity	2314.64	15248.66	658.79%	79242.14	3423.52%
breakdown-frequency	5416.3	288804.93	5332.14%	70205.29	1296.19%

下面我们对每个查询结果做一定的分析说明：

对于分组选择的查询中，TDengine 采用一张表一个设备（卡车）的设计方式，并采用缓存模式的 last_row 函数来查询最新的数据，使得TDengine 的查询响应时间上均优于 InfluxDB 和 TimescaleDB。

在复杂分组聚合的查询中，我们看到 TDengine 查询性能相比于 TimescaleDB 和 InfluxDB 有非常大的优势；而在时间窗口聚合的查询过程中，TimescaleDB 针对规模较大的数据集其查询性能不佳，long-driving-sessions 和 long-daily-sessions 均表现很差。TDengine 在 stationary-trucks 查询性能是 InfluxDB 的 132倍，是 TimescaleDB 的 8 倍。在 long-daily-sessions 中是TimescaleDB 的 87 倍，是 InfluxDB 的 6.5 倍。

在复杂的混合查询中， TDengine 展现出巨大的性能优势，其查询响应时间来度量，其中 avg-load 和 breakdown-frequency 的查询性能是 InfluxDB 的 426 倍和 53 倍；对比 TimescaleDB，在 daily-activity 查询中，TDengine 是其 34 倍，在 avg-load 查询中，TDengine 是其 23 倍。

4.2 资源开销对比

由于部分查询持续时间特别短，并不能完整地看到查询过程中服务器的 IO/CPU/网络情况。我们针对场景二，以 daily-activity 查询为例，执行 50 次查询，记录整个过程中三个软件系统在查询执行的整个过程中服务器 CPU、内存、网络的开销进行对比。

服务器 CPU 开销

如图 9 可以看到，三个系统在整个查询过程中 CPU 的使用均较为平稳。TDengine 在查询过程中整体 CPU 占用约 70%， TimescaleDB 在查询过程中瞬时 CPU 最低，约 22%。InfluxDB 的稳定的 CPU 占用的最大，约 98 %（有较多的瞬时100%）。整体 CPU 开销上来看，虽然 TimescaleDB 瞬时 CPU 开销最低，但是其完成查询持续时间最长，所以整体 CPU 资源消耗最多。InfluxDB 基本顶格100%使用全部 cpu，持续时间是TDengine的三倍，开销次之。 TDengine 完成全部查询的时间仅是 TimescaleDB 的 1/30，整体 CPU 开销最低。

服务器内存状况

如图 10 所示，在整个查询过程中，TDengine 内存维持了一个相对平稳的状态，平均使用约为 12G。TimescaleDB 和InfluxDB 内存占用在整个查询过程中保持平稳，平均约为 10G；其中 TimescaleDB 对 buffer 和 cache 使用比较多。

服务器网络带宽

图 11 展示了查询过程中服务器端上行和下行的网络带宽情况，负载状况基本上和 CPU 状况相似。TDengine 网络带宽开销最高，因为在最短的时间内就完成了全部查询，需要将查询结果返回给客户端。InfluxDB 和 TimescaleDB 网络带宽大致相同。

4.3 100 devices × 10 metrics 查询性能对比

对于场景一(100 devices x 10 metrics)，TSBS 的 15 个查询对比结果如下：

**表 9. InfluxDB 与 Timescale 相对于 TDengine 查询响应时间比率 (单位：ms)**
查询类型	TDengine	InfluxDB	InfluxDB/TDengine	TimescaleDB	TimescaleDB/TDengine
last-loc	1.03	14.94	1450.49%	1.35	131.07%
low-fuel	4.61	17.45	378.52%	6.74	146.20%
high-load	1.03	18.33	1779.61%	1.31	127.18%
stationary-trucks	3.59	69.1	1924.79%	4.02	111.98%
long-driving-sessions	5.4	13	240.74%	61.87	1145.74%
long-daily-sessions	13.88	42.91	309.15%	228.38	1645.39%
avg-vs-projected-fuel-consumption	267.03	1033.72	387.12%	830.79	311.12%
avg-daily-driving-duration	278.62	942.47	338.26%	1049.07	376.52%
avg-daily-driving-session	166.49	1707.27	1025.45%	1066.69	640.69%
avg-load	102.31	15956.73	15596.45%	487.39	476.39%
daily-activity	146.5	510.3	348.33%	1245.05	849.86%
breakdown-frequency	413.82	6953.83	1680.40%	955.2	230.82%

如表 9 所示，在更小规模的数据集（场景一）上的查询对比可以看到，整体上 TDengine 同样展现出极好的性能，在全部的查询语句中全面优于 TimescaleDB 和 InfluxDB，部分查询性能超过 TimescaleDB 16 倍，超过 InfluxDB 155 倍。

五、总结

本次基于 TSBS 性能基准框架的对比测评，拓展了 IoT 场景。得益于 TDengine 契合时序数据特点的架构设计，TDengine 相对于 TimescaleDB 和 InfluxDB，不论是数据写入的性能，写入过程中对于资源的消耗，查询的响应延迟还是查询过程中资源的开销，均全面优于 TimescaleDB 和 InfluxDB。加之上次的 CPU 场景[10]，在流行的工业物联网领域，TDengine 依然能作为企业的银弹，来发挥时序数据库的最大潜能。