在上一篇文章《写入性能：TDengine 最高达到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》中，咱们基于 TSBS 时序数据库（Time Series Database）性能基准测试报告对三大数据库写入性能进行了相干解读，较为直观地展现出了 TDengine 的泛滥写入劣势。本篇文章将以查问性能作为主题，给正在为数据分析痛点而头疼的敌人们带来一些帮忙。在查问性能评估局部，咱们应用场景一（只蕴含 4 天数据）和场景二作为基准数据集，对于根底数据集的具体特点，请点击进入《TSBS 是什么？为什么 TDengine 会抉择它作为性能比照测试平台？》一文中查看。
在查问性能评估之前，为确保两大数据库充分发挥查问性能，对于 TimescaleDB，咱们采纳了《TimescaleDB vs. InfluxDB》（见下方链接）中的举荐配置，设置为 8 个 Chunk；对于 InfluxDB，咱们开启 InfluxDB 的 TSI (time series index)。在整个查问比照中，TDengine 数据库的虚构节点数量（vnodes）放弃为默认的 6 个，其余的数据库参数配置为默认值。
TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-ti…
4,000 devices × 10 metrics 查问性能比照：最高达到 InfluxDB 的 34.2 倍
因为局部类型（分类规范参见上方《TimescaleDB vs. InfluxDB》一文）单次查问响应工夫十分短，为了更加精确地测量每个查问场景下较为稳固的响应工夫，咱们将单个查问运行次数晋升到 5000 次，而后应用 TSBS 主动统计并输入后果，最初后果是 5000 次查问的算数平均值，应用并发客户端 Workers 数量为 8。下表是场景二（4000 设施）的查问性能比照后果。
4,000 devices × 10 metrics（场景二）查问性能比照表（单位：ms）
上面咱们对每个查问后果做肯定的剖析阐明：
4000 devices × 10 metrics Simple Rollups 查问响应工夫 (数值越小越好)
因为 Simple Rollups 的整体查问响应工夫十分短，因而制约查问响应工夫的主体因素并不是查问所波及的数据规模，即这一类型查问的瓶颈并非数据规模。但从后果上看，TDengine 依然在所有类型的查问响应工夫上优于 InfluxDB 和 TimescaleDB，具体的数值比照请参见上表。
4000 devices × 10 metrics Aggregates 查问响应工夫 (数值越小越好)
在 Aggregates 类型的查问中，TDengine 的查问性能相比于 TimescaleDB 和 InfluxDB 劣势更为显著，其在 cpu-max-all-8 中的查问性能是 InfluxDB 的 7 倍，是 TimescaleDB 的 6 倍。
4000 devices × 10 metrics Double rollups 查问响应工夫 (数值越小越好)
从上表可见，在 Double-rollups 类型查问中，TDengine 展现出了微小的性能劣势。以查问响应工夫来度量，其在 double-groupby-5 和 double-groupby-all 的查问性能均是 TimescaleDB 的 24 倍；在 double-groupby-5 查问上是 InfluxDB 的 26 倍，double-groupby-all 上是其 34 倍。
4000 devices × 10 metrics Thresholds 查问 high-cpu-1 响应工夫 (数值越小越好)
4000 devices × 10 metrics Thresholds 查问 high-cpu-all 响应工夫 (数值越小越好)
如下面两图所示，threshold 类型的查问中，high-cpu-1 中 TDengine 的查问响应工夫均显著低于 TimescaleDB 和 InfluxDB。在 high-cpu-all 的查问中，TDengine 的性能是 InfluxDB 的 15 倍，是 TimescaleDB 的 1.23 倍。
4000 devices × 10 metrics Complex queries 查问响应工夫 (数值越小越好)
对于 Complex-queries 类型的查问，TDengine 两个查问均大幅当先 TimescaleDB 和 InfluxDB——在 lastpoint 查问中，其性能是 TimescaleDB 的 5 倍，InfluxDB 的 21 倍；在 groupby-orderby-limit 场景中其查问性能是 TimescaleDB 的 8 倍，是 InfluxDB 的 15 倍。在工夫窗口聚合的查问过程中，TimescaleDB 针对规模较大的数据集查问性能不佳（double rollups 类型查问），对于 groupby-orderby-limit 的查问，其性能上体现同样不是太好。
资源开销比照：整体 CPU 计算工夫耗费是 InfluxDB 的 1/10
因为局部查问持续时间特地短，因而并不能凭借以上信息残缺地看到查问过程中服务器的 IO/CPU/ 网络状况。为此，咱们以场景二的数据为模仿数据，以 Double rollups 类别中的 double-groupby-5 查问为例，执行 1000 次查问，记录整个过程中三个软件系统在查问执行的整个过程中服务器 CPU、内存、网络的开销并进行比照。
服务器 CPU 开销
查问过程中服务器 CPU 开销
从上图能够看到，三个零碎在整个查问过程中 CPU 的应用均较为安稳。TDengine 在查问过程中整体 CPU 占用约 80%, 在三个零碎中应用的 CPU 资源最高；TimescaleDB 在查问过程中刹时 CPU 占用次之，约 38%；InfluxDB 的 CPU 占用的最小，约 27 %（然而有较多的刹时冲高）。从整体 CPU 开销上来看，尽管 InfluxDB 刹时 CPU 开销最低，然而其实现查问持续时间也最长，所以整体 CPU 资源耗费最多。因为 TDengine 实现全副查问的工夫仅为 TimescaleDB 或 InfluxDB 的 1/20，因而尽管其 CPU 稳固值是 TimescaleDB 与 InfluxDB 的 2 倍多，但整体的 CPU 计算工夫耗费却只有其 1/10。
服务器内存情况
查问过程中服务器内存状况
如上图所示，在整个查问过程中，TDengine 内存维持了一个绝对安稳的状态。TimescaleDB 在整个查问过程中内存出现减少的状态，查问实现后即复原到初始状态，InfluxDB 内存占用出现绝对稳固的状态。
服务器网络带宽
查问过程中网络占用状况
上图展现了查问过程中服务器端上行和上行的网络带宽状况，负载情况基本上和 CPU 情况类似。TDengine 网络带宽开销最高，因为在最短的工夫内就实现了全副查问，须要将查问后果返回给客户端。InfluxDB 网络带宽开销最低，TimescaleDB 介于两者之间。
100 devices × 10 metrics 查问性能比照：最高达到 TimescaleDB 的 28.6 倍
对于场景一 (100 devices x 10 metrics) 来说，TSBS 的 15 个查问比照后果如下：
InfluxDB 与 Timescale 绝对于 TDengine 的查问响应工夫比率 (单位：ms)
如上表所示，在更小规模的数据集（100 设施）上的查问比照能够看到，整体来说 TDengine 同样展现出极好的性能，在全副查问语句中均优于 TimescaleDB 和 InfluxDB，局部查问性能超过 TimescaleDB 28 倍，超过 InfluxDB 37 倍。
写在最初
基于上文能够做出总结，整体来讲，在场景一（只蕴含 4 天的数据）与场景二的 15 个不同类型的查问中，TDengine 的查问均匀响应工夫全面优于 InfluxDB 和 TimescaleDB，在简单查问上劣势更为显著，同时具备最小的计算资源开销。绝对于 InfluxDB，场景一中 TDengine 查问性能是其 1.9 ～ 37 倍，场景二中 TDengine 查问性能是其 1.8 ～ 34.2 倍；绝对于 TimeScaleDB，场景一中 TDengine 查问性能是其 1.1 ～ 28.6 倍，场景二中 TDengine 查问性能是其 1.2 ～ 24.6 倍。
事实上，TDengine 高效的查问性能此前在很多企业客户的实际中就曾经展现进去了，以广东省环境迷信研究院生态环境数据治理服务项目为例，对于 76 亿行的超级表，TDengine 运行分组 TOP 查问仅用了 0.2 秒；基于 TDengine 返回 2,968 行，仅用了 0.06 秒；返回 5,280 行数据，仅用了 0.1 秒。
如果你也面临着数据处理难题或想要进行数据架构降级，欢送增加 小 T vx：tdengine1，退出 TDengine 用户交换群，和更多气味相投的开发者一起攻克难关。