IoT 场景下 TDengine 与老牌时序数据库怎么选？看看这份TSBS报告

上周一，TDengine 正式发布了 IoT 场景下基于 TSBS 的时序数据库（Time Series Database，TSDB）性能基准测试报告。该报告模拟虚拟货运公司车队中一组卡车的时序数据，预设了五种卡车规模场景，在相同的 AWS 云环境下运行了 TDengine 3.0、TimescaleDB 2.10.1 和 InfluxDB 1.8.10，从四大维度进行对比测试并输出结果。

为了便于大家更好地阅读和理解，基于本报告内容，我们将从写入、查询及测试过程如何复现等几大维度输出系列文章。本篇文章将为大家解读三大时序数据库在写入性能上的差异点。在上一篇文章《IoT 场景 TSBS 测试报告结果一键检验，测试脚本是______》中，我们对测试场景和基本配置已经进行了详细介绍，本篇文章便不再赘述，还没有了解过的小伙伴可以点击上文链接查看。

一、不同场景下写入性能对比 ::: hljs-center

不同场景下写入性能的对比（metrics/sec. 数值越大越好）

:::

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

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

TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ 在三个系统数据完全落盘后，我们针对三个系统在不同场景下的磁盘空间占用进行了比较。 ::: hljs-center

磁盘空间占用（数值越小越优）

:::

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

测试过程中还有个小插曲，下表反应了 TimescaleDB 的压缩比率，可以看到，TimescaleDB 在小数据规模的情况下，压缩比正常，但是在数据规模较大的场景四和场景五中，压缩以后的磁盘空间占用比例反而增大了 3.4 倍左右，疑似 bug。 二、写入过程资源消耗对比 仅凭数据写入速度，并不能全面地反映出三个系统在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics（场景四）为数据模板，检查数据写入过程中的服务器和客户端（包括客户端与服务器）的整体负载状况，并以此来对比三个系统在写入过程中服务器/客户端节点的资源占用情况。这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。

1、服务端 CPU 开销

下图展示了在场景四写入过程中服务器端 CPU 负载状况。可以看到，三个系统在返回给客户端写入完成消息以后，都还继续使用服务器的资源进行相应的处理工作，这点上，TimescaleDB 尤为明显。TimescaleDB 在 7x 秒时即反馈客户端写入完成，但是其服务器端仍然调用 CPU 资源进行了数据压缩和整理工作，当然整个工作带来的 CPU 负载相对而言并不高，只有其峰值 CPU 开销的一半左右，但是其持续时间相当长，接近净写入时间的 4 倍。

::: hljs-center

写入过程中服务器 CPU 开销

:::

InfluxDB 则使用了相当多的 CPU 资源，瞬时峰值甚至使用了全部的 CPU 资源，其写入负载较高，并且持续时间比 TimescaleDB 更长，当然更远长于 TDengine。三个系统对比，TDengine 对服务器的 CPU 需求最小，峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见，TDengine 独特的数据模型不仅体现在时序数据写入性能上，同样也展现在整体的资源开销上。

2、磁盘 I/O 对比

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

写入过程中服务器 IO 开销

:::

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

3、客户端 CPU 开销 ::: hljs-center

写入过程中客户端 CPU 开销

:::

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

三、性能基准评估扩展部分 为了更全面地评估 TDengine 在默认参数下的写入性能，我们在下面的性能评估中对可能会影响写入性能的多个参数进行了调整，以便开展更全面的评估工作。

1、虚拟节点（vnodes）数量

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

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

2、设备记录数量

TDengine 创新设计了“一个设备一张表”的数据模型，需要在数据写入时创建表，建表操作对每个设备只执行一次，但这也使得 TDengine 在数据写入的准备阶段耗时较多。当单个表中数据量增加以后，数据准备（建表）的开销被分摊到更多的数据写入整体开销中。

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

::: hljs-center

设备记录数增加时候数据写入性能对比（数值越大越好）

::: 我们调整 vnodes 数量配置，同时测试两个不同 vnodes 数量情况下的写入性能指标。如上图所示，随着表中记录数的增加，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 在单设备记录增加过程中，写入性能有衰减，但衰减趋势非常缓慢。 四、写在最后 由此可见，在全部的场景中，TDengine 的写入性能超过 TimescaleDB 和 InfluxDB。在整个写入过程中，TDengine 除了提供更高的写入能力，在服务器的 CPU 和 IO 上，也均远优于 TimescaleDB 和 InfluxDB——不管是服务器的磁盘 IO 开销抑或客户端的开销，TDengine 均远小于 TimescaleDB 和 InfluxDB。

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

在《中移物联车联网项目，在 TDengine 3.0 的应用》一文中，TDengine 3.0 高效的写入性能也在企业实践中得到了验证——从 2.0 到 3.0，面对 1.2-1.3w 行/s 的业务写入峰值，以及 20w 行/s 的数据迁移巨大写入量，TDengine 都可以轻松应对，磁盘占用量约占 MySQL 的 1/7。如果你也面临着数据处理难题或想要进行数据架构升级，欢迎添加小T vx：tdengine1，加入 TDengine 用户交流群，和更多志同道合的开发者一起攻克难关。