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

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

點此查看原文：http://click.aliyun.com/m/40930/

Prometheus

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

但InfluxDB的TSM，細節描述還是不夠多，更多的是策略和行為的描述。最近看到了一篇文章《Writing a Time Series Database from Scratch》，從零開始寫一個時序數據庫，雖然有點標題黨，但內容確是實打實的干貨，描述了一個TSDB存儲引擎的設計思路。而且這個存儲引擎不是一個概念或玩具，而是真實應用到生產了，是Prometheus在2017年11月對外發布的2.0版里的一個完全重寫的新的存儲引擎。這個新版存儲引擎號稱是帶來了『huge performance improvements』，由于變化太大，做不到向后兼容，估計也是真的帶來了很多驚喜，才能這樣子去耍流氓。
而本篇文章，主要是對那篇文章的一個解讀，大部分內容來自原文，略有刪減。想了解更詳細的內容的話，建議可以去看英文原文，有理解錯誤的地方歡迎指正。

數據模型

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

上圖是所有數據點分布的一個簡單視圖，橫軸是時間，縱軸是時間線，區域內每個點就是數據點。Prometheus每次接收數據，收到的是圖中區域內縱向的一條線。這個表述很形象，因為在同一時刻，每條時間線只會產生一個數據點，但同時會有多條時間線產生數據，把這些數據點連在一起，就是一條豎線。這個特征很重要，影響數據寫入和壓縮的優化策略。

V2存儲引擎

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

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

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

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

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

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

V3存儲引擎

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

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

設計思想

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

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

和V2一樣，最近的數據在內存內，最近的數據也是最熱的數據，在內存可支持最高效的查詢。

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

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

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

以上基本講完了數據存儲的一些設計要點，還是比較簡單明了的。和其他時序數據庫一樣，除了數據存儲庫，還有一份索引庫。V3的索引結構比較簡單，直接引用文章中給的例子：


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

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