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

Я не использовал данные Spring раньше, но я использовал Hibernate ORM несколько раз для приложения на основе MySQL. Я просто не понимаю, какую структуру выбрать между ними для приложения на основе MongoDB.

Я попытался найти ответ, но я не могу найти ответ, который делает сравнение между ними в производственной среде. Кто-нибудь обнаружил проблемы с работой с этими двумя фреймворками с MongoDB ?

2 ответов


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

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

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

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


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

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

этот подход интересен для нескольких причины:

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

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

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

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

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

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

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