小说阅读网,好看的历史书籍推荐

首頁 - 關(guān)于我們 - 新聞活動(dòng) - 物聯(lián)網(wǎng)場(chǎng)景中，我們?nèi)绾芜x擇時(shí)序數(shù)據(jù)庫？

物聯(lián)網(wǎng)場(chǎng)景中，我們?nèi)绾芜x擇時(shí)序數(shù)據(jù)庫？

2022-11-10新聞

如今時(shí)序數(shù)據(jù)的應(yīng)用場(chǎng)景十分廣泛，許多類型的數(shù)據(jù)都是時(shí)間序列數(shù)據(jù)：

金融市場(chǎng)交易
傳感器測(cè)量（水冷、高溫、地震...）
服務(wù)器監(jiān)控（CPU、內(nèi)存、磁盤...）
資源消耗（能源、電力...）
人體健康（心率、血氧濃度...）
網(wǎng)絡(luò)訪問

通過保留數(shù)據(jù)固有的時(shí)間序列性質(zhì)，我們可以記錄下事物是如何隨時(shí)間變化的事實(shí)，正因如此，這一反應(yīng)真實(shí)的客觀屬性使得時(shí)序數(shù)據(jù)在特定的場(chǎng)景中充滿了商業(yè)價(jià)值：通過分析時(shí)序數(shù)據(jù)，決策者可以了解到生產(chǎn)和業(yè)務(wù)中的細(xì)微變化，從而對(duì)資源優(yōu)化、跟蹤、預(yù)測(cè)、商業(yè)智能等方面進(jìn)行優(yōu)化。

在時(shí)序數(shù)據(jù)庫成為熱點(diǎn)之前，時(shí)序數(shù)據(jù)通常使用 MySQL 或 PostgreSQL 等關(guān)系數(shù)據(jù)庫進(jìn)行處理。但自2010年以來，隨著互聯(lián)網(wǎng)和通信技術(shù)的發(fā)展，網(wǎng)絡(luò)中產(chǎn)生的時(shí)間序列數(shù)據(jù)量有了爆炸式的增長(zhǎng)，傳統(tǒng)的數(shù)據(jù)庫已經(jīng)無法處理這種萬億級(jí)的海量數(shù)據(jù)。不僅如此，現(xiàn)代業(yè)務(wù)對(duì)數(shù)據(jù)價(jià)值挖掘的需求已不僅僅停留在簡(jiǎn)單計(jì)算和繪制圖表的層面上，而是需要更多精細(xì)、復(fù)雜的計(jì)算分析。

如何以一種高性能的方式記錄、查詢和分析如此大規(guī)模的數(shù)據(jù)，成為了一個(gè)難題。時(shí)序數(shù)據(jù)庫(time-series database)應(yīng)運(yùn)而生。以對(duì)數(shù)據(jù)價(jià)值嗅覺最敏感的金融領(lǐng)域?yàn)槔?，早?0年前，華爾街就已經(jīng)開始使用時(shí)序數(shù)據(jù)庫對(duì)股票交易數(shù)據(jù)進(jìn)行實(shí)時(shí)的計(jì)算分析。

那么，時(shí)序數(shù)據(jù)庫與“普通”數(shù)據(jù)庫在技術(shù)上有哪些區(qū)別呢？

我們假定“普通”數(shù)據(jù)庫是 MySQL、Oracle 之類的 OLTP (Online Transaction Processing) 事務(wù)型數(shù)據(jù)庫。

01.

首先，大部分時(shí)序數(shù)據(jù)庫的查詢場(chǎng)景可以認(rèn)為是 OLAP（Online Analytical Processing ）分析型數(shù)據(jù)庫場(chǎng)景。具體地說，時(shí)序數(shù)據(jù)庫的讀取負(fù)載主要可以分為兩種，一種是對(duì)指定時(shí)間序列在指定時(shí)間段內(nèi)數(shù)據(jù)的查詢，如查詢某個(gè)設(shè)備或某支股票最新一小時(shí)的數(shù)據(jù)等；另一種是對(duì)大量數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析，如分析某支股票、甚至是所有股票在過去一周內(nèi)的平均價(jià)格。這兩種場(chǎng)景都算是典型的 OLAP 的讀取場(chǎng)景。因此，時(shí)序數(shù)據(jù)庫具有大部分 OLAP 數(shù)據(jù)庫的特點(diǎn)，如列存、會(huì)對(duì)數(shù)據(jù)做壓縮、支持復(fù)雜的查詢語句等等。

02.

其次，從寫入負(fù)載來分析，時(shí)序數(shù)據(jù)庫的場(chǎng)景有大量數(shù)據(jù)的實(shí)時(shí)寫入，而非單行數(shù)據(jù)的寫入與修改。由于時(shí)序數(shù)據(jù)庫的寫入負(fù)載通常很高，如每秒幾百萬甚至幾千萬條數(shù)據(jù)，所以時(shí)序數(shù)據(jù)庫的存儲(chǔ)引擎往往是基于對(duì)大量寫入更加友好的 LSM Tree(Log Structured Merge Tree)，而非對(duì)主鍵點(diǎn)查詢、主鍵范圍查詢以及單行修改與更新更友好的 B+ 樹。開發(fā)高效的時(shí)序數(shù)據(jù)庫存儲(chǔ)引擎，需要扎實(shí)的操作系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、分布式系統(tǒng)、體系結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)與算法等計(jì)算機(jī)基礎(chǔ)。

03.

第三，時(shí)序數(shù)據(jù)庫需要支持很多時(shí)序場(chǎng)景特有的分析語句與函數(shù)。一些常見的語句與函數(shù)有：降采樣、插值、滑動(dòng)平均、時(shí)間滑動(dòng)平均、累積和、window join、context by、pivot by 等等。要高效地（往往是向量化地）支持這些查詢語句并不是一件非常容易的事情。

04.

第四，流數(shù)據(jù)的處理。對(duì)時(shí)序數(shù)據(jù)的離線分析屬于批處理的范疇，而還有許多時(shí)序數(shù)據(jù)場(chǎng)景則可以抽象成另外一個(gè)我們稱之為流數(shù)據(jù)的計(jì)算場(chǎng)景：有數(shù)據(jù)不停地產(chǎn)生，且需要低延時(shí)地對(duì)這些數(shù)據(jù)做即時(shí)的響應(yīng)與計(jì)算。在時(shí)序領(lǐng)域，對(duì)于流數(shù)據(jù)的處理，以往的做法往往是使用 flink 等單獨(dú)的流數(shù)據(jù)處理平臺(tái)，這當(dāng)然也能夠解決問題，但會(huì)導(dǎo)致至少兩個(gè)問題，第一是需要維護(hù)時(shí)序數(shù)據(jù)庫與 flink 這兩套系統(tǒng)，使得運(yùn)維成本大大提升；第二個(gè)問題則可能更加致命，那就是流數(shù)據(jù)的處理是否能夠與批數(shù)據(jù)處理一致，而如果產(chǎn)生不一致，則可能會(huì)對(duì)業(yè)務(wù)場(chǎng)景帶來毀滅性的影響（熟悉機(jī)器學(xué)習(xí)的同學(xué)應(yīng)該知道機(jī)器學(xué)習(xí)的訓(xùn)練場(chǎng)景、測(cè)試場(chǎng)景與服務(wù)場(chǎng)景必須達(dá)到高度的一致）。如果時(shí)序數(shù)據(jù)庫能夠推出針對(duì)時(shí)序場(chǎng)景的特殊流數(shù)據(jù)處理子系統(tǒng)，并且能夠達(dá)到“流批一體”，就可以保證批數(shù)據(jù)與流數(shù)據(jù)處理的結(jié)果完全一致。

數(shù)據(jù)庫的性能往往很大程度上由存儲(chǔ)引擎決定。如何針對(duì)不同的應(yīng)用場(chǎng)景設(shè)計(jì)高性能的存儲(chǔ)引擎一直是數(shù)據(jù)庫開發(fā)的難題。而在時(shí)序數(shù)據(jù)庫的場(chǎng)景下，究竟該怎么設(shè)計(jì)一個(gè)存儲(chǔ)引擎，至今仍是一個(gè)沒有標(biāo)準(zhǔn)答案的開放性問題。

長(zhǎng)按關(guān)注

新浪微博