翻譯

論文來源：bitcask-intro.pdf (riak.com)

背景介紹

Bitcask的起源與Riak分布式數(shù)據(jù)庫的歷史緊密相連。在Riak的K/V集群中，每個節(jié)點都使用了可插拔的本地存儲；幾乎任何結(jié)構(gòu)的K/V存儲都可以用作每個主機的存儲引擎。這種可插拔性使得Riak的處理能夠并行化，從而可以在不影響代碼庫其他部分的情況下改進和測試存儲引擎。

有很多類似的本地K/V存儲系統(tǒng)，包括但不限于Berkeley DB、Tokyo Cabinet和Innostore。在評估此類存儲引擎時，我們想實現(xiàn)的目標(biāo)包括：

• 讀取或?qū)懭朊總€項目的低延遲
• 高吞吐量，尤其是在寫入隨機項目的傳入流時
• 處理比RAM大得多的數(shù)據(jù)集的能力，無退化
• 故障友好性，在快速恢復(fù)和不丟失數(shù)據(jù)方面都很好
• 易于備份和恢復(fù)
• 相對簡單、可理解（因而可支持）的代碼結(jié)構(gòu)和數(shù)據(jù)格式
• 訪問負(fù)載大或容量大時的可預(yù)測行為
• 允許在Riak中輕松默認(rèn)使用的許可證

實現(xiàn)其中一些目標(biāo)并不困難，但是想實現(xiàn)所有目標(biāo)就不那么容易了。

現(xiàn)有的本地K/V存儲系統(tǒng)（包括但不限于作者編寫的系統(tǒng)）均未達(dá)到上述所有目標(biāo)。當(dāng)我們在與Eric Brewer討論這個問題時，他關(guān)于哈希表日志合并的關(guān)鍵見解是：這樣做可能會比LSM樹更快或更快。

這導(dǎo)致我們以新的視角探索了20世紀(jì)80年代和90年代首次開發(fā)的日志結(jié)構(gòu)化文件系統(tǒng)所使用的一些技術(shù)。這次探索導(dǎo)致了Bitcask的誕生，它是一個能夠完全實現(xiàn)上述所有目標(biāo)的存儲系統(tǒng)。雖然Bitcask最初是為了給Riak使用而誕生，但是它的設(shè)計很通用，因此也可以作為其他應(yīng)用程序的本地K/V存儲。

模型描述

active data file

最終采用的模型在概念上非常簡單。Bitcask實例是一個目錄，我們強制規(guī)定在給定時間內(nèi)，只有一個操作系統(tǒng)進程可以打開該Bitcask進行寫入。您可以將該進程有效地視為“數(shù)據(jù)庫服務(wù)器”。在任何時候，該目錄中都有一個文件由服務(wù)器進行寫入操作。當(dāng)該文件達(dá)到一定大小時，它將被關(guān)閉，并創(chuàng)建一個新的活動文件。[font color="#FFA500"]一旦文件被關(guān)閉，無論是出于有意還是由于服務(wù)器退出，它都被視為不可變的，并且永遠(yuǎn)不會被再次打開進行寫入。[/font]

活動文件，也就是上文提到的active data file，只能以追加的方式寫入，這意味著順序?qū)懭氲耐瑫r不需要磁盤尋址。
文件中的每個鍵值對entry的格式如下：

每次寫入時，都只是向active data file追加一個新的entry。刪除操作只是寫入一個特殊的墓碑值（可以理解為是一個特殊標(biāo)記），它將在下一次合并時被刪除。因此，Bitcask數(shù)據(jù)文件無非是這些entry的線性序列：

keydir

在active data file中完成追加操作后，接著去內(nèi)存中更新一個名為keydir的數(shù)據(jù)結(jié)構(gòu)。keydir是一個哈希表（在本論文中它是一個哈希表，也可以是其他數(shù)據(jù)結(jié)構(gòu)），它將Bitcask中的每個key映射到一個固定大小的結(jié)構(gòu)，這個結(jié)構(gòu)記錄了這個key寫在哪個文件、該鍵在該文件中的偏移量以及大小。

一開始我覺得上面這張圖就是對bitcask中哈希表存儲內(nèi)容的正確理解，但是后來覺得下面這個圖才是，因為哈希表的value存儲的應(yīng)該是entry的信息，而不是entry中value的信息。原論文中的圖有比較大的迷惑性。

數(shù)據(jù)寫入與讀取

數(shù)據(jù)的寫入其實在上面兩節(jié)已經(jīng)介紹過了，為了方便理解記憶就再總結(jié)一下。
寫入很簡單，就是往bitcask中追加一條entry，然后更新keydir（原子操作），將剛剛新增的entry的信息存儲起來，就像下面這樣：

數(shù)據(jù)的讀取流程則是先拿著key去keydir中取出相應(yīng)的entry信息，然后根據(jù)entry中提供的信息去data file中取出key對應(yīng)的value，就像下面這樣：

數(shù)據(jù)合并

因為bitcask刪除的數(shù)據(jù)的方式是通過追加一條相同key的entry實現(xiàn)的，所以文件的size會越來越大，就需要定期的合并文件，合并的過程是這樣的：

1. 先遍歷所有的old data file，將所有的有效數(shù)據(jù)進行合并，如果有多個entry含有相同的key，則只保留最新的entry，有點像Redis中的AOF，
2. 合并完成后，old data file會變成merge data file，且數(shù)量也會減少，例如10個old data file 合并成5個merge data file。
3. 因為bitcask是在內(nèi)存中構(gòu)建索引，也就是之前提到的keydir，構(gòu)建keydir需要在啟動的時候掃描所有的data file，如果數(shù)據(jù)量很大，那么構(gòu)建索引的過程就會很耗時，為了解決這個問題，bitcask在合并數(shù)據(jù)的時候還會為每個merge data file生成一個hint file，這個hint file中存儲的也是一堆entry，這些entry的格式和data file中的entry保持一致，唯一的區(qū)別就是data file中的entry存儲的value是真實數(shù)據(jù)，而hint file中entry的value存儲的是數(shù)據(jù)的位置。

結(jié)束

目前對bitcask的理解也就是這些了，肯定有不準(zhǔn)確的地方，想要徹底弄明白也只能自己手搓一個kv存儲才行。有任何問題都可以在評論區(qū)交流。

總結(jié)

以上是生活随笔為你收集整理的bitcask论文翻译/笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。