ドメインモデルの変更でLuceneインデックスを最新の状態に保つための戦略

Question

アプリケーションのドメインモデルオブジェクトに変更が加えられたときに、Luceneインデックスを最新の状態に保つことに対する人々の考えを知りたいと考えていました。

問題のアプリケーションは、Hibernateを使用するJava/J2EEベースのWebアプリケーションです。私が現在作業している方法は、Hibernateのマップされたモデルオブジェクトがすべて、Luceneに記録されたキー/値ペアのセットを返すことができる共通の "Indexable"インターフェイスを実装していることです。このようなオブジェクトを含むCRUD操作が実行されるたびに、JMSキューを介してメッセージ駆動型Beanに送信します。このBeanは、オブジェクトの主キーと、インデックス付きオブジェクトのindex（）メソッドから返されたキー/値のペアを記録します。提供されます。

このスキームに関する主な心配は、MDBが遅れて到着するインデックス処理に追いつかず、ある種のエラー/例外がオブジェクトのインデックスを停止した場合です。その結果、並べ替えまたは長い期間の古いインデックスが作成されます。

基本的に私はこの種のことについて他の人たちがどのような戦略を思いついたのか不思議に思っていました。必ずしも1つの正解を求めているわけではありませんが、私の脳が代替案を考えるには「ホワイトボード」のアイデアのリストを想像しています。

Answer 1

メッセージを変更します。主キーと現在の日付を入力し、キーと値のペアは入力しないでください。 mdbは主キーでエンティティを取得し、index（）を呼び出します。インデックスを作成した後、インデックスに「更新」された値をメッセージの日付に設定します。メッセージの日付がインデックスの「更新された」フィールドの後である場合にのみ、インデックスを更新します。この方法では、常に現在のキーと値のペアを最初にフェッチするので、後ろに出ることはできません。

代替手段としては、http://www.compass-project.orgをご覧ください。

Answer 2

受け入れられる回答は現在8歳ですが、非常に古いです。

コンパスプロジェクトは、主要開発者が優れたElasticsearchを作成するために移動して以来、もはや長期間使用されていません。

現代的な答えはHibernate Searchです。これは偶然にもLuceneインデックスに直接またはElasticsearchでマップできます。