時(shí)序數(shù)據(jù)庫發(fā)展研究

1 引言

隨著5G商用正式啟動(dòng)，中國正式進(jìn)入5G時(shí)代，物聯(lián)網(wǎng)（IoT）也將迎來巨大的轉(zhuǎn)變，5G技術(shù)帶來的高速通信為物聯(lián)網(wǎng)的數(shù)據(jù)傳輸速度帶來更高效的運(yùn)行。而物聯(lián)網(wǎng)的發(fā)展中一項(xiàng)重要的技術(shù)就是時(shí)序數(shù)據(jù)庫，物聯(lián)網(wǎng)設(shè)備產(chǎn)生的大量數(shù)據(jù)，需要通過有效的時(shí)序數(shù)據(jù)庫進(jìn)行處理和存儲(chǔ)，各大行業(yè)也對(duì)時(shí)序數(shù)據(jù)庫投入關(guān)注，本文將針對(duì)時(shí)序數(shù)據(jù)庫進(jìn)行研究和介紹。

2 介紹

2.1 時(shí)序數(shù)據(jù)

時(shí)序數(shù)據(jù)，即時(shí)間序列數(shù)據(jù)，我們把按照時(shí)間戳的大小順序排列的一系列記錄值的數(shù)據(jù)稱為時(shí)間序列數(shù)據(jù)（Time Series Data）[1]。在日常生活中，時(shí)序數(shù)據(jù)相當(dāng)常見，比如，汽車的位置定位，在一段時(shí)間內(nèi)某輛特定汽車的其他屬性，包括型號(hào)、顏色、車牌號(hào)、所有者等都是不變的，但它的位置數(shù)據(jù)是隨著時(shí)間變化不斷在變化的，那么根據(jù)時(shí)間確定的位置值及其他屬性所組成的一系列數(shù)據(jù)就是一組時(shí)序數(shù)據(jù)，當(dāng)我們駕駛汽車開啟導(dǎo)航時(shí)，就需要根據(jù)這一組時(shí)序數(shù)據(jù)判斷接下來到達(dá)目的地的路線以及存儲(chǔ)駕駛記錄，在即將到來的無人駕駛中更是必不可少的。在互聯(lián)網(wǎng)中，時(shí)序數(shù)據(jù)更是無處不在，比如，用戶訪問網(wǎng)站的記錄、應(yīng)用系統(tǒng)的系統(tǒng)日志數(shù)據(jù)等等。

近年來，時(shí)序數(shù)據(jù)的應(yīng)用更為廣泛，包括物聯(lián)網(wǎng)（以前述汽車定位為例外還有各類傳感器數(shù)據(jù)等）、經(jīng)濟(jì)金融領(lǐng)域、環(huán)境監(jiān)控領(lǐng)域[2]、醫(yī)學(xué)領(lǐng)域[3]、工業(yè)制造領(lǐng)域[4]、農(nóng)業(yè)生產(chǎn)領(lǐng)域[5]、硬件和軟件系統(tǒng)監(jiān)控[6]等各方面，都在大量使用時(shí)序數(shù)據(jù)，揭示研究對(duì)象的趨勢性、規(guī)律性、異常性，而在5G與人工智能的浪潮下，時(shí)序數(shù)據(jù)作為大數(shù)據(jù)、機(jī)器學(xué)習(xí)、實(shí)時(shí)預(yù)測、預(yù)警的基礎(chǔ)數(shù)據(jù)的作用更加顯著，因此，對(duì)時(shí)序數(shù)據(jù)的研究與應(yīng)用更為深入。從前述汽車定位的例子可以看到，時(shí)序數(shù)據(jù)與關(guān)系型數(shù)據(jù)存在較大的差異：

（1）最明顯的特征是時(shí)序數(shù)據(jù)都存在唯一的時(shí)間戳，并且以時(shí)間戳大小進(jìn)行排序，以時(shí)間戳作為唯一標(biāo)識(shí)進(jìn)行區(qū)分，而關(guān)系型數(shù)據(jù)通常有其他字段作為標(biāo)識(shí)，比如學(xué)生的數(shù)據(jù)通常使用學(xué)號(hào)作為唯一標(biāo)識(shí)進(jìn)行區(qū)分。

（2）時(shí)序數(shù)據(jù)并不關(guān)心關(guān)系，在汽車定位中，我們不需要了解這輛汽車的所有者的其他屬性，例如年齡、職業(yè)等等，也就不存在對(duì)汽車所有者的表的關(guān)聯(lián)。

（3）時(shí)序數(shù)據(jù)的數(shù)據(jù)量持續(xù)呈線性增長，每隔一定時(shí)間粒度就會(huì)產(chǎn)生新的數(shù)據(jù)，將會(huì)持續(xù)產(chǎn)生海量數(shù)據(jù)，因此數(shù)據(jù)量龐大。而關(guān)系型數(shù)據(jù)的增長通常不是隨著時(shí)間持續(xù)增長的，比如一所學(xué)校的學(xué)生數(shù)據(jù)量在一段時(shí)間內(nèi)都是相對(duì)穩(wěn)定的。

（4）時(shí)序數(shù)據(jù)很少會(huì)有更新操作，在某個(gè)時(shí)刻的測量值產(chǎn)生將不會(huì)發(fā)生變化，所以幾乎不需要對(duì)時(shí)序數(shù)據(jù)進(jìn)行更新。對(duì)于關(guān)系型數(shù)據(jù)，則是已存在的數(shù)據(jù)經(jīng)常發(fā)生更新，比如學(xué)生的個(gè)人信息，包括年齡、身高等屬性。

2.2 時(shí)序數(shù)據(jù)庫

基于快速增長的時(shí)序數(shù)據(jù)應(yīng)用需求以及區(qū)別于傳統(tǒng)關(guān)系型數(shù)據(jù)的特征，時(shí)序數(shù)據(jù)庫應(yīng)運(yùn)而生，時(shí)序數(shù)據(jù)庫一般具有以下特點(diǎn)[7]：

（1）高吞吐量數(shù)據(jù)高速寫入能力。由于時(shí)序業(yè)務(wù)會(huì)持續(xù)產(chǎn)生海量數(shù)據(jù)，并且對(duì)寫入的速度有很高的要求，寫入的并發(fā)量大，這就要求時(shí)序數(shù)據(jù)庫系統(tǒng)實(shí)現(xiàn)高吞吐量的數(shù)據(jù)高速寫入功能。

（2）高壓縮率。時(shí)序數(shù)據(jù)庫需要存儲(chǔ)大量的數(shù)據(jù)，并且有的監(jiān)控?cái)?shù)據(jù)可能需要存儲(chǔ)很長時(shí)間，5年到10年都有需求，因此需要根據(jù)時(shí)序數(shù)據(jù)的特征對(duì)數(shù)據(jù)進(jìn)行壓縮。

（3）高效時(shí)間窗口查詢能力。時(shí)序業(yè)務(wù)的查詢需求分為兩類，一是實(shí)時(shí)數(shù)據(jù)查詢，反映當(dāng)前監(jiān)控對(duì)象的狀態(tài)；二是主要是查詢某個(gè)時(shí)間段的歷史數(shù)據(jù)，歷史數(shù)據(jù)的數(shù)據(jù)量非常大，這時(shí)候需要針對(duì)時(shí)間窗口大量數(shù)據(jù)查詢進(jìn)行優(yōu)化。

（4）高效聚合能力。時(shí)序業(yè)務(wù)場景通常會(huì)關(guān)心數(shù)據(jù)的聚合值，比如count、mean等聚合值來反映某個(gè)時(shí)間段內(nèi)的數(shù)據(jù)情況，因此時(shí)序數(shù)據(jù)庫需要提供高效的聚合函數(shù)。

（5）批量刪除能力。時(shí)序業(yè)務(wù)對(duì)于過期的數(shù)據(jù)需要進(jìn)行批量刪除操作。

（6）通常不需要具備事務(wù)的能力。

時(shí)序數(shù)據(jù)庫與傳統(tǒng)關(guān)系型數(shù)據(jù)庫不同，傳統(tǒng)關(guān)系型數(shù)據(jù)庫注重增刪改查和事務(wù)功能，而時(shí)序數(shù)據(jù)庫針對(duì)海量數(shù)據(jù)寫入，其讀取查詢多是一段時(shí)間段內(nèi)的數(shù)據(jù)。傳統(tǒng)關(guān)系型數(shù)據(jù)庫都是采用的B tree，是隨機(jī)讀寫的模式，會(huì)在尋道上消耗較多時(shí)間，對(duì)于90%以上場景是寫入的時(shí)序數(shù)據(jù)庫來說效率太低，所以時(shí)序數(shù)據(jù)庫的主流是采用LSM Tree（Log-Structured Merge Tree，結(jié)構(gòu)化合并樹）[8]替換B Tree，比如KairosDB（底層使用Cassandra的單機(jī)模式）、openTSDB（底層使用Hbase）、LevelDB等，其核心思想是放棄部分讀的能力換取寫的能力最大化。當(dāng)然，除了LSM Tree作為存儲(chǔ)機(jī)制，時(shí)序數(shù)據(jù)庫還有許多其他的嘗試和改進(jìn)，并且在不斷發(fā)展，接下來在第三部分將簡要介紹時(shí)序數(shù)據(jù)庫的發(fā)展歷史。

3 時(shí)序數(shù)據(jù)庫的發(fā)展概況

3.1 時(shí)序數(shù)據(jù)庫的發(fā)展歷史

圖1展示了時(shí)序數(shù)據(jù)庫的發(fā)展時(shí)間軸，從時(shí)間軸中可以看到，雖然時(shí)序數(shù)據(jù)庫近幾年才進(jìn)入大眾視野，但其發(fā)展可以追溯到20世紀(jì)90年代，在監(jiān)控領(lǐng)域產(chǎn)生了時(shí)序數(shù)據(jù)存儲(chǔ)的需求，由此出現(xiàn)的第一代時(shí)序數(shù)據(jù)庫，以RRDtool（Round Robin Database Tool） 和 Whisper 為代表，使用固定大小的數(shù)據(jù)庫，可以隨時(shí)間變化快速存儲(chǔ)數(shù)值型數(shù)據(jù)，但是其讀性能還是比較弱，缺乏針對(duì)時(shí)間的特殊優(yōu)化，并且處理的數(shù)據(jù)模型單一，通常是內(nèi)嵌在監(jiān)控系統(tǒng)中。

圖1 時(shí)序數(shù)據(jù)庫發(fā)展時(shí)間軸

隨著大數(shù)據(jù)的發(fā)展，時(shí)序數(shù)據(jù)爆發(fā)式增長，不只是監(jiān)控系統(tǒng)，其他系統(tǒng)也有更多處理時(shí)序數(shù)據(jù)的需求，在2011年開始出現(xiàn)了以O(shè)penTSDB、KairosDB為代表的基于分布式存儲(chǔ)的時(shí)序數(shù)據(jù)庫，這類時(shí)序數(shù)據(jù)庫在繼承通用存儲(chǔ)優(yōu)勢的基礎(chǔ)上，針對(duì)時(shí)間進(jìn)行優(yōu)化。比如OpenTSDB底層依賴于HBase集群存儲(chǔ)，根據(jù)時(shí)序的特征對(duì)數(shù)據(jù)進(jìn)行壓縮，節(jié)省存儲(chǔ)空間；用TSD（Time Series Daemon）進(jìn)行讀寫，對(duì)時(shí)序數(shù)據(jù)的常用查詢進(jìn)行封裝，提供數(shù)據(jù)聚合、過濾等操作。這類專用于時(shí)序數(shù)據(jù)的數(shù)據(jù)庫相比第一代時(shí)序數(shù)據(jù)庫在存儲(chǔ)和查詢性能有明顯的提高，但是這類數(shù)據(jù)庫也有許多不足，比如低效的全局UID機(jī)制，依賴Hadoop和HBase環(huán)境，部署及維護(hù)成本高。

隨著微服務(wù)的發(fā)展，時(shí)序數(shù)據(jù)庫在高速發(fā)展，OpenTSDB存在的不足和部署復(fù)雜性促進(jìn)了低成本的垂直型時(shí)序數(shù)據(jù)庫的誕生。以IfluxDB為代表的垂直型時(shí)序數(shù)據(jù)庫成為時(shí)序數(shù)據(jù)庫市場的主流，針對(duì)時(shí)序數(shù)據(jù)具備更高效的存儲(chǔ)讀取等數(shù)據(jù)處理能力和高效的壓縮算法。InfluxDB的單機(jī)版本采用類似LSM Tree的TSM Tree（Timestamp-Structure Merge Tree）存儲(chǔ)結(jié)構(gòu)，引入了series-key的概念，根據(jù)時(shí)間特征對(duì)數(shù)據(jù)實(shí)現(xiàn)了很好的分類，減少冗余存儲(chǔ)，提高數(shù)據(jù)壓縮率。相對(duì)于OpenTSDB需要配置Java環(huán)境和HBase環(huán)境，InfluxDB基于Goland，無依賴，部署簡單，并且使用類SQL語言的InfluxQL，易于開發(fā)。

3.2 時(shí)序數(shù)據(jù)庫的發(fā)展現(xiàn)狀

近5年來，時(shí)序數(shù)據(jù)庫發(fā)展十分迅猛，各大互聯(lián)網(wǎng)企業(yè)包括Google、阿里、Amazon都推出自己的時(shí)序數(shù)據(jù)庫，DB-Engines從2014年起也把時(shí)序數(shù)據(jù)庫作為獨(dú)立的目錄進(jìn)行分類統(tǒng)計(jì)。

圖2為DB-Engines統(tǒng)計(jì)的2019年12月為止24月各類數(shù)據(jù)庫的關(guān)注度趨勢，可以看到時(shí)序數(shù)據(jù)庫關(guān)注度同比2017年12月上漲77.3%，相比第二名的圖形數(shù)據(jù)庫上漲近兩倍。

圖3為DB-Engines統(tǒng)計(jì)的2019年12月為止5年來業(yè)內(nèi)流行的時(shí)序數(shù)據(jù)庫的關(guān)注度和使用度排名。從圖中可以看到，從2015年開始，各種時(shí)序數(shù)據(jù)庫如雨后春筍般涌現(xiàn)：2017年，F(xiàn)acebook開源基于內(nèi)存的Gorilla時(shí)序數(shù)據(jù)庫（2015年發(fā)布）原型項(xiàng)目beringei，基于PostgreSQL設(shè)計(jì)的TimescaleDB開源，阿里發(fā)布時(shí)序數(shù)據(jù)庫TSDB；2018年Amazon推出完全托管的Timestream；其中，2013年發(fā)布的開源InfluxDB，在各種時(shí)序數(shù)據(jù)庫中脫穎而出，獨(dú)占鰲頭，直到目前為止都是時(shí)序數(shù)據(jù)庫關(guān)注度排名第一并且其人氣仍在增長，由于其開源特性，InfluxDB使用類SQL的InfluxQL查詢語言的易用性，基于Go語言編寫的無環(huán)境依賴等優(yōu)勢，InfluxDB的版本正在飛快的迭代更新，2019年就發(fā)布了7個(gè)版本，并且推出了云服務(wù)版本。

圖2 DB-Engines統(tǒng)計(jì)不同類別數(shù)據(jù)庫關(guān)注度趨勢

圖3 DB-Engines統(tǒng)計(jì)時(shí)序數(shù)據(jù)庫關(guān)注度趨勢

4 未來與展望

時(shí)序數(shù)據(jù)庫正處于高速發(fā)展階段，時(shí)序數(shù)據(jù)技術(shù)逐步走向成熟，但是這絕不是終點(diǎn)，時(shí)序數(shù)據(jù)技術(shù)還面臨各種新的需求和挑戰(zhàn)。各大廠商在提高時(shí)序數(shù)據(jù)庫性能的同時(shí)，針對(duì)新需求正在提出更多解決方案：

（1）云服務(wù)。除了單機(jī)版本，許多廠商還發(fā)布了分布式版本、云服務(wù)版本，特別是云服務(wù)，已經(jīng)成為必不可擋的發(fā)展趨勢。

（2）可視化服務(wù)。隨著萬物互聯(lián)的到來，用戶對(duì)信息的全面掌握的需求在增長，時(shí)序數(shù)據(jù)的可視化展示成為一大趨勢，這就對(duì)時(shí)序數(shù)據(jù)庫的查詢能力提出更高的要求。

（3）邊緣計(jì)算服務(wù)。在萬物互聯(lián)的時(shí)代，更多的傳感器帶來的龐大數(shù)據(jù)量是集中化處理方式難以負(fù)荷的，這就使得數(shù)據(jù)計(jì)算向邊緣化發(fā)展，設(shè)備將數(shù)據(jù)通過邊緣設(shè)備進(jìn)行實(shí)時(shí)處理分析反饋后再集中存儲(chǔ)，能夠提高設(shè)備的實(shí)時(shí)響應(yīng)能力，提升時(shí)效性數(shù)據(jù)的價(jià)值，因此，時(shí)序數(shù)據(jù)庫對(duì)邊緣計(jì)算的支持將成為其一個(gè)重要的功能。

面對(duì)這些挑戰(zhàn)與機(jī)遇，相信時(shí)序數(shù)據(jù)庫將會(huì)有更深的發(fā)展，未來可期。