Prometheus時(shí)序數(shù)據(jù)庫(kù)-磁盤中的存儲(chǔ)結(jié)構(gòu)
前言
之前的文章里，筆者詳細(xì)描述了監(jiān)控?cái)?shù)據(jù)在Prometheus內(nèi)存中的結(jié)構(gòu)。而其在磁盤中的存儲(chǔ)結(jié)構(gòu)，也是非常有意思的,關(guān)于這部分內(nèi)容，將在本篇文章進(jìn)行闡述。
磁盤目錄結(jié)構(gòu)
首先我們來(lái)看Prometheus運(yùn)行后，所形成的文件目錄結(jié)構(gòu)
在筆者自己的機(jī)器上的具體結(jié)構(gòu)如下:
- prometheus-data
- |-01EY0EH5JA3ABCB0PXHAPP999D (block)
- |-01EY0EH5JA3QCQB0PXHAPP999D (block)
- |-chunks
- |-000001
- |-000002
- .....
- |-000021
- |-index
- |-meta.json
- |-tombstones
- |-wal
- |-chunks_head
Block
一個(gè)Block就是一個(gè)獨(dú)立的小型數(shù)據(jù)庫(kù)，其保存了一段時(shí)間內(nèi)所有查詢所用到的信息。包括標(biāo)簽/索引/符號(hào)表數(shù)據(jù)等等。Block的實(shí)質(zhì)就是將一段時(shí)間里的內(nèi)存數(shù)據(jù)組織成文件形式保存下來(lái)。
最近的Block一般是存儲(chǔ)了2小時(shí)的數(shù)據(jù)，而較為久遠(yuǎn)的Block則會(huì)通過(guò)compactor進(jìn)行合并，一個(gè)Block可能存儲(chǔ)了若干小時(shí)的信息。值得注意的是，合并操作只是減少了索引的大小(尤其是符號(hào)表的合并)，而本身數(shù)據(jù)(chunks)的大小并沒(méi)有任何改變。
meta.json
我們可以通過(guò)檢查meta.json來(lái)得到當(dāng)前Block的一些元信息。
- {
- "ulid":"01EY0EH5JA3QCQB0PXHAPP999D"
- // maxTime-minTime = 7200s => 2 h
- "minTime": 1611664000000
- "maxTime": 1611671200000
- "stats": {
- "numSamples": 1505855631,
- "numSeries": 12063563,
- "numChunks": 12063563
- }
- "compaction":{
- "level" : 1
- "sources: [
- "01EY0EH5JA3QCQB0PXHAPP999D"
- ]
- }
- "version":1
- }
其中的元信息非常清楚明了。這個(gè)Block記錄了2個(gè)小時(shí)的數(shù)據(jù)。
讓我們?cè)僬乙粋€(gè)比較陳舊的Block看下它的meta.json.
- "ulid":"01EXTEH5JA3QCQB0PXHAPP999D",
- // maxTime - maxTime =>162h
- "minTime":1610964800000,
- "maxTime":1611548000000
- ......
- "compaction":{
- "level": 5,
- "sources: [
- 31個(gè)01EX......
- ]
- },
- "parents: [
- {
- "ulid": 01EXTEH5JA3QCQB1PXHAPP999D
- ...
- }
- {
- "ulid": 01EXTEH6JA3QCQB1PXHAPP999D
- ...
- }
- {
- "ulid": 01EXTEH5JA31CQB1PXHAPP999D
- ...
- }
- ]
從中我們可以看到，該Block是由31個(gè)原始Block經(jīng)歷5次壓縮而來(lái)。最后一次壓縮的三個(gè)Block ulid記錄在parents中。如下圖所示:
Chunks結(jié)構(gòu)
CUT文件切分
所有的Chunk文件在磁盤上都不會(huì)大于512M,對(duì)應(yīng)的源碼為:
- func (w *Writer) WriteChunks(chks ...Meta) error {
- ......
- for i, chk := range chks {
- cutNewBatch := (i != 0) && (batchSize+SegmentHeaderSize > w.segmentSize)
- ......
- if cutNewBatch {
- ......
- }
- ......
- }
- }
當(dāng)寫入磁盤單個(gè)文件超過(guò)512M的時(shí)候，就會(huì)自動(dòng)切分一個(gè)新的文件。
一個(gè)Chunks文件包含了非常多的內(nèi)存Chunk結(jié)構(gòu),如下圖所示:
圖中也標(biāo)出了，我們是怎么尋找對(duì)應(yīng)Chunk的。通過(guò)將文件名(000001，前32位)以及(offset,后32位)編碼到一個(gè)int類型的refId中，使得我們可以輕松的通過(guò)這個(gè)id獲取到對(duì)應(yīng)的chunk數(shù)據(jù)。
chunks文件通過(guò)mmap去訪問(wèn)
由于chunks文件大小基本固定(最大512M),所以我們很容易的可以通過(guò)mmap去訪問(wèn)對(duì)應(yīng)的數(shù)據(jù)。直接將對(duì)應(yīng)文件的讀操作交給操作系統(tǒng)，既省心又省力。對(duì)應(yīng)代碼為:
- func NewDirReader(dir string, pool chunkenc.Pool) (*Reader, error) {
- ......
- for _, fn := range files {
- f, err := fileutil.OpenMmapFile(fn)
- ......
- }
- ......
- bs = append(bs, realByteSlice(f.Bytes()))
- }
- 通過(guò)sgmBytes := s.bs[offset]就直接能獲取對(duì)應(yīng)的數(shù)據(jù)
index索引結(jié)構(gòu)
前面介紹完chunk文件，我們就可以開始闡述最復(fù)雜的索引結(jié)構(gòu)了。
尋址過(guò)程
索引就是為了讓我們快速的找到想要的內(nèi)容，為了便于理解。筆者就通過(guò)一次數(shù)據(jù)的尋址來(lái)探究Prometheus的磁盤索引結(jié)構(gòu)?？紤]查詢一個(gè)
- 擁有系列三個(gè)標(biāo)簽
- ({__name__:http_requests}{job:api-server}{instance:0})
- 且時(shí)間為start/end的所有序列數(shù)據(jù)
我們先從選擇Block開始,遍歷所有Block的meta.json，找到具體的Block
前文說(shuō)了，通過(guò)Labels找數(shù)據(jù)是通過(guò)倒排索引。我們的倒排索引是保存在index文件里面的。那么怎么在這個(gè)單一文件里找到倒排索引的位置呢?這就引入了TOC(Table Of Content)
TOC(Table Of Content)
由于index文件一旦形成之后就不再會(huì)改變，所以Prometheus也依舊使用mmap來(lái)進(jìn)行操作。采用mmap讀取TOC非常容易:
- func NewTOCFromByteSlice(bs ByteSlice) (*TOC, error) {
- ......
- // indexTOCLen = 6*8+4 = 52
- b := bs.Range(bs.Len()-indexTOCLen, bs.Len())
- ......
- return &TOC{
- Symbols: d.Be64(),
- Series: d.Be64(),
- LabelIndices: d.Be64(),
- LabelIndicesTable: d.Be64(),
- Postings: d.Be64(),
- PostingsTable: d.Be64(),
- }, nil
- }
Posting offset table 以及 Posting倒排索引
首先我們?cè)L問(wèn)的是Posting offset table。由于倒排索引按照不同的LabelPair(key/value)會(huì)有非常多的條目。所以Posing offset table就是決定到底訪問(wèn)哪一條Posting索引。offset就是指的這一Posting條目在文件中的偏移。
Series
我們通過(guò)三條Postings倒排索引索引取交集得出
- {series1,Series2,Series3,Series4}
- ∩
- {series1,Series2,Series3}
- ∩
- {Series2,Series3}
- =
- {Series2,Series3}
也就是要讀取Series2和Serie3中的數(shù)據(jù)，而Posting中的Ref(Series2)和Ref(Series3)即為這兩Series在index文件中的偏移。
Series以Delta的形式記錄了chunkId以及該chunk包含的時(shí)間范圍。這樣就可以很容易過(guò)濾出我們需要的chunk,然后再按照chunk文件的訪問(wèn)，即可找到最終的原始數(shù)據(jù)。
SymbolTable
值得注意的是，為了盡量減少我們文件的大小，對(duì)于Label的Name和Value這些有限的數(shù)據(jù)，我們會(huì)按照字母序存在符號(hào)表中。由于是有序的，所以我們可以直接將符號(hào)表認(rèn)為是一個(gè)
[]string切片。然后通過(guò)切片的下標(biāo)去獲取對(duì)應(yīng)的sting?？紤]如下符號(hào)表:
讀取index文件時(shí)候，會(huì)將SymbolTable全部加載到內(nèi)存中，并組織成symbols []string這樣的切片形式，這樣一個(gè)Series中的所有標(biāo)簽值即可通過(guò)切片下標(biāo)訪問(wèn)得到。
Label Index以及Label Table
事實(shí)上，前面的介紹已經(jīng)將一個(gè)普通數(shù)據(jù)尋址的過(guò)程全部講完了。但是index文件中還包含label索引以及l(fā)abel Table，這兩個(gè)是用來(lái)記錄一個(gè)Label下面所有可能的值而存在的。
這樣，在正則的時(shí)候就可以非常容易的找到我們需要哪些LabelPair。詳情可以見前篇。
事實(shí)上，真正的Label Index比圖中要復(fù)雜一點(diǎn)。它設(shè)計(jì)成一條LabelIndex可以表示(多個(gè)標(biāo)簽組合)的所有數(shù)據(jù)。不過(guò)在Prometheus代碼中只會(huì)采用存儲(chǔ)一個(gè)標(biāo)簽對(duì)應(yīng)所有值的形式。
完整的index文件結(jié)構(gòu)
這里直接給出完整的index文件結(jié)構(gòu)，摘自Prometheus中index.md文檔。
- ┌────────────────────────────┬─────────────────────┐
- │ magic(0xBAAAD700) <4b> │ version(1) <1 byte> │
- ├────────────────────────────┴─────────────────────┤
- │ ┌──────────────────────────────────────────────┐ │
- │ │ Symbol Table │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Series │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Label Index 1 │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ ... │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Label Index N │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Postings 1 │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ ... │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Postings N │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Label Index Table │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ Postings Table │ │
- │ ├──────────────────────────────────────────────┤ │
- │ │ TOC │ │
- │ └──────────────────────────────────────────────┘ │
- └──────────────────────────────────────────────────┘
tombstones
由于Prometheus Block的數(shù)據(jù)一般在寫完后就不會(huì)變動(dòng)。如果要?jiǎng)h除部分?jǐn)?shù)據(jù)，就只能記錄一下刪除數(shù)據(jù)的范圍，由下一次compactor組成新block的時(shí)候刪除。而記錄這些信息的文件即是tomstones。
總結(jié)
Prometheus作為時(shí)序數(shù)據(jù)庫(kù)，設(shè)計(jì)了各種文件結(jié)構(gòu)來(lái)保存海量的監(jiān)控?cái)?shù)據(jù)，同時(shí)還兼顧了性能。只有徹底了解其存儲(chǔ)結(jié)構(gòu)，才能更好的指導(dǎo)我們應(yīng)用它!
本文轉(zhuǎn)載自微信公眾號(hào)「解Bug之路」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系解Bug之路公眾號(hào)。
