stream - 压缩流的能力如何影响压缩算法？

Question

我最近备份了我即将过期的大学主目录，将它作为 tar 流发送并在我端压缩它:ssh user@host "tar cf - my_dir/" | bzip2 > uni_backup.tar.bz2 .

这让我想到:我只知道压缩工作原理的基础知识，但我想这种压缩数据流的能力会导致压缩效果较差，因为算法需要在某一时刻完成处理一个数据块，写这个到输出流并继续下一个块。

是这种情况吗？还是这些程序只是简单地将大量数据读入内存，然后压缩、写入，然后再做一遍？或者在这些“流压缩器”中使用了什么巧妙的技巧？我看到 bzip2 和 xz 的手册页都讨论了内存使用情况，并且 man bzip2 还暗示了这样一个事实，即将要压缩的数据切碎成块几乎没有损失:

Larger block sizes give rapidly diminishing marginal returns. Most of the compression comes from the first two or three hundred k of block size, a fact worth bearing in mind when using bzip2 on small machines. It is also important to appreciate that the decompression memory requirement is set at compression time by the choice of block size.

我仍然很想知道是否使用了其他技巧，或者我可以在哪里阅读更多相关信息。

Answer 1

这个问题更多地涉及缓冲区处理而不是压缩算法，尽管也可以说一下。

一些压缩算法本质上是“基于块的”，这意味着它们绝对需要处理特定大小的块。这就是bzip2的情况，选择哪个块大小得益于“级别”开关，从100kb到900kb。
因此，如果您将数据流式传输到其中，它将等待该块被填充，并在该块已满时开始压缩该块(或者，对于最后一个块，它将以接收到的任何大小工作)。

其他一些压缩算法可以处理流，这意味着它们可以使用保存在内存缓冲区中的旧数据连续压缩新数据。基于“滑动窗口”的算法可以做到这一点，通常 zlib 能够做到这一点。

现在，即使是“滑动窗口”压缩器也可以选择将输入数据切成块，以便更轻松地管理缓冲区，或者开发多线程功能，例如 pigz。