進入正題之前，咱們先講個故事

在2018年接觸到工業互聯網之前，我完全沒了解過時序數據庫(下面簡稱為TSDB)，因為做標準的原因開始慢慢接觸起國內一些做TSDB的廠家，其中不乏充滿干勁的創業公司和經驗豐厚的老牌信息化廠商，實力雄厚的BATH天團在TSDB上也都有布局，突然間各種TSDB產品就像雨后春筍一般涌現了。

[[264159]]

它是什么時候開始火的?

其實從2016年開始就有了這個趨勢，引用一下DB-Engines上發布的一張圖，在2016年12個月里，TSDB的人氣上漲了26%，是排名第二的圖數據庫的兩倍還多。

DB-Engines：https://db-engines.com/en/blog_post/62

2016年度各類數據庫人氣漲勢

再挑其中***的InfluxDB在Google Trends里查一下熱度，這個數據庫是2013年7月左右發布的***個版本，自此以后人氣漲勢是一發不可收拾。

2013-2019年InfluxDB的搜索熱度變化

所以我們加緊了學習步伐，希望能盡快的把標準梳理出來，好讓企業伙伴在做技術選型的時候能有些參考。

“這個數據庫我們十幾年前就開始做了，但是叫另一個名字——實時數據庫”。

很多做工業信息化起家的兄弟和我們提到了“實時數據庫”這個概念，并表示“我們功能其實是一樣的”。這讓我有些困惑，很是想搞明白這兩個數據庫之間的關系，能算成一類嗎?但當時網上對于這兩種數據庫的對比，大概只能找到CSDN的一篇《工業大數據漫談12：實時數據庫與時序數據庫》(https://blog.csdn.net/guanhui1997/article/details/72840769)，講的很清晰，如果你也有同樣的困惑可以點進去看一看~但也可以看我接下去要寫的，因為我們拉著做實時/時序數據庫的伙伴們針對這個問題討論了好幾回。

所以這一篇文章是一些學習心得，會盡量包括：這兩個數據庫的產生背景、具體區別和一些小趨勢。

先來點概念做鋪墊~

時序數據 time series data

基于穩定頻率或非固定周期頻率持續產生的一系列基于時間維度的指標監測數據。由時間戳、標簽和指標三要素組成。

時序數據庫 time series database

用于保存海量時序數據的數據庫。

我們可能是異父異母的親兄妹?

實時數據庫誕生于傳統工業，早在幾十年前就已經開始發展，技術已經很成熟，主要為了支持工業場景中大量測量數據的快速寫入、存儲和查詢，有時會涉及到實時的反饋控制。

而時序數據庫誕生于互聯網，興起于物聯網，主要為了支持海量網絡監控及傳感器數據的快速寫入和分析需求。

我們來看下為什么工業場景中要專門設計實時數據庫，工業場景中超過80%的數據都有這樣的一些特征：都帶有時間戳，且是按時間順序生成的;大多為結構化數據;采集頻率高，數據量大。以一個中等規模的工業企業為例，在流程監控的環節中，可能會涉及到5-10萬個傳感器測點，每天產出的數據量能達到上百GB，通常情況下，工業企業都會要求數據能夠長時間被存儲，這樣可以隨時查詢到歷史趨勢。這個簡單的需求已經顯示出了傳統的實時數據庫需要具備的一些能力，可以總結為以下幾點：

高速寫入的能力：工業實時數據庫通常會對寫入的速度有很高的要求。以流程工業的場景為例，每個環節都會設置傳感器，每個傳感器的采集頻率都很高，所以寫入的并發量會特別大，有時甚至會要求每秒上百萬的測點。所以除了對軟件的要求之外，也會選用一些高性能的服務器。

快速查詢的能力：查詢的需求分為兩塊，一是要響應實時的查詢請求，用于及時反映系統的狀態;二是歷史數據也要能快速被查詢，由于歷史數據的量非常大，在查詢時需要對特定時間段的數據做聚合，需要做到即使是查一整年的數據情況，也能很快的反應出來。

超強數據壓縮能力：上面提到監控數據會被存儲很長時間，5年甚至是10年都是常有的事，在存儲容量有限的情況下，就需要對數據做一定的壓縮，通常壓縮方式會分成無損壓縮和有損壓縮，相比而言，有損壓縮的壓縮比會更大一些，有時甚至會達到1:30-40，這就需要設計合理的算法來保留數據中的細節，使數據在還原后仍能保留重要的特征。

積累豐富的工具：傳統的實時數據庫的解決方案一般是從采集開始到直可視化的一整套系統，有多年積累形成的豐富的工具包，比如會積攢上百種的協議，或者各種場景的數據模型，這些都是工業軟件的重要競爭力。

追求***穩定：工業上對軟件的穩定性要求特別高，除了用主備來保證高可用外，完全由軟件的質量來保證程序的持續運行，工程師會自豪地拍胸脯保證軟件跑十年也不會出錯。

我們再來看一下時序數據庫的誕生環境，在進入互聯網飛速發展的時期之后，隨著通信技術的革新，數據通信成本的下降，掀起了一波又一波萬物互聯的熱潮。不僅是互聯網監控需要采集數據，人們每天接觸的手機、智能手環、共享自行車、汽車，都在源源不斷地產生數據。人們實時地收集這些數據并發送到云端，用大數據技術進行分析，對業務進行監控和預測，以數據驅動企業降本增效，提高服務質量。

仔細觀察一下互聯網場景中的數據特征，其實和工業領域大部分的實時數據類似：

1. 單條數據不會很長，但是數據量很大

2. 它們都帶有時間戳，且按順序生成

3. 數據大部分都是結構化的，用于描述某個參數在某個時間點的特征

4. 寫入的頻率會比查詢的頻率高很多

5. 已存儲的數據很少有更新的需求

6. 用戶會更關心一段時間的數據特征，而不是某一個時間點

7. 數據的查詢分析大多基于某一個時間段或者某個數值范圍

8. 需要進行統計和可視化的展示

從上面這些數據特征，可以很明顯的看出來，雖然兩種數據庫產生的環境不同，但是面對的問題是相同的，解決的需求是類似的，所以兩種數據庫設計出的功能有很多重合的部分。

功能要求可參考CCSA大數據技術標準推進委員會(TC601)關于時序數據庫的評估體系(http://databench.cn/evaluate?standard_id=5c07aec44b079)

這就好像兩個從未謀過面的兄妹，確認過眼神就知道是一家人。

你想替代我嗎?沒那么容易

隨著IoT和工業互聯網帶來的新一波風口，一系列新的生產方式、組織方式和商業模式開始涌現。物聯網技術逐步滲透工業，不斷增長的傳感器、飆升的數據量，以及更高的大數據分析需求對實時數據庫傳統的技術架構提出了挑戰。有些問題是需要直面的：

擴展性遇到瓶頸。傳統的技術架構雖然能保證單機具備極高的性能，也可以通過增加機器使性能線性擴展，但是不能像分布式系統那樣實現動態靈活的擴容和縮容，需要提前進行規劃。當業務升級需要系統擴容時，老架構的擴展性就很難滿足需求了。

無法和大數據生態對接。數據采集的最終目的是被理解和使用，大數據產業中對于海量數據的存儲分析已經有很成熟的方案，不論是hadoop還是spark的生態圈，都面臨著新老技術的對接。很多工業企業因為想使用新的大數據分析技術，不得不對現有的系統進行升級或是替換。

價格高昂。傳統的工業實時數據庫解決方案價格都十分昂貴，一般只有大型企業能忍痛接受。但是隨著新技術新理念的普及，更多的中小企業也意識到數據的重要性，但考慮到資金投入，會傾向于尋找價格更低廉的方案。

這時候來自互聯網大家庭的時序數據庫方案就展現出了一些先天優勢，比如：

分布式架構的天然優勢：傳統的實時數據庫多是主備的部署架構，通常要求有較高配置的機器，來追求單機***的性能;同時，在穩定性方面，會對運行軟件的穩定性做極高的要求，完全由高質量的代碼來保證運行的穩定;由于存儲容量有限，也會要求超高的數據壓縮比。但是時序數據庫的分布式架構，使得系統能夠輕松的進行水平擴展，讓數據庫不再依賴昂貴的硬件和存儲設備，以集群天然的優勢來實現高可用，不會出現單點的瓶頸或故障，在普通的x86服務器甚至是虛擬機上都可以運行，大大降低了使用成本。

更靈活的數據模型：傳統的實時數據庫由于工業場景的特殊性，常使用的是單值模型，一個被監控的參數稱為一個測點，在寫入時會對每一個測點建一個模型，比如一個風機的溫度指標算一個測點，十個風機的十個指標就是100個測點，每個測點會附帶描述信息(名稱、精度、數據類型、開關量/模擬量等)查詢的時候就會針對每個測點去查詢數值。單值模型的寫入效率會很高。

單值模型示例

而時序數據庫，開始采用多值模型，類似面向對象的處理方式，例如風機是一種數據模型，可以包括溫度、壓力等多個測量維度，還包括經緯度、編號等tag信息，這樣對外提供服務時會更適合分析的場景。當然單值模型和多值模型是可以互相轉換的。很多數據庫對外提供的服務為多值模型，但是底層存儲還是單值模型。

多值模型示例

現在大部分的時序數據庫都選擇了擴展性較好的NoSQL數據庫，相比于關系型數據庫，數據模型更靈活，非常適合時序數據的多值模型;更易擴展，在資源受限或者需要提升性能的時候，可以輕易的增加機器;查詢效率高;開源軟件成本低;可以與大數據生態無縫對接。看下使用NoSQL數據庫作為底層存儲的TSDB：

開源TSDB的底層存儲模型

但是使用NoSQL數據庫也會丟失一些特性，比如不支持事務，需要通過其他手段來保證數據一致性;比如不支持SQL，SQL作為一種標準查詢語句，已經被人們所習慣，是一種學習成本極低的操作，所以現在做時序數據庫的廠家也在嘗試去集成SQL引擎，降低使用的門檻。

時序數據庫被描述得這么優秀，那它會接班傳統的實時數據庫嗎?不是這么容易的事。

首先，工業中的實時數據庫經受過多年客戶需求的打磨，性能上絕對***，甚至可以進行一定的反饋控制。產品的配套也非常齊全，通常自帶采集工具、適配各種接口協議、具備計算能力及定制化的可視化能力(實時數據庫在這一塊的設計投入了很大精力，以使圖表能展示出監控數據的一些特征和細節)，是一套完整的解決方案。而時序數據庫的設計在這些領域知識的積累方面是很欠缺的，而且大多數只用于監控分析的場景;部署依賴過多，配套工具不完善也是一方面的問題;性能和可靠性離實時的反饋控制也還有一定距離。

再者，近幾年做實時數據庫的廠家也在積極行動中，陸續都為產品增加了分布式版本甚至是云服務版本，通常會以實時數據庫為核心反向建立起一套數據管理和分析的生態體系，勢頭一點都不輸互聯網玩家。

跑道上槍聲響起，這場比賽沒有人棄權。

那我們共同進步吧

不管技術架構如何變化，解決用戶的需求才是最終目的，以需求為導向的設計，永遠不會過時。那接下來我們來看看還出現了哪些新需求：

對查詢的要求逐漸超過了寫入要求：在互聯網時代，查詢的要求已經不僅僅是滿足于一些基礎的條件查詢或是插值查詢，隨著物聯網場景的豐富以及人們對信息全面掌控的需求，基于地圖的應用越來越多，查詢會由時間的維度逐步擴展到空間的維度，除了保證實時性之外，更豐富的可視化的展現也是一大趨勢。

逐步轉向云服務：傳統的工業場景處理實時數據出于安全和性能等原因都會使用私有化部署。機器、軟件以及后續的服務是一筆十分高昂的開銷，還需要配備專業的技術人員進行系統的維護。當服務逐步上云后，一方面省去了購置機器的成本，也不需要特別安排維護機器和軟件系統的工程師，只需要懂得如何開發和維護業務就可以。另外服務使用多少就購買多少，避免一次性購買服務造成的資源浪費或者資源不足再進行二次建設，可以為企業減少很大一筆開銷。隨著網絡和云計算技術的成熟，相關的性能和安全性也會不斷的升級，最終趨近于私有化部署的效果，服務上云已經成為了一個不可阻擋的趨勢。

計算分攤到邊緣：工業領域其實是IoT的重要實驗田，工業互聯網的發展勢必會帶來更多傳感器的使用以及更多數據的采集，當數據過于龐大，集中化的處理方式就很難響應實時的數據分析需求，這就帶來了數據計算向邊緣的發展，需要實時響應的監控就通過邊緣設備及時的處理并反饋，需要用于大規模分析的數據再進行集中存儲，這種分級的處理方式能夠有效的提升時效性數據的價值，同時減輕存儲系統的負擔，所以許多時序數據庫正在研發邊緣計算版本，并會配合流計算的能力使功能更加豐富。融合了邊緣計算的時序數據解決方案會更適合工業互聯網的處理場景。

總結一下上文，其實在技術發展的過程中，兩種數據庫都在為發展變化的業務需求不斷打磨自己的功能，各取所長、互為補充、甚至做出一些妥協，這是保持長久活力的必經之路——停滯造成焦慮，變化帶來生機。

在新的風口誰都想搶得先機。

而踏實做事的人能走到***。

王妙瓊，中國信息通信研究院云大所工程師，CCSA TC601 大數據行業應用工作組組長。主要研究方向為大數據基礎平臺架構、工業大數據應用等。牽頭流計算、時序數據庫等多項行業標準及研究報告的編寫工作。