[[382865]]

前言

筆者最近擔起了公司監控的重任，而當前監控最流行的數據庫即是Prometheus。按照筆者打破砂鍋問到底的精神，自然要把這個開源組件源碼搞明白才行。在經過一系列源碼/資料的閱讀以及各種Debug之后，對其內部機制有了一定的認識。今天，筆者就來介紹下Prometheus的存儲結構。

由于篇幅較長，所以筆者分為兩篇，本篇主要是描述Prometheus監控數據在內存中的存儲結構。下一篇，主要描述的是監控數據在磁盤中的存儲結構。

Gorilla

Prometheus的存儲結構-TSDB是參考了Facebook的Gorilla之后，自行實現的。所以閱讀

這篇文章《Gorilla: A Fast, Scalable, In-Memory Time Series Database》，可以對Prometheus為何采用這樣的存儲結構有著清晰的理解。

監控數據點

下面是一個非常典型的監控曲線。

可以觀察到，監控數據都是由一個一個數據點組成，所以可以用下面的結構來保存最基本的存儲單元

type sample struct { 
    t int64 
    v float64 
} 

同時我們還需要注意到的信息是，我們需要知道這些點屬于什么機器的哪種監控。這種信息在Promtheus中就用Label(標簽來表示)。一個監控項一般會有多個Label(例如圖中)，所以一般用labels []Label。

由于在我們的習慣中，并不關心單獨的點，而是要關心這段時間內的曲線情況。所以自然而然的，我們存儲結構肯定邏輯上是這個樣子:

這樣，我們就可以很容易的通過一個Labels(標簽們)找到對應的數據了。

監控數據在內存中的表示形式

最近的數據保存在內存中

Prometheus將最近的數據保存在內存中，這樣查詢最近的數據會變得非常快，然后通過一個compactor定時將數據打包到磁盤。數據在內存中最少保留2個小時(storage.tsdb.min-block-duration。至于為什么設置2小時這個值，應該是Gorilla那篇論文中觀察得出的結論

即壓縮率在2小時時候達到最高，如果保留的時間更短，就無法最大化的壓縮。

內存序列(memSeries)

接下來，我們看下具體的數據結構

type memSeries stuct { 
    ...... 
    ref uint64 // 其id 
    lst labels.Labels // 對應的標簽集合 
    chunks []*memChunk // 數據集合 
    headChunk *memChunk // 正在被寫入的chunk 
    ...... 
} 

其中memChunk是真正保存數據的內存塊，將在后面講到。我們先來觀察下memSeries在內存中的組織。

由此我們可以看到，針對一個最終端的監控項(包含抓取的所有標簽，以及新添加的標簽,例如ip)，我們都在內存有一個memSeries結構。

尋址memSeries

如果通過一堆標簽快速找到對應的memSeries。自然的,Prometheus就采用了hash。主要結構體為:

type stripeSeries struct { 
    series [stripeSize]map[uint64]*memSeries // 記錄refId到memSeries的映射 
    hashes [stripeSize]seriesHashmap // 記錄hash值到memSeries,hash沖突采用拉鏈法 
    locks  [stripeSize]stripeLock // 分段鎖 
} 
type seriesHashmap map[uint64][]*memSeries 

由于在Prometheus中會頻繁的對map[hash/refId]memSeries進行操作，例如檢查這個labelSet對應的memSeries是否存在，不存在則創建等。由于golang的map非線程安全，所以其采用了分段鎖去拆分鎖。

而hash值是依據labelSets的值而算出來。

數據點的存儲

為了讓Prometheus在內存和磁盤中保存更大的數據量，勢必需要進行壓縮。而memChunk在內存中保存的正是采用XOR算法壓縮過的數據。在這里，筆者只給出Gorilla論文中的XOR描述

更具體的算法在論文中有詳細描述。總之，使用了XOR算法后，平均每個數據點能從16bytes壓縮到1.37bytes，也就是說所用空間直接降為原來的1/12!

內存中的倒排索引

上面討論的是標簽全部給出的查詢情況。那么我們怎么快速找到某個或某幾個標簽(非全部標簽)的數據呢。這就需要引入以Label為key的倒排索引。我們先給出一組標簽集合

{__name__:http_requests}{group:canary}{instance:0}{job:api-server}    
{__name__:http_requests}{group:canary}{instance:1}{job:api-server} 
{__name__:http_requests}{group:production}{instance:1}{job,api-server} 
{__name__:http_requests}{group:production}{instance:0}{job,api-server} 

可以看到，由于標簽取值不同，我們會有四種不同的memSeries。如果一次性給定4個標簽，應該是很容易從map中直接獲取出對應的memSeries(盡管Prometheus并沒有這么做)。但大部分我們的promql只是給定了部分標簽，如何快速的查找符合標簽的數據呢?

這就引入倒排索引。

先看一下，上面例子中的memSeries在內存中會有4種，同時內存中還夾雜著其它監控項的series

如果我們想知道job:api-server,group為production在一段時間內所有的http請求數量,那么必須獲取標簽攜帶

({__name__:http_requests}{job:api-server}{group:production})的所有監控數據。

如果沒有倒排索引，那么我們必須遍歷內存中所有的memSeries(數萬乃至數十萬)，一一按照Labels去比對,這顯然在性能上是不可接受的。而有了倒排索引，我們就可以通過求交集的手段迅速的獲取需要哪些memSeries。

注意，這邊倒排索引存儲的refId必須是有序的。這樣，我們就可以在O(n)復雜度下順利的算出交集,另外，針對其它請求形式，還有并集/差集的操作,對應實現結構體為:

type intersectPostings struct {...}  // 交集 
type mergedPostings struct {...} // 并集 
type removedPostings struct {...} // 差集 

倒排索引的插入組織即為Prometheus下面的代碼

Add(labels,t,v)  
    |->getOrCreateWithID 
        |->memPostings.Add 
 
// Add a label set to the postings index. 
func (p *MemPostings) Add(id uint64, lset labels.Labels) { 
    p.mtx.Lock() 
    // 將新創建的memSeries refId都加到對應的Label倒排里去 
    for _, l := range lset { 
        p.addFor(id, l) 
    } 
    p.addFor(id, allPostingsKey) // allPostingKey "","" every one都加進去 
 
    p.mtx.Unlock() 
} 

正則支持

事實上，給定特定的Label:Value還是無法滿足我們的需求。我們還需要對標簽正則化，例如取出所有ip為1.1.*前綴的http_requests監控數據。為了這種正則，Prometheus還維護了一個標簽所有可能的取值。對應代碼為:

Add(labels,t,v)  
    |->getOrCreateWithID 
        |->memPostings.Add 
func (h *Head) getOrCreateWithID(id, hash uint64, lset labels.Labels){ 
    ... 
    for _, l := range lset { 
        valset, ok := h.values[l.Name] 
        if !ok { 
            valset = stringset{} 
            h.values[l.Name] = valset 
        } 
        // 將可能取值塞入stringset中 
        valset.set(l.Value) 
        // 符號表的維護 
        h.symbols[l.Name] = struct{}{} 
        h.symbols[l.Value] = struct{}{} 
    } 
    ... 
} 

那么，在內存中，我們就有了如下的表

圖中所示，有了label和對應所有value集合的表，一個正則請求就可以很容的分解為若干個非正則請求并最后求交/并/查集，即可得到最終的結果。

總結

Prometheus作為當今最流行的時序數據庫，其中有非常多的值得我們借鑒的設計和機制。這一篇筆者主要描述了監控數據在內存中的存儲結構。下一篇，將會闡述監控數據在磁盤中的存儲結構，敬請期待!

本文轉載自微信公眾號「解Bug之路」，可以通過以下二維碼關注。轉載本文請聯系解Bug之路公眾號。