Простой способ хранить и извлекать объекты на Java без использования реляционной БД?

• Сериализация объектов (также известная как сохранение данных в файл)
• Hibernate (использует реляционную базу данных, но она довольно прозрачна для разработчика)

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

NeoDatis выглядит интересно. Он лицензирован под LGPL, поэтому не так строг, как собственно GLP.

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

Я хотел бы порекомендовать XStream, который просто берет ваши POJO и создает из них XML, чтобы вы могли хранить его на диск. Он очень прост в использовании, а также имеет открытый исходный код.

Я бы порекомендовал Hibernate (или, в более общем смысле, OR-отображение), например Мэтт, но на бэкэнде также есть СУБД, и я не уверен, что вы имеете в виду под

... без использования реляционной БД? ...

Также было бы интересно узнать больше о приложении, потому что OR-отображение не всегда является хорошей идеей (производительность разработки или производительность во время выполнения).

Изменить: я вскоре узнал о терракоте, и здесь есть хорошее обсуждение stackoverflow здесь о замене БД этим инструментом. Все еще экспериментальный, но стоит прочитать.

Я по-прежнему считаю, что вам стоит подумать об оплате db4o.

Если вам нужно что-то еще, добавьте к заголовку «с лицензией в стиле MIT».

Просмотрите комментарии к Prevayler по этому вопросу. Prevayler - это транзакционная оболочка для сериализации объектов - грубо говоря, используйте объекты в простой java и сохраняйте на диске через java API без sql, что немного удобнее, чем писать собственную сериализацию.

Предостережения: с сериализацией как механизмом устойчивости вы рискуете сделать ваши сохраненные данные недействительными при обновлении класса. Даже с библиотекой-оболочкой вы, вероятно, захотите настроить обработку сериализации / десериализации. Это также помогает включить serialVersionUID в класс, чтобы вы переопределили представление JVM о том, когда класс обновляется (и, следовательно, не можете перезагрузить сохраненные сериализованные данные).

Хм ... без сериализации и без решения ORM я бы вернулся к какой-то реализации на основе XML? Вам все равно придется тщательно спроектировать его, если вы хотите извлечь только некоторые объекты из графа объектов - возможно, отдельный файл для каждого объекта, где отношения объектов ссылаются на URI с другим файлом?

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

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

Терракота:

• не нарушает идентичность объекта, обеспечивая наиболее естественный интерфейс программирования
• не требует сериализации
• кластеры (и сохраняется) почти все классы Java (Карты, Блокировки, Очереди, FutureTask, CyclicBarrier и др.)
• сохраняет объекты на диск со скоростью памяти
• перемещает только дельты объектов, обеспечивая очень высокую производительность

Вот пример того, как gnip использует Terracotta для сохранения в памяти. - нет базы данных. Gnip принимает все события в Facebook, Twitter и т. Д. И предоставляет их потребителям в стандартизированном виде. Их текущее решение обрабатывает более 50 000 сообщений в секунду.

Это OSS и имеет высокую степень интеграции со многими другими сторонними фреймворками, включая Spring и Hibernate.

Думаю, я нашел своего рода ответ на свой вопрос.

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

CouchDB, похоже, отвечает всем требованиям. Он по-прежнему может действовать как хранилище ключей и значений, но его отличные возможности запросов (отображение / сокращение, сопоставление просмотра), готовность к параллелизму и независимый от языка HTTP-доступ делают его моим выбором.

Единственная проблема заключается в том, чтобы правильно определять и сопоставлять структуры JSON с объектами, но я уверен, что придумаю простое решение для использования с реляционными моделями из Java и Scala (и позже буду беспокоиться о кешировании, поскольку конкуренция уходит от база данных). Терракотовый цвет все еще может быть полезен, но, конечно, не так, как в сценарии РСУБД.

Спасибо всем за ваш вклад.