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

公司簡介

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

一、行業(yè)背景

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

二、使用場景介紹

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

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

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

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

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

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

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

三、選型對比

MySQL

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

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

InfluxDB

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

TDengine

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

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

性能表現(xiàn)

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

四、方案落地

建模思路

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

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

方案創(chuàng)新

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

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

最終效果展示

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

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

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

五、寫在最后

對 TDengine 的長遠(yuǎn)規(guī)劃

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

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