近日，Hibernate Validator、Hibernate Search等项目的开发者Emmanuel Bernard宣布了Hibernate OGM。这个新框架的目标旨在通过JPA为NoSQL数据存储提供一个公共的接口。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提到很多人有兴趣为MongoDB、CouchDB与Redis提供实现。他希望对这些产品的支持能够尽快出现，此外他还希望其他项目与个人能够加入进来以支持键/值存储、面向文档的数据库、面向列的数据库以及面向图的数据库。

　　你可以通过Infinispan，Cassandra与Voldemort将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、运行应用

　　这是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实现。