盗墓笔记第二季,天下高月小说,好看的小说

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

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

2022-11-10新聞

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

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

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

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

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

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

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

01.

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

02.

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

03.

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

04.

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

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

長按關(guān)注

新浪微博