Question

我一直在考虑数据冗余，并且只是想在我继续这个之前把所有东西都写出去（并且还要仔细检查这个想法是否已经付诸实践）。 / p>

好的，所以这里。

互联网充满了冗余数据，包括文本，图像，视频等。因此，gzip和bzip2通过HTTP进行动态压缩和解压缩已经付出了很多努力。像谷歌和Facebook这样的大型网站都有整个团队，他们花时间让他们的网页加载速度更快。

我的“问题”涉及压缩仅在每个文件的基础上完成（gzip file.txt产生file.txt.gz）。毫无疑问，在互联网上分散的看似无关的数据之间存在许多共性。如果您可以存储这些公共块并将它们（客户端或服务器端）组合在一起以动态生成内容，该怎么办？

为了能够做到这一点，人们必须在互联网上找到最常见的“数据块”。这些块可以是任何大小（这里可能是最佳选择），并且，组合起来，需要能够表达任何可以想象的数据。

为了便于说明，我们假设我们有以下5个常见数据块a, b, c, d, and e。我们有两个仅包含这些块的文件。我们有一个名为chunk和combine的程序。 chunk获取数据，通过bzip2，gzip或其他压缩算法压缩数据，并输出包含所述数据的块（压缩后）。 combine扩展块并解压缩连接结果。以下是它们的使用方法：

$ cat gettysburg.txt
"Four score and seven years ago...cont'd"
$ cat test.txt
"This is a test"
$ chunk gettysburg.txt test.txt
$ cat gettysburg.txt.ck
abdbdeabcbdbe
$ cat test.txt.ck
abdeacccde
$ combine gettysburg.txt.ck test.txt.ck
$ cat gettysburg.txt
"Four score and seven years ago...cont'd"
$ cat test.txt
"This is a test"

例如，当通过HTTP发送文件时，服务器可以chunk数据并将其发送给客户端，然后客户端可以combine分块数据并进行渲染。

以前有人试过这个吗？如果不是，我想知道为什么，如果是，请发布你如何做这项工作。一个很好的第一步是详细说明如何弄清楚这些块是什么。一旦我们弄清楚如何获取块，那么我们就会弄清楚这两个程序chunk和combine是如何工作的。

我可能会对此表示赏心悦球（取决于招待会），因为我认为这是一个非常有趣的问题，具有现实意义。

Answer 1

你问过某人之前是否做过类似的事情以及块大小应该是什么，我想我会指出你想到的两篇论文：

（Google团队）Google正试图通过利用文档之间共享的数据来加速Web请求。服务器将预先计算的字典传送给客户端，该客户端包含文档之间通用的数据，并在以后的请求中引用。这仅适用于一次一个域，而且 - 目前 - 仅适用于Google Chrome：Shared Dictionary Compression Over HTTP
（一个团队）微软在他们的工作Optimizing File Replication over Limited-Bandwidth Networks using Remote Differential Compression中确定，对于他们的文件系统同步情况，大约2KiB的块大小效果很好。它们使用一定程度的间接，因此重新创建文件所需的块列表本身就会分成块 - 这篇论文很有吸引力，可能会给你关于如何完成工作的新想法。
< / LI>

不确定它是否对您有所帮助，但在这种情况下确实如此。： - ）

Answer 2

你真的不必为最常见的块分析它 - 事实上，这样的分布式决策可能真的很难。怎么样这样：

我们来看一下HTTP数据传输的情况。将每个文件块化为10MiB块（或者你关心的任何大小，我确定每种方式都有性能影响）并计算它们的SHA-256（或者你相当确定应该对冲突安全的一些哈希）

例如，文件F1包含块B1..Bn和校验和C1..Cn。现在，HTTP服务器可以使用列表C1..Cn

响应对文件F1的请求

为了使这个实际有用，客户端必须保留已知块的注册表 - 如果校验和已经存在，只需在本地获取块。完成。如果它不知道，要么从本地缓存中获取它，要么只从远程HTTP服务器获取块，你刚从校验和列表中获取。

如果您从任何服务器（甚至是完全不同的服务器）下载了另一个文件（恰好共享一个块），您已经下载了它，并且它与您选择的哈希算法一样安全。

现在这并没有解决存在偏移的情况（例如，一个文件是

AAAAAAAA

和另一个

BAAAAAAAA

压缩算法可能会处理。但也许如果你自己压缩块，你会发现你得到了大部分的节省......

思想？

Answer 3

有一种更简单的方法来处理文本数据。目前，我们将文本存储为代表声音的字母流。但是，语言单位不是单词。因此，如果我们有一个包含所有单词的字典，然后将“指针”存储到文件中的这些单词中，我们可以通过使用指针并查找单词列表来动态地重新构建文本。

这应该可以立即减少3或4倍的尺寸。在这种方法中，单词与您想到的单词相同。下一步是常见的词组，如“这是”，“我是”，“满月”，“认真的老兄”，“哦，宝贝”等。

单词列表也有助于拼写检查，应由操作系统实现。有没有理由为什么拼写检查器不属于操作系统？

Answer 4

与您的答案不完全相关，但您已经看到了这一点。 Microsoft（和其他人）已经提供了边缘网络来托管jquery库。您可以引用这些相同的URI，并获得用户从其他站点访问该文件并将其浏览器缓存的好处。

但是，你指的是过去20分钟内其他人提到的内容（任意数字）。你可能会看到很多员工分享应用程序的大公司会受益，但我认为你很难确定你想要的块，这将超过共享它的任何好处。

分布式文件压缩

4 个答案: