上周三，TDengine 正式發布了基于 TSBS 的時序數據庫（Time Series Database，TSDB）性能基準測試報告，該報告采用 TSBS 平臺中針對 DevOps 的場景作為基礎數據集，在相同的 AWS 云環境下對 TDengine 3.0、TimescaleDB 2.6 和 InfluxDB 1.8 進行了對比分析。為了便于大家更好地閱讀和理解，基于報告內容，我們將從寫入、查詢及測試過程如何復現等幾大維度輸出系列文章。本篇文章將為大家解讀三大時序數據庫在寫入性能上的差異點。
在《TSBS 是什么？為什么 TDengine 會選擇它作為性能對比測試平臺？》一文中，我們對測試場景和基本配置已經進行了詳細介紹，本篇文章便不再贅述，還沒有了解過的小伙伴可以點擊上文鏈接查看。
五大場景下，TDengine 寫入性能實現全面超越
如上圖所示，我們可以看到在全部五個場景中，TDengine 的寫入性能全面超越了 TimescaleDB 和 InfluxDB。在場景二中 TDengine 寫入性能最高達到了 TimescaleDB 的 6.74 倍，在差距最小的場景五中，TDengine 也是 TimescaleDB 的 1.52 倍。相比 InfluxDB，TDengine 在場景五中寫入性能達到 InfluxDB 的 10.63 倍，在差距最小的場景一中也有 3.01 倍，具體的倍率關系請參見下表。
此外，我們還注意到，隨著設備數規模的增加，所有系統寫入基本上呈現下降趨勢。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 負載狀況，在圖中我們使用虛線標識出了服務端給客戶端確認寫入完成的時刻。可以看到，三個系統在返回給客戶端寫入完成消息以后，都還繼續使用服務器資源進行相應的處理工作，這點上，TimescaleDB 尤為明顯——TimescaleDB 在 7x 秒時即反饋客戶端寫入完成，但是其服務器端仍然再調用 CPU 資源進行數據壓縮和整理工作，當然整個工作帶來的 CPU 負載相對而言并不高，只有其峰值 CPU 開銷的一半左右，但是持續時間相當長，接近凈寫入時間的 4 倍。
InfluxDB 則在寫入過程中使用了相當多的 CPU 資源，瞬時峰值甚至使用了全部的 CPU 資源，其寫入負載較高，并且持續時間比 TimescaleDB 更長，當然也遠長于 TDengine。三個系統對比，TDengine 對服務器的 CPU 需求最小，峰值也僅使用了 17% 左右的服務器 CPU 資源。由此可見，TDengine 獨特的數據模型不僅體現在時序數據寫入的性能上，在整體的資源開銷上優勢也極為明顯。
磁盤 I/O 對比
圖五展示了場景四下數據寫入過程中服務器端磁盤 IO 趨勢。可以看到，結合著服務器端 CPU 的開銷表現，三大系統的 IO 動作與 CPU 呈現同步的活躍狀態。寫入相同規模的數據集下，TDengine 在寫入過程中對于磁盤寫入能力的占用遠小于 TimescaleDB 和 InfluxDB，寫入過程只占用了部分磁盤寫入能力（125MiB/Sec. 3000IOPS）。從圖上能看到，數據寫入過程中磁盤的 IO 瓶頸是確實存在的——InfluxDB 運行中有相當長一段時間將全部的磁盤寫入能力消耗殆盡，TimescaleDB 對于寫入能力的消耗相對 InfluxDB 來說要更具優勢，但是仍然遠超過了 TDengine。
客戶端 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 參數控制寫入到預寫日志（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 用戶交流群，和更多志同道合的開發者一起攻克難關。
