Red Hat Summit第23章 Hibernate Search
23.1. Hibernate Search の使用
リンクのコピーリンクがクリップボードにコピーされました!
23.1.1. Hibernate Search について
リンクのコピーリンクがクリップボードにコピーされました!
Hibernate Search は、Hibernate アプリケーションに完全なテキスト検索機能を提供します。これは、全文、あいまい、位置情報検索などの SQL ベースのソリューションには適していないアプリケーションの検索に適しています。Hibernate Search は Apache Lucene を全文検索エンジンとして使用しますが、メンテナンスのオーバーヘッドを最小限に抑えるように設計されています。設定が完了したら、インデックス、クラスタリング、およびデータ同期は透過的に維持されるため、ビジネス要件を満たすことができます。
23.1.2. 概要
リンクのコピーリンクがクリップボードにコピーされました!
Hibernate Search はインデックスコンポーネントとインデックス検索コンポーネントで構成されており、どちらも Apache Lucene によってサポートされます。エンティティーがデータベースで挿入、更新、または削除されるたびに、Hibernate Search は（Hibernate イベントシステムから）このイベントを追跡し、インデックスの更新をスケジュールします。これらの更新はすべて、Apache Lucene API と直接対話せずに処理されます。代わりに、基礎となる Lucene インデックスとの対話は
IndexManager で処理されます。
インデックスが作成されると、基盤の Lucene インフラストラクチャーを処理するのではなく、エンティティーを検索し、管理エンティティーのリストを返すことができます。同じ永続コンテキストが Hibernate と Hibernate Search 間で共有されます。
FullTextSession クラスは Hibernate Session クラスの上に構築され、アプリケーションコードで統一された org.hibernate.Query または javax.persistence.Query API が HQL、JPA-QL またはネイティブクエリーの実行方法と全く同じ方法を使用できます。
注記
データベースと Hibernate Search の両方に対しては、JDBC または JTA で操作を実行するために、トランザクションで実行することが推奨されます。
注記
Hibernate Search はアトミックな会話として知られる、Hibernate / EntityManager の長い対話パターンで完全に問題なく機能します。
23.1.3. インデックスマネージャー
リンクのコピーリンクがクリップボードにコピーされました!
エンティティーがデータベースから挿入、更新、または削除されるたびに、Hibernate Search は Hibernate イベントシステムからこのイベントを追跡し、インデックスの更新をスケジュール設定します。基礎となる Lucene インデックスとの対話は IndexManager によって処理されます。各インデックスは名前で一意に識別されます。デフォルトでは、IndexManager と Lucene インデックスの間に 1 対 1 の関係があります。IndexManager は、選択した バックエンド、リーダーストラテジー、および選択した DirectoryProvider を含む特定のインデックス設定を抽象化します。
23.1.4. ディレクトリープロバイダーについて
リンクのコピーリンクがクリップボードにコピーされました!
Hibernate Search インフラストラクチャーの一部である Apache Lucene には、インデックスの保管にディレクトリーという概念があります。Hibernate Search は、ディレクトリープロバイダーを介して Lucene Directory インスタンスの初期化および設定を処理し ます。
Directory_provider プロパティーは、インデックスを保存するために使用するディレクトリープロバイダーを指定します。デフォルトのファイルシステムディレクトリープロバイダーは、ローカルファイルシステム を使用してインデックスを保存するファイルシステムです。
23.1.5. Worker について
リンクのコピーリンクがクリップボードにコピーされました!
Lucene インデックスへの更新は、すべてのエンティティーの変更を受け取る Hibernate Search ワーカー によって処理されます。最も一般的なコンテキストはトランザクションですが、エンティティーの変更数や他のアプリケーション（ライフサイクル）イベントの数によって異なる場合があります。
効率性を向上するために、対話はバッチ化され、通常はコンテキストの終了時に適用されます。トランザクション以外では、インデックスの更新操作は実際のデータベース操作の直後に実行されます。継続中のトランザクションの場合、インデックス更新操作はトランザクションのコミットフェーズに対してスケジュール設定され、トランザクションのロールバック時に破棄されます。worker は特定のバッチサイズ制限で設定でき、その後、インデックスはコンテキストに関係なく実行されます。
ワーカー設定オプションの詳細は、「ワーカー設定」 を参照してください。
この手法では、インデックス更新を処理するのに以下のようなメリットがあります。
- パフォーマンス: 操作がバッチで実行されると、Lucene インデックスのパフォーマンスが向上しました。
- ACIDity: 実行されるワークはデータベーストランザクションによって実行されたものと同じスコーピングを持ち、トランザクションがコミットされた場合にのみ実行されます。これは、厳密な意味では ACID ではありませんが、ACID の動作では、ソースからいつでも再構築できるため、完全なテキスト検索インデックスにはあまり役に立ちません。
2 つのバッチモード（スコープとトランザクション）は、自動コミットの動作とトランザクション動作に相当します。パフォーマンスの観点からは、transactional モードが推奨されます。スコープの選択は透過的に行われます。Hibernate Search はトランザクションの存在を検出し、スコーピングを調整します（ 「ワーカー設定」を参照してください）。
23.1.6. バックエンド設定と操作
リンクのコピーリンクがクリップボードにコピーされました!
23.1.6.1. バックエンド
リンクのコピーリンクがクリップボードにコピーされました!
Hibernate Search はさまざまなバックエンドを使用して、作業のバッチを処理します。バックエンドは、設定オプション
default.worker.backend に制限されません。このプロパティーは、バックエンド設定の一部である BackendQueueProcessor インターフェースの実装を指定します。バックエンド（ JMS バックエンドなど）を設定するには、追加の設定が必要です。
23.1.6.2. Lucene
リンクのコピーリンクがクリップボードにコピーされました!
Lucene モードでは、ノード(JVM)のすべてのインデックス更新は、ディレクトリープロバイダーを使用して同じノードで Lucene ディレクトリーに対して実行されます。このモードは、クラスター化されていない環境や、共有ディレクトリーストアを持つクラスター環境で使用します。
図23.1 Lucene バックエンドの設定
Lucene モードは、
Directory がロックストラテジーを管理する非クラスター化アプリケーションまたはクラスター化されたアプリケーションをターゲットにします。Lucene モードの主な利点は、Lucene クエリーの変更の単純化と即時表示です。Near Real Time(NRT)バックエンドは、クラスター化されず、共有されていないインデックス設定の代替バックエンドです。
23.1.6.3. JMS
リンクのコピーリンクがクリップボードにコピーされました!
ノードのインデックス更新は JMS キューに送信されます。一意のリーダーはキューを処理し、マスターインデックスを更新します。マスターインデックスは、マスター/スレーブパターンを確立するために定期的にスレーブコピーに複製されます。マスターは Lucene インデックスの更新を行います。スレーブは読み取りおよび書き込み操作を受け入れますが、ローカルインデックスコピーの読み取り操作を処理します。マスターは Lucene インデックスの更新のみを行います。更新操作にローカルの変更を適用するのは、マスターのみです。
図23.2 JMS バックエンドの設定
このモードは、スループットが重要であり、インデックス更新の遅延が発生するクラスター環境をターゲットにします。JMS プロバイダーは信頼性を確保し、スレーブを使用してローカルインデックスコピーを変更します。
23.1.7. リーダーストラテジー
リンクのコピーリンクがクリップボードにコピーされました!
クエリーの実行時に、Hibernate Search はリーダーストラテジーを使用して Apache Lucene インデックスと対話します。アプリケーションのプロファイル（ほとんどの場合、非同期インデックス更新など）に基づいてリーダーストラテジーを選択します。
23.1.7.3. カスタムリーダーストラテジー
リンクのコピーリンクがクリップボードにコピーされました!
org.hibernate.search.reader.ReaderProvider の実装を使用して、カスタムリーダーストラテジーを作成できます。実装はスレッドセーフである必要があります。
23.1.7.4. リーダーストラテジーの設定
リンクのコピーリンクがクリップボードにコピーされました!
以下のように、ストラテジーをデフォルト（
共有）から not-shared に変更します。
hibernate.search.[default|<indexname>].reader.strategy = not-shared
hibernate.search.[default|<indexname>].reader.strategy = not-shared
または、
my.corp.myapp.CustomReaderProvider をカスタムストラテジー実装に置き換えてリーダーストラテジーをカスタマイズします。
hibernate.search.[default|<indexname>].reader.strategy = my.corp.myapp.CustomReaderProvider
hibernate.search.[default|<indexname>].reader.strategy = my.corp.myapp.CustomReaderProvider
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}