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

Question

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

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

是这样吗？还是这些程序只是简单地将大量数据读入内存，压缩它，写入它，然后再做一遍？还是在这些“流压缩器”中使用了任何巧妙的技巧？我看到bzip2和xz的手册页都讨论了内存使用情况，并且man bzip2还暗示了将要压缩的数据切成块的损失很少：

较大的区块大小会导致边际收益迅速递减。大多数压缩来自前两三百 k 的块大小，在小型机器上使用 bzip2 时需要牢记这一点。同样重要的是要理解解压缩内存要求是通过选择块大小在压缩时设置的。

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

Answer 1

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

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

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

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