小 T 導讀：在 2021 樓宇科技 TRUE 大會上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺 iBuilding，以“軟驅硬核”方式賦能建筑行業(yè)。作為一個全新的項目，iBuilding 在數(shù)據庫選型上比較謹慎，分別對比了多款 Database 產品之后，才做出了自己的選擇。本文分享了他們的數(shù)據庫選型思考和落地經驗。

政策背景

根據 2021 年 12 月由美控智慧建筑聯(lián)合億歐智庫共同發(fā)布的《中國樓宇自控白皮書》，2021 年中國樓宇智能化市場產值約達 7238.2 億元，結合近幾年行業(yè)的發(fā)展趨勢，經過初步估算，2016-2021 年中國樓宇智能化市場規(guī)模逐年上升，存量規(guī)模接近 5000 億元，新增規(guī)模超過 2200 億元。

因樓宇智能化在低碳、節(jié)能方面優(yōu)勢突出，同時能為人們的生活帶來更多舒適體驗，加之政府對樓宇智能化建設規(guī)范化、科學化的引導，未來樓宇智能化將有非常好的發(fā)展前景。從目標來看，樓宇智能化符合建筑行業(yè)對數(shù)字化和智能化的發(fā)展需求，未來將繼續(xù)助力中國建筑行業(yè)轉型升級，以順應國家對節(jié)能減排和數(shù)字經濟的要求。

業(yè)務介紹

隨著 5G 時代的到來，美的一方面在繼續(xù)打造工業(yè)互聯(lián)網產品，另一方面也在不斷進行科技賦能，研發(fā)更加綠色環(huán)保的集成方案，為工業(yè)及制造業(yè)提供全新的思路。

作為美的集團旗下的五大業(yè)務板塊之一，美的暖通與樓宇事業(yè)部確立了“暖通及樓宇智慧生態(tài)集成解決方案引領者”的發(fā)展愿景，旨在用智慧集成的行業(yè)解決方案滿足復雜的建筑需求，目前主要涉足中央空調、電梯、樓宇控制等領域。在 2021 樓宇科技 TRUE 大會上，美的暖通與樓宇事業(yè)部首次發(fā)布了數(shù)字化平臺 iBuilding，以“軟驅硬核”方式賦能建筑行業(yè)。

作為一個全新的項目，我們分別對比了關系型數(shù)據庫（Relational Database）以及主流的時序數(shù)據庫（Time Series Database），包括 InfluxDB、TDengine、MySQL 等。對比關系型數(shù)據庫 MySQL 來說，在這個場景下，我們不需要復雜的查詢，卻需要高效的存儲和大范圍時間的數(shù)據拉取。和同為時序數(shù)據庫的 InfluxDB 對比，TDengine 的單機版性能遠好于 InfluxDB。因此，在綜合評估了適配、查詢、寫入和存儲等綜合能力后，我們最終選擇了 TDengine 這款產品。

iBuilding 項目屬于“智慧樓宇”的一部分，項目本身用于邊緣側對大型制冷設備（中央空調）的智能監(jiān)控與交互。具體應用場景是：項目所涉及的幾十個樓區(qū)，各自都有一些大型離心式冷水機組（10 臺左右），我們在每個樓區(qū)都部署了一個 TDengine 到 ARM64 系統(tǒng)上。通過 Python 程序，系統(tǒng)會先進行數(shù)據采集，然后把數(shù)據寫入 TDengine ，最后再把數(shù)據上傳到云端的 TDengine 進行處理。

具體實踐

以其中一個 Database 環(huán)境為例：

我們根據 TDengine “一個設備一張表，一類設備一個超級表”的建模原則，創(chuàng)建了如下表，兩類設備的指標數(shù)分別為 97 和 199 ，數(shù)據列以 float 和 int 為主，設備每 5s 上報一批數(shù)據：

對于邊緣側的數(shù)據采集，由于資源有限，所以資源數(shù)據的使用就成為了十分重要的指標。這方面 TDengine 表現(xiàn)非常好，進一步幫我們降本增效了。

我們承載數(shù)據庫服務的邊緣盒子配置為 2GB 內存，4C CPU，ARM64 位的系統(tǒng)。由于子表數(shù)量不大，以及 TDengine 寫入內存比較固定的特點，當前內存占用還不到 200MB。數(shù)據庫日常 CPU 消耗比較低，大概在 3%-5% 左右，保守估計即便寫入量擴大 50-100 倍，也沒有問題。

應用效果

求某個設備 70 天前到 40 天前之間，每隔一段時間的設備用電量，無數(shù)據則用 prev 值填充。結果如下：

查詢一個月之前的某設備某幾項指標之和，按照時間戳降序排序。查詢大約 19 萬行數(shù)據，耗時 0.4s。結果如下：

經驗匯總

在使用 TDengine 的過程中，我們也遇到過一些小問題，比如：我們環(huán)境眾多，但是客戶端和服務端又要保持版本精確一致，升級起來會比較復雜。再比如：監(jiān)控庫中 log 中的 dn 表的 disk_used 語義并不是實際的 TDengine 對磁盤的占用，而是數(shù)據文件所在文件系統(tǒng)的總占用，有些情況下會讓用戶誤以為是 TDengine 的空間占用，導致與預期不符，就像下圖一樣：

后面我們和 TDengine 社區(qū)工作人員一起討論了這個情況，大家認為可以新增一列，專門用來統(tǒng)計 TDengine 的數(shù)據文件的大小，然后把它與 disk_used、disk_total 一起規(guī)范化統(tǒng)一命名，就可以防止用戶誤解了。

目前 TDengine 官方已經在積極地處理優(yōu)化。這也是開源社區(qū)的一大價值，大家都可以參與進去，讓產品不斷迭代，發(fā)展地更好。

寫在最后

當前，TDengine 主要被應用于中央空調制冷設備的監(jiān)控業(yè)務中，作為先行試點，這一場景已經取得了不錯的效果。但由于機組價格昂貴、成本較高，因此通過平臺動態(tài)生成操作指令的這類智能化操作仍需謹慎，所以目前該功能還沒有正式開放。

在樓宇智能化方面，我們也有很多工作要做，從邊緣側的監(jiān)控、到指令控制、再到邊云協(xié)同的一體化服務，我們會在這些場景中繼續(xù)探索和挖掘 TDengine 的潛力。