共计 5109 个字符，预计需要花费 13 分钟才能阅读完成。
基于第三方基准性能测试平台 TSBS（Time Series Benchmark Suite）规范数据集，TDengine 团队别离就 TSBS 指定的 DevOps 中 cpu-only 五个场景，对时序数据库（Time Series Database，TSDB）TimescaleDB 和 TDengine 进行了比照测试。本文将会从写入、存储、查问及资源开销等几大维度为大家汇总分析测试后果。
为确保后果具备可比性，本次测试选用 TimescaleDB 2.6.0 版本。为取得较好的性能，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…
对于零碎的配置详情、如何一键复现测试后果及具体的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、《TSBS 是什么？为什么时序数据库 TDengine 会抉择它作为性能比照测试平台？》两篇文章，本文便不再赘述。
写入性能最高达到了 TimescaleDB 的 6.7 倍
在 TSBS 全副的 cpu-only 五个场景中，TDengine 写入性能均优于 TimescaleDB。相比 TimescaleDB，TDengine 写入速度最当先的场景是其 6.7 倍（场景二），起码也是 1.5 倍（场景五），而且对于场景四，如果将每个采集点的记录条数由 18 条减少到 576 条，TDengine 写入速度就达到了 TimescaleDB 的 13.2 倍。此外，TDengine 在写入过程中耗费的 CPU 资源和磁盘 IO 开销也是最低的。
不同场景下写入性能比照
不同场景下写入性能的比照（metrics/sec. 数值越大越好）
从上图能够看到，在全副五个场景中，TDengine 的写入性能全面超过 TimescaleDB。 在场景二中 TDengine 写入性能最大达到了 TimescaleDB 的 6.74 倍，在差距最小的场景五中，也达到了 TimescaleDB 的 1.52 倍。
写入过程资源耗费比照
但仅凭数据写入速度，并不能全面地反映出 TDengine 和 TimescaleDB 在不同场景下数据写入的整体体现。为此咱们以 1,000,000 devices × 10 metrics（场景四）为例，检查数据写入过程中的服务器和客户端的整体负载情况，并以此来比照 TDengine 和 TimescaleDB 在写入过程中服务器 / 客户端节点的资源占用状况，这里的资源占用次要包含服务器端的 CPU 开销 / 磁盘 IO 开销和客户端 CPU 开销。
服务端 CPU 开销
写入过程中服务器 CPU 开销上图展现了在场景四写入过程之中服务器端 CPU 负载情况。能够看到，TDengine 和 TimescaleDB 在返回给客户端写入实现音讯当前，都还持续应用服务器的资源进行相应的解决工作，这点上，TimescaleDB 尤为显著，TimescaleDB 在 7x 秒的时候即反馈客户端写入实现，然而其服务器端依然在调用 CPU 资源进行数据压缩和整顿工作，当然整个工作带来的 CPU 负载相对而言并不高，只有其峰值 CPU 开销的一半左右，然而其持续时间相当长，靠近净写入工夫的 4 倍，远长于 TDengine。TDengine 对服务器的 CPU 需要较小，峰值也仅应用了 17% 左右的服务器 CPU 资源。 由此可见，TDengine 独特的数据模型不仅体现在时序数据的写入性能上，也体现在整体的资源开销上。
磁盘 I/O 比照
写入过程中服务器 IO 开销上图展现了 1,000,000 devices × 10 metrics（场景四）两大零碎在数据写入过程中服务器端磁盘写入状态。联合服务器端 CPU 开销体现，能够看到，两大数据库的 IO 动作与 CPU 均呈现出同步沉闷状态。
在写入雷同规模数据集的状况下，TDengine 在写入过程中对于磁盘写入能力的占用远小于 TimescaleDB，整体写入过程只占用了局部磁盘写入能力（125MiB/Sec. 3000IOPS）。从图上能看到，对于两大数据库来说，数据写入过程中磁盘的 IO 瓶颈是的确存在的，但 TimescaleDB 写入过程对于写入的耗费远超过了 TDengine 对磁盘写入能力的需要。
客户端 CPU 开销
写入过程中客户端 CPU 开销从上图能够看到，客户端上 TDengine 对 CPU 的需要大于 TimescaleDB，TDengine 在客户端峰值霎时达到了 56%，而后疾速回落，其在客户端的开销相比于 TimescaleDB 多了 1 倍。但综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在零碎整体 CPU 开销上 TDengine 依然具备相当大的劣势。
查问性能最高达到了 TimescaleDB 的 28.6
倍在场景一（只蕴含 4 天数据）与场景二的 15 个不同类型的查问中，TDengine 的查问均匀响应工夫全面优于 TimescaleDB，而且在简单查问上劣势更为显著，同时具备最小的计算资源开销。相比 TimeScaleDB，场景一中 TDengine 的查问性能是其 1.1 ～ 28.6 倍，场景二中 TDengine 的查问性能是其 1.2 ～ 24.6 倍。
在查问性能评估局部，咱们应用场景一和场景二作为基准数据集。在查问性能评估之前，对于 TimescaleDB，咱们采纳上文呈现的 TimescaleDB vs. InfluxDB 比照报告中举荐配置，设置为 8 个 Chunk，以确保其充分发挥查问性能。在整个查问比照中，TDengine 数据库的虚构节点数量（vnodes）放弃为默认的 6 个，其余的数据库参数配置为默认值。
4,000 devices × 10 metrics 查问性能比照
因为局部类型（分类规范参见 TimescaleDB vs. InfluxDB 比照报告）单次查问响应工夫十分短，为了更加精确地测量每个查问场景的较为稳固的响应工夫，咱们将单个查问运行次数晋升到 5,000 次，而后应用 TSBS 主动统计并输入后果，最初后果是 5,000 次查问的算数平均值，应用并发客户端 Workers 数量为 8。
下表是场景二（4,000 设施）下两大数据库的查问性能比照后果。
上面咱们对每个查问后果做肯定的剖析阐明：
4000 devices × 10 metrics Simple Rollups 查问响应工夫 (数值越小越好)
因为 Simple Rollups 的整体查问响应工夫十分短，因而制约查问响应工夫的主体因素并不是查问所波及的数据规模，即这一类型查问的瓶颈并非数据规模。但从后果上看，TDengine 依然在所有类型的查问响应工夫上优于 TimescaleDB，具体的数值比照请参见上表。
4000 devices × 10 metrics Aggregates 查问响应工夫 (数值越小越好)
通过上图能够看到，在 Aggregates 类型的查问中，TDengine 的查问性能相比 TimescaleDB 有比拟大的劣势，其 cpu-max-all-8 查问性能是 TimescaleDB 的 6 倍。
4000 devices × 10 metrics Double rollups 查问响应工夫 (数值越小越好)
在 Double-rollups 类型查问中，TDengine 同样展现出微小的性能劣势，以查问响应工夫来度量，其在 double-groupby-5 和 double-groupby-all 类型下的查问性能均达到了 TimescaleDB 的 24 倍。
4000 devices × 10 metrics Thresholds 查问 high-cpu-1 响应工夫 (数值越小越好)
4000 devices × 10 metrics Thresholds 查问 high-cpu-all 响应工夫 (数值越小越好)
下面两图展现的是 threshold 类型的查问比照，能够看到，TDengine 的查问响应工夫均显著低于 TimescaleDB。在 high-cpu-all 类型的查问上，TDengine 的性能是 TimescaleDB 的 1.23 倍。
4000 devices × 10 metrics Complex queries 查问响应工夫 (数值越小越好)
对于 Complex-queries 类型的查问，TDengine 两个查问同样均大幅当先 TimescaleDB。在 lastpoint 查问中 TDengine 的查问性能是 TimescaleDB 的 5 倍，在 groupby-orderby-limit 场景中 TDengine 的查问性能是 TimescaleDB 的 8 倍。在工夫窗口聚合的查问过程中，针对规模较大的数据集 TimescaleDB 查问性能不佳（double rollups 类型查问），对于 groupby-orderby-limit 类型的查问，TimescaleDB 的性能体现同样不是太好。
资源开销比照
因为局部查问持续时间特地短，因而咱们并不能残缺地看到查问过程中服务器的 IO/CPU/ 网络状况。为此咱们针对场景二以 Double rollups 类别中的 double-groupby-5 查问为例，执行 1,000 次查问，记录整个过程中 TDengine、TimescaleDB 两个软件系统在查问执行的整个过程中服务器 CPU、内存、网络的开销并进行比照。
查问过程中服务器 CPU 开销如上图所示，两个零碎在整个查问过程中 CPU 的应用均较为安稳。TDengine 在查问过程中整体 CPU 占用约 80%，应用的 CPU 资源最高，TimescaleDB 在查问过程中刹时 CPU 占用约 38%。因为 TDengine 实现全副查问的工夫仅 TimescaleDB 1/20，因而尽管其 CPU 稳固值是 TimescaleDB 的 2 倍多，但整体的 CPU 计算工夫耗费只有其 1/10。服务器内存情况
查问过程中服务器内存状况如上图所示，在整个查问过程中，TDengine 内存维持在一个绝对安稳的状态。而 TimescaleDB 在整个查问过程中内存出现减少的状态，查问实现后即复原到初始状态。服务器网络带宽
查问过程中网络占用状况上图展现了查问过程中两个零碎的服务器端上行和上行的网络带宽状况，能够看到，负载情况基本上和 CPU 情况类似。TDengine 网络带宽开销较高，因为在最短的工夫内就实现了全副查问，须要将查问后果返回给客户端。TimescaleDB 开销较低，但持续时间长。
100 devices × 10 metrics 查问性能比照
对于场景一 (100 devices x 10 metrics)，TSBS 的 15 个查问比照后果如下：
如上表所示，从更小规模的数据集（100 设施）上的查问比照能够看到，整体上 TDengine 同样展现出极好的性能，在全副的查问语句中全面优于 TimescaleDB，局部查问性能超过 TimescaleDB 28 倍。
TimescaleDB 占用的磁盘空间最高达到 TDengine 的 26.9 倍
下图是 TDengine 和 TimescaleDB 数据齐全落盘当前，比拟了两个零碎在不同场景下的磁盘空间占用：
磁盘空间占用（数值越小越优）
在磁盘空间的占用上，从上图能够看到，TimescaleDB 在全副五个场景下的数据规模均显著大于 TDengine，并且这种差距随着数据规模减少疾速变大。TimescaleDB 在场景四和场景五中占用磁盘空间是 TDengine 的 25.6 倍和 26.9 倍。
写在最初
从上述 TSBS 测试报告中咱们能够得出结论，不论是在写入性能、查问性能还是存储性能，TDengine 比 TimescaleDB 都稍逊一筹，且不论是服务器的 CPU 还是 IO 抑或是客户端的开销统计，TDengine 均远优于 TimescaleDB。尤其本次性能测试还是基于 Timescale 打造的基准性能测试平台 TSBS 进行的，测试后果的偏心公正性可见一斑。
具体到实际上，在八五信息的新能源电力物联网平台我的项目，已经应用的数据库便是 TimescaleDB，前面因为种种原因，他们抉择利用 TDengine 降级数据架构，对于本次案例的具体信息能够查看《代替 TimescaleDB，TDengine 接管数据量日增 40 亿条的光伏日电零碎》。
为了不便大家验证测试后果，本测试报告反对运行测试脚本一键复现，欢送各位测验。同时，咱们也欢送大家增加 小 T vx：tdengine1，退出 TDengine 用户交换群，和更多气味相投的开发者一起探讨数据处理难题。
