5 大類 15 小類查詢型別全面對比，三大流行時序資料庫查詢效能孰強孰劣

在上一篇文章 中，我們基於 TSBS    （ ）效能基準測試報告對三大資料庫寫入效能進行了相關解讀，較為直觀地展現出了   的眾多寫入優勢。本篇文章將以查詢效能作為主題，給正在為資料分析痛點而頭疼的朋友們帶來一些幫助。

在查詢效能評估部分，我們使用場景一（只包含 4 天資料）和場景二作為基準資料集，關於基礎資料集的具體特點，請點選進入 一文中檢視。在查詢效能評估之前，為確保兩大資料庫充分發揮查詢效能，對於 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-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裝置）的查詢效能對比結果。

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 使用者交流群，和更多志同道合的開發者一起攻克難關。