Prometheus時序資料庫-磁碟中的儲存結構
阿新 • • 發佈：2021-03-01
# Prometheus時序資料庫-磁碟中的儲存結構
## 前言
之前的文章裡，筆者詳細描述了監控資料在Prometheus記憶體中的結構。而其在磁碟中的儲存結構，也是非常有意思的,關於這部分內容，將在本篇文章進行闡述。
## 磁碟目錄結構
首先我們來看Prometheus執行後，所形成的檔案目錄結構
在筆者自己的機器上的具體結構如下:
```
prometheus-data
|-01EY0EH5JA3ABCB0PXHAPP999D (block)
|-01EY0EH5JA3QCQB0PXHAPP999D (block)
|-chunks
|-000001
|-000002
.....
|-000021
|-index
|-meta.json
|-tombstones
|-wal
|-chunks_head
```
### Block
一個Block就是一個獨立的小型資料庫，其儲存了一段時間內所有查詢所用到的資訊。包括標籤/索引/符號表資料等等。Block的實質就是將一段時間裡的記憶體資料組織成檔案形式儲存下來。
最近的Block一般是儲存了2小時的資料，而較為久遠的Block則會通過compactor進行合併，一個Block可能儲存了若干小時的資訊。值得注意的是，合併操作只是減少了索引的大小(尤其是符號表的合併)，而本身資料(chunks)的大小並沒有任何改變。
#### meta.json
我們可以通過檢查meta.json來得到當前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
}
```
其中的元資訊非常清楚明瞭。這個Block記錄了從2個小時的資料。
讓我們再找一個比較陳舊的Block看下它的meta.json.
```
"ulid":"01EXTEH5JA3QCQB0PXHAPP999D",
// maxTime - maxTime =>162h
"minTime":1610964800000,
"maxTime":1611548000000
......
"compaction":{
"level": 5,
"sources: [
31個01EX......
]
},
"parents: [
{
"ulid": 01EXTEH5JA3QCQB1PXHAPP999D
...
}
{
"ulid": 01EXTEH6JA3QCQB1PXHAPP999D
...
}
{
"ulid": 01EXTEH5JA31CQB1PXHAPP999D
...
}
]
```
從中我們可以看到，該Block是由31個原始Block經歷5次壓縮而來。最後一次壓縮的三個Block ulid記錄在parents中。如下圖所示:
## Chunks結構
### CUT檔案切分
所有的Chunk檔案在磁碟上都不會大於512M,對應的原始碼為:
```
func (w *Writer) WriteChunks(chks ...Meta) error {
......
for i, chk := range chks {
cutNewBatch := (i != 0) && (batchSize+SegmentHeaderSize > w.segmentSize)
......
if cutNewBatch {
......
}
......
}
}
```
當寫入磁碟單個檔案超過512M的時候，就會自動切分一個新的檔案。
一個Chunks檔案包含了非常多的記憶體Chunk結構,如下圖所示:
圖中也標出了，我們是怎麼尋找對應Chunk的。通過將檔名(000001，前32位)以及(offset,後32位)編碼到一個int型別的refId中，使得我們可以輕鬆的通過這個id獲取到對應的chunk資料。
### chunks檔案通過mmap去訪問
由於chunks檔案大小基本固定(最大512M),所以我們很容易的可以通過mmap去訪問對應的資料。直接將對應檔案的讀操作交給作業系統，既省心又省力。對應程式碼為:
```
func NewDirReader(dir string, pool chunkenc.Pool) (*Reader, error) {
......
for _, fn := range files {
f, err := fileutil.OpenMmapFile(fn)
......
}
......
bs = append(bs, realByteSlice(f.Bytes()))
}
通過sgmBytes := s.bs[offset]就直接能獲取對應的資料
```
## index索引結構
前面介紹完chunk檔案，我們就可以開始闡述最複雜的索引結構了。
### 定址過程
索引就是為了讓我們快速的找到想要的內容，為了便於理解。筆者就通過一次資料的定址來探究Prometheus的磁碟索引結構。考慮查詢一個
```
擁有系列三個標籤
({__name__:http_requests}{job:api-server}{instance:0})
且時間為start/end的所有序列資料
```
我們先從選擇Block開始,遍歷所有Block的meta.json，找到具體的Block
前文說了，通過Labels找資料是通過倒排索引。我們的倒排索引是儲存在index檔案裡面的。 那麼怎麼在這個單一檔案裡找到倒排索引的位置呢？這就引入了TOC(Table Of Content)
### TOC(Table Of Content)
由於index檔案一旦形成之後就不再會改變，所以Prometheus也依舊使用mmap來進行操作。採用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倒排索引
首先我們訪問的是Posting offset table。由於倒排索引按照不同的LabelPair(key/value)會有非常多的條目。所以Posing offset table就是決定到底訪問哪一條Posting索引。offset就是指的這一Posting條目在檔案中的偏移。
### Series
我們通過三條Postings倒排索引索引取交集得出
```
{series1,Series2,Series3,Series4}
∩
{series1,Series2,Series3}
∩
{Series2,Series3}
=
{Series2,Series3}
```
也就是要讀取Series2和Serie3中的資料，而Posting中的Ref(Series2)和Ref(Series3)即為這兩Series在index檔案中的偏移。
Series以Delta的形式記錄了chunkId以及該chunk包含的時間範圍。這樣就可以很容易過濾出我們需要的chunk,然後再按照chunk檔案的訪問，即可找到最終的原始資料。
### SymbolTable
值得注意的是，為了儘量減少我們檔案的大小，對於Label的Name和Value這些有限的資料，我們會按照字母序存在符號表中。由於是有序的，所以我們可以直接將符號表認為是一個
[]string切片。然後通過切片的下標去獲取對應的sting。考慮如下符號表:
讀取index檔案時候，會將SymbolTable全部載入到記憶體中，並組織成symbols []string這樣的切片形式，這樣一個Series中的所有標籤值即可通過切片下標訪問得到。
### Label Index以及Label Table
事實上，前面的介紹已經將一個普通資料定址的過程全部講完了。但是index檔案中還包含label索引以及label Table，這兩個是用來記錄一個Label下面所有可能的值而存在的。
這樣，在正則的時候就可以非常容易的找到我們需要哪些LabelPair。詳情可以見前篇。
事實上，真正的Label Index比圖中要複雜一點。它設計成一條LabelIndex可以表示(多個標籤組合)的所有資料。不過在Prometheus程式碼中只會採用儲存一個標籤對應所有值的形式。
## 完整的index檔案結構
這裡直接給出完整的index檔案結構，摘自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的資料一般在寫完後就不會變動。如果要刪除部分資料，就只能記錄一下刪除資料的範圍，由下一次compactor組成新block的時候刪除。而記錄這些資訊的檔案即是tomstones。
## 總結
Prometheus作為時序資料庫，設計了各種檔案結構來儲存海量的監控資料，同時還兼顧了效能。只有徹底瞭解其儲存結構，才能更好的指導我們應用它！
歡迎大家關注我公眾號，裡面有各種乾貨，還有大禮包相送哦!
