Lucene结果分页

Lucene结果分页
Lucene结果分页

一 ,Hits对象是搜索结果的集合 主要有下面几个方法

•  
  
  在session中保留indexreader对象和hit对象，翻页的时候提取内容
  不使用session，每次都简单处理为重新查询
  lucene推荐先使用第二个办法，即每次都重新查询，这样做的好处是简单方便，不需要考虑session的问题，lucene的查询效率也能保证每次查询时间不长，除非真正有了性能问题，否则不用考虑第一个办法。
  
  
  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的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。


length() ,这个方法记录有多少条结果返回(lazy loading)
doc(n) 返回第n个记录
id(in) 返回第n个记录的Document ID
score(n) 第n个记录的相关度(积分)
由于搜索的结果一般比较大，从性能上考虑，Hits对象并不会真正把所有的结果全部取回，默认情况下是保留前100个记录(对于一般的 搜索引擎,100个记录足够了).
分页的处理
100条记录还是太多，我们多半会每页显示20条记录，然后分为若干页显示，对于分页，一般有两个办法