LSM樹和Elasticsearch的索引寫入機制

LSM簡介

Log Structured Merge Tree，下面簡稱 LSM。2006年，Google 發表了 BigTable 的論文。這篇論文提到 BigTable 單機上所使用的數據結構就是 LSM。目前，LSM 被很多存儲產品作為存儲結構，比如 Apache HBase, Apache Cassandra, MongoDB 的 Wired Tiger 存儲引擎, LevelDB 存儲引擎, RocksDB 存儲引擎等。簡單地說，LSM 的設計目標是提供比傳統的 B+ 樹更好的 寫性能。LSM 通過 將磁盤的隨機寫轉化為順序寫來提高寫性能 ，而付出的代價就是犧牲部分讀性能、 寫放大（B+樹同樣有寫放大的問題）。LSM 相比 B+ 樹能提高寫性能的本質原因是：外存，其隨機讀寫都要慢於順序讀寫，無論磁盤還是 SSD。

三種基本的存儲引擎

1、哈希存儲引擎

是哈希表的持久化實現，支持增、刪、改以及隨機讀取操作，但不支持順序掃描，對應的存儲系統為key-value存儲系統。對於key-value的插入以及查詢，哈希表的復雜度都是O(1)，明顯比樹的操作O(n)快，如果不需要有序的遍歷數據，哈希表就是正確的選擇。

2、B樹存儲引擎

是B樹的持久化實現，不僅支持單條記錄的增、刪、讀、改操作，還支持順序掃描（B+樹的葉子節點之間的指針），對應的存儲系統就是關系數據庫（Mysql等）。

3、LSM樹存儲引擎

和B樹存儲引擎一樣，同樣支持增、刪、讀、改、順序掃描操作。而且通過批量存儲技術規避磁盤隨機寫入問題。當然凡事有利有弊，LSM樹和B+樹相比，LSM樹犧牲了部分讀性能，用來大幅提高寫性能。

LSM樹（Log Structured Merge Tree，結構化合並樹）的思想非常朴素，就是將對數據的修改增量保持在內存中，達到指定的大小限制后將這些修改操作批量寫入磁盤（由此提升了寫性能），是一種基於硬盤的數據結構，與B-tree相比，能顯著地減少硬盤磁盤臂的開銷。讀取時需要合並磁盤中的歷史數據和內存中最近的修改操作，讀取時可能需要先看是否命中內存，否則需要訪問較多的磁盤文件（存儲在磁盤中的是許多小批量數據，由此降低了部分讀性能。但是磁盤中會定期做merge操作，合並成一棵大樹，以優化讀性能）。LSM樹的優勢在於有效地規避了磁盤隨機寫入問題，但讀取時可能需要訪問較多的磁盤文件。

LSM tree的核心特點：

1. 將索引分為內存和磁盤兩部分，並在內存達到閾值時啟動樹合並（Merge Trees）；
2. 用批量寫入代替隨機寫入，並且用預寫日志 WAL 技術（Elasticsearch 中為 translog 事務日志）保證內存數據，在系統崩潰后可以被恢復；
3. 數據采取類似日志追加寫的方式寫入（Log Structured）磁盤，以順序寫的方式提高寫入效率。

ES中的segment寫入機制

一個文檔被索引之后，就會被添加到內存緩沖區，並且追加到了translog中。

索引分片（shard）每秒被刷新（refresh）一次：

• 這些在內存緩沖區的文檔被寫入到一個新的段中，且沒有進行 fsync 操作。
• 這個段被打開，使其可被搜索。
• 內存緩沖區被清空。

Segment在被refresh之前，數據保存在內存中，是不可被搜索的，這也就是為什么 ES 被稱為提供近實時而非實時查詢的原因。

這個進程繼續工作，更多的文檔被添加到內存緩沖區和追加到事務日志

每隔一段時間，例如 translog 變得越來越大，索引被刷新（flush）；一個新的 translog 被創建，並且一個全量提交被執行：

• 所有在內存緩沖區的文檔都被寫入一個新的段。
• 緩沖區被清空。
• 一個提交點被寫入硬盤。
• 文件系統緩存通過 fsync 被刷新（flush）。
• 老的 translog 被刪除。

數據先寫入到內存中，通過定時refresh機制寫入到一個segment中，ES后台會進行segment merge（段合並）操作，將多個小的segment合並大的segment。

如上這種機制避免了隨機寫，數據寫入都是 Batch 和 Append，能達到很高的吞吐量。同時為了提高寫入的效率，利用了文件緩存系統和內存來加速寫入時的性能，並使用translog日志來防止數據的丟失。

對比LSM，ES的這種segment分段寫，再合並的機制，和LSM的思想是一致的。

 

參考：

https://www.cnblogs.com/yefeng654321/articles/11422231.html

https://www.jianshu.com/p/42d9dcd4f8cd