Question

尽管用 NoSQL 这个术语统称一系列的新型数据存储，但所有的这些存储都有不同的特性和使用场景。具有讽刺意味的是，正是这种缺失特性的特点（缺乏对运行 SQL 查询的支持）命名了这一系列数据库。由于这些存储的特征非常不同，所以它们的 Java 驱动要使用完全不同的 API 才能充分发挥其特性和功能。如果试图对这些差异进行抽象的话，就会失去每种 NoSQL 数据存储能带来的收益。图形数据库应该用来存储高度关联的数据；文件数据库应该存储树状以及聚合状的数据结构；如果需要类似缓存的功能和存取模式，那应该选择键/值（key/value）存储。

Java EE（企业版）领域通过 JPA 提供了持久化 API，这个 API 或许可以当作 NoSQL 数据库前端实现的候选方案。但是令人遗憾的是，规范的前两句话已经预示了这一点似乎不可能实现：

本文档是关于在 Java EE 和 Java SE 中管理持久化和对象/关系映射的 Java API 规范。这项成果的技术目标是为 Java 应用开发人员提供一个对象/关系映射机制，借助它可以使用域模型来管理关系型数据库。

这一主题在规范的后面有清晰的体现，它定义了与关系型持久化领域紧密关联的概念和 API。 @Table 注解对 NoSQL 数据库而言没有太大的意义， @Column 或 @JoinColumn 也是如此。在 MongoDB 这样的存储中如何实现事务 API 呢？要知道在这些环境中并没有提供跨多文档操作的事务语义。因此在 NoSQL 存储之上实现 JPA 层，最好采用一个基于配置文件的 API。

另一方面，所有 NoSQL 存储提供的特殊功能（地理空间功能、map-reduce 操作、图形遍历）都需要以专有的方式去实现，因为 JPA 并没有为它们提供抽象。因此我们可能会以“两边不讨好”（worst-of-both-world）的局面收场：有的部分可以通过 JPA 来实现，另外还需要使用专有的特性来重新启用与特定存储相关的功能。

上文排除了采用 JPA 作为这些存储的抽象 API 的可能性。Spring 生态系统中的各种项目为开发人员带来了高效率以及一致的编程模型，我们依然希望将其用于简化对 NoSQL 存储的使用。为此，Spring Data 团队发布了如下使命宣言：

针对 NoSQL 和关系型存储，Spring Data 提供了基于 Spring 的熟知且一致的编程模型，同时保留特定存储的特性和功能。

因此，我们决定采取略有不同的方法。不再试图以单一的 API 将所有存储抽象化。相反，Spring Data 项目对不同的存储实现都提供一致的编程模型，并使用了在 Spring 框架中大家已熟悉的模式和抽象。这样，在使用不同的存储时，会有一致的体验。