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

Question

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

此外,应用服务器层的压缩开销是否会因网络使用率降低而抵消？StackOverflow的经验表明它有什么意义吗？

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

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库可以)你可以通过在压缩时添加示例文本来实现类似的东西,但这意味着需要额外的计算成本.

感谢solrize这个很棒的技巧.

Answer 3

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

我不相信除了以下内容之外还有任何硬性规定：cost of compression << IO gains。您应该对其进行测试并找到设置下限的难点，但网络的MTU对于下限来说并不是一个糟糕的起点。