云浮市物聯(lián)網研究院有限公司是溫氏系企業(yè)，筠誠裝備管理集團下屬公司，主要為大型養(yǎng)殖業(yè)客戶提供 AIoT 物聯(lián)網服務。為了實現(xiàn)各廠商、各品牌相關環(huán)境控制器、傳感器的數(shù)據接入，聯(lián)合深圳市哇發(fā)科技有限公司，搭建了企業(yè)級的物聯(lián)網中間件平臺，專門負責設備接入、數(shù)據采集。

業(yè)務背景和痛點

在平臺建設前期，并沒有采用時序數(shù)據庫（Time-Series Database），而是采用了阿里云的 MySQL 實現(xiàn)所有傳感器數(shù)據的存儲。在設備接入量突破 6 萬，每日數(shù)據記錄超過 8000 萬條之后，平臺性能急劇下降。

根據項目規(guī)劃，平臺要支持數(shù)十萬設備的接入，之前采用 MySQL 數(shù)據庫分表的方案已經無能為力。有鑒于此，基于物聯(lián)網平臺的特性，規(guī)劃引入時序數(shù)據庫解決物聯(lián)網中間件平臺在數(shù)據的存儲和處理方面的痛點。

為什么選擇 TDengine Database

在養(yǎng)殖物聯(lián)網場景下，數(shù)據量最大的結構化數(shù)據來自于養(yǎng)殖場欄舍的環(huán)境傳感器（溫度、濕度、光照、Co2、Nh3等），還有水表、電表等資源測量傳感器，以及包括風機、水簾、側窗等被控設備的開/關狀態(tài)。

為了監(jiān)控欄舍環(huán)境，需要對來自不同采樣點的同類型傳感器數(shù)據進行計算，并根據實時平均值來判斷是否觸發(fā)環(huán)控告警。

這些需求，歸納起來包括：

• 高并發(fā)數(shù)據寫入，每條記錄都需要帶時間戳；
• 不同傳感器設備需要記錄的數(shù)據字段不同，希望能夠針對不同設備單獨建表；
• 針對同類數(shù)據類型（譬如溫度）的數(shù)據，有按照時間段（譬如 5 分鐘）進行聚合查詢的需求；
• 原始數(shù)據存儲要求在 3 年以上，需要支持數(shù)據壓縮，以降低數(shù)據存儲成本；
• 希望可以支持物聯(lián)網數(shù)據的補錄；
• 中間件平臺屬于生產系統(tǒng)，尤其是環(huán)控告警服務的時效性要求很高，對數(shù)據庫廠商服務響應有一定要求。

按照每秒 2 萬條的數(shù)據庫寫入的場景假設，針對對市面上主流的時序數(shù)據庫，譬如阿里云上的 InfluxDB、以及國內的 TDengine 進行了 POC 驗證。

出于以下幾方面原因，最終選擇了 TDengine Database。

• TDengine 的設計理念（超級表 + 子表）更吻合養(yǎng)殖行業(yè)物聯(lián)網大數(shù)據的需求，更符合我們原來的業(yè)務設計理念，譬如我們把每個物模型對應的產品設置為一個超級表，每個設備就是一個子表。
• 在數(shù)據寫入、聚合函數(shù)計算效率等多個方面，TDengine 高于 InfluxDB。
• 售后服務方面，國產數(shù)據庫廠家先天具有優(yōu)勢。

在選型決定之后，我們對原有業(yè)務系統(tǒng)進行了升級改造，引入了 TDengine。

引入 TDengine 之后的業(yè)務架構

物聯(lián)網中間件平臺以設備為目標，圍繞設備構建物模型。該平臺引入了時序數(shù)據庫 TDengine，實現(xiàn)海量設備數(shù)據的寫入、查詢（聚合函數(shù)），并對所有操作履歷、變更記錄等日志類數(shù)據全部入庫，為上層的應用提供了強大的數(shù)據能力 API，消除了養(yǎng)殖行業(yè)各場景應用對大數(shù)據處理的顧慮。

整體架構如下圖所示。

TDengine 的性能非常出色，下表為我們所做的性能測試。

業(yè)務架構改造完成之后，截至2021年9月，累積接入到物聯(lián)網中間件平臺需要創(chuàng)建子表的對象已經接近20萬，運行半年來，時序庫存儲容量不到200GB，普通查詢響應為 23ms；以單個設備為對象的每5分鐘溫度曲線，響應時間為43ms。

引入TDengine之后，優(yōu)異的查詢性能給我們帶來了很大的驚喜，極高的壓縮效率，也給我們節(jié)省了大量的存儲資源。

未來，我們也會嘗試在更多場景應用TDengine。

關于作者：

黃冬安，深圳市哇發(fā)科技有限公司技術總監(jiān)，長期從事物聯(lián)網大數(shù)據開發(fā)和運維工作，是物聯(lián)網中間件項目的技術負責人。當前主要在支持云浮市物聯(lián)網研究院養(yǎng)殖監(jiān)控場景的大數(shù)據平臺建設工作。