近期一直在分析oceanbase的源**，恰巧碰到了oceanbase的核心開發人員的新作《大規模分布式儲存系統：原理解析與架構實戰》.看完樣章後決定入手，果然物有所值。談儲存。那麼理解儲存的介質的特性顯然非常重要。書中談了非常多硬體結構，但最重要的結論，都濃縮在儲存介質對照這張表中了。對於準備學習分布式的同學，這是一本不錯的書籍，相對系統，全面的介紹了分布式的相關技術和專案，基本都是乾貨。
另一半是在介紹oceanbase的內容，對我來說，正是踏破鐵鞋無覓處。接下來會有幾篇專門研究儲存引擎的讀書筆記喲。廢話不多說，轉入正題。
磁碟介質對照
類別每秒讀寫(iops)次數
每gb**(元)
隨機讀取
隨機寫入
記憶體千萬級
150友好
友好ssd盤
35000
20友好
寫入放大問題
sas磁碟
1803
磁碟尋道
磁碟尋道
sata磁碟
900.5
磁碟尋道
磁碟尋道
從表中能夠看出，記憶體的隨機讀寫能力最強，遠超ssd盤和磁碟。可是我們都知道。記憶體無法持久化。如今很多公司在效能要求高的地方都使用了ssd盤。相對sas和sata磁碟，隨機讀取速度有了非常大的提公升。
可是對於隨機寫入，存在寫入放大問題。
寫入放大問題與ssd盤的特性有關，ssd盤不能隨機寫入，僅僅能整塊整塊的寫入。最簡單的樣例，比方要寫入乙個4kb的資料。最壞的情況就是，乙個塊裡已經沒有乾淨空間了，可是有無效資料能夠擦除，所以主控就把全部的資料讀出來。擦除塊，再加上這個4kb新資料寫回去，這個操作帶來的寫入放大就是: 實際寫4k的資料，造成了整個塊（512kb）的寫入操作，那就是128倍放大。此外，ssd盤的壽命也有寫入次數相關。假設使用ssd來作為儲存引擎的儲存介質。最好從設計上降低或避免隨機寫入，使用順序寫入取而代之。
儲存系統的基本功能包含：增、刪、讀、改。當中讀取操作有分為順序讀取和隨機讀取。整體來說，大部分應用使用讀的功能最多，解決讀的效能是儲存系統的重要命題。一般來說。高速查詢的思想基本源自二分查詢法和雜湊查詢。
比如關聯式資料庫中經常使用的b+儲存模型就是使用二分查詢的思想，當然，實際實現比二分查詢複雜非常多。b+儲存模型支援順序掃瞄。另外一類則是基於雜湊思想的鍵值模型，這類模型不支援順序掃瞄，僅支援隨機讀取。
今天要討論的bitcask模型是一種日誌型鍵值模型。
所謂日誌型，是指它不直接支援隨機寫入。而是像日誌一樣支援追加操作。
bitcask模型將隨機寫入轉化為順序寫入。有兩個優點：
bitcask中存在3種檔案，包括資料檔案,索引檔案和線索檔案(hint file,姑且就叫線索檔案吧)。資料檔案儲存於磁碟上，包括了原始的資料的鍵值資訊；索引檔案存在於記憶體，用於記錄記錄的位置資訊，啟動bitcask時。它會將所有資料的位置資訊所有讀入乙個記憶體中的雜湊表，也就是索引檔案；線索檔案(hint file)並非bitcask的必需檔案，它的存在是為了提供啟動時構建索引檔案的速度。
bitcask的資料檔案組織例如以下圖：隨意時刻。系統中僅僅有乙個資料檔案支援寫入。稱為active data file。其餘的資料檔案都是僅僅讀檔案，稱為older data file。
檔案裡的資料結構很easy，是一條一條的資料寫入操作。每一條資料的結構例如以下：
上面資料項分別為：後面幾項的crc校驗值,時間戳,key，value，key的大小。value的大小。
資料檔案裡就是連續一條條上面格式的資料，例如以下圖：
索引雜湊表記錄了所有記錄的主鍵和位置資訊，索引雜湊表的值包括了：記錄檔案的編號,value長度,value的在檔案裡的位置和時間戳。bitcask的整體資料結構例如以下圖：
bitcask啟動時要重建索引雜湊表。假設資料量特別大。則會導致啟動非常慢。
而線索檔案(hint file)則是用來加速啟動時重建雜湊表的速度。線索檔案(hint file)的記錄與資料檔案的格式基本同樣，唯一不同的是資料檔案記錄資料的值。而線索檔案(hint file)則是記錄資料的位置。
這樣在啟動的時候就能夠不用讀資料檔案，而是讀取線索檔案(hint file)。一行行重建就可以，大大加快了雜湊表的重建速度。
上節提到，儲存系統的基本功能包含：增、刪、讀、改。
那麼bitcask中怎樣實現的呢？
怎樣新增記錄？
使用者寫入的記錄直接追加到活動檔案，因此活動檔案會越來越大。當到達一定大小時。bitcask會凍結活動檔案。新建乙個活動檔案用於寫入，而之前的活動檔案則變為了older data file。
寫入記錄的同一時候還要在索引雜湊表中加入索引記錄。
怎樣刪除記錄？
bitcask不直接刪除記錄。而是新增一條同樣key的記錄，把value值設定乙個刪除的標記。原有記錄依舊存在於資料檔案裡。然後更新索引雜湊表。
怎樣改動記錄？
bitcask不支援隨機寫入。
由於對於儲存系統的基本功能中的增和改。實際上都是一樣的。都是直接寫入活動資料檔案。同一時候改動索引雜湊表中相應記錄的值。
(這個時候。實際上資料檔案裡同乙個key值相應了多條記錄，依據時間戳記錄來推斷，以最新的資料為準。
怎樣讀取記錄?
讀取時，首先從索引雜湊表中定位到記錄在磁碟中位置，然後通過io讀取出相應的記錄。
合併(marge)操作
bitcask這樣的僅僅增不減地不斷寫入，必定會是資料檔案不斷的膨脹。而當中有很多是被標記刪除和改動後留下的無用記錄。合併操作就是為了剔除這部分資料，減小資料檔案大小。
merge操作。通過定期將全部older data file中的資料掃瞄一遍並生成新的data file（沒有包含active data file 是由於它還在不停寫入）。假設同乙個key有多條記錄。則僅僅保留最新的一條。
從而去掉資料檔案裡的冗餘資料。並且進行合併(marge)操作時，還能夠順帶生成線索檔案(hint file)。合併(marge)操作一般會在資料庫較閒的時候進行。比方凌晨一兩點等。
bitcask是乙個精煉的鍵值儲存模型。採用日誌型的資料結構。僅僅追加不改寫就記錄，提高了隨機寫入的吞吐量，通過建立雜湊表來加快查詢速度，定期合併資料檔案。並生成線索檔案(hint file)，提高啟動時重建雜湊表的速度。
除了增刪讀寫外,主要還實現了：
參考：bitcask
優雅的bitcask
Bitcask 儲存模型
bitcask 是乙個日誌型 基於hash表結構的key value儲存模型，以bitcask為儲存模型的k v系統有 riak 和 beansdb 新版本。檔案中的資料結構非常簡單，是一條一條的資料寫入操作，每一條資料的結構如下 上面資料項分別為key，value，key的大小，value的大小，...
mysql資料儲存模型 資料儲存模型
rdbms nosql hadoop hbase hbase以big table為藍本，以鍵值對儲存，實現快速在主機內億級記錄中定位到所需的資料並訪問它。hbase彌補了hadoop無法隨即讀寫的缺陷，如果需要實時的訪問資料，就把資料存入hbase。hbase常應用於建立網際網路索引 推薦系統後台 ...
資料儲存模型
在網際網路行業，通常需要高併發 高效能 高可用性的資料庫系統。在處理大資料時，關係型資料庫遭遇了瓶頸，這就促使我們思考從資料模型的根源入手，來解決效能上的問題。根據資料的儲存模型和特點，nosql資料庫分為很多種類，主要分為以下四個型別 鍵值模型 列式模型 文件模型與圖形模型。鍵值模型 例項 dyn...