【轉載】工業大數據漫談12：實時數據庫與時序數據庫

轉自：http://blog.csdn.net/guanhui1997/article/details/72840769

工業大數據漫談12：實時數據庫與時序數據庫

在工業大數據數據庫存儲領域，除了傳統的關係型數據庫和分佈式數據庫之外，還有一種類型的數據庫是很是經常使用，並且是很是有必要的，就是實時數據庫和時序數據庫。

實時數據庫誕生於美國，主要是由於現代工業製造流程及大規模工業自動化的發展，致使大量的測量數據須要集成和存儲，而採用關係數據庫難以知足速度和容量的要求，所以在80年代中期，開始誕生了適用於工業監控領域的實時數據庫。

實時數據庫其實並不僅僅只是一個數據庫，而是一個系統，包括對各種工業接口的數據採集，海量監測數據的壓縮、存儲及檢索，基於監測數據的反饋及控制功能等。

實時數據庫的出現，主要是爲了解決當時關係型數據庫不太擅長的領域，包括：

一、海量數據的實時讀寫操做

工業監控數據要求採集速度和響應速度均是毫秒級的，一個大型企業幾萬甚至幾十萬監測點都是常有的事情，這麼大容量的高頻數據，若是用關係數據庫進行存儲，因爲關係庫自己設計的理念，致使它很難進行每秒幾十萬的數據的讀寫操做，而實時數據庫經過轉爲快速讀寫設計的時標型數據結構、高頻緩存等技術，能夠實現海量數據的實時讀寫操做。

二、大容量數據的存儲

因爲數據採集是海量的監控數據，那麼若是用傳統數據庫進行存儲，將會佔用大量的存儲空間，若是咱們用關係數據庫保存10000個監測點，每一個監測點每秒鐘採集一次雙精度數的數據，即便不考慮索引等因素，也須要5-6T的存儲空間，這裏還不包括存儲跟監測點相關的時間等因素，若是都包括，再創建索引，則須要15T-20T的存儲空間。實時數據庫採用了專門的壓縮算法，包括哈佛曼算法、旋轉門算法以及一些二次壓縮算法，壓縮比廣泛可以達到30:1左右，再加上對於時間及索引的特殊處理，存儲量可以縮小到關係庫的1/40，所以，上面的例子只須要500G的空間就可以進行有效存儲了。

三、集成了工業接口的數據採集

因爲歷史和壟斷的緣由，目前工業通信、傳輸的協議種類繁多，實時庫通常都集成了大量的工業協議接口，能夠對各類類型的工業協議進行解析和傳輸。同時，隨着實時數據庫的發展，接口軟件部分也慢慢被獨立出來，便可以與實時數據庫核心集中部署在1臺計算機上，也能夠單獨部署在接口機上，從而提供了更好的可擴展性和穩定性。

四、集成控制功能，可實現實時控制

實時數據庫通常都提供下行控制接口，而且是高速寫出。寫的效率嚴重依賴於接口通信效率和執行機構。所以，實時數據庫大都是從工控軟件廠商發展而來的，他們就有豐富的工業控制寫入的經驗。即使如此，畢竟工業系統對時序有嚴格的要求，而數據庫從讀到寫，會出現時滯，所以，實時數據庫通常不適宜對快速開關量的控制。

在雲計算的時代，實時數據庫的一些缺點就慢慢的顯露出來了。

首先，因爲實時數據庫是基於時標進行處理的，就致使它只能簡單的使用時間段進行查詢和檢索，固然，各大廠商也開發了許多工具，但不管如何檢索的豐富性不能和關係庫比擬。

其次，因爲實時庫都是出售給大型工業企業的，所以價格昂貴，在物聯網時代，對於中小工業企業來講，是個不小的成本。

再次，傳統實時庫在部署時不夠方便靈活，傳輸也更多的考慮工業網絡，甚少考慮互聯網的狀況，不太適應當下雲計算環境的部署。

這個時候，新興的時序數據庫就出現了。時序數據庫在2017年火了起來，出現了大量的開源和商業產品，時序數據庫就是存放時序數據的數據庫，而且須要支持時序數據的快速寫入、持久化、多緯度的聚合查詢等基本功能。時序數據庫其實主要是實時數據庫的數據存儲部分，可是，因爲它採用了新的技術，極大地擴展了數據的容量，除了數據點和時間戳以外，還提供標籤和內容等對數據的描述，而且提供各類聚合查詢，彌補了實時庫的缺陷。

可是，時序數據庫不提供工業接口、下行控制等功能，這些都須要開發人員自行開發，或者將原有的接口與時序庫對接。

固然，不論是實時數據庫仍是時序數據庫，都在飛速發展中，雙方必定會互相借鑑，互相學習，會提供更好、更多的產品供工業大數據使用。