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

近日，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 实现。

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