作者：黃培健，陳馳｜叄零肆零科技發展有限公司。

小 T 導讀：上海叄零肆零科技有限公司致力於能源（氣和熱）的數字化轉型，以現階段壓力和流量監測物聯為切入，結合企業已有的資訊化資料，利用物聯技術解決能源企業的安全執行痛點，助力其提升智慧運營效率。

依託數字孿生和人工智慧演算法模型，我們構建了實時反映管網實際運營工況的瞬態的模擬平臺。該平臺致力於為能源企業提供包括客戶認知、需求負荷分析、管網狀態監控和優化、多工況計算、氣(熱)源匹配、通路尋優等一系列資料服務。下圖為平臺實際運作場景畫面。

在此專案中，構建數字孿生的主要資料來源於以下兩個地方：

1. 物聯資料：物聯裝置每 5 分鐘上報一次物聯資料；
2. 模擬資料：依託於大量物聯裝置的接入，將工況資料進行實時對齊上傳做模擬求解以此得到模擬資料。

在專案即將投入研發測試之際，我們卻發現了一些會影響到專案正常運作的問題——兩種資料型別都非常龐大，此前常用的資料庫難以支撐如此龐大資料量的儲存查詢等操作。帶著這個問題，我們將目光轉移到當前市面上的資料庫產品上，試圖從中篩選到最適合本專案的資料庫。

波折重重的資料庫選型

從專案涉及到的資料型別來看，物聯資料具有典型的時序資料特點，量大但不會變化，模擬資料的計算結果量同樣很大。這兩類資料都需要快速的儲存、實時的查詢響應，但相比於儲存來講，查詢並不會過於複雜。

基於以上背景需求，我們開始進行資料庫產品選型。

首先嚐試使用的是非關係資料庫 MongoDB，在通用資料庫中 MongoDB 已經是佼佼者了，但是查詢和儲存效率仍然都沒有達到我們的預期。在思考過後，我們從資料型別出發縮小資料庫選型範圍，最終決定從時序資料庫中進行選擇。

我們率先將目光鎖定在當前市面比較流行的時序資料庫 InfluxDB 上，一套測試下來發現，儘管業務需求將將能夠滿足，但 InfluxDB 的運維成本太高，而且其叢集版並未開源，使用成本不低，因此 InfluxDB 也排除在我們的選型範圍之外。

一次偶然的機會，我們瞭解到了時序資料庫 TDengine，發現這一款資料庫效能勝於 InfluxDB 的同時，甚至把叢集也做了開源，方便進行水平擴充套件，且在成本管控上也達到了最優的狀態，輕量化、類 SQL 的結構設定大幅降低運維和學習成本。在眾多優點的推動下，我們便嘗試將 TDengine 投入測試使用。

非常高興的是，期間我們在 TDengine 的官方社群中獲得了及時專業的技術支援，最終順利地把開源版 TDengine 應用到了專案開發中。而 TDengine 也沒有讓我們失望，成功上線後其在執行上十分高效穩定。

具體場景與配置

目前我們選用的 TDengine 版本是 2.2.0.1，單機版暫時毫無壓力，但出於業務擴充套件的需求，同時也在籌備單機橫向拓展為叢集的工作。

在實際操作中，當前伺服器配置是“24G 記憶體 + 12 核 3.60GHzCPU +機械硬碟”。如下圖所示，庫中共有子表 20000+，超級表 6 張，其中常用的有 4 張表。資料保留日期為 10 年，資料周增幅大概為 1000 餘萬行。

根據濤思資料提供的資料，我們通過合理的配置引數讓資料庫的 Vnode 數量恰好等於計算機的 CPU 核數，從而可以充分利用計算機效能，順利完成環境搭建。

千萬級別資料量的查詢效果

超級表 computing_result 儲存了所有模擬計算的結果，單表總計 21 列，單行長度 1.8k，當前資料量為千萬級別，是我們的主要查詢物件——

針對以上的查詢資料，具體的查詢效果如下：

1. 查詢某些裝置的所有模擬計算結果為 0.09 秒，程式碼示例如下：

select * from slsl_digital_twin.computing_result r where r.batch_no in ( 'c080018_20211029080000' ) and r.device_id in ( '347444', '73593', '18146', '235652', '350382' );

2. 查詢某些裝置在一定時間範圍內的，最新的壓力資料耗時 7.8 毫秒。

3. 根據區域 id 分組，查詢該區域下不同裝置的最新資料，耗時 9 毫秒（由於 2.1 版本增加了巢狀查詢功能，我們得以更好地實現相對複雜的邏輯去得到查詢結果）。程式碼示例如下：

select sum(pressure) as pressure, sum(flow) as flow, sum(temperature) as temperature,last(on_off) as onOff,gis_id from (select last(pressure) as pressure, last(flow) as flow, last(temperature) as temperature,last(on_off) as on_off  from slsl_digital_twin.enn_iot where in_out_flag = 'OUT' and gis_id in( '347444', '73593', '18146', '235652', '350382') group by device_id,gis_id ) group by gis_id;

值得一提的是，在實現高效的儲存查詢效能下，TDengine 佔用的儲存空間不足 500MB。但事實上，僅僅 computing_result 單張超級表的實際資料量理論上就應為（82+（40+125+31+225）4+811+2+42+10）位元組*12409408 行數，即 21GB 左右，更不用提把靜態資料抽取出來做成記憶體裡的標籤大幅度減少了原資料量。

但由於 nchar 類資料中有部分 null 值，在本文中我們無法精準計算壓縮率。即便如此，TDengine 的表現也已經令我們足夠驚豔了。

寫在最後

未來，隨著我們接入更多城市的管網模擬、爆炸輻射、洩漏預警等計算模型，產生的資料量將會達到 10 億+，子表數量也會達到數千萬級。TDengine 即將上線的 3.0 版本可以輕鬆支援億級別的表數量，這一點讓我們更加期待未來和 TDengine 的深度合作，同時也對 TDengine 抱以更大的信心。在合作的過程中，我們也會繼續探索如何將 TDengine 應用於更多的業務場景，以更好地滿足我們的各類模擬計算環節的業務需求。

關於作者

黃培健，叄零肆零架構師。目前負責公司數字孿生專案和公司整體技術架構。
陳馳，叄零肆零高階工程師。目前負責公司數字孿生專案整體開發。

✨想了解更多TDengine的具體細節，歡迎大家在GitHub上檢視相關原始碼哦。✨