小 T 導(dǎo)讀：在元智信息的智慧礦山項(xiàng)目中，需要一款 Database 來(lái)支撐起生產(chǎn)交互管控系統(tǒng)的采運(yùn)排環(huán)節(jié)所有過(guò)程設(shè)備的采集、存儲(chǔ)、計(jì)算和監(jiān)控功能。在 MySQL、InfluxDB、TDengine 的數(shù)據(jù)庫(kù)選型調(diào)研中，TDengine 脫穎而出。本文講述了他們的選型思路、建模思路以及方案創(chuàng)新點(diǎn)，作為經(jīng)驗(yàn)參考分享給有需要的讀者。

公司簡(jiǎn)介

元智信息是國(guó)內(nèi)領(lǐng)先的露天礦業(yè)項(xiàng)目管理咨詢和技術(shù)方案提供商。元智公司為全國(guó)范圍內(nèi)的工礦企業(yè)提供一站式的技術(shù)支持服務(wù)， 包括可行性研究分析、礦山規(guī)劃與調(diào)度、生產(chǎn)評(píng)估、生產(chǎn)優(yōu)化、業(yè)務(wù)系統(tǒng)整合、系統(tǒng)集成和軟件開發(fā)等專項(xiàng)服務(wù)。

一、行業(yè)背景

智慧礦山是以礦山數(shù)字化、信息化為前提和基礎(chǔ)，對(duì)礦山生產(chǎn)、職業(yè)健康與安全、技術(shù)支持與后勤保障等各方面進(jìn)行主動(dòng)感知、自動(dòng)分析和快速處理。建設(shè)智慧礦山，首先以建設(shè)和實(shí)現(xiàn)礦山在生產(chǎn)、安全、經(jīng)營(yíng)與管理等環(huán)節(jié)的信息化為前提，最終實(shí)現(xiàn)”礦山一張圖”的系統(tǒng)管理目標(biāo)，開啟礦山“透明+智能+管控”的安全生產(chǎn)新模式。

二、使用場(chǎng)景介紹

在整個(gè)礦山生產(chǎn)交互管控系統(tǒng)的采運(yùn)排環(huán)節(jié)，需要對(duì)所有過(guò)程設(shè)備進(jìn)行采集、存儲(chǔ)、計(jì)算和監(jiān)控。這些數(shù)據(jù)涵蓋范圍廣，包括挖機(jī)、卡車的采集數(shù)據(jù)、調(diào)度管理數(shù)據(jù)、設(shè)備 GPS 信息、以及每一個(gè)固定位置工序的采集數(shù)據(jù)等。

數(shù)據(jù)類型

• 采：露天礦山采掘設(shè)備，超大型電鏟與液壓鏟。礦山中利用采掘設(shè)備進(jìn)行礦產(chǎn)資源以及覆蓋物的挖掘工作，在實(shí)際應(yīng)用中，需要采集和監(jiān)控各個(gè)采掘設(shè)備的信息，如設(shè)備運(yùn)行參數(shù)（像電壓和電流等）和位置信息。 
• 運(yùn)：主要是運(yùn)輸環(huán)節(jié)。在采煤的過(guò)程中，需要對(duì)大量的剝離物（如表土和巖石）進(jìn)行排棄，將原煤運(yùn)輸?shù)矫簜}(cāng)、破碎站以及選煤廠。在此過(guò)程中，需要通過(guò)安全合理的調(diào)度來(lái)實(shí)現(xiàn)礦產(chǎn)附屬物及礦品的運(yùn)輸。因此，我們會(huì)實(shí)時(shí)采集卡車運(yùn)輸設(shè)備位置信息、胎壓、油耗等信息，以保障安全調(diào)度。 
• 排：排土工作系指從露天采場(chǎng)將剝離覆蓋在礦床上部及其周圍的大量表土和巖石，運(yùn)送到專門設(shè)置的場(chǎng)地如（排土場(chǎng)）。主要通過(guò)卡車運(yùn)輸來(lái)實(shí)現(xiàn)。即煤炭開采剝離過(guò)程中產(chǎn)生的渣土剝離后通過(guò)運(yùn)輸系統(tǒng)排出生產(chǎn)作業(yè)區(qū)，排土過(guò)程中合理規(guī)劃以達(dá)到露天煤礦生態(tài)環(huán)保過(guò)程中的環(huán)保作業(yè)要求。 

數(shù)據(jù)量級(jí)

• 一般大規(guī)模的礦山車輛數(shù)量，往往超過(guò) 800 臺(tái)。如果是整個(gè)集團(tuán)級(jí)別的應(yīng)用，卡車數(shù)量可達(dá) 3000 ～ 7000 臺(tái)。 
• 以目前的安全生產(chǎn)要求，卡車的采集頻率是 5 ～ 10 秒，在有更高要求的場(chǎng)景中，需要采用更高的頻率，采集的數(shù)據(jù)內(nèi)容包括卡車 GPS 定位數(shù)據(jù)、油耗數(shù)據(jù)、胎壓數(shù)據(jù)以及卡車的速度信息。 
• 以 800 臺(tái)設(shè)備估算，采集頻率 5 秒，一天 24 小時(shí)會(huì)產(chǎn)出大概 1000 多萬(wàn)條數(shù)據(jù)。這個(gè)數(shù)據(jù)量相對(duì)于傳統(tǒng)的數(shù)據(jù)存儲(chǔ)是個(gè)比較大的量級(jí)。 

數(shù)據(jù)應(yīng)用

在實(shí)際的應(yīng)用場(chǎng)景中，對(duì)車輛的數(shù)據(jù)應(yīng)用，其中一個(gè)主要維度就是車輛軌跡，特別是車輛的實(shí)時(shí)位置必須滿足礦山生產(chǎn)的車輛調(diào)度實(shí)時(shí)需求。

三、選型對(duì)比

MySQL

MySQL 是我們團(tuán)隊(duì)在各種應(yīng)用開發(fā)領(lǐng)域使用最多的數(shù)據(jù)庫(kù)，從復(fù)用技術(shù)經(jīng)驗(yàn)的角度上考慮，最初考慮過(guò) MySQL 的可行性。但是在經(jīng)過(guò)分析和驗(yàn)證后，我們就排除了使用關(guān)系型數(shù)據(jù)庫(kù)的方案。主要原因如下：

• 存儲(chǔ)壓力：在最初使用 MySQL 的論證分析中，由于在 MySQL 中的 InnoDB 存儲(chǔ)引擎最小存儲(chǔ)單元頁(yè)的大小是 16 kb 左右， 而 MySQL 以頁(yè)為基礎(chǔ)的查詢數(shù)據(jù)加載時(shí)，數(shù)據(jù)的加載量會(huì)帶來(lái)極大的系統(tǒng)負(fù)擔(dān)。并且，MySQL 作為關(guān)系型數(shù)據(jù)庫(kù)，采用的是 B+ 樹存儲(chǔ)結(jié)構(gòu)，初步估算，深度為 3 的 B+ 樹預(yù)計(jì)能支撐 2000 萬(wàn)條左右的數(shù)據(jù)，這個(gè)數(shù)據(jù)量級(jí)是遠(yuǎn)遠(yuǎn)滿足不了我們的業(yè)務(wù)場(chǎng)景的。 
• 性能存在瓶頸：在實(shí)際驗(yàn)證中，伴隨著數(shù)據(jù)量的增加，MySQL 性能急劇下降。 

InfluxDB

其次，我們進(jìn)行了 InfluxDB 的調(diào)研。驗(yàn)證的初級(jí)階段，從查詢效率的 QPS 維度看，InfluxDB 的查詢問(wèn)題不大，效率可以滿足。但是，在測(cè)試智慧礦山的物聯(lián)網(wǎng)模型查詢時(shí)，很快遇到了 InfluxDB 對(duì)于此類查詢實(shí)時(shí)效率低下的問(wèn)題，而且設(shè)計(jì)復(fù)雜度也很高。 在 1000 臺(tái)設(shè)備的情況下，需要查所有設(shè)備的平均速度，查詢實(shí)時(shí)性要求高。 但 InfluxDB 沒(méi)有明確的基于設(shè)備的建表方式，如果用一張表存所有設(shè)備數(shù)據(jù)，數(shù)據(jù)量就會(huì)很大，查詢性能也會(huì)下降。比較明顯的是，在百萬(wàn)數(shù)據(jù)量級(jí)以內(nèi)，這種建表方式查詢時(shí)間在 1 秒左右，而當(dāng)數(shù)據(jù)到了千萬(wàn)量級(jí)的時(shí)候，查詢效率下降十分明顯。 在我們真實(shí)的智慧礦山中、所有設(shè)備產(chǎn)生的數(shù)據(jù)量級(jí)條件下，這個(gè)查詢效率的下降是明顯不符合我們要求的。

TDengine

最后，我們調(diào)研了 TDengine Database，這也成了我們最終選型采用的方案。其優(yōu)勢(shì)表現(xiàn)如下：

• 技術(shù)成本低：網(wǎng)上學(xué)習(xí)資料多，而且 TDengine 具有安裝方便、對(duì)運(yùn)維要求低、支持 SQL 所以學(xué)習(xí)成本低等特性，極大縮短了項(xiàng)目研發(fā)周期和開發(fā)難度。 
• 數(shù)據(jù)模型契合：TDengine 與智慧礦山比較契合的是， TDengine 有一個(gè)超級(jí)表概念，其超級(jí)表類似于物聯(lián)網(wǎng)的物模型，子表類似于具體設(shè)備。這一數(shù)據(jù)模型與智慧礦山的業(yè)務(wù)系統(tǒng)也比較吻合。 
• 國(guó)產(chǎn)化：目前在礦山應(yīng)用方面，對(duì)國(guó)產(chǎn)化要求是很高的。讓我們比較欣喜的是，即使在非國(guó)產(chǎn)化產(chǎn)品的對(duì)比中，TDengine 的讀寫速度和壓縮率也是比較領(lǐng)先的。 

性能表現(xiàn)

我們以智慧礦山業(yè)務(wù)中的 5000 設(shè)備、每天 1000 萬(wàn)采集點(diǎn)的數(shù)據(jù)量級(jí)下，在以車建模和以位置建模結(jié)合的數(shù)據(jù)模型下，TDengine 的性能遠(yuǎn)沒(méi)有達(dá)到極限，目前系統(tǒng)對(duì)于車和位置的查詢速度都在毫秒級(jí)。

四、方案落地

建模思路

在智慧礦山的實(shí)際應(yīng)用場(chǎng)景中，模型是一個(gè)關(guān)鍵設(shè)計(jì)，在我們使用 TDengine 的查詢場(chǎng)景中，數(shù)據(jù)模型的設(shè)計(jì)跟查詢是關(guān)聯(lián)在一起的。 比如在我們的系統(tǒng)中，在更關(guān)注單體設(shè)備的查詢的場(chǎng)景中，我們采用“一個(gè)設(shè)備一張表”的建模方式；而在智慧礦山的“電子圍欄”業(yè)務(wù)中，我們則采用了以位置建模的方式，這樣方便系統(tǒng)基于位置進(jìn)行統(tǒng)計(jì)和查詢，具體建模思路參考如下：

• 以車建模：這種建模以車為目標(biāo)統(tǒng)計(jì)，可以很好地解決系統(tǒng)中涉及車和各種設(shè)備的運(yùn)行情況的統(tǒng)計(jì)查詢問(wèn)題。?
• 以位置建模：采用了基于固定位置建模的方式。以工藝和流程位置建模，可以解決設(shè)備經(jīng)過(guò)某些點(diǎn)的統(tǒng)計(jì)問(wèn)題，查詢效率明顯提高。

方案創(chuàng)新

在濤思數(shù)據(jù)的工程師的建議下，我們可以在 MySQL 數(shù)據(jù)庫(kù)里，把所有的設(shè)備表的名字（TDengine 中的 tbname）進(jìn)行了存儲(chǔ)。我們?cè)谌?TDengine 中進(jìn)行設(shè)備查詢的時(shí)候，子表名從關(guān)系數(shù)據(jù)庫(kù)中直接讀取，然后在 TDengine 中針對(duì)子表進(jìn)行查詢。這個(gè)設(shè)計(jì)，在系統(tǒng)中針對(duì)單個(gè)設(shè)備進(jìn)行快速數(shù)據(jù)回放的時(shí)候，也明顯提高了查詢效率。

技術(shù)架構(gòu)圖

最終效果展示

目前，像我們的智慧礦山系統(tǒng)中，TDengine 的應(yīng)用查詢用于監(jiān)控性能指標(biāo)，主要查詢內(nèi)容：

• 位置信息：位置信息包括系統(tǒng)中每一個(gè)車輛，或者對(duì)每一個(gè)現(xiàn)場(chǎng)的坐標(biāo)位置，以及現(xiàn)場(chǎng)的電子圍欄的位置信息等。 
• 車輛速度：礦山的安全生產(chǎn)作業(yè)對(duì)卡車駕駛速度作出限制，速度不能超過(guò) 40 km/h，超速數(shù)據(jù)需要實(shí)時(shí)提醒，對(duì)超速車輛進(jìn)行確認(rèn)并響應(yīng)。 

基于上面的數(shù)據(jù)管理，我們的礦山一張圖系統(tǒng)，就是把車、鏟等時(shí)序的數(shù)據(jù)，以及相關(guān)調(diào)度的信息，統(tǒng)一管理起來(lái)。簡(jiǎn)單說(shuō)就是車、鏟怎么樣達(dá)到最優(yōu)化的配比。 查詢結(jié)果如下：

五、寫在最后

對(duì) TDengine 的長(zhǎng)遠(yuǎn)規(guī)劃

本次在內(nèi)蒙古露天礦山卡車調(diào)度中初次使用 TDengine Database，我們?cè)跇?gòu)建智慧礦山系統(tǒng)中有了很多新的思路，更讓我們對(duì)它的簡(jiǎn)單易用以及令人驚嘆的高性能產(chǎn)生了更多期待。基于目前對(duì) TDengine 的理解和使用經(jīng)驗(yàn)，我們計(jì)劃在如下場(chǎng)景中進(jìn)一步使用它來(lái)完善我們的系統(tǒng)：

• 環(huán)保監(jiān)測(cè)：礦山對(duì)環(huán)保的要求越來(lái)越高，主要集中在環(huán)保監(jiān)測(cè)這部分業(yè)務(wù)。一般情況下，整個(gè)礦山基本上是 30 臺(tái)到 50 臺(tái)環(huán)保監(jiān)測(cè)設(shè)備。這部分?jǐn)?shù)據(jù)數(shù)據(jù)更新頻率不是太大，采集頻率 20 秒即可，數(shù)據(jù)量很適合用 TDengine 來(lái)進(jìn)行處理。 
• 生產(chǎn)集控設(shè)備：TDengine 的數(shù)據(jù)模型比較適合做這部分業(yè)務(wù)。傳統(tǒng)意義上，在整個(gè)生產(chǎn)集控設(shè)備上，控制設(shè)備都是使用實(shí)時(shí)數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)的。時(shí)間序列屬性也比較適合時(shí)序數(shù)據(jù)的特征——查詢?yōu)橹鳎潞蛣h除很少。TDengine 對(duì)時(shí)序數(shù)據(jù)的查詢優(yōu)勢(shì)，可以在卡車調(diào)度系統(tǒng)中更快的對(duì)設(shè)備進(jìn)行調(diào)度。我們正在調(diào)研 TDengine 中的數(shù)據(jù)訂閱，這種方式應(yīng)該可以很好地適配這些場(chǎng)景。