LSM tree （log-structured merge-tree） 是一種對(duì)頻繁寫操作非常友好的數(shù)據(jù)結(jié)構(gòu)，同時(shí)兼顧了查詢效率。LSM tree 是許多 key-value 型或日志型數(shù)據(jù)庫所依賴的核心數(shù)據(jù)結(jié)構(gòu)，例如 BigTable、HBase、Cassandra、LevelDB、SQLite、Scylla、RocksDB 等。

LSM tree 之所以有效是基于以下事實(shí)：磁盤或內(nèi)存的連續(xù)讀寫性能遠(yuǎn)高于隨機(jī)讀寫性能，有時(shí)候這種差距可以達(dá)到三個(gè)數(shù)量級(jí)之高。這種現(xiàn)象不僅對(duì)傳統(tǒng)的機(jī)械硬盤成立，對(duì) SSD 硬盤也同樣成立。如下圖：

LSM tree 在工作過程中盡可能避免隨機(jī)讀寫，充分發(fā)揮了磁盤連續(xù)讀寫的性能優(yōu)勢(shì)。

SSTable

LSM tree 持久化到硬盤上之后的結(jié)構(gòu)稱為 Sorted Strings Table （SSTable）。顧名思義，SSTable 保存了排序后的數(shù)據(jù)（實(shí)際上是按照 key 排序的 key-value 對(duì)）。每個(gè) SSTable 可以包含多個(gè)存儲(chǔ)數(shù)據(jù)的文件，稱為 segment，每個(gè) segment 內(nèi)部都是有序的，但不同 segment 之間沒有順序關(guān)系。一個(gè) segment 一旦生成便不再修改（immutable）。一個(gè) SSTable 的示例如下：

可以看到，每個(gè) segment 內(nèi)部的數(shù)據(jù)都是按照 key 排序的。下面我們來介紹每個(gè) segment 是如何生成的。

寫入數(shù)據(jù)

LSM tree 的所有寫操作均為連續(xù)寫，因此效率非常高。但由于外部數(shù)據(jù)是無序到來的，如果無腦連續(xù)寫入到 segment，顯然是不能保證順序的。對(duì)此，LSM tree 會(huì)在內(nèi)存中構(gòu)造一個(gè)有序數(shù)據(jù)結(jié)構(gòu)（稱為 memtable），例如紅黑樹。每條新到達(dá)的數(shù)據(jù)都插入到該紅黑樹中，從而始終保持?jǐn)?shù)據(jù)有序。當(dāng)寫入的數(shù)據(jù)量達(dá)到一定閾值時(shí)，將觸發(fā)紅黑樹的 flush 操作，把所有排好序的數(shù)據(jù)一次性寫入到硬盤中（該過程為連續(xù)寫），生成一個(gè)新的 segment。而之后紅黑樹便從零開始下一輪積攢數(shù)據(jù)的過程。

讀取/查詢數(shù)據(jù)

如何從 SSTable 中查詢一條特定的數(shù)據(jù)呢？一個(gè)最簡(jiǎn)單直接的辦法是掃描所有的 segment，直到找到所查詢的 key 為止。通常應(yīng)該從最新的 segment 掃描，依次到最老的 segment，這是因?yàn)樵绞亲罱臄?shù)據(jù)越可能被用戶查詢，把最近的數(shù)據(jù)優(yōu)先掃描能夠提高平均查詢速度。

當(dāng)掃描某個(gè)特定的 segment 時(shí)，由于該 segment 內(nèi)部的數(shù)據(jù)是有序的，因此可以使用二分查找的方式，在

O（logn） 的時(shí)間內(nèi)得到查詢結(jié)果。但對(duì)于二分查找來說，要么一次性把數(shù)據(jù)全部讀入內(nèi)存，要么在每次二分時(shí)都消耗一次磁盤 IO，當(dāng) segment 非常大時(shí)（這種情況在大數(shù)據(jù)場(chǎng)景下司空見慣），這兩種情況的代價(jià)都非常高。一個(gè)簡(jiǎn)單的優(yōu)化策略是，在內(nèi)存中維護(hù)一個(gè)稀疏索引（sparse index），其結(jié)構(gòu)如下圖：

稀疏索引是指將有序數(shù)據(jù)切分成（固定大小的）塊，僅對(duì)各個(gè)塊開頭的一條數(shù)據(jù)做索引。與之相對(duì)的是全量索引（dense index），即對(duì)全部數(shù)據(jù)編制索引，其中的任意一條數(shù)據(jù)發(fā)生增刪均需要更新索引。兩者相比，全量索引的查詢效率更高，達(dá)到了理論極限值

O（logn），但寫入和刪除效率更低，因?yàn)槊看螖?shù)據(jù)增刪時(shí)均需要因?yàn)楦滤饕囊淮?IO 操作。通常的關(guān)系型數(shù)據(jù)庫，例如 MySQL 等，其內(nèi)部采用 B tree 作為索引結(jié)構(gòu)，這便是一種全量索引。

有了稀疏索引之后，可以先在索引表中使用二分查找快速定位某個(gè) key 位于哪一小塊數(shù)據(jù)中，然后僅從磁盤中讀取這一塊數(shù)據(jù)即可獲得最終查詢結(jié)果，此時(shí)加載的數(shù)據(jù)量?jī)H僅是整個(gè) segment 的一小部分，因此 IO 代價(jià)較小。以上圖為例，假設(shè)我們要查詢 dollar 所對(duì)應(yīng)的 value。首先在稀疏索引表中進(jìn)行二分查找，定位到 dollar 應(yīng)該位于 dog 和 downgrade 之間，對(duì)應(yīng)的 offset 為 17208~19504。之后去磁盤中讀取該范圍內(nèi)的全部數(shù)據(jù)，然后再次進(jìn)行二分查找即可找到結(jié)果，或確定結(jié)果不存在。

稀疏索引極大地提高了查詢性能，然而有一種極端情況卻會(huì)造成查詢性能驟降：當(dāng)要查詢的結(jié)果在 SSTable 中不存在時(shí)，我們將不得不依次掃描完所有的 segment，這是最差的一種情況。有一種稱為**布隆過濾器（bloom filter）**的數(shù)據(jù)結(jié)構(gòu)天然適合解決該問題。布隆過濾器是一種空間效率極高的算法，能夠快速地檢測(cè)一條數(shù)據(jù)是否在數(shù)據(jù)集中存在。我們只需要在寫入每條數(shù)據(jù)之前先在布隆過濾器中登記一下，在查詢時(shí)即可斷定某條數(shù)據(jù)是否缺失。

布隆過濾器的內(nèi)部依賴于哈希算法，當(dāng)檢測(cè)某一條數(shù)據(jù)是否見過時(shí)，有一定概率出現(xiàn)假陽性（False Positive），但一定不會(huì)出現(xiàn)假陰性（False Negative）。也就是說，當(dāng)布隆過濾器認(rèn)為一條數(shù)據(jù)出現(xiàn)過，那么該條數(shù)據(jù)很可能出現(xiàn)過；但如果布隆過濾器認(rèn)為一條數(shù)據(jù)沒出現(xiàn)過，那么該條數(shù)據(jù)一定沒出現(xiàn)過。這種特性剛好與此處的需求相契合，即檢驗(yàn)?zāi)硹l數(shù)據(jù)是否缺失。

文件合并（Compaction）

隨著數(shù)據(jù)的不斷積累，SSTable 將會(huì)產(chǎn)生越來越多的 segment，導(dǎo)致查詢時(shí)掃描文件的 IO 次數(shù)增多，效率降低，因此需要有一種機(jī)制來控制 segment 的數(shù)量。對(duì)此，LSM tree 會(huì)定期執(zhí)行文件合并（compaction）操作，將多個(gè) segment 合并成一個(gè)較大的 segment，隨后將舊的 segment 清理掉。由于每個(gè) segment 內(nèi)部的數(shù)據(jù)都是有序的，合并過程類似于歸并排序，效率很高，只需要

O（n）O（n）的時(shí)間復(fù)雜度。

在上圖的示例中，segment 1 和 2 中都存在 key 為 dog 的數(shù)據(jù)，這時(shí)應(yīng)該以最新的 segment 為準(zhǔn)，因此合并后的值取 84 而不是 52，這實(shí)現(xiàn)了類似于字典/HashMap 中“覆蓋寫”的語義。

刪除數(shù)據(jù)

現(xiàn)在你已經(jīng)了解了 LSM tree 讀寫數(shù)據(jù)的方式，那么如何刪除數(shù)據(jù)呢？如果是在內(nèi)存中，刪除某塊數(shù)據(jù)通常是將它的引用指向 NULL，那么這塊內(nèi)存就會(huì)被回收。但現(xiàn)在的情況是，數(shù)據(jù)已經(jīng)存儲(chǔ)在硬盤中，要從一個(gè) segment 文件中間抹除一段數(shù)據(jù)必須要覆寫其之后的所有內(nèi)容，這個(gè)成本非常高。LSM tree 所采用的做法是設(shè)計(jì)一個(gè)特殊的標(biāo)志位，稱為 tombstone（墓碑），刪除一條數(shù)據(jù)就是把它的 value 置為墓碑，如下圖所示：

這個(gè)例子展示了刪除 segment 2 中的 dog 之后的效果。注意，此時(shí) segment 1 中仍然保留著 dog 的舊數(shù)據(jù)，如果我們查詢 dog，那么應(yīng)該返回空，而不是 52。因此，刪除操作的本質(zhì)是覆蓋寫，而不是清除一條數(shù)據(jù)，這一點(diǎn)初看起來不太符合常識(shí)。墓碑會(huì)在 compact 操作中被清理掉，于是置為墓碑的數(shù)據(jù)在新的 segment 中將不復(fù)存在。

LSM tree 與 B tree 的對(duì)比

主流的關(guān)系型數(shù)據(jù)庫均以 B/B+ tree 作為其構(gòu)建索引的數(shù)據(jù)結(jié)構(gòu)，這是因?yàn)?B tree 提供了理論上最高的查詢效率 O（log n）

O（logn）。但對(duì)查詢性能的追求也造成了 B tree 的相應(yīng)缺點(diǎn)，即每次插入或刪除一條數(shù)據(jù)時(shí)，均需要更新索引，從而造成一次磁盤 IO。這種特性決定了 B tree 只適用于頻繁讀、較少寫的場(chǎng)景。如果在頻繁寫的場(chǎng)景下，將造成大量的磁盤 IO，從而導(dǎo)致性能驟降。這種應(yīng)用場(chǎng)景在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中比較常見。

而 LSM tree 則避免了頻繁寫場(chǎng)景下的磁盤 IO 開銷，盡管其查詢效率無法達(dá)到理想的 O（log n）

O（logn），但依然非?？欤梢越邮?。所以從本質(zhì)上來說，LSM tree 相當(dāng)于犧牲了一部分查詢性能，換取了可觀的寫入性能。這對(duì)于 key-value 型或日志型數(shù)據(jù)庫是非常重要的。

總結(jié)

LSM tree 存儲(chǔ)引擎的工作原理包含以下幾個(gè)要點(diǎn)：

寫數(shù)據(jù)時(shí)，首先將數(shù)據(jù)緩存到內(nèi)存中的一個(gè)有序樹結(jié)構(gòu)中（稱為 memtable）。同時(shí)觸發(fā)相關(guān)結(jié)構(gòu)的更新，例如布隆過濾器、稀疏索引。

當(dāng) memtable 積累到足夠大時(shí)，會(huì)一次性寫入磁盤中，生成一個(gè)內(nèi)部有序的 segment 文件。該過程為連續(xù)寫，因此效率極高。

進(jìn)行查詢時(shí)，首先檢查布隆過濾器。如果布隆過濾器報(bào)告數(shù)據(jù)不存在，則直接返回不存在。否則，按照從新到老的順序依次查詢每個(gè) segment。

在查詢每個(gè) segment 時(shí)，首先使用二分搜索檢索對(duì)應(yīng)的稀疏索引，找到數(shù)據(jù)所在的 offset 范圍。然后讀取磁盤上該范圍內(nèi)的數(shù)據(jù)，再次進(jìn)行二分查找并獲得結(jié)果。

對(duì)于大量的 segment 文件，定期在后臺(tái)執(zhí)行 compaction 操作，將多個(gè)文件合并為更大的文件，以保證查詢效率不衰減。

責(zé)任編輯：haq