基於上一篇文章，我們已經知道了日誌結構的存儲引擎-bitcask的基本原理。在這個基礎上，繼續討論SSTable。
回顧一下bitcask的key-value，它在段文件中是無序的，假設按key排序，並且要求每個key在每個段中只能出現一次，排好序再寫入到段文件中，這種格式的段文件稱之爲SSTable。
一、SSTable比bitcask有什麼優點？
1，由於key在一個段中只出現一次且有序，可以使用類似合併排序的方式，在段文件合併時，即使文件大於可用內存也可簡單高效合併。如下圖：
2，在文件中查找特定key時，不再需要在內存中保存所有key的索引，假設正在查找key-handiwork，且不知道該key在段文件中的準確偏移量。但是知道key-handbag和key-handsome的偏移量，考慮到key是有序的，只需要從handbag掃描到handsome，假設key存在，就能找到。這是稀疏索引的一種設計思路。通常對於段文件中的每幾千字節，只需要一個key就足夠了。如下圖
二、如何構建和維護SSTable？
1，當寫入時，在內存中維護平衡樹結構，用於key-value排序，當這個樹內存大於某個閾值(通常爲幾M)時，將其作爲SSTable文件寫入磁盤。由於樹已經維護了按key排序的key-value對，寫磁盤可以很高效。當SSTable寫入磁盤的同時，寫入可以繼續添加到一個新的內存表。
2，爲避免數據庫崩潰時，最近寫入到內存但還沒落地到磁盤的數據丟失，在數據寫入內存表前，先在日誌文件中追加寫該數據，每當內存表寫入段文件時，該日誌文件就可以被丟棄。否則就用該文件恢復崩潰時丟失的數據。
3，爲了處理讀請求，首先嚐試從內存讀取，然後從最新的段文件讀到最舊的段文件。當一個key不存在時，這種掃描算法就很慢。爲了優化這種訪問，維護一個額外的布隆過濾器，如果key不存在布隆過濾器中，那麼key肯定不存在。
4，同樣類似bitcask，後臺進程週期性合併段文件。
三，基於合併和壓縮排序文件原理的存儲引擎，通常都被稱爲LSM-Tree。如leveldb、RocksDB都是基於LSM-Tree的思想實現。受到了google的bigtable論文的啓發。
原文出自：https://blog.csdn.net/daiyudong2020/article/details/104706867
End；