LSM（log-structed-merge-tree）

leveldb和rocksdb底層使用LSM樹做存儲引擎，LSM樹使用skiplist做索引，他們先將數據寫入內存中，按照key進行劃分，定期的merge寫入到磁盤中，合并后數據寫入下一層level

LSM是什么?解決什么問題？
在leveldb和rocksdb中，面臨的一個主要問題是數據的落盤，在寫磁盤時，隨機寫會消耗很大的磁盤IO，因此為了解決隨機寫的問題，引入了LSM樹。LSM樹將隨機寫變成了append，極大地降低了磁盤IO的消耗。

?

MySQL的innodb引擎使用了B+樹作為索引

B+樹作為索引時，隨機讀很快，但是有大量的隨機寫時，會占用很多的磁盤IO導致消耗比較大。B+樹是通過降低樹的高度，使樹的分叉盡可能多來達到查詢時的高效率的。但是在update、insert或delete時，需要進行樹的調整，因此磁盤IO的消耗會比較大。所以說B+樹不適合作為leveldb和rocksdb的存儲引擎。

例如：假設要寫入一個100000個隨機的key，對磁盤來說，最快的寫入方式一定是順序地將每一次寫入都直接寫入到磁盤中即可。
但這樣帶來的問題是查詢消耗大量的磁盤IO，因為每次查詢一個值都需要遍歷整個數據才能找到，這個讀性能就太差了；
那么如果我想獲取磁盤讀性能最高，應該怎么做呢？把數據全部排序就行了，B+樹就是這樣的結構，但B+樹的寫性能太差了，需要提升寫，可以放棄部分磁盤讀性能，怎么辦呢？ 引入LSM樹

LSM是如何解決問題的？

LSM樹將隨機寫變成了append，降低了磁盤IO的消耗，但是以犧牲部分讀性能達到優化寫性能的目的。

將有序的分組數據劃分很多個小的有序結構，比如每m個數據，在內存里排序一次，下面100個數據，再排序一次……這樣依次做下去，我就可以獲得N/m個有序的小的有序結構，在查詢的時候，因為不知道這個數據到底是在哪里，所以就從最新的一個小的有序結構里做二分查找，找得到就返回，找不到就繼續找下一個小有序結構，一直到找到為止。

因此，LSM樹讀取的時間復雜度是(N/m)*log2N，讀取效率是會下降的，這就是LSM的根本思路。

為了降低讀時磁盤IO的消耗，leveldb和rocksdb引入了bloom filter和compact機制。

?

LSM樹是以犧牲讀的效率來達到提升隨機寫效率的目的。

總結

以上是生活随笔為你收集整理的LSM树存储模型的全部內容，希望文章能夠幫你解決所遇到的問題。

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