针对于lucene使用和优化

索引的优化技术大概有三种：
一是通过调整mergeFactor、maxMergeDocs和minMergeDocs参数的值来达到索引优化的目的。其中，mergeFactor是控制片段合并的频度和大小，maxMergeDocs是每片段文档数的上限，minMergeDocs是控制索引过程中可用RAM的数量。结合机器的内存情况，合理地配置这三个参数，能达到最优的效果。
二是组合使用RAMDirectory和FSDirectory。使用以上两者时会发现它们都有各自的长短处，例如，RAMDirectory具有较高的存储速度，但它受到实际内存的限制；FSDirectory不受实际内存的限制，但因为要读写文件，所以速度是它的瓶颈。组合使用RAMDirectory和FSDirectory，能很好地解决速度和内存空间的矛盾问题，从而达到优化目的。具体做法是先把doc存到RAMDirectory里，等到RAMDirectory里doc数量达到某个限度时，再把这些doc一次性地写到FSDirectory里。这里RAMDirctory起到一个缓冲的作用。
三是使用多索引器。通过使用多线程技术来实现并行程序设计，这样能提高建立索引的速度，但由于技术的复杂性和易错性，所以这种技术要求有很高的编程能力。


检索的优化技术：
Lucene支持内存索引：这样的搜索比基于文件的I/O有数量级的速度提升。而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。
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浪费多次检索，而且可以分级进行结果缓存。


转自：http://hi.baidu.com/lewutian/blog/item/48a86d03de58b984d43f7c1b.html


优化检索速度：http://blog.163.com/lewutian@126/blog/static/163824796201041131626170/


总结
优化检索优化：
1 lucene的版本是不是最新的
2 使用转速快的硬件设备（磁盘寻道时间比平常的硬盘要快）
3 加大jvm内存
4 唯一的IndexSearch实例（IndexSearch支持多线程）
5 尽量避免重新构造IndexSearcher对象（减少对系统的消耗）
6 optimize方法只在需要的时候调用（合并索引）
7 尽量重用filed对象
8 减少filed对象的存储，只存储必要的数据
9 如果索引不是需要经常优化，要减小MergeFactor合并因子的值
10 在返回结果的时候使用filedselect选择器，只返回需要的filed对象
11 返回的hits长度只要满足需求即可
12 使用模糊查询的时候尽量减少term的长度（。prefixLength在QueryParser以及FuzzyQuery中可以设置。默认值为0，将比较所有的Term）
13 如果要过滤一些关键字 要尽量使用filter