database - 为什么 git 和 mercurial 不使用数据库？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便 editing this post 提供事实和引用来回答它.

7年前关闭。




Improve this question




我找到了 mail Linux Torvalds 说:

...go play with Monotone. Really. They use a "real database".

并开始感兴趣——为什么流行的 VCS 不使用数据库，而是实现自己的数据存储模型来实现相同的目标——事务、持久性等？

Answer 1

因为数据库的存储和检索方法通常是为与 VCS 系统相关的任务而设计的。使用一种特殊的方法来管理数据为实现提供了针对 VCS 系统的用例高度优化其代码的能力。虽然 DVCS 存储子系统的需求可能肯定会映射到“真实数据库”的关系模型，但为什么会这样呢？ DVCS 不需要正式的查询(甚至更不需要 SQL)，与其试图提示其数据库子系统如何加快速度，它可能只是实现最快和最安全的方式来访问它管理的数据。

请注意，Monotone's horrid speed 的挫败感这就是 Linus 开始编写 Git 的原因(在 BitMover 从 Linux 开发人员的脚下撤下地毯之后，他确实首先考虑了现有的 DVCS 解决方案)。另一个使用真实数据库的(不太明显的)系统，Fossil , doesn't have stellar performance (PDF)要么。

Git 最初是作为实现版本化文件系统的最小工具集，其作者(Linus Torvalds)最初设想成熟的 VCS 将是基于 Git 的工具。实际上，Git 本身开始快速积累功能，使其成为一个成熟的 VCS，因此虽然这些级别的某些分离仍然存在，但它们不是单独的项目。

关于 Git 的存储子系统的另外两个有趣的点:

最初它只是将其对象存储在单独的文件中。之后，它被教导透明地将最不常访问的对象的存储切换到所谓的“packfiles”，这是一种带有内置索引的压缩文件，用于快速遍历和访问。

关键是开发人员研究了现有解决方案的性能，并精心设计了一种最能解决手头问题的改进方案。

它在速度方面正在改进。例如，去年秋天已经讨论了另一堆加速 Git 索引(暂存区)的补丁。

关键是，这些改进不仅仅是为了它们而编码，而是基于研究现实世界高工作负载的性能。

Mercurial 在存储数据的方式上采用了与 Git 不同的方法，它使用一种特殊的存储格式，便于使用差异数据。

因此，使用“真实数据库”的工具似乎可以分为以下几类:

“理想设计”。这是单调和化石。

据推测，此类工具的创建者认为使用“真实数据库”为他们提供了免费使用数据库的所有好处(例如耐用性)。这些好处是非常真实的(使用 Sqlite 进行存储使备份变得轻而易举)。

虽然好处是真实的，但在其他 VCS 系统中实现自定义存储后端的代码确实提供了持久性。请注意，虽然“真正的数据库”采用巧妙的技巧来尝试确保它们存储的数据始终正确且一致，但不要做任何魔术:一切仍然归结为使用正确的文件操作顺序，fsync()等

“企业”的思维方式。这是Veracity例如，它至少声称在其商业插件中支持 RDBMS 后端。

企业通常已经投资了诸如 Oracle 或 SQL Server 之类的“大”数据库以及诸如“高调”解决方案之类的管理。使用这种系统的一个好处是它通常是专业管理的，提供细粒度的访问控制、备份等。

使用 RDBMS 的明显缺点是缺乏分布(“DVCS”中缺少“D”)以及失去设置的一般便利性。

从不同角度看待自定义存储格式的额外阅读:Keith Packard 关于为什么 repository formats matter 的想法和 a short comment on some of his points来自 Mercurial 的主要开发商。