數據庫k/v存儲模型淺析——Hash，B樹，LSM

1.基於哈希的存儲引擎BitCask

 常見模型是BitCask

 

  併發下的數據庫文件讀寫：

  原本想使用FileLock，可是後來發現 FileLock是進程間的，並不能用於同一個JVM多個線程之間的同步：

File locks are held on behalf of the entire Java virtual machine.
* They are not suitable for controlling access to a file by multiple
* threads within the same virtual machine.

2.LSM （Log Structured Merge Trees）

 

日誌結構合併樹，LSM 做爲核心的文件組織方法如今已經被應用到大量的產品中。HBase、Cassandra、LevelDB、SQLite，甚至 MongoDB 3.0 版本在收購 Wired Tiger 引擎以後都是由 LSM 算法驅動的。

LSM使磁盤儘量的產生順序訪問，而不是分散的隨機訪問

 

LSM基本結構：

• 內存中的MemTable：通常用跳躍表來組織；當MemTable達到必定大小後，將其凍結起來變成Immutable MemTable，而後開闢一個新的MemTable用來記錄新的記錄。而Immutable MemTable則等待轉存到磁盤
• 內存中的Immutable MemTable：只能讀不能寫的內存表；
• 磁盤中的SSTable：存儲的就是一系列的鍵值對
• Bloom Filter：提升Key在不在SSTable的斷定速度

 

布隆過濾器和動態緩存有點像，不過都是數據結構很典型的例子，使用空間大幅度的下降了時間的使用。 

  

 

 

 

 

bloom 藉助的是一個大大大的位表以及多個hash函數，例如圖中，將{x,y,z}的用3個hash函數映射到位表中。那麼位表中有n個位置有標1,（3<=n<=9）。

1. 若是這個時候來了個w，w通過3個hash函數，對應到位表上的位置有一個映射的值爲0，那麼說明w確定不在{x,y,x}中。
2. 若是w的3個hash函數映射後，都爲1，並不可以說明w在{x,y,z}中。有多是相似上圖4，5，6位置格，而那些格是有不一樣的值映射出來的。

 

 

 

基本的LSM算法

 

從概念上講，基本 LSM 算法很簡單。批量寫入被順序地保存到一組較小的索引文件而不是一個很大的索引結構（將會使文件系統內部分散或者增長寫入放大）。因此每個文件都包含一小段時間的變化。在寫入後每個文件都被排序，因此在以後查找的時候會快不少。文件是不可變的，它們也從不更新。新的更新將會被寫入新的文件。讀取檢查全部的文件，並按期將文件合併從而減小文件的數量。