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不适合您.