共计 4957 个字符，预计需要花费 13 分钟才能阅读完成。
为了验证 TDengine 3.0 的性能，咱们应用第三方基准性能测试平台 TSBS（Time Series Benchmark Suite）中针对 DevOps 的 cpu-only 五个场景作为根底数据集，在雷同的 AWS 云环境下对 TDengine 3.0 和 InfluxDB 1.8（该版本是 InfluxDB 可能运行 TSBS 框架的最新版本）进行了比照剖析。在本篇文章中，咱们将从写入、存储、查问、及资源开销等几大维度对测试后果进行汇总剖析，给到大家参考。
咱们采纳下方 TimescaleDB vs. InfluxDB 比照报告中举荐的形式配置 InfluxDB，将缓冲区配置为 80G，以便 1000W 设施写入时可能顺利进行，同时开启 Time Series Index（TSI）。配置零碎在零碎插入数据实现 30s 后开始数据压缩。
TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：
https://www.timescale.com/blog/timescaledb-vs-influxdb-for-ti…
对于零碎的配置详情、如何一键复现测试后果及具体的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、《TSBS 是什么？为什么时序数据库 TDengine 会抉择它作为性能比照测试平台？》两篇文章，本文便不再赘述。
写入性能最高达到 InfluxDB 的 10.6 倍
总体而言，在 TSBS 报告全副的 cpu-only 五个场景中，时序数据库（Time Series Database）TDengine 写入性能均优于 InfluxDB。相比 InfluxDB，TDengine 写入速度最当先的场景是其 10.6 倍（场景五），起码也是 3.0 倍（场景一 )。此外，TDengine 在写入过程中耗费了起码 CPU 资源和磁盘 IO 开销。上面看一下具体分析：
不同场景下写入性能比照
不同场景下写入性能的比照（metrics/sec. 数值越大越好）
从上图能够看到，在全副五个场景中，TDengine 的写入性能全面超过 InfluxDB。TDengine 在场景五中写入性能是 InfluxDB 的 10.63 倍，在差距最小的场景一中也有 3.01 倍。
写入过程资源耗费比照
数据写入速度并不可能全面的反映 TDengine 和 InfluxDB 在不同场景下数据写入的整体体现。为此咱们以 1,000,000 devices × 10 metrics（场景四）为例，检查数据写入过程中的服务器和客户端（包含客户端与服务器）的整体负载情况，并以此来比照 TDengine 和 InfluxDB 在写入过程中服务器 / 客户端节点的资源占用状况，这里的资源占用次要包含服务器端的 CPU 开销 / 磁盘 IO 开销和客户端 CPU 开销。
服务端 CPU 开销
下图展现了两大数据库在场景四写入过程中服务器端 CPU 负载情况。能够看到，TDengine 和 InfluxDB 在返回给客户端写入实现音讯当前，都还持续应用服务器的资源进行相应的解决工作，InfluxDB 应用了相当多的 CPU 资源，刹时峰值甚至应用了全副的 CPU 资源，其写入负载较高，并且其持续时间远长于 TDengine。两个零碎比照，TDengine 对服务器的 CPU 需要最小，峰值也仅应用了 17% 左右的服务器 CPU 资源。由此可见，TDengine 独特的数据模型对于时序数据写入不仅在性能上，在整体的资源开销上也具备十分大的劣势。
写入过程中服务器 CPU 开销
磁盘 I/O 比照
下图展现了 1,000,000 devices × 10 metrics（场景四）数据写入过程中两大数据库在服务器端磁盘的写入状态。能够看到，联合着服务器端 CPU 开销体现，其 IO 动作与 CPU 出现同步的沉闷状态。
写入过程中服务器 IO 开销
在写入雷同规模的数据集状况下，TDengine 在写入过程中对于磁盘写入能力的占用远小于 InfluxDB，写入过程只占用了局部磁盘写入能力（125MiB/Sec. 3000IOPS）。从上图能看到，对于两大数据库，数据写入过程中磁盘的 IO 瓶颈都是的确存在的。但 InfluxDB 长时间耗费齐全部的磁盘写入能力，远远超过了 TDengine 对磁盘写入能力的需要。
客户端 CPU 开销
写入过程中客户端 CPU 开销
从上图能够看到，客户端上 TDengine 对 CPU 的需要是大于 InfluxDB 的。整体来说，在整个写入过程中，InfluxDB 客户端负载计算资源占用较低，对客户端压力小，这是因为其写入的压力基本上齐全集中在服务端，但这种模式很容易导致服务端成为瓶颈。而 TDengine 在客户端的开销最大，峰值霎时达到了 56%，而后疾速回落。综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在零碎整体 CPU 开销上 TDengine 依然具备相当大的劣势。
查问性能最高达到 InfluxDB 的 37 倍
在查问性能的评估上，咱们应用场景一和场景二作为基准数据集。为了让 InfluxDB 施展出更好的查问性能，咱们开启 InfluxDB 的 TSI (time series index)。在整个查问比照中，TDengine 数据库的虚构节点数量（vnodes）放弃为默认的 6 个，其余的数据库参数配置为默认值。
总体来说，查问方面，在场景一（只蕴含 4 天的数据）与场景二的 15 个不同类型的查问中，TDengine 的查问均匀响应工夫是全面优于 InfluxDB 的，而且在简单查问上劣势更为显著，同时具备最小的计算资源开销。相比 InfluxDB，场景一中 TDengine 查问性能是其 1.9 ～ 37.0 倍，场景二中 TDengine 查问性能是其 1.8 ～ 34.2 倍。
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 依然在所有类型的查问响应工夫上优于 InfluxDB，具体的数值比拟请参见上表中的具体数据表格。
4000 devices × 10 metrics Aggregates 查问响应工夫 (数值越小越好)
在 Aggregates 类型的查问中，咱们看到 TDengine 查问性能相比于 InfluxDB 有较大劣势，TDengine cpu-max-all-8 类型的查问性能是 InfluxDB 的 7 倍。
4000 devices × 10 metrics Double rollups 查问响应工夫 (数值越小越好)
在 Double-rollups 类型查问中，TDengine 同样展现出微小的性能劣势，以查问响应工夫来度量，在 double-groupby-5 查问上 TDengine 是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。
4000 devices × 10 metrics Thresholds 查问 high-cpu-1 响应工夫 (数值越小越好)
4000 devices × 10 metrics Thresholds 查问 high-cpu-all 响应工夫 (数值越小越好)
下面两图是 threshold 类型的查问比照，TDengine 的查问响应工夫均显著低于 InfluxDB。在 high-cpu-all 类型的查问上，TDengine 的性能是 InfluxDB 的 15 倍。
4000 devices × 10 metrics Complex queries 查问响应工夫 (数值越小越好)
对于 Complex-queries 类型的查问，TDengine 两个查问均大幅当先 InfluxDB。在 lastpoint 查问中，查问性能是 InfluxDB 的 21 倍；在 groupby-orderby-limit 场景中查问性能是 InfluxDB 的 15 倍。
资源开销比照
因为局部查问持续时间特地短，因而咱们并不能残缺地看到查问过程中服务器的 IO/CPU/ 网络状况。为此咱们针对场景二以 Double rollups 类别中的 double-groupby-5 查问为例，执行 1,000 次查问，记录 TDengine 和 InfluxDB 在查问执行的整个过程中服务器 CPU、内存、网络的开销并进行比照。
查问过程中服务器 CPU 开销
从上图能够看到，TDengine 和 InfluxDB 在整个查问过程中 CPU 的应用均较为安稳。TDengine 在查问过程中整体 CPU 占用约 80%，应用的 CPU 资源较高，InfluxDB 稳固的 CPU 占用较小，约 27 %（然而有较多的刹时冲高）。从整体 CPU 开销上来看，尽管 InfluxDB 刹时 CPU 开销大部分是较低的，然而其实现查问持续时间最长，所以整体 CPU 资源耗费最多。因为 TDengine 实现全副查问的工夫仅是 InfluxDB 的 1/20，尽管 CPU 稳固值是 InfluxDB 的 2 倍多，但整体的 CPU 计算工夫耗费只有其 1/10。
服务器内存情况
查问过程中服务器内存状况如上图所示，在整个查问过程中，TDengine 与 InfluxDB 的内存均维持在一个绝对安稳的状态。
服务器网络带宽
查问过程中网络占用状况上图展现了查问过程中服务器端上行和上行的网络带宽状况，负载情况基本上和 CPU 情况类似。TDengine 网络带宽开销最高，因为在最短的工夫内就实现了全副查问，须要将查问后果返回给客户端。InfluxDB 网络带宽开销最低，持续时间也较长。
3,100 devices × 10 metrics 查问性能比照
对于场景一 (100 devices x 10 metrics)，TSBS 的 15 个查问比照后果如下：
如上表所示，在更小规模的数据集（100 设施）上的查问比照能够看到，整体上 TDengine 同样展现出极好的性能，在全副的查问语句中全面优于 InfluxDB，局部查问性能超过 InfluxDB 37 倍。
InfluxDB 占用的磁盘空间最高达到 TDengine 的 4.5 倍
在后面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 十分靠近，然而在大数据规模的场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间显著超过了 TDengine。下图比拟了 TDengine 和 InfluxDB 在不同场景下的磁盘空间占用状况：
磁盘空间占用（数值越小越优）
从上图能够看到，在后面三个场景中，InfluxDB 落盘后数据文件规模与 TDengine 十分靠近（在场景二中，TDengine 的数据落盘规模比 InfluxDB 大了 1%）。然而在场景四和场景五中，InfluxDB 落盘后文件占用的磁盘空间别离是 TDengine 的 4.2 倍和 4.5 倍。
写在最初
基于本次测试报告，咱们能够得出结论，在全副的数据场景中，TDengine 写入性能、查问性能均全面超过 InfluxDB。在整个写入过程中，TDengine 在提供更高写入和查问能力的前提下，不论是服务器的 CPU 还是 IO，TDengine 均优于 InfluxDB。即便加上客户端的开销统计，TDengine 在写入开销上也在 InfluxDB 之下。
从实际角度登程，这个报告后果也很好地阐明了为什么有很多企业客户在 InfluxDB 和 TDengine 的选型调研中抉择了 TDengine，双汇便是其中之一，在《双汇大数据计划选型：从辣手的 InfluxDB+Redis 到毫秒级查问的 TDengine》这篇文章中，便论述了其选型调研过程的具体思考。
为了不便大家验证测试后果，本测试报告反对运行测试脚本一键复现，欢送大家在评论区互动交换。同时，你也能够增加 小 T vx：tdengine1，退出 TDengine 用户交换群，和更多气味相投的开发者一起探讨数据处理难题。