Lucene个人总结

1、调用commit方法，会生成一个.cfs文件，调用一次生成一个。
2、单独调用optimize()方法，会额外生成一个合并了多个.cfs文件的大.cfs文件，此时如果不close()，则索引文件大小翻倍。单独close()方法无效。
3、添加文档后，手动GC一次，内存释放快。
4、设置合并因子，根据.cfs文件个数合并。
5、添加一次document则消耗一定内存，然后释放，内存回升。
6、不进行提交操作，内存逐渐增长，若进行提交且内存占用多，则一次性回升大，然后降低至最低。
7、暂时未发现改变内存缓冲大小setRAMBufferSizeMB对索引性能的影响。
8、如果合并索引文件，则剩余的碎片会在commit或者是close之后自动删除。
9、合并式的索引效率没有提交式的索引效率高。
10、加载索引，首先读入段信息，然后看一下有几个段：如果只有一个，那么可能是优化过的，直接读取这一个段就可以；否则需要一次读入各个段，然后再拼成一个MultiReader。
11、增强索引的实时性，利用内存索引存放document一段时间，然后写入磁盘索引。搜索的时候提供内存跟磁盘索引多级目录。合并的时候，需要创建第三个索引，用于存放新增加的document，搜索时需要遍历这三个索引。
12、分布式的处理， 需要将相应的类，按照同样的路径打包，否则出现问题。
13、分布式的注册类，实现UnicastRemoteObject类后就不需要专门生成RMI类。
14、采用多线程，对每一个线程都有一个对应的文档集处理对象，因此可以并行的进行索引，虽然对文档的处理过程可以并行，但是将文档写入索引文件却必须串行进行。
15、setMergeFactor设置lucene的合并参数，可以由setMaxMergeDocs来控制一个.cfs文件里面的document个数，如果超过了，则合并因子失效了。
16、所谓的优化就是对整个目录内未合并的segment进行的合并。同设置合并因子之后的合并。
17、多字段查询，设置为should表示这一句查询语句分词后是or的连接，设置为Must,则为and 的连接。should+must=must。
18、对位置偏移量信息的API使用：
//获取到具体文档的具体字段的所有词向量对象。
TermPositions tp=ir.termPositions(new Term("content","你"));
while(tp.next()){
//根据文档默认的ID获取到该文档下面的content字段中的所有词。
TermPositionVector tfv=(TermPositionVector) ir.getTermFreqVector(tp.doc(), "content");
System.out.println(tfv);
//遍历每一个词，获取到内容和下标
for(int i=0;tfv!=null&&i<tfv.getTerms().length;i++){
System.out.println(tfv.getTerms()[i]);
//通过每个词的下标，取出当前词的位置信息数组，位置信息包括起始坐标和结束坐标，坐标计算标点，词出现过几次，就有几个位置对象。
TermVectorOffsetInfo[] tt=tfv.getOffsets(i);
for(TermVectorOffsetInfo to:tt)
{
//打印出来该词在原本的句子中的起始位置到结束位置。
System.out.println(to.getStartOffset()+"____"+to.getEndOffset());
}
}
}
19. 对关键词高亮的时候可以不需要其他参数，只要你能传递原始内容进去，它自动解析出来并进行高亮。
20. 对RMI修改端口问题：如果用默认的端口则在绑定（Naming.rebind()）中传递的字符串不需要添加地址和端口，如果修改了端口，则需要显示的声明出来。