Сжатие строк перед их повторным использованием - имеет ли это смысл?

Question

Немного подробнее: мы уже пытаемся максимально использовать zipmaps, ziplists и т. Д., И мне интересно, являются ли эти представления уже сжатыми, или это просто сериализованные хэши и списки; Сжатие значительно уменьшает использование памяти?

Кроме того, накладные расходы сжатия на уровне сервера приложений компенсируются меньшим использованием сети? Опыт StackOverflow подсказывает, есть ли другие мнения?

Вкратце, имеет ли смысл - как для коротких, так и для длинных строк?

Answer 1

Redis не сжимает ваши значения, и если вам нужно сжать их самостоятельно, во многом зависит от размера строк, которые вы собираетесь хранить.Для больших строк, сотен и более K, вероятно, стоит дополнительных циклов ЦП на стороне клиента, как и при работе с веб-страницами, но для более коротких строк это, вероятно, пустая трата времени.Короткие строки обычно не сильно сжимаются, поэтому усиление будет слишком маленьким.

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 вашей сети - неплохая отправная точка для нижней границы.