Prometheus時序數據庫-內存中的存儲結構

前言

筆者最近擔起了公司監控的重任，而當前監控最流行的數據庫即是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作為當今最流行的時序數據庫，其中有非常多的值得我們借鑒的設計和機制。這一篇筆者主要描述了監控數據在內存中的存儲結構。下一篇，將會闡述監控數據在磁盤中的存儲結構，敬請期待！

歡迎大家關注我公眾號，里面有各種干貨，還有大禮包相送哦!