查问机能：TDengine 至高到达了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍
在上一篇文章《写入机能：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：
influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/
4,000 devices × 10 metrics 查问机能对照：至高到达 InfluxDB 的 34.2 倍由于局部范例（分类尺度拜见上方《TimescaleDB vs. InfluxDB》 一文）单次查问呼应时光十分短，为了愈加准确地丈量每一个查问场景下比较稳固的呼应时光，咱们将单个查问运转次数提高到 5000 次，而后应用 TSBS 主动统计并输入成果，最初成果是 5000 次查问的算数均匀值，应用并发客户端 Workers 数目为 8。
下表是场景二 （4000装备）的查问机能对照成果
底下咱们对每一个查问成果做一定的分析说明：
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 倍。
4000devices×10metrics Thresholds查问high-cpu-all 呼应时光(数值越小越好)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 秒。
如果你也面对
