Lucene.net を読み始めたところですが、REST ベースの Web サービスで Lucene.net の強力な検索機能を使用したいと考えています。
しかし、IIS があらゆる種類のロックの問題を引き起こすアプリケーション プールをリサイクルするため、すべての lucene 検索/インデックスなどを実行する Windows サービス (WCF を使用) を作成する必要があるというリンクに出会いました。
私の質問は、これは正しいですか？もしそうなら、Windows サービスを (WCF で) 作成せずにこの問題を解決する別の方法はありますか? また、REST ベースのサービスを使用しているため、これらのサービスから Windows WCF サービスを呼び出すと処理が遅くなりますか?
IndexWriter読んでいるうちに、クラスを使用してインデックス作成が行われていることに気付いたでしょう。LuceneIndexWriterでは、一度に 1 つのインスタンスしか開くことができません。デフォルトのロックを使用すると、インデックス ディレクトリにロック ファイルが作成され、他の IndexWriter インスタンスが作成されなくなります。このため、より制御しやすいプロセスでインデックス作成を実装する方がよい場合があります。
インデックス作成プロセスが極度の偏見で終了し、IndexWriterクラスが閉じられない場合、インデックス フォルダーのロックが維持され、他のインスタンスは許可されません。このため、Lucene では ( を使用してIndexWriter.unlock) インデックス付きフォルダーからロックを解除できます。これは危険な方法です。同じインデックスで 2 つの IndexWriter が開かれていると、インデックスが破損するからです。インデックス作成を実行している Windows サービスがあり、それがソリューション内でインデックス作成 (および更新) を実行する唯一のプロセスである場合、サービスの起動時にインデックス作成フォルダーのロックを確実に解除できます。Web メソッドからインデックス作成を実行している Web サービス ベースの環境では、ロックの問題の制御と回復が問題になります。
クラスはIndexSearcher検索に使用されます。これは、読み取り専用モードで、サービス ベースのコードから実行できます。この目的のために別の WCF メソッド セットを作成する必要はないと思います。
ボリュームによっては、インデックスのパフォーマンスを定期的に最適化する必要がある場合があります。もう一度別のプロセスでインデックス作成を行うことで、毎晩、毎週、または必要に応じて最適化をスケジュールできます。最適化は、1 つのメソッドの呼び出しによって行われます。
新しいデータをインデックス化するためのインデックス作成プロセスをいつ、どのように取得するか....インデックスを作成しているデータがわからないので、わかりにくいです。私のシナリオでは、大量の入力データを担当する WCF メソッドがあります。受信したデータをできるだけ早く検索できるようにする必要があります。そう、
私のモデル層には通知層があり、必要なタイプの新しいレコードが正常にコミットされると、単純な通知メッセージが MSMQ のローカル キューに挿入されます。
MSMQ の理由は、キューが永続的でトランザクション可能であり、システムの再起動によるクラッシュの後でもそこにあるすべてのメッセージを利用できるためです。
インデックス サービスは通知を受け取り、LuceneDocumentを構築してデータのインデックスを作成します。
インデックス作成サービスは、既存のインデックスを削除してデータベースをクロールすることにより、完全な再インデックスを実行するようにトリガーすることもできます。
編集：
アーキテクチャの例:
WCF サービス メソッドはデータを受け取り、それをモデル レイヤーにコミットします。モデル レイヤーは、アイテムに対して CRUD 操作が正常に行われたことをリッスンしているクライアントに通知します。リッスンしているクライアントは、通知をキューにポストします。
Windows サービスは、データのインデックス作成を処理し、インデックス作成要求のキューを監視します。
ASP.Net アプリは、検索機能を備えたユーザー インターフェイスを提供します。
アプリケーション プールのリサイクルを無効にして、IIS でアプリケーション/サービスをホストするだけです。構成変更のリサイクルを無効にするには、disallowRotationOnConfigChange パラメーターを使用します。
アプリケーションをインデックスの更新と検索の 2 つの部分に分割することもできます。
Windows サービスからのインデックス更新を処理し、IIS 部分で検索を処理します (読み取り専用)。これを行うには、インデックスの更新を検出するメカニズムを用意し、IndexSearchers. このようにして、サービスを使用することによるパフォーマンスの低下が懸念される場合でも、ユーザーにとって重要な側面である検索時間に影響を与えることはありません。この構成では、マスター インデックス更新ノードを使用して、ファーム内のさまざまな Web サーバーに検索を分散することもできます。IndexWriter唯一の欠点は、クラスに組み込まれているほぼリアルタイムの検索機能がないことです。
http://wiki.apache.org/lucene-java/NearRealtimeSearch
そうは言っても、特に NetNamedPipe を使用する同じマシンまたは NetTcp を使用するローカル LAN で実行している場合、Lucene 関数が WCF サービスを介して公開されているセットアップでパフォーマンスの問題が発生したことはありません。