MongoDB的Spring Data MongoDB和Hibernate OGM有什么区别？

Question

我之前没有使用过Spring Data，但是我已经多次使用Hibernate ORM用于基于MySQL的应用程序。我只是不明白为基于MongoDB的应用程序在两者之间选择哪个框架。

我已经尝试寻找答案，但我找不到在生产环境中对两者进行比较的答案。有没有人发现使用MongoDB使用这两个框架有问题？

Answer 1

免责声明：我是Spring Data项目的负责人，因此我将主要介绍Spring Data方面的内容：

我认为这两个项目之间的核心区别在于Hibernate OGM团队选择围绕JPA集中精力，而Spring Data团队明确没有。原因如下：

• JPA是一种固有的关系API。规范状态的前两个句子，它是对象关系映射的API。这也体现在API的核心主题中：它讨论了表，列，连接，事务。不一定可以转移到NoSQL世界的概念。
• 您通常会选择NoSQL商店，因为它具有特殊的特性（例如MongoDB上的地理空间查询，能够为Neo4j执行图遍历）。它们都不是（并且将会）在JPA中可用，因此您无论如何都需要提供专有扩展。
• 更糟糕的是，如果JPA假定它们在像JPA中定义的NoSQL商店那样工作，那么它将简单地引导用户进入错误的方向：如何在MongoDB上合理地实现事务回滚？

因此，对于Spring Data，我们选择为受支持的存储提供一致的编程模型，但不要试图将所有内容强制转换为一个过度抽象的API：您获得了众所周知的模板实现，您获得了存储库抽象，这对于所有商店，但让你利用商店特定的功能和概念。

Answer 2

免责声明：我是Hibernate OGM开发人员之一，因此我将尝试提供其背后的一些原因。

Hibernate OGM为NoSQL解决方案提供Java持久性（JPA）支持。它重用了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不适合您。

Answer 3

可以使用SpringData。如果你还记得Spring ORM也使用了一些JPA的东西，比如Entity，Transaction，并提供了JPA和Hibernate API的最佳东西。如果JPA对NoSQL越来越成熟，Spring社区将在未来的版本中使用。虽然这不是主要原因。大多数原因都由@Oliver Drotbohm描述。阅读SprinData的更多文档，进一步分析您的数据模型，数据存储连续性/增长的可扩展性，找到最适合您的解决方案，并考虑@Davide给出的建议。很多情况下，与MongoDB集成时，SpringData的成功率要高于JPA。