在将字符串放入redis之前压缩字符串 - 是否有意义？

更详细一点：我们已经试图充分利用zipmaps，ziplists等，我想知道这些表示是否已经被压缩，或者只是序列化的散列和列表;压缩是否显着减少内存使用量？在将字符串放入redis之前压缩字符串 - 是否有意义？

此外，应用程序服务器层的压缩开销是否被较低的网络使用量抵消？ StackOverflow's experience暗示它有，还有其他意见吗？

简而言之，它是否有意义 - 对于短和长的字符串？

来源

2011-07-02 Hristo

Redis和客户端通常是IO绑定的，IO成本通常至少比请求/应答序列的其余部分大2个数量级。较小的有效载荷将为您提供更高的吞吐量和更低的延迟。

我不相信有超越以下的硬性规定：cost of compression << IO gains。你应该坐下来找到设定下限的汗点，但你的网络的MTU并不是一个不好的起点。

来源

2011-07-02 19:14:25 alphazero

我发现[this benchmark]（http://dev.mensfeld.pl/2013/04/compressing-large-data-sets-in-redis-with-gzip-ruby-test-case/）非常有用， [这些额外的想法]（http://nosql.mypopescu.com/post/46926679137/compressing-large-data-sets-in-redis-with-gzip）。 – robert4

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

来源

2011-07-02 11:28:31 Theo

因此，对于大约10K的东西，你说不要压缩 - 我是对的吗？对于一个特定的情况，你有很多内容一直约2到5K的JSON，低级别的gzip应该至少将内存占用空间减少2倍，特别是如果那些最终表现为zipmaps ？或者我错了 – Hristo

如果您可以将字符串的大小缩小两倍，那么您绝对应该压缩它们。我所说的是，你不能确定你会在小字符串上得到足够的压缩。根据字符串的内容，2-5K可能太低。XML由于重复的标签名称而非常好地压缩，但是由于JPEG，GIF或PNG中的图像数据已经压缩，所以它们根本不压缩，其他类型的数据具有其他属性。测试加载未压缩的数据并查看内存使用情况（'redis-cli info | grep used_memory'），然后查看压缩数据。 – Theo

有获得良好的压缩一条可行之路，即使是非常小的字符串（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。

来源

2012-03-24 00:01:58

在将字符串放入redis之前压缩字符串 - 是否有意义？

回答

相关问题