在 OPPO 的穿戴產品的手環/手表類業務中，產生的數據類型為時序數據，具有寫入量巨大且存在離線/歷史數據補錄（更新）的處理需求。此前使用的 MongoDB/MySQL 集群方案，后端存儲壓力較大，需要經常擴盤，針對此痛點，OPPO 云計算中心智慧物聯云團隊嘗試調研對比了幾款時序數據庫（Time-Series Database）產品，試圖尋找一個降本增效的解決方案。

除了存儲壓力外，我們進行數據庫替換還有一個比較重要的原因，就是 MySQL 和 MongoDB 的各個集群都比較獨立，維護和需求開發成本相對較高。

以上是三款 Database 的初步調研結果，TSHouse 是 OPPO 云監控時序數據庫，其底層為 Prometheus 的 TSDB 存儲引擎，目前不支持歷史數據和亂序寫入；InfluxDB 對歷史數據寫入會進行二次壓縮，影響性能，這兩款數據庫都不滿足當下的數據處理需求。初步研究 TDengine 后，我們發現其作為國產時序數據庫開源產品，不僅可以滿足歷史數據高效寫入，還擁有較高的壓縮能力。隨后，我們選擇對 TDengine 進行了比較詳細的產品調研和性能測試。

TDengine 產品與能力調研

某個數據表的結構如下：

我們寫入 60 萬行數據，到 MySQL（目前部分業務部署在 MySQL 集群）和 TDengine 的 4C 12G 容器上，對 CPU/內存/磁盤進行觀察。測試發現 CPU 和內存消耗基本持平的情況下，TDengine 的落盤數據是 MySQL 環境的1/4左右。

同時，我們在不同規格容器及物理機場景下進行 TDengine 寫入測試，部分記錄如下：

需要說明的是，對于不同業務場景需要進行實際測試，才能確定適合該業務的部署參數。在整個測試過程中，TDengine 工程師們也為我們進行了及時答疑和幫助。

隨后我們根據 TDengine 豐富的產品手冊，對一些關鍵能力進行了驗證，包括數據管理、數據寫入、聚合計算、集群擴容、故障可靠性保證等場景。

在數據管理上，TDengine 的元數據與業務數據是分離開來的。如下圖所示，Mnode 負責管理元數據信息；單個 Vnode 可以存放多個表數據，相當于相當于水平分片，單個表的數據，又可以繼續按照日期分片。

在數據寫入邏輯上，整體和 LSM 類似：WAL，內存塊，磁盤 FILE。

在 TDengine 中，數據在文件中是按塊連續存儲的。每個數據塊只包含一張表的數據，且數據是按照時間主鍵遞增排列的。數據在數據塊中按列存儲，這樣使得同類型的數據能夠存放在一起，大大提高了壓縮比，節省了存儲空間。

TDengine 是 10 天一組 data file，data file 里的 .data 文件只進行追加，且后續不會進行壓縮。這種好處是：對歷史數據和亂序極其友好，非常適用于 IoT 場景；沒有壓縮也就減少了寫入之后的資源消耗，保證了較好的讀寫性能。

TDengine落地實踐

在經歷了比較充分調研后，我們根據業務寫入模型，對生產環境中某一套 MySQL 集群環境，進行 TDengine 集群部署，搭建了如下所示的集群：

集群為 3 臺 AWS-EC2 容器（8C 32GB 3.5TB NVME 盤）組成，配置為 3 節點、2 副本，寫入端使用 RESTful 請求到 VIP 節點，轉發到數據庫服務。圖中的 V0-V2 為副本數為 2 的 3 組數據分片，M0-M2 為副本數為 3 的 1 組管理節點。

配置的 Grafana 面板展示如下：

后臺表結構展示如下：

目前數據已經開始接入 TDengine 的數據庫，歷史數據也在同步導入中。

1.使用 last_row() 函數一次性輸出 38 萬個設備查詢最新狀態，結果如下所示。

2.使用 interval() 查詢某個設備每 1 小時的總步數，結果如下所示。

在存儲方面，由于目前數據還沒有完全導入，針對生產環境的一個 6.6TB 集群，我們粗略估計了一下前后的壓縮比，大概在 6.6/0.4。

在我們原來的集群中是沒有副本的，單純就部署了 MySQL 的 5 個分庫，使用了 4C 8GB 2TB 的 5 臺機器，在應用 TDengine 之后，現在是 8C 32GB 2TB 的 3 臺機器。通過 TDengine 我們構建了多副本和統一的能力，以及后續上混合云的能力，這是整個平臺級的一個優化與提升。

寫在最后

在前期調研和集群搭建過程中，TDengine Database 的工程師伙伴們給我們提供了充分且及時的協助，為我們構建時序數據后端能力提供了很大幫助。目前接入TDengine的數據是海外某集群，后續我們會根據業務進展陸續進行其他集群數據的接入。

責任編輯：Rex_08