SVN的兩種儲存方式FSFS和BDB比較【轉】

標籤：blog   http   io   os   使用   ar   java   strong   檔案   

版本庫資料存放區

在Subversion1.2中，版本庫中儲存資料有兩種方式。一種是在Berkeley DB資料庫中儲存資料；另一種是使用普通的檔案，使用自訂格式。因為Subversion的開發人員稱版本庫為（版本化的）檔案系統，他們接受了稱後一種儲存方式為FSFS[14]的習慣，也就是說，使用本地作業系統檔案系統來儲存資料的版本化檔案的系統。

建 立一個版本庫時，管理員必須決定使用Berkeley DB還是FSFS。它們各有優缺點，我們將詳細描述。這兩個中並沒有一個是更正式的，訪問版本庫的程式與採用哪一種實現方式無關。訪問程式並不知道版本庫 如何儲存資料，它們只是從版本庫的API讀取到修訂版本和事務樹。

表 5.1 “版本庫資料存放區對照表”從總體上比較了Berkeley DB和FSFS版本庫，下一部分將會詳細講述細節。

表 5.1. 版本庫資料存放區對照表

特性	Berkeley DB	FSFS
對操作中斷的敏感	很敏感；系統崩潰或者許可權問題會導致資料庫“塞住”，需要定期進行恢複。	不敏感。
可唯讀載入	不能	可以
儲存平台無關	不能	可以
可從網路檔案系統訪問	不能	可以
版本庫大小	稍大	稍小
可擴充性：修訂版本樹的數量	資料庫，沒有限制	許多古老的本地檔案系統在處理單一目錄包含上千個條目時出現問題。
可擴充性：檔案較多的目錄	較慢	較快
速度：檢出最新的代碼	較快	較慢
速度： 大的提交	較慢，但是時間被分配在整個提交操作中	較快，但是最後較長的延時可能會導致用戶端操作逾時
組訪問權處理	對於使用者的umask設定十分敏感，最好只由一個使用者訪問。	對umask設定不敏感
功能成熟時間	2001年開始使用	2004年開始使用

 

Berkeley DB

在Subversion的初始設計階段，開發人員因為多種原因而決定採用Berkeley DB，比如它的開源協議、事務支援、可靠性、效能、簡單的API、安全執行緒、支援遊標等。

Berkeley DB提供了真正的事務支援－這或許是它最強大的特性，訪問你的Subversion版本庫的多個進程不必擔心偶爾會破壞其他進程的資料。事務系統提供的隔 離對於任何給定的操作，Subversion版本庫代碼看到的只是資料庫的靜態視圖－而不是一個在其他進程影響不斷變化的資料庫－並能夠根據該視圖作出決 定。如果該決定正好同其他進程所做操作衝突，整個操作會復原，就像什麼都沒有發生一樣，並且Subversion會優雅的再次對更新的靜態視圖進行操作。

Berkeley DB另一個強大的特性是熱備份－不必“離線”就可以備份資料庫環境的能力。我們將會在“版本庫備份”一節討論如何備份你的版本庫，能夠不停止系統對版本庫做全面備份的好處是顯而易見的。

Berkeley DB同時是一個可信賴的資料庫系統。Subversion利用了Berkeley DB可以記日誌的便利，這意味著資料庫先在磁碟上寫一個記錄檔，描述它將要做的修改，然後再做這些修改。這是為了確保如果如果任何地方出了差錯，資料庫 系統能恢複到先前的檢查點—一個記錄檔認為沒有錯誤的位置，重新開始事務直到資料恢複為一個可用的狀態。關於Berkeley DB記錄檔的更多資訊請查看“管理磁碟空間”一節。

但 是每朵玫瑰都有刺，我們也必須記錄一些Berkeley DB已知的缺陷。首先，Berkeley DB環境不是跨平台的。你不能簡單的拷貝一個在Unix上建立的Subversion版本庫到一個Windows系統並期望它能夠正常工作。儘管 Berkeley DB資料庫的大部分格式是不受架構約束的，但環境還是有一些方面沒有獨立出來。其次，使用Berkeley DB的Subversion不能在95/98系統上運行—如果你需要將版本庫建在一個Windows機器上，請裝到Windows2000或 WindowsXP上。另外，Berkeley DB版本庫不能放在網際網路共用檔案夾中，儘管Berkeley DB承諾如果按照一套特定規範的話，可以在網際網路共用上正常運行，但實際上已知的共用類型幾乎都不滿足這套規範。

最後，因為Berkeley DB的庫直接連結到了Subversion中，它對於中斷比典型的關係型資料庫系統更為敏感。大多數SQL系統，舉例來說，有一個主服務進程來協調對資料 庫表的訪問。如果一個訪問資料庫的程式因為某種原因出現問題，資料庫守護進程察覺到串連中斷會做一些清理。因為資料庫守護進程是唯一訪問資料庫表的進程， 應用程式不需要擔心訪問許可的衝突。但是，這些情況與Berkeley DB不同。Subversion（和使用Subversion庫的程式）直接存取資料庫的表，這意味著如果有一個程式崩潰，就會使資料庫處於一個暫時的不 一致、不可訪問的狀態。當這種情況發生時，管理員需要讓Berkeley DB恢複到一個檢查點，這的確有點討厭。除了崩潰的進程，還有一些情況能讓版本庫出現異常，比如程式在資料庫檔案的所有權或存取權限上發生衝突。因為 Berkeley DB版本庫非常快，並且可以擴充，非常適合使用一個單獨的服務進程，通過一個使用者來訪問—比如Apache的httpd或svnserve（參見第 6 章 設定管理員）—而不是多使用者通過file:///或svn+ssh://URL的方式多使用者訪問。如果將Berkeley DB版本庫直接用作多使用者訪問，請先閱讀“支援多種版本庫存取方法”一節。

FSFS

在 2004年中期，另一種版本庫儲存系統慢慢形成了：一種不需要資料庫的儲存系統。FSFS版本庫在單一檔案中儲存修訂版本樹，所以版本庫中所有的修訂版本 都在一個子檔案夾中有限的幾個檔案裡。事務在單獨的子目錄中被建立，建立完成後，一個單獨的事務檔案被建立並移動到修訂版本目錄，這保證提交是原子性的。 因為一個修訂版本檔案是持久不可改變的，版本庫也可以做到熱備份，就象Berkeley DB版本庫一樣。

修訂版本檔案格式代表了一個修訂 版本的目錄結構，檔案內容，和其它修訂版本樹中相關資訊。不像Berkeley DB資料庫，這種儲存格式可跨平台並且與CPU架構無關。因為沒有日誌或用到共用記憶體的檔案，資料庫能被網路檔案系統安全的訪問和在唯讀環境下檢查。缺少 資料庫花消同時也意味著版本庫的總體體積可以稍小一點。

FSFS也有一種不同的效能特性。當提交大量檔案時，FSFS使用O(N)演算法來追 加條目，而Berkeley DB則用(N^2)演算法來重寫整個目錄。另一方面，FSFS通過寫入與上一個版本比較的變化來記錄新版本，這也意味著擷取最新修訂版本時會比 Berkeley DB慢一點，提交時FSFS也會有一個更長的延遲，在某些極端情況下會導致客護端在等待回應時逾時。

最重要的區別是當出現錯誤時FSFS不會楔住的能力。如果使用Berkeley DB的進程發生許可錯誤或突然崩潰，資料庫會一直無法使用，直到管理員恢複。假如在應用FSFS版本庫時發生同樣的情況，版本庫不會受到任何幹擾，最壞情況下也就是會留下一些交易資料。

唯一真正對FSFS不利的是相對於Berkeley DB的不成熟，缺乏足夠的使用和壓力測試，許多關於速度和可擴充性的判斷都是建立在良好的猜測之上。在理論上，它承諾會降低管理員新手的門檻並且更加不容易發生問題。在實踐中，只有時間可以證明。

轉自：http://www.blogjava.net/jasmine214--love/archive/2011/01/18/343160.html

SVN的兩種儲存方式FSFS和BDB比較【轉】