深入淺出實時數(shù)據(jù)庫

1、深入淺出實時數(shù)據(jù)庫12.8日版主要介紹如下主題：談到實時數(shù)據(jù)庫，暫時大家還頗感神秘，后面我們將逐漸解開面紗，給大家展示一個真實的實時數(shù)據(jù)庫世界。先了解概念，再深入原理。說道實時數(shù)據(jù)庫，當時誕生于美國，隨著流程工業(yè)和航天工業(yè)的發(fā)展，大量的測量數(shù)據(jù)需要集成和存儲，采用關(guān)系數(shù)據(jù)庫難以滿足速度和容量的要求，而且接口訪問復雜，不適合科研和監(jiān)控的需要，因此80年代中期，開始誕生了以工業(yè)監(jiān)控為目的的實時數(shù)據(jù)庫。今天大家看到的一些實時數(shù)據(jù)庫，如PI、Uniformance、Infoplus、InSql等工業(yè)監(jiān)控類實時數(shù)據(jù)庫均先后誕生于此階段。而當時還有另外一個分支，即所謂硬實時數(shù)據(jù)庫，它的采集速度和響應速度均

2、是毫秒級的，而大家知道，今天大量應用實時數(shù)據(jù)庫，主動采集速度均是秒級的，響應速度也不嚴格，在Windows平臺下，小于40ms的響應均不準確，但當時卻有這類產(chǎn)品，目前多用于軍事和科研了。到了上世紀90年代，實時數(shù)據(jù)庫在流程工業(yè)全世界范圍內(nèi)大行其道，源于以太網(wǎng)的逐步普及；主要應用于工業(yè)監(jiān)控、控制和公用工程。國內(nèi)的實時數(shù)據(jù)庫發(fā)展較為緩慢，這和技術(shù)封鎖和政治風氣都有關(guān)系，到了2000年之后，國內(nèi)的實時數(shù)據(jù)庫逐漸展露頭角，如ESP-iSYS、Agilor等與國外的PI、InfoPlus均屬于大型分布式網(wǎng)絡實時數(shù)據(jù)庫。規(guī)模相對較小的，如PHD、ConRTDB、SuperInfo，在國內(nèi)開始應用。由于應用

3、場景的不同，好多企業(yè)開始還只是解決現(xiàn)場監(jiān)控的問題，分不清RTDB與SCADA的概念，結(jié)果InSql獲得了一個發(fā)展的機會。那么，什么是實時數(shù)據(jù)庫呢，過去國人老將其與SCADA搞混，倒也給SCADA一個發(fā)展的機會。實際上實時數(shù)據(jù)庫是“對實時性要求高的時標型信息的數(shù)據(jù)庫管理系統(tǒng)”，在這里特別提醒，是管理系統(tǒng)，而非單獨一個數(shù)據(jù)庫。實時數(shù)據(jù)庫雖是系統(tǒng)軟件，但更多是一個應用平臺軟件，原因是實時數(shù)據(jù)庫還沒有一個像SQL一樣的標準，而且其功能太過綜合，各廠商推出的產(chǎn)品功能各有側(cè)重。但以上的膜片中至少總結(jié)了實時數(shù)據(jù)庫的主要功能。目前實時數(shù)據(jù)庫已經(jīng)應用到眾多領(lǐng)域，它的應用范圍還在不斷擴展，業(yè)界的工程師在不斷創(chuàng)造出

4、實時數(shù)據(jù)庫的應用模式。只要有時標型數(shù)據(jù)（時標表示每隔幾個記錄間隔顯示一點），實時數(shù)據(jù)庫就可以在一定程度上發(fā)揮威力。說到這里，漸漸要講原理了。與一般認識不同，時標型數(shù)據(jù)并非僅僅指時間戳、值和質(zhì)量碼，還有一個很重要的屬性，那就是及時性，及時性有兩重含義，采樣間隔和數(shù)據(jù)的新鮮度。時標型數(shù)據(jù)的價值隨新鮮度降低而遞減。1秒鐘內(nèi)的數(shù)據(jù)可以用來流程工業(yè)中的控制，5秒鐘之內(nèi)可以用來監(jiān)視，半小時內(nèi)的數(shù)據(jù)可以用來分析和優(yōu)化，一天內(nèi)的數(shù)據(jù)可以用來日報表，如果是半年前的數(shù)據(jù)，則只能做對比和追溯了。而得到數(shù)據(jù)的新鮮程度往往取決于采樣頻率，這就是為什么如此重視實時數(shù)據(jù)庫的采樣快速性。同時采樣的頻率還進一步?jīng)Q定了實時數(shù)據(jù)庫

5、保存信息的豐富程度。請看下一張膜片：大家都知道采樣定理，根據(jù)拉普拉斯變換，任何信號都可以被分解為頻率不同、幅值不同的正弦波疊加，而如果要讓采到的數(shù)據(jù)中包含一個頻率的信息，則采樣頻率至少為此頻率的2倍。所以大家不要過分關(guān)心實時數(shù)據(jù)庫宣稱的無損壓縮，更重要的是要明白，信息的最大損失就在于采樣。更簡單的例子，當你以10秒鐘的周期去采樣，可能裝置運行過程中出現(xiàn)了異常的超調(diào)，在5秒內(nèi)又恢復了，而你的實時數(shù)據(jù)庫中卻根本不存在這些信息。從另一個方面講，實時數(shù)據(jù)庫中存儲的數(shù)據(jù)永遠是濾波后數(shù)據(jù)，實時數(shù)據(jù)庫就像一個低通濾波器。接下去，要講到實時數(shù)據(jù)庫的核心技術(shù)原理了，理解了這些原理，在設定實時數(shù)據(jù)庫運行參數(shù)的時候

6、，才能得到更好的效果。也就會明白，一個RTDBA（RTDB Administrator 實時數(shù)據(jù)庫 管理）的存在價值。看看這些標題，就知道，下面將會講很多關(guān)鍵的東西。首先看看，任何復雜的大型實時數(shù)據(jù)庫，其基本體系架構(gòu)，也不外乎如圖所示，通過現(xiàn)場適配層適配現(xiàn)場的各種接口，在工業(yè)控制中這是一個復雜的工作。然后通過實時核心，完成數(shù)據(jù)的采集、實時計算、報警計算、其它處理，實時數(shù)據(jù)被不斷泵入磁盤歷時存儲，形成可追溯的歷時信息，同時通過向應用層提供各種適配接口，支持各種開發(fā)語言和各種應用需求的訪問。認識好這個基礎(chǔ)架構(gòu)，下面看核心原理，就思路清晰了?？偟膩碚f，目前工業(yè)通訊、傳輸?shù)膮f(xié)議種類繁多，主要有兩方面原

7、因：1、歷史遺留；2、人為壟斷；二者的合力就是上邊這張膜片的內(nèi)容，很多時候，為了不付出廠商提出的巨額接口或接口板卡費用，廣大的業(yè)界工程師采取編程口、打印口等極端方式，以獲得可以接受的性價比。在協(xié)議載體上，主要是串行和以太兩種，當然在串行通訊中又有很多專用總線分支，例如Profibus等。未來在載體上是相當?shù)那逦?，以太網(wǎng)通訊技術(shù)已經(jīng)勢如破竹，所以，前途光明，但另一個困擾更大，就是封閉的協(xié)議，目前大部分廠商都宣稱自己開放了，但開放的是上層，而非底層。雖然，至少可以做到采用OPC訪問實時數(shù)據(jù)庫，但要想簡單地將For InSql的接口用于Agilor，則很難，這就是底層沒有協(xié)議的問題。有些工程師提出，

8、如果底層協(xié)議不統(tǒng)一，實時數(shù)據(jù)庫的市場將繼續(xù)存在混亂和低速發(fā)展。談到接口，小型實時數(shù)據(jù)庫（許多是號稱自己是實時數(shù)據(jù)庫的組態(tài)軟件）均采用了以上的架構(gòu)，即將核心和接口做在一起，用戶使用起來較為簡單，但如果出現(xiàn)任何一個不穩(wěn)定的接口或局部異常，那整個實時數(shù)據(jù)庫就崩潰了。另外對于大型應用，這種結(jié)構(gòu)也較難擴展。對于大型分布式實時數(shù)據(jù)庫，基本按照如下的配置：接口軟件被獨立出來，即可以與實時數(shù)據(jù)庫核心集中部署在1臺計算機上，也可以與部署在接口機上，在大規(guī)模應用的時候，接口的負載不會影響核心的穩(wěn)定，同時任意一個接口出現(xiàn)Crash，都不會導致實時數(shù)據(jù)庫整體宕機。從而提供了更好的可擴展性和穩(wěn)定性。談到影響接口效率的因

9、素，主要如下：首先協(xié)議如果慢，那沒什么好的方法，這主要可以看看DDE協(xié)議，在OPC出現(xiàn)前，也曾經(jīng)紅火了一段時間，DDE使計算機上跨進程數(shù)據(jù)可以方便通訊，但這種通訊協(xié)議本身效率很低。計算機再快，容量不能大幅度上升，幾百個位號就很不錯了。就這一點，就決定了其退出了歷史舞臺。第二在于網(wǎng)絡狀況。沒有有效地組網(wǎng)，以太網(wǎng)也會十分緩慢。有效的帶寬變低，使得快速協(xié)議也變得緩慢而不穩(wěn)定。網(wǎng)絡狀況有兩方面：1、物理結(jié)構(gòu)合理性，多少次經(jīng)驗告訴我們，沒有合理組織的以太網(wǎng)，往往導致數(shù)據(jù)的阻塞，梳理以太網(wǎng)就像控制交通流量，任何地方出現(xiàn)瓶頸，都會導致數(shù)據(jù)緩慢；2、病毒，尤其是占用大量帶寬的蠕蟲，一旦感染了這個，接口中斷就很

10、有可能了。設備效率也一樣關(guān)鍵，經(jīng)常出現(xiàn)DCS工作壓力很大了，這時再看其通訊，就很難了。針對這種情況往往應該增加通訊卡件來提高效率；工作站負載也是影響大型系統(tǒng)接口效率的關(guān)鍵，很多大型系統(tǒng)的OPC都在工作站上，這時，如果工作站負載很重，OPC能分到的運行時間不足，又會影響效率，最終數(shù)據(jù)傳輸還是很緩慢，而且不穩(wěn)定。OPC并非什么好協(xié)議，只不過因為是中立國出的協(xié)議而如此廣泛被使用。如果這些都沒有問題，那么最終協(xié)議總歸協(xié)議，實現(xiàn)協(xié)議交互的軟件質(zhì)量還十分關(guān)鍵，在實施中，我們也經(jīng)常會碰到因為質(zhì)量不好的OPC，效率低、穩(wěn)定性差導致整個系統(tǒng)不穩(wěn)定的。知道了以上內(nèi)容，現(xiàn)場遇到問題，應逐個排除，不要一開始就責怪實時

11、數(shù)據(jù)庫不好，只有對癥下藥地解決問題，才能獲得高效的系統(tǒng)。接下去將探尋接口內(nèi)部的奧秘，先給大家一張預覽圖：談到這里，就要談到實時數(shù)據(jù)庫為做到實時的考慮了。為了做到實時，實時數(shù)據(jù)庫采取了“實時”的反面-“緩存”，緩存是為了提高交互效率，從而使整體更加實時，這點后面將詳細介紹。那么一個接口程序內(nèi)部有什么呢？主要有兩部分：現(xiàn)場接口協(xié)議棧和位號分組。當然，對于小型的接口，位號分組被省略了。位號分組是按照實時數(shù)據(jù)庫組態(tài)的要求，按不同的頻率采集實時數(shù)據(jù)。分組的優(yōu)勢在于降低了位號采集的工作量。要知道很多協(xié)議是慢速的（如串口協(xié)議）。如果實時數(shù)據(jù)庫中僅要求5秒鐘的采樣頻率，而下端卻不作區(qū)分，按最快的頻率采集，則往

12、往效率就會降低，甚至影響到配置為高速采集的其它位號。因此，分組往往是必須的。協(xié)議棧則不用解釋，大家都知道必須實現(xiàn)的。實現(xiàn)的好，則效率高、穩(wěn)定性好。實時數(shù)據(jù)庫接口中有定時器，在Windows平臺上能獲得的最高定時精度為40ms，因此采樣周期高于40ms，沒有意義。一般主動采集的頻率都是1赫茲以下的（也就是慢于1秒/次），更加快速的時候，均采用主動通知的方法，即當數(shù)據(jù)變化的時候，主動向?qū)崟r數(shù)據(jù)庫內(nèi)核發(fā)送變化的數(shù)據(jù)，以達到更高效率。接口就簡單介紹到這里，要明確的是，對于主動采集方式下，接口相當于多了一層緩存，在今后的講解中，大家會發(fā)現(xiàn)，實時數(shù)據(jù)庫的效率和緩存的層次多少很有關(guān)系。簡單談談分布式技術(shù)，大

13、型分布式實時數(shù)據(jù)庫都采用了一定的分布式技術(shù)，采用的技術(shù)不同，局限性也不同。COM/DCOM被熟知，被業(yè)界認同，是微軟主要分布式技術(shù)，因此被廣泛應用。但逃不出DCOM安全性的魔障，與Windows權(quán)限捆綁緊密。而且對于連接效率低的時候容易出錯。跨平臺能力則更是徹底不具備了。J2EE很好，但效率有些低，最近JAVA6出現(xiàn)后，效率已經(jīng)有了顯著提升。甚至比.Net快，但作為底層研發(fā)來說，采用J2EE很不合適，原因是其對硬件的訪問能力較弱。隨著以太網(wǎng)和工業(yè)通訊標準的提升，J2EE平臺也許在工業(yè)應用上有后勁。目前多數(shù)實時數(shù)據(jù)庫廠商采用了專用TCP/IP協(xié)議，優(yōu)勢是易跨平臺，部署方便，穩(wěn)定性容易掌控。但增加

14、了掌控能力的同時也降低了對已有框架的集成，開發(fā)工作量大。從實時數(shù)據(jù)庫所面向的應用場景來說，專用TCP/IP協(xié)議更加適合一些。下面給出實時數(shù)據(jù)庫的簡化模型，后面的原理將結(jié)合這張圖來講解。實時數(shù)據(jù)庫被簡化成由多個接口、一個接口管理模塊、一個組態(tài)模塊、一個實時模塊、一個高速緩存和一個歷史模塊組成，上面覆以應用接口。這個結(jié)構(gòu)基本適合大部分實時數(shù)據(jù)庫，各模塊運行需要的組態(tài)信息往往從組態(tài)模塊中獲取，高速緩存往往和歷史模塊、實時模塊都發(fā)生關(guān)系。接下去將講解實時數(shù)據(jù)庫的核心IO策略。前面已經(jīng)講過了，實時數(shù)據(jù)庫一般采用緩存來增加讀實時數(shù)據(jù)的及時性，因此實時數(shù)據(jù)庫核心中都有高速緩存，如上圖所示，通過接口的采集，高

15、速緩存的數(shù)據(jù)得到不斷的更新，而當上層讀位號的時候，實時數(shù)據(jù)庫通過返回緩存的值來快速響應。因此，讀一般是異步的。但寫則一般是同步的，寫意味著控制，控制意味著嚴格的時序性，同時，寫也可能失敗的，如果寫是異步的，則可能以為成功了，但實際失敗了，后果不堪設想。寫的效率嚴重依賴于接口通訊效率和執(zhí)行機構(gòu)。如果只是修改設定值，則可以較快返回，如果直接寫閥位等需要機械執(zhí)行的值，那就慢了。由于緩存，則必然會產(chǎn)生時滯。實時數(shù)據(jù)庫的采集手段使時滯不止存在于一處。假設實時數(shù)據(jù)庫從OPC中采集數(shù)據(jù)，而OPC從設備上采集數(shù)據(jù)，如果OPC 1秒采集一次，實時數(shù)據(jù)庫5秒采集一次，實時數(shù)據(jù)庫上有一個應用軟件，也5秒采集一次，則

16、此應用軟件讀到的數(shù)據(jù)的最大時滯為11秒（各時滯的相加和），最小時滯為5秒（幾個時滯中最大的一個），在一般的情況下，時滯符合正態(tài)分布。時滯頻域的角度上來分析，實際上是波的相變?；蚍Q之為相移。相移在低速變化數(shù)據(jù)上顯現(xiàn)的問題不是很明顯，比如溫度最快每分鐘上升2度，影響并不明顯，但對于快速開關(guān)量，則十分致命，這個很容易理解，如果時滯1秒，而開關(guān)的變化周期也接近1秒，則會出現(xiàn)一個現(xiàn)象，數(shù)據(jù)采集上來是關(guān)，實際現(xiàn)場則是開的，現(xiàn)場與采集值總是相反，如果這時進行控制，就會發(fā)現(xiàn)控制失效，關(guān)閉已經(jīng)關(guān)閉的開關(guān)或打開已經(jīng)打開的開關(guān)，沒有意義。因此，實時數(shù)據(jù)庫不適宜對快速開關(guān)量的控制。這是一種極端的情況，另一種則是波動較

17、快的窄帶控制，意味著必須將被控量控制在一個較窄的區(qū)域內(nèi)，這時必須考慮時滯問題，如果時滯穩(wěn)定，則可以按照控制理論采用抵消時滯或者前饋的方式獲得較好的控制效果。而如果時滯變化很大，則通過實時數(shù)據(jù)庫之上進行的控制則效果不明顯了，很容易失控。講這些不是說實時數(shù)據(jù)庫不能用于有控制的場合，知道哪些不適合，才能更加正確地使用實時數(shù)據(jù)庫，應用好各種適合的場景。談到核心調(diào)度策略，就得講講多線程的核心，很少有實時數(shù)據(jù)庫是單線程的，大型實時數(shù)據(jù)庫中往往都有線程池，對于需要實時處理讀、寫、采集等任務的實時數(shù)據(jù)庫核心，其調(diào)度策略必須慎重考慮。首先，為難的是往往很難判斷那些任務的優(yōu)先級更高。所以實時數(shù)據(jù)庫內(nèi)部往往通過判斷

18、位號的更新周期來間接揣測任務的優(yōu)先級。雖然往往可以讓多個線程自己競爭，但如果某個位號的更新周期位1秒，而另一個的更新周期為10秒，那么，可想而知，應用對1秒更新的實時數(shù)據(jù)的實時性要求高于10秒的。因此，如果有1秒的為好讀任務沒有完成，則不執(zhí)行10秒的，對于CPU數(shù)量小于等待線程數(shù)量的時候，特別適用。另外，讀即時值的任務優(yōu)先級應該高于讀歷時值的任務，這個也可想而知的，讀一段歷時數(shù)據(jù)，往往不在乎晚響應幾十微秒，而讀實時值，則是越實時越好。這樣，在實時數(shù)據(jù)庫中就形成了一個內(nèi)核級的讀隊列，任務可以被線程順序執(zhí)行，而如果低優(yōu)先級的現(xiàn)成得以執(zhí)行的時候，會檢查一下是否還有更高優(yōu)先級的隊列中需要執(zhí)行，如果有，

19、則讓出時間片?？兹谧尷妫ＷC更需要實時的任務先完成。對于寫任務，往往可以和讀任務并行，但CPU是昂貴資源，如果當前CPU被讀占用而耽誤了寫，則不應該，因此，寫更重要，排在更高的優(yōu)先級。那么采集的優(yōu)先級和讀的優(yōu)先級誰高呢？如果采集被滯后，那么多個可能讀同一個位號的任務都將讀到老的數(shù)據(jù)，因此，采集往往是一個與讀優(yōu)先級的最高優(yōu)先級相當?shù)娜蝿?。具體到不同的實現(xiàn)者，以上的理論未必被完全的實現(xiàn)，有的小型和中型實時數(shù)據(jù)庫甚至根本沒有這些策略的實現(xiàn)，因為運行在其上的應用也不嚴格，因此也可以避繁就簡。接下去，將講到很多人想研究的實時數(shù)據(jù)庫壓縮算法，這個好像挺神秘的，我將結(jié)合PI的專利技術(shù)，旋轉(zhuǎn)門壓縮算法給予詳細

20、的講解。說到數(shù)據(jù)壓縮，無非有損和無損。無損的一般通過各類近似霍夫曼編碼的方法壓縮數(shù)據(jù)，有損則是采用線性擬合的方法。實時數(shù)據(jù)是如此海量，所以無損壓縮不是要講的重點，這里講的是實時數(shù)據(jù)庫中最常用的有損線性擬合算法。擬合方式很多，最著名的無過于OSI 的“旋轉(zhuǎn)門”：首先講當前采集的一個數(shù)據(jù)位門軸，看著PPT上面的圖，最左下角的就是門軸，然后每新采一個點，就將這個點和門軸畫一條線，就是所謂的門，當再采下一個點的時候，就從門軸向新點畫一條線，作為新的門位置，看看，門就“旋轉(zhuǎn)”了一定角度，然后看看從門軸到門邊中所有的點是否都距離門在一個閾值內(nèi)，如果是，也就是說可以用兩點一線的門擬合中間若干點，顯然壓縮掉了

21、大量數(shù)據(jù)。如果不行了，則將原來與門軸組成門的那個點記錄下來（此點將寫入歷時數(shù)據(jù)庫），然后將此點作為新的門軸，以此門軸與最新的點構(gòu)成新的門。這顯然是一個迭代算法，而且好處是明顯的，這樣計算，涉及到的乘除法很少，效率應該較高。所以PI一直用這個算法作為其核心壓縮算法。SUPCON采取了最小二次擬合的方法，原因是現(xiàn)在的計算機浮點能力大大增強，同時發(fā)現(xiàn)最小二次線性擬合的方法的迭代算法運算量也很小。效果和效率都很好。因此申請了專利。所有的有損壓縮算法基本類似，有的數(shù)據(jù)庫還將無損和有損兩種結(jié)合起來，即先有損壓縮，然后再無損壓縮，最終保存壓縮結(jié)果，這樣查詢歷時數(shù)據(jù)的時候多了解壓過程，速度會進一步降低，但空間

22、也進一步節(jié)省。壓縮是雙刃劍。特別告訴大家，千萬不要相信某些產(chǎn)品宣揚自己的壓縮比如何高，通過以上原理知道，壓縮比高的原因就是因為閾值大，閾值大，損失就多，得到的趨勢反應的細節(jié)就少。一般實際應用，流程工業(yè)采用10：1的壓縮很合適，超過此數(shù)據(jù)，會發(fā)現(xiàn)大量有用的細節(jié)都不見了。這樣方法也是一種低通濾波，低通濾波伴隨著時滯增大。掌握原理，合理設定壓縮閾值，才是最好的方法。實際上，實時數(shù)據(jù)庫中也使用了大量的索引技術(shù)，絕對不是關(guān)系數(shù)據(jù)庫的專利，因此，接下去將講講索引技術(shù)：談到索引，這個技術(shù)在所有的檢索系統(tǒng)中不可或缺的。而對于數(shù)據(jù)結(jié)構(gòu)，最重要的部分之一就是索引技術(shù)。各種技術(shù)速度和面向的場景差異很大。有哈希樹、哈希桶、其他散列表、二叉樹等等，不勝枚舉。所以本文僅僅拿出幾種經(jīng)典的情況出來討論一下。實時數(shù)據(jù)庫中，用來定位一個位號，可以通過ID和名稱，ID和名稱都是唯一