В чем разница между Spring Data MongoDB и Hibernate OGM для MongoDB?
Я раньше не использовал Spring Data, но несколько раз использовал Hibernate ORM для приложений на базе MySQL. Я просто не понимаю, какой фреймворк выбрать между двумя приложениями на базе MongoDB.
Я пытался найти ответ, но не могу найти ответ, который сравнивает их в производственной среде. Кто-нибудь сталкивался с проблемами работы с этими двумя фреймворками с MongoDB?
2 ответа
Отказ от ответственности: я являюсь руководителем проекта Spring Data, поэтому я в основном расскажу о стороне Spring Data:
Я думаю, что основное различие между этими двумя проектами состоит в том, что команда Hibernate OGM решила сосредоточить свои усилия на JPA, а команда Spring Data явно не сделала этого. Причины следующие:
- JPA по своей природе является реляционным API. Первые два предложения спецификации утверждают, что это API для объектно-реляционного отображения. Это также воплощено в основных темах API: оно говорит о таблицах, столбцах, объединениях, транзакциях. Концепции, которые не обязательно переносятся в мир NoSQL.
- Обычно вы выбираете хранилище NoSQL из-за его особых особенностей (например, геопространственные запросы в MongoDB, возможность выполнения обхода графа для Neo4j). Ни один из них не доступен (и не будет) в JPA, поэтому вам все равно нужно будет предоставить проприетарные расширения.
- Хуже того, в JPA реализованы концепции, которые будут просто направлять пользователей в неправильных направлениях, если они предполагают, что они работают в хранилище NoSQL, как они были определены в JPA: как должен быть разумно реализован откат транзакции поверх MongoDB?
Поэтому в Spring Data мы предпочли предоставить согласованную модель программирования для поддерживаемых хранилищ, но не пытаться объединить все в один чрезмерно абстрагирующий API: вы получаете хорошо известные реализации шаблонов, вы получаете абстракцию репозитория, которая работает идентично для все магазины, но давайте использовать возможности и особенности магазина.
Отказ от ответственности: я один из разработчиков Hibernate OGM, поэтому я постараюсь указать некоторые причины этого.
Hibernate OGM обеспечивает поддержку Java Persistence (JPA) для решений NoSQL. Он повторно использует движок Hibernate ORM, но сохраняет сущности в хранилище данных NoSQL вместо реляционной базы данных. Он также направлен на предоставление доступа к определенным функциям хранилища данных, когда JPA не подходит.
Этот подход интересен по нескольким причинам:
Известны семантика и API. Разработчики Java уже знакомы с JPA, это означает, что не нужно изучать API более низкого уровня. Он также поддерживает как HQL, так и нативные backend-запросы.
Поздний выбор бэкэнда. Выбор правильного NoSQL хранилища данных не тривиален. С Hibernate OGM вам не нужно переходить на конкретное NoSQL-решение, и вы сможете легко переключаться и тестировать разные бэкэнды.
Существующие инструменты и библиотеки. JPA и Hibernate ORM существуют уже давно, и вы сможете повторно использовать библиотеки и инструменты, которые их используют.
Большая часть JPA логическая модель подходит. Примером хорошей подгонки является
@Embedded,@EmbeddedCollectionа также@Entity(это может быть узел, документ или кэш на основе выбранного хранилища данных). Следует признать, что названия аннотаций могут быть странными, потому что вам также придется иметь дело с@Tableа также@Column,JPA абстрагирует постоянство на уровне объектов, оставляя место для множества хитростей и оптимизаций. У нас есть несколько запланированных идей, таких как сохранение полиглота: хранить данные в нескольких хранилищах данных и использовать лучшую для конкретной задачи чтения.
Основным недостатком является то, что некоторые концепции JPA не так просто сопоставить с миром NoSQL: например, транзакции. Хотя у вас будет доступ к методам разграничения транзакций, вы не сможете откатить хранилища данных, которые изначально не поддерживают транзакции (в этом случае транзакции будут использоваться для группировки операций и оптимизации числа вызовов для дБ).
Кроме того, если ваш набор данных по своей природе не ориентирован на доменную модель, то Hibernate OGM не для вас.
Можно просто использовать SpringData. Если вы помните, Spring ORM также использует некоторые вещи JPA, такие как Entity, Transaction, и обеспечивает наилучшее сочетание вещей из API JPA и Hibernate a. Сообщество Spring позаботится о будущих версиях, если JPA станет более зрелым для NoSQL. Хотя это не главная причина. Большинство причин описаны @Oliver Drotbohm. Прочтите дополнительную документацию по SprinData и проанализируйте свою модель данных, масштабируемость на непрерывность / рост хранилища данных, найдите наиболее подходящее для вашего решения и рассмотрите предложения, сделанные @Davide. Во многих случаях SpringData имеет больше успеха, чем JPA, при интеграции с MongoDB.