Алгоритм сжатия для небольших объемов данных - PullRequest
Новая
       36

Алгоритм сжатия для небольших объемов данных

3 голосов
/ 15 июля 2011

У меня есть серверная программа, которая генерирует JSON для клиента. Несколько моих коллег предложили использовать сжатие zip / gzip, чтобы уменьшить объем данных, передаваемых по проводам. Однако при проверке одного из моих средних сообщений JSON они оба фактически увеличили объем отправляемых данных. Лишь после того, как я отправил необычно большой ответ, молния сработала и стала полезной.

Итак, я начал разбираться со стековым потоком и в итоге обнаружил LZO , который при тестировании сделал именно то, что я хотел. Тем не менее, я не могу найти документацию по времени выполнения алгоритма, и я не достаточно хорош, чтобы сесть с кодом и разобраться сам:)

ТЛ; др? ВРЕМЯ РАБОТЫ LZO ?

Ответы [ 2 ]

8 голосов
/ 15 июля 2011

Я собираюсь проигнорировать ваш вопрос о времени выполнения LZO (ответ: почти наверняка достаточно быстро) и обсудить основную проблему.

Вы обмениваетесь структурами данных JSON по сети и хотите уменьшить пропускную способность. В данный момент вы рассматриваете алгоритмы сжатия общего назначения, такие как DEFLATE и LZO. Однако любой алгоритм сжатия, основанный на методах Lempel-Ziv , лучше всего работает с большими объемами данных. Эти алгоритмы работают путем создания словаря часто встречающихся последовательностей данных, чтобы они могли кодировать ссылку на словарь вместо всей последовательности, когда он повторяется. Чем больше словарь, тем лучше степень сжатия. Для очень небольших объемов данных, таких как отдельные пакеты данных, методика бесполезна: нет времени для создания словаря и нет времени для появления большого количества повторов.

Если вы используете JSON для кодирования проводного протокола, то ваши пакеты, скорее всего, стереотипны, с похожими структурами и небольшим количеством общих ключей. Поэтому я предлагаю изучить буферные протоколы Google , разработанные специально для этого варианта использования.

4 голосов
/ 15 июля 2011

Второе предложение, чтобы избежать LZO и любого другого типа алгоритма сжатия общих / двоичных данных.

Другие ваши варианты в основном:

Лучший выбор зависит от настроек вашего сервера / языка, вашеготребования скорости к сжатию и личные предпочтения.Я бы, наверное, сам пошел с MessagePack, но вы не ошибетесь и с буфером протокола.

...