Будет ли полезно сжатие справочником JSON domain-specific words?

Question

[mayton2019]

Бизнес гоняет из Редиса во фронт 10 килобайтные JSON документы которые состоят из всякого пенопласта.
Редис - лопается от объема и мы ему растягиваем память периодически. До 30 Гб дотянули кажется.

Документ содержит порядка 50 полей. Из них штук 5 - текстовые. Содержат описание товара. Обычно унылое
и однообразное. Содержат состав (химический). Эти 5 полей являются основными потребителями объема.

Я вот прикинул если я составлю справочних этих популярных слов то 80% этого пенопласта уйдет.
Остался пустяк - как сокращения придумать. Обратил внимание что спектр Unicode символов мы даже
близко полностью не используем. Там есть резервированные диапазоны. И я вот думаю если
я создам справочник из domain-specific words (DSW) то я как раз смогу уменьшить потребление редиса.

Еще остался пустяк. Научить фронт расшифровывать такие строки с сокращениями. Это у меня слабое место.

Вот. Что думаете?

UPD: Собрал гистограмму слов. Фильтровал слова длинее чем 5 символов. Топ слов по частоте за всю базу
редиски.

strong ; 11821
Ingredients ; 10320
ingredients ; 9825
formaldehyde ; 9430
formulated ; 8342
product ; 8224
Ingredient ; 7752
Callouts ; 7669
without ; 7567

Answer 1

[psiklop]

На вид геморрой какой-то самопальный себе заботу и приключение потом надолго. Я знаю архиваторы еще, может даже какое-то проф-решение есть. Я как-то делал JSON-ну: JSON_UNESCAPED_UNICODE + gzcompress чтобы уменьшить, и очень неплохо вышло.

Answer 2

[Dmtm]

Остался пустяк - как сокращения придумать.

не надо сокращения, достаточно пары байт
штук 5 бит отвести на признак замены а остальное - на ID замененного куска текста
и CRC для проверки что все корректно расшифровано
PS: хотя обычно это делают уровнем ниже, архивацией всего потока даннных при пересылке

Comments

[mayton2019]

Я хотел оперировать только символами. А символы из диапазона Unicode https://en.wikipedia.org/wiki/Private_Use_Areas которые в приватном использовании. Я себе это так понимаю что берешь его под свою задачу и как хочешь так и интерпретируешь.

И пара байт это как раз и будет символ из этого резервного диапазона.

Почему я интересовался именно символами и строками? Я опирался на то что строка - это основной транспортный формат. Мне ведь в JSON складывать блоб без base64 кодирование не получится. А это кодирование портит статистику сжатия.

Но вобщем это забавный творческий эксперимент. И это конечно никакой не архиватор. Конечно
snappy, LZW был бы лучше в этом случае полюбому. Но алгоритмы сжатия всегда на выходе продуцируют
сырые байты.

Answer 3

[d'Ivan]

Эти

domain-specific words

можно генерировать автоматически, исходя из их количества, кодируя Base62. Такой словарь можно передавать на фронт-энд при инициализации. Его можно даже в CDN выдавать, если он статический.