小 T 導讀： 在歐聖達的物聯網智慧裝置平臺專案中，需支援數百萬以上物聯網表具和智慧終端的接入管理，支援分散式部署且具備良好擴充套件性。在規則引擎場景下，TDengine 提供了很好的查詢和儲存效能，成為本專案實現實時告警和監控服務的重要一環。本篇文章分享了歐聖達在資料庫調研和搭建階段的思考和經驗，供參考。

公司簡介

哈工歐聖達是深圳市歐聖達科技有限公司和哈工大機器人集團的合資公司，總公司深圳市歐聖達科技有限公司成立於 2010 年 5 月，總部位於深圳，下設合肥研發中心、華東分公司（合肥）和西南分公司（成都）。公司始終致力於燃氣、供熱等公共事業領域的智慧化解決方案研發和應用推廣，擁有超過 10 餘項自主智慧財產權的、基於 5G/NB-IoT 和大資料的“一體化平臺+智慧安全終端”智慧燃氣解決方案，作為核心成員參與制定併發布 2019、2020 年 5G 智慧燃氣行業標準。

某燃氣公司擬建設一套物聯網智慧裝置平臺來滿足各類物聯網裝置接入以及資料的採集、儲存、分析、展示等各類需求，專案需包括資料採集模組、資料分析模組、監控告警模組、預付費實時結算模組、API 介面模組、大屏\地圖顯示模組、後臺管理模組、手機 App 功能模組。

該平臺的搭建目的是為了取代各燃氣錶廠原有的資料接收伺服器，實現對各錶廠物聯網表具（含 FSK、GFSK、LoRa、GPRS、4G、5G、NB-IoT 等技術標準）讀數、壓力、溫度、監控報警、氣價調整、系統引數設定等遠傳控制和管理。系統需支援數百萬以上物聯網表具和智慧終端的接入管理， 1 秒內瞬時併發連線數不低於 5 萬，系統支援分散式部署，且具備良好的擴充套件性，能夠根據業務需要，靈活的擴充套件系統效能和接入能力。

一、選型調研

以上是典型的時序物聯網場景，因此我們調研了國外的主流時序資料庫 InfluxDB，但考慮到國家基礎設施建設安全，我們最終把目光投向了國產開源資料庫 TDengine。我們結合業務資料量對 TDengine 進行了數百萬裝置的壓測，滿足本專案的資料儲存和效能要求。具體測試結果如下：

從測試結果來看，TDengine 的整體硬體消耗資源比較低，且能滿足數百萬裝置的併發寫入。此外相比 MongoDB，其壓縮率可以提升至 1/10 – 1/20，也為我們節約了大量儲存成本。最有吸引力的一點是 TDengine 具有完善的開源社群生態，不僅支援叢集版部署，更有完善的中國服務團隊及多元化的服務模式，可以做到實時響應。

二、 業務架構部署

在具體搭建上，我們將不同廠家、不同型號裝置定義為產品，不同產品的通訊機制、上報資料項、指令內容、上報頻次都是不同的，我們使用 TDengine 對不同產品建立對應的超級表，使用裝置 ID 建立子表。

• 技術架構圖如下圖所示：

具體路徑上，感測器資料經過 MQ 快取、結構化解析後進入到 TDengine，供後續業務進行查詢使用。規則引擎根據已有的規則引數，進行感測器資料訂閱，實時判斷感測器是否觸發了報警規則，從而實現專案的實時監控和報警需求。同時，規則引擎還會根據感測器資料，觸發對應的指令操作（如恢復服務、暫停服務指令），透過 MQ 非同步傳達給感測器。 TDengine 在規則引擎場景下，提供了很好的查詢效能，是實現實時告警和監控服務的重要一環。

• 建模思路

在本專案中，每種裝置的協議及上報資料引數都是不同的，我們將公共屬性（如所屬公司、所屬分公司、所屬廠家、是否預付費等）作為超級表 tags，將共有引數（如閥門狀態、最新讀數、抄表時間、溫度、壓力、電量、訊號強度等）作為普通列，通訊時間戳+時間漂移作為 TDengine 主鍵，其他非共有引數（如一些裝置會上報瞬時工況流量、一些會上報抄表模組電池電量等）作為子表欄位。以本專案的其中一張表作為示例，結構如下：

1.show create stable device_meter_record\G;
2.create table device_meter_record (receive_time TIMESTAMP,meter_readnum DOUBLE,meter_balance INT,meter_volume DOUBLE,meter_time TIMESTAMP,meter_temperature DOUBLE,meter_pressure DOUBLE,meter_instantflow DOUBLE,cust_num BINARY(50),cust_name BINARY(255),company_id BINARY(32),subcompany_id BINARY(32),readingteam_id BINARY(32),subreadingteam_id BINARY(32),area_id BINARY(32),community_id BINARY(32),building_id BINARY(32),user_type BINARY(20),is_holiday BOOL,supplier_id BINARY(32),supplier_device_code BINARY(20),platform_balance INT,platform_last_reading DOUBLE,platform_last_balance INT,platform_price BINARY(15)) TAGS (device_id BINARY(32),device_no BINARY(32),sno BINARY(32),model_id BINARY(32),type_id BINARY(100))

• 效果展示

最終我們採用了 3 節點 8 核 16 G 滿足整體業務需求，系統可以根據時間段範圍、針對單個裝置進行資料上報的查詢功能，且支援按照小時用量、日用量、月用量、年用量四個維度進行統計分析。 目前單個超級表的壓縮率為 2.5%。

三、 經驗分享與未來規劃

在我們使用 TDengine 的過程中，也遇到了一些小問題，在本文中總結出了一些經驗，分享如下：

• 查詢結果欄位名的特殊寫法

TDengine 的此前版本的設計當中，在查詢返回的欄位名時使用的是特殊寫法：例如 SELECT last_row(ts) FROM stb GROUP BY tbname，這樣的設計會導致 MyBatis 等 ORM 框架在對映時無法直接對上。這種情況下只需要將 keepColumnName 設定為 1，就可以避免。

• 及時更新版本

在前期使用過程中，我們曾經遇到過 DROP TABLE 就崩潰的 BUG。和官方溝通後發現，已經在很早的版本上修復了，建議各位遇到 TDengine 的新版本也及時更新。

• USING 語法

在使用  INSERT INTO table USING stable TAGS() 的語法時，一直以為這裡會對 tag 進行重新賦值。到了使用的時候才發現，原來 table 已經存在的情況下，是不會對 tag 發生修改的。細思一下絕對的也是合理的，因為畢竟多一次修改就會多一次效能消耗,如果跟著 insert 來修改，就會多了 1 : 1 的修改操作。

• 調整分片策略

在前期寫入過程中，發現 CPU 佔用只能到 1 核，CPU 資源上不去。和官方溝通後發現，原來預設的分片策略，在小規模裝置上只會建立幾個 Vnode，因此並不能很好地把全部核數利用起來。官方告知可以透過這兩個引數來調整分片策略：  tableIncStepPerVnode 50minTablesPerVnode 50 前者決定的是何時採用下一個 Vnode 來存放新的 table，後者決定的是何時建立下一個 Vnode 來存放新的 table。

• 寫入記憶體 blocks 很重要

在寫入過程中，官方的巡檢發現資料寫入的“碎片化”很嚴重。經過排查發現，分配給寫入過程的記憶體太小（block 預設 6，意味著 1 個 Vnode 只有 96 MB 用於寫入）。由於 TDengine 在寫入原理上是依賴於記憶體來做區域性排序的，因此記憶體小了就會頻頻觸發落盤，從而導致資料的落盤區塊的平均條數很小，需要頻繁 IO 來讀取資料。基於此，各位儘量設定較大的 block 來避免這個問題。

• 未來規劃

物聯網、車聯網等涉及時序資料儲存、分析的場景，使用 TDengine 可以大大降低系統架構複雜度，在提升效能和開發效率的同時還能夠降低學習和運維成本。之後我們也會結合業務需求在專案中充分發揮 TDengine 的優勢，利用其來長期儲存裝置上報的有效讀數資料，以及進行計費、抄表、用量統計分析。