摘要

閱讀這篇文章，希望你首先已經對Leveldb有了一定的了解，并預先知曉下列概念：

• LSM技術
• 跳表
• WAL技術
• Log Compaction

本文不是一篇專注于源代碼解析的文章，也不是一篇Leveldb的介紹文。我們更希望探討的是對于一般的單機數據存儲引擎存在哪些問題，Leveldb作為一個經典實現，是采用什么策略并如何解決這些問題的。
Leveldb的解決方案是出于什么考慮，如何高效實現的，做出了哪些權衡以及如何組織代碼和工程。你可以先從以下幾篇文章對Leveldb有一個基本了解。

Leveldb的實現原理

LevelDB之LSM-Tree

LevelDB設計與實現

Leveldb的基本架構

數據模型和需求

首先提出幾個問題：

• Leveldb在用戶視圖中的基本單元是什么？
• Leveldb一條記錄在內存中的形式是什么，記錄以怎樣的方式被組織？
• Leveldb的記錄在文件中的存儲格式是什么，多條記錄在單文件中是如何被管理的，多文件又是如何被管理的？
• Leveldb向用戶做出了怎樣的保證，在什么樣的場景下提供了優化？

首先，Leveldb所處理的每條記錄都是一條鍵值對，由于它基于sequence number提供快照讀，準確來說應該是鍵，序列號，值三元組，由于用戶一般關心最新的數據，可以簡化為鍵值對。

Leveldb對持久化的保證是基于操作日志的，一條寫操作只有落盤到操作日志中之后（暫時先這么理解，實際上這里有所出入，后面在優化部分會講到）才會在內存中生效，才能被讀取到。這就保證了對于已經能見到的操作，必定可以從操作日志中恢復。
它對一致性的保障可以認為是順序一致性（這里的一致性不是數據庫理論的一致性，不強調從安全狀態到另一個安全狀態，而是指從各個視圖看事件發生的順序是一致的，由于使用了write batch 競爭鎖，實際上寫入是串行化的，但同時并發的寫操作的順序取決于線程搶占鎖的順序）。
在這里我們可以稍微脫離leveldb的實現討論一下一致性，能不能實現線性一致性呢？如果我們不支持追加操作的情形下，寫是冪等的，如果確保版本號是按照操作開始時間嚴格遞增分配的，即使并發讀寫也是可以的，這樣做還有一個問題，就是如何支持快照讀，那就必須保留每一個寫記錄，但它們是亂序的，進行查找將是困難的，我們可以通過設置同步點，兩個同步點之間的是寫緩沖，快照讀只有在寫緩沖中需要遍歷查找，在寫緩沖被刷入之前重排序記錄，刷入的時機是任意小于當前同步點版本號的寫操作執行完畢。上述所描述的只可能適合于對熱點key的大量并發寫。上面所討論的接近編程語言的內存模型，可以參考JMM內存模型或者C++內存模型。

Leveldb對寫操作的要求是持久化到操作日志中，其所應對的數據量也超出了內存范圍，或者說其存儲內容的存儲主體還是在磁盤上，只不過基于最近寫的數據往往會被大量訪問的假設在內存中存儲了較新的數據。leveldb的核心做法就是保存了多個版本的數據以讓寫入操作不需要在磁盤中查找鍵的位置，將隨機寫改為順序寫，將這一部分代價某種程度上轉嫁給讀時在0層SSTable上的查找。那么它的讀性能受到影響了嗎？個人認為它的讀性能稍顯不足主要是受制于LSM的檢索方式而非由于多版本共存的問題，當然寫的便利也是基于這樣的組織方式。

上面這幾段主要是個人的一些想法，可能有些混亂，剩余的幾個問題將在下面的部分再詳細解答。

工程上的層次結構

leveldb的實現大致上可以分成以下幾層結構：

• 向用戶提供的DB類接口及其實現，主要是DB、DbImpl、iter等
• 中間概念層的memtable、table、version以及其輔助類，比如對應的iter、builder、VersionEdit等
• 更底層的偏向實際的讀寫輔助類，比如block、BlockBuilder、WritableFile及其實現等
• 最后是它定義的一些輔助類和實現的數據結構比如它用來表示數據的最小單元Slice、操作狀態類Status、memtable中用到的SkipList等

可能的性能瓶頸

首先讓我們考慮設計一款類似于Leveldb的存儲產品，那么面臨的主要問題主要是以下幾項：

• 寫入磁盤時的延遲
• 并發寫加鎖造成的競爭
• 讀操作時如何通過索引降低查找延遲
• 如何更好地利用cache優化查詢效率，增加命中
• 快速地從快照或者日志中恢復
• 后臺工作如何保持服務可用

Leveldb的內存管理

什么應該在內存中

在內存中存放的數據主要包含當前數據庫的元信息、memtable、ImmutableMemtable，前者顯然是必要的，后兩者存放的都是最新更新的數據。那么為什么需要有ImmutableMemtable呢。這是為了在持久化到磁盤上的同時保持對外服務可用，如果沒有這樣一個機制，那么我們要么需要持久化兩次，并在第一次持久化的中途記錄增量日志，第二次應用上去，這是CMS垃圾回收器的做法，但是顯然十分復雜；還有一種選擇是我們預留一定的空間，直接將要持久化的memtable拷貝一份，這樣做顯然會浪費大量可用內存，對于一個數據庫來說，這是災難性的。

那么元信息具體應該包含哪些信息呢？

• 當前的操作日志句柄
• 版本管理器、當前的版本信息（對應compaction）和對應的持久化文件標示
• 當前的全部db配置信息比如comparator及其對應的memtable指針
• 當前的狀態信息以決定是否需要持久化memtable和合并sstable
• sstable文件集合的信息

上面列出了一些比較重要的元信息，可能還有遺漏

memtable詳解

memtable的結構

memtable的鍵包含三個部分：

• Slice user ley
• sequence number
• value type

鍵的比較器首先按照遞增順序比較user key，然后安裝遞減順序比較sequence number，這兩個足以唯一確定一條記錄了。把user key放到前面的原因是，這樣對同一個user key的操作就可以按照sequence number順序連續存放了，不同的user key是互不相干的，因此把它們的操作放在一起也沒有什么意義。用戶所傳入的是LookupKey，它也是由User Key和Sequence Number組合而成的，其格式為：

| Size (int32變長)| User key (string) | sequence number (7 bytes) | value type (1 byte) |

這里的Size是user key長度+8，也就是整個字符串長度了。value type是kValueTypeForSeek，它等于kTypeValue。由于LookupKey的size是變長存儲的，因此它使用kstart_記錄了user key string的起始地址，否則將不能正確的獲取size和user key。

memtable本身存儲同一鍵的多個版本的數據，這一點從剛剛指出的鍵的格式也可以看出。這里為什么不直接在寫的時候直接將原有值替換并使用用戶鍵作為查找鍵呢？畢竟在memtable中add和update都需要先進行查找。個人認為除了需要支持快照讀也沒有別的解釋了，雖然這樣做會使得較老的記錄沒有被compact而較新的記錄已經compact了的奇怪現象發生，但并不影響數據庫的讀寫，在性能上也沒有損害。那么快照讀為何是必要的呢？這個問題我目前也沒有很好的回答，讀者可以自行思考。

memtable的追加

memtable的追加操作主要是將鍵值對進行編碼操作并最后委托給跳表處理，代碼很簡單，就放上來吧。

// KV entry字符串有下面4部分連接而成 // key_size : varint32 of internal_key.size() // key bytes : char[internal_key.size()] // value_size : varint32 of value.size() // value bytes : char[value.size()] size_t key_size = key.size(); size_t val_size = value.size(); size_t internal_key_size = key_size + 8; const size_t encoded_len = VarintLength(internal_key_size) + internal_key_size + VarintLength(val_size) + val_size; char* buf = arena_.Allocate(encoded_len); char* p = EncodeVarint32(buf, internal_key_size); memcpy(p, key.data(), key_size); p += key_size; EncodeFixed64(p, (s << 8) | type); p += 8; p = EncodeVarint32(p, val_size); memcpy(p, value.data(), val_size); assert((p + val_size) - buf == encoded_len); table_.Insert(buf);

有關跳表可以參考下列文章：

Skip List（跳躍表）原理詳解與實現

memtable的查找

根據傳入的LookupKey得到在memtable中存儲的key，然后調用Skip list::Iterator的Seek函數查找。Seek直接調用Skip list的FindGreaterOrEqual(key)接口，返回大于等于key的Iterator。然后取出user key判斷時候和傳入的user key相同，如果相同則取出value，如果記錄的Value Type為kTypeDeletion，返回Status::NotFound(Slice())。本質上依然委托跳表處理。

內存分配和釋放

Leveldb自己實現了基于引用計數的垃圾回收和一個簡單的內存池Arena，其實現預先分配大內存塊，劃分為不同對齊的內存空間，其機制乏善可陳，在這里就不多言，放張圖吧。

Arena主要提供了兩個申請函數：其中一個直接分配內存，另一個可以申請對齊的內存空間。Arena沒有直接調用delete/free函數，而是由Arena的析構函數統一釋放所有的內存。應該說這是和leveldb特定的應用場景相關的，比如一個memtable使用一個Arena，當memtable被釋放時，由Arena統一釋放其內存。

另外就是對于許多類比如memtable、table、cahe等leveldb都加上了引用計數，其實現也非常簡單，就是在對象中加入數據域refs，這也非常好理解。比如在迭代的過程中，已經進入下一個block中了，上一個block理應可以釋放了，但它有可能被傳遞出去提供某些查詢服務使用，在其計數不為0時不允許釋放，同理對于immutable_memtable，當它持久化完畢時，如果還在為用戶提供讀服務，也不能釋放。不得不說Leveldb的工程層次很清楚，幾乎沒有循環引用的問題。

Leveldb的磁盤存儲

需要存儲的內容

對于一個db，大致需要存儲下列文件

• db的操作日志
• 存儲實際數據的SSTable文件
• DB的元信息Manifest文件
• 記錄當前正在使用的Manifest文件，它的內容就是當前的manifest文件名
• 系統的運行日志，記錄系統的運行信息或者錯誤日志。
• 臨時數據庫文件，repair時臨時生成的。

SSTable詳解

SSTable文件組織

單個SSTable文件的組織如下圖所示：

大致分為幾個部分：

• 數據塊 Data Block，直接存儲有序鍵值對
• Meta Block，存儲Filter相關信息
• Meta Index Block，對Meta Block的索引，它只有一條記錄，key是meta index的名字（也就是Filter的名字），value為指向meta index的位置。
• Index Block，是對Data Block的索引，對于其中的每個記錄，其key >=Data Block最后一條記錄的key，同時<其后Data Block的第一條記錄的key；value是指向data index的位置信息
• Footer，指向各個分區的位置和大小，示意圖如下：

所有類型的block格式是一致的，主要包含下面幾部分：

其中type指的是采用哪種壓縮方式，當前主要是snappy壓縮，接下來主要講講block data部分的組織：

snappy是前綴壓縮的，為了兼顧查找效率，在構建Block時，每隔幾個key就直接存儲一個重啟點key。Block在結尾記錄所有重啟點的偏移，可以二分查找指定的key。Value直接存儲在key的后面，無壓縮。

普通的kv對存儲結構如下：

• 共享前綴長度
• 非共享鍵部分的長度
• 前綴之后的字符串
• 值

總體的Block Data如下：

總體來看Block可分為k/v存儲區和后面的重啟點存儲區兩部分，后面主要是重啟點的位置和個數。Block的大小是根據參數固定的，當不能存放下一條記錄時多余的空間將會閑置。

SSTable邏輯表達

SSTable在代碼上主要有負責讀相關的Table、Block和對應的Iterator實現；在寫上主要是BlockBuilder和TableBuilder。可以看出來這也是個典型的二層委托結構了，上面的層次將操作委托給下面層次的類執行，自己管控住progress的信息，控制當前的下層實體。這里我們主要關心Table和Block中應該存放哪些信息以支持它們的操作。

先講講簡單的Block，毫無疑問除了數據（char*+size）本身以外就是重啟點了，重啟點可是查詢的利器啊，直接的思路是解析重啟點部分成一個vector等，實際上Leveldb不是這樣做的，只是保留了一個指向重啟點部分的指針，至于為什么我們在查詢一節里再詳談。

再說說Table，

SSTable的寫入

首先，我們考慮在內存中構建一個連續的內存區域代表一個block的內容，它又可以分為兩部分：1. 數據的寫入 2. 數據寫入完畢后附加信息的添加。 先考慮追加一條記錄，我們需要知道哪些東西？

• 當前block提供給數據的剩余空間以確定是否需要換block
• 當前的重啟點以確定共享前綴
• 當前重啟點已有的key數量以確定是否將本次寫入作為新的重啟點
• 確保key的有序性，所以必須知道上次添加的key

在確定這些需要的信息后，追加的過程就是查找和維護這些信息以及單純的memcpy了。

第二步，讓我們考慮在數據寫入完畢之后需要為block添加其他信息的過程：

• 我們需要記錄所有的重啟點和重啟點位置，我們不得不在追加的時候來維護它們，看來得回去改上面的代碼了
• 我們得從配置元數據中得到壓縮類型
• 最后我們得記錄CRC

現在，我們可以把這么一段char[]的數據轉換成Slice表達的block了。接下來，讓我們考慮如何批量的把數據寫入單個SSTable文件中。這同樣分為三個步驟：1. 追加數據 2. 附加信息 3. Flush到文件。 我們依次考慮。

追加數據需要做哪些：

• 知道當前block及當前block能否再添加一條數據
• 維護有序性，需要上一次的key和新加key比較
• 如果生成新的block，為了維護索引，需要為將被替換的block生成索引記錄，所以必須維護一個index Block
• 維護過濾器信息（這一部分將在布隆過濾再詳細解釋，可以暫時忽略）
• 為了決定是否需要刷到文件中去，需要知道已寫的block數

實際上向文件寫入是以Block為單位的，當我們完成一個Block時，在將它寫入文件時需要做什么呢？

• 檢查工作，確定block確實需要寫入
• 壓縮工作
• 通知工作，告知index Block和Filter Block的維護方
• 重置工作，將當前block重置，準備下一次追加

最后，當數據全部添加完畢，該SSTable文件從此將不可變更，這一步需要執行的是：

• 寫入最后一塊data block
• 寫入Meta Block
• 根據上文寫入時留存的位置信息構建Meta Index Block
• 寫入Meta Index Block
• 將最后的data block位置信息寫入Index Block中，并將Index Block寫入文件
• 寫入Footer信息

SSTable的遍歷

SSTable的遍歷主要委托給一個two level iterator處理，我們只需要弄清楚它的Next操作就能明白其工作原理。所謂的two level，指的是索引一層，數據一層。在拿到一個SSTable文件的時候，我們先解析它的Index block部分，然后根據當前的index初始化data block層的iterator。接下來我們主要關注Next的過程。

分為兩種情形：

當前記錄不是當前Data Block的最后一條，只需要data iter向前進一步即可

當前記錄是最后一條，這時就要先前進一步index iter，得到data block的位置信息

讀取data block，此處先暫時省略table cache的優化，簡單起見都是從文件中讀

創建新的data iter

當然，二級迭代器還做了許多的其他工作，比如允許你傳入block function，但這和我們討論的主線無關，這里就不過多陳述了。

SSTable的查詢

SSTable的查詢也委托給iter處理，其主要過程就是對key的定位，也是主要分為三部分：

• 定位到哪個block
• 遷移到該block上
• 定位到block中的哪一條

無論是index block還是data block，它們的iter實現是一致的，其查找都遵循以下過程：

• 通過重啟點進行二分查找
• 跳到最大的不比目標大的重啟點，遍歷查找，一直到一個不比目標小的key出現

這里最絕妙的是兩點

• index block的設計和二級迭代器，一方面通過這種手段進行快速定位，另一方面將遍歷和查找統一到一個框架下，不可謂不妙
• 重啟點的設計，避免解析數據內容快速使用二分查找定位key的大致區域

我們都知道磁盤的讀寫是十分耗時的，索引的手段大量減少了磁盤讀的必要。當然，還有許多加速的手段比如過濾器和緩存，我們將在最后一節詳細解釋。

元信息存儲與管理

這里我們主要關注db的元信息，也即Manifest文件。

元信息文件的格式

首先，Manifest中應該包含哪些信息呢？

首先是使用的coparator名、log編號、前一個log編號、下一個文件編號、上一個序列號。這些都是日志、sstable文件使用到的重要信息，這些字段不一定必然存在。其次是compact點，可能有多個，寫入格式為{kCompactPointer, level, internal key}。其后是刪除文件，可能有多個，格式為{kDeletedFile, level, file number}。最后是新文件，可能有多個，格式為{kNewFile, level, file number, file size, min key, max key}。對于版本間變動它是新加的文件集合，對于MANIFEST快照是該版本包含的所有sstable文件集合。下面給出一張Manifest示意結構圖。

Leveldb在寫入每個字段之前，都會先寫入一個varint型數字來標記后面的字段類型。在讀取時，先讀取此字段，根據類型解析后面的信息。

元信息的邏輯表達

在代碼中元信息這一部分主要是Version類和VersionSet類。LeveDB用 Version 表示一個版本的元信息，Version中主要包括一個FileMetaData指針的二維數組，分層記錄了所有的SST文件信息。 FileMetaData 數據結構用來維護一個文件的元信息，包括文件大小，文件編號，最大最小值，引用計數等，其中引用計數記錄了被不同的Version引用的個數，保證被引用中的文件不會被刪除。除此之外，Version中還記錄了觸發Compaction相關的狀態信息，這些信息會在讀寫請求或Compaction過程中被更新。在CompactMemTable和BackgroundCompaction過程中會導致新文件的產生和舊文件的刪除。每當這個時候都會有一個新的對應的Version生成，并插入VersionSet鏈表頭部。

VersionSet是一個Version構成的雙向鏈表，這些Version按時間順序先后產生，記錄了當時的元信息，鏈表頭指向當前最新的Version，同時維護了每個Version的引用計數，被引用中的Version不會被刪除，其對應的SST文件也因此得以保留，通過這種方式，使得LevelDB可以在一個穩定的快照視圖上訪問文件。VersionSet中除了Version的雙向鏈表外還會記錄一些如LogNumber，Sequence，下一個SST文件編號的狀態信息。

元信息的修改

這里我們主要探討二個問題：

• 如何描述一次修改，或者說一次修改應該包括什么，怎樣才算是一次合法的修改？
• 如何應用一次修改，使得系統切換到新的配置上

描述一次變更的是VersionEdit類，而最為直接的持久化和apply它的辦法就是

構造VersionEdit并寫入Manifest文件

合并當前Version和versionEdit得到新version加入versionSet

將當前version指向新生成的version

首先，我們看看VersionEdit包含哪些內容：

std::string comparator_;uint64_t log_number_;uint64_t prev_log_number_;uint64_t next_file_number_;SequenceNumber last_sequence_;bool has_comparator_;bool has_log_number_;bool has_prev_log_number_;bool has_next_file_number_;bool has_last_sequence_;std::vector< std::pair<int, InternalKey> > compact_pointers_;DeletedFileSet deleted_files_;std::vector< std::pair<int, FileMetaData> > new_files_;

對比上文Manifest的結構，我們不難發現：Manifest文件記錄的是一組VersionEdit值，在Manifest中的一次增量內容稱作一個Block。

Manifest Block := N * VersionEdit

可以看出恢復元信息的過程也變成了依次應用VersionEdit的過程，這個過程中有大量的中間Version產生，但這些并不是我們所需要的。LevelDB引入VersionSet::Builder來避免這種中間變量，方法是先將所有的VersoinEdit內容整理到VersionBuilder中，然后一次應用產生最終的Version，這種實現上的優化如下圖所示：

元信息的持久化

Compaction過程會造成文件的增加和刪除，這就需要生成新的Version，上面提到的Compaction對象包含本次Compaction所對應的VersionEdit，Compaction結束后這個VersionEdit會被用來構造新的VersionSet中的Version。同時為了數據安全，這個VersionEdit會被Append寫入到Manifest中。在庫重啟時，會首先嘗試從Manifest中恢復出當前的元信息狀態，過程如下：

• 依次讀取Manifest文件中的每一個Block， 將從文件中讀出的Record反序列化為VersionEdit；
• 將每一個的VersionEdit Apply到VersionSet::Builder中，之后從VersionSet::Builder的信息中生成Version；
• 計算compaction_level_、compaction_score_；
• 將新生成的Version掛到VersionSet中，并初始化VersionSet的manifest_file_number_， next_file_number_，last_sequence_，log_number_，prev_log_number_ 信息；

操作日志存儲與管理

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

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

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

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的前驅后繼。

Leveldb的交互流程

recovery過程

Db恢復的步驟：

首先從CURRENT讀取最后提交的MANIFEST

讀取MANIFEST內容

清除過期文件

這里可以打開所有的sstable文件，但是更好的方案是lazy open

把log轉換為新的level 0sstable

將新寫操作導向到新的log文件，從恢復的序號開始

讀過程

讀的過程可以分為兩步：查找對應key+讀取對應值，主要問題在第一步。前面我們在SSTable章節中已經詳細解釋了對于單個SSTable文件如何快速定位key，在MemTable章節解釋了如何在內存中快速定位key；我們先大致列出查找的流程：

在MemTable中查找，無法命中轉到2

在immutable_memtable中查找，查找不中轉到3

在第0層SSTable中查找，無法命中轉到4

在剩余SSTable中查找

那么我們接下來的問題是對于第0層以及接下來若干層，如何快速定位key到某個SSTable文件？

對于Level > 1的層級，由于每個SSTable沒有交疊，在version中又包含了每個SSTable的key range，你可以使用二分查找快速找到你處于哪兩個點之間，再判斷這兩個點是否屬于同一個SSTable，就可以快速知道是否在這一層存在以及存在于哪個SSTable。

對于0層的，看來只能遍歷了，所以我們需要控制0層文件的數目。

寫過程

完成插入操作包含兩個具體步驟：

KV記錄以順序的方式追加到log文件末尾，并調用Sync將數據真正寫入磁盤。盡管這涉及到一次磁盤IO，但是文件的順序追加寫入效率是很高的，所以并不會導致寫入速度的降低；

如果寫入log文件成功，那么將這條KV記錄插入內存中的Memtable中。前面介紹過，Memtable只是一層封裝，其內部其實是一個Key有序的SkipList列表，插入一條新記錄的過程也很簡單，即先查找合適的插入位置，然后修改相應的鏈接指針將新記錄插入即可。

log文件內是key無序的，而Memtable中是key有序的。對于刪除操作，基本方式與插入操作相同的，區別是，插入操作插入的是Key:Value 值，而刪除操作插入的是“Key:刪除標記”，由后臺Compaction程序執行真正的垃圾回收操作。

其中的具體步驟可以參閱操作日志管理和memtable詳解這兩部分。

Leveldb的Log Compaction

Log Compaction的經典問題

在解釋Leveldb的log compaction過程之前我們先回顧幾個關于如何做compaction的重要問題：

• 為什么需要compaction？
• 何時需要做compaction
• 具體怎么做compaction
• 如何在compaction的同時保證服務可用
• compaction對性能的影響
• 如何在服務的延遲和單次compaction的收益做trade off

先回答第一個問題：，LevelDB之所以需要Compaction是有以下幾方面原因：

• 數據文件中的被刪除的KV記錄占用的存儲空間需要被回收；
• 將key存在重合的不同Level的SSTable進行Compaction，可以減少磁盤上的文件數量，提高讀取效率

我們接下來將主要圍繞這些問題給出Leveldb的答案。

compaction的時機

• 定期后臺觸發compaction任務
• 正常的讀寫流程中判定系統達到了一個臨界狀態，此時必須要進行Compaction

這里我們主要談談二，什么時候判斷，如何判斷到達了這個臨界狀態？

首先了解Leveldb的兩種Compaction：

• minor compaction：將內存immune memtable的數據dump至磁盤上的sstable文件。
• major compaction：多個level眾多SSTable之間的合并。

何時判斷是否需要compaction

• 啟動時，Db_impl.cc::Open()在完成所有的啟動準備工作以后，會發起一次Compaction任務。這時是由于還沒有開始提供服務，不會造成任何影響，還能夠提供之后所有的讀效率，一本萬利。
• 數據寫入過程中，使用函數MakeRoomForWrite確認memtable有足夠空間寫入數據
• get 操作時，如果有超過一個 sstable 文件進行了 IO，會檢查做 IO 的最后一個文件是否達到了 compact 的條件（ allowed_seeks 用光），達到條件，則主動觸發 compact。

在MakeRoomForWrite函數中:

先判斷是否有后臺合并錯誤，如果有，則啥都不做；如果沒有，則執行2;

如果后臺沒錯誤，則判斷mem_的大小是是否小于事先定義閾值：如果是，則啥都不做返回，繼續插入數據；如果大于事先定義的閾值，則需要進行一次minor compaction;

如果imm_不為空，代表后臺有線程在執行合并,在此等待;

如果0層文件個數太多，則也需要等待;

如果都不是以上情況，表示此時memtable空間不足且immu memtable不為空，需要將immune memtable的數據dump至磁盤sstable文件中。 這就是Minor Compaction了，調用MaybeScheduleCompaction()函數執行此事。

說明下為什么會有第4點：因為每進行一次minor compaction，level 0層文件個數可能超過事先定義的值，所以會又進行一次major compcation。而這次major compaction，imm_是空的，所以才會有第4條判斷。

如何判斷是否需要compaction

上文的MakeRoomForWrite主要針對Minor compaction，可以看出其判斷的依據主要就是有沒有足夠的空間執行下一次寫入操作；這里我們將主要關注major compaction，也就是文件的合并，其執行主要是在后臺的清理線程。

major compaction的觸發方式主要有三種：

• 某一level的文件數太多
• 某一文件的查找次數超過允許值
• 手動觸發

既然要判斷這幾個條件，就要維護相關信息，我們看看Leveldb為它們維護了哪些信息。

首先，介紹下列事實

不同level之間，可能存在Key值相同的記錄，但是記錄的Seq不同。 最新的數據存放在較低的level中，其對應的seq也一定比level+1中的記錄的seq要大。 因此當出現相同Key值的記錄時，只需要記錄第一條記錄，后面的都可以丟棄。level 0中也可能存在Key值相同的數據，但其Seq也不同。數據越新，其對應的Seq越大。 且level 0中的記錄是按照user_key遞增，seq遞減的方式存儲的，相同user_key對應的記錄被聚集在一起按照Seq遞減的方式存放的。 在更高層的Compaction時，只需要處理第一條出現的user_key相同的記錄即可，后面的相同user_key的記錄都可以丟棄。刪除記錄的操作也會在此時完成，刪除數據的記錄會被直接丟棄，而不會被寫入到更高level的文件。

接下來，我們分別對幾種觸發方式詳細介紹其機制：

• 容量觸發Compaction：每個Version在其生成的時候會初始化兩個值compaction_level_、compaction_score_，記錄了當前Version最需要進行Compaction的Level，以及其需要進行Compaction的緊迫程度，score大于1被認為是需要馬上執行的。我們知道每次文件信息的改變都會生成新的Version，所以每個Version對應的這兩個值初始化后不會再改變。level0層compaction_score_與文件數相關，其他level的則與當前層的文件總大小相關。這種區分的必要性也是顯而易見的：每次Get操作都需要從level0層的每個文件中嘗試查找，因此控制level0的文件數是很有必要的。同時Version中會記錄每層上次Compaction結束后的最大Key值compact_pointer_，下一次觸發自動Compaction會從這個Key開始。容量觸發的優先級高于下面將要提到的Seek觸發。
• Seek觸發Compaction：Version中會記錄file_to_compact_和file_to_compact_level_，這兩個值會在Get操作每次嘗試從文件中查找時更新。LevelDB認為每次查找同樣會消耗IO，這個消耗在達到一定數量可以抵消一次Compaction操作消耗的IO，所以對Seek較多的文件應該主動觸發一次Compaction。但在引入布隆過濾器后，這種查找消耗的IO就會變得微不足道了，因此由Seek觸發的Compaction其實也就變得沒有必要了。
• 手動Compaction：LevelDB提供了外部接口CompactRange，用戶可以指定觸發某個Key Range的Compaction，LevelDB默認手動Compaction的優先級高于兩種自動觸發。

這幾個觸發條件并非無的放矢，單個文件過大的容量會吸引大量的查詢并且這些查詢的速度由于其容量均會減慢，考慮極端情況，只有一個SSTable，那么查詢最快也得經歷其所有重啟點的二分查找。容量越大，能夠裝入內存的table就更少，需要發生文件讀的可能性就越大。對每一層次來說，上面的理由依然成立，一層的容量過大，要么是文件數很多，要么是單個文件的容量過大，后者已經分析過了，前者會導致二分變慢，而且新數據和老數據沒有區分度，不能對于這一假設（新的數據往往被更頻繁地訪問）做優化，而且對于同一key，其記錄數變多，重啟點能覆蓋的key變少，即使單個文件內的查找也變得低效。

某個文件頻繁地被查找，可能出于幾種情形：1. 它包含了太多的熱點key最新的記錄，也就是說它的查找大部分命中了。2. 它的key range 和一些長期木有更新而又被經常訪問的key重合了，這種就是出現大量未命中的查找。個人認為compaction主要改善的是后者，這也是為什么布隆過濾器使得seek compaction無足輕重，因為判斷一個SSTable是否含有對應key所需要的IO資源變少了，但如果你命中了，該讀的還是得讀，布隆并不能改善啥，所以個人認為主要為了改善第二點。

上面兩段就是Leveldb對于compaction的IO消耗與單次comapct收益權衡之后給出的答案。

compaction的過程

minor compaction

首先，我們來講講minor compaction，它的目的是把immutable_memtable寫入0層的SSTable文件中。我們已經只讀如何遍歷一個memtable了，也知道如何通過逐條添加構建一個SSTable了，更清楚了SSTable如何持久化到文件中。對上述步驟不明白的，請參閱上文memtable和sstable章節，所以minor compaction的過程不是理所當然的嗎？

這里，主要還是強調兩點：

• 寫入過程發生在immutable_memtable上，所以絲毫不影響寫服務，memtable依然可用
• 寫入文件過程完畢后，在交換memtable和immutable_memtabled之后，immutable_memtable正在服務的讀操作不會受到影響，這是得益于引用計數，直到服務完畢才會刪除原來的immutable_memtable

接下來，我們主要解析major compaction。

選取參與compaction的SSTable

除level0外，每個level內的SSTable之間不會有key的重疊：也就是說，某一個key只會出現在該level（level > 0）內的某個SSTable中。但是某個key可能出現在多個不同level的SSTable中。因此，大部分情形下，Compaction應該是發生在不同的level之間的SSTable之間。

對level K的某個SSTable S1，Level K+1中能夠與它進行Compaction的SSTable必須滿足條件：與S1存在key范圍的重合。

如上圖所示，對于SSTable X，其key范圍為hello ~ world，在level K+1中，SSTable M的key范圍為 mine ~ yours，與SSTable X存在key范圍的重合，同時SSTable N也是這樣。因此，對于 SSTable X，其Compaction的對象是Level K+1的SSTable M和SSTable N。

最后，考慮特殊情形——level0 的狀況。Level 0的SSTable之間也會存在key范圍的重合，因此進行Compaction的時候，不僅需要在level 1尋找可Compaction的SSTable，同時也要在level 0尋找，如下圖示：

major compaction的過程

先從觸發點開始考慮，我們就先從簡單的情況——也就是compact單個文件開始講起。先假設我們需要compact Level K層的某個文件，首先我們要做的就是首先找到參與compaction的所有文件，然后遍歷這些文件中的所有記錄，選取里面有效且最新的記錄寫入到新的SSTable文件。最后用新生成的SSTable文件替換掉原來的Level K + 1層的文件。

這樣我們就面臨一個生死攸關的問題了：當處理一條記錄的時候，如何判斷要不要將它寫入新文件中呢？答案是當有比它更新的同一key的記錄就拋棄它，那么如何找到這個更新的記錄呢？

最簡單的做法：由于Level k 比Level k+1新，Level k+1又不會出現key 重合，我們很自然地可以得到一個從新到舊的遍歷順序，只要去新寫入的SSTable中查詢即可。但這樣每次寫入都需要一次查詢，依然太慢了。我們能不能先按key序遍歷，在同一key內部再按seq遞減序遍歷，這樣只要保留每個key區間的第一個。Leveldb就是這么做的，但是如何實現呢？

Leveldb使用了一個merging iterator，它統籌控制每個SSTable的iterator，并在它們中選取一個前進，然后跳過所有同一key的記錄。這樣處理一條記錄所需的查找代價從查詢新SSTable文件的所有內容變成了詢問幾個SSTable對應iter的當前游標，不可謂不妙啊，令人驚嘆的做法！下圖是一個簡單的流程示意：

關于iterator的詳細參考可以閱讀下列文章：

庖丁解LevelDB之Iterator

下一步，我們把它擴展到一層文件的compaction：對于大多數層，由于文件之間的key range沒有交疊，所以你完全可以迭代進行上面的操作，分別對每一個文件合并。實際上major compaction是按key range來的，它每次會compact一個level中的一個范圍內的SSTable，然后將這個key范圍更新，下次就compact下一范圍，控制每一層參與一次compact的SSTable數量。

接下來，我們考慮Level 0 的情形，由于我們必須保證0層的總比1層新，假設0層本來有兩個同一key的記錄，較新的那個被合并到1層之后，查詢時在0層能查到較老的那個，bug出現了！所以我們不得不找出本層所有和當前所要合并的文件有重疊的文件加入合并集合來解決。

然后，我們來講講刪除的情形。Leveldb中的刪除是一個特殊記錄，它不會導致數據立即被刪除，而是查詢到刪除記錄后將會忽略更老的記錄。真正的刪除過程是發生在Compaction中的，這里我們又得問一個問題了：那么刪除記錄需要寫入到上一層嗎？需要的，否則在上上層的記錄就有可能被查到，只有最上層的刪除記錄會真正被刪除，所以刪除是逐步逐層地進行的，一層一層刪去過去的記錄。

我們考慮major compaction對服務可用性和性能的影響：在生成新SSTable期間，舊的SSTable依然可用。由于SSTable本就是不可寫的，所以對寫服務不會造成任何不可用，對于讀服務，依然可以在老的SSTable上進行。新的SSTable寫到的是一個臨時文件，當寫入完畢后會進行重命名操作，但是注意對于舊文件，必須查詢它在內存中有沒有對應的table以及該table的引用計數。只有當沒有讀服務在該文件上，才能刪除該文件。所以，綜上compaction對服務可用性沒有什么影響。

最后，我們還需要生成一次compact點，進行一次version edit并寫入Manifest文件，最終使當前version更新到新版本。這個過程在元信息管理中已經講述過了，就不再贅述了。

Leveldb的工程優化

write batch

Leveldb采用write batch來優化并發寫，對每一個寫操作，先通過傳入的鍵值對構造一個WriteBatch對象，這玩意里面其實就是一個字符串，多個并發寫的write batch最后會被合并成一個。這一段的代碼確實精妙，請參閱下列文章。

leveldb - 并發寫入處理

table cache

對于Leveldb這種主要基于磁盤存儲的引擎，cache優化是非常自然的想法。levelDb中引入了兩個不同的Cache:Table Cache和Block Cache。其中Block Cache是配置可選的。cache主要還是作用在讀過程中，詳細情況大家請參閱下列文章：

LevelDB教程9：levelDB中的Cache

源代碼實現解析：

leveldb源碼分析之Cache

如何作用在讀操作流程中的：

Leveldb源碼分析--11

布隆過濾器

先了解布隆過濾器的原理和概念：

Bloom Filter概念和原理

對實現感興趣的盆友，可以繼續看這篇文章

leveldb源碼學習--BloomFilter布隆過濾器

增加過濾器就需要在寫入SSTable的時候向過濾器添加自己寫入的鍵，這一點可以回頭看SSTable寫入過程。過濾器的作用在Compaction一章中也說了，主要為了改善當發現目標key在某個SSTable的key range內，但事實上未命中時，減少IO消耗，所以大家也知道解析過濾器部分應該用在哪兒了吧。

參考文章

• The Log-Structured Merge-Tree
• Leveldb源代碼
• 庖丁解LevelDB系列
• LevelDB專題系列
• Leveldb源碼解讀系列
• Leveldb之Put實現
• 那巖 《Leveldb實現解析》

總結

以上是生活随笔為你收集整理的Leveldb二三事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。