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世界：例如事务。虽然您可以访问事务划分方法，但您将无法回滚本机不支持事务的数据存储（在这种情况下，事务将用于对操作进行分组并尝试优化对db）。

此外，如果您的数据集本质上是非域模型中心的，那么Hibernate OGM不适合您。

Answer 3

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