bitcask 是乙個日誌型、基於hash表結構的key-value儲存模型，以bitcask為儲存模型的k-v系統有 riak 和 beansdb 新版本。
檔案中的資料結構非常簡單，是一條一條的資料寫入操作，每一條資料的結構如下：
上面資料項分別為key，value，key的大小，value的大小，時間戳（應該是），以及對前面幾項做的crc校驗值。（資料刪除操作也不會刪除舊的條目，而是將value設定為乙個特殊的值以作標示）
資料檔案中就是連續一條條上面格式的資料，如下圖：
上面就是日誌型的資料檔案，但檔案這樣持續的存下去，肯定是會無限膨脹的，為了解決個問題，和其他日誌型儲存系統一樣bitcask也有乙個定期的merge操作。
merge操作，即定期將所有older data file中的資料掃瞄一遍並生成新的data file（沒有包括active data file 是因為它還在不停寫入），這裡的merge其實就是將對同乙個key的多個操作以只保留最新乙個的原則進行刪除。每次merge後，新生成的資料檔案就不再有冗餘資料了。
事實上，bitcask 中有兩類檔案：
write.pos：記錄當前數值最大的 ***.w 檔案（fileno），以及該檔案的寫位移（offset），方便在寫資料的時候快速定位；
定義了資料檔案和記錄寫位移的檔案後，我們通過以下方式實現資料寫：
寫操作有 write.pos 檔案指明要寫入的 fileno 和 offset；但對於讀操作，如何快速地從浩瀚的資料中，找到某個 key 對應資料所在的檔案和檔案位移呢？這要依賴於記憶體中的hash表資料索引，如下圖
hash表對應的這個結構中包括了三個用於定位資料value的資訊，分別是檔案id號(file_id)，value值在檔案中的位置（value_pos）,value值的大小（value_sz），於是我們通過讀取file_id對應檔案的value_pos開始的value_sz個位元組，就得到了我們需要的value值。整個過程如下圖所示：
由於多了乙個hash表的存在，我們的寫操作就需要多更新一塊內容，即這個hash表的對應關係。於是乙個寫操作就需要進行一次順序的磁碟寫入和一次記憶體操作。
另外，由於索引hash表是存放在記憶體中的，每次程序重啟時需要重建hash表，這需要整個掃瞄一遍所有的資料檔案，如果資料檔案很大，這將是乙個非常耗時的過程。因此bitcask模型中包含了乙個稱作hint file的部分，目的在於提高重建hash表的速度。
上面講到在old data file進行merge操作時，會產生新的data file，而bitcask模型實際還鼓勵生成乙個hint file，這個hint file中每一項的資料結構，與data file中的資料結構非常相似，不同的是他並不儲存具體的value值，而是儲存value的位置，這樣，在重建hash表時，就不需要再掃瞄所有data file檔案，而僅僅需要將hint file中的資料一行行讀取並重建即可。大大提高了利用資料檔案重啟資料庫的速度。
Bitcask儲存模型
近期一直在分析oceanbase的源 恰巧碰到了oceanbase的核心開發人員的新作 大規模分布式儲存系統 原理解析與架構實戰 看完樣章後決定入手，果然物有所值。對於準備學習分布式的同學，這是一本不錯的書籍，相對系統，全面的介紹了分布式的相關技術和專案，基本都是乾貨。另一半是在介紹oceanbas...
mysql資料儲存模型 資料儲存模型
rdbms nosql hadoop hbase hbase以big table為藍本，以鍵值對儲存，實現快速在主機內億級記錄中定位到所需的資料並訪問它。hbase彌補了hadoop無法隨即讀寫的缺陷，如果需要實時的訪問資料，就把資料存入hbase。hbase常應用於建立網際網路索引 推薦系統後台 ...
資料儲存模型
在網際網路行業，通常需要高併發 高效能 高可用性的資料庫系統。在處理大資料時，關係型資料庫遭遇了瓶頸，這就促使我們思考從資料模型的根源入手，來解決效能上的問題。根據資料的儲存模型和特點，nosql資料庫分為很多種類，主要分為以下四個型別 鍵值模型 列式模型 文件模型與圖形模型。鍵值模型 例項 dyn...