作者：黃培健，陳馳｜叁零肆零科技有限公司
小 T 導讀：上海叁零肆零科技有限公司致力于能源（氣和熱）的數字化轉型，以現階段壓力和流量監測物聯為切入，結合企業已有的信息化數據，利用物聯技術解決能源企業的安全運行痛點，助力其提升智慧運營效率。
依托數字孿生和人工智能算法模型，我們構建了實時反映管網實際運營工況的瞬態的仿真平臺。該平臺致力于為能源企業提供包括客戶認知、需求負荷分析、管網狀態監控和優化、多工況計算、氣(熱)源匹配、通路尋優等一系列數據服務。下圖為平臺實際運作場景畫面。
在此項目中，構建數字孿生的主要數據來源于以下兩個地方：
- 物聯數據：物聯設備每 5 分鐘上報一次物聯數據；
- 仿真數據：依托于大量物聯設備的接入，將工況數據進行實時對齊上傳做仿真求解以此得到仿真數據。
在項目即將投入研發測試之際，我們卻發現了一些會影響到項目正常運作的問題——兩種數據類型都非常龐大，此前常用的數據庫難以支撐如此龐大數據量的存儲查詢等操作。帶著這個問題，我們將目光轉移到當前市面上的數據庫產品上，試圖從中篩選到最適合本項目的數據庫。
波折重重的數據庫選型
從項目涉及到的數據類型來看，物聯數據具有典型的時序數據特點，量大但不會變化，仿真數據的計算結果量同樣很大。這兩類數據都需要快速的存儲、實時的查詢響應，但相比于存儲來講，查詢并不會過于復雜。
基于以上背景需求，我們開始進行數據庫產品選型。
首先嘗試使用的是非關系數據庫 MongoDB，在通用數據庫中 MongoDB 已經是佼佼者了，但是查詢和存儲效率仍然都沒有達到我們的預期。在思考過后，我們從數據類型出發縮小數據庫選型范圍，最終決定從時序數據庫（Time-Series Database）中進行選擇。
我們率先將目光鎖定在當前市面比較流行的時序數據庫 InfluxDB 上，一套測試下來發現，盡管業務需求將將能夠滿足，但 InfluxDB 的運維成本太高，而且其集群版并未開源，使用成本不低，因此 InfluxDB 也排除在我們的選型范圍之外。
一次偶然的機會，我們了解到了時序數據庫 TDengine，發現這一款數據庫性能勝于 InfluxDB 的同時，甚至把集群也做了開源，方便進行水平擴展，且在成本管控上也達到了最優的狀態，輕量化、類 SQL 的結構設定大幅降低運維和學習成本。在眾多優點的推動下，我們便嘗試將 TDengine Database投入測試使用。
非常高興的是，期間我們在 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 單張超級表的實際數據量理論上就應為（8*2+（40+125+31+225）*4+8*11+2+4*2+10）字節*12409408 行數，即 21GB 左右，更不用提把靜態數據抽取出來做成內存里的標簽大幅度減少了原數據量。
但由于 nchar 類數據中有部分 null 值，在本文中我們無法精準計算壓縮率。即便如此，TDengine 的表現也已經令我們足夠驚艷了。
寫在最后
未來，隨著我們接入更多城市的管網仿真、爆炸輻射、泄漏預警等計算模型，產生的數據量將會達到 10 億+，子表數量也會達到數千萬級。TDengine 即將上線的 3.0 版本可以輕松支持億級別的表數量，這一點讓我們更加期待未來和 TDengine 的深度合作，同時也對 TDengine 抱以更大的信心。在合作的過程中，我們也會繼續探索如何將 TDengine 應用于更多的業務場景，以更好地滿足我們的各類仿真計算環節的業務需求。
關于作者
黃培健，叁零肆零架構師。目前負責公司數字孿生項目和公司整體技術架構。
陳馳，叁零肆零高級工程師。目前負責公司數字孿生項目整體開發。
