Немного более подробно: мы уже пытаемся максимально использовать преимущества zipmaps, ziplists и т.д., и мне интересно, сжаты ли эти представления или просто сериализованные хэши и списки; делает сжатие значительно сокращает использование памяти?
Кроме того, накладные расходы сжатия на уровне сервера приложений компенсируются меньшим использованием сети? Опыт StackOverflow предполагает, что это так, любые другие мнения?
Вкратце, имеет ли смысл - для коротких и более длинных строк?
Redis и клиенты, как правило, привязаны к IO, а затраты на ВЗ обычно составляют как минимум 2 порядка по отношению к остальной части последовательности запросов/ответов. Меньшая полезная нагрузка даст вам более высокую пропускную способность и более низкие задержки.
Я не верю, что существуют жесткие и быстрые правила: cost of compression << IO gains. Вы должны сканировать его и найти пятно пота при настройке нижней границы, но MTU вашей сети не является плохой отправной точкой для нижней границы.
Redis не сжимает ваши значения, и если вы должны их сжимать, то многое зависит от размера строк, которые вы собираетесь хранить. Для больших строк, сотни K и более, вероятно, стоит дополнительных циклов процессора на стороне клиента, точно так же, как при обслуживании веб-страниц, но для более коротких строк это, вероятно, пустая трата времени. Короткие строки обычно не сильно сжимаются, поэтому коэффициент усиления будет слишком мал.
Там есть практический способ получить хорошее сжатие даже для очень маленьких строк (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 для этого потрясающего трюка.