LevelDb日知錄之一：LevelDb 101

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

　　Jeff Dean其人：http://research.google.com/people/jeff/index.html，Google大規模分散式平臺Bigtable和MapReduce主要設計和實現者。

　　Sanjay Ghemawat其人：http://research.google.com/people/sanjay/index.html

，Google大規模分散式平臺GFS，Bigtable和MapReduce主要設計和實現工程師。

　　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不同層級有很多SSTable檔案（以後綴.sst為特徵），所有.sst檔案內部佈局都是一樣的。上節介紹Log檔案是物理分塊的，SSTable也一樣會將檔案劃分為固定大小的物理儲存塊，但是兩者邏輯佈局大不相同，根本原因是：Log檔案中的記錄是Key無序的，即先後記錄的key大小沒有明確大小關係，而.sst檔案內部則是根據記錄的Key由小到大排列的，從下面介紹的SSTable佈局可以體會到Key有序是為何如此設計.sst檔案結構的關鍵。

圖4.1 .sst檔案的分塊結構

　　圖4.1展示了一個.sst檔案的物理劃分結構，同Log檔案一樣，也是劃分為固定大小的儲存塊，每個Block分為三個部分，紅色部分是資料儲存區， 藍色的Type區用於標識資料儲存區是否採用了資料壓縮演算法（Snappy壓縮或者無壓縮兩種），CRC部分則是資料校驗碼，用於判別資料是否在生成和傳輸中出錯。

　　以上是.sst的物理佈局，下面介紹.sst檔案的邏輯佈局，所謂邏輯佈局，就是說盡管大家都是物理塊，但是每一塊儲存什麼內容，內部又有什麼結構等。圖4.2展示了.sst檔案的內部邏輯解釋。

圖4.2 邏輯佈局

　　從圖4.2可以看出，從大的方面，可以將.sst檔案劃分為資料儲存區和資料管理區，資料儲存區存放實際的Key:Value資料，資料管理區則提供一些索引指標等管理資料，目的是更快速便捷的查詢相應的記錄。兩個區域都是在上述的分塊基礎上的，就是說檔案的前面若干塊實際儲存KV資料，後面資料管理區儲存管理資料。管理資料又分為四種不同型別：紫色的Meta Block，紅色的MetaBlock 索引和藍色的資料索引塊以及一個檔案尾部塊。

　　LevelDb 1.2版對於Meta Block尚無實際使用，只是保留了一個介面，估計會在後續版本中加入內容，下面我們看看資料索引區和檔案尾部Footer的內部結構。

圖4.3 資料索引

　　圖4.3是資料索引的內部結構示意圖。再次強調一下，Data Block內的KV記錄是按照Key由小到大排列的，資料索引區的每條記錄是對某個Data Block建立的索引資訊，每條索引資訊包含三個內容，以圖4.3所示的資料塊i的索引Index i來說：紅色部分的第一個欄位記載大於等於資料塊i中最大的Key值的那個Key，第二個欄位指出資料塊i在.sst檔案中的起始位置，第三個欄位指出Data Block i的大小（有時候是有資料壓縮的）。後面兩個欄位好理解，是用於定位資料塊在檔案中的位置的，第一個欄位需要詳細解釋一下，在索引裡儲存的這個Key值未必一定是某條記錄的Key,以圖4.3的例子來說，假設資料塊i 的最小Key=“samecity”，最大Key=“the best”;資料塊i+1的最小Key=“the fox”,最大Key=“zoo”,那麼對於資料塊i的索引Index i來說，其第一個欄位記載大於等於資料塊i的最大Key(“the best”)同時要小於資料塊i+1的最小Key(“the fox”)，所以例子中Index i的第一個欄位是：“the c”，這個是滿足要求的；而Index i+1的第一個欄位則是“zoo”，即資料塊i+1的最大Key。

　　檔案末尾Footer塊的內部結構見圖4.4，metaindex_handle指出了metaindex block的起始位置和大小；inex_handle指出了index Block的起始地址和大小；這兩個欄位可以理解為索引的索引，是為了正確讀出索引值而設立的，後面跟著一個填充區和魔數。

圖4.4 Footer

　　上面主要介紹的是資料管理區的內部結構，下面我們看看資料區的一個Block的資料部分內部是如何佈局的（圖4.1中的紅色部分），圖4.5是其內部佈局示意圖。

圖4.5 資料Block內部結構

　　從圖中可以看出，其內部也分為兩個部分，前面是一個個KV記錄，其順序是根據Key值由小到大排列的，在Block尾部則是一些“重啟點”（Restart Point）,其實是一些指標，指出Block內容中的一些記錄位置。

　　“重啟點”是幹什麼的呢？我們一再強調，Block內容裡的KV記錄是按照Key大小有序的，這樣的話，相鄰的兩條記錄很可能Key部分存在重疊，比如key i=“the Car”，Key i+1=“the color”,那麼兩者存在重疊部分“the c”，為了減少Key的儲存量，Key i+1可以只儲存和上一條Key不同的部分“olor”，兩者的共同部分從Key i中可以獲得。記錄的Key在Block內容部分就是這麼儲存的，主要目的是減少儲存開銷。“重啟點”的意思是：在這條記錄開始，不再採取只記載不同的Key部分，而是重新記錄所有的Key值，假設Key i+1是一個重啟點，那麼Key裡面會完整儲存“the color”，而不是採用簡略的“olor”方式。Block尾部就是指出哪些記錄是這些重啟點的。

圖4.6 記錄格式

　　在Block內容區，每個KV記錄的內部結構是怎樣的？圖4.6給出了其詳細結構，每個記錄包含5個欄位：key共享長度，比如上面的“olor”記錄， 其key和上一條記錄共享的Key部分長度是“the c”的長度，即5；key非共享長度，對於“olor”來說，是4；value長度指出Key:Value中Value的長度，在後面的Value內容欄位中儲存實際的Value值；而key非共享內容則實際儲存“olor”這個Key字串。

　　上面講的這些就是.sst檔案的全部內部奧祕。

LevelDb日知錄之五：MemTable詳解

 　　LevelDb日知錄前述小節大致講述了磁碟檔案相關的重要靜態結構，本小節講述記憶體中的資料結構Memtable，Memtable在整個體系中的重要地位也不言而喻。總體而言，所有KV資料都是儲存在Memtable，Immutable Memtable和SSTable中的，Immutable Memtable從結構上講和Memtable是完全一樣的，區別僅僅在於其是隻讀的，不允許寫入操作，而Memtable則是允許寫入和讀取的。當Memtable寫入的資料佔用記憶體到達指定數量，則自動轉換為Immutable Memtable，等待Dump到磁碟中，系統會自動生成新的Memtable供寫操作寫入新資料，理解了Memtable，那麼Immutable Memtable自然不在話下。

 　　LevelDb的MemTable提供了將KV資料寫入，刪除以及讀取KV記錄的操作介面，但是事實上Memtable並不存在真正的刪除操作,刪除某個Key的Value在Memtable內是作為插入一條記錄實施的，但是會打上一個Key的刪除標記，真正的刪除操作是Lazy的，會在以後的Compaction過程中去掉這個KV。

 　　需要注意的是，LevelDb的Memtable中KV對是根據Key大小有序儲存的，在系統插入新的KV時，LevelDb要把這個KV插到合適的位置上以保持這種Key有序性。其實，LevelDb的Memtable類只是一個介面類，真正的操作是通過背後的SkipList來做的，包括插入操作和讀取操作等，所以Memtable的核心資料結構是一個SkipList。

 　　SkipList是由William Pugh發明。他在Communications of the ACM June 1990, 33(6) 668-676 發表了Skip lists: a probabilistic alternative to balanced trees，在該論文中詳細解釋了SkipList的資料結構和插入刪除操作。

SkipList是平衡樹的一種替代資料結構，但是和紅黑樹不相同的是，SkipList對於樹的平衡的實現是基於一種隨機化的演算法的，這樣也就是說SkipList的插入和刪除的工作是比較簡單的。

關於SkipList的詳細介紹可以參考這篇文章：http://www.cnblogs.com/xuqiang/archive/2011/05/22/2053516.html，講述的很清楚，LevelDb的SkipList基本上是一個具體實現，並無特殊之處。

　　SkipList不僅是維護有序資料的一個簡單實現，而且相比較平衡樹來說，在插入資料的時候可以避免頻繁的樹節點調整操作，所以寫入效率是很高的，LevelDb整體而言是個高寫入系統，SkipList在其中應該也起到了很重要的作用。Redis為了加快插入操作，也使用了SkipList來作為內部實現資料結構。

LevelDb日知錄之六 寫入與刪除記錄

      在之前的五節LevelDb日知錄中，我們介紹了LevelDb的一些靜態檔案及其詳細布局，從本節開始，我們看看LevelDb的一些動態操作，比如讀寫記錄，Compaction，錯誤恢復等操作。

       本節介紹levelDb的記錄更新操作，即插入一條KV記錄或者刪除一條KV記錄。levelDb的更新操作速度是非常快的，源於其內部機制決定了這種更新操作的簡單性。 

圖6.1 LevelDb寫入記錄

        圖6.1是levelDb如何更新KV資料的示意圖，從圖中可以看出，對於一個插入操作Put(Key,Value)來說，完成插入操作包含兩個具體步驟：首先是將這條KV記錄以順序寫的方式追加到之前介紹過的log檔案末尾，因為儘管這是一個磁碟讀寫操作，但是檔案的順序追加寫入效率是很高的，所以並不會導致寫入速度的降低；第二個步驟是:如果寫入log檔案成功，那麼將這條KV記錄插入記憶體中的Memtable中，前面介紹過，Memtable只是一層封裝，其內部其實是一個Key有序的SkipList列表，插入一條新記錄的過程也很簡單，即先查詢合適的插入位置，然後修改相應的連結指標將新記錄插入即可。完成這一步，寫入記錄就算完成了，所以一個插入記錄操作涉及一次磁碟檔案追加寫和記憶體SkipList插入操作，這是為何levelDb寫入速度如此高效的根本原因。

        從上面的介紹過程中也可以看出：log檔案內是key無序的，而Memtable中是key有序的。那麼如果是刪除一條KV記錄呢？對於levelDb來說，並不存在立即刪除的操作，而是與插入操作相同的，區別是，插入操作插入的是Key:Value 值，而刪除操作插入的是“Key:刪除標記”，並不真正去刪除記錄，而是後臺Compaction的時候才去做真正的刪除操作。

        levelDb的寫入操作就是如此簡單。真正的麻煩在後面將要介紹的讀取操作中。

LevelDb日知錄之七：讀取記錄

 　　LevelDb是針對大規模Key/Value資料的單機儲存庫，從應用的角度來看，LevelDb就是一個儲存工具。而作為稱職的儲存工具，常見的呼叫介面無非是新增KV，刪除KV，讀取KV，更新Key對應的Value值這麼幾種操作。LevelDb的介面沒有直接支援更新操作的介面，如果需要更新某個Key的Value,你可以選擇直接生猛地插入新的KV，保持Key相同，這樣系統內的key對應的value就會被更新；或者你可以先刪除舊的KV， 之後再插入新的KV，這樣比較委婉地完成KV的更新操作。

     假設應用提交一個Key值，下面我們看看LevelDb是如何從儲存的資料中讀出其對應的Value值的。圖7-1是LevelDb讀取過程的整體示意圖。

圖7-1  LevelDb讀取記錄流程

　　LevelDb首先會去檢視記憶體中的Memtable，如果Memtable中包含key及其對應的value，則返回value值即可；如果在Memtable沒有讀到key，則接下來到同樣處於記憶體中的Immutable Memtable中去讀取，類似地，如果讀到就返回，若是沒有讀到,那麼只能萬般無奈下從磁碟中的大量SSTable檔案中查詢。因為SSTable數量較多，而且分成多個Level，所以在SSTable中讀資料是相當蜿蜒曲折的一段旅程。總的讀取原則是這樣的：首先從屬於level 0的檔案中查詢，如果找到則返回對應的value值，如果沒有找到那麼到level 1中的檔案中去找，如此迴圈往復，直到在某層SSTable檔案中找到這個key對應的value為止（或者查到最高level，查詢失敗，說明整個系統中不存在這個Key)。

 　　那麼為什麼是從Memtable到Immutable Memtable，再從Immutable Memtable到檔案，而檔案中為何是從低level到高level這麼一個查詢路徑呢？道理何在？之所以選擇這麼個查詢路徑，是因為從資訊的更新時間來說，很明顯Memtable儲存的是最新鮮的KV對；Immutable Memtable中儲存的KV資料對的新鮮程度次之；而所有SSTable檔案中的KV資料新鮮程度一定不如記憶體中的Memtable和Immutable Memtable的。對於SSTable檔案來說，如果同時在level L和Level L+1找到同一個key，level L的資訊一定比level L+1的要新。也就是說，上面列出的查詢路徑就是按照資料新鮮程度排列出來的，越新鮮的越先查詢。

 　　為啥要優先查詢新鮮的資料呢？這個道理不言而喻，舉個例子。比如我們先往levelDb裡面插入一條資料{key="www.samecity.com"  value="我們"},過了幾天，samecity網站改名為：69同城，此時我們插入資料{key="www.samecity.com"  value="69同城"}，同樣的key,不同的value；邏輯上理解好像levelDb中只有一個儲存記錄，即第二個記錄，但是在levelDb中很可能存在兩條記錄，即上面的兩個記錄都在levelDb中儲存了，此時如果使用者查詢key="www.samecity.com",我們當然希望找到最新的更新記錄，也就是第二個記錄返回，這就是為何要優先查詢新鮮資料的原因。

　　前文有講：對於SSTable檔案來說，如果同時在level L和Level L+1找到同一個key，level L的資訊一定比level L+1的要新。這是一個結論，理論上需要一個證明過程，否則會招致如下的問題：為神馬呢？從道理上講呢，很明白：因為Level L+1的資料不是從石頭縫裡蹦出來的，也不是做夢夢到的，那它是從哪裡來的？Level L+1的資料是從Level L 經過Compaction後得到的（如果您不知道什麼是Compaction，那麼........也許以後會知道的），也就是說，您看到的現在的Level L+1層的SSTable資料是從原來的Level L中來的，現在的Level L比原來的Level L資料要新鮮，所以可證，現在的Level L比現在的Level L+1的資料要新鮮。

　　SSTable檔案很多，如何快速地找到key對應的value值？在LevelDb中，level 0一直都愛搞特殊化，在level 0和其它level中查詢某個key的過程是不一樣的。因為level 0下的不同檔案可能key的範圍有重疊，某個要查詢的key有可能多個檔案都包含，這樣的話LevelDb的策略是先找出level 0中哪些檔案包含這個key（manifest檔案中記載了level和對應的檔案及檔案裡key的範圍資訊，LevelDb在記憶體中保留這種對映表）， 之後按照檔案的新鮮程度排序，新的檔案排在前面，之後依次查詢，讀出key對應的value。而如果是非level 0的話，因為這個level的檔案之間key是不重疊的，所以只從一個檔案就可以找到key對應的value。

　　最後一個問題,如果給定一個要查詢的key和某個key range包含這個key的SSTable檔案，那麼levelDb是如何進行具體查詢過程的呢？levelDb一般會先在記憶體中的Cache中查詢是否包含這個檔案的快取記錄，如果包含，則從快取中讀取；如果不包含，則開啟SSTable檔案，同時將這個檔案的索引部分載入到記憶體中並放入Cache中。 這樣Cache裡面就有了這個SSTable的快取項，但是隻有索引部分在記憶體中，之後levelDb根據索引可以定位到哪個內容Block會包含這條key，從檔案中讀出這個Block的內容，在根據記錄一一比較，如果找到則返回結果，如果沒有找到，那麼說明這個level的SSTable檔案並不包含這個key，所以到下一級別的SSTable中去查詢。

　　從之前介紹的LevelDb的寫操作和這裡介紹的讀操作可以看出，相對寫操作，讀操作處理起來要複雜很多，所以寫的速度必然要遠遠高於讀資料的速度，也就是說，LevelDb比較適合寫操作多於讀操作的應用場合。而如果應用是很多讀操作型別的，那麼順序讀取效率會比較高，因為這樣大部分內容都會在快取中找到，儘可能避免大量的隨機讀取操作。

LevelDb日知錄之八：Compaction操作

     前文有述，對於LevelDb來說，寫入記錄操作很簡單，刪除記錄僅僅寫入一個刪除標記就算完事，但是讀取記錄比較複雜，需要在記憶體以及各個層級檔案中依照新鮮程度依次查詢，代價很高。為了加快讀取速度，levelDb採取了compaction的方式來對已有的記錄進行整理壓縮，通過這種方式，來刪除掉一些不再有效的KV資料，減小資料規模，減少檔案數量等。

     levelDb的compaction機制和過程與Bigtable所講述的是基本一致的，Bigtable中講到三種類型的compaction: minor ，major和full。所謂minor Compaction，就是把memtable中的資料匯出到SSTable檔案中；major compaction就是合併不同層級的SSTable檔案，而full compaction就是將所有SSTable進行合併。

     LevelDb包含其中兩種，minor和major。

    我們將為大家詳細敘述其機理。

    先來看看minor Compaction的過程。Minor compaction 的目的是當記憶體中的memtable大小到了一定值時，將內容儲存到磁碟檔案中，圖8.1是其機理示意圖。 

圖8.1 minor compaction

     從8.1可以看出，當memtable數量到了一定程度會轉換為immutable memtable，此時不能往其中寫入記錄，只能從中讀取KV內容。之前介紹過，immutable memtable其實是一個多層級佇列SkipList，其中的記錄是根據key有序排列的。所以這個minor compaction實現起來也很簡單，就是按照immutable memtable中記錄由小到大遍歷，並依次寫入一個level 0 的新建SSTable檔案中，寫完後建立檔案的index 資料，這樣就完成了一次minor compaction。從圖中也可以看出，對於被刪除的記錄，在minor compaction過程中並不真正刪除這個記錄，原因也很簡單，這裡只知道要刪掉key記錄，但是這個KV資料在哪裡?那需要複雜的查詢，所以在minor compaction的時候並不做刪除，只是將這個key作為一個記錄寫入檔案中，至於真正的刪除操作，在以後更高層級的compaction中會去做。

     當某個level下的SSTable檔案數目超過一定設定值後，levelDb會從這個level的SSTable中選擇一個檔案（level>0），將其和高一層級的level+1的SSTable檔案合併，這就是major compaction。

    我們知道在大於0的層級中，每個SSTable檔案內的Key都是由小到大有序儲存的，而且不同檔案之間的key範圍（檔案內最小key和最大key之間）不會有任何重疊。Level 0的SSTable檔案有些特殊，儘管每個檔案也是根據Key由小到大排列，但是因為level 0的檔案是通過minor compaction直接生成的，所以任意兩個level 0下的兩個sstable檔案可能再key範圍上有重疊。所以在做major compaction的時候，對於大於level 0的層級，選擇其中一個檔案就行，但是對於level 0來說，指定某個檔案後，本level中很可能有其他SSTable檔案的key範圍和這個檔案有重疊，這種情況下，要找出所有有重疊的檔案和level 1的檔案進行合併，即level 0在進行檔案選擇的時候，可能會有多個檔案參與major compaction。

　　levelDb在選定某個level進行compaction後，還要選擇是具體哪個檔案要進行compaction，levelDb在這裡有個小技巧，就是說輪流來，比如這次是檔案A進行compaction，那麼下次就是在key range上緊挨著檔案A的檔案B進行compaction，這樣每個檔案都會有機會輪流和高層的level 檔案進行合併。

如果選好了level L的檔案A和level L+1層的檔案進行合併，那麼問題又來了，應該選擇level L+1哪些檔案進行合併？levelDb選擇L+1層中和檔案A在key range上有重疊的所有檔案來和檔案A進行合併。

 　　也就是說，選定了level L的檔案A,之後在level L+1中找到了所有需要合併的檔案B,C,D…..等等。剩下的問題就是具體是如何進行major 合併的？就是說給定了一系列檔案，每個檔案內部是key有序的，如何對這些檔案進行合併，使得新生成的檔案仍然Key有序，同時拋掉哪些不再有價值的KV 資料。

    圖8.2說明了這一過程。

圖8.2 SSTable Compaction

　　Major compaction的過程如下：對多個檔案採用多路歸併排序的方式，依次找出其中最小的Key記錄，也就是對多個檔案中的所有記錄重新進行排序。之後採取一定的標準判斷這個Key是否還需要儲存，如果判斷沒有儲存價值，那麼直接拋掉，如果覺得還需要繼續儲存，那麼就將其寫入level L+1層中新生成的一個SSTable檔案中。就這樣對KV資料一一處理，形成了一系列新的L+1層資料檔案，之前的L層檔案和L+1層參與compaction 的檔案資料此時已經沒有意義了，所以全部刪除。這樣就完成了L層和L+1層檔案記錄的合併過程。

　　那麼在major compaction過程中，判斷一個KV記錄是否拋棄的標準是什麼呢？其中一個標準是:對於某個key來說，如果在小於L層中存在這個Key，那麼這個KV在major compaction過程中可以拋掉。因為我們前面分析過，對於層級低於L的檔案中如果存在同一Key的記錄，那麼說明對於Key來說，有更新鮮的Value存在，那麼過去的Value就等於沒有意義了，所以可以刪除。

 

LevelDb日知錄之九 levelDb中的Cache

　　書接前文，前面講過對於levelDb來說，讀取操作如果沒有在記憶體的memtable中找到記錄，要多次進行磁碟訪問操作。假設最優情況，即第一次就在level 0中最新的檔案中找到了這個key，那麼也需要讀取2次磁碟，一次是將SSTable的檔案中的index部分讀入記憶體，這樣根據這個index可以確定key是在哪個block中儲存；第二次是讀入這個block的內容，然後在記憶體中查詢key對應的value。

　　levelDb中引入了兩個不同的Cache:Table Cache和Block Cache。其中Block Cache是配置可選的，即在配置檔案中指定是否開啟這個功能。

圖9.1 table cache

 　　圖9.1是table cache的結構。在Cache中，key值是SSTable的檔名稱，Value部分包含兩部分，一個是指向磁碟開啟的SSTable檔案的檔案指標，這是為了方便讀取內容；另外一個是指向記憶體中這個SSTable檔案對應的Table結構指標，table結構在記憶體中，儲存了SSTable的index內容以及用來指示block cache用的cache_id ,當然除此外還有其它一些內容。

　　比如在get(key)讀取操作中，如果levelDb確定了key在某個level下某個檔案A的key range範圍內，那麼需要判斷是不是檔案A真的包含這個KV。此時，levelDb會首先查詢Table Cache，看這個檔案是否在快取裡，如果找到了，那麼根據index部分就可以查詢是哪個block包含這個key。如果沒有在快取中找到檔案，那麼開啟SSTable檔案，將其index部分讀入記憶體，然後插入Cache裡面，去index裡面定位哪個block包含這個Key 。如果確定了檔案哪個block包含這個key，那麼需要讀入block內容，這是第二次讀取。

圖9.2 block cache

 　　Block Cache是為了加快這個過程的，圖9.2是其結構示意圖。其中的key是檔案的cache_id加上這個block在檔案中的起始位置block_offset。而value則是這個Block的內容。

　　如果levelDb發現這個block在block cache中，那麼可以避免讀取資料，直接在cache裡的block內容裡面查詢key的value就行，如果沒找到呢？那麼讀入block內容並把它插入block cache中。levelDb就是這樣通過兩個cache來加快讀取速度的。從這裡可以看出，如果讀取的資料區域性性比較好，也就是說要讀的資料大部分在cache裡面都能讀到，那麼讀取效率應該還是很高的，而如果是對key進行順序讀取效率也應該不錯，因為一次讀入後可以多次被複用。但是如果是隨機讀取，您可以推斷下其效率如何。

LevelDb日知錄之十 Version、VersionEdit、VersionSet

　　Version 儲存了當前磁碟以及記憶體中所有的檔案資訊，一般只有一個Version叫做"current" version（當前版本）。Leveldb還儲存了一系列的歷史版本，這些歷史版本有什麼作用呢？

當一個Iterator建立後，Iterator就引用到了current version(當前版本)，只要這個Iterator不被delete那麼被Iterator引用的版本就會一直存活。這就意味著當你用完一個Iterator後，需要及時刪除它。

　　當一次Compaction結束後（會生成新的檔案，合併前的檔案需要刪除），Leveldb會建立一個新的版本作為當前版本，原先的當前版本就會變為歷史版本。

　　VersionSet 是所有Version的集合，管理著所有存活的Version。

　　VersionEdit 表示Version之間的變化，相當於delta 增量，表示有增加了多少檔案，刪除了檔案。下圖表示他們之間的關係。

Version0 +VersionEdit-->Version1

　　VersionEdit會儲存到MANIFEST檔案中，當做資料恢復時就會從MANIFEST檔案中讀出來重建資料。

　　leveldb的這種版本的控制，讓我想到了雙buffer切換，雙buffer切換來自於圖形學中，用於解決螢幕繪製時的閃屏問題，在伺服器程式設計中也有用處。

　　比如我們的伺服器上有一個字典庫，每天我們需要更新這個字典庫，我們可以新開一個buffer，將新的字典庫載入到這個新buffer中，等到載入完畢，將字典的指標指向新的字典庫。

leveldb的version管理和雙buffer切換類似，但是如果原version被某個iterator引用，那麼這個version會一直保持，直到沒有被任何一個iterator引用，此時就可以刪除這個version。