бинарный формат

[grigori]

Мне надо для абстрактного исследования в вакууме преобразовать 2-мерный массив строк в бинарный формат, и посмотреть насколько он займет меньше места, чем json и csv.
Данные - однородный каталог товаров, 5 полей, 200 тысяч записей.
Protobuf можно, но сложности с not invented here, проще велосипед придумать.
Посоветуйте алгоритм на php.

 

[AnrDaemon]

composer require AnrDaemon/minecraft-nbt-demos

 

[grigori]

@AnrDaemon, спасибо, гляну

 

[antson]

@grigori, из интереса тоже глянул в репу.
в выходном файле у тебя окажется gzip'аные
строки в паскале стиле (4байта длины)и контент строки.
ну и еще немного обвеса.

длину неархивированных можно прикинуть и так 4мБ префиксов + суммарная длина строк во всех ячейках. после сжатия раз 8-10 меньше
Нультерминайтед строки как-то повыгоднее смотрятся (всего 1М сверху)

csv это у нас 4 запятых и перенос строки плюсом к длине строк в записи, т.е. тоже
самое что просто все строки заканчивающиеся на нули (+ мы видим сразу записи, в бинари нужно считать).

json накладных побольше {} "", да еще экранирование. Хотя в процентах наверное не больше 1 будет.

Самым перспективным мне кажется вариант
когда строка прайса архивируется по усредненному статическому алфавиту .
Не нужно обработается весь файл целиком.
Да сжимать будет намного хуже, но быстро.

 

[AnrDaemon]

@antson, ты видимо по диагонали смотрел.

 

[antson]

@AnrDaemon, возможно. Открывал на просмотр 8 или 10 классов.
TAG_Short::store($len) . $value; - это разве не то, что запишется в файл для строки ?

 

[grigori]

@antson, что у тебя значит "4мБ" и "1М"? что такое префиксы? "после сжатия раз 8-10 меньше" чем что?
"Нультерминайтед строки повыгоднее" чем что?

что такое усредненный статический алфавит? ссылку можешь дать на описание алгоритма? по смыслу слов приблизительно понимаю, но алгоритм буду придумывать очень долго

csv - это еще кавычки, экранирование кавычек и запятых
в json накладные расходы - это в первую очередь названия полей сущностей, например

{
"name": "abc",
"value": 1
}

но json тоже можно оптимизировать - вынести имена полей в отдельный пакет с метаданными, и будет почти как csv

 

[grigori]

сравнивать в итоге я буду с json, который сжат gzip nginx-ом и зашифрован tls - сниму размер пакетов tcpdump-ом с 443го порта

кушать эти данные я буду в javascript, тут json удобнее

вероятно, overhead формата json будет незначителен по сравнению с бинарным, но это надо доказать

 

[AnrDaemon]

Сами данные никак не трансформируются. Сжиматься может файл, но сжимается он только целиком при записи.
Да, строки с префиксами, но иначе ты никак не обеспечишь бинарную чистоту формата. (Это и в названии прямо сказано - Named BINARY Tags.)

 

[AnrDaemon]

сравнивать в итоге я буду с json, который сжат gzip nginx-ом и зашифрован tls - сниму размер пакетов tcpdump-ом с 443го порта

кушать эти данные я буду в javascript, тут json удобнее

вероятно, overhead формата json будет незначителен по сравнению с бинарным, но это надо доказать

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

 

[MiksIr]

Для абстрактого исследования, имхо, сойдет соединить все данные в одну большую строку и загзипать. Накладными расходами на разделители полей - можно принебречь, имхо. Ну или сварганить что-то примитивное типа длина поля;данные... + разделитель строк, если все текстовое.
Если же хочется менее абстрактное и заложиться на универсализм и расчет на ПХП - то просто попробовать igbinary для начала.

 

[grigori]

хм, если под усредненным алфавитом понимается что-то вроде алгоритма Хаффмана по предварительно подготовленному словарю, то есть проблема - в проекте заявлена поддержка >20 языков, включая китайский-японский-корейский

 

[fixxxer]

msgpack?

 

[MiksIr]

msgpack?

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

 

[grigori]

Для абстрактого исследования, имхо, сойдет соединить все данные в одну большую строку и загзипать. Накладными расходами на разделители полей - можно принебречь, имхо. Ну или сварганить что-то примитивное типа длина поля;данные... + разделитель строк, если все текстовое.
Если же хочется менее абстрактное и заложиться на универсализм и расчет на ПХП - то просто попробовать igbinary для начала.

нужен прототип
igbinary - это реализация, причем, без js-клиента, затаскивать его в проект нереально

 

[grigori]

msgpack?

о! любопытно, спасибо

 

[MiksIr]

нужен прототип
igbinary - это реализация, как и protobuf, мне нужен простой алгоритм, чтобы самому написать код

Алгоритм универсальный или конкретный под набор данных? Если под конкретный набор 5 х 200к не бинарных строк, то gzip текста из всех склеенных строк + ~1Мб разделители

 

[grigori]

Не убирает накладные на имена полей. gzip то, возможно, это нивелирует, но тут как раз идея проверить это на практике, как я понял.

а имена полей я сам уберу, руками

 

[grigori]

Алгоритм универсальный или конкретный под набор данных? Если под конкретный набор 5 х 200к не бинарных строк, то gzip текста из всех склеенных строк + ~1Мб разделители

формат нефиксированный, но стандартный - "2-мерный массив строк, каталог товаров"
данные клиентские, пришли по SOAP, мультибайтовые, надо переварить и раздать на много тысяч мобильных без ограничений по серверным затратам, но с ограничениями браузерного js,
какой-попало формат откушивает 100мбит, это не нравится

 

[MiksIr]

Ну мультибайт - он все же не бинарный, т.е. вполне можно взять банально \0 как разделитель строк, и уложить их одну за другой. С учетом того, что число столбцов матрицы, их порядок и названия тебе известны заранее (и передавать не нужно), исходную структуру 2-мерного массива ты восстановишь. Имхо, это вариант с наименьшим оверхедом на сериализацию.