不久前，基于 TSBS，咱们公布了 TDengine 3.0 测试报告系列第一期——《DevOps 场景下 TDengine 3.0 比照测试报告》，报告验证了 TDengine 基于时序数据场景所设计的独特架构，在 DevOps 场景下带来的性能劣势以及老本管制程度。本期咱们持续探寻在 IoT 场景下，TDengine 比照 TimescaleDB、InfluxDB 在写入和查问上的性能体现——《IoT 场景下 TDengine 3.0 性能比照剖析报告来啦！》，给有时序数据库（Time Series Database）选型需要的开发者做参考。
本期报告显示，在全副的五个场景中，TDengine 写入性能均优于 TimescaleDB 和 InfluxDB。写入性能最大达到 TimescaleDB 的 3.3 倍，InfluxDB 的 16.2 倍；此外，TDengine 在写入过程中耗费了起码计算（CPU）资源和磁盘 IO 开销。在查问方面，对于大多数查问类型，TDengine 的性能均优于 InfluxDB 和 TimescaleDB，在简单的混合查问中 TDengine 展现出微小的劣势——其中 avg-load 和 breakdown-frequency 的查问性能是 InfluxDB 的 426 倍 和 53 倍；daily-activity 和 avg-load 的查问性能是 TimescaleDB 的 34 倍和 23 倍。
为了便于大家对报告后果进行验证，本篇文章将会对测试数据及环境搭建等环节进行一一论述，不便有须要的开发者取用复制。此外，本测试报告中的数据在筹备好物理环境后，能够由脚本一键执行生成，测试步骤在本文中也有波及。
一、测试背景
1、测试场景
介绍在本期测试报告中，咱们应用了 TSBS 的 IoT 场景作为根底数据集，在 TSBS 框架下模仿虚构货运公司车队中一组卡车的时序数据，针对每个卡车的诊断数据（diagnostics）记录蕴含 3 个测量值和 1 个（纳秒分辨率）工夫戳、8 个标签值；卡车的指标信息（readings）记录蕴含 7 个测量值和 1 个（纳秒分辨率）工夫戳，8 个标签值。数据模式（schema）见下图，每 10 秒对生成的数据进行一条记录。因为 IoT 场景引入了环境因素，所以每个卡车存在无序和缺失的工夫序列数据。
样例数据
在整个基准性能评估中，波及以下五个场景，每个场景的具体数据规模和特点见下表，因为存在数据缺失，所以单个卡车数据记录取记录均值：
从上表能够看到，五个场景的区别次要在于数据集所蕴含的单个卡车记录数量以及卡车总数的差别，数据工夫距离均维持在 10 秒。整体上看，五个场景的数据规模都不大，数据规模最大的是场景五，数据规模最小的是场景四。在场景四和场景五中，因为卡车数量绝对较多，所以数据集仅笼罩了 3 分钟的时间跨度。
2、数据建模
在 TSBS 框架中，TimescaleDB 和 InfluxDB 会主动创立相应的数据模型并生成对应格局的数据。本文不再赘述其具体的数据建模形式，只介绍 TDengine 的数据建模策略。
TDengine 一个重要的翻新是其独特的数据模型——为每个设施创立独立的数据表（子表），并通过超级表（Super Table）在逻辑上和语义上对同一采集类型的设施进行对立治理。针对 IoT 场景的数据内容，咱们为每个卡车创立了两张表（后文中设施和卡车同义），用来存储诊断信息和指标信息的时序数据。在上述数据记录中，truck name 能够作为每个卡车的标识 ID，因为有两张超级表，因而在 TDengine 中应用 truck name 拼接 d（r）作为子表的名称。咱们应用如下的语句创立名为 diagnostics 和 readings 的超级表，别离蕴含 3、7 个测量值和 8 个标签。
而后，咱们应用如下语句创立名为 r_truck_1 和 d_truck_1 的子表：
由此可知，对于 100 个设施（CPU）的场景一，咱们将会建设 100 个子表；对于 4000 个设施的场景二，零碎中将会建设 4000 个子表用以存储各自对应的数据。在 TSBS 框架生成的数据中，咱们发现存在标签信息 truck 为 null 的数据内容，为此建设了 d_truck_null(r_truck_null) 的表，用以存储所有未能标识 truck 的数据。
3、软件版本和配置
本报告比拟 TDengine、InfluxDB 与 TimeScaleDB 三种类型的数据库，上面对应用的版本和配置做出阐明。
01 TDengine
咱们间接采纳 TDengine 3.0，从 GitHub 克隆 TDengine 代码编译版本作为性能比照的版本。gitinfo: 1bea5a53c27e18d19688f4d38596413272484900 在服务器上编译装置运行：
在 TDengine 的配置文件中设置了六个波及查问的配置参数：
第一个参数 numOfVnodeFetchThreads 作用是设置 Vnode（virtual node）的 Fetch 线程数量为 4 个；第二个参数 queryRspPolicy 用于关上 query response 疾速返回机制；第三个参数 compressMsgSize 让 TDengine 在传输层上大于 128000 bytes 的音讯主动进行压缩；第四个参数的作用是在 CPU 反对的状况下启用内置的 FMA/AVX/AVX2 硬件加速；第五个参数用于开启 tag 列的过滤缓存；第六个参数用于设置工作队列的线程数量为 24。
因为 IoT 场景下表数目是卡车规模数的二倍，所以 TDengine 建库默认创立 12 个 vnodes，即创立的表会依照表名随机调配到 12 个虚构节点中，将 LRU 缓存设置为 last_row 缓存模式。对于场景一和场景二，stt_trigger 设置为 1，此时 TDengine 会筹备一个 Sorted Time-series Table (STT) 文件，用于包容单表写入量小于 minimum rows 时的数据，当 STT 文件中无奈包容新数据时，零碎会将 STT 中的数据进行整顿，再写入到数据文件中。
在本次报告中，场景三配置 stt_trigger 为 8，场景四和场景五 stt_trigger 设置为 16，即容许最多生成 16 个 STT 文件。针对低频表多的场景，须要适度减少 STT 的值，以此来取得更好的写入性能。
02 TimescaleDB
为确保后果具备可比性，咱们选用 TimescaleDB version 2.10.1。为取得较好的性能，TimescaleDB 须要针对不同的场景设置不同的 Chunk 参数，不同场景下参数的设置如下表所示：
对于上述参数的设置，咱们充沛参考了 [TimescaleDB vs. InfluxDB] 比照报告中举荐的配置参数设置，以确保可能最大化写入性能指标。
TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-ti…
03 InfluxDB
针对 InfluxDB，本报告选用的是 version 1.8.10。这里没有应用 InfluxDB 最新的 2.x 版本是因为 TSBS 没有对其进行适配，所选用的 1.8.10 版本是 InfluxDB 可能运行 TSBS 框架的最新版本。在配置上，依然采纳 [TimescaleDB vs. InfluxDB] 比照报告中举荐的形式对其进行配置，将缓冲区配置为 80GB，以便 1000W 设施写入时可能顺利进行，同时开启 Time Series Index（TSI）。配置零碎在零碎插入数据实现 30s 后开始进行数据压缩：
二、测试步骤
1、硬件筹备
为与 [TimescaleDB vs. InfluxDB] 比照报告的环境高度靠近，咱们应用亚马逊 AWS 的 EC2 提供的 r4.8xlarge 类型实例作为根底运行平台，包含 1 台服务器、1 台客户端共两个节点形成的环境。客户端与服务器硬件配置完全相同，客户端与服务器应用 10 Gbps 网络连接。配置简表如下：
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 拜访免密，以便脚本可不裸露明码，可参考免密配置文档：https://blog.csdn.net/qq_38154295/article/details/121582534。
保障 client 和 server 之间所有端口凋谢。
3、获取测试脚本
为便于反复测试，暗藏繁琐的下载、装置、配置、启动、汇总后果等细节，整个 TSBS 的测试过程被封装成一个测试脚本。重复本测试报告，须要先下载该测试脚本，脚本暂反对 ubuntu20.04 的零碎。以下操作要求具备 root 权限。
在客户端机器，进入测试目录拉取代码，默认进入 /usr/local/src/ 目录：
须要批改配置文件 test.ini 中服务端和客户端的 IP 地址（这里配置 AWS 的私网地址即可）和 hostname，如果服务器未配置免密，还须要配置服务器端的 root 明码。因为本次测试在 IoT 场景下，故批改 caseType 为 iot。
4、一键执行
比照测试执行以下命令：
测试脚本将主动装置 TDengine、InfluxDB、TimescaleDB 等软件，并主动运行各种比照测试项。在目前的硬件配置下，整个测试跑完须要大概三天的工夫。测试完结后，将主动生成 CSV 格局的比照测试报告，并存放在客户端的 /data2 目录，对应 load 和 query 前缀的文件夹下。
三、结语
浏览结束，你肯定更加深刻地理解了 TDengine 的数据建模、三大数据库测试版本和配置，以及如何使用测试脚本进行一键复现。如果有小伙伴想要验证三大数据库在 IoT 场景下的测试后果，欢送依照上述步骤进行操作，测验测试后果，有任何问题都欢送大家和咱们及时沟通。当初你也增加小 T vx:tdengine1，申请加入 TDengine 用户交换群，和更多气味相投的开发者一起聊技术、聊实战。