在近些年的橋隧綜合監(jiān)控系統(tǒng)中，集成監(jiān)控軟件負(fù)責(zé)對(duì)底層設(shè)備數(shù)據(jù)進(jìn)行實(shí)時(shí)采集、并通過組態(tài)頁(yè)面將數(shù)據(jù)通過圖表、動(dòng)畫等方式展現(xiàn)。在展現(xiàn)數(shù)據(jù)的同時(shí)，監(jiān)控軟件將交通流量、COVI環(huán)境參數(shù)、消防報(bào)警等重要數(shù)據(jù)通過轉(zhuǎn)儲(chǔ)服務(wù)接口存儲(chǔ)至關(guān)系型數(shù)據(jù)庫(kù)，如Oracle、SQLSERVER等。第三方軟件如設(shè)備管理系統(tǒng)、大數(shù)據(jù)分析系統(tǒng)等對(duì)若干年的隧道運(yùn)營(yíng)數(shù)據(jù)進(jìn)行挖掘、清洗，趨勢(shì)分析，則需采用ODBC. JDBC等數(shù)據(jù)庫(kù)中間件方式對(duì)關(guān)系型數(shù)據(jù)庫(kù)訪問，生成報(bào)表，納入到專家?guī)熘?。?yīng)用場(chǎng)景適用于城市越江隧道、快速路地下通道、城市高架立交橋等單點(diǎn)設(shè)施應(yīng)用場(chǎng)景，設(shè)備數(shù)量較少，監(jiān)控點(diǎn)數(shù)在1-5萬點(diǎn)。

弱電工程公司表示隨著多隧合一監(jiān)控中心共用、島橋隧等特大型綜合監(jiān)控領(lǐng)域的擴(kuò)展，從單個(gè)設(shè)施到全路段路網(wǎng)管理，監(jiān)控設(shè)備點(diǎn)數(shù)高達(dá)數(shù)十萬級(jí)，在數(shù)據(jù)存儲(chǔ)計(jì)算方面對(duì)數(shù)據(jù)庫(kù)服務(wù)端提出了大容量和高性能的要求，期望分析處理速度達(dá)到千萬點(diǎn)/秒，甚至更高的實(shí)時(shí)歷史數(shù)據(jù)存儲(chǔ)和查詢要求，因此實(shí)時(shí)庫(kù)的存儲(chǔ)技術(shù)優(yōu)勢(shì)得以體現(xiàn)。

國(guó)內(nèi)橋隧監(jiān)控系統(tǒng)中數(shù)據(jù)庫(kù)存儲(chǔ)升級(jí)的現(xiàn)狀

在新建橋隧項(xiàng)目建設(shè)完成后，無論是實(shí)時(shí)數(shù)據(jù)庫(kù)或者歷時(shí)數(shù)據(jù)庫(kù)，都伴隨著高清監(jiān)控系統(tǒng)的建設(shè)一起投入運(yùn)行，隨著后期設(shè)施內(nèi)新增系統(tǒng)的接入以及設(shè)施長(zhǎng)期運(yùn)營(yíng)數(shù)據(jù)業(yè)務(wù)量的不斷增長(zhǎng)，原有數(shù)據(jù)庫(kù)服務(wù)器的存儲(chǔ)容量顯得捉襟見肘，系統(tǒng)整體性能越來越無法滿足日益增長(zhǎng)的業(yè)務(wù)系統(tǒng)的需要，而此時(shí)則必須對(duì)相關(guān)硬件以及軟件進(jìn)行升級(jí)改造傳統(tǒng)的升級(jí)方法是采購(gòu)更高性能的服務(wù)器，對(duì)處理器、內(nèi)存、硬盤進(jìn)行升級(jí)擴(kuò)容，由此提高運(yùn)算性能，增加存儲(chǔ)空間等。但是這種升級(jí)擴(kuò)容帶來的弊端也是顯而易見的，改造周期長(zhǎng)，預(yù)算成本高，而且在新老系統(tǒng)切換期間，往往需要額外的技術(shù)支持，備份轉(zhuǎn)移用戶數(shù)據(jù)，確定升級(jí)失敗后的同退機(jī)制等，導(dǎo)致每次升級(jí)過程中步驟切換復(fù)雜，對(duì)用戶的在線業(yè)務(wù)系統(tǒng)影響比較大。

在目前橋隧監(jiān)控中使用的是關(guān)系型數(shù)據(jù)庫(kù)，面向?qū)ο笫怯脩?，在存?chǔ)性能上只能支持每秒千條數(shù)據(jù)的增刪改操作，在實(shí)時(shí)性方面無法保證實(shí)時(shí)響應(yīng)，且與實(shí)時(shí)庫(kù)的定位不同，關(guān)系型數(shù)據(jù)庫(kù)一般關(guān)注數(shù)據(jù)的完整性、一致性，而實(shí)時(shí)數(shù)據(jù)庫(kù)更傾向于關(guān)注數(shù)據(jù)的實(shí)時(shí)性和數(shù)據(jù)質(zhì)量，更適應(yīng)于在大數(shù)量的情況下對(duì)數(shù)據(jù)的實(shí)時(shí)分析展示。

主流方案架構(gòu)

實(shí)時(shí)數(shù)據(jù)庫(kù)作為一款通用型基礎(chǔ)產(chǎn)品，可針對(duì)橋隧監(jiān)控行業(yè)作定制化應(yīng)用，因此采用了友好的二次開發(fā)平臺(tái)，封裝了簡(jiǎn)單易用的服務(wù)接口，為開發(fā)人員提供了快速定制非標(biāo)協(xié)議數(shù)據(jù)采集器的功能，同時(shí)，集成了功能強(qiáng)大的組態(tài)系統(tǒng)，進(jìn)行輔助設(shè)計(jì)I作．基于以上需求，主流的實(shí)時(shí)庫(kù)架構(gòu)采用典型的c／S模式，結(jié)構(gòu)上劃分為四層：

數(shù)據(jù)采集層：主要負(fù)責(zé)和外部系統(tǒng)通信，對(duì)數(shù)據(jù)接口可進(jìn)行標(biāo)準(zhǔn)以及非標(biāo)定義，進(jìn)行數(shù)據(jù)采集，并將采集的設(shè)備數(shù)據(jù)轉(zhuǎn)儲(chǔ)進(jìn)庫(kù)表中。

數(shù)據(jù)服務(wù)層：屬于實(shí)時(shí)庫(kù)的核心層，可進(jìn)行數(shù)據(jù)管理服務(wù)、數(shù)據(jù)源管理服務(wù)、網(wǎng)絡(luò)管理服務(wù)，在整個(gè)系統(tǒng)中起到了關(guān)鍵作用。

系統(tǒng)接口層：主要是對(duì)數(shù)據(jù)服務(wù)層進(jìn)行封裝，以接口的方式提供給外部系統(tǒng)或者系統(tǒng)應(yīng)用層。

系統(tǒng)應(yīng)用層：提供了四個(gè)展示平臺(tái)，并以表格、圖形、動(dòng)畫等多種形式展示系統(tǒng)配置及數(shù)據(jù)。

系統(tǒng)架構(gòu)如下：

在新建系統(tǒng)進(jìn)行硬件部署時(shí)，為了節(jié)約資源，可將配置中心、數(shù)據(jù)節(jié)點(diǎn)、采集客戶端、展示客戶端、配置客戶端等五類組件集中部署在一臺(tái)服務(wù)器中．若是資源充分的情況下，也可分散部署在單獨(dú)的服務(wù)器中，可根據(jù)項(xiàng)目情況進(jìn)行靈活配置。在數(shù)據(jù)節(jié)點(diǎn)上可進(jìn)行分布式部署，由此凸顯出系統(tǒng)的擴(kuò)展性。

由于采用了分布式部署機(jī)制，用戶在對(duì)已有系統(tǒng)改造時(shí)，只需要增加一臺(tái)數(shù)據(jù)節(jié)點(diǎn)，這臺(tái)數(shù)據(jù)節(jié)點(diǎn)即可以分擔(dān)原有數(shù)據(jù)庫(kù)服務(wù)器的負(fù)載，此節(jié)點(diǎn)的增加過程對(duì)于橋隧監(jiān)控系統(tǒng)透明，即對(duì)橋隧監(jiān)控系統(tǒng)的在線運(yùn)行業(yè)務(wù)并無影響，新的數(shù)據(jù)節(jié)點(diǎn)上線后，自動(dòng)分擔(dān)系統(tǒng)負(fù)載，同步相關(guān)數(shù)據(jù)，從而做到了無縫擴(kuò)容的過程，此種分布式可擴(kuò)展的設(shè)計(jì)極大提升了系統(tǒng)的整體性能和可靠性，使得項(xiàng)目后續(xù)的可擴(kuò)展性和可維護(hù)性得到了較大的提升。