小 T 導讀：在元智信息的智慧礦山項目中，需要一款 Database 來支撐起生產交互管控系統的采運排環節所有過程設備的采集、存儲、計算和監控功能。在 MySQL、InfluxDB、TDengine 的數據庫選型調研中，TDengine 脫穎而出。本文講述了他們的選型思路、建模思路以及方案創新點，作為經驗參考分享給有需要的讀者。
公司簡介
元智信息是國內領先的露天礦業項目管理咨詢和技術方案提供商。元智公司為全國范圍內的工礦企業提供一站式的技術支持服務， 包括可行性研究分析、礦山規劃與調度、生產評估、生產優化、業務系統整合、系統集成和軟件開發等專項服務。
一、行業背景
智慧礦山是以礦山數字化、信息化為前提和基礎，對礦山生產、職業健康與安全、技術支持與后勤保障等各方面進行主動感知、自動分析和快速處理。建設智慧礦山，首先以建設和實現礦山在生產、安全、經營與管理等環節的信息化為前提，最終實現”礦山一張圖”的系統管理目標，開啟礦山“透明+智能+管控”的安全生產新模式。
二、使用場景介紹
在整個礦山生產交互管控系統的采運排環節，需要對所有過程設備進行采集、存儲、計算和監控。這些數據涵蓋范圍廣，包括挖機、卡車的采集數據、調度管理數據、設備 GPS 信息、以及每一個固定位置工序的采集數據等。
數據類型
- 采：露天礦山采掘設備，超大型電鏟與液壓鏟。礦山中利用采掘設備進行礦產資源以及覆蓋物的挖掘工作，在實際應用中，需要采集和監控各個采掘設備的信息，如設備運行參數（像電壓和電流等）和位置信息。
- 運：主要是運輸環節。在采煤的過程中，需要對大量的剝離物（如表土和巖石）進行排棄，將原煤運輸到煤倉、破碎站以及選煤廠。在此過程中，需要通過安全合理的調度來實現礦產附屬物及礦品的運輸。因此，我們會實時采集卡車運輸設備位置信息、胎壓、油耗等信息，以保障安全調度。
- 排：排土工作系指從露天采場將剝離覆蓋在礦床上部及其周圍的大量表土和巖石，運送到專門設置的場地如（排土場）。主要通過卡車運輸來實現。即煤炭開采剝離過程中產生的渣土剝離后通過運輸系統排出生產作業區，排土過程中合理規劃以達到露天煤礦生態環保過程中的環保作業要求。
數據量級
- 一般大規模的礦山車輛數量，往往超過 800 臺。如果是整個集團級別的應用，卡車數量可達 3000 ～ 7000 臺。
- 以目前的安全生產要求，卡車的采集頻率是 5 ～ 10 秒，在有更高要求的場景中，需要采用更高的頻率，采集的數據內容包括卡車 GPS 定位數據、油耗數據、胎壓數據以及卡車的速度信息。
- 以 800 臺設備估算，采集頻率 5 秒，一天 24 小時會產出大概 1000 多萬條數據。這個數據量相對于傳統的數據存儲是個比較大的量級。
數據應用
在實際的應用場景中，對車輛的數據應用，其中一個主要維度就是車輛軌跡，特別是車輛的實時位置必須滿足礦山生產的車輛調度實時需求。
三、選型對比
MySQL
MySQL 是我們團隊在各種應用開發領域使用最多的數據庫，從復用技術經驗的角度上考慮，最初考慮過 MySQL 的可行性。但是在經過分析和驗證后，我們就排除了使用關系型數據庫的方案。主要原因如下：
- 存儲壓力：在最初使用 MySQL 的論證分析中，由于在 MySQL 中的 InnoDB 存儲引擎最小存儲單元頁的大小是 16 kb 左右， 而 MySQL 以頁為基礎的查詢數據加載時，數據的加載量會帶來極大的系統負擔。并且，MySQL 作為關系型數據庫，采用的是 B+ 樹存儲結構，初步估算，深度為 3 的 B+ 樹預計能支撐 2000 萬條左右的數據，這個數據量級是遠遠滿足不了我們的業務場景的。
- 性能存在瓶頸：在實際驗證中，伴隨著數據量的增加，MySQL 性能急劇下降。
InfluxDB
其次，我們進行了 InfluxDB 的調研。驗證的初級階段，從查詢效率的 QPS 維度看，InfluxDB 的查詢問題不大，效率可以滿足。但是，在測試智慧礦山的物聯網模型查詢時，很快遇到了 InfluxDB 對于此類查詢實時效率低下的問題，而且設計復雜度也很高。 在 1000 臺設備的情況下，需要查所有設備的平均速度，查詢實時性要求高。 但 InfluxDB 沒有明確的基于設備的建表方式，如果用一張表存所有設備數據，數據量就會很大，查詢性能也會下降。比較明顯的是，在百萬數據量級以內，這種建表方式查詢時間在 1 秒左右，而當數據到了千萬量級的時候，查詢效率下降十分明顯。 在我們真實的智慧礦山中、所有設備產生的數據量級條件下，這個查詢效率的下降是明顯不符合我們要求的。
TDengine
最后，我們調研了 TDengine Database，這也成了我們最終選型采用的方案。其優勢表現如下：
- 技術成本低：網上學習資料多，而且 TDengine 具有安裝方便、對運維要求低、支持 SQL 所以學習成本低等特性，極大縮短了項目研發周期和開發難度。
- 數據模型契合：TDengine 與智慧礦山比較契合的是， TDengine 有一個超級表概念，其超級表類似于物聯網的物模型，子表類似于具體設備。這一數據模型與智慧礦山的業務系統也比較吻合。
- 國產化：目前在礦山應用方面，對國產化要求是很高的。讓我們比較欣喜的是，即使在非國產化產品的對比中，TDengine 的讀寫速度和壓縮率也是比較領先的。
性能表現
我們以智慧礦山業務中的 5000 設備、每天 1000 萬采集點的數據量級下，在以車建模和以位置建模結合的數據模型下，TDengine 的性能遠沒有達到極限，目前系統對于車和位置的查詢速度都在毫秒級。
四、方案落地
建模思路
在智慧礦山的實際應用場景中，模型是一個關鍵設計，在我們使用 TDengine 的查詢場景中，數據模型的設計跟查詢是關聯在一起的。 比如在我們的系統中，在更關注單體設備的查詢的場景中，我們采用“一個設備一張表”的建模方式；而在智慧礦山的“電子圍欄”業務中，我們則采用了以位置建模的方式，這樣方便系統基于位置進行統計和查詢，具體建模思路參考如下：
- 以車建模：這種建模以車為目標統計，可以很好地解決系統中涉及車和各種設備的運行情況的統計查詢問題。?
- 以位置建模：采用了基于固定位置建模的方式。以工藝和流程位置建模，可以解決設備經過某些點的統計問題，查詢效率明顯提高。
方案創新
在濤思數據的工程師的建議下，我們可以在 MySQL 數據庫里，把所有的設備表的名字（TDengine 中的 tbname）進行了存儲。我們在去 TDengine 中進行設備查詢的時候，子表名從關系數據庫中直接讀取，然后在 TDengine 中針對子表進行查詢。這個設計，在系統中針對單個設備進行快速數據回放的時候，也明顯提高了查詢效率。
技術架構圖
最終效果展示
目前，像我們的智慧礦山系統中，TDengine 的應用查詢用于監控性能指標，主要查詢內容：
- 位置信息：位置信息包括系統中每一個車輛，或者對每一個現場的坐標位置，以及現場的電子圍欄的位置信息等。
- 車輛速度：礦山的安全生產作業對卡車駕駛速度作出限制，速度不能超過 40 km/h，超速數據需要實時提醒，對超速車輛進行確認并響應。
基于上面的數據管理，我們的礦山一張圖系統，就是把車、鏟等時序的數據，以及相關調度的信息，統一管理起來。簡單說就是車、鏟怎么樣達到最優化的配比。 查詢結果如下：
五、寫在最后
對 TDengine 的長遠規劃
本次在內蒙古露天礦山卡車調度中初次使用 TDengine Database，我們在構建智慧礦山系統中有了很多新的思路，更讓我們對它的簡單易用以及令人驚嘆的高性能產生了更多期待。基于目前對 TDengine 的理解和使用經驗，我們計劃在如下場景中進一步使用它來完善我們的系統：
- 環保監測：礦山對環保的要求越來越高，主要集中在環保監測這部分業務。一般情況下，整個礦山基本上是 30 臺到 50 臺環保監測設備。這部分數據數據更新頻率不是太大，采集頻率 20 秒即可，數據量很適合用 TDengine 來進行處理。
- 生產集控設備：TDengine 的數據模型比較適合做這部分業務。傳統意義上，在整個生產集控設備上，控制設備都是使用實時數據庫來存儲的。時間序列屬性也比較適合時序數據的特征——查詢為主，更新和刪除很少。TDengine 對時序數據的查詢優勢，可以在卡車調度系統中更快的對設備進行調度。我們正在調研 TDengine 中的數據訂閱，這種方式應該可以很好地適配這些場景。
