Сжатие JSON

Есть ли готовые библиотеки, которые убирают из коллекции одинаковых объектов ключи и записывают их отдельно? (в виде 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']
}


Или это экономия на спичках?
  • Вопрос задан
  • 7956 просмотров
Решения вопроса 1
Пригласить эксперта
Ответы на вопрос 4
neyronius
@neyronius
Если вы включите GZip сжатие при отдаче с сервера, то получите тоже самое, но прозрачно — архиватор построит частотное дерево для повторяющихся строк и заменит каждую из них несколькими битами.

Использование найденного вами подхода также ограничивает формат данных — все записи должны иметь одинаковую структуру.
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Вопервых это слишком специфичная оптимизация. Я допустим ни разу не встречал необходимости в подобном. Это все же не оптимизация даже, а способ агрегации данных.

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

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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Artezio Нижний Новгород
от 130 000 до 180 000 ₽
Artezio Москва
от 160 000 до 220 000 ₽
от 80 000 до 150 000 ₽
24 нояб. 2020, в 01:46
3000000 руб./за проект
24 нояб. 2020, в 01:34
10000 руб./за проект