時(shí)序數(shù)據(jù)庫(kù)忽然火了起來(lái)。Facebook開源了beringei時(shí)序數(shù)據(jù)庫(kù),基于PostgreSQL打造的時(shí)序數(shù)據(jù)庫(kù)TimeScaleDB也開源了。時(shí)序數(shù)據(jù)庫(kù)作為物聯(lián)網(wǎng)方向一個(gè)非常重要的服務(wù),業(yè)界的頻頻發(fā)聲,正說(shuō)明各家企業(yè)已經(jīng)迫不及待的擁抱物聯(lián)網(wǎng)時(shí)代的到來(lái)。
本文會(huì)從時(shí)序數(shù)據(jù)庫(kù)的基本概念、應(yīng)用場(chǎng)景、需求與能力等方面一一展開,帶你了解時(shí)序數(shù)據(jù)庫(kù)的前世今生。
01
應(yīng)用場(chǎng)景
時(shí)序數(shù)據(jù)庫(kù)是一種針對(duì)時(shí)序數(shù)據(jù)高度優(yōu)化的垂直型數(shù)據(jù)庫(kù)。在制造業(yè)、銀行金融、DevOps、社交媒體、衛(wèi)生保健、智慧家居、網(wǎng)絡(luò)等行業(yè)都有大量適合時(shí)序數(shù)據(jù)庫(kù)的應(yīng)用場(chǎng)景:
制造業(yè):
比如輕量化的生產(chǎn)管理云平臺(tái),運(yùn)用物聯(lián)網(wǎng)和大數(shù)據(jù)技術(shù),采集、分析生產(chǎn)過程產(chǎn)生的各類時(shí)序數(shù)據(jù),實(shí)時(shí)呈現(xiàn)生產(chǎn)現(xiàn)場(chǎng)的生產(chǎn)進(jìn)度、目標(biāo)達(dá)成狀況,以及人、機(jī)、料的利用狀況,讓生產(chǎn)現(xiàn)場(chǎng)完全透明,提高生產(chǎn)效率。
銀行金融:
傳統(tǒng)證券、新興的加密數(shù)字貨幣的交易系統(tǒng),采集、分析交易過程中產(chǎn)生的時(shí)序數(shù)據(jù),實(shí)現(xiàn)金融量化交易。
DevOps:
IT基礎(chǔ)設(shè)施和應(yīng)用的運(yùn)維系統(tǒng),采集、分析設(shè)備運(yùn)行和應(yīng)用服務(wù)運(yùn)行監(jiān)控指標(biāo),實(shí)時(shí)掌握設(shè)備和應(yīng)用的健康狀態(tài)。
社交媒體:
社交APP大數(shù)據(jù)平臺(tái),跟蹤用戶交互數(shù)據(jù),分析用戶習(xí)慣、改善用戶體驗(yàn);直播系統(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)平臺(tái),采集家居智能設(shè)備數(shù)據(jù),實(shí)現(xiàn)遠(yuǎn)程監(jiān)控。
網(wǎng)絡(luò):
網(wǎng)絡(luò)監(jiān)控系統(tǒng),實(shí)時(shí)呈現(xiàn)網(wǎng)絡(luò)延時(shí)、帶寬使用情況。
02
時(shí)序數(shù)據(jù)的需求
在上述場(chǎng)景中,特別在IoT物聯(lián)網(wǎng)以及OPS運(yùn)維監(jiān)控領(lǐng)域,存在海量的監(jiān)控?cái)?shù)據(jù)需要存儲(chǔ)管理。以華為云Cloud Eye Service(CES)服務(wù)為例,單個(gè)Region需要監(jiān)控7000多萬(wàn)個(gè)監(jiān)控指標(biāo),每秒需要處理90萬(wàn)個(gè)上報(bào)的監(jiān)控指標(biāo)項(xiàng),假設(shè)每個(gè)指標(biāo)50個(gè)字節(jié),一年的監(jiān)控?cái)?shù)據(jù)有1PB;自動(dòng)駕駛的車輛一天各種傳感器監(jiān)測(cè)數(shù)據(jù)就80G。 傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)很難支撐這么大的數(shù)據(jù)量以及這么大的寫入壓力,Hadoop大數(shù)據(jù)解決方案以及現(xiàn)有的時(shí)序數(shù)據(jù)庫(kù)也會(huì)面臨非常大的挑戰(zhàn)。大規(guī)模IoT物聯(lián)網(wǎng),以及公有云規(guī)模的運(yùn)維監(jiān)控場(chǎng)景,對(duì)時(shí)序數(shù)據(jù)庫(kù)的需求主要包括:
持續(xù)高性能寫入:
監(jiān)控指標(biāo)往往以固定的頻率采集,部分工業(yè)物聯(lián)網(wǎng)場(chǎng)景傳感器的采集頻率非常高,有的已經(jīng)達(dá)到100ns,公有云運(yùn)維監(jiān)控場(chǎng)景基本也是秒級(jí)采集。時(shí)序數(shù)據(jù)庫(kù)需要支持7*24小時(shí)不中斷的持續(xù)高壓力寫入。
高性能查詢:
時(shí)序數(shù)據(jù)庫(kù)的價(jià)值在于數(shù)據(jù)分析,而且有較高的實(shí)時(shí)性要求,典型分析任務(wù)如異常檢測(cè)及預(yù)測(cè)性維護(hù),這類時(shí)序分析任務(wù)需要頻繁的從數(shù)據(jù)庫(kù)中獲取大量時(shí)序數(shù)據(jù),為了保證分析的實(shí)時(shí)性,時(shí)序數(shù)據(jù)庫(kù)需要能快速響應(yīng)海量數(shù)據(jù)查詢請(qǐng)求。
低存儲(chǔ)成本:
IoT物聯(lián)網(wǎng)及運(yùn)維監(jiān)控場(chǎng)景的數(shù)據(jù)量呈現(xiàn)指數(shù)級(jí)增長(zhǎng),數(shù)據(jù)量是典型的OLTP數(shù)據(jù)庫(kù)場(chǎng)景的千倍以上,并且對(duì)成本非常敏感,需要提供低成本的存儲(chǔ)方案。
支持海量時(shí)間線:
在大規(guī)模IoT物聯(lián)網(wǎng)及公有云規(guī)模的運(yùn)維場(chǎng)景,需要監(jiān)控的指標(biāo)通常在千萬(wàn)級(jí)甚至億級(jí),時(shí)序數(shù)據(jù)庫(kù)要能支持億級(jí)時(shí)間線的管理能力;
彈性:
監(jiān)控場(chǎng)景也存在業(yè)務(wù)突發(fā)增長(zhǎng)的場(chǎng)景,例如:華為Welink服務(wù)的運(yùn)維監(jiān)控?cái)?shù)據(jù)在疫情期間暴增100倍,時(shí)序數(shù)據(jù)庫(kù)需要提供足夠靈敏的彈性伸縮能力,能夠快速擴(kuò)容以應(yīng)對(duì)突發(fā)的業(yè)務(wù)增長(zhǎng)。
03
開源時(shí)序數(shù)據(jù)庫(kù)能力
過去10年,隨著移動(dòng)互聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能、物聯(lián)網(wǎng)、機(jī)器學(xué)習(xí)等相關(guān)技術(shù)的快速應(yīng)用和發(fā)展,涌現(xiàn)出許多時(shí)序數(shù)據(jù)庫(kù),因?yàn)椴煌瑪?shù)據(jù)庫(kù)采用的技術(shù)和設(shè)計(jì)初衷不一樣,所以在解決上述時(shí)序數(shù)據(jù)需求上,他們之間也表現(xiàn)出現(xiàn)較大的差異,本文在下面內(nèi)容將選擇使用最多的幾種開源時(shí)序數(shù)據(jù)庫(kù)為分析對(duì)象進(jìn)行討論。
OpenTSDB
OpenTSDB基于Hbase數(shù)據(jù)庫(kù)作為底層存儲(chǔ),向上封裝自己的邏輯層和對(duì)外接口層。這種架構(gòu)可以充分利用Hbase的特性實(shí)現(xiàn)了數(shù)據(jù)的高可用和較好的寫入性能。但相比Influxdb,OpenTSDB數(shù)據(jù)棧較長(zhǎng),在讀寫性能和數(shù)據(jù)壓縮方面都還有進(jìn)一步優(yōu)化的空間。
InfluxDB
Influxdb是業(yè)界比較流行的一個(gè)時(shí)間序列數(shù)據(jù)庫(kù),它擁有自研的數(shù)據(jù)存儲(chǔ)引擎,引入倒排索引增強(qiáng)了多維條件查詢的功能,非常適合在時(shí)序業(yè)務(wù)場(chǎng)景中使用。由于時(shí)序洞察報(bào)表和時(shí)序數(shù)據(jù)聚合分析,是時(shí)序數(shù)據(jù)庫(kù)主要的查詢應(yīng)用場(chǎng)景,每次查詢可能需要處理上億數(shù)據(jù)的分組聚合運(yùn)算,所以在這方面,InfluxDB采用的火山模型對(duì)聚合查詢性能影響較大。
Timescale
TimeScale是一個(gè)基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)postgresql改造的時(shí)間序列數(shù)據(jù)庫(kù),繼承了postgresql許多優(yōu)點(diǎn),比如支持SQL,支持軌跡數(shù)據(jù)存儲(chǔ),支持join,可擴(kuò)展等等,讀寫性能好。TimeScale采用固定schema,數(shù)據(jù)占用空間大,對(duì)于時(shí)序業(yè)務(wù)長(zhǎng)期相對(duì)固定且對(duì)數(shù)據(jù)存儲(chǔ)成本不敏感的業(yè)務(wù)來(lái)說(shuō),也是一種選擇。
04
針對(duì)高性能寫入、海量時(shí)間線和高數(shù)據(jù)壓縮的需求,當(dāng)前還未能有比較好的開源解決方案。GaussDB(For Influx)汲取了開源各家之長(zhǎng),設(shè)計(jì)了云原生架構(gòu)的時(shí)序數(shù)據(jù)庫(kù)。架構(gòu)如下圖所示。
相比現(xiàn)有的開源時(shí)序數(shù)據(jù)庫(kù),架構(gòu)設(shè)計(jì)上有以下兩方面的考慮:
存儲(chǔ)與計(jì)算分離
存儲(chǔ)計(jì)算分離,一方面利用成熟的分布式存儲(chǔ)系統(tǒng)提高系統(tǒng)的可靠性。監(jiān)控?cái)?shù)據(jù)一直持續(xù)高性能寫入,同時(shí)還有大量的查詢業(yè)務(wù),任何系統(tǒng)故障導(dǎo)致業(yè)務(wù)中斷甚至數(shù)據(jù)丟失都會(huì)造成嚴(yán)重的業(yè)務(wù)影響,而利用經(jīng)過驗(yàn)證的成熟的分布式存儲(chǔ)系統(tǒng),能夠顯著的提升系統(tǒng)可靠性,降低數(shù)據(jù)丟失風(fēng)險(xiǎn),并明顯縮短構(gòu)建本系統(tǒng)的時(shí)間。
另一方面,解除在傳統(tǒng)Share Nothing架構(gòu)下,數(shù)據(jù)和節(jié)點(diǎn)物理綁定的約束,數(shù)據(jù)只是邏輯上歸宿于某個(gè)計(jì)算節(jié)點(diǎn),使得計(jì)算節(jié)點(diǎn)無(wú)狀態(tài)化。這樣在擴(kuò)容計(jì)算節(jié)點(diǎn)時(shí),可以避免在計(jì)算節(jié)點(diǎn)間遷移大量的數(shù)據(jù),只需要邏輯上將部分?jǐn)?shù)據(jù)從一個(gè)節(jié)點(diǎn)移交給另外一個(gè)節(jié)點(diǎn)即可,可以將集群擴(kuò)容的耗時(shí)從以天為單位縮短為分鐘級(jí)別。
再一方面,通過將多副本復(fù)制從計(jì)算節(jié)點(diǎn)卸載到分布式存儲(chǔ)節(jié)點(diǎn),可以避免用戶以Cloud Hosting形態(tài)在云上自建數(shù)據(jù)庫(kù)時(shí),分布式數(shù)據(jù)庫(kù)和分布式存儲(chǔ)分別做3副本復(fù)制導(dǎo)致總共9副本冗余的問題,能夠顯著降低存儲(chǔ)成本。
Kernel Bypass
為了避免在用戶態(tài)內(nèi)核態(tài)來(lái)回拷貝數(shù)據(jù)帶來(lái)的性能損失,GaussDB(for Influx)系統(tǒng)端到端考慮Kernel bypass設(shè)計(jì),沒有選擇使用標(biāo)準(zhǔn)的分布式塊或分布式文件服務(wù),而是定制的針對(duì)數(shù)據(jù)庫(kù)設(shè)計(jì)的分布式存儲(chǔ),對(duì)外暴露用戶態(tài)接口,計(jì)算節(jié)點(diǎn)采用容器化部署,通過專用存儲(chǔ)網(wǎng)絡(luò)直接和存儲(chǔ)節(jié)點(diǎn)通信。
除了架構(gòu)之外,GaussDB(for Influx)還針對(duì)IoT物聯(lián)網(wǎng)及運(yùn)維監(jiān)控場(chǎng)景的其他需求做了如下優(yōu)化:
1、寫優(yōu)化的LSM-Tree布局和異步Logging方案,相比當(dāng)前時(shí)序數(shù)據(jù)庫(kù)提升94%寫性能。
2、通過向量化查詢引擎,ARC Block Cache,以及Aggregation Result Cache提升聚合查詢性能,相比當(dāng)前時(shí)序數(shù)據(jù)庫(kù)提升最高可達(dá)9倍;
3、設(shè)計(jì)針對(duì)時(shí)序數(shù)據(jù)分布特征的壓縮算法,壓縮率相比Gorilla提升2倍,并自動(dòng)將冷數(shù)據(jù)分級(jí)到對(duì)象存儲(chǔ),降低60%存儲(chǔ)成本;
4、優(yōu)化海量時(shí)間線的索引算法,提升索引效率,在千萬(wàn)時(shí)間線量級(jí)下,寫入性能是當(dāng)前時(shí)序數(shù)據(jù)庫(kù)的5倍;
GaussDB(for Influx)成功保障了公司welink和云監(jiān)控CES兩大服務(wù)之后上線商用,接下來(lái)我們還將探索如何在海量數(shù)據(jù)中尋找有價(jià)值數(shù)據(jù)的高效分析方法,為用戶提供更加合適的分析和洞察能力。
參考文獻(xiàn):
https://zhuanlan.zhihu.com/p/32709932
https://www.cnblogs.com/jpfss/p/12183214.html
責(zé)任編輯:xj
原文標(biāo)題:大廠為啥親睞時(shí)序數(shù)據(jù)庫(kù)?讀完你就懂了
文章出處:【微信公眾號(hào):華為開發(fā)者社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
-
數(shù)據(jù)庫(kù)
+關(guān)注
關(guān)注
7文章
3711瀏覽量
64023 -
時(shí)序
+關(guān)注
關(guān)注
5文章
370瀏覽量
37186
原文標(biāo)題:大廠為啥親睞時(shí)序數(shù)據(jù)庫(kù)?讀完你就懂了
文章出處:【微信號(hào):Huawei_Developer,微信公眾號(hào):華為開發(fā)者社區(qū)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論