Сжатие JSON

Question

[sdevalex]

Есть ли готовые библиотеки, которые убирают из коллекции одинаковых объектов ключи и записывают их отдельно? (в виде pack, unpack функций, а может быть и ещё чего-то)

Т.е.

[{ "data1": 1, "data2": 2, "data3": 3 },
 { "data1": 1, "data2": 2, "data3": 3 },
 { "data1": 1, "data2": 2, "data3": 3 }, ...]

В

{
   data: [[1, 2, 3], [1, 2, 3]. [1, 2, 3], ...],
   keys: ['data1', 'data2', 'data3']
}

Или это экономия на спичках?

Comments

[sdevalex]

Решение найдено.
github.com/WebReflection/JSONH

[sdevalex]

JSON сжимается на 44%, если считать от изначального размера. В количестве символов:
(3639 — 2031) / 3639 = 0.44

[sdevalex]

Жертвы минимальны:

Application.data.servers.reset(#{collection.to_json.html_safe});

Заменил на:

Application.data.servers.reset(JSONH.unpack(#{JSONH.dump(collection.as_json).html_safe}));

Для AJAX загрузки нужно будет… пока не нужно…
В Backbone.Collection переопределить метод parse:

class @Application.Collection extends Backbone.Model
  parse: (respoce) -> JSONH.unpack(responce)

И добавить упаковку при рендере JSON (тоже в одном месте для всех контроллеров).

[sdevalex]

3.5кб — тестовые данные. Планируется на 1-2 порядка больше.

Answer 1

[Aleks]

я думаю вы говорите про это: www.cliws.com/e/06pogA9VwXylo_GknPEeFA/

Comments

[Aleks]

RJSON converts any JSON data collection into more compact recursive form. Compressed data is still JSON and can be parsed with JSON.parse. RJSON can compress not only homogeneous collections, but also any data sets with free structure.

[sdevalex]

Почти то, что нужно. Но RJSON — обобщенная реализация. У них в описании есть ссылка на то, что нужно:
github.com/WebReflection/JSONH

Answer 2

[neyronius]

Если вы включите GZip сжатие при отдаче с сервера, то получите тоже самое, но прозрачно — архиватор построит частотное дерево для повторяющихся строк и заменит каждую из них несколькими битами.

Использование найденного вами подхода также ограничивает формат данных — все записи должны иметь одинаковую структуру.

Comments

[sdevalex]

Все записи имеют одинаковую структуру, поэтому и задумался об оптимизации.

[EugeneOZ]

sdevalex, Вы себе такой «оптимизацией» создадите лишних ограничений. Чем меньше «нестандартного», тем лучше, проще будет другие модули добавлять (может быть даже чужие).

Answer 3

[Сергей Протько]

Вопервых это слишком специфичная оптимизация. Я допустим ни разу не встречал необходимости в подобном. Это все же не оптимизация даже, а способ агрегации данных.

Во вторых — да, это экономия на спичках. Даже если у вас этих данных мегабайт, то вы еще должны будете на клиенте/сервере данные обработать. Я бы лучше поэкономил процессорное время.

Comments

[sdevalex]

Rails делает из коллекции моделей такой JSON…

javascript:
    Application.data.servers.reset(#{collection.to_json.html_safe});

Application.data.servers — экземпляр Backbone.Collection

Answer 4

[Oronro]

Эта «оптимизация» больше зависит от того, как эти данные будут обрабатываться и использоваться.

Первый вариант имеет право на жизнь, поскольку он позволяет в потоке «кусками» передавать строки таблицы (структура данных и предложенная оптимизация больше похожа на описание таблицы), более того, позволяет пропускать значения конкретных «столбцов» считая что обработчик на автомате подставит туда `null` значения — данных то нет.

Второй вполне логичная оптимизация, однако потоком такую «таблицу» уже не передать, поскольку структура не предусматривает это by design и `null` значения уже не пропустить, иначе собьется порядок следования значений «стоблцов».

Итого: it depends. Необходимость этой «оптимизации» зависит не от экономии, а от способа обработки данных.

P.S. Если нужно получить более компактное представление JSON данных, при этом не пугает binary-формат и не хочется связываться с gzip — можно попробовать UBJSON — при полной совместимости размер обычно меньше процентов на 20-40, особенно при малом количестве ascii-строк и обилии unicode и числовых значений.

Answer 5

[pletinsky]

Нет — это не экономия на спичках. Это гораздо хуже — совмещение ответственности по формату данных с ответственностью по сжатию данных. Это чревато массой не очевидных проблем, связанных с обработкой таких данных.

Если рассматривать данный подход как некую контентозависимую архивацию — то он имеет право на жизнь. Но его эффективность нужно сравнивать с другими решениями — для бинарных данных (контентонезависимыми) и текстовых. Сравнивать необходимо выигрышь при сжатии и скорость архивации и разархивации. Даже если вы и выиграете — конечно только в специфическом json — врятли в типичном. А чтобы еще и овчинка стоила выделки (то есть разница со стандартными архиваторами имела бизнес значение на проекте) — по моему нужно совсем какие то экзотические условия.

Но я могу и ошибаться — вы можете провести исследования и проверить.
Или используйте готовые решения для сжатия текстовых данных.
Для xml в отличие от json — есть сжатие специфическое для xml над сжатием текста — там с этим намного проще.