Легкий способ хранения и извлечения объектов в Java без использования реляционной БД?
Знаете ли вы о "легком" способе хранения и извлечения объектов в Java без использования реляционного DB/ORM, такого как Hibernate?
[Обратите внимание, что я не рассматриваю сериализацию как есть для этой цели, так как он не позволит извлекать произвольные объекты в середине графа объектов. Я также не рассматриваю DB4O из-за его ограничительной лицензии. Спасибо.]
"Простое" значение: не нужно обрабатывать детали низкого уровня, такие как пары ключ/значение, чтобы перестроить граф объекта (например, с BerkeleyDB или традиционными кешами). То же самое относится к восстановлению объектов из базы данных, основанной на документах или столбцах (CouchDB, HBase,..., даже Lucene).
Возможно, есть интересные проекты, которые обеспечивают уровень интеграции между упомянутыми системами хранения и объектной модели (например, ORM для RDBMS), о которых я не знаю.
Любой, кто успешно использует тех, кто занимается производством, или экспериментирует с стратегиями сохранения, отличными от реляционных БД? Как насчет хранилищ RDF?
Обновление: я наткнулся на очень интересную статью: Список распределенных хранилищ ключей p >
Ответы
Ответ 1
Думаю, я нашел своего рода ответ на мой вопрос.
Получение ориентированного на документацию парадигмы - непростая задача, когда вы всегда считали свои данные соотношением, нормализацией и объединением.
CouchDB, похоже, соответствует счету. Он по-прежнему может выступать в качестве хранилища для ключей, но его отличные возможности запросов (сопоставление/сокращение, просмотр), concurrency готовность и доступность по языковым ресурсам HTTP делают это моим выбором.
Только глюк должен определить соответствие и сопоставить структуры JSON с объектами, но я уверен, что придумаю простое решение для использования с реляционными моделями из Java и Scala (и позже подумайте о кэшировании, поскольку конкуренция удаляется из базы данных). Терракота все еще может быть полезна, но, конечно, не так, как в случае сценария РСУБД.
Спасибо всем за ваш вклад.
Ответ 2
Я бы предложил Hibernate, потому что он будет иметь дело с большинством уродливых деталей, которые болотные разработчики используют при использовании базы данных, но при этом сохраняя оптимизацию, которая была сделана для программного обеспечения базы данных на протяжении многих лет.
Ответ 3
NeoDatis выглядит интересным. Он лицензируется под LGPL, поэтому не настолько ограничительный, как собственно GLP.
Посмотрите 1 минута учебника, чтобы узнать, будет ли это работать для ваших нужд.
Ответ 4
Я бы рекомендовал XStream, который просто берет ваши POJO и создает XML из них, поэтому вы можете хранить его на диске. Он очень прост в использовании и также является открытым исходным кодом.
Ответ 5
Я бы порекомендовал Hibernate (или, что более общее, OR-mapping), например, Matt, но также есть RDBMS на бэкэнд, и я не уверен в том, что вы подразумеваете под
... без использования реляционной БД?...
Также было бы интересно узнать больше о приложении, поскольку OR-сопоставление не всегда является хорошей идеей (производительность разработки и производительность выполнения).
Изменить: я вскоре узнал о терракоте, и здесь обсуждается обсуждение о замене БД этим инструментом. Еще экспериментально, но стоит прочитать.
Ответ 6
Я все еще думаю, что вам стоит подумать о том, чтобы заплатить за db4o.
Если вы хотите что-то еще, добавьте "с лицензией в стиле MIT" в заголовок.
Ответ 7
Ознакомьтесь с комментариями к Prevayler по этому вопросу. Prevayler - это транзакционная оболочка вокруг сериализации объектов - грубо говоря, использование объектов в простой Java и сохранение на диске через API java без sql, немного более аккуратный, чем запись собственной сериализации.
Предостережения - с сериализацией в качестве механизма устойчивости вы рискуете аннулировать сохраненные данные при обновлении класса. Даже с библиотекой обертки вы, вероятно, захотите настроить обработку сериализации/десериализации. Это также помогает включить serialVersionUID в класс, чтобы вы переопределили идею JVM о том, когда класс обновлен (и, следовательно, не может перезагрузить сохраненные сериализованные данные).
Ответ 8
Хм... без сериализации и без решения ORM я бы отказался от какой-то реализации на основе XML? Вам все равно придется тщательно его проектировать, если вы хотите вытащить только некоторые объекты из графа объектов - возможно, другой файл для каждого объекта, где ссылки на объекты ссылаются на URI на другой файл?
Я бы сказал, что это было не "легко", потому что я всегда считал, что проектирование отображения XML на объекты требует много времени, но я был действительно вдохновлен разговором на Apache Betwixt, в котором я чувствую надежду, что Я просто устарел, и теперь доступны более простые решения.
Ответ 9
Terracotta предоставляет высокодоступную, высоко масштабируемую стойкую к хранилищу объектов диска. Вы можете использовать его только для этой функции - или вы можете использовать его широкими возможностями для реализации полностью кластерного приложения - ваш выбор.
Terracotta:
- не нарушает идентификацию объекта, предоставляя вам наиболее естественный программный интерфейс
- не требует сериализации
- кластеров (и сохраняется) почти все классы Java (Карты, Замки, Очереди, Будущее, CyclicBarrier и т.д.)
- сохраняет объекты на диске со скоростью памяти
- перемещает только дельта объектов, обеспечивая очень высокую производительность.
Вот пример того, как gnip использует Terracotta для сохранения в памяти - нет базы данных. Гнип принимает все события на Facebook, Twitter и т.п. И производит их для потребителей в нормальном режиме. Их текущее решение обрабатывает более 50 000 сообщений в секунду.
Он OSS и имеет высокую степень интеграции со многими другими сторонними платформами, включая Spring и Hibernate.
