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

注:作为业界成熟的ORM解决方案,hibernate对rdbms的支持非常成熟,而目前宣布对nosql的支持无疑对Java程序员是一个强心剂。面对如此多的nosql,如何管理后端的nosql成为了一个巨大的挑战,而hibernate将为我们解决这个问题。

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

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

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

你可以通过Infinispan,CassandraVoldemortApache 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. 运行应用

这是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解决方案,那么它就是成功的。

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

我认为传统关系数据库与NoSQL数据存储之间的不匹配将会出现在如下两个大的领域中:

  1. 在事务与恢复模型中
  2. 在关联数据的存储方式中(随后又会被访问)

对于事务的差异来说,我认为Hibernate OGM不应该掩盖这种差异,而是要拥抱下面的事务模型并让用户知道它。其他的做法都是错误的,因为这会改变每一个NoSQL解决方案的本性。

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

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

我认为Google App Engine的JPA之痛是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

anyShare赠人玫瑰,手有余香,分享知识,德艺双馨!
          

无觅相关文章插件,快速提升流量

分类 NoSQL杂谈 · tag