lucene并行建索引解决方案 .

 转：http://blog.csdn.net/pwlazy/article/details/1511097

http://blog.csdn.net/pwlazy/article/category/225768    lucene

 

 

背景：单线程为30万条数据建索引花了10分钟，为了提高效率采用多线程
 
 起初我采用多个线程共享一个indexwriter实例（也意味着往同一个目录写索引），这是
 lucene in action 和lucene wiki的推荐做法，不知道到为什么总是报FileNotFoundException，
 很让人困惑。偶尔会成功一次。这个错误让我想起另外一个问题，就是在建索引的时候搜索也会报这个
 错误，lucene in action 明明也说了建索引读的时候没问题。
 
 言归正传，我第二次尝试使用每个线程单独拥有自己的indexwriter实例，但往同一个目录写索引，果然报了
 写锁的错， 这和书上说的很一致。
 
 最后没办法了，我使用每个线程单独使用自己的实例，往自己的目录写索引，最后一个干完的线程将所有的索引合并
 比如我开了4个线程，那么就有5个目录build_index,build_index1,build_index2,build_index3,build_index4
 线程1往build_index1中写，线程2往build_index2，。。。依次类推，最后一个干完的将build_index1-4目录的索引合并到
 build_index.
 
 
 我开了4个线程尝试发现也要花大概7-8分钟，合并索引的过程非常快20秒左右。
 开了10个线程，整个过程需要6分多钟，合并索引也只花了21秒。

似乎效果并不明显,这因该是因为数据量还不够大引起的,数据量越大,并行的优势会越明显
 
 可见合并索引的过程非常快，这又提供了另外的好处，我们通常将build_index作为搜索目录，就像上面说的那样，建索引的过程 会影响搜索（虽然按照书上说是不影响的），如果我们采用这种方案，建索引的绝大部分过程其实与build_index目录无关，只有最后 合并的时候需要用到build_index，但那个过程又非常的快速，所以可以极大的缓解建索引给搜索带来的问题。
 

顺便说：当然你也可以再开一个通知线程专门等待索引线程，当索引线程完毕之后加入通知线程的队列，通知线程发现自己的队列有通知记录就开始合并索引，这样就不用所有的线程完毕之后才开始合并索引。（这种方案待尝试）

 如果条件允许，你可以扩展一下这个方案，将多线程索引升级为多台机器同时建。