在將字符串放入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之前壓縮字符串 - 是否有意義？

回答

相關問題