利用开源的 Apache Solr 搜索引擎构建 RESTful 基础存储服务（2）

look_w

本文的目的本文对使用搜索引擎作为存储服务的思路的实现方法做了简单的分析，并基于开源的 Apache Solr 项目构建一个基础存储服务系统，在此基础上结合一个很简单的 BLOG 网站的例子对存储服务的结构和使用进行了说明。希望本文所探讨的思路能对那些迫切需要大规模、高扩展性存储服务的应用有所启发。
基于搜索引擎的基础存储服务为了说明基于搜索引擎的基础存储服务的构成，首先需要对搜索引擎的角色变化有所了解：
图 1. 传统的网络服务中搜索引擎扮演的角色传统的网络服务中搜索引擎仅仅对外提供检索服务，索引服务通过自动化的 Crawler 在后台完成，一般并不对外提供索引服务接口。
图 2. 在基础存储服务中扮演的角色：很显然，在基于搜索引擎的基础存储服务系统中，搜索引擎不再仅仅是接收检索请求返回检索结果，还可以接收存储请求（也就是索引服务）。索引服务不再隐藏在后台、仅仅通过 Crawler 来搜集信息，现在也可以接收外界存储的信息了。
存储系统的组织存储模式
基于搜索引擎的基础存储服务并不是基于结构化的概念，而是基于声明式的概念。基础存储服务使用 URL 来组织存储资源，因为 URL 对用户来说是隐藏的，因此用户使用基础存储服务的时候不用考虑以什么样的结构来存储数据，而是直接通知基础存储服务要存储什么样的数据。当然对于不同的搜索引擎来说，其所能接受的资源的格式通常是有差别的，例如本文中所使用的开源搜索引擎 Apache Solr，其能处理的资源为 XML 格式的文档，实际使用的时候需要将存储的资源变化为 XML 格式的文档来进行存储。本文附带的例子中包含有用于进行 Java 对象到 Solr XML 文档的变换代码，详细的处理逻辑请参考例子的代码。
基础存储服务内部的资源存储方式是类似于互联网信息的存储方式：分布式、且使用 URL 来标识实体之间的关联。显然这里的实体可以类比为互联网的页面。存储服务可定制，即可以定制将实体以任何形式存储在任何场所，如果以 Internet 中页面来进行类比，即将实体存在各个网站的各个页面中。但是这个结构对外是不暴露的，用户可以不必关心 URL 的信息。
分布式
分布式对于以搜索引擎为基础的存储服务系统来说是天然的，存储系统中标识一个资源的唯一标识符是资源的 URL，但是这个 URL 不同于一般意义上的 URL（这里叫 URL 仅仅是为了和存储服务的灵感来源—— Internet 进行统一，因为 Internet 中的资源是使用 URL 来定位的），存储服务的 URL 不包含地址信息，仅包含用于标识资源的信息。虽然 URL 不包含地址信息，但是基础存储服务依然可以根据 URL 的内容决定将资源的存储节点，但是存储在哪一个节点上是根据存储系统实际的部署的情况来确定。
扩展性
扩展性对于以搜索引擎为基础的存储服务系统来说也是天然的，因为用户使用存储服务的时候不用关心资源如何存储，另外因为分布式存储是通过资源的 URL 来进行区分，而 URL 却不包含地址信息，所以就像 Internet（可能 IPv4 会有所限制，但是 IPv6 就没问题了）一样，理论上，基于搜索引擎的基础存储服务是可以无限扩展的。
事务
本文中的 BLOG 网站的例子虽然应用了事务，但是，毫无疑问，直接利用搜索引擎的索引服务自身提供的简单事务管理功能是不足以满足作为一个存储系统时的事务管理需要的。如果要进行复杂系统的开发，需要定制搜索引擎的事务管理机制。因为本文的目的仅在于对使用搜索引擎作为存储服务的可能性做简单的分析和验证，关于如何定制事务管理的问题超出了本文的范围，所以这里不再赘述。
安全
同事务一样，关于安全的问题同样超出了本文的范围，所以这里不再赘述。
使用存储系统同组织 Internet 的资源的 URL 一样，基础存储系统最重要的方面就是资源的 URL 设计。在基础存储系统的 URL 设计思路中，主要参照了 REST 的原则。
RESTful 存储结构
什么是 REST ？ REST 定义了一组体系架构原则（例如：显式地使用 HTTP 方法、无状态、公开目录结构式的 URI、传输 XML、JSON，或同时传输这两者），您可以根据这些原则设计以系统资源为中心的 Web 服务，包括使用不同语言编写的客户端如何通过 HTTP 处理和传输资源状态。
为什么需要 REST ？在基础存储服务中，REST 原则应用在资源的 URL 设计上。虽然看起来 REST 和存储服务好像没有什么关系。但是前面已经说过，基于搜索引擎的基础存储服务实际上是将 Internet 倒转过来，也就是说原来搜索引擎仅用于检索的资源现在不仅用于检索，还用于提供存储服务，那么存储系统的结构就等同于 Internet 的结构了，因此应用 REST 的原则就顺理成章了。REST 原则在组织 Internet 资源中的意义是非常重要的，在基础存储服务中，REST 原则对 URL 设计同样也是极为重要的。
URL 的结构
基于搜索引擎的存储服务的处理依赖于资源的 URL 结构。在存储和检索资源的过程中，存储系统根据资源的 URL 来对资源进行组织，例如在存储的时候，可能会将 URL 相似的对象保存到同一个存储地址空间中（当然对用户来说这个问题是不需要考虑的，决定采用什么样的策略来保存资源是存储服务系统需要考虑的问题）；同样，在进行检索处理的过程中，也可能会在某一个 URL 空间内进行资源的检索，类似于使用 Google 搜索引擎检索的时候使用 site 关键字：solr site:apache.org。
在存储系统中有两种类型的资源：基础资源和附属资源，资源的类型是依照资源本身和其他关联资源的关联形式的不同加以区分（关于为何这样进行区分，参考后面的说明）。两种类型的资源的 URL 的结构是不同的：

• 基础资源，基础资源是指不附属于其他资源的资源。追加、更新和删除基础资源都需要以基础资源为单位来进行，追加、更新和删除其他资源的时候不会影响到基础资源的内容。基础资源的 URL 可以使用任意的形式构建。
• 附属资源，附属资源是指附属于其他资源的资源，附属资源的 URL 以其附属的基础资源的 URL 为基础构建。

基础资源和附属资源之所以使用不同的 URL 格式进行标识，这主要参考了面向对象方法论中对象之间关系的模式，基础存储服务使用这些模式来组织存储系统中的资源。例如：面向对象方法论中对象之间的关系主要有：has-a、contains-a 和 is-a 三种模式（其他的模式都可以划到这三种模式中），has-a 所关联的资源可以理解为基础资源，contains-a 所关联的资源可以理解为附属资源，这两种关联方式在本文的例子中都有所体现。但是 is-a 关系在本文的例子中没有体现，但是通过记录资源的类型信息可以很容易的实现 is-a 关系的存储和查询。
如何查询
毫无疑问，作为基础存储服务基础的搜索引擎所支持的查询方式，基础存储服务无疑都是支持的，例如基于 URL 的查询。除了这些基本的查询功能以外，还可以使用其他更为精确的查询方法，这依赖于具体的存储服务设计和具体的应用系统设计。
如何更新
更新过程类似于搜索引擎的索引处理。但是根据用于更新的资源和其关联资源的关联形式的不同，追加、更新和删除资源的时候其处理方式也是不同的：

• 追加资源，类似于关系数据库的插入处理。如果被追加的资源内部包含有其他附属资源，那么同样需要递归的追加附属资源；如果被追加的资源内部包含有其他基础资源，不做特殊处理。
• 更新资源，类似于关系数据的更新处理，同追加资源类似，如果被更新的资源内部包含有其他附属资源，那么同样需要递归的更新附属资源；如果被更新的资源内部包含有其他基础资源，不做特殊处理。
• 删除资源，类似于关系数据的删除处理，如果被删除的资源内部包含有其他附属资源，那么同样需要递归的删除附属资源；如果被更新的资源内部包含有其他基础资源，不做特殊处理。