Annotated Lucene(中文版)

Annotated Lucene 作者：naven

3           索引类关系图

下面逐个介绍与建立索引有关的一些类及它们的关系。 

3.1      org.apache.lucene.store.IndexWriter

一个IndexWriter对象只创建并维护一个索引。IndexWriter通过指定存放的目录（Directory）以及文档分析器（Analyzer）来构建，direcotry代表索引存储（resides）在哪里；analyzer表示如何来分析文档的内容；similarity用来规格化（normalize）文档，给文档算分（scoring）；IndexWriter类里还有一些SegmentInfos对象用于存储索引片段信息，以及发生故障回滚等。以下是它们的类图：

3.2       org.apache.lucene.store.Directory

一个Directory对象是一系列统一的文件列表（a flat list of files）。文件可以在它们被创建的时候一次写入，一旦文件被创建，它再次打开后只能用于读取（read）或者删除（delete）操作。并且同时在读取和写入的时候允许随机访问（random access）。

在这里并不直接使用Java I/O API，但是更确切地说，所有I/O操作都是通过这个API处理的。这使得读写操作方式更统一起来，如基于内存的索引（RAM-based indices）的实现（即RAMDirectory）、通过JDBC存储在数据库中的索引、将一个索引存储为一个文件的实现（即FSDirectory）。

Directory的锁机制是一个LockFactory的实例实现的，可以通过调用Directory实例的setLockFactory()方法来更改。

3.3       org.apache.lucene.store.FSDirectory

FSDirectory类直接实现Directory抽象类为一个包含文件的目录。目录锁的实现使用缺省的SimpleFSLockFactory，但是可以通过两种方式修改，即给getLockFactory()传入一个LockFactory实例，或者通过调用setLockFactory()方法明确制定LockFactory类。

目录将被缓存（cache）起来，对一个指定的符合规定的路径（canonical path）来说，同样的FSDirectory实例通常通过getDirectory()方法返回。这使得同步机制（synchronization）能对目录起作用。

3.4       org.apache.lucene.store.RAMDirectory

RAMDirectory类是一个驻留内存的（memory-resident）Directory抽象类的实现。目录锁的实现使用缺省的SingleInstanceLockFactory，但是可以通过setLockFactory()方法修改。

3.5       org.apache.lucene.store.IndexInput

IndexInput类是一个为了从一个目录（Directory）中读取文件的抽象基类，是一个随机访问（random-access）的输入流（input stream），用于所有Lucene读取Index的操作。BufferedIndexInput是一个实现了带缓冲的IndexInput的基础实现。

3.6       org.apache.lucene.store.IndexOutput

IndexOutput类是一个为了写入文件到一个目录（Directory）中的抽象基类，是一个随机访问（random-access）的输出流（output stream），用于所有Lucene写入Index的操作。BufferedIndexOutput是一个实现了带缓冲的IndexOutput的基础实现。RAMOuputStream是一个内存驻留（memory-resident）的IndexOutput的实现类。

3.7       org.apache.lucene.store.Analyzer

Analyzer类构建用于分析文本的TokenStream对象，因此（thus）它表示（represent）用于从文本中分解（extract）出组成索引的terms的一个规则器（policy）。典型的（typical）实现首先创建一个Tokenizer，它将那些从Reader对象中读取字符流（stream of characters）打碎为（break into）原始的Tokens（raw Tokens）。然后一个或更多的TokenFilters可以应用在这个Tokenizer的输出上。警告：你必须在你的子类（subclass）中覆写（override）定义在这个类中的其中一个方法，否则的话Analyzer将会进入一个无限循环（infinite loop）中。

3.8       org.apache.lucene.store.StandardAnalyzer

StandardAnalyzer类是使用一个English的stop words列表来进行tokenize分解出文本中word，使用StandardTokenizer类分解词，再加上StandardFilter以及LowerCaseFilter以及StopFilter这些过滤器进行处理的这样一个Analyzer类的实现。

3.9       org.apache.lucene.search.Similarity

Similarity类实现算分（scoring）的API，它的子类实现了检索算分的算法。DefaultSimilarity类是缺省的算分的实现，SimilarityDelegator类是用于委托算分（delegating scoring）的实现，在Query.getSimilarity(Searcher)}的实现里起作用，以便覆写（override）一个Searcher中Similarity实现类的仅有的确定方法（certain methods）。

查询q相对于文档d的分数与在文档和查询向量（query vectors）之间的余弦距离（cosing-distance）或者点乘积（dot-product）有关系（correlates to），文档和查询向量存于一个信息检索（Information Retrieval）的向量空间模型（Vector Space Model (VSM)）之中。一篇文档的向量与查询向量越接近（closer to），它的得分也越高（scored higher），这个分数按如下公式计算：

其中：

1.          tf(t in d)与term的出现次数（frequency）有关系（correlate to），定义为（defined as）term t在当前算分（currently scored）的文档d中出现（appear in）的次数（number of times）。对一个给定（gived）的term，那些出现此term的次数越多（more occurences）的文档将获得越高的分数（higher score）。缺省的tf(t in d)算法实现在DefaultSimilarity类中，公式如下：

2.          idf(t) 代表（stand for）反转文档频率（Inverse Document Frequency）。这个分数与反转（inverse of）的docFreq（出现过term t的文档数目）有关系。这个分数的意义是越不常出现（rarer）的term将为最后的总分贡献（contribution）更多的分数。缺省idff(t in d)算法实现在DefaultSimilarity类中，公式如下：

3.          coord(q,d) 是一个评分因子，基于（based on）有多少个查询terms在特定的文档（specified document）中被找到。通常（typically），一篇包含了越多的查询terms的文档将比另一篇包含更少查询terms的文档获得更高的分数。这是一个搜索时的因子（search time factor）是在搜索的时候起作用（in effect at search time），它在Similarity对象的coord(q,d)函数中计算。

4.          queryNorm(q)是一个修正因子（normalizing factor），用来使不同查询间的分数更可比较（comparable）。这个因子不影响文档的排名（ranking）（因为搜索排好序的文档（ranked document）会增加（multiplied）相同的因数（same factor）），更确切地说只是（but rather just）为了尝试（attempt to）使得不同查询条件（甚至不同索引（different indexes））之间更可比较性。这是一个搜索时的因子是在搜索的时候起作用，由Similarity对象计算。缺省queryNorm(q)算法实现在DefaultSimilarity类中，公式如下：

sumOfSquaredWeights（查询的terms）是由查询Weight对象计算的，例如一个布尔（boolean）条件查询的计算公式为：

5.          t.getBoost()是一个搜索时（search time）的代表查询q中的term t的boost数值，具体指定在（as specified in）查询的文本中（参见查询语法），或者由应用程序调用setBoost()来指定。需要注意的是实际上（really）没有一个直接（direct）的API来访问（accessing）一个多个term的查询（multi term query）中的一个term 的boost值，更确切地说（but rather），多个terms（multi terms）在一个查询里的表示形式（represent as）是多个TermQuery对象，所以查询里的一个term的boost值的访问是通过调用子查询（sub-query）的getBoost()方法实现的。

6.          norm(t,d)是提炼取得（encapsulate）一小部分boost值（在索引时间）和长度因子（length factor）：

ú            document boost – 在添加文档到索引之前通过调用doc.setBoost()来设置。

ú            Field boost – 在添加Field到文档之前通过调用field.setBoost()来设置。

ú            lengthNorm(field) – 在文档添加到索引的时候，根据（in accordance with）文档中该field的tokens数目计算得出，所以更短（shorter）的field会贡献更多的分数。lengthNorm是在索引的时候起作用，由Similarity类计算得出。

当一篇文档被添加到索引的时候，所有上面计算出的因子将相乘起来（multiplied）。如果文档拥有多个相同名字的fields（multiple fields with same name），所有这些fields的boost值也会被一起相乘起来（multiplied together）：

然而norm数值的结果在被存储（stored）之前被编码成（encoded as）一个单独的字节(single byte)。在检索的时候，这个norm字节值从索引目录（index directory）中读取出来，并解码回（decoded back）一个norm浮点数值（float value）。这个编/解码（encoding/decoding）行为，会缩减（reduce）索引的大小（index size），这得自于（come with）精度损耗的代价（price of precision loss）- 它不保证decode(encode(x))=x，举例来说decode(encode(0.89))=0.75。还有需要注意的是，检索的时候再修改评分（scoring）的这个norm部分已近太迟了，例如，为检索使用不同的Similarity。