時序數(shù)據(jù)庫的前世今生

時序數(shù)據(jù)庫忽然火了起來。Facebook開源了beringei時序數(shù)據(jù)庫，基于PostgreSQL打造的時序數(shù)據(jù)庫TimeScaleDB也開源了。時序數(shù)據(jù)庫作為物聯(lián)網(wǎng)方向一個非常重要的服務(wù)，業(yè)界的頻頻發(fā)聲，正說明各家企業(yè)已經(jīng)迫不及待的擁抱物聯(lián)網(wǎng)時代的到來。

本文會從時序數(shù)據(jù)庫的基本概念、應(yīng)用場景、需求與能力等方面一一展開，帶你了解時序數(shù)據(jù)庫的前世今生。

01

應(yīng)用場景

時序數(shù)據(jù)庫是一種針對時序數(shù)據(jù)高度優(yōu)化的垂直型數(shù)據(jù)庫。在制造業(yè)、銀行金融、DevOps、社交媒體、衛(wèi)生保健、智慧家居、網(wǎng)絡(luò)等行業(yè)都有大量適合時序數(shù)據(jù)庫的應(yīng)用場景：

制造業(yè)：

比如輕量化的生產(chǎn)管理云平臺，運用物聯(lián)網(wǎng)和大數(shù)據(jù)技術(shù)，采集、分析生產(chǎn)過程產(chǎn)生的各類時序數(shù)據(jù)，實時呈現(xiàn)生產(chǎn)現(xiàn)場的生產(chǎn)進(jìn)度、目標(biāo)達(dá)成狀況，以及人、機、料的利用狀況，讓生產(chǎn)現(xiàn)場完全透明，提高生產(chǎn)效率。

銀行金融：

傳統(tǒng)證券、新興的加密數(shù)字貨幣的交易系統(tǒng)，采集、分析交易過程中產(chǎn)生的時序數(shù)據(jù)，實現(xiàn)金融量化交易。

DevOps：

IT基礎(chǔ)設(shè)施和應(yīng)用的運維系統(tǒng)，采集、分析設(shè)備運行和應(yīng)用服務(wù)運行監(jiān)控指標(biāo)，實時掌握設(shè)備和應(yīng)用的健康狀態(tài)。

社交媒體：

社交APP大數(shù)據(jù)平臺，跟蹤用戶交互數(shù)據(jù)，分析用戶習(xí)慣、改善用戶體驗；直播系統(tǒng)，采集直播過程中包括主播、觀眾以及中間各環(huán)節(jié)的監(jiān)控指標(biāo)數(shù)據(jù)，監(jiān)控直播質(zhì)量。

衛(wèi)生保?。?/p>

商業(yè)智能工具，采集智能手表，智能手環(huán)中的健康數(shù)據(jù)，跟蹤關(guān)鍵指標(biāo)和業(yè)務(wù)的總體健康情況；

智慧家居：

居家物聯(lián)網(wǎng)平臺，采集家居智能設(shè)備數(shù)據(jù)，實現(xiàn)遠(yuǎn)程監(jiān)控。

網(wǎng)絡(luò)：

網(wǎng)絡(luò)監(jiān)控系統(tǒng)，實時呈現(xiàn)網(wǎng)絡(luò)延時、帶寬使用情況。

02

時序數(shù)據(jù)的需求

在上述場景中，特別在IoT物聯(lián)網(wǎng)以及OPS運維監(jiān)控領(lǐng)域，存在海量的監(jiān)控數(shù)據(jù)需要存儲管理。以華為云Cloud Eye Service(CES)服務(wù)為例，單個Region需要監(jiān)控7000多萬個監(jiān)控指標(biāo)，每秒需要處理90萬個上報的監(jiān)控指標(biāo)項，假設(shè)每個指標(biāo)50個字節(jié)，一年的監(jiān)控數(shù)據(jù)有1PB；自動駕駛的車輛一天各種傳感器監(jiān)測數(shù)據(jù)就80G。 傳統(tǒng)關(guān)系型數(shù)據(jù)庫很難支撐這么大的數(shù)據(jù)量以及這么大的寫入壓力，Hadoop大數(shù)據(jù)解決方案以及現(xiàn)有的時序數(shù)據(jù)庫也會面臨非常大的挑戰(zhàn)。大規(guī)模IoT物聯(lián)網(wǎng)，以及公有云規(guī)模的運維監(jiān)控場景，對時序數(shù)據(jù)庫的需求主要包括：

持續(xù)高性能寫入：

監(jiān)控指標(biāo)往往以固定的頻率采集，部分工業(yè)物聯(lián)網(wǎng)場景傳感器的采集頻率非常高，有的已經(jīng)達(dá)到100ns，公有云運維監(jiān)控場景基本也是秒級采集。時序數(shù)據(jù)庫需要支持7*24小時不中斷的持續(xù)高壓力寫入。

高性能查詢：

時序數(shù)據(jù)庫的價值在于數(shù)據(jù)分析，而且有較高的實時性要求，典型分析任務(wù)如異常檢測及預(yù)測性維護(hù)，這類時序分析任務(wù)需要頻繁的從數(shù)據(jù)庫中獲取大量時序數(shù)據(jù)，為了保證分析的實時性，時序數(shù)據(jù)庫需要能快速響應(yīng)海量數(shù)據(jù)查詢請求。

低存儲成本：

IoT物聯(lián)網(wǎng)及運維監(jiān)控場景的數(shù)據(jù)量呈現(xiàn)指數(shù)級增長，數(shù)據(jù)量是典型的OLTP數(shù)據(jù)庫場景的千倍以上，并且對成本非常敏感，需要提供低成本的存儲方案。

支持海量時間線：

在大規(guī)模IoT物聯(lián)網(wǎng)及公有云規(guī)模的運維場景，需要監(jiān)控的指標(biāo)通常在千萬級甚至億級，時序數(shù)據(jù)庫要能支持億級時間線的管理能力；

彈性：

監(jiān)控場景也存在業(yè)務(wù)突發(fā)增長的場景，例如：華為Welink服務(wù)的運維監(jiān)控數(shù)據(jù)在疫情期間暴增100倍，時序數(shù)據(jù)庫需要提供足夠靈敏的彈性伸縮能力，能夠快速擴容以應(yīng)對突發(fā)的業(yè)務(wù)增長。

03

開源時序數(shù)據(jù)庫能力

過去10年，隨著移動互聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能、物聯(lián)網(wǎng)、機器學(xué)習(xí)等相關(guān)技術(shù)的快速應(yīng)用和發(fā)展，涌現(xiàn)出許多時序數(shù)據(jù)庫，因為不同數(shù)據(jù)庫采用的技術(shù)和設(shè)計初衷不一樣，所以在解決上述時序數(shù)據(jù)需求上，他們之間也表現(xiàn)出現(xiàn)較大的差異，本文在下面內(nèi)容將選擇使用最多的幾種開源時序數(shù)據(jù)庫為分析對象進(jìn)行討論。

OpenTSDB

OpenTSDB基于Hbase數(shù)據(jù)庫作為底層存儲，向上封裝自己的邏輯層和對外接口層。這種架構(gòu)可以充分利用Hbase的特性實現(xiàn)了數(shù)據(jù)的高可用和較好的寫入性能。但相比Influxdb，OpenTSDB數(shù)據(jù)棧較長，在讀寫性能和數(shù)據(jù)壓縮方面都還有進(jìn)一步優(yōu)化的空間。

InfluxDB

Influxdb是業(yè)界比較流行的一個時間序列數(shù)據(jù)庫，它擁有自研的數(shù)據(jù)存儲引擎，引入倒排索引增強了多維條件查詢的功能，非常適合在時序業(yè)務(wù)場景中使用。由于時序洞察報表和時序數(shù)據(jù)聚合分析，是時序數(shù)據(jù)庫主要的查詢應(yīng)用場景，每次查詢可能需要處理上億數(shù)據(jù)的分組聚合運算，所以在這方面，InfluxDB采用的火山模型對聚合查詢性能影響較大。

Timescale

TimeScale是一個基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫postgresql改造的時間序列數(shù)據(jù)庫，繼承了postgresql許多優(yōu)點，比如支持SQL，支持軌跡數(shù)據(jù)存儲，支持join，可擴展等等，讀寫性能好。TimeScale采用固定schema，數(shù)據(jù)占用空間大，對于時序業(yè)務(wù)長期相對固定且對數(shù)據(jù)存儲成本不敏感的業(yè)務(wù)來說，也是一種選擇。

04

GaussDB(For Influx)的出現(xiàn)

針對高性能寫入、海量時間線和高數(shù)據(jù)壓縮的需求，當(dāng)前還未能有比較好的開源解決方案。GaussDB（For Influx）汲取了開源各家之長，設(shè)計了云原生架構(gòu)的時序數(shù)據(jù)庫。架構(gòu)如下圖所示。

相比現(xiàn)有的開源時序數(shù)據(jù)庫，架構(gòu)設(shè)計上有以下兩方面的考慮：

存儲與計算分離

存儲計算分離，一方面利用成熟的分布式存儲系統(tǒng)提高系統(tǒng)的可靠性。監(jiān)控數(shù)據(jù)一直持續(xù)高性能寫入，同時還有大量的查詢業(yè)務(wù)，任何系統(tǒng)故障導(dǎo)致業(yè)務(wù)中斷甚至數(shù)據(jù)丟失都會造成嚴(yán)重的業(yè)務(wù)影響，而利用經(jīng)過驗證的成熟的分布式存儲系統(tǒng)，能夠顯著的提升系統(tǒng)可靠性，降低數(shù)據(jù)丟失風(fēng)險，并明顯縮短構(gòu)建本系統(tǒng)的時間。

另一方面，解除在傳統(tǒng)Share Nothing架構(gòu)下，數(shù)據(jù)和節(jié)點物理綁定的約束，數(shù)據(jù)只是邏輯上歸宿于某個計算節(jié)點，使得計算節(jié)點無狀態(tài)化。這樣在擴容計算節(jié)點時，可以避免在計算節(jié)點間遷移大量的數(shù)據(jù)，只需要邏輯上將部分?jǐn)?shù)據(jù)從一個節(jié)點移交給另外一個節(jié)點即可，可以將集群擴容的耗時從以天為單位縮短為分鐘級別。

再一方面，通過將多副本復(fù)制從計算節(jié)點卸載到分布式存儲節(jié)點，可以避免用戶以Cloud Hosting形態(tài)在云上自建數(shù)據(jù)庫時，分布式數(shù)據(jù)庫和分布式存儲分別做3副本復(fù)制導(dǎo)致總共9副本冗余的問題，能夠顯著降低存儲成本。

Kernel Bypass

為了避免在用戶態(tài)內(nèi)核態(tài)來回拷貝數(shù)據(jù)帶來的性能損失，GaussDB（for Influx）系統(tǒng)端到端考慮Kernel bypass設(shè)計，沒有選擇使用標(biāo)準(zhǔn)的分布式塊或分布式文件服務(wù)，而是定制的針對數(shù)據(jù)庫設(shè)計的分布式存儲，對外暴露用戶態(tài)接口，計算節(jié)點采用容器化部署，通過專用存儲網(wǎng)絡(luò)直接和存儲節(jié)點通信。

除了架構(gòu)之外，GaussDB（for Influx）還針對IoT物聯(lián)網(wǎng)及運維監(jiān)控場景的其他需求做了如下優(yōu)化：

1、寫優(yōu)化的LSM-Tree布局和異步Logging方案，相比當(dāng)前時序數(shù)據(jù)庫提升94%寫性能。

2、通過向量化查詢引擎，ARC Block Cache，以及Aggregation Result Cache提升聚合查詢性能，相比當(dāng)前時序數(shù)據(jù)庫提升最高可達(dá)9倍；

3、設(shè)計針對時序數(shù)據(jù)分布特征的壓縮算法，壓縮率相比Gorilla提升2倍，并自動將冷數(shù)據(jù)分級到對象存儲，降低60%存儲成本；

4、優(yōu)化海量時間線的索引算法，提升索引效率，在千萬時間線量級下，寫入性能是當(dāng)前時序數(shù)據(jù)庫的5倍；

GaussDB（for Influx）成功保障了公司welink和云監(jiān)控CES兩大服務(wù)之后上線商用，接下來我們還將探索如何在海量數(shù)據(jù)中尋找有價值數(shù)據(jù)的高效分析方法，為用戶提供更加合適的分析和洞察能力。

參考文獻(xiàn):

https://zhuanlan.zhihu.com/p/32709932

https://www.cnblogs.com/jpfss/p/12183214.html

責(zé)任編輯：xj

原文標(biāo)題：大廠為啥親睞時序數(shù)據(jù)庫？讀完你就懂了

文章出處：【微信公眾號：華為開發(fā)者社區(qū)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。