终于清楚如何用读Lucene的索引 。本文要介绍一下如何利用IndexReader获取信息。为什么要读索引呢？因为我需要实现这些功能：
(1) 统计term在整个collection中的文档频度(document frequency, DF)；
(2) 统计term在整个collection中出现的词次(term frequency in whole collection)；
(3) 统计term在某个文档中出现的频度(term frequency, TF)；
(4) 列出term在某文档中出现的位置(position)；
(5) 整个collection中文档的个数；

那 么为什么要用到这些数据呢？这些数据是实现TR(Text Retrieval，文本检索)的必备的”原料”，而且是经过加工的。在检索之前，只有原始文本(raw data)；经过索引器(indexer)的处理之后，原始文本变成了一个一个的term(或者token)，然后被indexer纪录下来所在的位置、 出现的次数。有了这些数据，应用一些模型，就可以实现搜索引擎实现的功能――文本检索。

聪明的读 者您可能会说，这看起来似乎很好做，不过就是计数(count)么。不错，就是计数，或者说是统计。但是看似简单的过程，如果加上空间(内存容量)的限 制，就显得不那么简单了。假设如果每篇文档有100个term，每个term需要存储10字节信息，存1,000,000篇文档需要 10x100x10^6=10^9=2^30字节，也就是1GB。虽然现在1G内存不算什么，可是总不能把1GB的数据时时刻刻都放入内存吧。那么放入硬 盘好了，现在需要用数据的时候，再把1GB数据从硬盘搬到内存。OK，可以先去冲杯咖啡，回来在继续下面的操作。这是1,000,000的文档，如果更多 一点呢，现在没有任何辅助数据结构的方式，会导致很差的效率。

Lucene的索引会把数据分成 段，并且在需要的时候才读，不需要的时候就让数据乖乖地呆在硬盘上。Lucene本身是一个优秀的索引引擎，能够提供有效的索引和检索机制。文本的目的 是，介绍如用利用Lucene的API，如何从已经建好的索引的数据中读取需要的信息。至于Lucene如何使用，我会在后续的文章中逐渐介绍。

我们一步一步来看。这里建设已经有实现建好索引，存放在index目录下。好，要读索引，总得先生成一个读索引器(即Lucene中IndexReader的实例)。好，写下面的程序(程序为C#程序，本文使用DotLucene)。
IndexReader reader;
问 题出来了，IndexReader是一个abstract类，不能实例化。那好，换派生类试试看。找到IndexReader的两个孩子 ――SegmentReader和MultiReader。用哪个呢？无论是哪个都需要一大堆参数(我是颇费了周折才搞清楚它们的用途，后面再解释)，似 乎想用Lucene的索引数据不是那么容易啊。通过跟踪代码和查阅文档，我终于找到使用IndexReader的钥匙。原来IndexReader有一个 “工厂模式”的static interface――IndexReader.Open。定义如下：
#0001 public static IndexReader Open(System.String path)
#0002 public static IndexReader Open(System.IO.FileInfo path)
#0003 public static IndexReader Open(Directory directory)
#0004 private static IndexReader Open(Directory directory, bool closeDirectory)
其中有三个是public的接口，可供调用。打开一个索引，就是这么简单：
#0001 IndexReader reader = IndexReader.Open(index);

实际上，这个打开索引经历了这样的一个过程：
#0001 SegmentInfos infos = new SegmentInfos();
#0002 Directory directory = FSDirectory.GetDirectory(index, false);
#0003 infos.Read(directory);
#0004 bool closeDirectory = false;
#0005 if (infos.Count == 1)
#0006 {
#0007 // index is optimized
#0008 return new SegmentReader(infos, infos.Info(0), closeDirectory);
#0009 }
#0010 else
#0011 {
#0012 IndexReader[] readers = new IndexReader[infos.Count];
#0013 for (int i = 0; i < infos.Count; i++)
#0014 readers[i] = new SegmentReader(infos.Info(i));
#0015 return new MultiReader(directory, infos, closeDirectory, readers);
#0016 }

首 先要读入索引的段信息(segment information, #0001~#0003)，然后看一下有几个段：如果只有一个，那么可能是优化过的，直接读取这一个段就可以(#0008)；否则需要一次读入各个段 (#0013~#0014)，然后再拼成一个MultiReader(#0015)。打开索引文件的过程就是这样。

接下来我们要看看如何读取信息了。用下面这段代码来说明。
#0001 public static void PrintIndex(IndexReader reader)
#0002 {
#0003 //显示有多少个document
#0004 System.Console.WriteLine(reader + “tNumDocs = ” + reader.NumDocs());
#0005 for (int i = 0; i < reader.NumDocs(); i++)
#0006 {
#0007 System.Console.WriteLine(reader.Document(i));
#0008 }
#0009
#0010 //枚举term，获得<document, term freq, position* >信息
#0011 TermEnum termEnum = reader.Terms();
#0012 while (termEnum.Next())
#0013 {
#0014 System.Console.Write(termEnum.Term());
#0015 System.Console.WriteLine(“tDocFreq=” + termEnum.DocFreq());
#0016
#0017 TermPositions termPositions = reader.TermPositions(termEnum.Term());
#0018 int i = 0;
#0019 int j = 0;
#0020 while (termPositions.Next())
#0021 {
#0022 System.Console.WriteLine((i++) + “->” + ” DocNo:” + termPositions.Doc() + “, Freq:” + termPositions.Freq());
#0023 for (j = 0; j < termPositions.Freq(); j++)
#0024 System.Console.Write(“[" + termPositions.NextPosition() + "]“);
#0025 System.Console.WriteLine();
#0026 }
#0027
#0028 //直接获取 <term freq, document> 的信息
#0029 TermDocs termDocs = reader.TermDocs(termEnum.Term());
#0030 while (termDocs.Next())
#0031 {
#0032 System.Console.WriteLine((i++) + “->” + ” DocNo:” + termDocs.Doc() + “, Freq:” + termDocs.Freq());
#0033 }
#0034 }
#0035
#0036 // FieldInfos fieldInfos = reader.fieldInfos;
#0037 // FieldInfo pathFieldInfo = fieldInfos.FieldInfo(“path”);
#0038
#0039 //显示 term frequency vector
#0040 for (int i = 0; i < reader.NumDocs(); i++)
#0041 {
#0042 //对contents的token之后的term存于了TermFreqVector
#0043 TermFreqVector termFreqVector = reader.GetTermFreqVector(i, “contents”);
#0044
#0045 if (termFreqVector == null)
#0046 {
#0047 System.Console.WriteLine(“termFreqVector is null.”);
#0048 continue;
#0049 }
#0050
#0051 String fieldName = termFreqVector.GetField();
#0052 String[] terms = termFreqVector.GetTerms();
#0053 int[] frequences = termFreqVector.GetTermFrequencies();
#0054
#0055 System.Console.Write(“FieldName:” + fieldName);
#0056 for (int j = 0; j < terms.Length; j++)
#0057 {
#0058 System.Console.Write(“[" + terms[j] + “:” + frequences[j] + “]”);
#0059 }
#0060 System.Console.WriteLine();
#0061 }
#0062 System.Console.WriteLine();
#0063 }

#0004 计算document的个数
#0012~#0034 枚举collection中所有的term
其中#0017~#0026 枚举每个term在出现的document中的所有位置(第几个词，从1开始计数)；#0029~#0033 计算每个term出现在哪些文档和相应的出现频度(即DF和TF)。
#0036~#0037在reader是SegmentReader类型的情况下有效。
#0040~#0061可以快速的读取某篇文档中出现的term和相应的频度。但是这部分需要在建索引时，设置storeTermVector为true。比如
doc.Add(Field.Text(“contents”, reader, true));
其中的第三项即是。默认为false。

有了这些数据，就可以统计我需要的数据了。以后我会介绍如何建立索引，如何应用Lucene。

Lucene在用IndexReader打开索引的同时，允许用IndexWriter对该索引进行更新，但是IndexReader只能查询到open索引时所索引的文件或者说Document，要想查询新索引的Document，IndexReader必须调用reopen方法（该方法开销较小）。

IndexReader.isCurrent() 方法可以用于测试索引是否有更新。

摘要： Indri 动态文档索引的实现技术，支持在更新索引的同时处理用户在线查询请求。 文本搜索引擎曾被设计为针对固定的文档集合进行查询，对不少应用来说，这种机制工作得很好，然而对于诸于新闻，财经和桌面搜索而言，需要的是高效、经常性的更新索引。 以往支持动态文档集合的研究主要围绕增量索引方法，增量系统通过往已有的索引中追加大的文档集合来优化索引性能，但是不允许在增量索引的同时处理用户查询。 与以往的增量系统不同，Indri搜索引擎的最新版本支持动态文档集合，不需要通过加大文档集合大小来获取索引性能，同时Indri支持索引和查询的并发，允许用户在增量索引的同时进行查询。

1．介绍

尽管全文索引技术已经出现了几十年之久，但是直到互联网的出现，它才真正得到普及。现在，几乎每个互联网使用者都是搜索引擎用户，全文搜索技术被广泛地用于各种应用领域，如Web搜索，新闻搜索，以及时下流行的桌面搜索等。

搜索桌面（或硬盘）文件和e-mails对大多数信息检索系统而言是一个新的挑战。用户期望他们的e-mails即到即索引，文件在保存到磁盘的顷刻便被索引好。永远不要期望桌面搜索用户能忍受由于索引更新所带来的存储消耗。不管是祈祷还是咒骂，用户看到了全文搜索的好处，更为普遍的事实是人们越来越发现自己离不开搜索。

然后，更新一个全文索引是一个耗时的过程，现在的搜索引擎通过建立大量文档的倒排索引表来创建索引，一个倒排索引项包含一篇文章的无重复词语列表，以及这些词语的附加信息（如词语在文档中的位置，词性等）。一篇短小的包含100个左右不重复词语的文章，索引的时候需要更新100个倒排索引项。如果这些倒排索引是存储在磁盘上的话，更新操作将需要100次的磁盘寻址，在现有的硬件配置下，这需要一秒或更长的时间。当然，长文章耗时也越长。另外，一个随之而来的问题是，在更新索引的时候，搜索引擎是该让用户等待更新完成还是继续处理用户的查询请求呢？

Indri搜索引擎新的版本突破了上述限制。作为Lemur[1]项目研发的一部分，Indri支持结构化查询语言，采用语言建模方法[2]，同时为了满足问答系统的需要，Indri还支持对结构化文档不同域进行查询。Indri第一个版本没有加入对增量索引的支持，但在最新的版本中允许对单个文档进行真正的实时索引。

一个信息检索系统要处理动态的文档集合，需要解决三个关键问题。首先，要能快速地添加和删除集合中的文档，这里的快速取决于一个桌面搜索用户愿意花多长的时间来等待索引的完成，也就是说对于单个文档而言响应应该是瞬时的。其次，系统要允许查询在任何时候都能得到响应，即使是在新文档添加进文档集合的同时。另外，系统要实用，在索引和检索性能上比不支持动态文档集合的检索系统更具有竞争性。

在Indri最新版本中，我们通过引入如下设计原则来实现上述目标：

内存结构-为了避免读写磁盘，尽可能长地把数据调入内存。

加锁机制-系统在尽可能小的时间段内对数据进行加锁互斥。

只读结构-为了减少对互斥锁的依赖，系统引入只读数据结构。

后台I/O-系统采用后台线程来和低速设备进行交互，以提高索引操作性能。

多版本结构-如果一个耗时长的操作需要获取可能已经更新的数据，系统将维持此数据的多个版本来减少互斥锁的使用。

上述原则的具体运用将在文章后续部分进行详细介绍。

2．相关工作

数据库研究团体已经花了几十年时间来研究数据获取并发技术。Ramakrishnan和Gehrke提出了一个通用的数据库原则[3]，Gray和Reuter则进一步深入探讨了事务处理系统[4]。

尽管访问文档数据和访问数据库数据所遇到的问题类似，但它们之间仍然存在着显著的差别。在数据库系统中，用户特别关心的是数据的原子性，有一个经典得例子，一位银行顾客把d美元钱从一个储蓄户头转到一个支票账号，如果d美元先从储蓄户头减掉，那么这位顾客的总钱数就少了d美元；如果先往支票账号加入d美元，那么他的钱就凭空多了d美元。不管怎么样，在第一个账号改变的同时就会出现金额不一致的情况。于是，数据库中事件并发研究的一个主要任务就是确保数据库的一致性，即使是在系统操作失败的情况下也要如此。

在我们系统中可以确保文档的插入和删除是原子操作，没有用户会看到一个文档是部分被删除或者插入的。但我们不允许多个文档的插入和删除是原子的。既然文档之间很少像数据库中记录那样相互依赖，这就不会成为我们系统的主要限制。

虽然有上述的差异，我们仍然可以从数据库中得到借鉴。异步I/O和互斥技术被现代数据库系统广泛使用，我们也在索引系统中采用类似的多版本并发技术[5]。

信息检索研究团体没有忽略动态文档集合，他们把研究重点放在了增量系统上，这种系统通过一次性添加大批量文档到已有索引上来代替单个文档的高效添加。这种研究并没有考虑当更新索引时系统能否继续处理查询的问题。

Brown，Callan和Croft[6]研究了一种高效增量索引的方法。他们区别对待小于8k和大于8k的索引，当一个小的索引需要增大时，它将被拷贝到一个大的连续的倒排索引文件中。然而对于一个大的索引项则不需要移动，只需添加一个前向指针到新的存储段(segment)里面。这也使得倒排索引可以通过倒排索引文件串连起来。他们发现，当在7个簇中创建一个索引的时候，查询性能降低了6%。使用小的簇时代价偏高，在他们的模型中索引每簇大小为64M的文本所花的时间是索引每簇大小为1M的文本的8倍。

在最近的研究中，Lester，Zobel以及Williams[7]比较了三种索引策略：占位(in-place)，合并（re-merge）以及重构（rebuild）。除了没有对连接链表进行优化外，in-place策略类似Brown所采用的方法。所有的倒排索引连续存放，如果没有足够的空间写入新数据的时候，已有数据必须被拷贝到别的地方。在re-merge策略中，新的文档簇被创建到单独的索引中，然后和已经存在的索引进行合并。rebuild策略则对已经构建的索引弃之不顾，在原始文档的基础上重新构建索引。他们研究发现，re-merge策略是最高效的更新索引的方法。但是，他们没有像Brow，Callan和Croft所作的那样，对预分配(pre-allocation)策略之间和处理大索引策略之间的差异进行比较。

Lester，Zobel和Williams提到，在使用最小的文档簇(10个文档)的情况下，表现最好的索引策略(in-place策略)在大约7秒的时间内更新了1G的索引。相对于别的策略而言，这已经是非常快了，但是，对于单个文档的索引更新来说，这并不是个理想的策略。

本文描述的方法类似Lucene搜索引擎，正常情况下，就像传统的批量索引一样，Lucene以分段(segment)的方式把数据写入磁盘。一旦数据被写入段中，他们就可以被查询到，并且不需要进行段的合并。这和Brown，Callan和Croft的连接链表方法有点类似，只是，把数据写入簇(batch)中需要更多的开销。为了获得更好的性能，许多文档必须被写入磁盘的一个簇(batch)中。

如果需要快速的响应，Lucene提供一个RAMDirectory类在内存中创建索引。添加一个文档到RAMDirectory很快，因为不需要进行磁盘I/O操作。一个文档一加入RAMDirectory便可以通过一个叫做IndexWriter的对象进行查询。这也解决了文档簇对于小文档集合的问题。然而，对于大小大于机器内存的文档集合，内存索引方式将不再可用，数据必须被写入磁盘，并根据用户对索引数据的定位方式来决定，哪些数据需要驻留内存，哪些数据应该写入磁盘。

在我们的工作中，当需要对文档进行快速存取时，Indri使用内存索引而不是批量索引。当需要同时处理查询请求的时候，Indri会立即决定什么时候该合并索引，而什么时候该把数据写入磁盘。

3．策略

3.1 内存结构

Indri采用两种类型的索引：内存索引和磁盘索引。内存索引驻留内存，而磁盘索引则存储在磁盘上。两种索引都能够处理查询，但只有内存索引能添加新的文档。Indri的磁盘索引结构是固定不变的，可以删除，但不能修改。

大多数的信息检索系统在磁盘上为所有文档创建一个单独的索引，而Indri在创建索引的同时还会生成不同用途的索引文件，这里我们使用”索引库repository“来指代一个文档集合对应的索引及其相关数据结构。

当在文本集合上创建索引库的时候，Indri把当前文档索引到活动的内存索引中。只要一个索引库处在打开写模式，就存在一个活动的内存索引准备接收文档。对于小的文档集合，索引数据直到索引库需要关闭的时候才写入磁盘。数据写入的同时，一个新的内存索引被创建，作为新的活动索引使用。

用上述方法构建一个索引相当于多个检索系统同时工作。文档通常一次性加入内存索引结构，只有当达到了内存限制时才被写入磁盘。在批量系统中，磁盘和内存结构不能独立工作，索引需要经过后续处理才能用于系统查询。

因为构建许多小的索引比构建一个单独的大索引更加高效，所以在磁盘上维持许多单独的小索引要更加有利。大的索引只有在需要合并小索引的时候才会出现，为了尽可能快地向系统中添加文档，简单地生成小的索引更有优势[7]。

然而，从一个单独的大索引中查询比在众多小索引中寻觅要快的多，主要的原因在于磁盘寻址时间，查询所需要的大量的磁盘寻址和索引数目之间具有线性的关系。因此，重查询负载的情况下，Indri将通过合并索引的方式来减少磁盘索引数目。

3.2 加锁机制

为了满足系统快速响应的需求，Indri必须快速地处理查询和加入文档。Indri以前的版本已经是一个有效的批量系统，可以很容易地对数据结构进行加锁，但是这也容易使查询或文档插入被长时间阻塞。为了保持快速的响应，必须确保系统中互斥锁的使用是在很短的时间内。

我们通过只允许活动内存索引可变来减少互斥锁的加锁时间。除了一些caches外，内存索引是系统加锁时需要处理的唯一结构。而内存索引的大小是受可用内存大小限制的，它的全部内容都驻留在内存中，即算对于复杂的查询，内存索引的响应也相当快。当然，加锁时间也可以通过减少内存限制来降低。

互斥锁也需要向内存索引中添加新的文档，为了减少加锁时间，我们确保每个文档在上锁前是被解析过的，只有当单个文档被索引的时候才加锁，然后开锁以处理查询。大多数的网页和新闻文档可以在小于1/100秒的时间内索引好，查询处理需要等待的时间相应也就很短。

当处理查询的时候有新文档到来，系统又正好处于加锁状态，此时，系统将禁止磁盘I/O操作。这样可以显著减少主线程在持有互斥锁的情形下任务调度混乱。

3.3 只读结构

为了减少系统在处理大卷数据时互斥锁加锁的时间，我们设法让大部分数据保持不变，对于磁盘数据来说这是基本准则。如果磁盘数据不是只读的，那么线程之间就需要在进行磁盘I/O读写时进行加锁，这可能导致加锁时数据的高度不一致。

既然磁盘数据在写入后便不允许更改，对于读取数据来说就不用加锁。加锁策略让Indri可以充分利用多处理器系统来提高性能。大部分的查询代码路径(query code path)仅仅需要只读锁就可以了，也就是说查询处理是高度并行的，尽管它看起来似乎受到磁盘子系统的并行限制。另外，由于文本解析和索引可以同时进行，索引过程也具有可并行性。

3.4 后台I/O

如果I/O操作在查询和索引时候不能执行，就需要引入异步I /O。Indri通过一直运行如下两个线程来实现异步I/O操作：

RepositoryMaintenanceThread

RepositoryLoadThread

这两个线程和特定的Repository相关联，如果多于一个Repository被打开，每个repository均需要对应的这样一对线程相关联。

RepositoryLoadThread执行两项任务。一是为查询和新加入的文档载入统计数据，这种数据载入和Unix进程载入有些类似，线程标明在过去的1，5以及15分钟内处理的查询和添加的文档数目，以帮助系统决定何时该把内存数据写入磁盘。

RepositoryLoadThread的另一项任务是检查系统的内存使用情况。如果系统使用的内存超过用户限制的25％，RepositoryLoadThread将挂起所有文档索引线程直到内存占用降下来为止，这可以防止系统在大批量文档加入的时候崩溃。对于多数可能的实时程序，如新闻播报，系统的运行决不能超出内存限制。

RepositoryMaintenanceThread把索引写入磁盘，它是唯一能把索引数据写入磁盘，并可以从磁盘删除数据的线程，在这个线程中不需要复杂的加锁机制。该线程每分钟激活5次以检查系统当前内存占用量，如果系统使用了过多的内存，它就开始把内存数据写入磁盘。

如上所述，创建新的磁盘索引并不是总有好处，因为许多小的磁盘索引结构对于大的磁盘索引结构来说需要更多的查询时间。为此，索引库维护线程RepositoryMaintenaceThread在写磁盘之前检查查询和文档的载入情况，如果查询相对于文档载入量更大的话，维护线程将进行索引合并而不是往磁盘中写入一个新的索引。

3.5 多版本结构

Indri Repository可能包含多个索引，Indri维护一个称之为index_state的结构，这个结构持有指向当前索引库中所有索引的指针。索引数据在两种情况下被写入磁盘：

内存索引MemoryIndex已经达到了它的内存限制；

存在过多的内存索引MemoryIndex，他们需要进行合并。

在上述两种情况下，Indri把数据写入磁盘，这些数据可能已经以别的形式存在于系统中，因此index_state需要进行修改以反映数据是否被删除。

一个解决办法是对index_state结构的读写进行互斥，然而，这种方法也可能导致在重负载情况下系统性能低下。

考虑Indri是运行在一个并行系统中，并且用户正在进行复杂的查询，这些查询每个都需要10分钟的处理时间。假如用户在两个独立的线程中提交查询，系统中就总是有两份同样的查询在运行。如果这些查询以5分钟为时间片轮流执行，A线程分别在一个小时的0，10，20，30，40和50分钟时开始运行，而B线程则分别在5，15，25，35，45和55分钟时开始执行。在一个小时开始的时候，我们对index_state的写进行加锁，当在B线程处理完一个查询前，A线程不允许处理它的下一个的查询，于是一个处理器将有5分钟的空闲时间，这是我们不希望看到的。

为了避免上述情况的出现，Indri在同一时间维持多个index_state结构，所有新的任务（如新的查询，文档的加入）使用新的index_state结构，而旧的任务继续使用旧的index_state结构，当没有用户需要使用index_state的时候，它将被删除。

在上面的例子中，这意味着线程B在使用它旧的index_state结构完成它的查询处理的同时，线程A使用新的index_state结构开始处理它的下一个查询。当线程B处理完毕当前查询，旧的index_state将不在有用户使用，从而被删除掉。

4．删除文档

Indri支持删除标记。删除标记是一种弱删除方式，只是简单地隐藏文档对于用户的可见性，而不是真正的删除。文档对应的索引数据并不会真正从倒排链表，有向链表或者压缩集合中删除掉，也就是说文档中词语的计数仍然保留在语料统计数据库中。

假设我们有一个文档集合A，以及它的一个子集B，首先创建A的索引I，然后从I中删除B对应的索引。我们只是通过把文档集合A－B添加到I’来创建一个相似的索引I’。由于包含了文档集B的数据，索引I比索引I’需要占用更多的磁盘空间。进一步，因为I和I’对应的语料统计库稍有差别，当在这两个索引上进行查询时，查询结果也会有所不同。基于如上原因，当使用Indri进行搜索的时候要谨慎地使用文档删除特性。

尽管实际应用中，删除是个很有用的特性，但单纯的删除用处不大。删除往往被用于进行文档更新（删除旧的版本，插入新的版本）。对于桌面搜索或新闻搜索而言，经常需要更新已有文档的错误（或者过时）版本，这就显得尤为重要。

我们采用一个简单的位图来标记文档的删除，当一个文档需要删除，就为其设置对应的比特位，任何不在位图中的比特位均假设没有被设置。因此，如果没有文档被删除，位图文件将是一个空文件。这个文件会一直扩充直到最后一个比特位被设置为非0。

查询时，每个文档均要在打分前对照位图进行检查，只有没有被标记为删除的文档才能进行查询计分。

5．总结

Indri现在可以在小于1秒的短时间片内完成文档索引并立即用于查询，这使得高速、并发访问新索引的文档所付出的代价足够小，以至Indri不需要采用特殊的批量和增量模式。Indri可以每小时索引约15G的Web数据，包括压缩和存储每个原始文档。

在这种性能下，我们已经实现了适合新闻过滤以及桌面搜索应用的检索系统，我们相信这是第一个具有如此高性能的开源系统。

Copyright@戴维 2005.8 于北京

参考文献：

[1] Trevor Strohman, Donald Metzler, Howard Turtle, and W. Bruce Croft, Indri: A language model-based serach engine for complex queries, IA 2005: Proceedings of the 2nd International Conference on Intelligence Analysis (to appear), 2005.

[2] Donald Metzler, Victor Lavrenko, and W. Bruce Croft, Formal multiple-bernoulli models for language modeling, Proceedings of ACM SIGIR 2004, 2004, pp. 540-541.

[3] Raghu Ramakrishnan and Johannes Gehrke, Database management systems, McGraw-Hill Higher Education, 2000.

[4] Jim Gray and Andreas Reuter, Transaction processing: Concepts and techniques, Morgan Kaufmann, 1993.

[5] Philip A. Bernstein and Nathan Goodman, Multiversion concurrency control˙theory and algorithms, ACM Trans. Database Syst. 8 (1983), no. 4, 465-483.

[6] Eric W. Brown, Fast evaluation of structured queries for information retrieval,SIGIR’95:Proceedings of the 18th annual international ACM SIGIRconference onResearch and development in information retrieval (NewYork, NY, USA),ACM Press, 1995, pp. 30-38.

[7] Nicholas Lester, Justin Zobel, and Hugh E. Williams, In-place versus re-build versus re-merge: index maintenance strategies for text retrieval systems, Proceedings of the 27th conference on Australasian computer science, Australian Computer Society, Inc., 2004, pp. 15-23.

相关链接：
http://newhaven.lti.cs.cmu.edu/indri/

将133行的
return open(FSDirectory.getDirectory(path, false), true);
修改为
return open(new RAMDirectory( FSDirectory.getDirectory(path, false)), true);
这样就可以在查询的时候将所有索引一次加载到内存，查询响应时间即使是第一次查询，也会小于0.1秒，但仅适用于索引文档数量不超过200W个，并且平均的页面大小不超过10K，文献检索系统 ，这种方式尤其适合。
创建索引的时候也能够使用 RAMDirectory ， 比FSDirectory 要快很多 。

令一种方法：

FSDirectory directory = FSDirectory.getDirectory(args[0], false); 1

RAMDirectory directory = new RAMDirectory(args[0]); 2

用2代替1即可