IndexWriterConfig这个配置管理类

介绍了IndexWriter的作用，它的最大价值体现在对索引的创建，管理和维护上，通过与IndexWriterConfig这个配置管理类的组合，可以实现最佳的索引策略，当然前提是你得了解IndexWriterConfig里一些重要的参数的配置含义。


本篇文章散仙要介绍的是IndexSearcher这个类，这个类是Lucene在进行检索时必不可少的一个组件，可以称为是检索的入口，通过这个入口之后，我们就可以获取与我们检索的关键词相关的一系列Doc，然后我们就可以进行后续相关的业务处理。

所以我们经常会在代码里这样写：




Java代码 复制代码 收藏代码
1.Directory directory=FSDirectory.open(new File("D:\\索引测试"));//获取一个索引目录 
2.IndexReader reader=DirectoryReader.open(directory);//返回一个复合Reader=》DirectoryReader 
3.         //构造IndexSearcher 检索环境 
4.IndexSearcher searcher=new IndexSearcher(reader); 


大多数，情况下，我们的代码都是这样写的，实际上IndexSearcher的构造函数有4个，我们最常用的一般有2个，部分源码如下：



Java代码 复制代码 收藏代码
1.final IndexReader reader; // package private for testing! 
2.   
3.  // NOTE: these members might change in incompatible ways 
4.  // in the next release 
5.  protected final IndexReaderContext readerContext; 
6.  protected final List<AtomicReaderContext> leafContexts; 
7.  /** used with executor - each slice holds a set of leafs executed within one thread */ 
8.  protected final LeafSlice[] leafSlices; 
9. 
10.  // These are only used for multi-threaded search 
11.  private final ExecutorService executor; 
12. 
13.  // the default Similarity 
14.  private static final Similarity defaultSimilarity = new DefaultSimilarity(); 
15.   
16.  /**
17.   * Expert: returns a default Similarity instance.
18.   * In general, this method is only called to initialize searchers and writers.
19.   * User code and query implementations should respect
20.   * {@link IndexSearcher#getSimilarity()}.
21.   * @lucene.internal
22.   */ 
23.  public static Similarity getDefaultSimilarity() { 
24.    return defaultSimilarity; 
25.  } 
26.   
27.  /** The Similarity implementation used by this searcher. */ 
28.  private Similarity similarity = defaultSimilarity; 
29. 
30.  /** Creates a searcher searching the provided index. */ 
31.  public IndexSearcher(IndexReader r) { 
32.   //调用的是2参的构造函数 
33.    this(r,null); 
34.  } 
35. 
36.  /** Runs searches for each segment separately, using the
37.   *  provided ExecutorService.  IndexSearcher will not
38.   *  shutdown/awaitTermination this ExecutorService on
39.   *  close; you must do so, eventually, on your own.  NOTE:
40.   *  if you are using {@link NIOFSDirectory}, do not use
41.   *  the shutdownNow method of ExecutorService as this uses
42.   *  Thread.interrupt under-the-hood which can silently
43.   *  close file descriptors (see <a 
44.   *  href="https://issues.apache.org/jira/browse/LUCENE-2239">LUCENE-2239</a>).
45.   * 
46.   * @lucene.experimental */ 
47.  public IndexSearcher(IndexReader r, ExecutorService executor) { 
48.      
49.    this(r.getContext(), executor); 
50.  } 



看了源码，我们就会发现，我们常用的构造函数实际上是会调用含有线程池并行检索的2参的构造方法，只不过，把线程池设置为null而已，这其实是一个优化的操作，在某些时候能够带来极大的性能提升，这个稍后散仙会详细分析。下面先来看下IndexSearcher里面的一些常用的API方法

方法名 描述 
IndexSearcher(IndexReader r)  构建一个搜索实例，使用指定的Reader
IndexSearcher(IndexReader r, ExecutorService executor)  创建一个并行的检索实例，使用ExecutorService 提供的线程池
doc(int docID)  通过一个docid获取一个对应的doc
explain(Query query, int doc)  获取query详细的评分依据信息
getIndexReader()  获取IndexReader实例
search(Query query, int n)  获取前N个检索的结果
search(Query query, Collector results)  通过collector对检索结果进行自定义控制
search(Query query, Filter filter, Collector results)  通过检索，过滤，以及收集，获取一个特定的检索结果
search(Query query, Filter filter, int n)  经过滤后 的前N个结果
search(Query query, Filter filter, int n, Sort sort)  经过滤，排序后的前n个结果
search(Query query, Filter filter, int n, Sort sort, boolean doDocScores, boolean doMaxScore)  对排序后的结果，是否开启评分策略
searchAfter(ScoreDoc after, Query query, int n)  检索上一次query后的数据，通常用来分页使用
setSimilarity(Similarity similarity)  设置自定义的打分策略
search(Weight weight, int nDocs, Sort sort, boolean doDocScores, boolean doMaxScore)  检索指定分数以上的结果


IndexSearcher类里面提供了大量的方法，用来对检索的数据集的限制和过滤，从而达到我们业务需要的一部分数据，当然我们也可也通过setSimilarity方法来设置我们的自定义的打分策略，还可以通过其他的一些方法，来实现排序，过滤，收集，调试打分信息等等。

最后，回到文章开始，散仙来分析下，IndexSearcher的并行构造，如何使用多线程来提升检索性能。

大多数时候，我们默认使用的都是单线程检索，这时候的检索总耗时是顺序检索所有段文件的时间之和，而如果我们使用了并行检索，这时候，我们的检索总耗时，其实就是检索段文件里，耗时最大的那个线程的时间，因为我们是并行检索，所以影响耗时的其实就是检索耗时最长的那个线程的耗时，这有点像“木桶效应”，决定木桶装水的多少，不是由最长的木板决定的，而是由最短的那块木板决定的，反映到这里，其实就是散仙刚提及的耗时可能最长的那个线程，决定了检索的总耗时。

首先呢，这个功能，并不是说所有的场景下，都有明显的作用，比如，我的索引里就只有一个段文件，那么你开启再多的线程也没用，因为这个并行检索，是一个线程对应一个段文件。
另外一种情况，我的索引非常小，然后我又压缩成多个段文件，然后使用这个并行检索去检索数据，其实这时候的性能可能连一个单线程都不如，这也就是单线程与多线程的使用场景的区分，只要正确的理解了什么时候使用单线程，什么时候使用多线程，才有可能达到我们最想要的结果。

所以，这个并行优化的功能，最适合的场景就是我的索引非常大，然后我们把这份索引，压缩成了多个段文件，可能有5个，或者10个以上的段文件，这时候利用这个功能，检索就有很大优势了，下面我们在来看下源码里具体处理：





Java代码 复制代码 收藏代码
1.if (executor == null) { 
2.      return search(leafContexts, weight, after, nDocs); 
3.    } else { 
4.        //通过一个公用的队列，来合并结果集 
5.      final HitQueue hq = new HitQueue(nDocs, false); 
6.      final Lock lock = new ReentrantLock();//锁 
7.      final ExecutionHelper<TopDocs> runner = new ExecutionHelper<TopDocs>(executor); 
8.     
9.      for (int i = 0; i < leafSlices.length; i++) { // search each sub 
10.        runner.submit(new SearcherCallableNoSort(lock, this, leafSlices[i], weight, after, nDocs, hq)); 
11.      } 
12. 
13.      int totalHits = 0; 
14.      float maxScore = Float.NEGATIVE_INFINITY; 
15.      for (final TopDocs topDocs : runner) { 
16.        if(topDocs.totalHits != 0) { 
17.          totalHits += topDocs.totalHits; 
18.          maxScore = Math.max(maxScore, topDocs.getMaxScore()); 
19.        } 
20.      } 
21. 
22.       //最后从队列里，取值给ScoreDoc进行返回 
23.      final ScoreDoc[] scoreDocs = new ScoreDoc[hq.size()]; 
24.      for (int i = hq.size() - 1; i >= 0; i--) // put docs in array 
25.        scoreDocs[i] = hq.pop(); 




然后在具体的线程类里的实现：



Java代码 复制代码 收藏代码
1.private static final class SearcherCallableNoSort implements Callable<TopDocs> { 
2. 
3.  private final Lock lock; 
4.  private final IndexSearcher searcher; 
5.  private final Weight weight; 
6.  private final ScoreDoc after; 
7.  private final int nDocs; 
8.  private final HitQueue hq; 
9.  private final LeafSlice slice; 
10. 
11.  public SearcherCallableNoSort(Lock lock, IndexSearcher searcher, LeafSlice slice,  Weight weight, 
12.      ScoreDoc after, int nDocs, HitQueue hq) { 
13.    this.lock = lock; 
14.    this.searcher = searcher; 
15.    this.weight = weight; 
16.    this.after = after; 
17.    this.nDocs = nDocs; 
18.    this.hq = hq; 
19.    this.slice = slice; 
20.  } 
21. 
22.  @Override 
23.  public TopDocs call() throws IOException { 
24.    final TopDocs docs = searcher.search(Arrays.asList(slice.leaves), weight, after, nDocs); 
25.    final ScoreDoc[] scoreDocs = docs.scoreDocs; 
26.    //it would be so nice if we had a thread-safe insert  
27.    lock.lock(); 
28.    try { 
29.      for (int j = 0; j < scoreDocs.length; j++) { // merge scoreDocs into hq 
30.        final ScoreDoc scoreDoc = scoreDocs[j]; 
31.        if (scoreDoc == hq.insertWithOverflow(scoreDoc)) { 
32.          break; 
33.        } 
34.      } 
35.    } finally { 
36.      lock.unlock(); 
37.    } 
38.    return docs; 
39.  } 
40.} 


通过源码，我们大概可以看出，这个提升，其实是利用了多线程的方式来完成的，通过实现Callable接口，以及重写其的call方法，最后通过公用的全局锁，来控制把检索到的结果集添加到公用的命中队列里，这样一来，一个检索，就被并行的分散到多个线程里，然后最后通过一个全局的容器，来获取所有线程检索的结果，由此以来，在某些场合就能大大提升检索性能。

当然这种提升是否，还跟我们的硬件环境有关系，如果我们的机器CPU不够强劲，或者我们在单核或双核上的机器上跑，可能会出现预期之外的结果，不过，现在的服务器基本都是配置很好的，一般不会出现这种情况。