はい、私はあなたが説明していることとまったく同じようにそれを使用しました。 2つのサービスがありました。1つは読み取り用、もう1つは書き込み用ですが、これは複数のリーダーがあったためです。 1つのサービス（ライター）だけでそれを実行し、リーダーをWebアプリとサービスに組み込むことができたと確信しています。
私は一般的なデータベースインデクサーとしてlucene.netを使用したので、返されるのは基本的にDB ID（インデックス付きの電子メールメッセージ）であり、検索結果などを入力するのに十分な情報を取得するためにも使用しました。データベース。どちらの場合もうまく機能しました。IDを取得したり、IDを選択したりする必要があるため、SQLの処理が少し遅くなる可能性があります。これを回避するには、一時テーブル（ID行のみを含む）を作成します。ファイル（luceneからの出力）から一括挿入してから、メッセージテーブルに結合します。ずっと速かった。
Luceneは完璧ではありません。また、リレーショナルデータベースボックスの外側を少し考える必要があります。これは、全体的に1つではないためですが、その機能は非常に優れています。一見の価値があり、MS SQLのFTIのような「おっと、申し訳ありませんが、インデックスを再構築する必要があります」という問題はありません。
ところで、私たちは2,000万から5,000万の電子メール（および約100万の一意の添付ファイル）を処理していました。合計で約20 GBのluceneインデックス、および250GB以上のSQLデータベースと添付ファイルです。
控えめに言っても、パフォーマンスは素晴らしかったです。マージ係数（インデックスセグメントをマージするとき）について考え、微調整するようにしてください。複数のセグメントがある場合でも問題はありませんが、それぞれに1milのアイテムがある2つのセグメントをマージしようとすると、大きな問題が発生する可能性があります。また、時間がかかりすぎるとプロセスを強制終了するウォッチャースレッドがあります... ..（はい、それはしばらくの間私たちのお尻を蹴った）。したがって、モノごとのドキュメントの最大数を低く抑えます（つまり、私たちが行ったようにmaxintに設定しないでください！）
Corey Tragerを編集して、BugTracker.NETでLucene.NETを使用する方法をここに文書化しました。