原文链接 http://opensearchlab.otago.ac.nz/paper_10.pdf
第一次翻译这样高级别的论文，有些地方采取了意译，特别是有些用词可能不够准确。
从这篇论文大概可以获取以下信息
1. 总体认识Lucene4 的新特性、新的结构和可扩展性。
2. 索引构建高性能为何 Lucene4 高并发无锁写索引
3. 各种自定义优化数据结构 Codec编码
4. 新的词典结构 有限自动机
5. 倒排压缩 各种先进的压缩算法
6.各种得分模型 向量到概率到统计到语言到信息模型
7.基于测试驱动
Apache Lucene 4
Andrzej Bialecki，Robert Muir，Grant Ingerosll Lucid Imagination
{adrezej.bialecki,Robert.muir,grant.ingersoll}@lucidimagination.com
译者 鹰缘 @淘宝 2012.12.15
摘要Apache Lucene是一个流行的、开源的搜索库，支持搜索的相关性和高性能。而且，Lucene经历了非常重要的变化过去几年，从一个个人项目到主流的搜索解决方案。Lucene已经被大量使用在移动设备、桌面搜索到网络访问解决方案。Lucene的发展非常迅速，尤其是当前发布的Lucene4.0. 这篇论文工作机制在Lucene的总体特征、社区开发模型、体系结构和实现，包括Lucene的索引和得分实现。
分类和子项目描述
H3.3 [信息搜索和检索]： 信息搜索和检索
通用词
算法 性能 设计 实验
关键词 信息检索 开源软件 Apache Lucene
1引言
Lucene是一个基于Java编程语言的开源软件包，提供应用编程接口来完成常规的搜索、查询相关的任务，例如索引构建，查询，高亮，分词等。Lucene 是由一批贡献者和源码提交者基于ASF运维的。完全基于比较广泛的组织、志愿者，通过Apache way方式合作起来。
今天，Lucene被广泛的使用，表现非常强大的搜索能力。在当今流行的网站、应用产品和设备，例如Twitter、Nefflix、Instagram 和其他的基于搜索的应用。Lucene同时嵌入到其他搜索服务中，例如Apache Solr 支持扩展性、可配置和基本服务架构就是基于Lucene。在论文写作期间，Lucene4.0正处在官方即将发布时期，可能在论文出版时已经发布。作为一个里程碑的发布版本，相比之前的Lucene版本，Lucene实现了大量的新特征并提升了效率。这篇文章讨论范围集中在Lucene4.0.
Lucene的主要功能集中在索引创建、维护和访问倒排索引。在第二部分将回顾Lucene的背景，第3部分介绍相关工作，Lucene4.0特征、结构、开源软件开发。第4部分提供一个更宽的视野看lcuene4.0. 第5部分更详细的分析Lcuene结构和功能，认识Lucene如何实现索引构建和查询功能。第6部分介绍Lucene的开源开发模式，以及如何直接成功地贡献代码到项目中。第7部分将提供一个原信息(第三方信息)，分析Lucene的性能，通过不同的搜索评价，例如TREC。最后第8、9 部分将总结这篇文章并展望Lcuene接下来的工作。
2 背景
最早在1997年Doug Cutting将Lucene作为自己学习Java的方法，后来贡献给ASF 2001的时候。Lucene有32个官方发布版本，包括最大、最小、补丁发布版。当前发布的版本中，截止文章撰写的时候是3.6.0。
早期Lucene实现的是不可修改的向量空间模型来支持增量索引更新。对于查询，Lucene最早发布在官方1.2，尽管从1.2版本起，Lucene已支持了多种查询类型，包括域值激励、通配符查询、模糊查询(使用leveshtein distance)、前缀搜索和布尔运算（AND OR NOT）。Lucene3.6继续支持上面所有查询特征，并且增加更多新的特性。例如，支持正则表达式搜索、复杂短语、空间距离和任意函数得分（基于域值），例如，使用时间戳或者价格作为得分因子[10].
更多关于Lucene3的总体特征可以参阅[15]。
经历了3年的时间，Lucene4.0吸收大量的前人系统和想法，不仅仅Lucene自身。Lucene支持很多新的相似度模型，后面将描述到。其他贡献者也修改了Lucene，BM25 和BM25F [16] 增加来了。在U . Amssterdam sweet spot similarity 和ILPS 已经容纳到语言模型，并加入到到Lucene[18]。 Lucene同时支持了大量新的抽象，逻辑层分离索引格式和相关数据结构，用Lucene术语称为 Codecs ，Codec和Xapian的核心理论相似。可以从存储层的Codec API获取更多细节。
3 相关工作
今天有大量的开源搜索引擎[30]表现不同特征集、性能特性和软件版本模型，Xapan[32] 是一个可裁剪的IR库，使用C++语言编写，支持概率检索模型。Lemur项目[33]是一个语言模型和信息检索工具集。Terrier IR 平台[34]是一个开源工具用于研究和实验，支持各种模型。MG4J 是一个全文检索引擎设计大规模文件集合。
4 Lucene4 特性
Lucene4.0 特性可以分为4大块，文本和查询的分词、索引和存储、搜索以及辅助模块等， 前三部分构成Lucene core，最后部分的代码是已经被证实非常有用，在解决搜索的具体相关问题，例如高亮。
4.1 语言分析
Lucene语言分析主要负责将待建索引的文本或者查询串，转换成合适的内部表示。建索引和查询阶段将使用到。在建索引阶段，分析器创建的词条被插入到Lcuene倒排索引中，而查询阶段词条创建，表示合适的查询需求。分析器处理过程3部分： 1）字符过滤，去掉变音字符； 2）分词； 3）词条过滤、词干提取、去停用词、n元表示。分析器更多的细节在下面Lucene文本模型中讲述。
4.2 索引构建和存储
Lucene索引构建和存储层主要有下面基本特征，更多细节将在体系结构及实现部分讨论。
。用户用于构建索引的文档，由一个或者多个包含文档内容的域组成。每个域或者分词，或者不分词（使用前面提到的分析器完成），特性如下：
。存储用户定义的文档
。无锁构建索引[20]
。准实时索引 当文档完成索引构建之后立即可以搜索
。分段索引并支持索引合并，合成策略可以配置[19]
。抽象不同的存储策略针对IO 存储 和倒排链表数据结构[36]
。支持添加和回滚事务
。支持不同词条、文档、分级统计，针对不同的得分模型[24]
4.3 查询
在查询端，Lucene支持多种查询实现，包括过滤、分页、 结果排序以及伪相关性反馈。Lucene支持超过50种不同查询表达，多种查询解析，提供的查询解析框架可以帮助开发编写自己的解析器[24]。更多信息关于查询讨论将下后面提供。
另外，Lucene4.0现在支持复杂的可拔插的得分模型[24]，由开发者自己重写的。并且附带了多种预定义模型，例如Lucene传统的向量空间模型VSM、 概率模型Okapi BM25[21]、语言模型[25]、基于信息和差异的随机模式[23]。
4.4 辅助特征
Lcuene的辅助模块由各种常见模块组成，支持不同搜索应用。这些贡献或者第三方包主要由代码组成，并且不是对所有人都有帮助，但是非常有用，对于一些具体应用。帮助包从主干中单独打包，并与主干共享版本号。当前有13中不同的模型，包括性能、结果高亮、切面、空间搜索、按关键词文档分组，例如按相同url收集在一起。文档路由（基于优化的常驻内存的单文档索引）、基于点的空间搜索和输入提示。
5 系统结构及实现
Lucene 在发展过程中，系统结构也在不断的改进，主要围绕可用性和高性能方面做了很多工作。这些工作进一步细化体现在：内存的使用效率、去掉同步。本部分将描述Lucene 基本的类，并阐述索引构建和查询是如何基于这些类来工作的。首先，请看图1 Lucene顶层结构图
5.1 主要组成
Lucene4.0主要有两大块组成，文本分析和有限自动机，二者将下后面章节讨论。
5.1.1 文本分析
文本分析链将域内容转为词条流(参考图3)。从文本分析链输出的词条表现为一个属性集合。除了主要的单词本身这个属性外，还包含词条的其他属性，例如词条位置、起点、终点偏移、词条类型、任意的payload值（字节数组保存的、每个词条位置均可以有一个的）、整形标志和应用自己定义的属性，例如搜索标签。
分析链由字符过滤器（用于过滤变音符号）、分词、词条过滤器（分词分出的词条做二次修改）。词条常用属性可以以每个term的bit形式传入处理链的下一步。
Lucene包含5种字符过滤器实现，18种分词策略和97中词条过滤，涵盖32种不同的语言[24] 。这些token 流执行不同的功能，例如按模式分词、按规则和词典分词（例如空格分词、正则表达式、中文、日文、韩文、ICU（international Component for Unicode 以下简称 ICU是一套稳定、成熟、功能强大、轻便易用和跨平台支持Unicode 的开发包）、 定义词条过滤、有效索引数值和日期（支持trie数字区间查询）、具体语言相关的词干分析、去停用词、创建新字符或者字层面的n元组合、标签（UIMA Unstructured Information Management applications http://uima.apache.org/ ）等。使用提供的模块或者常见的分析模块，就可以表达复杂的分析管道。
5.1.2 自动有限状态机
Lucene4.0极大地减少了内存使用相对之前的版本。内存部分的倒排索引使用有限状态机FST包实现。Lucene的FST包支持线性时间开销来构建最小自动机[38]， FST压缩[39]、递归查找、自动权重、并且API支持可以拔插的代数输出。同义词处理、日文分析、输入纠错、自动提示都是基于lucene 自动机包，未来会有进一步改进计划。
5.2 索引构建
Lucene使用经典的倒排结构，并支持每个文档邻近非倒排文本的存储。内存和持久数据使用不同的编码集，伴随的代价是影响了索引大小，付出了数据压缩和解压的性能代价。Lucene使用拔插机制支持数据编码，请查看Codec API 部分，其中索引存储格式的是DirectoryAPI。
增量更新同时支持，并且保持索引在额外的文件 （通常称为segment），能定期的合并更大的索引段，从而较少总的索引碎片数[19]
5.2.1 文档模型
文档模型在Lucene中以撇平的域链表形式出现，域中保存文档的真正内容。每个域由域名、内容、float权重（为了得分使用）和其他属性构成，属性依赖具体的域类型。域的属性联合起来决定域的内容处理方式和索引中的形态。在文档中可以存在相同域名的域，在索引构建阶段将按序处理。文本并不一定要有唯一标示（通常会有一个应用层的唯一id，用来查找）
，文档在索引构建过程中，内部会分配一个整形标示符。
5.2.2 域类型
更广义的来看，域的分类有两种类型，内容索引和内容保存。每一个域都属于其中一种或者二种类型。只有索引和存储的域才可以提交存储和构建索引，但是，只有存储域才可以返回回来，倒排数据可以通过相应的API访问。
以文本形式出现的索引域，首先传入文本分析管道，或者以最终的token流（包含属性）。
Token 流程然后执行倒排，添加到内存索引段中，内存索引段会定期刷磁盘和合并。根据域的属性定义，不同的词条属性例如位置、起点、终点偏移、每个位置的payload等可以存储在倒排数据中。可以取消位置信息而只保存词条在每个文档每个域中的词频[36]
当索引域需要创建和存储词频向量时候，词条流将构建更小的倒排结构，只由当前域内容组成（不分词）。词频向量是是每个文档的每个域独立构建。词频向量在执行文本高亮、相关性反馈、获取结果快照（匹配查询词条的文档块）时候非常有用
存储的域的典型使用场景：用于存储辅助的文档数据，他不被检索，但是获取时相当笨重，从另外的系统中读取。存储的域值以字节数组形式保存，可以通过更友好的API获取，例如UTF-8编码的字符串、数字、数组等，或者使用典型的API doc values 直接的存储，使用更优化的存储格式，例如强类型存储，每个文档每个域的权重（称为norms 典型的表示域的长度唯一因子，影响得分）
5.2.3 索引构建链
分析器输出的term流，包含了term的属性（term值、位置、偏移和payload值）添加到每个term的posting list中，参见图3。词条的值没有必要使用UTF-8字符串信息，在先前的版本中是使用的，4.0版本完全支持任意字节数组值作为词条，并可以使用常用的比较器定义这些词条的排序规则。
另外，在索引构建过程中，文档会分配内部文档唯一编号，这些编号是小的、有序整数（使用差值压缩有效的减少空间）。这些内部标示符是短暂的，相对于具体的索引段内有效。所以，在两个或者更多的段合并过程中（索引聚合）将改变内部编号。
5.3 增量索引更新
索引支持在线更新：增加文档、删除已经存储的文档，同时支持查询。索引追击作为一种常见的增量索引更新方式不需要修改已经出现的索引[19]。
当新的文档提交到索引中，每个域（前面描述过），将执行倒排和非倒排数据计算，构成一个新的内存索引段，参加图2，内存索引是压缩的格式（各种Coded ）。一旦定义的配置伐值达到了，例如文档总数、索引段字节大小，这些内存索引段就刷到持久存储中（使用Codec 和Directory 抽象方法）
5.3.1 IndexWriter 类
IndexWriter类是一个上层类用作索引更新，记录新的索引段和创建新的提交点，并且偶尔触发索引聚合（索引段合并）使用DocumentWriter线程池来创建新的内存索引段。
新的文档被添加到内存索引段然后刷到存储，定期的后端线性执行索引聚合（合并），聚合后的索引将减少总的索引段数量。
文档删除以查询的形式从索引中查询到文档然后删除。删除是积累的、作用到内存索引段在刷磁盘之前，同时记录在提交点上，这样就可以从已经刷出去的不可修改的索引中删除。
每一次刷磁盘操作或者索引聚合都创建新的提交点，记录在全局的索引结构中，使用二阶段提交。
每个提交点是由一组索引段和删除信息构成，提交点完整的反应索引在该提交点时刻的全部信息。内存索引刷到磁盘构成新的索引段，新索引段编码格式使用的配置的Codec实现。
在Lucene3.X 以及更早的索引段数据是不能修改的。例如包含删除的内容、域的归一化权重，这些影响了并发读写，任何修改索引操作需要加锁，从而不能打开索引直到更新完毕并且锁释放。
在Lucene4.0 索引段完全可以在写之后更新，表现多次更新已经存在的索引段或者新的删除列表来实现更新的。两种操作都形成新的提交点。通过两阶段提交之后，新的索引视图将可见。这种无锁支持读的同时并发更新，存在短时间内读到的视图依然是在当前最新提交点完成之前的索引视图。
5.3.2 IndexReader类
IndexReader类提供上层入口获取存储的域值、term向量和遍历倒排索引数据。IndexReader使用Codec API 检索和解码索引数据 参见图1
IndexReader 代表了某个时刻的索引视图。通常用户获取IndexReader要么通过提交点（此时所有的数据已经写入磁盘）或者直接的通过IndexWriter（准实时的快照，包含已经刷磁盘的索引和内存索引段）
前面已经提到，索引段是可以修改的，从而删除并不是真正从索引段中删除。实际上删除的文档保留了，当打开出现的索引段的时候，删除的文档以bitset形式存活（没有真正删除文档）。 这个bitset 然后枚举倒排链和存储域，在搜索到隐藏删除的文档时候。全局索引统计没有重新计算，所以会有轻微的错误（包括term倒排链表统计信息，因为包含了删除的文档信息）。为了性能考虑，文档删除真正删除在索引段的合并阶段，从而全局统计重新计算。
IndexReader API 遵循下面的构成形式：IndexReader代表了定义的提交点，管理一序列子reader，每个segment一个reader。复合后的reader在不同的时刻关联所有子reader，而子reader可以有效的表示各自的提交点视图。一个极端的例子就是Twitter搜索引擎，每个搜索选择获取一个新的indexReader[20]。
5.4 Codec API
在Lucene3.X 使用预定义编码算法（变成差值压缩），在Lucene4.0 所有部分的编码和压缩已经独立开来，归并到Codec API
新设计的Lucene体系结构，开发出的新库有非常多的改进，方便最新的倒排压缩算法实验。Codec API 允许完全定制所有数据的编码和写入对应的存储。例如，倒排和非倒排部分，如何解码，如何索引段合并。下面部分将介绍更多的细节关于倒排索引如何通过API实现。
5.4.1 倒排索引的4维视图
CodecAPI 实现了倒排索引以逻辑4思维表 形式进行遍历。4维如下：域、词条、文档、位置。一个类比，4维由行列组成，支持下一项获取、查找操作，支持从当前位置按行和单元位置检索。举例，假设当前位置 field f1 term t1，游标可以查找到倒排链表的文档d1，并且文档的t1 频率可以获取，也可以迭代获取连续性的位置信息、偏移、payload 在每个文档的位置。
高层抽象不仅直接支持多种评估策略，同时清晰地区分了如何组成数据结构和编码，这些概念封装在Codec实现中。
5.4.2 Lucene4.0 Codec
默认的Codec实现，一种可选的命名Lcuene40，使用组合的、非常经典的压缩算法和有针对性的选择策略，实现较好的平衡索引大小（关联磁盘IO寻道开销）和编码成本。面向字节编码目的是改善解压速度。例如，倒排链表数据使用可变字节差值编码，同时使用多层跳跃表，使用有序文档标号，交错文档id和位置数据[36] 。对于高频出现的短链表（根据Zipf定律） Codec采取脉冲策略，直接将倒排信息内链到词典里面[19] ，词典采取分块树（固定或者不固定大小）机制共享前缀增量和跳跃表。非倒排的数据使用不同的策略，例如，每个文档的强类型（固定数据类型或者事先明确数据类型的数据，例如基本的数值型 int long 等）数据直接使用固定长度、位对齐的压缩（类似参照系编码 Frame of reference），而常规的存储域内容不使用压缩（应用可以再在储之前压缩每个值）。
Lucene40 Codec在实践上提供了一个很好的平衡高性能构建索引和快速的执行查询。由于CodecAPI在倒排索引功能和数据格式细节之间界限清晰，如果默认的实现不是非常有效在lucene4.0，非常方便定制自己的数据格式。Lucene社区已经实践了多种先进的Codec，包括PForDelta、Simple9/16/24(二者都包在lucene4.0中) 和SEncoding[26]，并且在词典方面尝试使用新的结构，例如有限状态机。
CodecAPI 提供了运行时管理posting的读写。例如在线增删、分片、增加布隆过滤为了失败后快速查找 fail-fast 或者根据具体存储限制而改进。例如追加性的Codec 工作在追加性文件系统，例如Hadoop DFS。
5.4.3 Directory API
最后物理磁盘访问抽象为Directory API，提供非常简单的类似文件系统视图的持久存储。
Lucene directory基本属于撇平的文件集合，这些文件写一次，抽象层提供顺序或者随机访问，在读写文件时候。
这些抽象总体是足够的并且有限制的实现，基于java.io.File 、NIO缓存器、内存、分布式文件系统，例如Amazon s3 或者Hadoop HDFS ，NoSQL 的key-value 存储，甚至传统的SQL数据库。
5.5 搜索
Lucene主要搜索概念可以细分为几个领域，接下来将描述。Lucene的查询模型、查询评估、得分和普通查询扩展。首先介绍Lucene模式下的查询。
5.5.1 查询模型和类型
Lucene并没有针对某个语言特别加强实践。相反，使用查询对象用于搜索。多个查询组合成一个查询块去表达复杂查询，开发者可以构造直接的查询或者通过查询解析器来实现。
Lucene4.0查询类型包括词条查询、单个词查询具体的域、布尔查询（支持AND OR NOT、每个查询块可以使任意的查询条件）、前缀查询、严格的短语查询（坡度短语允许最大N个间隔词[40,41]、基于位置的查询，称为距离按Lucene的用语表述。允许表达更复杂的规则和邻近和相关位置词条；通配符查询、模糊查询、正则表达式查询（使用有限状态机来计算匹配的词条）；最大吸取查询disjunction –max，指定得分基于文档最佳匹配，当查询跨多个域的时候。
Payload 查询支持处理每个term 位置的payload数据等。 Lucene同时支持多个域联合来计算得分，称为函数查询，当增加得分因子例如时间和距离到得分模型中，这些查询非常有用。
这些预定义的丰富查询集合允许开发者构建复杂的查询，从而获取最佳匹配和最好得分的文档，以一种良好的树形结构来表示所有子查询单元。
典型的一个查询是通过查询解析器转换为查询树，这不是强制性的，查询是可以通过编程来生成和合并的。Lucene 附带了大量不同的核心解析器。一些事基于JavaCC语法，一些事基于XML的。 更多的查询解析器细节和框架超出了本文的重点。
5.5.2 查询评估
当一个查询执行了，每个倒排索引段顺序处理因为效率：没有必要执行倒排链表的合并。对于每个索引段，查询生成一个得分器对象：基本上是遍历或者迭代匹配的文档通过score 方法。
得分器对象典型的计算得分基于DAAT策略（通俗说就是获取文档对象立即计算该文档的得分），尽管通常有时使用布尔得分器使用TAAT策略（每个term 一个得分）当词条数量比较少的时候[27]。
得分器在查询树种典型的位于叶子节点，通过传入原始索引的统计信息，例如词频来计算相似度。相似度是可以配置的对于词条评分。得分器更上一层通常操作子得分器，例如吸取得分就计算他的所有孩子的得分。
最后，收集器负责负责消费这些得分器并生成最终结果。例如，注入一个优先级队列，查询topN 文档[42]。 开发者可以实现自己的收集器用于高级需求的场景，例如提前终止查询，切面facet 和相似结果分组等。
5.5.3 相似度对象
相似度对象方法实现了按词条和查询单元计算得分：词条、全局索引统计信息、特殊的查询（例如短语查询的词条距离 多词条查询匹配的词条数 模糊查询的Levenshtein距离http://en.wikipedia.org/wiki/Levenshtein_distance ）一起参入计算得分。Lucene 4 现在维护了几个相对单个索引段范围内的统计信息（例如总的词频，唯一词条数，所有词条的文档频率总和等）支持其他的得分模型。
作为构建索引链中的一个环节，得分相似度负责计算域的归一化因子（权重）真正依赖域的长度和任意用户定义的域激励(域的长度是指域的词条数目，而不是词条的文本字节长度或者字符长度) 。Similarity类主要角色是定义查询得分细节在查询执行过程中。
前面已经提及，lucene4 提供了多种相似度实现，提供非常好的得分模型： TF/IDF 支持多个不同的、归一化因子，BM 25 best match25模型、信息模式、基于随机分布模型，语言模型.
5.5.4 普通查询扩展
关键词搜索仅仅是查询执行的一部分对于现代搜索引擎系统来讲。Lucene 提供了查询扩展的功能，支持简单的搜索导航，Facet 模块可实现浏览和下拉，这个在很多电子商务应用中出现，结果分组实现结果的聚合（在一些websit上已经出现）而且查询模型支持嵌套文档，查询扩展，地理搜索。
6 开业软件运作
Lucene的开发由一个广泛的贡献者、一部分核心提交者（基于ASF协议下能够修改Lucene源码的开发者）共同完成。这个过程的核心是任人唯才，贡献者持续的获取源码和文档，持续定期的提交优秀的改进补丁，然后在Lucene项目管理委员会内部投票决定，贡献者提交的代码和文档那些被吸收[3]。
整个开发过程以松散的开发者联盟形式通过邮件列表进行，并且记录软件过程中的问题，也有IRC频道和偶尔的面对面会议。所有的提交者选举某人的改进代码，这个是不会发生的，在实践中遵循上面提到的协议机制（基于贡献和选择性加入lucene中）。项目计划非常轻量，几乎总是通过patch 代码补丁来演示需求的特性是否可行。相对抽象的讨论，潜在的可实现性更为重要。版本发布通常是社区选择（一些志愿者来完成）协调者来管理发布，社区的其他人员校验发布的点，然后投票发布那些必要的包。Lucene开发者一直坚持确保版本向后兼容（重要的变动，知道的话都会写入文档）保证所有主要版本更新能消费最近的最小版本索引，尽量减少升级成本。
Lucene开发者经常面临需要平衡速度、索引大小、内存开销的矛盾。自从Lucene使用到许多严格的环境 Twitter，例如处理 截止2.11 秋，250 0000000 tweets and几十亿的请求每天。 所有的查询平均延迟50毫秒或更少[20]，例如 lucene40 默认Codec使用相对简单的压缩算法平衡索引空间和速度，域归一化因子使用浮点值全部转为使用单字节，牺牲了精度但是极大节省了存储空间。更多的数据结构，例如词典和倒排链表通常设计跳跃表，并缓存在内存，而主要数据分块检索，这个过程中没有缓存，依赖磁盘操作系统的有效的LRU缓存。
工程师拥有lucene最佳实践经验，从Lucene 2、 3 和lucene4，已经表现非常巨大市场需求。在最佳实践的核心是测试驱动的开发设计，确保正确性和性能。举例，Lucene已经拥有广泛的测试用例 2012/1/7lucene测试覆盖79%，实例运行链接
http://builds.apache.org/job/lucene-trunk/clover/ 分支标记能力设计用来推动Lucene的稳定向前，同时保留缺陷在相应的版本里面。
所有的测试由测试框架驱动，支持工业标准的单元测试，但是也出现了集中随机测试。前面的方法只要用于测试常规操作，而后者（定期的每天运行lucene连续集成的系统）主要设计用于获取边界案例超出了开发的访问。
由于Lucene支持拔插，随机编译，然后运行测试单元没有覆盖许多边界条件。因为太笨重对于开发者来执行。举例，某个测试运行随机Codec 用到，查询类型，本地，字符编码 ，内存数量子系统的等等。后期的相同的测试重复运行可能采取一个不同的合并实现。最后 Lucene 也有一套测试用于大规模索引、检索工作。这些测试结果会持续跟踪，确保提供更好的决策，融合新的特性、修改已经实现的技术[24]
7 相关性评测
在论文撰写时候，作者并不知道很多Trec 类型的评估针对luene4 （论文撰写时候官方4.0版本还没有发布），但是Lucene 已经被使用在过去的Trec参赛中。 而且，由于存在版权限制，在使用一些Trec 类型的数据评估相关性。对与开业软件像lucene，有效的、 公开评估自身使用方法，非常困难的，社区不能依赖和公开地获取这些内容和重复生成结果。
这就某种程度微妙，并不是技术上不知道如何运行trec 类型评估，而是没有可靠的方式分发内容给社区任何需要的人愿意测试。例如，注册并同意协议http://lemurproject.org/clueveb09/organization_agreement.clueweb09.worder.Jun28-12.pdf 并因此变为非公开的过程，对于社区来说就是这样。又例如，假设贡献者A已经付费Trce数据集，并且做了改进针对Lucene，改进了精准通过统计的方法获取，并且提交一个patch。但是，对于贡献者B，没有访问相同的内容，重新生成结果或者验证或者拒绝这个贡献。 [28] 深入讨论了这个问题。社区里面一些人已经尝试克服上面的问题，启动一个开源相关性项目
http://lucene.apache.org/openrelevance ,但是没有获得发展和跟进。因此，社区里面的每个人只能在自己的公司里面访问数据、执行评估和贡献结果到社区里面。毕竟大部分开发者集中在实现搜索应用，需要公开的trec的并不多见。作者意识到Lucene 对应IR研究领域来说，还有很大的距离，这些距离也正是作者们希望改善的，在未来通过与研究社区更加紧密的合作来缩小距离。
在过去，一些独立团体个人已经使用TREC类型数据评估。[17]基于修改的2.3.0使用100w查询评测，[29]未修改的lucene3.0，包含查询扩展技术，使用trec 2011 Medical Track。 [30]
Lucene 1.9.1 广泛的比较，对比各种开源的搜索引擎的默认实现功能。Lucene的boost 和协调因子影响tf/itf评分被研究了[43]。 许多研究者使用Lucene作为基准，例如 [44] 一个用来实验和实例实现标准的IR 算法。例如[45] 使用lucene2.4.0 采取”out of box” 配置，尽管还不清楚作者是如何定义lucene的这个配置的，因为社区从没有这样定义过。
8 未来工作
开源软件的一个特性就是未来没有确切的工作计划。（patch welcome 不仅仅是一个口号，并且是一个开发方式。社区经常活跃起来，在提出新的方案和改进质量的时候，而这些信息在其他地方没有看到）。总的来说，在文章撰写的时候，未来工作集中：1）确定4.0 API 和开源发布问题，2） 增加倒排链表的压缩算法 例如PRFOR，3）域层面的更新或者至少可以更新某些类型的域，例如doc-values 和元数据域，4）继续提升相关性例如结果合并、分组、切面、输入提示和空间搜索能力。同时，对现有代码的清理和重构从而更加好理解也一直进行下去。
Lucene的未来同样重要的lucene代码，来源社区。社区Lucene是非常重要的组成部分，在构建和维护Lucene，例如持续更新最新的算法和数据结构有非常重要的角色。
9 结论
在这篇论文中，站在Lucene历史视觉和细节来描述Lucene的各个模块。这些特征已使得Lucene成为现代基于搜索的企业级应用的重要一部分。这些组件已经超出了代码和测试驱动开发方法，在更大范围、开源、联合工作，使得Lucene 更好发展基于ASF协议。
在深层上，Lucene4 标志着一个非常重要的起点对应lucene发展历程来说。通过大改Lucene核心，使得Lucene更加灵活、可拔插、极大提升效率和性能。Lucene在商业应用上获得了持续的成功，同时也更好的适应于实验研究工作。
10 感谢
作者希望感谢过去所有使用和贡献Lucene 项目的人们，特别感谢Doug cutting，Lucene的始作者。我们也希望感谢所有项目提交者，没有他们就没有Lucene。 Andrzej Bialecki,Bill Au, Michael Busch, Doron Cohen ,Doug Cutting, James Dyer, Shai Erera, Erick Ericksion, Otis Gospodnetic, Adrien Grand, Martijin van Groningern, Erik Hatcher,Mark Harwood, Chris Hostetter, Jan Hoydahl, Grant Ingersoll, Mike McCandless, Ryan McKinley, Chris Male,Bernhard Messer, Mark Miller,Christian Moen, Robert Muir, Stanishlaw Osinski, Noble Paul,Steven Rowe,Uwe Schindler, Shalin Shekhar Manger,Yonik Seeley,Koji Sekiguchi, Sami Siren, David Smiley, Tommaso Teofili, Andi Vaida,Dawid Weiss,Simon Willnauer,Stefan Matheis,Josh Bloch, Peter Carlson, Tal Dayan, Bertrand Delacretaz,Scott Ganyo, Brian Goetz, Christoph Goller, Eugene Gluzberg,Wolfgang Hoschek,Cory Hubert, Ted Husted Tim Jones, Mike Klaas,Dave Kor,Daniel Naber,Patrick O’Leary, Andreww C.Oliver,Dmitry Serbrennikov,Jon Stevens,Matt Tucker,Karl Wettin.
11 参考文献
[1] The Apache Software Foundation The Apache Software Foundation .2012 .Accessed 6/23/2012 .http://www.apache.org
[2] Apache License, Version 2.0 The Apache Software Foundation. Januaray 2004. Accessed 6/23/2012http://www.apache.org/licenses/LICENESE-2.0
[3]How it Works. The Apache Software Foundataion Circa 2012. Accessed 6/24/1012http://www.apache.org/foundation/how-it-waroks.html
[4]Interveiw with Walter Underwood of Netflix. Lucid Imagination. May 2009. Access 6/23/2012
[5] Instagram Engineering Blog. Instagram. January 2012. Accessed 6/23/2012.http://instagram.engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances-dozens-of
[6] Lucene Powered By Wiki. The Apache Software Foundataion Various. Accessed 6/23/2012http://wiki.apache.org/lucene-java/PoweredBy/
[7]Apache Solr. The Apache Software Foundation Accessed 6/23/2012 http://lucene.apache.org/solr
[8]Interview with Doug Cutting. Lucid Imagination .circa 2008 Accessed 6/23/1012
http://www.lucidimagination.com/devzone/videos-podcasts/podcats/intervide-doug-cutting
[9]Apache Subversion Initial Lucene Revision. The Apache Software Fundation 9/18/2001. Accessed 6/23/2012
http://svn.apache.org/viewvc?view=revision&revision=149570
[10] Apache Subversion Lucene Source Code Repository. The Apache Software Foundation. various. Accessed 6/23/2012.
http://svn.apache.org/repos/asf/lucene/java/tags/
[11] Apache Subversion Lucene Source Code Repository. The Apache Software Foundation. various. Accessed 6/23/2012.
http://svn.apache.org/repos/asf/lucene/dev/tags/
[12] D. Cutting, J. Pedersen, and P. K. Halvorsen, “An object-oriented architecture for text retrieval,” In Conference Proceedings of RIAO'91, Intelligent Text and Image Handling, 1991.
[13] Levenshtein VI (1966)."Binary codes capable of correcting deletions, insertions, and reversals". Soviet Physics Doklady 10:707–10.
[14] Lucene 1.2 Source Code. The Apache Software Foundation. Circa 2001. Accessed 6/23/2012.http://svn.apache.org/repos/asf/lucene/java/tags/lucene_1_2_final/
[15] E. Hatcher, O. Gospodnetic, and M. McCandless. Lucene in Action.Manning, 2nd revised edition. edition, 8 2010.
[16] J. Pérez-Iglesias, J. R. Pérez-Agüera, V. Fresno, and Y. Z. Feinstein,
“Integrating the Probabilistic Models BM25/BM25F into Lucene,”arXiv.org, vol. cs.IR. 26-Nov.-2009.
[17] D. Cohen, E. Amitay, and D. Carmel, “Lucene and Juru at Trec 2007: 1-million queries track,” Proc. of the 16th Text Retrieval Conference, 2007.
[18] A Language Modeling Extension for Lucene. Information and Language Processing Systems. Accessed 6/30/2012. http://ilps.science.uva.nl/resources/lm-lucene
[19] D. Cutting and J. Pedersen. 1989. Optimization for dynamic inverted index maintenance. In Proceedings of the 13th annual international ACM SIGIR conference on Research and development in information retrieval_r(SIGIR '90), Jean-Luc Vidick (Ed.). ACM,New York, NY, USA, 405-411.
[20] M. Busch, K. Gade, B. Larson, P. Lok, S. Luckenbill, and J. Lin,“Earlybird: Real-Time Search at Twitter.”
[21] S. Robertson, S. Walker, and S. Jones, “Okapi at TREC-3,” NIST SPECIAL 1995.
[22] Stephane Clinchant and Eric Gaussier. 2010. Information-based models for ad hoc IR. In Proceeding of the 33rd international ACM SIGIR conference on Research and development in information retrieval_r(SIGIR '10). ACM, New York, NY, USA, 234-241
[23] G. Amati and C. J. Van Rijsbergen, “Probabilistic models of information retrieval based on measuring the divergence from randomness,” ACM Transactions on Information Systems (TOIS),vol. 20, no. 4, pp. 357–389, 2002.
[24] Lucene Trunk Source Code. Revision 1353303. The Apache Software Foundation. 2012. Accessed 6/24/2012.
http://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/
[25] C. Zhai and J. Lafferty, “A study of smoothing methods for language
models applied to ad hoc information retrieval,” Proceedings of the 24th annual international ACM SIGIR conference on Research and development in information retrieval, pp. 334–342, 2001.
[26] Fabrizio Silvestri and Rossano Venturini. 2010. VSEncoding: efficient coding and fast decoding of integer lists via dynamic programming. In Proceedings of the 19th ACM international conference on Information and knowledge management (CIKM '10).
[27] Douglass R. Cutting and Jan O. Pedersen, Space Optimizations for Total Ranking, Proceedings of RAIO'97, Computer-Assisted Information Searching on Internet, Quebec, Canada, June 1997, pp.401-412.
[28] TREC Collection, NIST and Lucene. Apache Lucene Public Mail Archives. Aug. 2007. Accessed 6/30/2012.
[29] B. King, L. Wang, I. Provalov, and J. Zhou, “Cengage Learning at TREC 2011 Medical Track,” Proceedings of TREC, 2011.
[30] C. Middleton and R. Baeza-Yates, “A comparison of open source search engines,” 2007.
[31] C. J. van Rijsbergen. Information Retrieval, 2nd edition. 1979, Butterworths
[32] The Xapian Project. Accessed 7/2/2012. http://www.xapian.org
[33] The Lemur Project. CIIR. Accessed 7/2/2012. http://www.lemurproject.org
[34] Terrier IR Platform. Univ. of Glasgow. Accessed 7/2/2012.
[35] P. Boldi, “MG4J at TREC 2005,” …Text REtrieval Conference(TREC 2005). 2005.
[36] V. Anh, A. Moffat. Structured index organizations for highthroughput text querying. String Processing and Information Retrieval, 304–315, 2006.
[37] G. Salton, E. A. Fox, and H. Wu. Extended Boolean information retrieval. Commun. ACM 26, 11 (November 1983), 1022-1036
[38] S. Mihov , D. Maurel. Direct Construction of Minimal Acyclic Subsequential Transducers. 2001.
[39] J. Daciuk, D. Weiss. Smaller Representation of Finite State Automata. In: Lecture Notes in Computer Science, Implementation and Application of Automata, Proceedings of the 16th International Conference on Implementation and Application of Automata,CIAA'2011, vol. 6807, 2011, pp. 118—192.
[40] Yves Rasolofo and Jacques Savoy. Term proximity scoring for keyword-based retrieval systems. In Proceedings of the 25th European conference on IR research (ECIR'03), Fabrizio Sebastiani(Ed.). Springer-Verlag, Berlin, Heidelberg, 207-218, 2003.
[41] S. Büttcher, C. Clarke, B. Lushman, B. Term proximity scoring for ad-hoc retrieval on very large text collections. Proceedings of the 29th annual international ACM SIGIR conference on Research and development in information retrieval, 621–622, 2006.
[42] A. Moffat, J. Zobel. Fast Ranking in Limited Space. In Proceedings of the Tenth International Conference on Data Engineering. IEEE Computer Society, Washington, DC, USA, 428-437, 1994.
[43] L. Dolamic, J. Savoy. Variations autour de tf idf et du moteur Lucene. In: Publié dans les 1 Actes 9e journées Analyse statistique des Données Textuelles JADT 2008, 1047-1058, 2008
[44] X. Xu, S. Pan, J. Wan. Compression of Inverted Index for Comprehensive Performance Evaluation in Lucene. 2010 Third International Joint Conference on Computational Science and Optimization (CSO), vol. 1, 382–386, 2010
[45] T. G. Armstrong, A. Moffat, W. Webber, and J. Zobel,“Has adhoc retrieval improved since 1994?,” presented at the SIGIR '09: Proceedings of the 32nd international ACM SIGIR conference on Research and development in information retrieval, 2009.
