Lucene 学习资料

Lucene是一个基于Java的全文索引工具包。

另外，若是是在选择全文引擎，如今也许是试试Sphinx的时候了：相比Lucene速度更快，有中文分词的支持，并且内置了对简单的分布式检索的支持；

基于Java的全文索引/检索引擎——Lucene

Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它能够方便的嵌入到各类应用中实现针对应用的全文索引/检索功能。

Lucene的做者：Lucene的贡献者DougCutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操做系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各类中小型应用程序加入全文检索功能。

Lucene的发展历程：早先发布在做者本身的www.lucene.com，后来发布在SourceForge，2001年年末成为APACHE基金会jakarta的一个子项目：http://jakarta.apache.org/lucene/

已经有不少Java项目都使用了Lucene做为其后台的全文索引引擎，比较著名的有：

· Jive：WEB论坛系统；

· Eyebrows：邮件列表HTML归档/浏览/查询系统，本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”做者就是EyeBrows系统的主要开发者之一，而EyeBrows已经成为目前APACHE项目的主要邮件列表归档系统。

· Cocoon:基于XML的web发布框架，全文检索部分使用了Lucene

·  Eclipse:基于Java的开放开发平台，帮助部分的全文索引使用了Lucene

对于中文用户来讲，最关心的问题是其是否支持中文的全文检索。但经过后面对于Lucene的结构的介绍，你会了解到因为Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。

全文检索的实现机制

Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，因此不少传统的应用的文件、数据库等均可以比较方便的映射到Lucene的存储结构/接口中。整体上看：能够先把Lucene当成一个支持全文索引的数据库系统。

比较一下Lucene和数据库：

Lucene	数据库
索引数据源：doc(field1,field2...) doc(field1,field2...)                   \  indexer /                  _____________                 | Lucene Index|                 --------------                  / searcher \  结果输出：Hits(doc(field1,field2) doc(field1...))	索引数据源：record(field1,field2...) record(field1..)               \  SQL: insert/                _____________               | DB  Index   |                -------------               / SQL: select \ 结果输出：results(record(field1,field2..) record(field1...))
Document：一个须要进行索引的“单元” 一个Document由多个字段组成	Record：记录，包含多个字段
Field：字段	Field：字段
Hits：查询结果集，由匹配的Document组成	RecordSet：查询结果集，由多个Record组成

全文检索 ≠ like "%keyword%"

一般比较厚的书籍后面经常附关键词索引表（好比：北京：12, 34页，上海：3,77页……），它可以帮助读者比较快地找到相关内容的页码。而数据库索引可以大大提升查询的速度原理也是同样，想像一下经过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之因此效率高，另一个缘由是它是排好序的。对于检索系统来讲核心是一个排序问题。

因为数据库索引不是为全文索引设计的，所以，使用like "%keyword%"时，数据库索引是不起做用的，在使用like查询时，搜索过程又变成相似于一页页翻书的遍历过程了，因此对于含有模糊查询的数据库服务来讲，LIKE对性能的危害是极大的。若是是须要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。

因此创建一个高效检索系统的关键是创建一个相似于科技索引同样的反向索引机制，将数据源（好比多篇文章）排序顺序存储的同时，有另一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个能够利用索引的精确查询的逻辑组合的过程。从而大大提升了多关键词查询的效率，因此，全文检索问题归结到最后是一个排序问题。

由此能够看出模糊查询相对数据库的精确查询是一个很是不肯定的问题，这也是大部分数据库对全文检索支持有限的缘由。Lucene最核心的特征是经过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不一样应用的定制。

能够经过一下表格对比一下数据库的模糊查询：

Lucene全文索引引擎	数据库
索引	将数据源中的数据都经过全文索引一一创建反向索引	对于LIKE查询来讲，数据传统的索引是根本用不上的。数据须要逐个便利记录进行GREP式的模糊匹配，比有索引的搜索速度要有多个数量级的降低。
匹配效果	经过词元(term)进行匹配，经过语言分析接口的实现，能够实现对中文等非英语的支持。	使用：like "%net%"会把netherlands也匹配出来， 多个关键词的模糊匹配：使用like "%com%net%"：就不能匹配词序颠倒的xxx.net..xxx.com
匹配度	有匹配度算法，将匹配程度（类似度）比较高的结果排在前面。	没有匹配程度的控制：好比有记录中net出现5词和出现1次的，结果是同样的。
结果输出	经过特别的算法，将最匹配度最高的头100条结果输出，结果集是缓冲式的小批量读取的。	返回全部的结果集，在匹配条目很是多的时候（好比上万条）须要大量的内存存放这些临时结果集。
可定制性	经过不一样的语言分析接口实现，能够方便的定制出符合应用须要的索引规则（包括对中文的支持）	没有接口或接口复杂，没法定制
结论	高负载的模糊查询应用，须要负责的模糊查询的规则，索引的资料量比较大	使用率低，模糊匹配规则简单或者须要模糊查询的资料量少

全文检索和数据库应用最大的不一样在于：让最相关的头100条结果知足98%以上用户的需求

Lucene的创新之处：

大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会致使大量的IO操做，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断建立新的索引文件，而后按期的把这些新的小索引文件合并到原先的大索引中（针对不一样的更新策略，批次的大小能够调整），这样在不影响检索的效率的前提下，提升了索引的效率。

Lucene和其余一些全文检索系统/应用的比较：

Lucene	其余开源全文检索系统
增量索引和批量索引	能够进行增量的索引(Append)，能够对于大量数据进行批量索引，而且接口设计用于优化批量索引和小批量的增量索引。	不少系统只支持批量的索引，有时数据源有一点增长也须要重建索引。
数据源	Lucene没有定义具体的数据源，而是一个文档的结构，所以能够很是灵活的适应各类应用（只要前端有合适的转换器把数据源转换成相应结构），	不少系统只针对网页，缺少其余格式文档的灵活性。
索引内容抓取	Lucene的文档是由多个字段组成的，甚至能够控制那些字段须要进行索引，那些字段不须要索引，近一步索引的字段也分为须要分词和不须要分词的类型：    须要进行分词的索引，好比：标题，文章内容字段    不须要进行分词的索引，好比：做者/日期字段	缺少通用性，每每将文档整个索引了
语言分析	经过语言分析器的不一样扩展实现： 能够过滤掉不须要的词：an the of等， 西文语法分析：将jumps jumped jumper都归结成jump进行索引/检索 非英文支持：对亚洲语言，阿拉伯语言的索引支持	缺少通用接口实现
查询分析	经过查询分析接口的实现，能够定制本身的查询语法规则： 好比：多个关键词之间的 + - and or关系等
并发访问	可以支持多用户的使用

 

关于亚洲语言的的切分词问题(Word Segment)

对于中文来讲，全文索引首先还要解决一个语言分析的问题，对于英文来讲，语句中单词之间是自然经过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，全部，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。

首先，确定不能用单个字符做(si-gram)为索引单元，不然查“上海”时，不能让含有“海上”也匹配。

但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？
“北京天安门”仍是“北京天安门”？让计算机可以按照语言习惯进行切分，每每须要机器有一个比较丰富的词库才可以比较准确的识别出语句中的单词。

另一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，好比：
"北京天安门" ==> "北京京天天安安门"。

这样，在查询的时候，不管是查询"北京"仍是查询"天安门"，将查询词组按一样的规则进行切分："北京"，"天安安门"，多个关键词之间按与"and"的关系组合，一样可以正确地映射到相应的索引中。这种方式对于其余亚洲语言：韩文，日文都是通用的。

基于自动切分的最大优势是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来讲，基于2元语法的切分仍是够用的。基于2元切分后的索引通常大小和源文件差很少，而对于英文，索引文件通常只有原文件的30%-40%不一样，

自动切分	词表切分
实现	实现很是简单	实现复杂
查询	增长了查询分析的复杂程度，	适于实现比较复杂的查询语法规则
存储效率	索引冗余大，索引几乎和原文同样大	索引效率高，为原文大小的30％左右
维护成本	无词表维护成本	词表维护成本很是高：中日韩等语言须要分别维护。 还须要包括词频统计等内容
适用领域	嵌入式系统：运行环境资源有限 分布式系统：无词表同步问题 多语言环境：无词表维护成本	对查询和存储效率要求高的专业搜索引擎

目前比较大的搜索引擎的语言分析算法通常是基于以上2个机制的结合。关于中文的语言分析算法，你们能够在Google查关键词"wordsegment search"能找到更多相关的资料。

安装和使用

下载：http://jakarta.apache.org/lucene/

注意：Lucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCC：JavaCompilerCompiler，纯Java的词法分析生成器），因此若是从源代码编译或须要修改其中的QueryParser、定制本身的词法分析器，还须要从https://javacc.dev.java.net/下载javacc。

lucene的组成结构：对于外部应用来讲索引模块(index)和检索模块(search)是主要的外部应用入口

org.apache.Lucene.search/	搜索入口
org.apache.Lucene.index/	索引入口
org.apache.Lucene.analysis/	语言分析器
org.apache.Lucene.queryParser/	查询分析器
org.apache.Lucene.document/	存储结构
org.apache.Lucene.store/	底层IO/存储结构
org.apache.Lucene.util/	一些公用的数据结构

简单的例子演示一下Lucene的使用方法：

索引过程：从命令行读取文件名（多个），将文件分路径(path字段)和内容(body字段)2个字段进行存储，并对内容进行全文索引：索引的单位是Document对象，每一个Document对象包含多个字段Field对象，针对不一样的字段属性和数据输出的需求，对字段还能够选择不一样的索引/存储字段规则，列表以下：

方法	切词	索引	存储	用途
Field.Text(String name, String value)	Yes	Yes	Yes	切分词索引并存储，好比：标题，内容字段
Field.Text(String name, Reader value)	Yes	Yes	No	切分词索引不存储，好比：META信息， 不用于返回显示，但须要进行检索内容
Field.Keyword(String name, String value)	No	Yes	Yes	不切分索引并存储，好比：日期字段
Field.UnIndexed(String name, String value)	No	No	Yes	不索引，只存储，好比：文件路径
Field.UnStored(String name, String value)	Yes	Yes	No	只全文索引，不存储

public classIndexFiles { 
  //使用方法：: IndexFiles [索引输出目录] [索引的文件列表] ...
  public static void main(String[] args)throws Exception {
    String indexPath = args[0];
    IndexWriter writer;
    //用指定的语言分析器构造一个新的写索引器（第3个参数表示是否为追加索引）
    writer = new IndexWriter(indexPath,new SimpleAnalyzer(), false);

    for (int i=1; i<args.length; i++){
      System.out.println("Indexingfile " + args[i]);
      InputStream is = new FileInputStream(args[i]);

      //构造包含2个字段Field的Document对象
      //一个是路径path字段，不索引，只存储
      //一个是内容body字段，进行全文索引，并存储
      Document doc = new Document();
     doc.add(Field.UnIndexed("path", args[i]));
     doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
      //将文档写入索引
      writer.addDocument(doc);
      is.close();
    };
    //关闭写索引器
    writer.close();
  }
}

索引过程当中能够看到：

· 语言分析器提供了抽象的接口，所以语言分析(Analyser)是能够定制的，虽然lucene缺省提供了2个比较通用的分析器SimpleAnalyser和StandardAnalyser，这2个分析器缺省都不支持中文，因此要加入对中文语言的切分规则，须要修改这2个分析器。

· Lucene并无规定数据源的格式，而只提供了一个通用的结构（Document对象）来接受索引的输入，所以输入的数据源能够是：数据库，WORD文档，PDF文档，HTML文档……只要可以设计相应的解析转换器将数据源构形成成Docuement对象便可进行索引。

· 对于大批量的数据索引，还能够经过调整IndexerWrite的文件合并频率属性（mergeFactor）来提升批量索引的效率。

检索过程和结果显示：

搜索结果返回的是Hits对象，能够经过它再访问Document==>Field中的内容。

假设根据body字段进行全文检索，能够将查询结果的path字段和相应查询的匹配度(score)打印出来，

public class Search{ 
  public static void main(String[] args)throws Exception {
    String indexPath = args[0],queryString = args[1];
    //指向索引目录的搜索器
    Searcher searcher = newIndexSearcher(indexPath);
    //查询解析器：使用和索引一样的语言分析器
    Query query =QueryParser.parse(queryString, "body", 
                              newSimpleAnalyzer());
    //搜索结果使用Hits存储
    Hits hits = searcher.search(query);
    //经过hits能够访问到相应字段的数据和查询的匹配度
    for (int i=0; i<hits.length();i++) {
     System.out.println(hits.doc(i).get("path") + "; Score:" + 
                         hits.score(i));
    };
  }
}

在整个检索过程当中，语言分析器，查询分析器，甚至搜索器（Searcher）都是提供了抽象的接口，能够根据须要进行定制。

Hacking Lucene

简化的查询分析器

我的感受lucene成为JAKARTA项目后，画在了太多的时间用于调试日趋复杂QueryParser，而其中大部分是大多数用户并不很熟悉的，目前LUCENE支持的语法：

Query ::= ( Clause )*
Clause ::= ["+", "-"] [<TERM> ":"] (<TERM> | "(" Query ")")

中间的逻辑包括：and or + - &&||等符号，并且还有"短语查询"和针对西文的前缀/模糊查询等，我的感受对于通常应用来讲，这些功能有一些华而不实，其实可以实现目前相似于Google的查询语句分析功能其实对于大多数用户来讲已经够了。因此，Lucene早期版本的QueryParser还是比较好的选择。

添加修改删除指定记录（Document）

Lucene提供了索引的扩展机制，所以索引的动态扩展应该是没有问题的，而指定记录的修改也彷佛只能经过记录的删除，而后从新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是须要在索引时根据数据源中的记录ID专门另建索引，而后利用IndexReader.delete(Termterm)方法经过这个记录ID删除相应的Document。

根据某个字段值的排序功能

lucene缺省是按照本身的相关度算法（score）进行结果排序的，但可以根据其余字段进行结果排序是一个在LUCENE的开发邮件列表中常常提到的问题，不少原先基于数据库应用都须要除了基于匹配度（score）之外的排序功能。而从全文检索的原理咱们能够了解到，任何不基于索引的搜索过程效率都会致使效率很是的低，若是基于其余字段的排序须要在搜索过程当中访问存储字段，速度回大大下降，所以很是是不可取的。

但这里也有一个折中的解决方法：在搜索过程当中可以影响排序结果的只有索引中已经存储的docID和score这2个参数，因此，基于score之外的排序，其实能够经过将数据源预先排好序，而后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行排序和在搜索过程当中访问不在索引中的某个字段值。

这里须要修改的是IndexSearcher中的HitCollector过程：

...

　scorer.score(newHitCollector() {
        private float minScore = 0.0f;
        public final void collect(int doc,float score) {
         if (score > 0.0f &&                   // ignore zeroed buckets
              (bits==null || bits.get(doc))) {         // skip docs not in bits
           totalHits[0]++;
           if (score >= minScore) {
              /* 原先：Lucene将docID和相应的匹配度score例入结果命中列表中：
               *hq.put(new ScoreDoc(doc, score));      // update hit queue
               * 若是用doc 或 1/doc 代替 score，就实现了根据docID顺排或逆排
               * 假设数据源索引时已经按照某个字段排好了序，而结果根据docID排序也就实现了
               * 针对某个字段的排序，甚至能够实现更复杂的score和docID的拟合。
               */
              hq.put(new ScoreDoc(doc, (float) 1/doc )); 
              if (hq.size() > nDocs) {         // if hit queue overfull
               hq.pop();                        // remove lowest in hit queue
               minScore =((ScoreDoc)hq.top()).score; // reset minScore
              }
           }
         }
        }
      }, reader.maxDoc());

更通用的输入输出接口

虽然lucene没有定义一个肯定的输入文档格式，但愈来愈多的人想到使用一个标准的中间格式做为Lucene的数据导入接口，而后其余数据，好比PDF只须要经过解析器转换成标准的中间格式就能够进行数据索引了。这个中间格式主要以XML为主，相似实现已经不下4，5个：

数据源: WORD       PDF    HTML    DB       other
         \          |       |     |         /
                       XML中间格式
                            |
                     Lucene INDEX

目前尚未针对MSWord文档的解析器，由于Word文档和基于ASCII的RTF文档不一样，须要使用COM对象机制解析。这个是我在Google上查的相关资料：http://www.intrinsyc.com/products/enterprise_applications.asp
另一个办法就是把Word文档转换成text：http://www.winfield.demon.nl/index.html

索引过程优化

索引通常分2种状况，一种是小批量的索引扩展，一种是大批量的索引重建。在索引过程当中，并非每次新的DOC加入进去索引都从新进行一次索引文件的写入操做（文件I/O是一件很是消耗资源的事情）。

Lucene先在内存中进行索引操做，并根据必定的批量进行文件的写入。这个批次的间隔越大，文件的写入次数越少，但占用内存会不少。反之占用内存少，但文件IO操做频繁，索引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数能够帮助你在构造索引器后根据应用环境的状况充分利用内存减小文件的操做。根据个人使用经验：缺省Indexer是每20条记录索引后写入一次，每将MERGE_FACTOR增长50倍，索引速度能够提升1倍左右。

搜索过程优化

lucene支持内存索引：这样的搜索比基于文件的I/O有数量级的速度提高。
http://www.onjava.com/lpt/a/3273
而尽量减小IndexSearcher的建立和对搜索结果的前台的缓存也是必要的。

Lucene面向全文检索的优化在于首次索引检索后，并不把全部的记录（Document）具体内容读取出来，而起只将全部结果中匹配度最高的头100条结果（TopDocs）的ID放到结果集缓存中并返回，这里能够比较一下数据库检索：若是是一个10,000条的数据库检索结果集，数据库是必定要把全部记录内容都取得之后再开始返回给应用结果集的。因此即便检索匹配总数不少，Lucene的结果集占用的内存空间也不会不少。对于通常的模糊检索应用是用不到这么多的结果的，头100条已经能够知足90%以上的检索需求。

若是首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存，并再从新向后抓取。因此若是构造一个Searcher去查1－120条结果，Searcher实际上是进行了2次搜索过程：头100条取完后，缓存结果用完，Searcher从新检索再构造一个200条的结果缓存，依此类推，400条缓存，800条缓存。因为每次Searcher对象消失后，这些缓存也访问那不到了，你有可能想将结果记录缓存下来，缓存数尽可能保证在100如下以充分利用首次的结果缓存，不让Lucene浪费屡次检索，并且能够分级进行结果缓存。

Lucene的另一个特色是在收集结果的过程当中将匹配度低的结果自动过滤掉了。这也是和数据库应用须要将搜索的结果所有返回不一样之处。

个人一些尝试：

·  支持中文的Tokenizer：这里有2个版本，一个是经过JavaCC生成的，对CJK部分按一个字符一个TOKEN索引，另一个是从SimpleTokenizer改写的，对英文支持数字和字母TOKEN，对中文按迭代索引。

·  基于XML数据源的索引器：XMLIndexer，所以全部数据源只要可以按照DTD转换成指定的XML，就能够用XMLIndxer进行索引了。

·  根据某个字段排序：按记录索引顺序排序结果的搜索器：IndexOrderSearcher，所以若是须要让搜索结果根据某个字段排序，可让数据源先按某个字段排好序（好比：PriceField），这样索引后，而后在利用这个按记录的ID顺序检索的搜索器，结果就是至关因而那个字段排序的结果了。

从Lucene学到更多

Luene的确是一个面对对象设计的典范

·  全部的问题都经过一个额外抽象层来方便之后的扩展和重用：你能够经过从新实现来达到本身的目的，而对其余模块而不须要；

·  简单的应用入口Searcher, Indexer，并调用底层一系列组件协同的完成搜索任务；

·  全部的对象的任务都很是专注：好比搜索过程：QueryParser分析将查询语句转换成一系列的精确查询的组合(Query),经过底层的索引读取结构IndexReader进行索引的读取，并用相应的打分器给搜索结果进行打分/排序等。全部的功能模块原子化程度很是高，所以能够经过从新实现而不须要修改其余模块。 

·  除了灵活的应用接口设计，Lucene还提供了一些适合大多数应用的语言分析器实现（SimpleAnalyser,StandardAnalyser），这也是新用户可以很快上手的重要缘由之一。

这些优势都是很是值得在之后的开发中学习借鉴的。做为一个通用工具包，Lunece的确给予了须要将全文检索功能嵌入到应用中的开发者不少的便利。

此外，经过对Lucene的学习和使用，我也更深入地理解了为何不少数据库优化设计中要求，好比：

·  尽量对字段进行索引来提升查询速度，但过多的索引会对数据库表的更新操做变慢，而对结果过多的排序条件，实际上每每也是性能的杀手之一。

·  不少商业数据库对大批量的数据插入操做会提供一些优化参数，这个做用和索引器的merge_factor的做用是相似的，

·  20%/80%原则：查的结果多并不等于质量好，尤为对于返回结果集很大，如何优化这头几十条结果的质量每每才是最重要的。

·  尽量让应用从数据库中得到比较小的结果集，由于即便对于大型数据库，对结果集的随机访问也是一个很是消耗资源的操做。