面向NoSQL数据存储的Hibernate对象映射

╰+攻爆jí腚メ 2022-10-01 04:40 147阅读 0赞

本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2011/07/hibernateogm

近日，Hibernate Validator、Hibernate Search等项目的开发者Emmanuel Bernard[宣布了Hibernate OGM][Hibernate OGM]。这个新框架的目标旨在通过[JPA][]为[NoSQL数据存储][NoSQL]提供一个公共的接口。OGM是Object Grid Mapping的缩写。

InfoQ有幸采访到了[Emmanuel Bernard][]以深入了解[Hibernate OGM][Hibernate OGM 1]以及它将要支持的NoSQL后端存储。Emmanuel说他们将从[Infinispan][]开始，因为团队之间能够更轻松地进行合作，但也将支持其他产品。Infinispan与Hibernate OGM都是JBoss创建的。Infinispan之所以成为第一选择是因为它的事务模型非常类似于关系数据库，可以很容易桥接JPA。

目前的Hibernate OGM尚处在萌芽期，但我们计划支持其他的NoSQL实现。比如说，[EhCache团队][EhCache]打算成为Hibernate OGM提供者，并且正在与Hibernate OGM团队协作以在必要的情况下为Hibernate OGM提供增强与抽象。Emmanuel提到很多人有兴趣为[MongoDB][]、[CouchDB][]与[Redis][]提供实现。他希望对这些产品的支持能够尽快出现，此外他还希望其他项目与个人能够加入进来以支持键/值存储、面向文档的数据库、面向列的数据库以及面向图的数据库。

你可以通过Infinispan，[Cassandra][]与[Voldemort][]将[Apache Lucene索引][Apache Lucene]存储到数据源中，与之类似，Hibernate OGM JP-QL引擎实现依赖于Lucene与[Hibernate Search][]，因此Hibernate OGM一开始采用这些产品也是自然而然的事情了。不提供这种支持的NoSQL数据存储需要通过不同的策略来实现查询。

InfoQ：对于熟悉JPA与[MySQL][]的开发者来说，上手Hibernate OGM与Infinispan困难么？其学习曲线如何呢？

> 非常简单！这也正是我们的目标所在。  
>   
> 他们的编程模型与语义完全相同。我这里所说的并不是类似于JPA的API。Hibernate OGM是个完整的JPA引擎。我们已经支持大多数映射及CRUD操作了（包括实体继承、关联等等）。如果你需要将使用 [Hibernate Core][]的JPA应用转换为Hibernate OGM，你需要按照如下步骤进行：  
> 
> 
> 1.  将Hibernate OGM jar及其依赖添加到应用中
> 2.  编辑persistence.xml并将提供者改为Hibernate OGM，删除JDBC之类的属性（比如JDBC驱动、方言及模式生成等），并添加对Infinispan配置文件的引用
> 3.  运行应用
> 
> [这是][Link 1]persistence.xml文件修改前后的一个示例。  
>   
> 就这些。目前的限制因素就是JP-QL。Alpha 2尚不支持JP-QL，下一版本（Alpha 3）将提供对简单JP-QL查询的支持。然而，如果你熟悉Hibernate Search，那么你就可以使用全文搜索了。  
>   
> 该项目最酷的地方就是我们重用了大多数的Hibernate Core以实现对JPA的CRUD支持，这样引擎的成熟性就可以保证了。这么做可以保证不会出现与JPA相关的Bug，如果出现了Bug，那也是来自于Hibernate Core。

InfoQ：何时应该使用JPA/RDBMS，何时又该使用JPA/NoSQL呢？这两者孰优孰劣该如何评判呢？

> 我不会不懂装懂的。坦白地说，整个业界都想搞清楚这个问题。那我就先班门弄斧了。首先，如果关系数据库能够满足项目的需求，那么就请继续使用。NoSQL是一套非常不同的工具，他们能够解决当前关系数据库引擎所无法解决的问题。面向图的数据库对于与图相关的查询很有帮助（告诉我住在巴黎的我朋友的朋友的朋友）。比如说，在对延迟与事务要求非常严格的情况下（同时数据量不太大）就可以使用数据网格。如果数据量是个重要的因素（比如说占据大量数据的记录），那么就可以使用BigTable。

Emmanuel又补充说使用JPA编程模型与选择使用NoSQL解决方案是正交的。JPA并不适合于所有的NoSQL场景。使用领域模型的应用与Hibernate OGM搭配得会很好。JPA/NoSQL的一个显而易见的用例就是去除关系数据库。如果Hibernate OGM能够让开发者[尝试并探索NoSQL解决方案][NoSQL 1]，那么它就是成功的。

InfoQ：就眼前来看，Hibernate OGM会支持哪些简单的查询呢？考虑到关系模型与大多数NoSQL数据存储存在不匹配的情况，那么你对JPA的支持能有多少呢？

> 我认为传统关系数据库与NoSQL数据存储之间的不匹配将会出现在如下两个大的领域中：  
> 
> 
> 1.  在事务与恢复模型中
> 2.  在关联数据的存储方式中（随后又会被访问）
> 
> 对于事务的差异来说，我认为Hibernate OGM不应该掩盖这种差异，而是要拥抱下面的事务模型并让用户知道它。其他的做法都是错误的，因为这会改变每一个NoSQL解决方案的本性。

Emmanuel继续说到，根据底层数据存储的不同，[钝化的实体][Link 2]与关联可能是不同的。他认为JPA的关系模型能够很自然地适应于众多的NoSQL存储。大家有疑问的不匹配问题并不是JPA的问题，因为JPA可以实现具有关联关系的两个实体拥有独立的生命周期，它可以拥有嵌入的对象，甚至是嵌入对象的集合，这非常类似于面向文档的模型。在Hibernate OGM中，该模式是由领域模型托管的，可以脱离实际的对象结构以适应无模式的数据存储。

InfoQ：[人们对Google App Engine的JPA支持的一个普遍的抱怨][Google App Engine_JPA]是与RDBMS上的JPA比起来，它有点强迫的味道，相似的地方则是它是与NoSQL存储打交道的JPA。对于熟悉JPA与RDBMS的开发者来说，学习Hibernate OGM会很容易么？你是否听说过使[用Google App Engine的JPA支持][Google App Engine_JPA 1]的开发者所发出的抱怨和遇到的问题？

> 我认为Google App Engine的JPA之痛是 [BigTable存储限制][BigTable]、查询引擎以及GAE/J团队的时间约束共同导致的结果。GAE/J团队的开发者们非常聪明，对于他们所取得的成果来说，团队的规模其实很小，他们不可能事事都做到最好。  
>   
> 在Hibernate OGM中（到目前为止），相对于不支持的特性来说，你会看到更多的性能限制（比如说在某些情况下过多的键查找）。当然，我们最初对JPA-QL的支持远达不到完美，人们对此需要忍耐一阵。我们的目标是让JPA开发者感到自然。也就是说，我们不会与底层NoSQL引擎的能力和强项背道而驰。

InfoQ：Hibernate OGM与[SQLFire][]相比如何呢？

> 我不会谈具体的细节，因为我也不太了解这个产品，但我可以简单说两句：  
> 
> 
> 1.  它只用于GemFire而不是NoSQL中立的（甚至是数据网格）
> 2.  它不开源
> 
> 在处理Hibernate OGM与Infinispan时，我们也打算支持JDBC。我们打算过一段时间再提供支持，但我发现了JPA以及更加抽象的层次（关联实体与嵌入式对象等等）。你可以将Hibernate OGM看作是反规范化的引擎，同时它又可以保持数据副本的一致性。这是个巨大的优势，可以优化你的数据访问模式。我们将提供一些声明的方式来对数据进行反规范化处理。这一点你是很难做到的，而在关系层次又是很自然的。

由于很多开发者在使用Hibernate和JPA，因此向Hibernate框架中添加对NoSQL的支持也是自然而然的事情。Hibernate OGM通过统一NoSQL实现的接口进一步推动了NoSQL的使用，但问题在于如何将对象映射、将JPA-QL转换为各种NoSQL实现。

**查看英文原文：**[Hibernate Object Mapping for NoSQL Datastores][]

[Hibernate OGM]: http://in.relation.to/Bloggers/HibernateOGMBirthAnnouncement
[JPA]: http://en.wikipedia.org/wiki/Java_Persistence_API
[NoSQL]: http://www.infoq.com/articles/nosql-in-the-enterprise
[Emmanuel Bernard]: http://www.emmanuelbernard.com/
[Hibernate OGM 1]: http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html_single/
[Infinispan]: http://www.jboss.org/infinispan
[EhCache]: http://ehcache.org/
[MongoDB]: http://www.mongodb.org/
[CouchDB]: http://couchdb.apache.org/
[Redis]: http://redis.io/
[Cassandra]: http://cassandra.apache.org/
[Voldemort]: http://project-voldemort.com/
[Apache Lucene]: http://lucene.apache.org/java/docs/index.html
[Hibernate Search]: http://www.hibernate.org/subprojects/search.html
[MySQL]: http://www.mysql.com/
[Hibernate Core]: http://www.hibernate.org/
[Link 1]: https://gist.github.com/1044781
[NoSQL 1]: http://highscalability.com/blog/2011/6/20/35-use-cases-for-choosing-your-next-nosql-database.html
[Link 2]: http://stackoverflow.com/questions/3715301/which-classes-are-cached-in-second-level-cache-in-hibernate
[Google App Engine_JPA]: http://blogs.oracle.com/pblaha/entry/buggy_jpa_support_in_google
[Google App Engine_JPA 1]: http://code.google.com/appengine/docs/java/datastore/jpa/overview.html
[BigTable]: http://labs.google.com/papers/bigtable.html
[SQLFire]: http://www.infoq.com/news/2011/06/VMware-vFabric-SQLFire
[Hibernate Object Mapping for NoSQL Datastores]: http://www.infoq.com/news/2011/07/hibernateogm