在 OPPO 的穿戴產(chǎn)品的手環(huán)/手表類(lèi)業(yè)務(wù)中，產(chǎn)生的數(shù)據(jù)類(lèi)型為時(shí)序數(shù)據(jù)，具有寫(xiě)入量巨大且存在離線(xiàn)/歷史數(shù)據(jù)補(bǔ)錄（更新）的處理需求。此前使用的 MongoDB/MySQL 集群方案，后端存儲(chǔ)壓力較大，需要經(jīng)常擴(kuò)盤(pán)，針對(duì)此痛點(diǎn)，OPPO 云計(jì)算中心智慧物聯(lián)云團(tuán)隊(duì)嘗試調(diào)研對(duì)比了幾款時(shí)序數(shù)據(jù)庫(kù)（Time-Series Database）產(chǎn)品，試圖尋找一個(gè)降本增效的解決方案。

除了存儲(chǔ)壓力外，我們進(jìn)行數(shù)據(jù)庫(kù)替換還有一個(gè)比較重要的原因，就是 MySQL 和 MongoDB 的各個(gè)集群都比較獨(dú)立，維護(hù)和需求開(kāi)發(fā)成本相對(duì)較高。

以上是三款 Database 的初步調(diào)研結(jié)果，TSHouse 是 OPPO 云監(jiān)控時(shí)序數(shù)據(jù)庫(kù)，其底層為 Prometheus 的 TSDB 存儲(chǔ)引擎，目前不支持歷史數(shù)據(jù)和亂序?qū)懭?；InfluxDB 對(duì)歷史數(shù)據(jù)寫(xiě)入會(huì)進(jìn)行二次壓縮，影響性能，這兩款數(shù)據(jù)庫(kù)都不滿(mǎn)足當(dāng)下的數(shù)據(jù)處理需求。初步研究 TDengine 后，我們發(fā)現(xiàn)其作為國(guó)產(chǎn)時(shí)序數(shù)據(jù)庫(kù)開(kāi)源產(chǎn)品，不僅可以滿(mǎn)足歷史數(shù)據(jù)高效寫(xiě)入，還擁有較高的壓縮能力。隨后，我們選擇對(duì) TDengine 進(jìn)行了比較詳細(xì)的產(chǎn)品調(diào)研和性能測(cè)試。

TDengine 產(chǎn)品與能力調(diào)研

• 產(chǎn)品調(diào)研

某個(gè)數(shù)據(jù)表的結(jié)構(gòu)如下：

我們寫(xiě)入 60 萬(wàn)行數(shù)據(jù)，到 MySQL（目前部分業(yè)務(wù)部署在 MySQL 集群）和 TDengine 的 4C 12G 容器上，對(duì) CPU/內(nèi)存/磁盤(pán)進(jìn)行觀(guān)察。測(cè)試發(fā)現(xiàn) CPU 和內(nèi)存消耗基本持平的情況下，TDengine 的落盤(pán)數(shù)據(jù)是 MySQL 環(huán)境的1/4左右。

同時(shí)，我們?cè)诓煌?guī)格容器及物理機(jī)場(chǎng)景下進(jìn)行 TDengine 寫(xiě)入測(cè)試，部分記錄如下：

需要說(shuō)明的是，對(duì)于不同業(yè)務(wù)場(chǎng)景需要進(jìn)行實(shí)際測(cè)試，才能確定適合該業(yè)務(wù)的部署參數(shù)。在整個(gè)測(cè)試過(guò)程中，TDengine 工程師們也為我們進(jìn)行了及時(shí)答疑和幫助。

• 能力調(diào)研

隨后我們根據(jù) TDengine 豐富的產(chǎn)品手冊(cè)，對(duì)一些關(guān)鍵能力進(jìn)行了驗(yàn)證，包括數(shù)據(jù)管理、數(shù)據(jù)寫(xiě)入、聚合計(jì)算、集群擴(kuò)容、故障可靠性保證等場(chǎng)景。

在數(shù)據(jù)管理上，TDengine 的元數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)是分離開(kāi)來(lái)的。如下圖所示，Mnode 負(fù)責(zé)管理元數(shù)據(jù)信息；單個(gè) Vnode 可以存放多個(gè)表數(shù)據(jù)，相當(dāng)于相當(dāng)于水平分片，單個(gè)表的數(shù)據(jù)，又可以繼續(xù)按照日期分片。

在數(shù)據(jù)寫(xiě)入邏輯上，整體和 LSM 類(lèi)似：WAL，內(nèi)存塊，磁盤(pán) FILE。

在 TDengine 中，數(shù)據(jù)在文件中是按塊連續(xù)存儲(chǔ)的。每個(gè)數(shù)據(jù)塊只包含一張表的數(shù)據(jù)，且數(shù)據(jù)是按照時(shí)間主鍵遞增排列的。數(shù)據(jù)在數(shù)據(jù)塊中按列存儲(chǔ)，這樣使得同類(lèi)型的數(shù)據(jù)能夠存放在一起，大大提高了壓縮比，節(jié)省了存儲(chǔ)空間。

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

TDengine落地實(shí)踐

在經(jīng)歷了比較充分調(diào)研后，我們根據(jù)業(yè)務(wù)寫(xiě)入模型，對(duì)生產(chǎn)環(huán)境中某一套 MySQL 集群環(huán)境，進(jìn)行 TDengine 集群部署，搭建了如下所示的集群：

集群為 3 臺(tái) AWS-EC2 容器（8C 32GB 3.5TB NVME 盤(pán)）組成，配置為 3 節(jié)點(diǎn)、2 副本，寫(xiě)入端使用 RESTful 請(qǐng)求到 VIP 節(jié)點(diǎn)，轉(zhuǎn)發(fā)到數(shù)據(jù)庫(kù)服務(wù)。圖中的 V0-V2 為副本數(shù)為 2 的 3 組數(shù)據(jù)分片，M0-M2 為副本數(shù)為 3 的 1 組管理節(jié)點(diǎn)。

配置的 Grafana 面板展示如下：

后臺(tái)表結(jié)構(gòu)展示如下：

目前數(shù)據(jù)已經(jīng)開(kāi)始接入 TDengine 的數(shù)據(jù)庫(kù)，歷史數(shù)據(jù)也在同步導(dǎo)入中。

• 實(shí)際效果展示

1. 使用 last_row() 函數(shù)一次性輸出 38 萬(wàn)個(gè)設(shè)備查詢(xún)最新?tīng)顟B(tài)，結(jié)果如下所示。

2. 使用 interval() 查詢(xún)某個(gè)設(shè)備每 1 小時(shí)的總步數(shù)，結(jié)果如下所示。

在存儲(chǔ)方面，由于目前數(shù)據(jù)還沒(méi)有完全導(dǎo)入，針對(duì)生產(chǎn)環(huán)境的一個(gè) 6.6TB 集群，我們粗略估計(jì)了一下前后的壓縮比，大概在 6.6/0.4。

在我們?cè)瓉?lái)的集群中是沒(méi)有副本的，單純就部署了 MySQL 的 5 個(gè)分庫(kù)，使用了 4C 8GB 2TB 的 5 臺(tái)機(jī)器，在應(yīng)用 TDengine 之后，現(xiàn)在是 8C 32GB 2TB 的 3 臺(tái)機(jī)器。通過(guò) TDengine 我們構(gòu)建了多副本和統(tǒng)一的能力，以及后續(xù)上混合云的能力，這是整個(gè)平臺(tái)級(jí)的一個(gè)優(yōu)化與提升。

寫(xiě)在最后

在前期調(diào)研和集群搭建過(guò)程中，TDengine Database 的工程師伙伴們給我們提供了充分且及時(shí)的協(xié)助，為我們構(gòu)建時(shí)序數(shù)據(jù)后端能力提供了很大幫助。目前接入TDengine的數(shù)據(jù)是海外某集群，后續(xù)我們會(huì)根據(jù)業(yè)務(wù)進(jìn)展陸續(xù)進(jìn)行其他集群數(shù)據(jù)的接入。