InfluxDB vs TDengine，用資料“說”效能

為了驗證 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-time-series-data-timescale-influx-sql-nosql-36489299877/

關於系統的配置詳情、如何一鍵復現測試結果及詳細的測試資料介紹等內容，大家可參考《一鍵獲取測試指令碼，輕鬆驗證“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，雙匯便是其中之一，在 這篇文章中，便闡述了其選型調研過程的具體思考。

為了方便大家驗證測試結果，本測試報告支援執行測試指令碼一鍵復現，歡迎大家在評論區互動交流。同時，你也可以新增 小T vx：tdengine1，加入 TDengine 使用者交流群，和更多志同道合的開發者一起探討資料處理難題。