有任何問題請聯絡我：[email protected]

LevelDB是LSM最有名的實現系統。網上介紹的文章不少， 本文主要用於我自己的理解和備忘錄，我將用具體的例項來介紹LevelDB的讀寫過程，希望能讓讀者更加清楚其細節是如何實現的。

總體來說，LevelDB是LSM+SkipList來實現的。具體來說，memtable是SkipList， sstable是LSM。SkipList的結構如下圖所示：

SkipList是一個有序的list。如上圖例子中，key依照字母排序。既然是一個list，那麼只要找到對應位置後，插入新的元素只需要一個操作即可，即斷開原來的連結串列，插入新的元素即可。SkipList每個節點，除了其基本的元素外，還包括了額外的幾個元素（具體幾個可以當引數來設定）。那麼查詢的效率為O(logN)，具體證明可以見原始paper。

上面說了，對於插入而言，找到新的位置後，插入的效率為O(1)，那麼總的插入效率自然和查詢效率一直，即也是O(logN). 對SkipList的簡要介紹到此結束。

LevelDB的在記憶體中的資料結構就是SkipList。如上圖所示，只不過除了key之外，每個還包括了對應的value。例如NodeA，其key是A1001，value是一個字串xiaoming。LevelDB在記憶體中的資料結構稱之為memtable和immutable，其實都是SkipList，只不過memtable到了一定程度就是隻讀的了，就變成了immutable。那麼新來的寫入和更新操作都要新啟一個memtable來進行。這樣的話memtable和immutable就可能含有相同的key。查詢的時候是先從memtable開始找，如果找到了就返回，找不到再找immutable，因此就算memtable和immutable有兩個一樣的key，那麼因為memtable是先被找到，並且memtable含有的資料是最新的，因此返回也是最新的。

當immutable到達一定數量的時候，就要被置換到磁碟上，如上圖所示的Level0，其每一個檔案都是immutable置換過來的。注意，這個過程沒有Merge，就是把記憶體中的資料挪到磁碟上（我們不是資料的創造者，我們只是資料的搬運工）。上文我們提到，memtable和immutable是有可能有相同key的，也就是說immutable之間也可能有相同的key。所以Level0中的檔案是有可能有相同的key的。因此當查詢的時候，如果需要查詢Level0，就需要查詢多個檔案，然後比較最後的結果，選擇最新的。當然也可以做些優化，我們暫時不提。

當Level0中的檔案數量達到一定的時候，就要進行真正的Merge。如果有相同的key，merge的時候要把老的資料去掉，因此從Level1開始，sstable檔案之間不會出現相同的key。所以如果能定位到一個檔案含有要查詢的key，那麼這一層就不用再去查詢別的檔案了。