在 OPPO 的穿戴產品的手環/手表類業務中，產生的數據類型為時序數據，具有寫入量巨大且存在離線/歷史數據補錄（更新）的處理需求。此前使用的 MongoDB/MySQL 集群方案，后端存儲壓力較大，需要經常擴盤，針對此痛點，OPPO 云計算中心智慧物聯云團隊嘗試調研對比了幾款時序數據庫（Time-Series Database）產(chan)品，試圖尋找一個降本增效(xiao)的(de)解(jie)決方案。
除了存儲壓力(li)外，我們進(jin)行(xing)數據庫替換還有一個比較重要的原因，就是 MySQL 和(he)(he) MongoDB 的各個集群都比較獨立，維護和(he)(he)需(xu)求開發(fa)成本相(xiang)對(dui)較高。
以上是三款 Database 的初步調研結果，TSHouse 是 OPPO 云監控時序數據庫，其底層為 Prometheus 的 TSDB 存(cun)儲引(yin)擎(qing)，目前不(bu)支(zhi)持歷(li)史數(shu)據(ju)和亂序(xu)寫入；InfluxDB 對歷(li)史數(shu)據(ju)寫入會進行(xing)二次壓縮(suo)，影響(xiang)性(xing)能，這兩款數(shu)據(ju)庫(ku)都(dou)不(bu)滿足當下的數(shu)據(ju)處理需求。初步研究(jiu) TDengine 后，我們發現其作為(wei)國產時序(xu)數(shu)據(ju)庫(ku)開源(yuan)產品(pin)，不(bu)僅(jin)可(ke)以滿足歷(li)史數(shu)據(ju)高(gao)效寫入，還擁有(you)較高(gao)的壓縮(suo)能力。隨后，我們選擇對 TDengine 進行(xing)了比較詳細的產品(pin)調研和性(xing)能測(ce)試(shi)。
TDengine 產品與能力調研
- 產品調研
某個數據表的(de)結構如下(xia)：
我們寫入 60 萬行數據，到 MySQL（目前部分業務部署在 MySQL 集群）和 TDengine 的 4C 12G 容器上，對 CPU/內存/磁盤進行觀察。測試發現 CPU 和內存消耗基本持平的情況下，TDengine 的落盤數據是 MySQL 環境的1/4左右。
同時，我們在(zai)不同規(gui)格容(rong)器及物(wu)理機(ji)場景下進(jin)行 TDengine 寫入測試，部分記錄如下：
需(xu)要說(shuo)明的(de)是，對于不同業務(wu)場景需(xu)要進行(xing)實際測(ce)試(shi)，才能確定適合該業務(wu)的(de)部署參數。在整個測(ce)試(shi)過(guo)程(cheng)中，TDengine 工程(cheng)師們也為我們進行(xing)了及時答疑和幫助。
- 能力調研
隨后我(wo)們根據(ju)(ju) TDengine 豐富的產(chan)品手冊，對一些關(guan)鍵(jian)能力進行(xing)了驗(yan)證，包括(kuo)數據(ju)(ju)管理、數據(ju)(ju)寫入、聚合計(ji)算(suan)、集群擴容、故障(zhang)可靠(kao)性保證等場景(jing)。
在數(shu)(shu)據(ju)管理上(shang)，TDengine 的(de)元數(shu)(shu)據(ju)與業務數(shu)(shu)據(ju)是(shi)分(fen)離(li)開來(lai)的(de)。如下圖所示，Mnode 負責(ze)管理元數(shu)(shu)據(ju)信息；單個 Vnode 可以存放多個表(biao)數(shu)(shu)據(ju)，相(xiang)當(dang)于(yu)相(xiang)當(dang)于(yu)水平分(fen)片(pian)，單個表(biao)的(de)數(shu)(shu)據(ju)，又可以繼續按(an)照日期(qi)分(fen)片(pian)。
在(zai)數據寫入邏輯上，整體和 LSM 類似：WAL，內(nei)存(cun)塊，磁盤(pan) FILE。
在(zai)(zai) TDengine 中，數(shu)(shu)據在(zai)(zai)文件(jian)中是(shi)按塊(kuai)(kuai)連(lian)續存(cun)(cun)儲(chu)的。每個(ge)數(shu)(shu)據塊(kuai)(kuai)只包含一(yi)張表(biao)的數(shu)(shu)據，且數(shu)(shu)據是(shi)按照時間主鍵遞增排列的。數(shu)(shu)據在(zai)(zai)數(shu)(shu)據塊(kuai)(kuai)中按列存(cun)(cun)儲(chu)，這(zhe)樣使得(de)同類(lei)型的數(shu)(shu)據能夠存(cun)(cun)放(fang)在(zai)(zai)一(yi)起，大大提高了壓縮比，節省了存(cun)(cun)儲(chu)空間。
TDengine 是(shi) 10 天一(yi)組 data file，data file 里的(de)(de) .data 文件(jian)只進行(xing)追加，且后(hou)續不會(hui)進行(xing)壓縮。這種好(hao)處是(shi)：對歷(li)史數據和亂序極(ji)其友好(hao)，非(fei)常適用(yong)于 IoT 場景；沒有壓縮也就減(jian)少了寫入之后(hou)的(de)(de)資(zi)源消(xiao)耗，保證了較好(hao)的(de)(de)讀寫性能。
TDengine落地實踐
在經(jing)歷(li)了比較充分調研后，我們根(gen)據業務寫入模型，對(dui)生產(chan)環(huan)境中某一套 MySQL 集群(qun)(qun)環(huan)境，進行 TDengine 集群(qun)(qun)部署，搭建了如下(xia)所示的集群(qun)(qun)：
集群為(wei)(wei)(wei) 3 臺 AWS-EC2 容器（8C 32GB 3.5TB NVME 盤）組(zu)成，配置(zhi)為(wei)(wei)(wei) 3 節(jie)點、2 副(fu)本，寫(xie)入端使(shi)用 RESTful 請求到 VIP 節(jie)點，轉發(fa)到數(shu)據(ju)庫服務(wu)。圖中的 V0-V2 為(wei)(wei)(wei)副(fu)本數(shu)為(wei)(wei)(wei) 2 的 3 組(zu)數(shu)據(ju)分片，M0-M2 為(wei)(wei)(wei)副(fu)本數(shu)為(wei)(wei)(wei) 3 的 1 組(zu)管理節(jie)點。
配置的 Grafana 面(mian)板展示如(ru)下：
后臺表(biao)結構展示如下：
目前數據已經開始接(jie)入(ru)(ru) TDengine 的數據庫，歷史數據也在(zai)同(tong)步導入(ru)(ru)中。
- 實際效果展示
- 使用 last_row() 函數一次性輸出 38 萬個設備查詢最新狀態，結果如下所示。
- 使用 interval() 查詢某個設備每 1 小時的總步數，結果如下所示。
在存儲方面，由于目前數據還沒有完全導入，針對生產環境的一個 6.6TB 集群，我們粗略估計了一下前后的壓縮比，大概在 6.6/0.4。
在(zai)我們原來的(de)(de)集群中(zhong)是(shi)(shi)沒有副本(ben)的(de)(de)，單純就(jiu)部署(shu)了 MySQL 的(de)(de) 5 個分庫，使用(yong)了 4C 8GB 2TB 的(de)(de) 5 臺(tai)機器，在(zai)應(ying)用(yong) TDengine 之后(hou)，現在(zai)是(shi)(shi) 8C 32GB 2TB 的(de)(de) 3 臺(tai)機器。通過 TDengine 我們構建了多副本(ben)和統一的(de)(de)能力，以(yi)及后(hou)續上混合云(yun)的(de)(de)能力，這是(shi)(shi)整個平臺(tai)級的(de)(de)一個優化與提升。
寫在最后
在前期調研和集群搭建過程中，TDengine Database 的工程師伙伴們給我們提供了充分且及時的協助，為我們構建時序數據后端能力提供了很大幫助。目前接入TDengine的數據是海外某集群，后續我們會根據業務進展陸續進行其他集群數據的接入。
