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

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

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

Prometheus

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

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

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

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

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

V2存儲引擎

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

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

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

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

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

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

V3存儲引擎

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

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

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

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

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

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

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

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

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

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


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

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