lucene 漫谈--入门与介绍(6)

8 分析器

        在前面的概念介绍中我们已经知道了分析器的作用，就是把句子按照语义切分成一个个词语。英文切分已经有了很成熟的分析器： StandardAnalyzer，很多情况下StandardAnalyzer是个不错的选择。甚至你会发现StandardAnalyzer也能对中文进行分词。

        但是我们的焦点是中文分词，StandardAnalyzer能支持中文分词吗？实践证明是可以的，但是效果并不好，搜索“如果”会把“牛奶不如果汁好喝”也搜索出来，而且索引文件很大。那么我们手头上还有什么分析器可以使用呢？core里面没有，我们可以在sandbox里面找到两个： ChineseAnalyzer和CJKAnalyzer。但是它们同样都有分词不准的问题。相比之下用StandardAnalyzer和 ChineseAnalyzer建立索引时间差不多，索引文件大小也差不多，CJKAnalyzer表现会差些，索引文件大且耗时比较长。

        要解决问题，首先分析一下这三个分析器的分词方式。StandardAnalyzer和ChineseAnalyzer都是把句子按单个字切分，也就是说 “牛奶不如果汁好喝”会被它们切分成“牛 奶 不 如 果 汁 好 喝”；而CJKAnalyzer则会切分成“牛奶 奶不 不如 如果 果汁 汁好好喝”。这也就解释了为什么搜索“果汁”都能匹配这个句子。

        以上分词的缺点至少有两个：匹配不准确和索引文件大。我们的目标是将上面的句子分解成“牛奶 不如 果汁好喝”。这里的关键就是语义识别，我们如何识别“牛奶”是一个词而“奶不”不是词语？我们很自然会想到基于词库的分词法，也就是我们先得到一个词库，里面列举了大部分词语，我们把句子按某种方式切分，当得到的词语与词库中的项匹配时，我们就认为这种切分是正确的。这样切词的过程就转变成匹配的过程，而匹配的方式最简单的有正向最大匹配和逆向最大匹配两种，说白了就是一个从句子开头向后进行匹配，一个从句子末尾向前进行匹配。基于词库的分词词库非常重要，词库的容量直接影响搜索结果，在相同词库的前提下，据说逆向最大匹配优于正向最大匹配。

        当然还有别的分词方法，这本身就是一个学科，我这里也没有深入研究。回到具体应用，我们的目标是能找到成熟的、现成的分词工具，避免重新发明车轮。经过网上搜索，用的比较多的是中科院的ICTCLAS和一个不开放源码但是免费的JE-Analysis。ICTCLAS有个问题是它是一个动态链接库， java调用需要本地方法调用，不方便也有安全隐患，而且口碑也确实不大好。JE-Analysis效果还不错，当然也会有分词不准的地方，相比比较方便放心。


9 性能优化


        一直到这里，我们还是在讨论怎么样使lucene跑起来，完成指定任务。利用前面说的也确实能完成大部分功能。但是测试表明lucene的性能并不是很好，在大数据量大并发的条件下甚至会有半分钟返回的情况。另外大数据量的数据初始化建立索引也是一个十分耗时的过程。那么如何提高lucene的性能呢？下面从优化创建索引性能和优化搜索性能两方面介绍。

        9.1 优化创建索引性能
        这方面的优化途径比较有限，IndexWriter提供了一些接口可以控制建立索引的操作，另外我们可以先将索引写入RAMDirectory，再批量写入FSDirectory，不管怎样，目的都是尽量少的文件IO，因为创建索引的最大瓶颈在于磁盘IO。另外选择一个较好的分析器也能提高一些性能。

        9.1.1 通过设置IndexWriter的参数优化索引建立
           

setMaxBufferedDocs(int maxBufferedDocs);

        控制写入一个新的segment前内存中保存的document的数目，设置较大的数目可以加快建索引速度，默认为10。
           

setMaxMergeDocs(int maxMergeDocs);

        控制一个segment中可以保存的最大document数目，值较小有利于追加索引的速度，默认Integer.MAX_VALUE，无需修改。
           

setMergeFactor(int mergeFactor);

        控制多个segment合并的频率，值较大时建立索引速度较快，默认是10，可以在建立索引时设置为100。

        9.1.2 通过RAMDirectory缓写提高性能
        我们可以先把索引写入RAMDirectory，达到一定数量时再批量写进FSDirectory，减少磁盘IO次数。

            FSDirectory fsDir = FSDirectory.getDirectory("/data/index", true);
            RAMDirectory ramDir = new RAMDirectory();
            IndexWriter fsWriter = new IndexWriter(fsDir, new StandardAnalyzer(), true);
            IndexWriter ramWriter = new IndexWriter(ramDir, new StandardAnalyzer(), true);
            while (there are documents to index)
            {
                    ... create Document ...
                ramWriter.addDocument(doc);
                if (condition for flushing memory to disk has been met)
                {
                    fsWriter.addIndexes(new Directory[] { ramDir });
                    ramWriter.close();
                    ramWriter = new IndexWriter(ramDir, new StandardAnalyzer(), true);
                }
            }   

9.1.3 选择较好的分析器
        这个优化主要是对磁盘空间的优化，可以将索引文件减小将近一半，相同测试数据下由600M减少到380M。但是对时间并没有什么帮助，甚至会需要更长时间，因为较好的分析器需要匹配词库，会消耗更多cpu，测试数据用StandardAnalyzer耗时133分钟；用MMAnalyzer耗时150分钟。

        9.2 优化搜索性能
        虽然建立索引的操作非常耗时，但是那毕竟只在最初创建时才需要，平时只是少量的维护操作，更何况这些可以放到一个后台进程处理，并不影响用户搜索。我们创建索引的目的就是给用户搜索，所以搜索的性能才是我们最关心的。下面就来探讨一下如何提高搜索性能。

        9.2.1 将索引放入内存
        这是一个最直观的想法，因为内存比磁盘快很多。Lucene提供了RAMDirectory可以在内存中容纳索引：

            Directory fsDir = FSDirectory.getDirectory(“/data/index/”, false);
            Directory ramDir = new RAMDirectory(fsDir);
            Searcher searcher = new IndexSearcher(ramDir);

       

     但是实践证明RAMDirectory和FSDirectory速度差不多，当数据量很小时两者都非常快，当数据量较大时（索引文件400M）RAMDirectory甚至比FSDirectory还要慢一点，这确实让人出乎意料。而且lucene的搜索非常耗内存，即使将400M的索引文件载入内存，在运行一段时间后都会out of memory，所以个人认为载入内存的作用并不大。

        9.2.2 优化时间范围限制
        既然载入内存并不能提高效率，一定有其它瓶颈，经过测试发现最大的瓶颈居然是时间范围限制，那么我们可以怎样使时间范围限制的代价最小呢？

        当需要搜索指定时间范围内的结果时，可以：
        1、用RangeQuery，设置范围，但是RangeQuery的实现实际上是将时间范围内的时间点展开，组成一个个BooleanClause加入到 BooleanQuery中查询，因此时间范围不可能设置太大，经测试，范围超过一个月就会抛BooleanQuery.TooManyClauses，可以通过设置 BooleanQuery.setMaxClauseCount(int maxClauseCount)扩大，但是扩大也是有限的，并且随着maxClauseCount扩大，占用内存也扩大。
        2、用RangeFilter代替RangeQuery，经测试速度不会比RangeQuery慢，但是仍然有性能瓶颈，查询的90%以上时间耗费在 RangeFilter，研究其源码发现RangeFilter实际上是首先遍历所有索引，生成一个BitSet，标记每个document，在时间范围内的标记为true，不在的标记为false，然后将结果传递给Searcher查找，这是十分耗时的。
        3、进一步提高性能，这个又有两个思路：

•        a、缓存Filter结果。既然RangeFilter的执行是在搜索之前，那么它的输入都是一定的，就是IndexReader，而 IndexReader是由Directory决定的，所以可以认为RangeFilter的结果是由范围的上下限决定的，也就是由具体的 RangeFilter对象决定，所以我们只要以RangeFilter对象为键，将filter结果BitSet缓存起来即可。lucene API已经提供了一个CachingWrapperFilter类封装了Filter及其结果，所以具体实施起来我们可以cache CachingWrapperFilter对象，需要注意的是，不要被CachingWrapperFilter的名字及其说明误导， CachingWrapperFilter看起来是有缓存功能，但的缓存是针对同一个filter的，也就是在你用同一个filter过滤不同 IndexReader时，它可以帮你缓存不同IndexReader的结果，而我们的需求恰恰相反，我们是用不同filter过滤同一个 IndexReader，所以只能把它作为一个封装类。
•         b、降低时间精度。研究Filter的工作原理可以看出，它每次工作都是遍历整个索引的，所以时间粒度越大，对比越快，搜索时间越短，在不影响功能的情况下，时间精度越低越好，有时甚至牺牲一点精度也值得，当然最好的情况是根本不作时间限制。

        下面针对上面的两个思路演示一下优化结果（都采用800线程随机关键词随即时间范围）：
       

• 第一组，时间精度为秒：
          方式 直接用RangeFilter 使用cache 不用filter
           平均每个线程耗时 10s 1s 300ms

•         第二组，时间精度为天
          方式 直接用RangeFilter 使用cache 不用filter
         平均每个线程耗时 900ms 360ms 300ms

        由以上数据可以得出结论：

•        1、 尽量降低时间精度，将精度由秒换成天带来的性能提高甚至比使用cache还好，最好不使用filter。
•         2、 在不能降低时间精度的情况下，使用cache能带了10倍左右的性能提高。

       9.2.3 使用更好的分析器
      这个跟创建索引优化道理差不多，索引文件小了搜索自然会加快。当然这个提高也是有限的。较好的分析器相对于最差的分析器对性能的提升在20%以下。


10 注意事项

        10.1关键词区分大小写
        or AND TO等关键词是区分大小写的，lucene只认大写的，小写的当做普通单词。

        10.2 读写互斥性
        同一时刻只能有一个对索引的写操作，在写的同时可以进行搜索

        10.3 文件锁
        在写索引的过程中强行退出将在tmp目录留下一个lock文件，使以后的写操作无法进行，可以将其手工删除

        10.4 时间格式
        lucene只支持一种时间格式yyMMddHHmmss，所以你传一个yy-MM-dd HH:mm:ss的时间给lucene它是不会当作时间来处理的

        10.5 设置boost
        有些时候在搜索时某个字段的权重需要大一些，例如你可能认为标题中出现关键词的文章比正文中出现关键词的文章更有价值，你可以把标题的boost设置的更大，那么搜索结果会优先显示标题中出现关键词的文章（没有使用排序的前题下）。使用方法：
        Field. setBoost(float boost);默认值是1.0，也就是说要增加权重的需要设置得比1大。