标签：场景 测试报告 TDengine IoT 写入 InfluxDB 查询 CPU
为了验证 TDengine 3.0 在 IoT 场景下的性能，我们针对第三方基准性能测试平台 TSBS（Time Series Benchmark Suite） 中的 IoT 场景，预设了五种规模的卡车车队基础数据集，在相同的 AWS 云环境下对 TDengine 3.0 和 InfluxDB 1.8（该版本是 InfluxDB 能够运行 TSBS 框架的最新版本）进行了对比分析。在本篇文章中，我们将从写入、存储、查询、及资源开销等几大维度对两大数据库的测试结果进行汇总分析，给到大家参考。
为了将 InfluxDB 的性能发挥到极致，我们采用下方 [TimescaleDB vs. InfluxDB] 对比报告中推荐的方式配置 InfluxDB，将缓冲区配置为 80GB，以便 1000W 设备写入时能够顺利进行，同时开启 Time Series Index（TSI）。配置系统在系统插入数据完成 30s 后开始数据压缩。
TimescaleDB vs. InfluxDB 测试报告: https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/
关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《IoT 场景 TSBS 测试报告结果一键检验，测试脚本是______》一文，本文便不再赘述。
写入性能
总体而言，在预设的五种规模的卡车车队场景中，TDengine 写入性能均优于 InfluxDB。相比 InfluxDB，TDengine 写入速度最领先的场景达到其 16.2 倍（场景五），最小为 1.82 倍（场景三)。此外，TDengine 在写入过程中消耗了最少 CPU 资源和磁盘 IO 开销。下面看一下具体分析：
不同场景下写入性能对比
不同场景下写入性能的对比（metrics/sec. 数值越大越好）
可以看到在全部五个场景中，
TDengine 的写入性能全面超越 InfluxDB。相对于 InfluxDB，TDengine在场景五中写入性能是 InfluxDB 的 16 倍，在差距最小的场景三中也有 1.8 倍。
写入过程资源消耗对比
数据写入速度并不能够全面的反映三个系统在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics（场景四）为例，检查数据写入过程中的服务器和客户端（包括客户端与服务器）的整体负载状况，并以此来对比 TDengine 和 InfluxDB 在写入过程中服务器/客户端节点的资源占用情况，这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。
下图展示了在场景四写入过程之中服务器端 CPU 负载状况。可以看到，TDengine 和 InfluxDB 在返回给客户端写入完成消息以后，都还继续使用服务器的资源进行相应的处理工作。其中，InfluxDB 使用了相当多的 CPU 资源，瞬时峰值甚至使用了全部的 CPU 资源，其写入负载较高，并且其持续时间远长于 TDengine。两个系统对比，TDengine 对服务器的 CPU 需求最小，峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见，TDengine 独特的数据模型对于时序数据写入不仅体现在性能上，同样也体现在了整体的资源开销上。
写入过程中服务器CPU开销
下图展示了 1,000,000 devices × 10 metrics（场景四）数据写入过程中服务器端磁盘写入状态。可以看到，结合着服务器端 CPU 开销表现，其 IO 动作与 CPU 呈现同步的活跃状态。
写入过程中服务器 IO 开销
在写入相同规模的数据情况下，TDengine 在写入过程中对于磁盘写入能力的占用远小于 InfluxDB，写入过程只占用了部分磁盘写入能力（125MiB/Sec. 3000IOPS）。从上图能看到，对于两大数据库，数据写入过程中磁盘的 IO 瓶颈是确实存在的。但 InfluxDB 长时间消耗完全部的磁盘写入能力，远远超过了 TDengine 对磁盘写入能力的需求。
写入过程中客户端 CPU 开销
从上图可以看到，客户端上 TDengine 对 CPU 的需求大于 InfluxDB。整体来说，在整个写入过程中，InfluxDB 客户端负载计算资源占用较低，对客户端压力小，这是因为其写入的压力基本上完全集中在服务端，但这种模式很容易导致服务端成为瓶颈。TDengine 在客户端的开销最大，峰值瞬间达到了 70%，然后快速回落。
但综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在系统整体 CPU 开销上TDengine 仍然具有优势。
查询性能
在查询性能评估部分，我们使用场景一（只包含 4 天数据，本修改与 [TimescaleDB vs. InfluxDB] 中要求一致）和场景二作为基准数据集。在整个查询对比中，TDengine 数据库的虚拟节点数量（vnodes）保持为默认的 6 个（scale=100 时配置 1 个），其他的数据库参数配置为默认值。
总体来说，查询方面，在场景一（只包含 4 天的数据）与场景二的 15 个不同类型的查询中，TDengine 的查询平均响应时间全面优于 InfluxDB，而且在复杂查询上优势更为明显，同时具有最小的计算资源开销。相比 InfluxDB，场景一中 TDengine 查询性能是其 2.4 到 155.9 倍，场景二中 TDengine 查询性能是其 6.3 到 426.3 倍。
4,000 devices × 10 metrics 查询性能对比
由于大部分类型单次查询响应时间过长，为了更加准确地测量每个查询场景的较为稳定的响应时间，我们依据卡车数量规模，将单个查询运行次数分别提升到 2,000 次（场景一）和 500 次（场景二），然后使用 TSBS 自动统计并输出结果，最后结果是多次查询的算数平均值，使用并发客户端 Workers 数量为 4。首先我们提供场景二 （4,000 设备）的查询性能对比结果。
| 查询类型 |
TDengine |
InfluxDB |
InfluxDB/TDengine |
| last-loc |
11.52 |
562.86 |
4885.94% |
| low-fuel |
30.72 |
635 |
2067.06% |
| high-load |
10.74 |
861.13 |
8017.97% |
| stationary-trucks |
23.9 |
3156.65 |
13207.74% |
| long-driving-sessions |
59.44 |
374.98 |
630.85% |
| long-daily-sessions |
218.97 |
1439.19 |
657.25% |
| avg-vs-projected-fuel-consumption |
3111.18 |
40842.05 |
1312.75% |
| avg-daily-driving-duration |
4402.15 |
43588.02 |
990.15% |
| avg-daily-driving-session |
4034.09 |
84494.79 |
2094.52% |
| avg-load |
1295.97 |
552493.78 |
42631.68% |
| daily-activity |
2314.64 |
15248.66 |
658.79% |
| breakdown-frequency |
5416.3 |
288804.93 |
5332.14% |
下面我们对每个查询结果做一定的分析说明：
4000 devices 查询响应时间 (数值越小越好)
在分组选择的查询中，TDengine 采用一张表一个设备（卡车）的设计方式，并采用缓存模式的 last_row 函数来查询最新的数据，在查询响应时间上全面优于 InfluxDB。
4000 devices Aggregates 查询响应时间 (数值越小越好)
在复杂分组聚合的查询中，我们看到 TDengine 查询性能相比于 InfluxDB 有非常大的优势。其中，TDengine 在 stationary-trucks 查询性能是 InfluxDB 的 132倍，在 long-daily-sessions 中是 InfluxDB 的 6.5 倍。
4000 devices Double rollups 查询响应时间 (数值越小越好)
4000 devices 查询响应时间 (数值越小越好)
在复杂的混合查询中， TDengine 同样展现出巨大的性能优势，从查询响应时间来看，其中 avg-load 和 breakdown-frequency 的查询性能是 InfluxDB 的 426 倍和 53 倍。
资源开销对比
由于部分查询持续时间特别短，并不能完整地看到查询过程中服务器的 IO/CPU/网络情况，为此我们针对场景二，以 daily-activity 查询为例，执行 50 次查询，记录整个过程中三个软件系统在查询执行中服务器 CPU、内存、网络的开销并进行对比。
查询过程中服务器 CPU 开销
从上图可以看到，两个系统在整个查询过程中 CPU 的使用均较为平稳，TDengine 在查询过程中整体 CPU 占用约 70%，InfluxDB 稳定的 CPU 占用最大，约 98 %（有较多的瞬时 100%）。从整体 CPU 开销上来看，InfluxDB 基本顶格 100% 使用全部 CPU，持续时间是 TDengine 的三倍，开销次之；TDengine 完成全部查询的时间较短，整体 CPU 开销最低。
查询过程中服务器内存情况
如上图所示，在整个查询过程中，TDengine 内存维持在一个相对平稳的状态，平均使用约为 12GB；InfluxDB 内存占用在整个查询过程中保持平稳，平均约为 10GB。
查询过程中网络占用情况
上图展示了两大系统在查询过程中服务器端上行和下行的网络带宽情况，负载状况基本上和 CPU 状况相似。其中 TDengine 网络带宽开销最高，因为在最短的时间内就完成了全部查询，需要将查询结果返回给客户端。
100 devices × 10 metrics 查询性能对比
对于场景一(100 devices x 10 metrics)，TSBS 的 15 个查询对比结果如下：
| 查询类型 |
TDengine |
InfluxDB |
InfluxDB/TDengine |
| last-loc |
1.03 |
14.94 |
1450.49% |
| low-fuel |
4.61 |
17.45 |
378.52% |
| high-load |
1.03 |
18.33 |
1779.61% |
| stationary-trucks |
3.59 |
69.1 |
1924.79% |
| long-driving-sessions |
5.4 |
13 |
240.74% |
| long-daily-sessions |
13.88 |
42.91 |
309.15% |
| avg-vs-projected-fuel-consumption |
267.03 |
1033.72 |
387.12% |
| avg-daily-driving-duration |
278.62 |
942.47 |
338.26% |
| avg-daily-driving-session |
166.49 |
1707.27 |
1025.45% |
| avg-load |
102.31 |
15956.73 |
15596.45% |
| daily-activity |
146.5 |
510.3 |
348.33% |
| breakdown-frequency |
413.82 |
6953.83 |
1680.40% |
如上表所示，从更小规模的数据集（场景一）上的查询对比可以看到，整体上 TDengine 同样展现出了极好的性能，在全部的查询语句中全面优于 InfluxDB，部分查询性能甚至超过 InfluxDB 155 倍。
磁盘空间占用
在两大系统数据完全落盘以后，我们对 TDengine 和 InfluxDB 在不同场景下的磁盘空间占用也进行了比较。
磁盘空间占用（数值越小越优）
从上图可以看到，在前面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 比较接近；但是在场景四/五两个场景中，InfluxDB 落盘后文件占用的磁盘空间是 TDengine 的 2 倍以上。
写在最后
基于本次测试报告，我们可以得出结论，在全部的 IoT 数据场景中，TDengine 写入性能、查询性能均全面超过 InfluxDB。在整个写入过程中，TDengine 在提供更高写入和查询能力的前提下，不论是服务器的 CPU 还是 IO，均优于 InfluxDB。即使加上客户端的开销统计，TDengine 在写入开销上也在 InfluxDB 之下。
从实践角度出发，这个报告结果也很好地说明了为什么有很多企业和开发者在时序数据库（Time Series Database） InfluxDB 和 TDengine 的选型调研中选择了 TDengine，在《从 InfluxDB 到 TDengine，我们为什么会做出这个选择》这篇文章中，便阐述了作者在进行项目选型调研过程时的具体思考。
为了方便大家验证测试结果，本测试报告支持运行测试脚本一键复现，欢迎大家在评论区互动交流。同时，你也可以添加 小T vx：tdengine1，加入 TDengine 用户交流群，和更多志同道合的开发者一起探讨数据处理难题。
标签：场景,
测试报告,
TDengine,
IoT,
写入,
InfluxDB,
查询,
CPU
From： https://www.cnblogs.com/taosdata/p/17571088.html