鄭重宣告：本篇部落格是自己學習 Leveldb 實現原理時參考了郎格科技系列部落格整理的，原文地址：

LevelDb日知錄之一：LevelDb 101

　　說起LevelDb也許您不清楚，但是如果作為IT工程師，不知道下面兩位大神級別的工程師，那您的領導估計會Hold不住了：Jeff Dean和Sanjay Ghemawat。這兩位是Google公司重量級的工程師，為數甚少的Google Fellow之二。

　　LevelDb就是這兩位大神級別的工程師發起的開源專案，簡而言之，LevelDb是能夠處理十億級別規模Key-Value型資料永續性儲存的C++ 程式庫。正像上面介紹的，這二位是Bigtable的設計和實現者，

如果瞭解Bigtable的話，應該知道在這個影響深遠的分散式儲存系統中有兩個核心的部分：Master Server和Tablet Server。其中Master Server做一些管理資料的儲存以及分散式排程工作，實際的分散式資料儲存以及讀寫操作是由Tablet Server完成的，而LevelDb則可以理解為一個簡化版的Tablet Server。

　　LevelDb有如下一些特點：

　　　　首先，LevelDb是一個持久化儲存的KV系統，和Redis這種記憶體型的KV系統不同，LevelDb不會像Redis一樣狂吃記憶體，而是將大部分資料儲存到磁碟上。

　　　　其次，LevleDb在儲存資料時，

是根據記錄的key值有序儲存的，就是說相鄰的key值在儲存檔案中是依次順序儲存的，而應用可以自定義key大小比較函式，LevleDb會按照使用者定義的比較函式依序儲存這些記錄。

　　　　再次，像大多數KV系統一樣，LevelDb的操作介面很簡單，基本操作包括寫記錄，讀記錄以及刪除記錄。也支援針對多條操作的原子批量操作。

　　　　另外，LevelDb支援資料快照（snapshot）功能，使得讀取操作不受寫操作影響，可以在讀操作過程中始終看到一致的資料。

　　除此外，LevelDb還支援資料壓縮等操作，這對於減小儲存空間以及增快IO效率都有直接的幫助。

　　LevelDb效能非常突出，官方網站報道其隨機寫效能達到40

萬條記錄每秒，而隨機讀效能達到6萬條記錄每秒。總體來說，LevelDb的寫操作要大大快於讀操作，而順序讀寫操作則大大快於隨機讀寫操作。至於為何是這樣，看了我們後續推出的LevelDb日知錄，估計您會了解其內在原因。

LevelDb日知錄之二：整體架構

      LevelDb本質上是一套儲存系統以及在這套儲存系統上提供的一些操作介面。為了便於理解整個系統及其處理流程，我們可以從兩個不同的角度來看待LevleDb：靜態角度和動態角度。從靜態角度，可以假想整個系統正在執行過程中（不斷插入刪除讀取資料），此時我們給LevelDb照相，從照片可以看到之前系統的資料在記憶體和磁碟中是如何分佈的，處於什麼狀態等；從動態的角度，主要是瞭解系統是如何寫入一條記錄，讀出一條記錄，刪除一條記錄的，同時也包括除了這些介面操作外的內部操作比如compaction，系統執行時崩潰後如何恢復系統等等方面。

     本節所講的整體架構主要從靜態角度來描述，之後接下來的幾節內容會詳述靜態結構涉及到的檔案或者記憶體資料結構，LevelDb日知錄後半部分主要介紹動態視角下的LevelDb，就是說整個系統是怎麼運轉起來的。

     LevelDb作為儲存系統，資料記錄的儲存介質包括記憶體以及磁碟檔案，如果像上面說的，當LevelDb運行了一段時間，此時我們給LevelDb進行透視拍照，那麼您會看到如下一番景象：

圖1.1：LevelDb結構

    從圖中可以看出，構成LevelDb靜態結構的包括六個主要部分：記憶體中的MemTable和Immutable MemTable以及磁碟上的幾種主要檔案：Current檔案，Manifest檔案，log檔案以及SSTable檔案。當然，LevelDb除了這六個主要部分還有一些輔助的檔案，但是以上六個檔案和資料結構是LevelDb的主體構成元素。

LevelDb的Log檔案和Memtable與Bigtable論文中介紹的是一致的，當應用寫入一條Key:Value記錄的時候，LevelDb會先往log檔案裡寫入，成功後將記錄插進Memtable中，這樣基本就算完成了寫入操作，因為一次寫入操作只涉及一次磁碟順序寫和一次記憶體寫入，所以這是為何說LevelDb寫入速度極快的主要原因。

Log檔案在系統中的作用主要是用於系統崩潰恢復而不丟失資料，假如沒有Log檔案，因為寫入的記錄剛開始是儲存在記憶體中的，此時如果系統崩潰，記憶體中的資料還沒有來得及Dump到磁碟，所以會丟失資料（Redis就存在這個問題）。為了避免這種情況，LevelDb在寫入記憶體前先將操作記錄到Log檔案中，然後再記入記憶體中，這樣即使系統崩潰，也可以從Log檔案中恢復記憶體中的Memtable，不會造成資料的丟失。

當Memtable插入的資料佔用記憶體到了一個界限後，需要將記憶體的記錄匯出到外存檔案中，LevleDb會生成新的Log檔案和Memtable，原先的Memtable就成為Immutable Memtable，顧名思義，就是說這個Memtable的內容是不可更改的，只能讀不能寫入或者刪除。新到來的資料被記入新的Log檔案和Memtable，LevelDb後臺排程會將Immutable Memtable的資料匯出到磁碟，形成一個新的SSTable檔案。SSTable就是由記憶體中的資料不斷匯出並進行Compaction操作後形成的，而且SSTable的所有檔案是一種層級結構，第一層為Level 0，第二層為Level 1，依次類推，層級逐漸增高，這也是為何稱之為LevelDb的原因。

    SSTable中的檔案是Key有序的，就是說在檔案中小key記錄排在大Key記錄之前，各個Level的SSTable都是如此，但是這裡需要注意的一點是：Level 0的SSTable檔案（字尾為.sst）和其它Level的檔案相比有特殊性：這個層級內的.sst檔案，兩個檔案可能存在key重疊，比如有兩個level 0的sst檔案，檔案A和檔案B，檔案A的key範圍是：{bar, car}，檔案B的Key範圍是{blue,samecity}，那麼很可能兩個檔案都存在key=”blood”的記錄。對於其它Level的SSTable檔案來說，則不會出現同一層級內.sst檔案的key重疊現象，就是說Level L中任意兩個.sst檔案，那麼可以保證它們的key值是不會重疊的。這點需要特別注意，後面您會看到很多操作的差異都是由於這個原因造成的。

    SSTable中的某個檔案屬於特定層級，而且其儲存的記錄是key有序的，那麼必然有檔案中的最小key和最大key，這是非常重要的資訊，LevelDb應該記下這些資訊。Manifest就是幹這個的，它記載了SSTable各個檔案的管理資訊，比如屬於哪個Level，檔名稱叫啥，最小key和最大key各自是多少。下圖是Manifest所儲存內容的示意：

圖2.1：Manifest儲存示意圖

圖中只顯示了兩個檔案（manifest會記載所有SSTable檔案的這些資訊），即Level 0的test.sst1和test.sst2檔案，同時記載了這些檔案各自對應的key範圍，比如test.sstt1的key範圍是“an”到 “banana”，而檔案test.sst2的key範圍是“baby”到“samecity”，可以看出兩者的key範圍是有重疊的。

Current檔案是幹什麼的呢？這個檔案的內容只有一個資訊，就是記載當前的manifest檔名。因為在LevleDb的執行過程中，隨著Compaction的進行，SSTable檔案會發生變化，會有新的檔案產生，老的檔案被廢棄，Manifest也會跟著反映這種變化，此時往往會新生成Manifest檔案來記載這種變化，而Current則用來指出哪個Manifest檔案才是我們關心的那個Manifest檔案。

以上介紹的內容就構成了LevelDb的整體靜態結構，在LevelDb日知錄接下來的內容中，我們會首先介紹重要檔案或者記憶體資料的具體資料佈局與結構。

LevelDb日知錄之三：log檔案

     上節內容講到log檔案在LevelDb中的主要作用是系統故障恢復時，能夠保證不會丟失資料。因為在將記錄寫入記憶體的Memtable之前，會先寫入Log檔案，這樣即使系統發生故障，Memtable中的資料沒有來得及Dump到磁碟的SSTable檔案，LevelDB也可以根據log檔案恢復記憶體的Memtable資料結構內容，不會造成系統丟失資料，在這點上LevelDb和Bigtable是一致的。

     下面我們帶大家看看log檔案的具體物理和邏輯佈局是怎樣的，LevelDb對於一個log檔案，會把它切割成以32K為單位的物理Block，每次讀取的單位以一個Block作為基本讀取單位，下圖展示的log檔案由3個Block構成，所以從物理佈局來講，一個log檔案就是由連續的32K大小Block構成的。

圖3.1 log檔案佈局

        在應用的視野裡是看不到這些Block的，應用看到的是一系列的Key:Value對，在LevelDb內部，會將一個Key:Value對看做一條記錄的資料，另外在這個資料前增加一個記錄頭，用來記載一些管理資訊，以方便內部處理，圖3.2顯示了一個記錄在LevelDb內部是如何表示的。

圖3.2 記錄結構

       記錄頭包含三個欄位，ChechSum是對“型別”和“資料”欄位的校驗碼，為了避免處理不完整或者是被破壞的資料，當LevelDb讀取記錄資料時候會對資料進行校驗，如果發現和儲存的CheckSum相同，說明資料完整無破壞，可以繼續後續流程。“記錄長度”記載了資料的大小，“資料”則是上面講的Key:Value數值對，“型別”欄位則指出了每條記錄的邏輯結構和log檔案物理分塊結構之間的關係，具體而言，主要有以下四種類型：FULL/FIRST/MIDDLE/LAST。

        如果記錄型別是FULL，代表了當前記錄內容完整地儲存在一個物理Block裡，沒有被不同的物理Block切割開；如果記錄被相鄰的物理Block切割開，則型別會是其他三種類型中的一種。我們以圖3.1所示的例子來具體說明。

       假設目前存在三條記錄，Record A，Record B和Record C，其中Record A大小為10K，Record B 大小為80K，Record C大小為12K，那麼其在log檔案中的邏輯佈局會如圖3.1所示。Record A是圖中藍色區域所示，因為大小為10K<32K，能夠放在一個物理Block中，所以其型別為FULL；Record B 大小為80K，而Block 1因為放入了Record A，所以還剩下22K，不足以放下Record B，所以在Block 1的剩餘部分放入Record B的開頭一部分，型別標識為FIRST，代表了是一個記錄的起始部分；Record B還有58K沒有儲存，這些只能依次放在後續的物理Block裡面，因為Block 2大小隻有32K，仍然放不下Record B的剩餘部分，所以Block 2全部用來放Record B，且標識型別為MIDDLE，意思是這是Record B中間一段資料；Record B剩下的部分可以完全放在Block 3中，型別標識為LAST，代表了這是Record B的末尾資料；圖中黃色的Record C因為大小為12K，Block 3剩下的空間足以全部放下它，所以其型別標識為FULL。

     從這個小例子可以看出邏輯記錄和物理Block之間的關係，LevelDb一次物理讀取為一個Block，然後根據型別情況拼接出邏輯記錄，供後續流程處理。

LevelDb日知錄之四：SSTable檔案

 　　SSTable是Bigtable中至關重要的一塊，對於LevelDb來說也是如此，對LevelDb的SSTable實現細節的瞭解也有助於瞭解Bigtable中一些實現細節。

本節內容主要講述SSTable的靜態佈局結構，我們曾在“LevelDb日知錄之二：整體架構”中說過，SSTable檔案形成了不同Level的層級結構，至於這個層級結構是如何形成的我們放在後面Compaction一節細說。本節主要介紹SSTable某個檔案的物理佈局和邏輯佈局結構，這對了解LevelDb的執行過程很有幫助。

　　LevelDb

相關推薦