Высокопроизводительная сериализация объектов Java в Google App Engine (GAE)

Мы ищем высокопроизводительное компактное сериализационное решение для объектов Java в GAE.Высокопроизводительная сериализация объектов Java в Google App Engine (GAE)

Собственная сериализация Java не выполняет все это хорошо, и это ужасно при совместимости, то есть она не может не инициализировать старый объект, если поле добавлено в класс или удалено.

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

Любые идеи, пожалуйста? Благодаря!

источник

2013-12-03 user1176505

Вам нужны перекрестные способности? и re. высокопроизводительные вы имеете в виду только скорость, или включая оптимизированное управление памятью для меньшего количества GC, или включая размер сериализованного объекта?

Если вам нужен перекрестный язык, я думаю, что protobuf является решением. Однако его вряд ли можно назвать «высокой производительностью», потому что строки UTF-8, созданные на стороне Java, вызывают постоянные GC.

В случае, если данные, которые вы поддерживаете, являются в основном простыми объектами, и вам не нужна композиция, я бы рекомендовал вам написать собственный уровень сериализации (не шутите).

Использование перечисления индексировать ваши поля таким образом, вы можете сериализовать поля, которые содержат значение только
Создание карт для примитивных типов с использованием коллекций trove4j.
Использование кэшированных объектов ByteBuffer, если вы можете предсказать размер для большинства ваших объектов под определенным значением.
Использования строки словаря, чтобы уменьшить строковый объект воссоздание и использовать кэшированные StringBuilder во время десериализации

Вот что мы сделали для нашего «высокопроизводительного» сериализации слоя. По существу, мы могли бы добиться почти объектно-сериализации сериализации/де-сериализации в разумные сроки.

источник

2013-12-03 10:37:49

Извините, но вы получите -1. В Java существует множество существующих сериализационных решений, и писать свои собственные - это признак неопытного разработчика. Кроме того, OP должен сначала провести некоторое тестирование и решить, что оптимизация сериализации имеет смысл. –

На самом деле, если вы действительно подробно рассмотрели существующие решения для сериализации в Java, вы заметите различные недостатки. Вот почему я спросил OP, в первую очередь, что именно он ищет.Вы можете задаться вопросом, зачем изобретать колесо, но поверьте мне, что в моей индустрии люди по-разному пишут свой собственный слой сериализации. –

Спасибо. Я беспокоюсь в основном о скорости. Я могу закрепить его потом, если это необходимо для размера. Не требуется перекрестный язык. Странно писать наши собственные, может быть, не такая плохая идея в этом случае, учитывая, как менеджер безопасности взаимодействует с библиотеками. – user1176505

Остерегайтесь, преждевременная оптимизация - это корень всего зла.

Сначала вы должны попробовать одно из стандартных решений, а затем решить, соответствует ли оно вашим требованиям к производительности. Я проверил несколько сериализационных решений на GAE (сериализация Java, JSON, JSON + ZIP), и они были на порядок быстрее, чем доступ к хранилищу данных.

Поэтому, если данные сериализации занимают 10 мс и записывают их в хранилище данных, занимает 100 мс, при попытке оптимизировать 10 мс очень мало пользы.

Btw, вы попробовали Джексона?

Кроме того, все вызовы API для GAE реализованы как вызовы RPC на другие серверы, где полезная нагрузка сериализуется как protobuf.

источник

2013-12-03 13:22:46

Вы называете Джексона высокопроизводительным? –

Нет, я достаточно назову Джексона. Btw благодарит за -1. –

Это говорит только о том, что вы не работали с высокопроизводительной системой. –

Высокопроизводительная сериализация объектов Java в Google App Engine (GAE)

ответ

Смежные вопросы