寫入效能：TDengine 最高達到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍

上週三，TDengine   正式釋出了基於 TSBS 的時序資料庫 （Time Series Database ，TSDB ）效能基準測試報告，該報告採用 TSBS 平臺中針對 DevOps 的場景作為基礎資料集，在相同的 AWS 雲環境下對 TDengine 3.0 、 TimescaleDB 2.6 和 InfluxDB 1.8 進行了對比分析。為了便於大家更好地閱讀和理解，基於報告內容，我們將從寫入、查詢及測試過程如何復現等幾大維度輸出系列文章。本篇文章將為大家解讀三大時序資料庫在寫入效能上的差異點。

在《TSBS 是什麼？為什麼 TDengine 會選擇它作為效能對比測試平臺？》 一文中，我們對測試場景和基本配置已經進行了詳細介紹，本篇文章便不再贅述，還沒有了解過的小夥伴可以點選上文連結檢視。

五大場景下，TDengine 寫入效能實現全面超越

不同場景下寫入效能的對比（metrics/sec. 數值越大越好）

 

如上圖所示，我們可以看到在全部五個場景中，TDengine 的寫入效能全面超越了 TimescaleDB 和 InfluxDB 。在場景二中 TDengine 寫入效能最高達到了 TimescaleDB 的 6.74 倍，在差距最小的場景五中， TDengine 也是 TimescaleDB 的 1.52 倍。相比 InfluxDB ， TDengine 在場景五中寫入效能達到 InfluxDB 的 10.63 倍，在差距最小的場景一中也有 3.01 倍，具體的倍率關係請參見下表。

TDengine 與 InfluxDB 、 TimescaleDB 的寫入效能對比

 

此外，我們還注意到，隨著裝置數規模的增加，所有系統寫入基本上呈現下降趨勢。TimescaleDB 在小規模資料情況下寫入效能不及 InfluxDB ，但是隨著裝置數量的增加，其寫入效能超過了 InfluxDB 。

在資料完全落盤後，我們又比較了一下三個系統在不同場景下的磁碟空間佔用情況。

磁碟空間佔用（數值越小越優）

 

可以看到， TimescaleDB 在所有的場景下資料規模均顯著地大於 InfluxDB 和 TDengine ，並且這種差距隨著資料規模增加快速變大 —— TimescaleDB 在場景四和場景五中佔用磁碟空間是 TDengine 的 25 倍。在前面三個場景中， InfluxDB 落盤後資料檔案規模與 TDengine 非常接近（在場景二中， TDengine 的資料落盤規模比 InfluxDB 大了 1% ） , 但是在場景四 / 五兩個場景中， InfluxDB 落盤後檔案佔用的磁碟空間卻達到了 TDengine 的 4 倍以上。

寫入過程資源消耗對比，InfluxDB>TimescaleDB>TDengine

僅憑資料寫入速度，並不能全面地反映出三個系統在不同場景下資料寫入的整體表現。為此我們以 1,000,000 devices × 10 metrics （場景四）為資料模板，檢查三大資料庫在資料寫入過程中伺服器和客戶端的整體負載狀況，並以此來對比它們在寫入過程中伺服器 / 客戶端節點的資源佔用情況。這裡的資源佔用主要包括伺服器端的 CPU 開銷 / 磁碟 IO 開銷和客戶端 CPU 開銷。

服務端 CPU 開銷

寫入過程中伺服器 CPU 開銷

 

上圖直觀地展示出了三大系統在場景四寫入過程中的伺服器端 CPU 負載狀況，在圖中我們使用虛線標識出了服務端給客戶端確認寫入完成的時刻。可以看到，三個系統在返回給客戶端寫入完成訊息以後，都還繼續使用伺服器資源進行相應的處理工作，這點上， TimescaleDB 尤為明顯 ——TimescaleDB 在 7x 秒時即反饋客戶端寫入完成，但是其伺服器端仍然再呼叫 CPU 資源進行資料壓縮和整理工作，當然整個工作帶來的 CPU 負載相對而言並不高，只有其峰值 CPU 開銷的一半左右，但是持續時間相當長，接近淨寫入時間的 4 倍。

InfluxDB 則在寫入過程中使用了相當多的 CPU 資源，瞬時峰值甚至使用了全部的 CPU 資源，其寫入負載較高，並且持續時間比 TimescaleDB 更長，當然也遠長於 TDengine 。 三個系統對比，TDengine 對伺服器的 CPU 需求最小，峰值也僅使用了 17% 左右的伺服器 CPU 資源。 由此可見，TDengine 獨特的資料模型不僅體現在時序資料寫入的效能上，在整體的資源開銷上優勢也極為明顯。

磁碟 I/O 對比

寫入過程中伺服器 IO 開銷

 

圖五展示了場景四下資料寫入過程中伺服器端磁碟 IO 趨勢。可以看到，結合著伺服器端 CPU 的開銷表現，三大系統的 IO 動作與 CPU 呈現同步的活躍狀態。 寫入相同規模的資料集下，TDengine 在寫入過程中對於磁碟寫入能力的佔用遠小於 TimescaleDB 和 InfluxDB ，寫入過程只佔用了部分磁碟寫入能力（ 125MiB/Sec. 3000IOPS ） 。從圖上能看到，資料寫入過程中磁碟的 IO 瓶頸是確實存在的 ——InfluxDB 執行中有相當長一段時間將全部的磁碟寫入能力消耗殆盡， TimescaleDB 對於寫入能力的消耗相對 InfluxDB 來說要更具優勢，但是仍然遠超過了 TDengine 。

客戶端 CPU 開銷

寫入過程中客戶端 CPU 開銷

 

從上圖可以看到，三個系統在伺服器確認寫入完成以後客戶端均不再有 CPU 開銷。客戶端上 TDengine 對 CPU 的需求大於 TimescaleDB 和 InfluxDB ，而 InfluxDB 在整個寫入過程中，客戶端負載整體上來說是三個系統中計算資源佔用最低的，對客戶端壓力也是三者中最小的， 其寫入的壓力基本上完全集中在服務端，這種模式很容易導致服務端發生瓶頸。

再看 TimescaleDB ，對於客戶端壓力比 InfluxDB 要更大， CPU 峰值達到 17% 左右。而 TDengine 在客戶端的開銷最大，峰值瞬間達到了 56% ，然後快速回落。雖然 TDengine 在客戶端的開銷相比於 TimescaleDB 多了 1 倍，但其 寫入持續時間更短，綜合伺服器與客戶端的資源開銷來看，在系統整體 CPU 開銷上 TDengine 仍然具有相當大的優勢。

寫入效能基準評估擴充套件部分

為了更全面地評估 TDengine 在預設引數下的寫入效能，我們在下面的效能評估中對可能會影響寫入效能的多個引數進行了調整，以便開展更全面的評估工作。

虛擬節點（vnodes ）數量

我們調整資料庫中虛擬節點數量（預設是 6 ）為 6 、 8 、 12 、 24 ，並衡量不同 vnode 數量情況下 TDengine 的寫入效能。

不同虛擬節點資料量情況寫入效能變化

 

從上表可以看到，在裝置數最小的場景一中，隨著虛擬節點數的增加，寫入變化趨勢不明顯。在較多裝置的場景（場景五）中，增加 vnodes 的數量 ，寫入效能獲得了顯著的提升。 可見在不同規模的場景中，透過調整 TDengine 虛擬節點的數量可以獲得更好的寫入效能，大規模場景中尤甚。

fsync 對寫入效能的影響

不同 fsync 配置下寫入效能趨勢

 

我們使用 fsync 引數控制寫入到預寫日誌（ write ahead log, WAL ）檔案中的資料呼叫 fsync 的頻率，以確保資料可靠落盤。一般來說，呼叫 fsync 會消耗較多的 IO 資源，並會對寫入過程造成一定的影響。 但從上表可以看到，fsync 的配置調整對 TDengine 寫入效能影響很小。

在前四個場景中，fsync 配置為實時同步刷入磁碟（ fsync 為 0 ）的情況下，寫入效能並沒有出現顯著降低。這是由於寫入過程採用了大批次的寫入模式，降低了每次刷入磁碟的次數需求，所以對效能影響並不明顯，反之寫入效能將降低。因此，我們可以獲得一個資訊，在此種情況下應用 TDengine ， 增加每批次寫入資料量，可以有效緩解 fsync 配置寫入的影響 。

裝置記錄數量

TDengine 的 “ 一個裝置一張表 ” 資料模型使得其在進行資料寫入時要先建立表，建表操作對每個裝置只執行一次，但這會讓 TDengine 在資料寫入的準備階段耗時較多。當單個表中資料量增加以後，資料準備（建表）的開銷會被分攤到資料寫入的整體開銷中，所以應該有更好的資料寫入效能。

以場景四為例，單個裝置的資料量僅有 18 條。當我們調整引數，將單個裝置記錄資料增加到 36 、 72 、 144 條時，整體寫入時間也變得更長，即建表開銷被分攤到更多的資料寫入過程中，建表的開銷相對於資料寫入的耗時佔比越來越小，相應的整體寫入速度也就越來越快。 因此可以看到，隨著裝置記錄數量增加，TDengine 表現出了更加明顯的寫入優勢。

裝置記錄數增加時資料寫入效能對比（數值越大越好）

 

隨後我們調整了 vnodes 的數量配置，並同時測試兩個不同 vnodes 數量情況下的寫入效能指標。如上圖所示，隨著表中記錄數的增加，單表記錄增加到 72 時， TDengine 設定為 6 vnodes 的寫入效能出現了下降，但是在 24 vnodes 的情況下，寫入效能呈現出持續增加的趨勢，並且在全部場景下寫入效能均優於 6 vnodes 的寫入效能。

當裝置記錄數達到 576 行（此時資料集規模為 1,000,000 × 576 = 5.76 億行資料記錄）時，寫入效能達到 6,605,515 metrics/sec. 。在單裝置記錄達到 576 行時， 預設 6 vnodes 配置下 TDengine 寫入效能是 TimescaleDB 和 InfluxDB 的 7 倍多，當設定為 24 vnodes 時，效能更是大幅領先於 TimescaleDB 與 InfluxDB ，最高達到了 TimescaleDB 和 InfluxDB 的 13 倍多。

TimescaleDB 寫入效能在單表記錄數量大於 72 行時就出現了下降趨勢，在單表記錄數 144 行以後出現了快速衰減。 InfluxDB 在單裝置記錄增加過程中，寫入效能有衰減，但衰減趨勢比較緩慢。

寫在最後

由此可見，TDengine 在五個測試場景中，寫入效能均超過了 TimescaleDB 和 InfluxDB 。且在整個寫入過程中， TDengine 不僅提供了更高的寫入能力，還保證了最小的資源消耗，不論是伺服器的 CPU 還是 IO ， TDengine 均遠優於 TimescaleDB 和 InfluxDB 。即使加上客戶端的開銷統計， TDengine 在寫入開銷上也遠優於 TimescaleDB 和 InfluxDB 。

在後面的擴充部分，透過調整不同的引數，以及設定不同的資料規模、調整 fsync 引數等方式，我們在更多的方面評估了 TDengine 在 TSBS 基準資料集上的寫入效能。透過這一系列深入的對比可以看到， 針對更大規模資料集，TDengine 可以透過簡單調整虛擬節點數量的方式獲得更高的寫入效能，並且 TDengine 在針對大資料集寫入場景下展現出了更大的效能優勢。

TDengine 高效的寫入效能在企業實踐中也得到了驗證，此前在機器人骨幹企業拓斯達的工廠整體解決方案專案案例中，就闡述了應用 TDengine 後的改造結果 —— 一個裝置一天最多能寫入近十萬條資料，近千個裝置同時寫入也完全沒有問題，相較於之前，寫入速度提升了數十倍。如果你也面臨著資料處理難題或想要進行資料架構升級，歡迎新增 小T 微信： tdengine1 ，加入 TDengine 使用者交流群，和更多志同道合的開發者一起攻克難關。