分布式文件压缩

我一直在想一些关于数据冗余的问题，只是想在写完之前把所有东西都写出来（并且仔细检查这个想法是否已经付诸实践）。分布式文件压缩

好的，所以在这里。

互联网充满了冗余数据，包括文本，图像，视频等。因此，通过HTTP进行gzip和bzip2即时压缩和解压缩的努力已经很多。像谷歌和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。

我可能会为此付出代价（取决于接待），因为我认为这是一个非常有趣的现实世界问题。

来源

2009-12-27 Dan Loewenherz

能否详细说明块和联合功能到底是做什么的？ – Vitaliy 2009-12-27 21:47:54

刚刚添加了几句话，说明他们在做什么。 – 2009-12-27 21:54:54

你问，如果有人做了以前类似的东西，什么块大小应该是的，我想我会点你到来到我的脑海两篇论文：

（A团队） Google正试图通过利用文档间共享的数据来加速网络请求。服务器将预先计算的字典传送给客户端，该客户端包含文档间通用的数据，并在稍后的请求中引用。这仅适用于单个域的时间，和 - 目前 - 只有谷歌浏览器：Shared Dictionary Compression Over HTTP
（A团队），微软在他们的工作Optimizing File Replication over Limited-Bandwidth Networks using Remote Differential Compression确定为自己的文件系统同步的块大小的情况下，大约2KiB运作良好。它们使用间接级别，以便重新创建文件所需的区块列表本身被分割成多个区块 - 这篇论文很吸引人，可能会为您提供有关如何完成任务的新想法。

不知道它是否对您有帮助，但在这里是为了防止它。 :-)

来源

2009-12-27 22:16:31 DataWraith

你不必为最常见的块进行分析 - 事实上，这样的分布式决策确实很难。这是怎么回事：

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

例如，您具有文件F1，其中块B1..Bn和校验和C1..Cn。现在，HTTP服务器可以仅仅使用列表C1来响应对文件F1的请求。CN

为了使这个真正有用的，客户必须保持阻止已知的注册表 - 如果校验已经存在，只是在本地获取该块。完成。如果它不知道，可以从本地缓存中抓取它，或者从刚获得校验和列表的远程HTTP服务器获取块。

如果你下载的这恰好共享一个块中的任何服务器（甚至是完全不同的一个）另一个文件，你已经拥有它下载，那么当你选择了哈希算法的安全性。

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

AAAAAAAA

和其他

BAAAAAAAA

其压缩算法大概可以应付，但是也许如果你压缩块本身，你会发现，无论如何你得到了大部分的储蓄...

想法？

来源

2009-12-27 21:34:09

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

但是，您指的是过去20分钟内有人提及过多少内容（任意数量）？您可能会看到一个大公司中的一些好处，那里有很多员工共享一个应用程序，但否则我认为您会遇到困难确定您想要的组块，并且这会超过分享它的任何好处。

来源

2009-12-27 22:55:29

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

这应该将事物的大小减少3或4倍。在这种方法中，单词与您所想的块相同。下一步是诸如“这就是”，“我是”，“满月”，“严肃的家伙”，“哦宝贝”等常用词组。

单词列表还有助于拼写检查，应该是由操作系统实施。拼写检查程序不是操作系统的一部分，是否有任何理由？

来源

2009-12-27 22:57:04

分布式文件压缩

回答

相关问题