保證高效寫入查詢的情況下，如何實現 CPU 資源和磁碟 IO 的最低開銷？

從 《寫入效能：TDengine 最高達到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查詢 效能：TDengine 最高達到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》兩篇文章中，我們發現，TDengine 不僅在寫入和查詢效能上超越了 InfluxDB 和 TimescaleDB，在資料處理過程的資源消耗也比兩大時序資料庫要更低。本篇文章將會從 TDengine 的產品設計角度出發，為感興趣的小夥伴分析一下 TDengine 效能強消耗低的原因。

為什麼 TDengine 的“寫入強，開銷低”？

“客戶端上 TDengine 對 CPU 的需求大於 TimescaleDB 和 InfluxDB， 而 InfluxDB 的寫入壓力基本上完全集中在服務端，這種模式很容易導致服務端成為瓶頸。TDengine 在客戶端的開銷最大，峰值瞬間達到了 56%，然後快速回落。綜合伺服器與客戶端的資源開銷來看，TDengine 寫入持續時間更短，在系統整體 CPU 開銷上 TDengine 仍然具有相當大的優勢。”

在 TSBS 測試報告全部的 cpu-only 五個場景中，TDengine 寫入效能均優於 TimescaleDB 和 InfluxDB。相對於 TimescaleDB，TDengine 寫入速度最領先的場景是其 6.7 倍（場景二），最少也是 1.5 倍（場景五），而且對於場景四，如果將每個採集點的記錄條數由 18 條增加到 576 條，TDengine 寫入速度是 TimescaleDB 的 13.2 倍。相對於 InfluxDB，TDengine 寫入速度最領先的場景是其 10.6 倍（場景五），最少也是 3.0 倍（場景一)。此外，在保證高效寫入的情況下，TDengine 在寫入過程中消耗的 CPU 資源和磁碟 IO 開銷也是最少的。

寫入過程中客戶端 CPU 開銷

透過上圖可以看到，從客戶端負載來說，三個系統中 InfluxDB 計算資源佔用最低，對客戶端壓力最小，但這並不能說明 InfluxDB 是三個資料庫當中 CPU 開銷最低的，因為其寫入壓力基本完全集中在了服務端，而這種模式也為 InfluxDB 埋下了一個隱患， 如果寫入的資料規模過大，寫入執行緒會長時間地大量消耗伺服器的計算和磁碟IO資源。

與 InfluxDB 相反，TDengine 在客戶端的開銷最大，峰值直接衝到了 56%，其在客戶端的開銷比 TimescaleDB 都多了 1 倍，但在用時上，卻比 InfluxDB 和 TimescaleDB 都小。也因此，從系統整體的 CPU 開銷來看，TDengine 的優勢仍舊非常顯著。

基於產品特點，我們可以從兩個方面分析這種“高寫入，低開銷”的特點。首先，為充分利用資料的時序性等特點，TDengine 採取了“一個資料採集點一張表”的策略，要求對每個資料採集點單獨建表（比如有一千萬個智慧電錶，就需建立一千萬張表），用來儲存這個資料採集點所採集的時序資料。 這種設計對於提升寫入效能來說主要表現在兩個方面：

1. 由於不同資料採集點產生資料的過程完全獨立，每個資料採集點的資料來源是獨一無二 的，一張表也就只有一個寫入者，這樣就可採用無鎖方式來寫，寫入速度就能大幅提升。
2. 對於一個資料採集點而言，其產生的資料是按照時間排序的，因此寫的操作可用追加的方式實現，進一步大幅提高資料寫入速度。

其次，因為 TDengine 的 SQL 解析是在客戶端完成的，這樣一來，其在整個寫入過程中，主要的負載都集中在客戶端，伺服器端承擔的壓力就會變得非常小。我們之所以將寫入的負載轉移到客戶端，其原因是客戶應用端的伸縮和擴充套件操作非常地便捷容易，可操作性更強—— 在保障伺服器有剩餘能力的情況下，如果寫入效能不夠，只要增加寫入程式或寫入客戶端即可解決此問題，不再需要增加伺服器的裝置了。

試想一下，如果不需要變更伺服器數量，那也就不會涉及到叢集的伸縮操作、資源負載均衡等複雜邏輯，整體的寫入成本自然就會顯著降低。

除了客戶端 CPU 開銷外，三個系統對比，TDengine 對伺服器的 CPU 需求也是最小的，峰值僅使用了 17% 左右的伺服器 CPU 資源。在磁碟寫入能力的消耗上，InfluxDB 長時間消耗完全部的磁碟寫入能力，TimescaleDB 寫入過程對於寫入的消耗相對 InfluxDB 來說要更具優勢，但是仍然遠超 TDengine 對磁碟寫入能力的需求。

如何用最小的計算開銷實現最高的查詢效能？

“從整體 CPU 開銷上來看，TDengine 不僅完成全部查詢的時間低於 TimescaleDB 和 InfluxDB，在整體上CPU計算資源的消耗也遠小於 TimescaleDB 和 InfluxDB。在整個查詢過程中，TDengine 記憶體也始終維持在一個相對平穩的狀態。”

基於 TSBS 測試報告我們可以總結出，查詢方面，在場景一（只包含 4 天的資料）與場景二的 15 個不同型別的查詢中，TDengine 的查詢平均響應時間全面優於 InfluxDB 和 TimescaleDB，而且在複雜查詢上優勢更為明顯，同時具有最小的計算資源開銷。相比 InfluxDB，場景一中 TDengine 查詢效能是其 1.9 ～ 37.0 倍，場景二中 TDengine 查詢效能是其 1.8 ～ 34.2 倍；相比 TimescaleDB，場景一中 TDengine 查詢效能是其 1.1 ～ 28.6 倍，場景二中 TDengine 查詢效能是其 1.2 ～ 24.6 倍。

查詢過程中伺服器 CPU 開銷

在資源開銷上，TDengine 在查詢過程中整體 CPU 佔用約 80%，是三個系統中最高的，TimescaleDB 在查詢過程中瞬時 CPU 佔用次之，InfluxDB 的穩定 CPU 佔用最小（但是有較多的瞬時衝高）。從整體 CPU 開銷上來看，雖然 InfluxDB 瞬時 CPU 開銷大部分是最低的，但是其完成查詢持續時間最長，所以整體 CPU 資源消耗最多。由於 TDengine 完成全部查詢的時間僅為 TimescaleDB 或 InfluxDB 的 1/20，雖然 CPU 穩定值是 TimescaleDB 與 InfluxDB 的 2 倍多，但整體的 CPU 計算時間消耗只有其 1/10 。

用最小的計算開銷實現最高的查詢效能，TDengine 是如何做到的呢？首先，TDengine 對每個資料採集點單獨建表，但在實際應用中經常需要對不同的採集點資料進行聚合。為高效的進行聚合操作，TDengine 引入超級表（STable）的概念。超級表用來代表一特定型別的資料採集點，它是包含多張表的表集合，集合裡每張表的模式（schema）完全一致，但每張表都帶有自己的靜態標籤，標籤可以有多個，可以隨時增加、刪除和修改。應用可透過指定標籤的過濾條件，對一個 STable 下的全部或部分表進行聚合或統計操作，這樣就大大簡化了應用的開發。其具體流程如下圖所示：

由於 TDengine 在 vnode 內將標籤資料與時序資料分離儲存，透過在記憶體裡過濾標籤資料，就可以先找到需要參與聚合操作的表的集合，這樣需要掃描的資料集就會變得大幅減少，聚合計算速度自然就會獲得顯著提升。同時，由於資料分佈在多個 vnode/dnode，聚合計算操作在多個 vnode 裡併發進行，這又進一步提升了聚合的速度。

其次，在單表查詢上，當我們要對全部資料集進行查詢時，就需要將查詢請求廣播到所有的節點。 試想一下，當我們在業務場景中需要對某個裝置進行查詢，這時如果可以不使用標籤過濾，直接查詢對應的裝置，查詢效率是不是變得更高了，TDengine 便是如此。在本次測試報告中就有幾個這樣的場景，TDengine 都表現出了很好的查詢效能。

此外，為有效提升查詢處理的效能，針對物聯網資料不可更改的特點，TDengine 會在資料塊頭部記錄該資料塊中儲存資料的統計資訊：包括最大值、最小值、和，我們稱之為預計算單元。如果查詢處理涉及整個資料塊的全部資料，就可以直接使用預計算結果，完全不需要讀取資料塊的內容。由於預計算資料量遠小於磁碟上儲存的資料塊資料的大小，對於磁碟 I/O 為瓶頸的查詢處理，使用預計算結果可以極大地減小讀取 I/O 壓力，加速查詢處理的流程。預計算機制與 PostgreSQL 的索引 BRIN（block range index）有異曲同工之妙。

多選項壓縮比實現儲存成本的大程度降低

“磁碟空間佔用方面，TimescaleDB 在所有五個場景下的資料規模均顯著大於 InfluxDB 和 TDengine，並且這種差距隨著資料規模增加快速變大。TimescaleDB 在場景四和場景五中佔用磁碟空間是 TDengine 的 25.6 倍和 26.9 倍。在前面三個場景中，InfluxDB 落盤後資料檔案規模與 TDengine 非常接近，但是在大資料規模的場景四和場景五中，InfluxDB 落盤後檔案佔用的磁碟空間是 TDengine 的 4.2 倍和 4.5 倍。”

當資料寫入磁碟時，TDengine 會根據系統配置引數 comp 決定是否壓縮資料。TDengine 共提供了三種壓縮選項：無壓縮、一階段壓縮和兩階段壓縮，分別對應 comp 值為 0、1 和 2 的情況。一階段壓縮根據資料的型別進行了相應的壓縮，壓縮演算法包括 delta-delta 編碼、simple 8B 方法、zig-zag 編碼、LZ4 等演算法。二階段壓縮在一階段壓縮的基礎上又用通用壓縮演算法進行了壓縮，壓縮率更高。

同時， TDengine 採用的是標籤分離儲存機制，即標籤與資料是分開進行儲存的，這樣就帶來了兩個方面的好處：

1. 在儲存操作上佔用更小的磁碟空間，表級別的標籤基本上沒有冗餘。
2. 標籤集中儲存更有利於標籤過濾操作中 IO 訪問的區域性性，標籤過濾完成得更快，查詢效能也會變得更好。

此外，對於 TDengine 來說，每個資料塊內部採用的就是列式儲存模式，而且打造了“一個資料採集點一張表”的創新設計，一個資料採集點採集量的變化肯定比多個採集點的採集量變化更慢，壓縮率自然也會變得更高。 綜合上述的幾點設計，TDengine 在進行資料處理時提供了很好的壓縮比，幫使用者節約了儲存空間和儲存資源，極大程度上減少了儲存成本浪費。

寫在最後

在產品開發之初，TDengine 就明確了設計方向，即針對時序資料的特點對寫入、儲存、查詢等流程進行設計和最佳化，在經過幾個版本的不斷迭代加強後，其儲存量大、儲存運維成本低、讀寫效能卓越、壓縮率高等特點越發顯著。這些優勢也體現在企業的具體實踐上，以 為例，TDengine 幫助其 SIMICAS® OEM 2.0 版本移除了 Flink、Kafka 以及 Redis，大大簡化了系統架構，節約了運維成本；而在 中，TDengine 高壓縮演算法助力其壓縮效能提升了10-20 倍，降低儲存壓力的同時也解決了資料儲存成本高的問題。

如果你也面臨著效能和成本難以兩全的資料處理難題，亟需升級資料架構，歡迎新增 小T vx：tdengine1，加入 TDengine 使用者交流群，和更多志同道合的開發者一起攻克難關。