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

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

Кроме того, накладные расходы сжатия на уровне сервера приложений компенсируются за счет более низкого использования сети? StackOverflow's experience предлагает это, любые другие мнения?

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

источник

2011-07-02 Hristo

Redis и клиенты, как правило, связаны с IO, а затраты на ВО обычно составляют не менее 2 порядков по отношению к остальной части последовательности запросов/ответов. Меньшая полезная нагрузка даст вам более высокую пропускную способность и более низкие задержки.

Я не верю, что существуют жесткие и быстрые правила за пределами: cost of compression << IO gains. Вы должны сканировать его и найти пятно пота при настройке нижней границы, но MTU вашей сети не является плохой отправной точкой для нижней границы.

источник

2011-07-02 19:14:25 alphazero

Я нашел [этот тест] (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 и более, вероятно, стоит дополнительных циклов процессора на стороне клиента, точно так же, как когда вы обслуживаете веб-страницы, но для более коротких строк это, скорее всего, пустая трата времени. Короткие строки обычно не сильно сжимаются, поэтому коэффициент усиления будет слишком мал.

источник

2011-07-02 11:28:31 Theo

Итак, для чего-то, что около 10K, вы говорите, не сжимаете - я прав? Что касается конкретного случая, когда у вас много контента, который составляет примерно от 2 до 5K JSON, низкоуровневый gzipping должен сокращать объем памяти этих лиц по крайней мере в 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 - это имеет смысл?

ответ

Смежные вопросы