SVN 兩種存儲格式（BDB和FSFS）區別

版本庫數據存儲

在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的不成熟，缺少足夠的使用和壓力測試，許多關於速度和可擴展性的判斷都是創建在良好的猜想之上。在理論上，它承諾會下降管理員新手的門檻而且更加不容易發生問題。在實踐中，只有時間能夠證實。