lucene查询经验分享

将查询的响应时间降低到0.5秒以内      

  Nutch 的索引文档数量在100W以下的时候，怎么处理查询响应都比较的快速，基本上不会超过0.5秒。但是超过200W索引文档 的时候如果不处理，查询的响应时间就会超过这个数字。如果内存足够，甚至可以把200W的索引文档全部加载到内存，这时查询响应时间会小于0.1秒，但内存占用会超过1.5G，这种方式适合数据量比较小的查询系统，例如文献检索等。 

       当数据量超过200W的时候如果全部加载到内存则不太适合了，因为受JVM最大内存的限制（1.2G到3.6G Linux下），加载超过200W索引页面的时候，JVM会溢出。

        以下介绍通过几种方式实现超过1000W的索引页面查询响应时间降低到0.5秒以内。     

   1、让索引尽可能的简单，非必要的索引字段尽可能的删除掉，索引的字段需要正确的区分那些Index ；那些Tokenize、那些Store。     

   2、将 indexer.minMergeDocs 和 indexer.mergeFactor 调整到尽可能的大。如果索引的页面大小平均在10K，JVM可用的内存是2.6G，则可以将indexer.minMergeDocs 设置为30000（根据页面尺寸定），这对查询的效率影响巨大。   

     3、将尽可能多的 segemts合并到一起，可以让 一个 segment 包含100W个document 并根据实际情况调整一个segment 包含的 document的数量 。    

    4、将所有的 index 合并到一起，如果创建索引的时候 indexer.minMergeDocs 是 足够大，则合并以后的index目录下的文件会很少，这将非常的有利于查询性能的提高（我在我的系统里面把大约400W个document合并到一个segments目录下，然后分成5个segment，最后把400W个索引文档合并到一个index目录下，最后产生的index目录下的文件只有10多个，但文件尺寸非常大）。   

     5、将索引分布在多个JVM。如果单台服务器的内存很大（超过6G），那么可以在一台计算机上开启多个查询服务器，每个查询服务器启动的JVM内存占用会从400M逐渐增加到2G左右，所以如果单个的查询服务器使用的索引文档超过200W，则需要增加足够的内存以应付查询缓存（查询服务器启动时间越长，缓存的内容越多，内存占用越大）。  

      6、一般的垂直搜索引擎都需要在Nutch 上再做开发，索引的及时更新都会面临一些问题。  

      索引超过3000W个页面的查询效率调整暂时不能公开，按照以上方式处理会超过1秒，但小于5秒。