2011-01-14 17 views
5

私はLucene 3.0.3を使用しています。私は同じインデックス上のすべての操作をカプセル化することを目的としたSpring Beanを作成しました。急速な変化と検索を可能にするためにLuceneではコミットされた表示が変更されます。ベストプラクティス

public class IndexOperations { 

    private IndexWriter writer; 
    private IndexReader reader; 
    private IndexSearcher searcher; 

    public void init() {...} 
    public void destroy() {...} 

    public void save(Document d) {...} 
    public void delete(Document d) {...} 
    public List<Document> list() {...} 

} 

、私は良いアイデアかもしれないオープンライター、リーダーと探索を残して思いました。しかし、問題は、再開するまで、作家のコミットされた変更を読者が見ることができないことです。この操作はコストがかかる可能性があるため、高速検索のための良い考えではないかもしれません。

この典型的なシナリオにはどのようなアプローチが最適でしょうか?

答えて

4

ライターは常に開いたままにしておきますが、リーダー/サーチャーを持続させないでください。検索者が必要なときIndexSearcher srch = new IndexSearcher(writer.getReader());この方法では、検索者はディスクにフラッシュされていなくても、最新の変更を得ることができます。

+0

@ Xoradap:良いアイデア、私はそれについて考えなかった。しかし、インデックスが大きい場合、これは非常にコストがかかりませんか? – sinuhepop

+0

@Sinuhe:いいえ、これはこれを行うための推奨方法です。ライターは必要に応じてディスクにフラッシュします。 – Xodarap

+0

@ Xoradap:いくつかのテストの後、あなたの方法は素晴らしいです!ありがとう。 – sinuhepop

2

このような使用例では、Luceneの上位抽象であるCompassを強くお勧めします。あなたの質問に特有の、それはあなたが持っているリーダー/ライター/検索者の問題を手動で制御する必要性を排除するトランザクションに加えて、より良い並行制御を提供します。それはかなり巧妙なものです、正直に言うとそれはかなりバロック的ですが、それは問題の良い解決策です。

Lucene 2.9は3.0ではなく、3.0よりも速くないため、積極的に管理されていませんが、安定しており、かなり文書化されています。 Lucene。

+1

コンパスとソルについて読んだことがあります。私は彼らがこの非常に単純なユースケースのために必要ではないと思うし、おそらく彼らは私がやるのと同じ方法でこれらのオブジェクトを開閉しているのだろう。コンパスについて、私はあなたが言う理由のために少し落胆しますが、多分私はもう一度試してみます。ありがとう。 – sinuhepop

+0

@シンフ:もちろん、それは必要ではありません。しかし、あなたの仕事は簡単になります。 – skaffman

+0

ちょうどメモ:elasticsearchはコンパス3.0です:)それを試してください。それはsolrよりももっと最近のluceneを使用します。 – Karussell

関連する問題