performance - 鉴于磁盘速度很慢，并且多核动态解压缩对性能有意义吗？

Question

过去，磁盘压缩用于以牺牲效率为代价增加存储空间，但当时我们都在单处理器系统上。

这些天来，周围有额外的内核可能会在处理数据的同时进行解压缩工作。

对于 I/O 密集型应用程序（尤其是读取大量顺序数据处理），可以通过仅将压缩数据读取和写入磁盘来提高吞吐量。

有没有人有经验支持或拒绝这个猜想？

Answer 1

注意不要混淆磁盘寻道时间和磁盘读取率。在硬盘驱动器 (HDD) 上寻找正确的轨道需要数百万个 CPU 周期（5–10 毫秒或 5–1000 万纳秒）。一旦你在那里，你可以每秒读取数十兆字节的数据，假设碎片很低。对于固态驱动器 (SSD)，寻道时间 (35,000–100,000ns) 低于 HDD。

不管数据是否压缩在磁盘上，你仍然需要寻找。问题变成了，是（压缩数据的磁盘读取时间+解压缩时间）<（未压缩数据的磁盘读取时间）。解压缩相对较快，因为它相当于用较长的令牌替换短令牌。最后，它可能归结为数据的压缩程度以及最初的大小。如果您正在阅读 2KB 的压缩文件而不是 5KB 的原始文件，那可能不值得。如果您正在阅读 2MB 的压缩文件而不是 25MB 的原始文件，则很可能是这样。

以合理的工作量进行测量。

Answer 2

是的！事实上，处理器的速度如此之快，以至于它甚至对内存都有意义。（IBM 这样做，我相信。）我相信，目前的一些大铁机器甚至对 CPU 缓存进行压缩。

Answer 3

是的，这完全有道理。在基于 NT 的 Windows 操作系统上，人们普遍认为，有时启用 NTFS 压缩比禁用它更快，正是出于这个原因。多年来一直如此，多核只会让它更加真实。

Answer 4

我认为这还取决于您的压缩程度与您的 IO 绑定程度。

例如，DB2 的行压缩特性针对 IO 绑定应用程序：数据仓库、报告系统等。它使用基于字典的算法并且不是很激进 - 导致 50-80% 的数据压缩（表、索引存储以及何时在内存中）。但是 - 它也倾向于将查询速度提高 10% 左右。

他们本可以进行更积极的压缩，但随后会受到性能影响。