7.8. 高度な機能

SearchFactory オブジェクトは、Hibernate Search の基礎となる Lucene リソースを追跡します。これは、Lucene にネイティブにアクセスする便利な方法です。SearchFactory は FullTextSession からアクセスできます。

FullTextSession fullTextSession = Search.getFullTextSession(regularSession);
SearchFactory searchFactory = fullTextSession.getSearchFactory();

Lucene のクエリーは IndexReader で実行されます。Hibernate Search は、パフォーマンスを最大化するためにインデックスリーダーをキャッシュするか、更新された IndexReader 軽減 I/O 操作を取得するために他の効率的なストラテジーを提供する場合があります。コードはこれらのキャッシュされたリソースにアクセスできますが、要件がいくつかあります。

IndexReader reader = searchFactory.getIndexReaderAccessor().open(Order.class);
try {
   //perform read-only operations on the reader
}
finally {
   searchFactory.getIndexReaderAccessor().close(reader);
}

この例では、SearchFactory は (シャード化ストラテジーに関連して) このエンティティーのクエリーに必要なインデックスを判別します。各インデックスで設定された ReaderProvider を使用して、関連するすべてのインデックスの上に複合 IndexReader を返します。この IndexReader は複数のクライアント間で共有されるため、以下のルールに従う必要があります。

これらのルール以外に、特にネイティブな Lucene クエリーを行うため、IndexReader を自由に使用できます。共有 IndexReaders を使用すると、たとえばファイルシステムから直接開くよりも、ほとんどのクエリーがより効率的になります。

open (Class…​types) メソッドの代替として、open (String…​indexNames) を使用して、1 つ以上のインデックス名で渡すことができます。このストラテジーを使用して、シャードが使用される場合に、インデックスタイプに対してインデックスのサブセットを選択することもできます。

IndexReader reader = searchFactory.getIndexReaderAccessor().open("Products.1", "Products.3");

Directory は、インデックスストレージを表すために Lucene で使用される最も一般的な抽象化です。Hibernate Search は Lucene Directory と直接対話することはありませんが、これらの対話は IndexManager 経由で抽象化されます。インデックスが必ずしもディレクトリーによって実装される必要はありません。

インデックスが Directory として表示され、アクセスする必要がある場合は、IndexManager からディレクトリーへの参照を取得できます。IndexManager を DirectoryBasedIndexManager にキャストし、getDirectoryProvider().getDirectory() を使用して基礎となる Directory への参照を取得します。これは推奨されていません.代わりに IndexReader を使用することが推奨されます。

場合によっては、特定のエンティティーのインデックス付きデータを複数の Lucene インデックスに分割 (シャード) すると役に立つことがあります。

シャード化のユースケースを以下に示します。

デフォルトでは、シャードの数が設定されていないとシャード化は有効になりません。これには、hibernate.search.<indexName>.sharding_strategy.nbr_of_shards プロパティーを使用します。

hibernate.search.<indexName>.sharding_strategy.nbr_of_shards = 5

データをサブインデックスに分割するには、IndexShardingStrategy を使用します。デフォルトのシャード化ストラテジーは、(FieldBridge によって生成された)ID 文字列表現のハッシュ値に従ってデータを分割します。これにより、シャードが大幅に分散されます。カスタムの IndexShardingStrategy を実装して、デフォルトのストラテジーを置き換えることができます。カスタムストラテジーを使用するには、hibernate.search.<indexName>.sharding_strategy プロパティーを設定する必要があります。

hibernate.search.<indexName>.sharding_strategy = my.shardingstrategy.Implementation

IndexShardingStrategy プロパティーでは、クエリーを実行するシャードを選択して検索を最適化することもできます。フィルターをアクティベートすることで、シャード化ストラテジーはクエリー (IndexShardingStrategy.getIndexManagersForQuery) に回答するために使用されるシャードのサブセットを選択できるため、クエリーの実行が速くなります。

各シャードには独立した IndexManager があるため、異なるディレクトリープロバイダーおよびバックエンド設定を使用するように設定できます。以下の例の Animal エンティティーの IndexManager インデックス名は Animal.0 から Animal.4 です。つまり、各シャードには所有するインデックス名の後に . (ドット) とそのインデックス番号が設定されます。

hibernate.search.default.indexBase = /usr/lucene/indexes
hibernate.search.Animal.sharding_strategy.nbr_of_shards = 5
hibernate.search.Animal.directory_provider = filesystem
hibernate.search.Animal.0.indexName = Animal00
hibernate.search.Animal.3.indexBase = /usr/lucene/sharded
hibernate.search.Animal.3.indexName = Animal03

上記の例では、設定はデフォルトの id 文字列ハッシュストラテジーを使用し、シャードは Animal インデックスを 5 つのサブインデックスに使用しています。すべてのサブインデックスはファイルシステムのインスタンスで、各サブインデックスが保存されるディレクトリーは、以下のようになります。

IndexShardingStrategy を実装する場合は、任意のフィールドを使用してシャード化の選択を判断できます。deletion、purge、purgeAll などの操作を処理するには、すべてのフィールド値またはプライマリー識別子を読み取れずにインデックスを返す必要があることもあります。このような場合、すべてのインデックスが返されるため、削除操作は、削除されるドキュメントが含まれる可能性のあるすべてのインデックスに伝播されます。

Lucene を使用するとユーザーは、org.apache.lucene.search.Similarity を拡張して、そのフラグ式をカスタマイズできます。このクラスで定義された抽象メソッドは、以下の式の係数と一致し、ドキュメント d のクエリー q のスコアを計算します。

org.apache.lucene.search.Similarity を拡張して、Lucene の診断式をカスタマイズします。抽象メソッドは、以下のようにドキュメント d のクエリー q のスコアを計算するために使用される式と一致します。

*score(q,d) = coord(q,d) · queryNorm(q) · ∑ ~t in q~ ( tf(t in d) ·
idf(t) ^2^ · t.getBoost() · norm(t,d) )*

この式の詳細は、本書の範囲外です。詳細は、Similarity の Java ドキュメントを参照してください。

Hibernate Search では、Lucene の類似性の計算を修正する方法を利用できます。

最初に、プロパティー hibernate.search.matchity を使用して、Similarity 実装の完全に指定されたクラス名を指定すると、デフォルトの類似性を設定できます。デフォルト値は org.apache.lucene.search.DefaultSimilarity です。

また、similarity プロパティーを設定して特定のインデックスに使用される類似性を上書きすることもできます。

hibernate.search.default.similarity = my.custom.Similarity

最後に、@Similarity アノテーションを使用してクラスレベルのデフォルトの類似性を上書きできます。

@Entity
@Indexed
@Similarity(impl = DummySimilarity.class)
public class Book {
...
}

たとえば、ドキュメントに用語が表示される頻度は重要ではないと仮定します。用語が 1 回出現したドキュメントは、複数回見つかったドキュメントと同様にスコア付けされる必要があります。この場合、メソッド tf(float freq) のカスタム実装は 1.0 を返します。

Hibernate Search では、インデックスプロセスでの例外の処理方法を設定できます。設定が指定されていない場合、デフォルトでは例外がログ出力に記録されます。以下のように例外ロギングメカニズムを明示的に宣言できます。

hibernate.search.error_handler = log

デフォルトの例外処理は、同期インデックスと非同期インデックスの両方で行われます。Hibernate Search は、デフォルトのエラー処理実装を上書きする簡単なメカニズムを提供します。

独自の実装を指定するには、handle(ErrorContext context) メソッドを提供する ErrorHandler インターフェイスを実装する必要があります。ErrorContext は、プライマリー LuceneWork インスタンス、LuceneWork、およびプライマリー例外により処理できなかった後続の LuceneWork インスタンスへの参照を提供します。

public interface ErrorContext  {
   List<LuceneWork> getFailingOperations();
   LuceneWork getOperationAtFault();
   Throwable getThrowable();
   boolean hasErrors();
}

このエラーハンドラーを Hibernate Search に登録するには、設定プロパティーで ErrorHandler 実装の完全修飾クラス名を宣言する必要があります。

hibernate.search.error_handler = CustomerErrorHandler

Hibernate Search は必要に応じて部分的にまたは完全に無効にできます。Hibernate Search のインデックスは、たとえばインデックスが読み取り専用の場合や、自動ではなく手動でインデックスを実行したい場合など、無効にすることができます。Hibernate Search を完全に無効にして、インデックス設定や検索を阻止することもできます。