摘要：摘要開(kāi)源時(shí)序數(shù)據(jù)庫(kù)解析的系列文章在之前已經(jīng)完成了幾篇，對(duì)比分析了系的系的及，最后是的。數(shù)據(jù)模型與其他主流時(shí)序數(shù)據(jù)庫(kù)一樣，在數(shù)據(jù)模型定義上，也會(huì)包含一個(gè)或多個(gè)同以及。

摘要： Prometheus 開(kāi)源時(shí)序數(shù)據(jù)庫(kù)解析的系列文章在之前已經(jīng)完成了幾篇，對(duì)比分析了Hbase系的OpenTSDB、Cassandra系的KairosDB、BlueFlood及Heroic，最后是tsdb ranking top 1的InfluxDB。

點(diǎn)此查看原文：http://click.aliyun.com/m/40930/

Prometheus

開(kāi)源時(shí)序數(shù)據(jù)庫(kù)解析的系列文章在之前已經(jīng)完成了幾篇，對(duì)比分析了Hbase系的OpenTSDB、Cassandra系的KairosDB、BlueFlood及Heroic，最后是tsdb ranking top 1的InfluxDB。InfluxDB是從底到上純自研的一款TSDB，在看他相關(guān)資料時(shí)對(duì)其比較感興趣的是底層的TSM，一個(gè)基于LSM思想針對(duì)時(shí)序數(shù)據(jù)場(chǎng)景優(yōu)化的存儲(chǔ)引擎。InfluxDB分享了他們從最初使用LevelDB，到替換為BoltDB，最后到?jīng)Q定自研TSM的整個(gè)過(guò)程，深刻描述了每個(gè)階段的痛點(diǎn)及過(guò)度到下個(gè)階段需要解決的核心問(wèn)題，以及最終TSM的核心設(shè)計(jì)思路。這類分享是我比較喜歡的，不是直接一上來(lái)告訴你什么技術(shù)是最好，而是一步一步告訴你整個(gè)技術(shù)演進(jìn)的歷程。這其中對(duì)每個(gè)階段遇到的問(wèn)題的深刻剖析、最終做出技術(shù)選擇的理由等，讓人印象深刻，能學(xué)到很多東西。

但I(xiàn)nfluxDB的TSM，細(xì)節(jié)描述還是不夠多，更多的是策略和行為的描述。最近看到了一篇文章《Writing a Time Series Database from Scratch》，從零開(kāi)始寫一個(gè)時(shí)序數(shù)據(jù)庫(kù)，雖然有點(diǎn)標(biāo)題黨，但內(nèi)容確是實(shí)打?qū)嵉母韶洠枋隽艘粋€(gè)TSDB存儲(chǔ)引擎的設(shè)計(jì)思路。而且這個(gè)存儲(chǔ)引擎不是一個(gè)概念或玩具，而是真實(shí)應(yīng)用到生產(chǎn)了，是Prometheus在2017年11月對(duì)外發(fā)布的2.0版里的一個(gè)完全重寫的新的存儲(chǔ)引擎。這個(gè)新版存儲(chǔ)引擎號(hào)稱是帶來(lái)了『huge performance improvements』，由于變化太大，做不到向后兼容，估計(jì)也是真的帶來(lái)了很多驚喜，才能這樣子去耍流氓。
而本篇文章，主要是對(duì)那篇文章的一個(gè)解讀，大部分內(nèi)容來(lái)自原文，略有刪減。想了解更詳細(xì)的內(nèi)容的話，建議可以去看英文原文，有理解錯(cuò)誤的地方歡迎指正。

數(shù)據(jù)模型

Prometheus與其他主流時(shí)序數(shù)據(jù)庫(kù)一樣，在數(shù)據(jù)模型定義上，也會(huì)包含metric name、一個(gè)或多個(gè)labels（同tags）以及metric value。metric name加一組labels作為唯一標(biāo)識(shí)，來(lái)定義time series，也就是時(shí)間線。在查詢時(shí)，支持根據(jù)labels條件查找time series，支持簡(jiǎn)單的條件也支持復(fù)雜的條件。存儲(chǔ)引擎的設(shè)計(jì)，會(huì)根據(jù)時(shí)序數(shù)據(jù)的特點(diǎn)，重點(diǎn)考慮數(shù)據(jù)存儲(chǔ)（寫多讀少）、數(shù)據(jù)回收（retention）以及數(shù)據(jù)查詢，Prometheus這里暫時(shí)還沒(méi)提數(shù)據(jù)分析。

上圖是所有數(shù)據(jù)點(diǎn)分布的一個(gè)簡(jiǎn)單視圖，橫軸是時(shí)間，縱軸是時(shí)間線，區(qū)域內(nèi)每個(gè)點(diǎn)就是數(shù)據(jù)點(diǎn)。Prometheus每次接收數(shù)據(jù)，收到的是圖中區(qū)域內(nèi)縱向的一條線。這個(gè)表述很形象，因?yàn)樵谕粫r(shí)刻，每條時(shí)間線只會(huì)產(chǎn)生一個(gè)數(shù)據(jù)點(diǎn)，但同時(shí)會(huì)有多條時(shí)間線產(chǎn)生數(shù)據(jù)，把這些數(shù)據(jù)點(diǎn)連在一起，就是一條豎線。這個(gè)特征很重要，影響數(shù)據(jù)寫入和壓縮的優(yōu)化策略。

V2存儲(chǔ)引擎

這篇文章主要闡述的是新的V3存儲(chǔ)引擎的一些設(shè)計(jì)思想，老的存儲(chǔ)引擎就是V2。V2存儲(chǔ)引擎會(huì)把每條時(shí)間線上的數(shù)據(jù)點(diǎn)分別存儲(chǔ)到不同的文件，這種設(shè)計(jì)策略下，文中提出了幾個(gè)問(wèn)題來(lái)探討：
針對(duì)寫入要做的優(yōu)化：針對(duì)SSD和HDD的寫入優(yōu)化，均可遵循順序?qū)懞团繉懙脑瓌t。但是如上面所說(shuō)，Prometheus一次性接收到的數(shù)據(jù)是一條豎線，包含很多的數(shù)據(jù)點(diǎn)，但是這些數(shù)據(jù)點(diǎn)屬于不同的時(shí)間線。而當(dāng)前的設(shè)計(jì)是一條時(shí)間線對(duì)應(yīng)一個(gè)獨(dú)立的文件，所以每次寫入都會(huì)需要向很多不同的文件寫入極少量的數(shù)據(jù)。針對(duì)這個(gè)問(wèn)題，V2存儲(chǔ)引擎的優(yōu)化策略是Chunk寫，針對(duì)單個(gè)時(shí)間線的寫入必須是批量寫，那就需要數(shù)據(jù)在時(shí)間線維度累積一定時(shí)間后才能湊到一定量的數(shù)據(jù)點(diǎn)。Chunk寫策略帶來(lái)的好處除了批量寫外，還能優(yōu)化熱數(shù)據(jù)查詢效率以及數(shù)據(jù)壓縮率。V2存儲(chǔ)引擎使用了和Facebook Gorilla一樣的壓縮算法，能夠?qū)?6個(gè)字節(jié)的數(shù)據(jù)點(diǎn)壓縮到平均1.37個(gè)字節(jié)，節(jié)省12倍內(nèi)存和空間。Chunk寫就要求數(shù)據(jù)一定要在服務(wù)器內(nèi)存里積累一定的時(shí)間，即熱數(shù)據(jù)基本都在內(nèi)存中，查詢效率很高。

針對(duì)查詢要做的優(yōu)化：時(shí)序數(shù)據(jù)的查詢場(chǎng)景多遍，可以查某個(gè)時(shí)間線的某個(gè)時(shí)間點(diǎn)、某個(gè)時(shí)間點(diǎn)多條時(shí)間線或者是某個(gè)時(shí)間范圍多條時(shí)間線的數(shù)據(jù)等等。在上面的數(shù)據(jù)模型圖上示意出來(lái)，就是在二維象限內(nèi)一個(gè)矩形的數(shù)據(jù)塊。不斷是針對(duì)SSD還是HDD，對(duì)磁盤數(shù)據(jù)讀取比較友好的優(yōu)化，均是優(yōu)化到一次查詢只需要少量的隨機(jī)定位加上大塊的順序讀取。這個(gè)和數(shù)據(jù)在磁盤的分布有很大的關(guān)系，歸根到底，還是和數(shù)據(jù)寫有關(guān)系，但不一定是實(shí)時(shí)寫優(yōu)化，也可以通過(guò)后續(xù)的數(shù)據(jù)整理來(lái)優(yōu)化。

V2存儲(chǔ)引擎里，有一些已經(jīng)做的比較好的優(yōu)化策略，主要是Chunk寫以及熱數(shù)據(jù)內(nèi)存緩存，這兩個(gè)優(yōu)化延續(xù)到了V3。但是除了這兩點(diǎn)，V2還是存在很多的缺陷：
文件數(shù)會(huì)隨著時(shí)間線的數(shù)量同比增長(zhǎng)，慢慢會(huì)耗盡inode。

即便使用了Chunk寫優(yōu)化，若一次寫入涉及的時(shí)間線過(guò)多，IOPS要求還是會(huì)很高。
每個(gè)文件不可能會(huì)時(shí)刻保持open狀態(tài)，一次查詢可能需要重新打開(kāi)大量文件，增大查詢延遲。

數(shù)據(jù)回收需要從大量文件掃描和重寫數(shù)據(jù)，耗時(shí)較長(zhǎng)。

數(shù)據(jù)需要在內(nèi)存中積累一定時(shí)間以Chunk寫，V2會(huì)采用定時(shí)寫Checkpoint的機(jī)制來(lái)盡量保證內(nèi)存中數(shù)據(jù)不丟失。但通常記錄Checkpoint的時(shí)間大于能承受的數(shù)據(jù)丟失的時(shí)間窗口，并且在節(jié)點(diǎn)恢復(fù)時(shí)從checkpoint restore數(shù)據(jù)的時(shí)間也會(huì)很長(zhǎng)。
另外關(guān)于時(shí)間線的索引，V2存儲(chǔ)引擎使用LevelDB來(lái)存儲(chǔ)label到時(shí)間線的映射。當(dāng)時(shí)間線到一定規(guī)模后，查詢的效率會(huì)變得很低。在一般場(chǎng)景下，時(shí)間線的基數(shù)都是比較小的，因?yàn)閼?yīng)用環(huán)境很少變更，運(yùn)行穩(wěn)定的話時(shí)間線基數(shù)也會(huì)處于一個(gè)穩(wěn)定的狀態(tài)。但是若label設(shè)置不合理，例如采用一個(gè)動(dòng)態(tài)值，比如是程序版本號(hào)作為label，每次應(yīng)用升級(jí)label的值都會(huì)改變。那隨著時(shí)間的推進(jìn)，會(huì)存在越來(lái)越多無(wú)效的時(shí)間線（Prometheus稱其為Series Churn）。時(shí)間線的規(guī)模會(huì)變得越來(lái)越大，影響索引查詢效率。

V3存儲(chǔ)引擎

V3引擎完全重新設(shè)計(jì)，來(lái)解決V2引擎中存在的這些問(wèn)題。V3引擎可以看做是一個(gè)簡(jiǎn)單版、針對(duì)時(shí)序數(shù)據(jù)場(chǎng)景優(yōu)化過(guò)后的LSM，可以帶著LSM的設(shè)計(jì)思想來(lái)理解，先看一下V3引擎中數(shù)據(jù)的文件目錄結(jié)構(gòu)。

data目錄下存放所有的數(shù)據(jù)，data目錄的下一級(jí)目錄是以"b-"為前綴，順序自增的ID為后綴的目錄，代表Block。每個(gè)Block下有chunks、index和meta.json，chunks目錄下存放chunk的數(shù)據(jù)。這個(gè)chunk和V2的chunk是一個(gè)概念，唯一的不同是一個(gè)chunk內(nèi)會(huì)包含很多的時(shí)間線，而不再只是一條。index是這個(gè)block下對(duì)chunk的索引，可以支持根據(jù)某個(gè)label快速定位到時(shí)間線以及數(shù)據(jù)所在的chunk。meta.json是一個(gè)簡(jiǎn)單的關(guān)于block數(shù)據(jù)和狀態(tài)的一個(gè)描述文件。要理解V3引擎的設(shè)計(jì)思想，只需要搞明白幾個(gè)問(wèn)題：1. chunk文件的存儲(chǔ)格式？2. index的存儲(chǔ)格式，如何實(shí)現(xiàn)快速查找？3. 為何最后一個(gè)block沒(méi)有chunk目錄但有一個(gè)wal目錄？

設(shè)計(jì)思想

Prometheus將數(shù)據(jù)按時(shí)間維度切分為多個(gè)block，每個(gè)block被認(rèn)為是獨(dú)立的一個(gè)數(shù)據(jù)庫(kù)，覆蓋不同的時(shí)間范圍的數(shù)據(jù)，完全沒(méi)有交叉。每個(gè)Block下chunk內(nèi)的數(shù)據(jù)dump到文件后即不可再修改，只有最近的一個(gè)block允許接收新數(shù)據(jù)。最新的block內(nèi)數(shù)據(jù)寫入會(huì)先寫到一個(gè)內(nèi)存的結(jié)構(gòu)，為了保證數(shù)據(jù)不丟失，會(huì)先寫一份WAL（write ahead log）。

V3完全借鑒了LSM的設(shè)計(jì)思想，針對(duì)時(shí)序數(shù)據(jù)特征做了一些優(yōu)化，帶來(lái)很多好處：
當(dāng)查詢一個(gè)時(shí)間范圍的數(shù)據(jù)時(shí)，可快速排除無(wú)關(guān)的block。每個(gè)block有獨(dú)立的index，能夠有效解決V2內(nèi)遇到的『無(wú)效時(shí)間線 Series Churn』的問(wèn)題。
內(nèi)存數(shù)據(jù)dump到chunk file，可高效采用大塊數(shù)據(jù)順序?qū)?，?duì)SSD和HDD都很友好。

和V2一樣，最近的數(shù)據(jù)在內(nèi)存內(nèi)，最近的數(shù)據(jù)也是最熱的數(shù)據(jù)，在內(nèi)存可支持最高效的查詢。

老數(shù)據(jù)的回收變得非常簡(jiǎn)單和高效，只需要?jiǎng)h除少量目錄。

V3內(nèi)block以兩個(gè)小時(shí)的跨度來(lái)切割，這個(gè)時(shí)間跨度不能太大，也不能太小。太大的話若內(nèi)存中要保留兩個(gè)小時(shí)數(shù)據(jù)，則內(nèi)存占用會(huì)比較大。太小的話會(huì)導(dǎo)致太多的block，查詢時(shí)需要對(duì)更多的文件做查詢。所以兩個(gè)小時(shí)是一個(gè)綜合考慮后決定的值，但是當(dāng)查詢大跨度時(shí)間范圍時(shí)，仍不可避免需要跨多個(gè)文件，例如查詢一周時(shí)間跨度需要84個(gè)文件。V3也是采用了LSM一樣的compaction策略來(lái)做查詢優(yōu)化，把小的block合并為大的block，compaction期間也可做其他一些事，例如刪除過(guò)期數(shù)據(jù)或重構(gòu)chunk數(shù)據(jù)以支持更高效的查詢。這篇文章中對(duì)V3的compaction描述的比較少，這個(gè)倒可以去看看InfluxDB怎么做的，InfluxDB有多種不同的compaction策略，在不同的時(shí)刻使用，具體可以看看這篇文章。

這個(gè)圖是V3內(nèi)對(duì)過(guò)期數(shù)據(jù)回收的一個(gè)示意圖，相比V2會(huì)簡(jiǎn)單很多。對(duì)整個(gè)block已經(jīng)過(guò)期的數(shù)據(jù)，直接刪除文件夾即可。但對(duì)只有部分?jǐn)?shù)據(jù)過(guò)期的block，無(wú)法進(jìn)行回收，只能等全部過(guò)期或者compaction。這里有個(gè)問(wèn)題要討論，隨著對(duì)歷史數(shù)據(jù)不斷的做compaction，block會(huì)變得越來(lái)越大，覆蓋的時(shí)間范圍會(huì)越大，則越難被回收。這里必須控制block的上限，通常是根據(jù)一個(gè)retention window的周期來(lái)配置。

以上基本講完了數(shù)據(jù)存儲(chǔ)的一些設(shè)計(jì)要點(diǎn)，還是比較簡(jiǎn)單明了的。和其他時(shí)序數(shù)據(jù)庫(kù)一樣，除了數(shù)據(jù)存儲(chǔ)庫(kù)，還有一份索引庫(kù)。V3的索引結(jié)構(gòu)比較簡(jiǎn)單，直接引用文章中給的例子：


從文章描述看，V3沒(méi)有和V2一樣采用LevelDB，在已經(jīng)持久化的Block，Index已經(jīng)固定下來(lái)，不可修改。而對(duì)于最新的還在寫數(shù)據(jù)的block，V3則會(huì)把所有的索引全部hold在內(nèi)存，維護(hù)一個(gè)內(nèi)存結(jié)構(gòu)，等到這個(gè)block被關(guān)閉，再持久化到文件。這樣做會(huì)比較簡(jiǎn)單一點(diǎn)，內(nèi)存里維護(hù)時(shí)間線到ID的映射以及l(fā)abel到ID列表的映射，查詢效率會(huì)很高。而且Prometheus對(duì)Label的基數(shù)會(huì)有一個(gè)假設(shè)：『a real-world dataset of ~4.4 million series with about 12 labels each has less than 5,000 unique labels』，這個(gè)全部保存在內(nèi)存也是一個(gè)很小的量級(jí)，完全沒(méi)有問(wèn)題。InfluxDB采用的是類似的策略，而其他一些TSDB則直接使用ElasticSearch作為索引引擎。

總結(jié)
針對(duì)時(shí)序數(shù)據(jù)這種寫多讀少的場(chǎng)景，類LSM的存儲(chǔ)引擎還是有不少優(yōu)勢(shì)的。有些TSDB直接基于開(kāi)源的LSM引擎分布式數(shù)據(jù)庫(kù)例如Hbase或Cassandra，也有自己基于LevelDB/RocksDB研發(fā)，或者再像InfluxDB和Prometheus一樣純自研，因?yàn)闀r(shí)序數(shù)據(jù)這一特定場(chǎng)景還是可以做更多的優(yōu)化，例如索引、compaction策略等。Prometheus V3引擎的設(shè)計(jì)思想和InfluxDB真的很像，優(yōu)化思路高度一致，后續(xù)在有新的需求的出現(xiàn)后，會(huì)有更多變化。