亮點總結：

TSBS 測試表明，對于少于 100 萬臺設備的數據集，InfluxDB OSS 3.0 的數據寫入速度實際上比 InfluxDB OSS 1.8 更慢。

對于 100 萬臺及以上設備的數據集，InfluxDB OSS 3.0 的數據寫入性能才開始超過 InfluxDB OSS 1.8。

InfluxDB OSS 3.0 的數據寫入接口與 InfluxDB 1.8 并不兼容，用戶無法順利遷移。

早在 2023 年，在 InfluxDB 3.0 推向企業用戶時，官方曾宣稱其相比舊版本有顯著的性能提升。為了驗證這一說法，InfluxData 還發布了一份基準測試報告，對比了 InfluxDB 3.0 企業版與 InfluxDB OSS 1.8，結果顯示 InfluxDB 3.0 在各方面表現出色。

我們對這個版本非常好奇，但作為非企業用戶，只能和大多數人一樣等待了一年半，直到今年 1 月 InfluxDB OSS 3.0 終于公開發布。雖然目前的版本僅是“public alpha”，但這并不妨礙我們對其性能抱有很高的期待，畢竟 InfluxData 已經第二次徹底重構產品架構。對于那些希望平穩升級的用戶來說，這無疑是個不小的沖擊，更何況官方還直接放棄了 Flux 語言。如果 InfluxDB 3.0 無法在性能上帶來真正的突破，那這樣的升級又有何意義？

實際測試：InfluxDB 3.0 真的更快嗎？

為了驗證 InfluxDB 3.0 是否真的如官方宣傳般帶來巨大性能提升，我們采用 Time Series Benchmark Suite (TSBS) 進行對比測試。TSBS 由 InfluxData 最初開發，目前由 Timescale 維護，是業界公認的時序數據庫基準測試工具。理論上，InfluxDB 3.0 仍支持 InfluxQL 和傳統的 Line Protocol，因此應該能夠直接運行針對 1.8 版本的測試套件。然而，在實際測試過程中，我們遇到了多個兼容性問題，不得不尋找替代方案，這部分將在后續介紹測試方法的章節中詳細說明。

我們之所以選擇 TSBS 作為測試工具，不僅因為它比 QuestDB 之前發布的簡單基準測試更全面，還因為它提供了一個公開透明的測試框架，讓不同數據庫的對比變得更加公平。然而，測試結果卻讓我們大跌眼鏡。

TSBS 提供了兩個測試場景：DevOps 監控（CPU 監測）和物聯網（IoT，車輛跟蹤）。在測試中，我們使用 TSBS 生成數據，并分別寫入 InfluxDB 3 0.1.0（修訂版 v2.5.0-14345）、InfluxDB OSS 1.8 和 TDengine OSS 3.3.5.8。以下圖表展示了各系統在不同測試場景下的寫入性能（指標數/秒）。

TSBS DevOps 用例：

TSBS IoT 用例：

測試結果分析：InfluxDB 3.0 寫入提升遠不及 45 倍

在最大規模的數據集中，InfluxDB 3.0 在 DevOps 場景下的寫入性能提升了 5.4 倍，在物聯網（IoT）場景下提升了 4.9 倍。這與 InfluxData 基準測試報告中聲稱的“寫入吞吐量提升 45 倍”相去甚遠。更令人意外的是，在設備數量不超過 10 萬的場景下，InfluxDB 1.8 的寫入性能竟然優于 InfluxDB 3.0。這表明，InfluxDB 3.0 所謂的性能提升，要么僅適用于企業版，要么在獨立測試中并不成立。

從測試結果我們也可以看到，TDengine 的寫入速度比 InfluxDB 3.0 快 4.4 至 11.3 倍，相較 InfluxDB 1.8 更是提升了 3.1 至 22.8 倍。這進一步證明，即便 InfluxDB 3.0 進行了徹底重構，其寫入性能仍難以與 TDengine 相媲美。

TSBS 適配已完成，歡迎查看源碼自行測試

本次測試在一臺 40 核、256GB 內存的服務器上進行。該服務器的配置略低于 InfluxDB 官方基準測試環境，高于 QuestDB 的測試環境，但硬件差異對整體性能趨勢的影響可忽略不計。

由于 TSBS 尚未針對 InfluxDB 3.0 進行更新，我們不得不對其進行一定的修改。為確保公平性，我們盡量減少了改動，但仍需解決以下問題：

• 數據庫管理指令不兼容 TSBS 運行 InfluxDB 1.8 時使用的 SHOW、CREATE、DELETE 數據庫命令在 InfluxDB 3.0 中已不可用。因此，我們改用 InfluxDB v3 API：

  • GET /api/v3/configure/database 查詢數據庫

  • POST /api/v3/configure/database 創建數據庫

  • DELETE /api/v3/configure/database 刪除數據庫

• 多線程寫入失敗 在使用多個并發寫入進程時，InfluxDB 3.0 頻繁出現寫入失敗，并報錯 Invalid write response (status 409): catalog update error: table already exists。為解決此問題，我們修改了 TSBS，使其在遇到該錯誤時自動重試，而不是直接退出。此外，數據寫入采用 InfluxDB 3.0 提供的 /api/v3/write_lp 接口。

現在所有修改均已提交到我們維護的 TSBS 分支，任何人都可以查看源碼并自行運行測試。

結語

盡管 InfluxDB 3.0 經過全面重構，并宣傳性能顯著提升，但從寫入性能來看，至少對開源用戶而言，這一承諾并未兌現。測試結果表明，其寫入性能僅在超大規模數據集下略優于 InfluxDB 1.8，而對于大多數用戶，尤其是設備數少于 100 萬場景下，性能反而有所下降。即便目前仍處于 Public Alpha 階段，但該版本已開發一年多的時間，它的表現真的值得開源社區期待嗎？

此外，InfluxDB 3.0 采用了全新架構，導致用戶無法順利從 1.8 版本升級。對于開源用戶而言，這次升級是否值得，也確實需要慎重考慮。尤其是當數據寫入性能成為瓶頸時，從目前的測試結果來看，InfluxDB 3.0 并未能提供令人信服的解決方案。相比之下，TDengine 始終堅持對開源社區的承諾，不僅提供高性能、全功能的軟件，還確保所有用戶都能公平獲取和使用。面對時序數據存儲與處理的挑戰，選擇一款真正高效、穩定的數據庫，才是更明智的決定。