在上一篇文章《寫入性能：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-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 秒。