基于第三方基准性能测试平台 TSBS（Time Series Benchmark Suite） 标准数据集，TDengine 团队在 TSBS 的 IoT 场景中，预设了五种规模的卡车车队基础数据集，在相同的 AWS 云环境下对时序数据库（Time Series Database） TDengine 3.0 和 TimescaleDB 2.10.1 进行了对比分析。本文将会从写入、存储、查询及资源开销等几大维度为大家汇总分析测试结果。
为了让 TimescaleDB 获得较好的性能，确保结果具有可比性，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 |
上述参数的设置，充分参考了下方 TimescaleDB vs. InfluxDB 对比报告中推荐的配置参数设置，以确保写入性能指标的最优化。
TimescaleDB vs. InfluxDB 测试报告：TimescaleDB vs. InfluxDB: Purpose-built for time-series data
关于系统的配置详情、如何一键复现测试结果及详细的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证 TDengine 3.0 IoT 场景下 TSBS 测试报告》一文，本文便不再赘述。
写入性能
总体而言，在预设的五种规模的卡车车队场景中，TDengine 写入性能均优于 TimescaleDB。相比 TimescaleDB，TDengine 写入速度最领先的场景是其 3.3 倍（场景一），最少也是 1.04 倍（场景四），而且对于场景四，如果将每个采集点的记录条数由 18 条增加到 576 条，且 vgroups=24 时，TDengine 写入速度就达到了 TimescaleDB 的 7 倍。此外，TDengine 在写入过程中消耗的 CPU 资源和磁盘 IO 开销也是最低的。
不同场景下写入性能对比
不同场景下写入性能的对比（metrics/sec. 数值越大越好）
从上图中我们可以看到，在全部五个场景中，TDengine 的写入性能全面超越 TimescaleDB。在场景二中 TDengine 写入性能最大达到 TimescaleDB 的 3.3 倍，在差距最小的场景五中，也达到了 TimescaleDB 的 1.04 倍。
写入过程资源消耗对比
仅凭数据写入速度，并不能全面地反映出三个系统在不同场景下数据写入的整体表现。为此我们以 1,000,000 devices × 10 metrics（场景四）为数据模板，检查数据写入过程中的服务器和客户端（包括客户端与服务器）的整体负载状况，并以此来对比两大系统在写入过程中服务器/客户端节点的资源占用情况。这里的资源占用主要包括服务器端的 CPU 开销/磁盘 IO 开销和客户端 CPU 开销。
服务端 CPU 开销
下图展示了在场景四写入过程中服务器端 CPU 负载状况。可以看到，两大系统在返回给客户端写入完成消息以后，都还继续使用服务器的资源进行相应的处理工作。TimescaleDB 在 7x 秒时即反馈客户端写入完成，但是其服务器端仍然调用 CPU 资源进行了数据压缩和整理工作，当然整个工作带来的 CPU 负载相对而言并不高，只有其峰值 CPU 开销的一半左右，但是其持续时间相当长，接近净写入时间的 4 倍。
写入过程中服务器 CPU 开销
两个系统对比，TDengine 对服务器的 CPU 需求最小，峰值也仅使用了 17% 左右的服务器 CPU 资源。由此可见，TDengine 独特的数据模型不仅体现在时序数据写入性能上，同样也展现在整体的资源开销上。
磁盘 I/O 对比
下图展示了 1,000,000 devices × 10 metrics （场景四）数据写入过程中服务器端磁盘写入状态。可以看到，结合着服务器端 CPU 开销表现，IO 动作与 CPU 呈现同步的活跃状态。
写入过程中服务器 IO 开销
在写入相同规模数据集情况下，TDengine 在写入过程中对于磁盘写入能力的占用远小于 TimescaleDB，只占用了部分磁盘写入能力（125MiB/Sec. 3000IOPS）。从上图能看到，数据写入过程中磁盘的 IO 瓶颈是确实存在的，TimescaleDB 在写入过程中对磁盘写入能力的需求远超 TDengine。
客户端 CPU 开销
写入过程中客户端 CPU 开销
从上图可以看到，客户端上 TDengine 对 CPU 的需求大于 TimescaleDB。TimescaleDB 对于客户端压力更大，CPU 峰值达到 20% 左右；TDengine 在客户端的开销最大，峰值瞬间达到了 70%，然后快速回落，其在客户端的开销相比于 TimescaleDB 多了 1 倍。但综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在系统整体 CPU 开销上 TDengine 仍然具有优势。
查询性能
在场景一（只包含 4 天数据）与场景二的 15 个不同类型的查询中，TDengine 的查询平均响应时间全面优于 TimescaleDB，而且在复杂查询上优势更为明显，同时具有最小的计算资源开销。相比 TimeScaleDB，场景一中 TDengine 的查询性能是其 1.1 到 16.4 倍，场景二中 TDengine 的查询性能是其 1.02 倍到 87 倍。
在查询性能评估部分，我们使用场景一和场景二作为基准数据集。在查询性能评估之前，对于 TimescaleDB，我们采用上文出现的 [TimescaleDB vs. InfluxDB] 对比报告中推荐配置，设置为 8 个 Chunk ，以确保其充分发挥查询性能。在整个查询对比中，TDengine 数据库的虚拟节点数量（vnodes）保持为默认的 6 个（scale=100 时配置 1 个），其他的数据库参数配置为默认值。
4,000 devices × 10 metrics 查询性能对比
由于大部分类型单次查询响应时间过长，为了更加准确地测量每个查询场景下较为稳定的响应时间，我们依据卡车数量规模，将单个查询运行次数分别提升到 2,000 次（场景一）和 500 次（场景二），然后使用 TSBS 自动统计并输出结果，最后结果是多次查询的算数平均值，使用并发客户端 Workers 数量为 4。下表是场景二 （4,000 设备）的查询性能对比结果。
| 查询类型 | TDengine | TimescaleDB | TimescaleDB/TDengine |
| last-loc | 11.52 | 11.77 | 102.17% |
| low-fuel | 30.72 | 416.75 | 1356.61% |
| high-load | 10.74 | 11.62 | 108.19% |
| stationary-trucks | 23.9 | 195.46 | 817.82% |
| long-driving-sessions | 59.44 | 2938.54 | 4943.71% |
| long-daily-sessions | 218.97 | 19080.95 | 8713.96% |
| avg-vs-projected-fuel-consumption | 3111.18 | 37127.24 | 1193.35% |
| avg-daily-driving-duration | 4402.15 | 73781.97 | 1676.04% |
| avg-daily-driving-session | 4034.09 | 80765.04 | 2002.06% |
| avg-load | 1295.97 | 30452.26 | 2349.77% |
| daily-activity | 2314.64 | 79242.14 | 3423.52% |
| breakdown-frequency | 5416.3 | 70205.29 | 1296.19% |
下面我们对每个查询结果做一定的分析说明：
注：查询一=daily-activity；查询二=avg-daily-driving-session；查询三=avg-daily-driving-duration；查询四=avg-vs-projected-fuel-consumption
4000 devices 查询响应时间 (数值越小越好)
在分组选择的查询中，TDengine 采用一张表一个设备（卡车）的设计方式，并采用缓存模式的 last_row 函数来查询最新的数据。从结果上看，TDengine 的查询响应时间优于 TimescaleDB。
4000 devices Aggregates 查询响应时间 (数值越小越好)
在复杂分组聚合的查询中，我们看到 TDengine 查询性能相比于 TimescaleDB 有非常大的优势；而在时间窗口聚合的查询过程中，针对规模较大的数据集，TimescaleDB 查询性能不佳——long-driving-sessions 和 long-daily-sessions 均表现很差。TDengine 在 stationary-trucks 查询性能是 TimescaleDB 的 8 倍；在 long-daily-sessions 中是 TimescaleDB 的 87 倍。
4000 devices Double rollups 查询响应时间 (数值越小越好)
4000 devices 查询响应时间 (数值越小越好)
在复杂的混合查询中， TDengine 展现出巨大的性能优势，按查询响应时间来度量，在 daily-activity 查询中，TDengine 是TimescaleDB 的 34 倍，在 avg-load 查询中，TDengine 是其 23 倍。
资源开销对比
由于部分查询持续时间特别短，因此并不能完整地看到查询过程中服务器的 IO/CPU/网络情况。为此，我们针对场景二，以 daily-activity 查询为例，执行 50 次查询，记录两大软件系统在查询执行的整个过程中服务器 CPU、内存、网络的开销并进行对比。
服务器 CPU 开销
查询过程中服务器 CPU 开销
从上图可以看到，两大系统在整个查询过程中 CPU 的使用均较为平稳。TDengine 在查询过程中整体 CPU 占用约 为 70%，TimescaleDB 在查询过程中瞬时 CPU 最低，约为 22%。从整体 CPU 开销上来看，虽然 TimescaleDB 瞬时 CPU 开销最低，但是其完成查询持续时间最长，所以整体 CPU 资源消耗最多。TDengine 完成全部查询的时间仅是 TimescaleDB 的 1/30，整体 CPU 开销最低。
服务器内存状况
查询过程中服务器内存情况
如上图所示，在整个查询过程中，TDengine 内存维持了一个相对平稳的状态，平均使用约为 12GB；TimescaleDB 内存占用在整个查询过程中均保持平稳，平均约为 10GB，此外其对 buffer 和 cache 使用比较多。
服务器网络带宽
查询过程中网络占用情况
上图展示了查询过程中两大系统服务器端上行和下行的网络带宽情况，负载状况基本上和 CPU 状况相似——TDengine 网络带宽开销最高，因为在最短的时间内就完成了全部查询，需要将查询结果返回给客户端。
100 devices × 10 metrics 查询性能对比
对于场景一(100 devices x 10 metrics)，TSBS 的 15 个查询对比结果如下：
| 查询类型 | TDengine | TimescaleDB | TimescaleDB/TDengine |
| last-loc | 1.03 | 1.35 | 131.07% |
| low-fuel | 4.61 | 6.74 | 146.20% |
| high-load | 1.03 | 1.31 | 127.18% |
| stationary-trucks | 3.59 | 4.02 | 111.98% |
| long-driving-sessions | 5.4 | 61.87 | 1145.74% |
| long-daily-sessions | 13.88 | 228.38 | 1645.39% |
| avg-vs-projected-fuel-consumption | 267.03 | 830.79 | 311.12% |
| avg-daily-driving-duration | 278.62 | 1049.07 | 376.52% |
| avg-daily-driving-session | 166.49 | 1066.69 | 640.69% |
| avg-load | 102.31 | 487.39 | 476.39% |
| daily-activity | 146.5 | 1245.05 | 849.86% |
| breakdown-frequency | 413.82 | 955.2 | 230.82% |
如上表所示，从更小规模的数据集（场景一）上的查询对比可以看到，整体上 TDengine 同样展现出极好的性能，在全部的查询语句中全面优于 TimescaleDB，部分查询性能超过 TimescaleDB 16 倍。
磁盘空间占用
在两大系统数据完全落盘后，我们针对 TimescaleDB 和 TDengine 在不同场景下的磁盘空间占用进行了比较。
磁盘空间占用（数值越小越优）
从上图可以看到，TimescaleDB 在所有的场景下数据规模均显著地大于 TDengine，并且这种差距随着数据规模增加快速变大。其中，TimescaleDB 在场景四和场景五中占用磁盘空间超过了 TDengine 的 11 倍。
测试过程中还有个小插曲，下表反应了 TimescaleDB 的压缩比率，可以看到，TimescaleDB 在小数据规模的情况下，压缩比正常，但是在数据规模较大的场景四和场景五中，压缩以后的磁盘空间占用比例反而增大了 3.4 倍左右，疑似 bug。
| 压缩后磁盘空间占用（KB） | 压缩前磁盘空间占用（KB） | 压缩比率 |
| 998312 | 6907312 | 14% |
| 4246528 | 36490408 | 12% |
| 6035528 | 26290904 | 23% |
| 16612380 | 4841552 | 343% |
| 165769964 | 48305396 | 343% |
写在最后
值得一提的是，本次性能测试所用的基准性能测试平台 TSBS 是由 Timescale 一手打造的，测试结果的公平公正性可见一斑。从上述 IoT 场景下的 TSBS 测试报告中我们可以得出结论，不管是在写入性能、查询性能还是存储性能，TDengine 比 TimescaleDB 都略胜一筹，且不论是服务器的 CPU 还是 IO 抑或是客户端的开销统计，TDengine 均远优于 TimescaleDB。
具体到实践上，在八五信息的新能源电力物联网平台项目，曾经使用的数据库便是 TimescaleDB，后面因为种种原因，他们选择应用 TDengine 升级数据架构，关于本次案例的具体信息可以查看《代替 TimescaleDB，TDengine 接管数据量日增 40 亿条的光伏日电系统》。
为了方便大家验证测试结果，本测试报告支持运行测试脚本一键复现，欢迎各位检验。同时，我们也欢迎大家添加 小T vx：tdengine，加入 TDengine 用户交流群，和更多志同道合的开发者一起探讨数据处理难题。