Буферы протокола для сериализации нескольких объектов данных поста / комментария в один сериализованный фрагмент данных - PullRequest
5 голосов
/ 03 марта 2011

Я занимаюсь разработкой социального приложения на базе баз данных Java и Cassandra. Мне нужно хранить сообщения / комментарии общих сообщений пользователя в базе данных, для которой я хочу сериализовать данные для одного комментария / сообщения, а затем хранить сериализованные данные в базе данных в одном столбце. Таким образом, для каждого комментария будет один столбец, в котором хранятся эти данные в сериализованном формате: -

  1. Данные комментариев (не более 700 символов)
  2. CommentorId (длинный тип)
  3. CommentTime (отметка времени)

Аналогичным образом данные сообщений будут сериализованы и сохранены в виде одного столбца.

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

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

Кроме того, возможно ли отправить данные в сериализованном формате клиенту, а затем их можно десериализовать? связь сервера с клиентом?

Ответы [ 3 ]

2 голосов
/ 03 марта 2011

Не знаю, подходит ли это в вашем конкретном случае, но я видел предложения по сохранению JSON-представления данных, которые можно напрямую отправить в браузер.Если вам не нужны дальнейшие этапы обработки с участием POJO, то этот или аналогичный подход может быть (быстрым) способом.

1 голос
/ 03 марта 2011

буферы протокола, безусловно, обеспечивают сериализацию, хотя сторона RPC остается для вашего воображения (часто что-то простое и основанное на сокетах работает очень хорошо).

Все типы данных хорошо поддерживаются protobuf (хотя вы можете использовать что-то вроде ms в эпоху unix для даты). Обратите внимание, что этот protobuf не включает сжатие (если вы не применили gzip и т. Д. К потоку). Таким образом, сообщение будет «немного длиннее строки (которая всегда использует кодировку UTF-8 в protobuf). Я говорю« немного », потому что алгоритм varint для целочисленных типов может дать что-нибудь между 1 и 10 байтами каждый для идентификатора и отметка времени, в зависимости от их величины. И несколько (3, вероятно) байтов для заголовков полей.

Если это звучит примерно так, значит, все должно работать нормально. Однако, если у вас много текстовых данных, вы можете также запустить поток protobuf через gzip. Java имеет отличную поддержку в рамках protobuf через основной ствол Google.

1 голос
/ 03 марта 2011

В целом, похоже, что Protocol Buffers хорошо подходит для того, что вы хотите сделать. Многие люди используют его именно для того, что вы описали. Я слышал о некоторых других, использующих простой JSON для этого, но он определенно менее эффективен.

Protocol Buffers - это быстрый, переносимый, зрелый и хорошо документированный. Он разработан и поддерживается Google. Одной из отличительных особенностей буферов протокола является возможность прозрачного расширения существующих записей новыми полями. Например, вы можете расширить существующий формат записи, включив в него некоторые другие поля, не преобразовывая существующие данные или не изменяя программное обеспечение, работающее со старыми полями (так как оно будет молча отбрасывать неизвестные поля).

По поводу вашего вопроса о том, может ли клиент работать с сериализованным форматом (если я правильно понял вопрос). Если клиент поддерживает буфер протоколов и имеет файлы «.proto», описывающие формат данных, он сможет работать с ним так же, как и вы. Если клиент не может работать с буфером протокола, есть некоторые сторонние библиотеки [1], которые могут конвертировать между форматами Protobuf, JSON и XML (я сам не пробовал их использовать).

Возможно, вы также захотите проверить некоторые альтернативы буферам протоколов, такие как Message Pack [2] и Avro. Они утверждают, что быстрее / компактнее / поддерживают динамическую печать.

[1], например, http://code.google.com/p/protobuf-java-format/

[2] http://msgpack.org/

...