在将它们放入redis之前压缩字符串 - 这有意义吗？

Question

更详细一点：我们已经尝试充分利用zipmaps，ziplists等，我想知道这些表示是否已经压缩，或者只是序列化的哈希和列表;压缩会显着减少内存使用量吗？

此外，应用服务器层的压缩开销会因网络使用率降低而抵消吗？ StackOverflow's experience表明它有什么意见吗？

简而言之，对于短弦和长弦都有意义吗？

Answer 1

Redis不会压缩您的值，如果您应该自己压缩它们，则很大程度上取决于您要存储的字符串的大小。对于大字符串，数百K以及更多它可能值得客户端额外的CPU周期，就像您在提供网页时一样，但对于较短的字符串，这可能是浪费时间。短弦通常不会压缩太多，因此增益太小。

Answer 2

有一种实用的方法可以获得良好的压缩，即使是非常小的字符串（50字节！） -

如果您的值彼此有些相似 - 例如，它们是几个相关对象类的JSON表示 - 您可以根据一些示例文本预先计算压缩器/解压缩器字典。

这听起来很复杂，但在实践中很简单 - 并且使用正确的包装器代码来处理它也更简单。

这是一个Python实现：

https://github.com/internetarchive/openlibrary/blob/master/openlibrary/utils/compress.py

这里是压缩特定字符串类的包装器:(简短的JSON记录）

https://github.com/internetarchive/openlibrary/blob/master/openlibrary/utils/olcompress.py

一个问题：为了有效地执行此操作，您的压缩库必须支持“克隆”内部状态。 （Python库可以）你可以通过在压缩时添加示例文本来实现类似的东西，但这意味着需要额外的计算成本。

感谢这个令人敬畏的绝招。

Answer 3

Redis和客户端通常是IO绑定的，并且IO成本通常相对于请求/回复序列的其余部分至少为2个数量级。较小的有效负载将为您提供更高的吞吐量和更低的延迟。

我认为除了cost of compression << IO gains之外还有任何严格的规则。您应该在设置下限时找到它并找到汗点，但是网络的MTU并不是下限的起点。