二进制增量存储技术

Question

我正在寻找一种二进制增量存储解决方案，用于版本控制大型二进制文件（数字音频工作站文件）。

在处理DAW文件时，大部分更改，特别是在混音接近尾声时，与用于存储原始数据（波形）的大量数据相比非常小。

拥有DAW文件的版本控制系统将非常有用，允许我们回滚到旧版本。

该系统仅保存每个版本的二进制文件之间的差异（diff）。这将为我们提供一系列指令，以从当前版本更改为上一个版本，而无需为每个单独版本存储完整文件。

是否有任何当前版本控制系统可以做到这一点？我已经阅读过SVN使用二进制diff来节省存储库空间的信息...但我也读到它实际上并没有为二进制文件而只是为文本文件做到了这一点...不确定。有什么想法吗？

我现在的行动计划是继续研究现有工具，如果没有，就熟悉c/c++读取二进制数据并创建工具。

- Colton Phillips

---

请不要在我们的网站上重复同一个问题。谢谢。 - Kev

重复的问题是意外发生的，可能是由于一个错误。我试图只按一次添加问题按钮，但它给了我一个错误提示，说我需要等待20分钟才能提交。之后我再次提交，结果出现了两个问题，而不是一个... - Colton Phillips

Answer 1

我无法对在网络上提交大文件时可能存在的可靠性或连接问题发表评论（一篇引用帖子暗示存在问题）。但这里有一些您可能会发现有用（或不重要）的经验数据。

我今天进行了一些测试，研究了磁盘查找时间，并且有一个相当好的测试案例。我觉得你的问题很有趣，所以我用我正在使用/修改的文件做了一个快速测试。我创建了一个本地Subversion存储库，并向其中添加了两个二进制文件（下面显示大小），然后在对它们进行更改后多次提交了这些文件。较小的二进制文件（.85GB）每次只是在其末尾添加了数据。较大的文件（2.2GB）包含代表“随机”整数数据的b树数据。在提交之间对该文件的更新涉及添加约4000个新的随机值，因此会将修改的节点分散在整个文件中。

以下是原始文件大小以及提交后本地Subversion存储库中所有文件的大小/数量：

file1    851,271,675  
file2  2,205,798,400 

1,892,512,437 bytes in 32 files and 32 dirs

在第二次提交后：

file1    851,287,155  
file2  2,207,569,920  

1,894,211,472 bytes in 34 files and 32 dirs

第三次提交后：

file1    851,308,845  
file2  2,210,174,976  

1,897,510,389 bytes in 36 files and 32 dirs

这些提交有点长。我没有仔细关注，因为我还在做其他工作，但我认为每个提交可能需要大约10分钟的时间。检查特定版本需要大约5分钟的时间。根据我的结果，我无法做出任何建议。我只能说它似乎运行良好，没有发生错误。文件差异比较功能也很好用（对于这些文件而言）。

- Mark Wilkins

---

@Colton：出于好奇，我使用了默认设置的7-Zip（文件压缩实用程序），压缩了这两个文件。结果是一个1.88GB的文件。因此，在这种情况下Subversion使用的压缩也是正确的。它们可能都使用了ZLib。 - Mark Wilkins

我正在使用Reason作为数字音频工作站。请随时告诉我你在做什么以及它的效果如何 :) - Colton Phillips

我猜实际的差异只有几兆字节，花费了大部分10分钟提交时间可能是在进行二进制差异处理。 - Colton Phillips

你认为解压缩和压缩阶段大约需要多长时间？在我看来，我自己实现的二进制增量存储版本控制系统与svn相比唯一的优势就是它不会执行这两个阶段，此外，我的工具可能是单一用途且稍微快一些，因为它比svn更不灵活。现在的问题是，即使那段时间很重要，编写该应用程序是否值得...可能不值得... - Colton Phillips

需要注意的一件事是 - 根据您的二进制数据是什么，Subversion 在创建增量时可能会变得非常糟糕。 我对此进行了调查，详见这个问题。 看起来需要知道的一个关键点是跳过增量的内容，这意味着每个增量不一定针对文件的前一个版本进行计算。 - Jon Stafford

Answer 2

视你对“大”一词的定义而定，Subversion 可能适用。根据这个问题/答案，只要文件大小不超过 1 GB，它就可以很好地工作。

- Shane Wealti

Answer 3

Subversion可以对二进制文件和文本文件执行二进制增量。 但是，Subversion无法为二进制文件提供可读的增量，并且无法帮助合并二进制文件中的冲突。

- bdonlan

---

我不小心发布了两次这个帖子...但是在我的另一个帖子上，有人说：Subversion可能有效，具体取决于您对“大型”的定义。这个问题/答案说，只要您的文件小于1 GB，它就可以很好地工作。这是一个问题，因为几乎所有的DAW文件都会大于1 GB。 - Colton Phillips

Answer 4

Git 压缩（虽然您可能需要手动调用 git gc），看起来真的很好：

$ git init
$ dd if=/dev/urandom of=largefile bs=1M count=100
$ git add largefile
$ git commit -m 'first commit'
[master (root-commit) e474841] first commit
 1 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 largefile
$ du -sh .
201M    .
$ for i in $(seq 20); do date >> largefile; git commit -m "$i" -a; git gc; done
$ du -sh .
201M    .

- phihag

---

如果您在32位操作系统上使用git，这可能会失败。 - yarun can

@yaruncan，您能详细说明为什么您认为它会失败，以及为什么操作系统的位数应该成为问题中的关键因素吗？在32位系统上，我得到了完全相同的输出结果。 - phihag

当你需要大量内存进行这些操作时，phihag，64位与32位操作系统的区别很重要。我主要是在谈论通过git repack和git gc等方式进行的git压缩。事实上，这些操作在我的32位Linux上总是失败，所以我不得不在另一台64位操作系统的电脑上进行这些操作。 - yarun can

@yaruncan 我不同意，这与操作系统的“片段性”无关。你说的是进程可用地址空间，那是另外一回事。如果你的代码仓库确实很大，某些操作可能会出现问题。但要注意，即使在32位操作系统和少于1 GiB RAM的条件下，处理200MB文件的例子也可以正常工作。此外，更新版本的git已经对repack和gc进行了优化。 - phihag

无论我使用什么打包限制，git 的打包和压缩经常会失败。我只是在警告发帖者存在的危险。 - yarun can