作為一個存儲引擎，數據存儲自然是LevelDB重中之重的需求。我們已經在庖丁解LevelDB之概覽中介紹了Leveldb的使用流程，以及數據在Memtable，Immutable，SST文件之間的流動。本文就將詳細的介紹LevelDB的數據存儲方式，包括數據在不同介質中的存儲方式，數據結構及設計思路。

Memtable

Memtable對應Leveldb中的內存數據，LevelDB的寫入操作會直接將數據寫入到Memtable后返回。讀取操作又會首先嘗試從Memtable中進行查詢。我們對Memtable的需求如下：

• 常駐內存；

• 可能會有頻繁的插入和查詢操作；
• 不會有刪除操作；
• 需要支持阻寫狀態下的遍歷操作（Immutable的Dump過程）

LevelDB采用跳表SkipList實現，在給提供了O(logn)的時間復雜度的同時，又非常的易于實現：

跳表

SkipList中單條數據存放一條Key-Value數據，定義為：

SkipList Node := InternalKey + ValueString
InternalKey := KeyString + SequenceNum + Type
Type := kDelete or kValue
ValueString := ValueLength + Value
KeyString := UserKeyLength + UserKey

Log

數據寫入Memtable之前，會首先順序寫入Log文件，以避免數據丟失。LevelDB實例啟動時會從Log文件中恢復Memtable內容。所以我們對Log的需求是：

• 磁盤存儲
• 大量的Append操作
• 沒有刪除單條數據的操作
• 遍歷的讀操作

LevelDB首先將每條寫入數據序列化為一個Record，單個Log文件中包含多個Record。同時，Log文件又劃分為固定大小的Block單位，并保證Block的開始位置一定是一個新的Record。這種安排使得發生數據錯誤時，最多只需丟棄一個Block大小的內容。顯而易見地，不同的Record可能共存于一個Block，同時，一個Record也可能橫跨幾個Block。

Log format

Block := Record * N
Record := Header + Content
Header := Checksum + Length + Type
Type := Full or First or Midder or Last

Log文件劃分為固定長度的Block，每個Block中包含多個Record；Record的前56個字節為Record頭，包括32位checksum用做校驗，16位存儲Record實際內容數據的長度，8位的Type可以是Full、First、Middle或Last中的一種，表示該Record是否完整的在當前的Block中，如果不是則通過Type指明其前后的Block中是否有當前Record的前驅后繼。

SST文件

SST文件是Leveldb中數據的最終存儲角色，劃分為不同的Level，Level 0的SST文件由Memtable直接Dump產生。其他層次的SST文件則由其上一層文件在Compaction過程中歸并產生。讀請求時可能會從SST文件中查找某條數據。我們對SST文件的需求是：

• 支持順序寫操作
• 支持遍歷操作
• 查找操作

我們將從物理格式和邏輯格式兩個方面來介紹SST文件中的數據存儲方式。所謂物理格式指的是數據的存儲和解析方式；利用確定的物理格式，我們可以存儲不同意義的數據，這就是數據的邏輯格式。

物理格式

LevelDB將SST文件定義為Table，每個Table又劃分為多個連續的Block，每個Block中又存儲多條數據Entry：

SST物理格式

可以看出，單個Block作為一個獨立的寫入和解析單位，會在其末尾存儲一個字節的Type和4個字節的Crc，其中Type記錄的是當前Block的數據壓縮策略，而Crc則存儲Block中數據的校驗信息。Block中每條數據Entry是以Key-Value方式存儲的，并且是按Key有序存儲，Leveldb很巧妙了利用了有序數組相鄰Key可能有相同的Prefix的特點來減少存儲數據量。如上圖所示，每個Entry只記錄自己的Key與前一個Entry Key的不同部分，例如要順序存儲Key值“apple”和“applepen”的兩條數據，這里第二個Entry中只需要存儲“pen”的信息。在Entry開頭記錄三個長度值，分別是當前Entry和其之前Entry的公共Key Prefix長度、當前Entry Key自有Key部分的長度和Value的長度。通過這些長度信息和其后相鄰的特有Key及Value內容，結合前一條Entry的Key內容，我們可以方便的獲得當前Entry的完整Key和Value信息。

這種方式非常好的減少了數據存儲，但同時也引入一個風險，如果最開頭的Entry數據損壞，其后的所有Entry都將無法恢復。為了降低這個風險，leveldb引入了重啟點，每隔固定條數Entry會強制加入一個重啟點，這個位置的Entry會完整的記錄自己的Key，并將其shared值設置為0。同時，Block會將這些重啟點的偏移量及個數記錄在所有Entry后邊的Tailer中。

邏輯格式

Table中不同的Block物理上的存儲方式一致，如上文所示，但在邏輯上可能存儲不同的內容，包括存儲數據的Block，存儲索引信息的Block，存儲Filter的Block：

SST邏輯格式

• Footer：為于Table尾部，記錄指向Metaindex Block的Handle和指向Index Block的Handle。需要說明的是Table中所有的Handle是通過偏移量Offset以及Size一同來表示的，用來指明所指向的Block位置。Footer是SST文件解析開始的地方，通過Footer中記錄的這兩個關鍵元信息Block的位置，可以方便的開啟之后的解析工作。另外Footer種還記錄了用于驗證文件是否為合法SST文件的常數值Magicnum。

• Index Block：記錄Data Block位置信息的Block，其中的每一條Entry指向一個Data Block，其Key值為所指向的Data Block最后一條數據的Key，Value為指向該Data Block位置的Handle?。

• Metaindex Block：與Index Block類似，由一組Handle組成，不同的是這里的Handle指向的Meta Block。

• Data Block：以Key-Value的方式存儲實際數據，其中Key定義為：

  DataBlock Key := UserKey + SequenceNum + Type
  Type := kDelete or kValue
  

  對比Memtable中的Key，可以發現Data Block中的Key并沒有拼接UserKey的長度在UserKey前，這是由于上面講到的物理結構中已經有了Key的長度信息。

• Meta Block：比較特殊的Block，用來存儲元信息，目前LevelDB使用的僅有對布隆過濾器的存儲。寫入Data Block的數據會同時更新對應Meta Block中的過濾器。讀取數據時也會首先經過布隆過濾器過濾。Meta Block的物理結構也與其他Block有所不同：

   [filter 0]
   [filter 1] 
   [filter 2] 
   ... 
   [filter N-1] 
   [offset of filter 0] : 4 bytes 
   [offset of filter 1] : 4 bytes 
   [offset of filter 2] : 4 bytes 
   ... 
   [offset of filter N-1] : 4 bytes 
   [offset of beginning of offset array] : 4 bytes 
   lg(base) : 1 byte
  

  其中每個filter節對應一段Key Range，落在某個Key Range的Key需要到對應的filter節中查找自己的過濾信息，base指定這個Range的大小。

總結

本文重點介紹了LevelDB不同介質角色中數據的存儲方式，并沒有過多的涉及代碼細節。因為一旦有了具體的存儲格式，相關的代碼不過就是在讀寫兩端的序列化反序列化。同樣，之后幾篇博客將要介紹的版本控制，迭代器，緩存等方面的內容也都非常緊密的依賴這些存儲格式。

參考

Source Code：https://github.com/google/leveldb

LevelDB Doc: https://raw.githubusercontent.com/google/leveldb/master/doc/table_format.txt

LevelDB Doc: https://raw.githubusercontent.com/google/leveldb/master/doc/log_format.txt

庖丁解LevelDB之概覽: http://catkang.github.io/2017/01/07/leveldb-summary.html