Ищете быстрый, компактный, потоковый, многоязычный, строго типизированный формат сериализации

В настоящее время я использую JSON (сжатый через gzip) в своем проекте Java, в котором мне нужно хранить на диске большое количество объектов (сотни миллионов). У меня есть один объект JSON на строку, и я запрещаю перенос строк в объекте JSON. Таким образом, я могу передавать данные с диска построчно, не читая сразу весь файл.

Оказывается, анализ кода JSON (с помощью http://www.json.org/java/) - это больше накладных расходов, чем извлечение необработанных данных с диска или их распаковка (что я делаю на лету).

В идеале мне нужен строго типизированный формат сериализации, где я могу указать «это поле объекта представляет собой список строк» ​​(например), и поскольку система знает, чего ожидать, она может быстро десериализовать его. Я также могу указать формат, просто указав кому-нибудь его «тип».

Он также должен быть кроссплатформенным. Я использую Java, но работаю с людьми, использующими PHP, Python и другие языки.

Итак, резюмируя, это должно быть:

  • Строго типизированный
  • Потоковая передача (т. Е. Чтение файла по крупицам без необходимости загружать все сразу в ОЗУ)
  • Кросс-платформенный (включая Java и PHP)
  • Быстрый
  • Бесплатно (как в речи)

Есть указатели?


java php serialization strong-typing
person sanity    schedule 28.07.2009    source источник
comment
Если получение необработанных данных с диска происходит быстрее, почему бы этого не сделать? Зачем связываться с JSON, если он медленнее?   -  person S.Lott    schedule 28.07.2009
comment
Итак, синтаксический анализ json выполняется медленнее, чем распаковка или чтение данных с диска. Ну и что? Это слишком медленно для того, что вам нужно сделать? Или вы оптимизируете просто ради этого?   -  person Breton    schedule 28.07.2009
comment
Бретон: это слишком медленно для того, что мне нужно делать, это не преждевременная оптимизация.   -  person sanity    schedule 28.07.2009

Ответы (3)


arrow_upward
8
arrow_downward

Вы смотрели буферы протокола Google ?:

http://code.google.com/apis/protocolbuffers/

Они кроссплатформенные (C ++, Java, Python) со сторонними привязками для PHP. Он быстрый, довольно компактный и строго типизированный.

Здесь также есть полезное сравнение между различными форматами:

http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking

Возможно, вы захотите рассмотреть Thrift или один из других, упомянутых здесь.

person Jon    schedule 28.07.2009
comment
... и есть поддержка Google. - person Isaac Waller; 28.07.2009

arrow_upward
3
arrow_downward

У меня были очень хорошие результаты, анализируя JSON с помощью Джексона

Джексон - это:

  • Стриминг (чтение, запись)
  • БЫСТРЫЙ (по измерениям быстрее, чем у любого другого парсера Java json и связывания данных)
  • Мощный (полная привязка данных для общих классов JDK, а также любого класса Java bean, Collection, Map или Enum)
  • Нулевая зависимость (не полагается на другие пакеты, кроме JDK)
  • Открытый исходный код (LGPL или AL)
  • Полностью соответствует

Процессор JSON (парсер JSON + генератор JSON), написанный на Java. Помимо базового чтения / записи JSON (синтаксический анализ, генерация), он также предлагает полную модель дерева на основе узлов, а также полную функциональность привязки данных OJM (Object / Json Mapper).

Его производительность очень хороша по сравнению со многими другими вариантами сериализации. .

person Robert Munteanu    schedule 28.07.2009
comment
Используйте Джексона, прежде чем пробовать что-нибудь еще. Код на json.org не подходит для производственного использования. - person Kevin Peterson; 28.07.2009

arrow_upward
2
arrow_downward

Вы можете взглянуть на YAML- http://www.yaml.org

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

Я понятия не имею, будет ли он «достаточно быстрым», но синтаксический анализатор libyaml (написанный на C) кажется довольно быстрым.

person Sharpie    schedule 28.07.2009
comment
Хотя Yaml никоим образом не является надмножеством JSON, я согласен с тем, что это один из самых читаемых / компактных / типизированных форматов, которые я знаю. - person gizmo; 28.07.2009
comment
yaml намного сложнее, чем json. Я думаю, что большинство реализаций медленнее. - person troelskn; 28.07.2009
comment
AFAIK, да, реализации не очень производительны. YAML ориентирован на несколько иные цели, максимальную выразительность и так далее, а не на скорость или простоту. - person StaxMan; 21.11.2009