小 T 導讀：在元智資訊的智慧礦山專案中，需要一款資料庫能支撐起生產互動管控系統的採運排環節所有過程裝置的採集、儲存、計算和監控功能。在 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，這也成了我們最終選型採用的方案。其優勢表現如下：

• 技術成本低：網上學習資料多，而且 TDengine 具有安裝方便、對運維要求低、  所以學習成本低等特性，極大縮短了專案研發週期和開發難度。 
• 資料模型契合：TDengine 與智慧礦山比較契合的是， TDengine 有一個 概念，其超級表類似於物聯網的物模型，子表類似於具體裝置。這一資料模型與智慧礦山的業務系統也比較吻合。 

• 國產化：目前在礦山應用方面，對國產化要求是很高的。讓我們比較欣喜的是，即使在非國產化產品的對比中，TDengine 的讀寫速度和壓縮率也是比較領先的。 

效能表現

我們以智慧礦山業務中的 5000 裝置、每天 1000 萬採集點的資料量級下，在以車建模和以位置建模結合的資料模型下，TDengine 的效能遠沒有達到極限，目前系統對於車和位置的查詢速度都在毫秒級。

四、方案落地

建模思路

在智慧礦山的實際應用場景中，模型是一個關鍵設計，在我們使用 TDengine 的查詢場景中，資料模型的設計跟查詢是關聯在一起的。 比如在我們的系統中，在更關注單體裝置的查詢的場景中，我們採用“ ”的建模方式；而在智慧礦山的“電子圍欄”業務中，我們則採用了以位置建模的方式，這樣方便系統基於位置進行統計和查詢，具體建模思路參考如下：

• 以車建模：這種建模以車為目標統計，可以很好地解決系統中涉及車和各種裝置的執行情況的統計查詢問題。 
• 以位置建模：採用了基於固定位置建模的方式。以工藝和流程位置建模，可以解決裝置經過某些點的統計問題，查詢效率明顯提高。 

方案創新

在濤思資料的工程師的建議下，我們可以在 MySQL 資料庫裡，把所有的裝置表的名字（TDengine 中的 tbname）進行了儲存。我們在去 TDengine 中進行裝置查詢的時候，子表名從關聯式資料庫中直接讀取，然後在 TDengine 中針對子表進行查詢。這個設計，在系統中針對單個裝置進行快速資料回放的時候，也明顯提高了查詢效率。

技術架構圖 

最終效果展示

目前，像我們的智慧礦山系統中，TDengine 的應用查詢用於監控效能指標，主要查詢內容：

• 位置資訊：位置資訊包括系統中每一個車輛，或者對每一個現場的座標位置，以及現場的電子圍欄的位置資訊等。 
• 車輛速度：礦山的安全生產作業對卡車駕駛速度作出限制，速度不能超過 40 km/h，超速資料需要實時提醒，對超速車輛進行確認並響應。 

基於上面的資料管理，我們的礦山一張圖系統，就是把車、鏟等時序的資料，以及相關排程的資訊，統一管理起來。簡單說就是車、鏟怎麼樣達到最最佳化的配比。 查詢結果如下：

五、寫在最後

對 TDengine 的長遠規劃

本次在內蒙古露天礦山卡車排程中初次使用 TDengine，我們在構建智慧礦山系統中有了很多新的思路，更讓我們對它的簡單易用以及令人驚歎的高效能產生了更多期待。基於目前對 TDengine 的理解和使用經驗，我們計劃在如下場景中進一步使用它來完善我們的系統：

• 環保監測：礦山對環保的要求越來越高，主要集中在環保監測這部分業務。一般情況下，整個礦山基本上是 30 臺到 50 臺環保監測裝置。這部分資料資料更新頻率不是太大，採集頻率 20 秒即可，資料量很適合用 TDengine 來進行處理。 
• 生產集控裝置：TDengine 的資料模型比較適合做這部分業務。傳統意義上，在整個生產集控裝置上，控制裝置都是使用實時資料庫來儲存的。時間序列屬性也比較適合時序資料的特徵——查詢為主，更新和刪除很少。TDengine 對時序資料的查詢優勢，可以在卡車排程系統中更快的對裝置進行排程。我們正在調研 TDengine 中的 ，這種方式應該可以很好地適配這些場景。