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

它是什么時候開始火的?

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

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

2016年度各類數(shù)據(jù)庫人氣漲勢

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

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

所以我們加緊了學(xué)習(xí)步伐，希望能盡快的把標(biāo)準(zhǔn)梳理出來，好讓企業(yè)伙伴在做技術(shù)選型的時候能有些參考。

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

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

所以這一篇文章是一些學(xué)習(xí)心得，會盡量包括：這兩個數(shù)據(jù)庫的產(chǎn)生背景、具體區(qū)別和一些小趨勢。

先來點概念做鋪墊~

時序數(shù)據(jù) time series data

基于穩(wěn)定頻率或非固定周期頻率持續(xù)產(chǎn)生的一系列基于時間維度的指標(biāo)監(jiān)測數(shù)據(jù)。由時間戳、標(biāo)簽和指標(biāo)三要素組成。

時序數(shù)據(jù)庫 time series database

用于保存海量時序數(shù)據(jù)的數(shù)據(jù)庫。

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

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

而時序數(shù)據(jù)庫誕生于互聯(lián)網(wǎng)，興起于物聯(lián)網(wǎng)，主要為了支持海量網(wǎng)絡(luò)監(jiān)控及傳感器數(shù)據(jù)的快速寫入和分析需求。

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

高速寫入的能力：工業(yè)實時數(shù)據(jù)庫通常會對寫入的速度有很高的要求。以流程工業(yè)的場景為例，每個環(huán)節(jié)都會設(shè)置傳感器，每個傳感器的采集頻率都很高，所以寫入的并發(fā)量會特別大，有時甚至?xí)竺棵肷习偃f的測點。所以除了對軟件的要求之外，也會選用一些高性能的服務(wù)器。

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

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

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

追求極致穩(wěn)定：工業(yè)上對軟件的穩(wěn)定性要求特別高，除了用主備來保證高可用外，完全由軟件的質(zhì)量來保證程序的持續(xù)運行，工程師會自豪地拍胸脯保證軟件跑十年也不會出錯。

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

仔細觀察一下互聯(lián)網(wǎng)場景中的數(shù)據(jù)特征，其實和工業(yè)領(lǐng)域大部分的實時數(shù)據(jù)類似：

1. 單條數(shù)據(jù)不會很長，但是數(shù)據(jù)量很大

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

3. 數(shù)據(jù)大部分都是結(jié)構(gòu)化的，用于描述某個參數(shù)在某個時間點的特征

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

5. 已存儲的數(shù)據(jù)很少有更新的需求

6. 用戶會更關(guān)心一段時間的數(shù)據(jù)特征，而不是某一個時間點

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

8. 需要進行統(tǒng)計和可視化的展示

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

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

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

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

隨著IoT和工業(yè)互聯(lián)網(wǎng)帶來的新一波風(fēng)口，一系列新的生產(chǎn)方式、組織方式和商業(yè)模式開始涌現(xiàn)。物聯(lián)網(wǎng)技術(shù)逐步滲透工業(yè)，不斷增長的傳感器、飆升的數(shù)據(jù)量，以及更高的大數(shù)據(jù)分析需求對實時數(shù)據(jù)庫傳統(tǒng)的技術(shù)架構(gòu)提出了挑戰(zhàn)。有些問題是需要直面的：

擴展性遇到瓶頸。傳統(tǒng)的技術(shù)架構(gòu)雖然能保證單機具備極高的性能，也可以通過增加機器使性能線性擴展，但是不能像分布式系統(tǒng)那樣實現(xiàn)動態(tài)靈活的擴容和縮容，需要提前進行規(guī)劃。當(dāng)業(yè)務(wù)升級需要系統(tǒng)擴容時，老架構(gòu)的擴展性就很難滿足需求了。

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

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

這時候來自互聯(lián)網(wǎng)大家庭的時序數(shù)據(jù)庫方案就展現(xiàn)出了一些先天優(yōu)勢，比如：

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

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

單值模型示例

而時序數(shù)據(jù)庫，開始采用多值模型，類似面向?qū)ο蟮奶幚矸绞?，例如風(fēng)機是一種數(shù)據(jù)模型，可以包括溫度、壓力等多個測量維度，還包括經(jīng)緯度、編號等tag信息，這樣對外提供服務(wù)時會更適合分析的場景。當(dāng)然單值模型和多值模型是可以互相轉(zhuǎn)換的。很多數(shù)據(jù)庫對外提供的服務(wù)為多值模型，但是底層存儲還是單值模型。

多值模型示例

現(xiàn)在大部分的時序數(shù)據(jù)庫都選擇了擴展性較好的NoSQL數(shù)據(jù)庫，相比于關(guān)系型數(shù)據(jù)庫，數(shù)據(jù)模型更靈活，非常適合時序數(shù)據(jù)的多值模型;更易擴展，在資源受限或者需要提升性能的時候，可以輕易的增加機器;查詢效率高;開源軟件成本低;可以與大數(shù)據(jù)生態(tài)無縫對接?？聪率褂肗oSQL數(shù)據(jù)庫作為底層存儲的TSDB：

開源TSDB的底層存儲模型

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

時序數(shù)據(jù)庫被描述得這么優(yōu)秀，那它會接班傳統(tǒng)的實時數(shù)據(jù)庫嗎?不是這么容易的事。

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

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

跑道上槍聲響起，這場比賽沒有人棄權(quán)。

那我們共同進步吧

不管技術(shù)架構(gòu)如何變化，解決用戶的需求才是最終目的，以需求為導(dǎo)向的設(shè)計，永遠不會過時。那接下來我們來看看還出現(xiàn)了哪些新需求：

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

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

計算分?jǐn)偟竭吘墸汗I(yè)領(lǐng)域其實是IoT的重要實驗田，工業(yè)互聯(lián)網(wǎng)的發(fā)展勢必會帶來更多傳感器的使用以及更多數(shù)據(jù)的采集，當(dāng)數(shù)據(jù)過于龐大，集中化的處理方式就很難響應(yīng)實時的數(shù)據(jù)分析需求，這就帶來了數(shù)據(jù)計算向邊緣的發(fā)展，需要實時響應(yīng)的監(jiān)控就通過邊緣設(shè)備及時的處理并反饋，需要用于大規(guī)模分析的數(shù)據(jù)再進行集中存儲，這種分級的處理方式能夠有效的提升時效性數(shù)據(jù)的價值，同時減輕存儲系統(tǒng)的負(fù)擔(dān)，所以許多時序數(shù)據(jù)庫正在研發(fā)邊緣計算版本，并會配合流計算的能力使功能更加豐富。融合了邊緣計算的時序數(shù)據(jù)解決方案會更適合工業(yè)互聯(lián)網(wǎng)的處理場景。

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

在新的風(fēng)口誰都想搶得先機。

而踏實做事的人能走到最后。

王妙瓊，中國信息通信研究院云大所工程師，CCSA TC601 大數(shù)據(jù)行業(yè)應(yīng)用工作組組長。主要研究方向為大數(shù)據(jù)基礎(chǔ)平臺架構(gòu)、工業(yè)大數(shù)據(jù)應(yīng)用等。牽頭流計算、時序數(shù)據(jù)庫等多項行業(yè)標(biāo)準(zhǔn)及研究報告的編寫工作。

本文名稱：實時數(shù)據(jù)庫一下受到了時序數(shù)據(jù)庫的威脅
網(wǎng)頁鏈接：http://jinyejixie.com/news21/100221.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、企業(yè)建站、品牌網(wǎng)站制作、關(guān)鍵詞優(yōu)化、外貿(mào)建站、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)