實時資料庫簡介

實時資料庫是資料庫系統發展的一個分支，它适用于處理不斷更新的快速變化的資料及具有時間 限制的事務處理。實時資料庫技術是實時系統和資料庫技術相結合的産物，研究人員希望利用資料庫 技術來解決實時系統中的資料管理問題，同時利用實時技術為實時資料庫提供時間驅動排程和資源分 配算法。然而，實時資料庫并非是兩者在概念、結構和方法上的簡單內建。需要針對不同的應用需求 和應用特點，對實時資料模型、實時事務排程與資源配置設定政策、實時資料查詢語言、實時資料通信等 大量問題作深入的理論研究。實時資料庫系統的主要研究内容包括：

實時資料庫模型

實時事務排程：包括并發控制、沖突解決、死鎖等内容

容錯性與錯誤恢複

通路準入控制

記憶體組織與管理

I/O與磁盤排程

主記憶體資料庫系統

不精确計算問題

放松的可串行化問題

實時SQL

實時事務的可預測性

研究現狀與發展實時資料庫系統最早出現在1988年3月的ACM SIGMOD Record的一期專刊中。随後，一個成熟的研究群體逐漸出現，這标志着實時領域與資料庫領域的融合，标志着實時資料庫這個新興研究領域的确立。此後，出 現了大批有關實時資料庫方面的論文和原型系統。人機互動技術與智能資訊處理實驗室實時資料庫小組一直緻力于實時系統、實時智能、實時資料庫系統及相關技術 的研究與開發，并取得了一定的成績。

實時資料庫RTDB（Real-Time Data Base）是資料和事務都有定時特性或顯示的定時限制的資料庫。RTDB的本質特征就是定時限制，定時限制可以歸納為兩類：一類是與事務相聯的定時限制， 典型的就是“截止時間”；另一類為與資料相聯的“時間一緻性”。時間一緻性則是作為過去的限制的一個時間視窗，它是由于要求資料庫中資料的狀态與外部環境 中對應實體的實際狀态要随時一緻，以及由事務存取的各資料狀态在時間上要一緻而引起的。實時資料庫是一個新的資料庫研究領域，它在概念、方法和技術上都與 傳統的資料庫有很大的不同，其核心問題是事物處理既要確定資料的一緻性，又要保證事物的正确性，而它們都與定時限制相關聯。

實時資料庫子系統是SCADA系統的核心之一。實時資料庫子系統設計包含實時資料庫結構設計和實時資料庫管理程式設計兩部分組成，實時資料庫結構設 計主要根據SCADA系統的特點和要求設計實時資料庫的結構。管理程式負責實時資料庫的産生，根據現場修改内容，處理其它任務對實時資料庫的實時請求以及 報警和輔助遙控操作等對外界環境的響應。

[實時資料庫比較]

關系資料庫使用得比較廣，為大部分人所熟悉，以至于談到資料庫，預設情況下指的就是關系資料庫，但實際上還有一些其他種類的資料庫在生産生活中被廣泛使用，比如我将談到的實時資料庫，它們用在要求非常嚴格、資料量非常大的生産工控中。

當今國際國内廣泛使用的實時資料庫隻有三個産品：

a. 美國OSI公司的 PI ( Plant Information System )

b. 美國HONEYWELL公司的 PHD ( Process History Database )

c. 美國AspenTech公司的 IP21 ( InfoPlus .21 )

這些實時資料庫的價格是非常昂貴的，以百萬人民币為機關，但是它們不全是以套也不全是以點(可容納的資料點)為機關來出售，是以無法數字化的比較其價格。因為工作的關系，我有幸能接觸到這三種資料庫，在此對它們做一個比較。

1. PI

采用了旋轉門壓縮專利技術和獨到的二次過濾技術，使進入到PI資料庫的資料經過了最有效的壓縮，極大地節省了硬碟空間。據計算， 每秒1萬點資料存儲一年，僅需要4G的空間，即一隻普通硬碟也可存貯五到十年的資料。是效率最高，使用最簡單，使用最廣泛的實時資料庫，因為其傑出的性 能，PI已經多次提高了它的價格，确實不墜OSI的名号，而且PI在其文檔中公開了她的各種算法，比如上面提到的旋轉門壓縮和二次過濾。

2. PHD

HONEYWELL占據了DCS大部分份額，是以PHD使用得也比較廣泛，PHD在内部其實使用了Oracle關系資料庫，因 此購買PHD就必須先購買Oracle。因為 PHD内部使用Oracle簡化了開發量 和 Oracle的性能限制比較嚴重，是以 PHD 的價格在這三種資料庫最低，算不上正宗的實時資料庫。但不要以為PHD内部使用Oracle就認為Oracle很強，如果直接使用Oracle，隻要兩三 秒的時間，巨大的資料量就會令它崩潰。HONEYWELL其志不在實時資料庫這一塊，而是她的DCS。

3. IP21

IP21基本上還未進入中國市場，它正在通過先期贈送的辦法打開中國市場。

在評價IP21之前，我需要先申明“我對IP21的看法隻是個人看法，不是任何産品的事先串通的人”。

IP21是我見過的最差的關系資料庫，也是我見過的最差的一個軟體，

a. 其軟體的安裝程式的運作需要一個硬狗，這種小氣的做法和PI公開算法的做法沒法比，問題還在于它的這條狗經常會死翹翹。

b. 其軟體的安裝即使是其公司的專業員工也不能保證安裝成功，10台計算機讓它的專業員工來安裝大約隻能成功一兩台。

c. 其軟體的安裝盤隻有一張，但這一張盤需要安裝四個小時以上，中途不停地看到在安裝某個版本的Java解釋器，其後它們又被删除。

d. 沒有實作真正的自動安裝，在安裝之前它們的工程師需要在計算機上修改不少的檔案。

e. 安裝中途如果出現錯誤是不立即報告的，需要四個小時之後安裝完畢才能看到安裝失敗的字樣，但也僅僅隻能知道安裝失敗，不知道在哪一步安裝失敗。

f. 管理維護軟體非常的複雜，除非有人願意犧牲以後的前途來學習它，否則就隻能讓它自己的員工來鼓弄。

g. 運作效率非常低下，而且占用系統資源非常嚴重，一台伺服器隻能給一個IP21使用。

實時資料庫的通路方式

a. 使用自己的API，這種方式效率最高，其實也最簡單。

b. 使用ODBC，這種方式其實沒有多大作用，因為實時資料庫不同于關系資料庫，ODBC沒有太大的用武之地，是以在使用ODBC時有非常多的限制，大部分功能并不支援ODBC方式。

c. 使用OPC方式（OLE for Process Control）

因 為太多的資料庫和DCS使用自己的API方式存取資料，無法做到算法的通用，因為提出了一個标準的存取接口，這就是OPC，如今有超過兩百家産商加入到 OPC組織中，聲勢浩大，包括臭名昭著的M$，之是以講M$臭名昭著是因為M$強制性的在這個标準的存取接口中使用了COM/DCOM，令OPC隻能在 windows下使用，且效率（因為是工控場合，是以效率非常重要）低下。M$在OPC組織中非常的積極，是以現在的OPC基本上也脫離了當初制定的目 标，令很多産商不滿，包括OSI在内，雖然OSI PI提供OPC接口，但OSI不建議客戶使用它，也不對它進行技術支援。在OPC中的COM還有另外一個大問題，因為COM規定必須支援先前制定的接口， 而工控要求又非常嚴格，開發測試的費用和時間都非常高，沒有任何廠商願意支援先前的COM接口，是以沒有真正符合COM标準的OPC。