开放源代码的全文检索引擎Lucene

四、             存储抽象

有了上面的知识，我们接下来来分析存储抽象部分，也就是org.apache.lucene.store包。存储抽象是唯一能够直接对索引文件存取的包，因此其主要目的是抽象出和平台文件系统无关的存储抽象，提供诸如目录服务（增、删文件）、输入流和输出流。在分析其实现之前，首先我们看一下UML^[22]图。

图 3.3 存储抽象实现UML图（一）

图 3.4 存储抽象实现UML图（二）

图 3.4 存储抽象实现UML图（三）

    图3.2到3.4展示了整个org.apache.lucene.store中主要的继承体系。共有三个抽象类定义：Directory、InputStream和OutputStrem，构成了一个完整的基于抽象文件系统的存取体系结构，在此基础上，实作出了两个实现品：（FSDirectory，FSInputStream，FSOutputStream）和（RAMDirectory，RAMInputStream和RAMOutputStream）。前者是以实际的文件系统做为基础实现的，后者则是建立在内存中的虚拟文件系统。前者主要用来永久的保存索引文件，后者的作用则在于索引操作时是在内存中建立小的索引，然后一次性的输出合并到文件中去，这一点我们在后面的索引逻辑部分能够看到。此外，还定以了org.apache.lucene.store.lock和org.apache.lucene.store.with两个辅助内部实现的类用在实现Directory方法的makeLock的时候，以在锁定索引读写之前来让客户程序做一些准备工作。

    （FSDirectory，FSInputStream，FSOutputStream）的内部实现依托于java语言中的io类库，只是简单的做了一个外部逻辑的包装。这当然要归功于java语言所提供的跨平台特性，同时也带了一些隐患：文件存取的效率提升需要依耐于文件类库的优化。如果需要继续优化文件存取的效率，应该还提供一个文件与目录的抽象，以根据各种文件系统或者文件类型来提供一个优化的机会。当然，这是应用开发者所不需要关系的问题。

    （RAMDirectory，RAMInputStream和RAMOutputStream）的内部实现就比较直接了，直接采用了虚拟的文件RAMFile类（定义于文件RAMDirectory.java中）来表示文件，目录则看作一个String与RAMFile对应的关联数组。RAMFile中采用数组来表示文件的存储空间。在此的基础上，完成各项操作的实现，就形成了基于内存的虚拟文件系统。因为在实际使用时，并不会牵涉到很大字节数量的文件，因此这种设计是简单直接的，也是高效率的。

    这部分的实现在理清楚继承体系后，相当的简单。因此接下来的部分，我们可以通过直接阅读源代码解决。接下来我们看看这个部分的源代码如何在实际中使用的。

    一般来说，我们使用的是抽象类提供的接口而不是实际的实现类本身。在实现类中一般都含有几个静态函数，比如createFile，它能够返回一个OutputStream接口，或者openFile，它能够返回一个InputStream接口，利用这些接口之中的方法，比如writeString，writeByte等等，我们就能够在抽象的层次上处理Lucene定义的数据类型的读写。简单的说，Lucene中存储抽象这部分设计时采用了工厂模式（Factory parttern）^[23]。我们利用静态类的方法也就是工厂来创建对象，返回接口，通过接口来执行操作。

五、             关于cLucene项目

这一部分详细的说明了Lucene系统中所采用的索引文件格式、一些基础类和存储抽象。接下来我们来叙述一下我们在项目cLucene中重新实现这些结构时候的一些考虑。

    cLucene彻底的遵守了Lucene所定义的索引文件格式，这是Lucene对于各个兼容系统的基本要求。在此基础上，cLucene系统和Lucene系统才能够共享索引文件数据。或者说，cLucene生成的索引文件和Lucene生成的索引文件完全等价。

    在基础类问题上，cLucene同样封装了类似的结构。我们同样列表描述，请和前面的表3.2与3.3对照比较。

表 3.4 基础类包cLucene::util

表 3.3 基础类包cLucene::document

    存储抽象的实现上，也同样是类似于java实现。由于我们采用了OpenTop库，因此同样得以借助其中对于文件系统抽象的ot::io包来解决文件系统问题。这部分问题与前面一样，存在优化的可能。在实现的类层次上、对外接口上，均与java版本的一样。