Какая разница между Spring Data MongoDB и Hibernate OGM для MongoDB?

Ответ 1

Отказ от ответственности: я возглавляю проект данных Spring Data, поэтому я в основном рассмотрю часть данных Spring Data here:

Я думаю, что основное различие между этими двумя проектами состоит в том, что команда OGM Hibernate решила сосредоточить свои усилия на JPA, а команда Spring Data явно не сделала этого. Причины таковы:

• JPA является неотъемлемо реляционным API. Первые два предложения состояния spec, что он API для объектно-реляционного сопоставления. Это также отражено в основных темах API: оно говорит о таблицах, столбцах, объединениях, транзакциях. Концепции, которые не обязательно переносятся в мир NoSQL.
• Обычно вы выбираете хранилище NoSQL из-за его особых свойств (например, геопространственные запросы на MongoDB, способные выполнять трассировки графиков для Neo4j). Ни один из них (и не будет) доступен в JPA, поэтому вам все равно придется предоставлять проприетарные расширения.
• Хуже того, JPA предлагает концепции, которые просто направят пользователей на неправильные направления, если они предполагают, что они будут работать в хранилище NoSQL, как они были определены в JPA: как должен быть выполнен откат транзакции разумно поверх MongoDB?

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

Ответ 2

Отказ от ответственности: я являюсь одним из разработчиков OGM Hibernate, поэтому я попытаюсь объяснить некоторые причины этого.

Hibernate OGM обеспечивает поддержку Java Persistence (JPA) для решений NoSQL. Он повторно использует движок Hibernate ORMs, но сохраняет объекты в хранилище данных NoSQL вместо реляционной базы данных. Он также направлен на предоставление доступа к конкретным функциям хранилища данных, когда JPA не имеет хорошей подгонки.

Этот подход интересен по нескольким причинам:

• Известные семантические и API-интерфейсы. Разработчики Java уже знакомы с JPA, это означает, что не нужно изучать API нижнего уровня. Он также поддерживает как HQL, так и собственные бэкэнд-запросы.

• Поздний выбор бэкэнд. Выбор правильного хранилища данных NoSQL не является тривиальным. С Hibernate OGM вам не придется совершать какое-либо конкретное решение NoSQL, и вы сможете легко переключаться и тестировать разные серверы.

• Существующие инструменты и библиотеки. JPA и Hibernate ORM существуют некоторое время, и вы сможете повторно использовать библиотеки и инструменты, которые их используют под ними.

• Большая часть логической модели JPA подходит. Примером хорошей подгонки является @Embedded, @EmbeddedCollection и @Entity (это может быть node, документ или кеш, основанный на выбранном хранилище данных). По общему признанию, имена аннотаций могут быть странными, потому что вам также придется иметь дело с @Table и @Column.

• Сохранение рефератов JPA на уровне объектов, оставляя место для множества трюков и оптимизаций. У нас запланировано несколько идей, таких как сохранение полиглота: хранение данных в нескольких хранилищах данных и использование лучшего для конкретного задания на чтение.

Основной недостаток заключается в том, что некоторые из понятий JPA не легко отображаются в мир NoSQL: транзакции, например. Пока у вас будет доступ к методам демаркации транзакций, вы не сможете откатываться от хранилищ данных, которые не поддерживают транзакции изначально (транзакции в этом случае будут использоваться для группировки операций и оптимизации количества вызовов db).

Кроме того, если ваш набор данных по своей природе ориентирован не на модель, то Hibernate OGM не для вас.

Ответ 3

Можно просто пойти с SpringData. Если вы помните, Spring ORM также использует некоторые элементы JPA, такие как Entity, Transaction, и обеспечивает наилучшее сочетание элементов из JPA и Hibernate API a. Сообщество Spring позаботится о будущих версиях, если JPA станет более зрелой для NoSQL. Хотя это не главная причина. Большинство причин описаны @Oliver Drotbohm. Прочитайте дополнительную документацию по SprinData и проанализируйте свою модель данных, масштабируемость по непрерывности/росту хранилища данных, найдите наиболее подходящее для вашего решения решение и рассмотрите предложение, данное @Davide. Во многих случаях SpringData имеет большую вероятность успеха, чем JPA, при интеграции с MongoDB.