Сериализация самодельных и Java

Question

У меня есть определенный POJO, который необходимо сохранить в базе данных, текущий дизайн определяет его поле как однострочный столбец, и добавление дополнительных полей в таблицу не вариант.

Это означает, что объекты должны быть каким-то образом сериализованы. Так что просто для базовой реализации я разработал собственную сериализованную форму объекта, которая означала объединение всех его полей в одну красивую строку, разделенную выбранным разделителем. Но это довольно уродливо и может вызвать проблемы, скажем, если одно из полей содержит мой разделитель.

Итак, я попробовал базовую сериализацию Java, но из проведенного мною основного теста это почему-то становится очень дорогой операцией (создание ByteArrayOutputStream, ObjectOutputStream и т. Д., То же самое для десериализации).

Так, каковы мои варианты? Каков предпочтительный способ сериализации объектов в базе данных?

Редактировать: это будет очень распространенная операция в моем проекте, поэтому накладные расходы должны быть сведены к минимуму, а производительность имеет решающее значение. Кроме того, сторонние решения хороши, но не имеют значения (и обычно приводят к накладным расходам, которых я стараюсь избегать)

Answer 1

Второе предложение - использовать JAXB или, возможно, XStream (первый быстрее, второй больше фокусируется на части сериализации объектов). Кроме того, я дополнительно предложу достойную альтернативу на основе JSON, Джексон (http://jackson.codehaus.org/Tutorial),), которая может полностью сериализовать / десериализовать бины в текст JSON для хранения в столбце.

Да, и я абсолютно согласен с тем, что не используйте двоичную сериализацию Java ни при каких обстоятельствах для долговременного хранения данных. То же самое касается протокольных буферов; оба являются слишком хрупкими для этой цели (они лучше подходят для передачи данных между системами с жесткой связью).

Answer 2

Вы смотрели в JAXB ? Это механизм, с помощью которого вы можете определить набор java-объектов, которые создаются из XML-схемы. Это позволяет вам выполнить маршализацию из иерархии объектов в XML или демонтировать XML обратно в иерархию объектов.

Answer 3

Рассмотрите возможность изменения вашей схемы. Даже если вы найдете быстрый способ сериализации POJO в строку, как вы обрабатываете разные версии? Как вы переносите базу данных из X-> Y? Или хуже от A-> D? У меня возникают проблемы, когда мы сохраняем сериализованный объект в поле BLOB и вынуждены переносить клиента в несколько версий.

Answer 4

У меня есть определенный POJO, который необходимо сохранить в базе данных, текущий дизайн определяет его поле как однострочный столбец, и добавление дополнительных полей в таблицу не вариант.

Не могли бы вы создать новую таблицу и вставить внешний ключ в этот столбец!?!? :) Я подозреваю, что нет, но давайте рассмотрим все основы!

Сериализация: Недавно мы провели это обсуждение, чтобы в случае сбоя нашего приложения мы могли воскресить его в том же состоянии, что и ранее. Мы по существу отправляем событие персистентности в очередь, а затем это захватывает объект, блокирует его и затем сериализует его. Это кажется довольно быстрым. Сколько данных вы сериализуете? Можете ли вы сделать какие-либо переменные (то есть, кэшированные переменные) Можете ли вы рассмотреть возможность разделения вашей сериализации? Осторожно: что произойдет, если ваши объекты изменятся (блокировка) или классы изменятся (другой идентификатор сериализации)? Вам нужно обновить все, что сериализовано, до последних классов. Возможно, вам нужно хранить это только на ночь, чтобы это не имело значения?

XML: Вы можете использовать что-то вроде xstream для достижения этой цели. Создание чего-то нестандартного выполнимо (хороший вопрос для интервью!), Но я бы, наверное, не сделал это сам. Зачем беспокоиться? Помните, если у вас есть циклические ссылки или если у вас есть ссылки на объекты более одного раза. Восстановление объектов не так тривиально.

Хранилище базы данных: Если вы используете Oracle 10g для хранения больших двоичных объектов, обновитесь до последней версии, поскольку производительность c / blob значительно возросла. Если мы говорим о больших объемах данных, то, возможно, сжатый поток данных?

Это приложение в реальном времени, или будут две или две паузы, где вы можете безопасно сохранить реальный объект? Если у вас есть время, вы можете его клонировать, а затем сохранить клон в другом потоке. Для чего настойчивость? Это важно, что это сделано внутри транзакции?