時(shí)序數(shù)據(jù)庫系列

時(shí)序數(shù)據(jù)庫-01-時(shí)序數(shù)據(jù)庫有哪些？為什么要使用

時(shí)序數(shù)據(jù)庫-02-聊一聊時(shí)序數(shù)據(jù)庫

時(shí)序數(shù)據(jù)庫-03-pentsdb-分布式時(shí)序數(shù)據(jù)庫

時(shí)序數(shù)據(jù)庫-04-InfluxData-分布式時(shí)序數(shù)據(jù)庫

時(shí)序數(shù)據(jù)庫-05-TDengine 是一款開源、高性能、云原生的時(shí)序數(shù)據(jù)庫 (Time-Series Database, TSDB)

時(shí)序數(shù)據(jù)庫-05-TDengine Time-Series Database, TSDB

時(shí)序數(shù)據(jù)庫-05-TDengine windows11 WSL 安裝實(shí)戰(zhàn)筆記 docker

時(shí)序數(shù)據(jù)庫-06-01-vm VictoriaMetrics 快速、經(jīng)濟(jì)高效的監(jiān)控解決方案和時(shí)間序列數(shù)據(jù)庫

時(shí)序數(shù)據(jù)庫-06-02-vm VictoriaMetrics install on docker 安裝 vm

時(shí)序數(shù)據(jù)庫-06-03-vm VictoriaMetrics java 整合

時(shí)序數(shù)據(jù)庫-06-04-vm VictoriaMetrics storage 存儲原理簡介

時(shí)序數(shù)據(jù)庫-06-05-vm VictoriaMetrics cluster 集群原理

時(shí)序數(shù)據(jù)庫-06-06-vm VictoriaMetrics cluster 集群訪問方式

3.基本特點(diǎn)

時(shí)序業(yè)務(wù)和普通業(yè)務(wù)在很多方面都有巨大的區(qū)別，歸納起來主要有如下幾個(gè)方面：

3.1 持續(xù)產(chǎn)生海量數(shù)據(jù)，沒有波峰波谷

舉幾個(gè)簡單的例子，比如類似哨兵的監(jiān)控系統(tǒng)，假如現(xiàn)在系統(tǒng)監(jiān)控1w臺服務(wù)器的各類指標(biāo)，每臺服務(wù)器每秒采集100種metrics，這樣每秒鐘將會有100w的TPS。再比如說，現(xiàn)在比較流行的運(yùn)動手環(huán)，假如當(dāng)前有100w人佩戴，每個(gè)手環(huán)一秒只采集3種metrcis(心跳、脈搏、步數(shù))，這樣每秒鐘也會產(chǎn)生300w的TPS。

3.2 數(shù)據(jù)都是插入操作，基本沒有更新刪除操作

時(shí)序業(yè)務(wù)產(chǎn)生的數(shù)據(jù)很少有更新刪除的操作，基于這樣的事實(shí)，在時(shí)序數(shù)據(jù)庫架構(gòu)設(shè)計(jì)上會有很大的簡化。

3.3 近期數(shù)據(jù)關(guān)注度更高，未來會更關(guān)注流式處理這個(gè)環(huán)節(jié)，時(shí)間久遠(yuǎn)的數(shù)據(jù)極少被訪問，甚至可以丟棄

這個(gè)很容易理解，哨兵系統(tǒng)我們通常最關(guān)心最近一小時(shí)的數(shù)據(jù)，最多看看最近3天的數(shù)據(jù)，很少去看3天以前的數(shù)據(jù)。隨著流式計(jì)算的到來，時(shí)序數(shù)據(jù)在以后的發(fā)展中必然會更關(guān)注即時(shí)數(shù)據(jù)的價(jià)值，這部分?jǐn)?shù)據(jù)的價(jià)值毫無疑問也是最大的。數(shù)據(jù)產(chǎn)生之后就可以根據(jù)某些規(guī)則進(jìn)行報(bào)警是一個(gè)非常常見并重要的場景，報(bào)警時(shí)效性越高，對業(yè)務(wù)越有利。

3.4 數(shù)據(jù)存在多個(gè)維度的標(biāo)簽，往往需要多維度聯(lián)合查詢以及統(tǒng)計(jì)查詢。

時(shí)序數(shù)據(jù)另一個(gè)非常重要的功能是多維度聚合統(tǒng)計(jì)查詢，比如業(yè)務(wù)需要統(tǒng)計(jì)最近一小時(shí)廣告主google發(fā)布在USA地區(qū)的廣告點(diǎn)擊率和總收入分別是多少，這是一個(gè)典型的多維度聚合統(tǒng)計(jì)查詢需求。這個(gè)需求通常對實(shí)效性要求不高，但對查詢聚合性能有比較高的要求。

4.TSDB核心特性

總結(jié)起來TSDB需要關(guān)注的技術(shù)點(diǎn)主要有這么幾個(gè)：

4.1 高吞吐量寫入能力

這是針對時(shí)序業(yè)務(wù)持續(xù)產(chǎn)生海量數(shù)據(jù)這么一個(gè)特點(diǎn)量身定做的，當(dāng)前要實(shí)現(xiàn)系統(tǒng)高吞吐量寫入，必須要滿足兩個(gè)基本技術(shù)點(diǎn)要求：系統(tǒng)具有水平擴(kuò)展性和單機(jī)LSM體系結(jié)構(gòu)。系統(tǒng)具有水平擴(kuò)展性很容易理解，單機(jī)肯定是扛不住的，系統(tǒng)必須是集群式的，而且要容易加節(jié)點(diǎn)擴(kuò)展，說到底，就是擴(kuò)容的時(shí)候?qū)I(yè)務(wù)無感知，目前Hadoop生態(tài)系統(tǒng)基本上都可以做到這一點(diǎn)；而LSM體系結(jié)構(gòu)是用來保證單臺機(jī)器的高吞吐量寫入，LSM結(jié)構(gòu)下數(shù)據(jù)寫入只需要寫入內(nèi)存以及追加寫入日志，這樣就不再需要隨機(jī)將數(shù)據(jù)寫入磁盤，HBase、Kudu以及Druid等對寫入性能有要求的系統(tǒng)目前都采用的這種結(jié)構(gòu)。

4.2 數(shù)據(jù)分級存儲/TTL

這是針對時(shí)序數(shù)據(jù)冷熱性質(zhì)定制的技術(shù)特性。數(shù)據(jù)分級存儲要求能夠?qū)⒆罱r(shí)級別的數(shù)據(jù)放到內(nèi)存中，將最近天級別的數(shù)據(jù)放到SSD，更久遠(yuǎn)的數(shù)據(jù)放到更加廉價(jià)的HDD或者直接使用TTL過期淘汰掉。

4.3 高壓縮率

提供高壓縮率有兩個(gè)方面的考慮，一方面是節(jié)省成本，這很容易理解，將1T數(shù)據(jù)壓縮到100G就可以減少900G的硬盤開銷，這對業(yè)務(wù)來說是有很大的誘惑的。另一個(gè)方面是壓縮后的數(shù)據(jù)可以更容易保證存儲到內(nèi)存中，比如最近3小時(shí)的數(shù)據(jù)是1T，我現(xiàn)在只有100G的內(nèi)存，如果不壓縮，就會有900G的數(shù)據(jù)被迫放到硬盤上，這樣的話查詢開銷會非常之大，而使用壓縮會將這1T數(shù)據(jù)都放入內(nèi)存，查詢性能會非常之好。

4.4 多維度查詢能力

時(shí)序數(shù)據(jù)通常會有多個(gè)維度的標(biāo)簽來刻畫一條數(shù)據(jù)，就是上文中提到的維度列。如何根據(jù)隨機(jī)幾個(gè)維度進(jìn)行高效查詢就是必須要解決的一個(gè)問題，這個(gè)問題通常需要考慮位圖索引或者倒排索引技術(shù)。

4.5 高效聚合能力

時(shí)序業(yè)務(wù)一個(gè)通用的需求是聚合統(tǒng)計(jì)報(bào)表查詢，比如哨兵系統(tǒng)中需要查看最近一天某個(gè)接口出現(xiàn)異常的總次數(shù)，或者某個(gè)接口執(zhí)行的最大耗時(shí)時(shí)間。這樣的聚合實(shí)際上就是簡單的count以及max，問題是如何能高效的在那么大的數(shù)據(jù)量的基礎(chǔ)上將滿足條件的原始數(shù)據(jù)查詢出來并聚合，要知道統(tǒng)計(jì)的原始值可能因?yàn)闀r(shí)間比較久遠(yuǎn)而不在內(nèi)存中哈，因此這可能是一個(gè)非常耗時(shí)的操作。目前業(yè)界比較成熟的方案是使用預(yù)聚合，就是在數(shù)據(jù)寫進(jìn)來的時(shí)候就完成基本的聚合操作。

未來技術(shù)點(diǎn)：異常實(shí)時(shí)檢測、未來預(yù)測等等。

5.傳統(tǒng)關(guān)系型數(shù)據(jù)庫存儲時(shí)序數(shù)據(jù)的問題

很多人可能認(rèn)為在傳統(tǒng)關(guān)系型數(shù)據(jù)庫上加上時(shí)間戳一列就能作為時(shí)序數(shù)據(jù)庫。數(shù)據(jù)量少的時(shí)候確實(shí)也沒問題。但時(shí)序數(shù)據(jù)往往是由百萬級甚至千萬級終端設(shè)備產(chǎn)生的，寫入并發(fā)量比較高，屬于海量數(shù)據(jù)場景。

5.1 MySQL在海量的時(shí)序數(shù)據(jù)場景下存在如下問題：

存儲成本大：對于時(shí)序數(shù)據(jù)壓縮不佳，需占用大量機(jī)器資源；

維護(hù)成本高：單機(jī)系統(tǒng)，需要在上層人工的分庫分表，維護(hù)成本高；

寫入吞吐低：單機(jī)寫入吞吐低，很難滿足時(shí)序數(shù)據(jù)千萬級的寫入壓力；

查詢性能差：適用于交易處理，海量數(shù)據(jù)的聚合分析性能差。

5.2 使用Hadoop生態(tài)(Hadoop、Spark等)存儲時(shí)序數(shù)據(jù)會有以下問題：

數(shù)據(jù)延遲高：離線批處理系統(tǒng)，數(shù)據(jù)從產(chǎn)生到可分析，耗時(shí)數(shù)小時(shí)、甚至天級；

查詢性能差：不能很好的利用索引，依賴MapReduce任務(wù)，查詢耗時(shí)一般在分鐘級。

5.3 時(shí)序數(shù)據(jù)庫需要解決以下幾個(gè)問題：

時(shí)序數(shù)據(jù)的寫入：如何支持每秒鐘上千萬上億數(shù)據(jù)點(diǎn)的寫入。

時(shí)序數(shù)據(jù)的讀?。喝绾沃С衷诿爰墝ι蟽|數(shù)據(jù)的分組聚合運(yùn)算。

成本敏感：由海量數(shù)據(jù)存儲帶來的是成本問題。如何更低成本的存儲這些數(shù)據(jù)，將成為時(shí)序數(shù)據(jù)庫需要解決的重中之重。