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的不成熟，缺少足够的使用和压力测试，许多关于速度和可扩展性的判断都是创建在良好的猜想之上。在理论上，它承诺会下降管理员新手的门槛而且更加不容易发生问题。在实践中，只有时间能够证实。