7.2. Configuration (設定)
7.2.1. 最小設定
Hibernate Search は、設定および操作の柔軟性を提供するように設計されており、ほとんどのユースケースに合わせてデフォルト値を慎重に選択しています。少なくとも、Directory Provider とそのプロパティーを設定する必要があります。デフォルトの Directory Provider は filesystem で 、インデックスストレージにローカルファイルシステムを使用します。利用可能な Directory Providers およびその設定の詳細は、DirectoryProvider Configuration を参照してください。
Hibernate を直接使用する場合は、DirectoryProvider などの設定を、設定ファイル (hibernate.properties または ) で設定する必要があります。Jakarta Persistence 経由で Hibernate を使用している場合、設定ファイルは hibernate.cfg.xmlpersistence.xml になります。
その他のリソース
- 利用可能な Directory Providers およびその設定の詳細は、DirectoryProvider Configuration を参照してください。
7.2.2. IndexManager の設定
Hibernate Search は、このインターフェイスにいくつかの実装を提供します。
-
directory-based: LuceneDirectory抽象化を使用してインデックスファイルを管理するデフォルトの実装。 -
near-real-time: コミット時にディスクへの書き込みをフラッシュしないようにします。このインデックスマネージャーはDirectoryベースでもありますが、Lucene のほぼリアルタイムの NRT 機能を使用します。
デフォルト以外の IndexManager を指定するには、以下のプロパティーを指定します。
hibernate.search.[default|<indexname>].indexmanager = near-real-time
7.2.2.1. Directory-based
Directory-based 実装はデフォルトの IndexManager 実装です。これは高度な設定が可能で、リーダーストラテジー、バックエンド、およびディレクトリープロバイダーに個別の設定を可能にします。
7.2.2.2. Near Real Time
NRTIndexManager はデフォルトの IndexManager の拡張機能で、低レイテンシーインデックス書き込みに Lucene NRT、Near Real Time 機能を活用します。ただし、lucene 以外の代替のバックエンドの設定を無視し、Directory で排他的な書き込みロックを取得します。
IndexWriter は、低レイテンシーを提供するため、ディスクへの変更をすべてフラッシュしません。クエリーは、フラッシュされていないインデックスライターバッファーから更新された状態を読み取ることができます。ただし、これは、IndexWriter が強制終了したり、アプリケーションがクラッシュした場合に、インデックスを再構築する必要があるように更新が失われる可能性があることを意味します。
Near Real Time 設定は、上記のデメリットとマスターノードを個別に設定できるため、データが限定されたクラスター化されていない Web サイトに対して推奨されます。
7.2.2.3. Custom
カスタム実装の完全修飾クラス名を指定して、カスタマイズされた IndexManager を設定します。以下のように、実装に no-argument コンストラクターを設定します。
[default|<indexname>].indexmanager = my.corp.myapp.CustomIndexManager
カスタムインデックスマネージャーの実装には、デフォルトの実装と同じコンポーネントは必要ありません。たとえば、Directory インターフェイスを公開しないリモートインデックスサービスに委譲します 。
7.2.3. DirectoryProvider の設定
DirectoryProvider は Lucene Directory に関する Hibernate Search の抽象化で、基盤の Lucene リソースの設定および初期化を処理します。Directory Providers and Their Properties では Hibernate Search で利用可能なディレクトリープロバイダーの一覧と、対応するオプションを表示しています。
インデックス化された各エンティティーは Lucene インデックスに関連付けられます (複数のエンティティーが同じインデックスを共有している場合を除きます)。インデックスの名前は、@Indexed アノテーションの index プロパティーによって指定されます。Index プロパティーが指定されていない場合は、インデックスされたクラスの完全修飾名が名前として使用されます (推奨)。
DirectoryProvider および追加オプションは、接頭辞 hibernate.search.<indexname> を使用して設定できます。名前 default (hibernate.search.default) は予約されており、すべてのインデックスに適用されるプロパティーを定義するために使用できます。Configuring Directory Providers では、hibernate.search.default.directory_provider を使用してデフォルトのディレクトリープロバイダーをファイルシステムに設定する方法を示しています。その後に、hibernate.search.default.indexBase がインデックスのデフォルトのベースディレクトリーを設定します。その結果、エンティティー Status のインデックスが /usr/lucene/indexes/org.hibernate.example.Status に作成されます。
ただし、Rule エンティティーのインデックスは、メモリー内ディレクトリーを使用します。これは、このエンティティーのデフォルトのディレクトリープロバイダーが hibernate.search.Rules.directory_provider プロパティーによって上書きされるためです。
最後に、Action エンティティーは 、hibernate.search.Actions.directory_provider で指定されるカスタムディレクトリープロバイダー CustomDirectoryProvider を使用します。
インデックス名の指定
package org.hibernate.example;
@Indexed
public class Status { ... }
@Indexed(index="Rules")
public class Rule { ... }
@Indexed(index="Actions")
public class Action { ... }
ディレクトリープロバイダーの設定
hibernate.search.default.directory_provider = filesystem hibernate.search.default.indexBase=/usr/lucene/indexes hibernate.search.Rules.directory_provider = ram hibernate.search.Actions.directory_provider = com.acme.hibernate.CustomDirectoryProvider
上記の設定スキームを使用すると、ディレクトリープロバイダーやベースディレクトリーなどの一般的なルールを簡単に定義でき、これらのデフォルトをインデックスごとに後で上書きできます。
ディレクトリープロバイダーおよびそれらのプロパティー
- ram
- None
- Filesystem
ファイルシステムベースのディレクトリー使用されるディレクトリーは <indexBase> /< indexName > です。
- indexBase: ベースディレクトリー
- indexName: @Indexed.index を上書き (シャード化されたインデックスに便利です)
- locking_strategy: オプション。LockFactory Configuration を参照してください。
-
filesystem_access_type: この
DirectoryProviderで使用されるFSDirectory実装の正確なタイプを判別できます。許可される値はauto(デフォルト値。Windows 以外のシステムではNIOFSDirectory、Windwos ではSimpleFSDirectory)、simple (SimpleFSDirectory)、nio (NIOFSDirectory)、mmap (MMapDirectory)を選択します。この設定を変更する前に、これらのディレクトリー実装に関する Java ドキュメントを参照してください。NIOFSDirectoryまたはMMapDirectoryは、パフォーマンスを大幅に向上させる可能性がありますが、問題もあります。
filesystem-masterファイルシステムベースのディレクトリー
filesystemと類似しています。また、定期的にインデックスをソースディレクトリー (コピーディレクトリー) にコピーします。更新期間に推奨される値は (最低 50%)、情報をコピーする時間 (デフォルトは 3600 秒 - 60 分) です。
コピーは、増分コピーメカニズムをベースにしているため、コピーの平均時間が短縮されることに注意してください。
DirectoryProvider は通常、Jakarta Messaging バックエンドクラスターのマスターノードで使用されます。
buffer_size_on_copy最適化は、ご使用のオペレーティングシステムと利用可能な RAM によって異なります。多くユーザーは 16 から 64MB までの値を使用して良好な結果を報告しています。- indexBase: ベースディレクトリー
- indexName: @Indexed.index を上書き (シャード化されたインデックスに便利です)
- sourceBase: ソース (コピー) のベースディレクトリー。
-
source: ソースディレクトリーの接尾辞 (
デフォルトは @Indexed.index)。実際のソースのディレクトリー名は<sourceBase>/<source>です。 - refresh: 更新の間隔 (秒単位) です (コピーは更新の秒数ごとに行われます)。次の refresh 期間が経過してもコピーが進行中であると、次のコピー操作はスキップされます。
- buffer_size_on_copy: 単一の低レベルのコピー命令で移動するメガージの量。デフォルトは 16MB です。
- locking_strategy: オプション。LockFactory Configuration を参照してください。
-
filesystem_access_type: この
DirectoryProviderで使用されるFSDirectory実装の正確なタイプを判別できます。許可される値はauto(デフォルト値。Windows 以外のシステムではNIOFSDirectory、Windwos ではSimpleFSDirectory)、simple (SimpleFSDirectory)、nio (NIOFSDirectory)、mmap (MMapDirectory)を選択します。この設定を変更する前に、これらのディレクトリー実装に関する Java ドキュメントを参照してください。NIOFSDirectoryまたはMMapDirectoryではパフォーマンスが大幅に向上しますが、注意が必要な問題もあります。
filesystem-slaveファイルシステムベースのディレクトリー
filesystemと似ていますが、マスターバージョン (ソース) を定期的に取得します。ロックおよび一貫性のない検索結果を避けるため、2 つのローカルコピーが維持されます。更新期間に推奨される値は (最低 50%)、情報をコピーする時間 (デフォルトは 3600 秒 - 60 分) です。
コピーは、増分コピーメカニズムをベースにしているため、コピーの平均時間が短縮されることに注意してください。refresh 期間が経過してもコピーが進行中であると、次のコピー操作はスキップされます。
DirectoryProvider は通常、Jakarta Messaging バックエンドを使用するスレーブノードに使用されます。
buffer_size_on_copy最適化は、ご使用のオペレーティングシステムと利用可能な RAM によって異なります。多くユーザーは 16 から 64MB までの値を使用して良好な結果を報告しています。- indexBase: ベースディレクトリー
- indexName: @Indexed.index を上書き (シャード化されたインデックスに便利です)
- sourceBase: ソース (コピー) のベースディレクトリー。
-
source: ソースディレクトリーの接尾辞 (
デフォルトは @Indexed.index)。実際のソースのディレクトリー名は<sourceBase>/<source>です。 - refresh: 更新の間隔 (秒単位) です (コピーは更新の秒数ごとに行われます)。
- buffer_size_on_copy: 単一の低レベルのコピー命令で移動するメガージの量。デフォルトは 16MB です。
- locking_strategy: オプション。LockFactory Configuration を参照してください。
- retry_marker_lookup: オプションで、デフォルトは 0 です。Hibernate Search がソースディレクトリーのマーカーファイルをチェックする回数を定義します。試行ごとに 5 秒待機します。
-
retry_initialize_period: オプション。再試行初期化機能を有効にするために整数値を秒単位で設定します。スレーブがマスターインデックスを検出できない場合、アプリケーションがバックグラウンドで起動しないようにせずに再試行します。インデックスの初期化前に実行された FULLTEXT クエリーはブロックされず、空の結果が返されます。オプションを有効にしない、または明示的にゼロに設定すると、再試行タイマーのスケジュール設定ではなく、例外により失敗します。無効なインデックスなしでアプリケーションが起動しないようにし、初期化のタイムアウトを制御するには、代わりに
retry_marker_lookupを参照してください。 -
filesystem_access_type: この
DirectoryProviderで使用されるFSDirectory実装の正確なタイプを判別できます。許可される値は auto (デフォルト値。Windows 以外のシステムではNIOFSDirectory、Windwos ではSimpleFSDirectory)、simple (SimpleFSDirectory)、nio (NIOFSDirectory)、mmap (MMapDirectory)を選択します。この設定を変更する前に、これらのディレクトリー実装に関する Java ドキュメントを参照してください。NIOFSDirectoryまたはMMapDirectoryはパフォーマンスを大幅に向上させる可能性がありますが、問題にも認識する必要があります。
ビルトインディレクトリープロバイダーがニーズに適さない場合は、org.hibernate.store.DirectoryProvider インターフェイスを実装して独自のディレクトリープロバイダーを作成することができます。この場合、プロバイダーの完全修飾クラス名を directory_provider プロパティーに渡します。接頭辞 hibernate.search.<indexname> を使用して追加のプロパティーを渡すことができます。
7.2.4. Worker 設定
workder 設定では、Hibernate Search が Lucene と対話する方法を詳細化することができます。複数のアーキテクチャーコンポーネントと可能な拡張ポイントが存在します。詳しく見てみましょう。
ワーカー設定を使用して、Infinispan クエリーが Lucene と対話する方法を詳細化します。この設定には、いくつかのアーキテクチャーコンポーネントおよび可能な拡張ポイントを使用できます。
まず、Worker があります。Worker インターフェイスの実装は、すべてのエンティティーの変更を受け取り、コンテキストによってそれらをキューに登録し、コンテキストの終了時に適用します。特に ORM との接続で最も直感的なコンテキストはトランザクションです。このため、はデフォルトで TransactionalWorker を使用してトランザクションごとにすべての変更をスコープします。ただし、エンティティーの変更数やその他のアプリケーションライフサイクルイベントなどによってコンテキストが異なるシナリオを想定できます。
表7.1 スコープの設定
| プロパティー | 説明 |
|---|---|
|
|
使用する |
|
|
接頭辞 |
|
|
コンテキストごとにバッチ処理されるインデックス操作の最大数を定義します。制限に達すると、コンテキストが終了していなくてもインデックスがトリガーされます。このプロパティーは、 |
コンテキストが終了すると、インデックスの変更を準備して適用します。これは、新規スレッド内で同期または非同期に実行できます。同期更新には、常にインデックスがデータベースと同期しているという利点があります。一方、非同期の更新は、ユーザーの応答時間を最小限に抑えるのに役立ちます。欠点は、データベースとインデックスの状態間で不一致が生じる可能性があることです。
以下のオプションはインデックスごとに異なる場合があります。実際には、indexName 接頭辞が必要になるか、default を使用してすべてのインデックスのデフォルト値を設定する必要があります。
表7.2 実行設定
| プロパティー | 説明 |
|---|---|
|
|
|
|
| バックエンドは、スレッドプールを使用して、同じトランザクションコンテキスト (またはバッチ) から更新を並行して適用することができます。デフォルト値は 1 です。トランザクションごとに多数の操作がある場合は、大きな値を試すことができます。 |
|
| スレッドプールが不足している場合は、ワークキューの最大数を定義します。非同期実行のみに便利です。デフォルトは infinite です。制限に達すると、ワークはメインスレッドによって行われます。 |
現在、いずれの実行モードであっても、すべての作業は同じ仮想マシン内で行われます。単一仮想マシンの作業合計量は変更されていません。常に、より適切なアプローチ (つまり委任) があります。hibernate.search.default.worker.backend を設定すると、インデックス作業を別のサーバーに送信できます。このオプションも、インデックスごとに異なる方法で設定できます。
表7.3 バックエンドの設定
| プロパティー | 説明 |
|---|---|
|
|
|
- Java Messaging サービスのバックエンド設定
| プロパティー | 説明 |
|
| 必要に応じて InitialContext を開始する Java Naming および Directory Interface プロパティーを定義します。Java Naming and Directory Interface は、Java Messaging サービスのバックエンドによってのみ使用されます。 |
|
|
Java Messaging Service バックエンドには必須です。Java Messaging Service 接続ファクトリーを (Red Hat JBoss Enterprise Application Platform のデフォルトでは |
|
| Java Messaging Service バックエンドには必須です。Java Messaging Service キューを検索する Java Naming and Directory Interface 名を定義します。キューはワークメッセージをポストするために使用されます。 |
おそらく、表示されるプロパティーの一部は関連付けられるため、プロパティー値のすべての組み合わせが適切であるとは限りません。実際には、機能以外の設定を行うことができます。これは、特に、ここに示されるインターフェイスの独自の実装を提供する場合が該当します。独自の Worker または BackendQueueProcessor 実装を作成する前に、既存のコードを調査してください。
7.2.4.1. Jakarta Messaging マスター/スレーブバックエンド
このセクションでは、マスター/スレーブの Hibernate Search アーキテクチャーの設定方法について説明します。
図7.3 Jakarta Messaging バックエンドの設定
7.2.4.2. スレーブノード
すべてのインデックス更新操作は Jakarta Messaging キューに送信されます。インデックスクエリー操作は、ローカルインデックスコピーで実行されます。
Jakarta Messaging スレーブの設定
### slave configuration ## DirectoryProvider # (remote) master location hibernate.search.default.sourceBase = /mnt/mastervolume/lucenedirs/mastercopy # local copy location hibernate.search.default.indexBase = /Users/prod/lucenedirs # refresh every half hour hibernate.search.default.refresh = 1800 # appropriate directory provider hibernate.search.default.directory_provider = filesystem-slave ## Back-end configuration hibernate.search.default.worker.backend = jms hibernate.search.default.worker.jms.connection_factory = /ConnectionFactory hibernate.search.default.worker.jms.queue = queue/hibernatesearch #optional jndi configuration (check your Jakarta Messaging provider for more information) ## Optional asynchronous execution strategy # hibernate.search.default.worker.execution = async # hibernate.search.default.worker.thread_pool.size = 2 # hibernate.search.default.worker.buffer_queue.max = 50
ファイルシステムローカルコピーは、より高速な検索結果を得るために推奨されます。
7.2.4.3. マスターノード
すべてのインデックス更新操作は Jakarta Messaging キューから取得され、実行されます。マスターインデックスは定期的にコピーされます。
Jakarta Messaging キューのインデックス更新操作は実行され、マスターインデックスは定期的にコピーされます。
Jakarta Messaging Service Master 設定
### master configuration ## DirectoryProvider # (remote) master location where information is copied to hibernate.search.default.sourceBase = /mnt/mastervolume/lucenedirs/mastercopy # local master location hibernate.search.default.indexBase = /Users/prod/lucenedirs # refresh every half hour hibernate.search.default.refresh = 1800 # appropriate directory provider hibernate.search.default.directory_provider = filesystem-master ## Back-end configuration #Back-end is the default for Lucene
Hibernate Search フレームワークの設定に加えて、Jakarta Messaging を介してインデックスを処理するようメッセージ駆動 Bean を作成し、設定する必要があります。
メッセージ駆動型 Bean がインデックスキューを処理する
@MessageDriven(activationConfig = {
@ActivationConfigProperty(propertyName="destinationType",
propertyValue="javax.jms.Queue"),
@ActivationConfigProperty(propertyName="destination",
propertyValue="queue/hibernatesearch"),
@ActivationConfigProperty(propertyName="DLQMaxResent", propertyValue="1")
} )
public class MDBSearchController extends AbstractJMSHibernateSearchController
implements MessageListener {
@PersistenceContext EntityManager em;
//method retrieving the appropriate session
protected Session getSession() {
return (Session) em.getDelegate();
}
//potentially close the session opened in #getSession(), not needed here
protected void cleanSessionIfNeeded(Session session)
}
}
この例では、Hibernate Search ソースコードで利用可能な抽象 Jakarta Messaging コントローラークラスから継承し、Jakarta EE MDB を実装します。この実装は例として提供されており、Jakarta EE 以外のメッセージ駆動 Bean を利用するように調整できます。
7.2.5. Lucene インデックスのチューニング
7.2.5.1. Lucene インデックスのパフォーマンスチューニング
Hibernate Search は、mergeFactor、maxMergeDocs、maxBufferedDocs など、基礎となる Lucene IndexWriter に渡される一連のパラメーターを指定することで Lucence インデクスパフォーマンスを調整するのに使用されます。これらのパラメーターは、インデックスベースまたはシャードごとに、すべてのインデックスに適用されるデフォルト値として指定します。
各種ユースケースに合わせて調整できる低レベルの IndexWriter 設定がいくつかあります。これらのパラメーターは、indexwriter キーワードでグループ化されます。
hibernate.search.[default|<indexname>].indexwriter.<parameter_name>
特定のシャード設定の indexwriter 値に値が設定されていないと、Hibernate Search は index セクションをチェックしてから default セクションをチェックします。
以下の表の設定により、Animal インデックスの 2 つ目のシャードにこれらの設定が適用されます。
-
max_merge_docs= 10 -
merge_factor= 20 -
ram_buffer_size= 64MB -
term_index_interval= Lucene default
他のすべての値は、Lucene で定義されたデフォルトを使用します。
デフォルトでは、すべての値は Lucene の独自のデフォルトのままにします。Indexing Performance and Behavior Properties に一覧表示される値は、使用している Lucene のバージョンに応じて異なります。上記の値はバージョン 2.4 に相対的です。
Hibernate Search の以前のバージョンには batch および transaction プロパティーの概念がありました。バックエンドは常に同じ設定を使用して機能するため、これは変わりました。
表7.4 パフォーマンスおよび動作プロパティーのインデックス作成
| プロパティー | 説明 | デフォルト値 |
|---|---|---|
|
|
他のプロセスが同じインデックスに書き込む必要がない場合は |
|
|
|
各インデックスには、インデックスに適用される更新が含まれる個別の pipeline があります。このキューが満杯になると、ブロック操作になります。 |
|
|
| バッファーインメモリー削除の条件が適用され、フラッシュされるまでに最低限必要な削除用語を決定します。時点でバッファーされたドキュメントがメモリーにある場合、ドキュメントはマージされ、新しいセグメントが作成されます。 | Disabled (RAM 使用率によるフラッシュ) |
|
| インデックス作成中にメモリーでバッファーされたドキュメントの量を制御します。RAM が大きいほど消費されます。 | Disabled (RAM 使用率によるフラッシュ) |
|
| セグメント内で許容されるドキュメントの最大数を定義します。値を小さくすると、頻繁に変更されるインデックスでのパフォーマンスが向上します。値を大きくすると、インデックスが頻繁に変更されない場合に検索パフォーマンスが向上します。 | Unlimited (Integer.MAX_VALUE) |
|
| セグメントマージの頻度とサイズを制御します。 挿入時にセグメントインデックスをマージする頻度を決定します。値を小さくすると、インデックス処理時に使用される RAM が少なくなり、最適化されていないインデックスの検索速度が速くなりますが、インデックスの速度は遅くなります。値が大きいと、インデックス時により多くの RAM が使用され、最適化されていないインデックスの検索速度が遅くなるため、インデックスがより速くなります。そのため、大きな値 (> 10) はバッチインデックスの作成に最も適しており、対話的に維持されるインデックスに小さい値 (< 10) が適しています。この値は 2 未満にしないでください。 | 10 |
|
|
セグメントマージの頻度とサイズを制御します。このサイズより小さいセグメント (MB 単位) は常に次のセグメントマージ操作の対象となります。このパラメーターを高く設定しすぎると、マージ操作が頻繁に行われない場合でも、処理にコストがかかる可能性があります。 | 0 MB (実際 ~1K) |
|
| セグメントマージの頻度とサイズを制御します。 このサイズより大きいセグメント (MB 単位) は、大きなセグメントにマージされることはありません。 これにより、メモリー要件が減り、一部のマージ操作が最適な検索速度で回避されます。インデックスの最適化時にこの値は無視されます。
| 無制限 |
|
| セグメントマージの頻度とサイズを制御します。
このサイズよりも大きい (MB 単位) セグメントは、インデックスの最適化中にも大きなセグメントではマージされません (
| 無制限 |
|
| セグメントマージの頻度とサイズを制御します。
|
|
|
| ドキュメントバッファー専用の RAM の容量 (MB 単位) を制御します。Max_buffered_docs を一緒に使用すると、いずれのイベントに対してもフラッシュが発生します。 通常、インデックスのパフォーマンスを上げるには、ドキュメント数ではなく、RAM 使用率によってフラッシュし、RAM バッファーをできるだけ大きく使用するのが最良の方法です。 | 16 MB |
|
| インデックス化された期間の間隔を設定します。 値が大きくなると、IndexReader では使用されるメモリーが少なくなります。しかし、ランダムアクセスが遅くなります。値が小さいと、IndexReader の方がより多くのメモリーが使用され、用語へのランダムアクセスが速くなります。詳細は、Lucene ドキュメントを参照してください。 | 128 |
|
|
複合ファイル形式を使用すると、使用するファイル記述子が少なくなります。欠点は、インデックス作成にかかる時間と一時ディスク容量が多いことです。インデックス処理時間を短縮するために、このパラメーターを
ブール値のパラメーター。 | true |
|
| すべてのエンティティーの変更に Lucene インデックスの更新が必要であるわけではありません。更新されたエンティティープロパティー (dirty プロパティー) すべてがインデックス化されない場合、Hibernate Search はインデックス変更プロセスを省略します。
各更新イベントで呼び出す必要があるカスタムの
この最適化は、
ブール値のパラメーター。 | true |
blackhole バックエンドは 、インデックスのボトルネックを特定するツールとしてのみ、実稼働環境で使用することは意図されていません。
7.2.5.2. Lucene IndexWriter
各種ユースケースに合わせて調整できる低レベルの IndexWriter 設定がいくつかあります。これらのパラメーターは、indexwriter キーワードでグループ化されます。
default.<indexname>.indexwriter.<parameter_name>
シャード設定で indexwriter の値が設定されていない場合、Hibernate Search は index セクションを参照し、デフォルトのセクションを探します。
7.2.5.3. パフォーマンスオプションの設定
以下の設定では、これらの設定が Animal インデックスの 2 つ目のシャードに適用されます。
パフォーマンスオプションの設定例
default.Animals.2.indexwriter.max_merge_docs = 10 default.Animals.2.indexwriter.merge_factor = 20 default.Animals.2.indexwriter.term_index_interval = default default.indexwriter.max_merge_docs = 100 default.indexwriter.ram_buffer_size = 64
-
max_merge_docs= 10 -
merge_factor= 20 -
ram_buffer_size= 64MB -
term_index_interval= Lucene default
他のすべての値は、Lucene で定義されたデフォルトを使用します。
Lucene のデフォルト値が Hibernate Search のデフォルト設定です。したがって、以下の表に記載する値は、使用される Lucene のバージョンによって異なります。上記の値はバージョン 2.4 に相対的です。Lucene インデックスのパフォーマンスに関する詳細は、Lucene のドキュメントを参照してください。
バックエンドは常に同じ設定を使用して動作します。
表7.5 パフォーマンスおよび動作プロパティーのインデックス作成
| プロパティー | 説明 | デフォルト値 |
|---|---|---|
|
|
他のプロセスが同じインデックスに書き込む必要がない場合は |
|
|
|
各インデックスには、インデックスに適用される更新が含まれる個別の pipeline があります。このキューが満杯になると、ブロック操作になります。 |
|
|
| バッファーインメモリー削除の条件が適用され、フラッシュされるまでに最低限必要な削除用語を決定します。時点でバッファーされたドキュメントがメモリーにある場合、ドキュメントはマージされ、新しいセグメントが作成されます。 | Disabled (RAM 使用率によるフラッシュ) |
|
| インデックス作成中にメモリーでバッファーされたドキュメントの量を制御します。RAM が大きいほど消費されます。 | Disabled (RAM 使用率によるフラッシュ) |
|
| セグメント内で許容されるドキュメントの最大数を定義します。値を小さくすると、頻繁に変更されるインデックスでのパフォーマンスが向上します。値を大きくすると、インデックスが頻繁に変更されない場合に検索パフォーマンスが向上します。 | Unlimited (Integer.MAX_VALUE) |
|
| セグメントマージの頻度とサイズを制御します。 挿入時にセグメントインデックスをマージする頻度を決定します。値を小さくすると、インデックス処理時に使用される RAM が少なくなり、最適化されていないインデックスの検索速度が速くなりますが、インデックスの速度は遅くなります。値が大きいと、インデックス時により多くの RAM が使用され、最適化されていないインデックスの検索速度が遅くなるため、インデックスがより速くなります。そのため、大きな値 (> 10) はバッチインデックスの作成に最も適しており、対話的に維持されるインデックスに小さい値 (< 10) が適しています。この値は 2 未満にしないでください。 | 10 |
|
| セグメントマージの頻度とサイズを制御します。 このサイズより小さいセグメント (MB 単位) は常に次のセグメントマージ操作の対象となります。 このパラメーターを高く設定しすぎると、マージ操作が頻繁に行われない場合でも、処理にコストがかかる可能性があります。
| 0 MB (実際 ~1K) |
|
| セグメントマージの頻度とサイズを制御します。 このサイズより大きいセグメント (MB 単位) は、大きなセグメントにマージされることはありません。 これにより、メモリー要件が減り、一部のマージ操作が最適な検索速度で回避されます。インデックスの最適化時にこの値は無視されます。
| 無制限 |
|
| セグメントマージの頻度とサイズを制御します。
このサイズよりも大きい (MB 単位) セグメントは、インデックスの最適化中にも大きなセグメントではマージされません (
| 無制限 |
|
| セグメントマージの頻度とサイズを制御します。
|
|
|
| ドキュメントバッファー専用の RAM の容量 (MB 単位) を制御します。Max_buffered_docs を一緒に使用すると、いずれのイベントに対してもフラッシュが発生します。 通常、インデックスのパフォーマンスを上げるには、ドキュメント数ではなく、RAM 使用率によってフラッシュし、RAM バッファーをできるだけ大きく使用するのが最良の方法です。 | 16 MB |
|
| インデックス化された期間の間隔を設定します。 大きな値を設定すると、IndexReader が使用するメモリーは少なくなりますが、ランダムアクセスの速度が遅くなります。値を小さくすると、IndexReader によりより多くのメモリーが使用され、用語へのランダムアクセスが速くなります。詳細は、Lucene ドキュメントを参照してください。 | 128 |
|
|
複合ファイル形式を使用すると、使用するファイル記述子が少なくなります。欠点は、インデックス作成にかかる時間と一時ディスク容量が多いことです。インデックス処理時間を短縮するために、このパラメーターを
ブール値のパラメーター。 | true |
|
| すべてのエンティティーの変更に Lucene インデックスの更新が必要であるわけではありません。更新されたエンティティープロパティー (dirty プロパティー) すべてがインデックス化されない場合、Hibernate Search はインデックス変更プロセスを省略します。
各更新イベントで呼び出す必要があるカスタムの
この最適化は、
ブール値のパラメーター。 | true |
7.2.5.4. インデックス速度の調整
アーキテクチャーが許可する場合、インデックスの書き込み効率を向上させるために default.exclusive_index_use=true のままにします。
インデックスの速度を調整する場合は、最初にオブジェクトの読み込みの最適化に焦点を合わせ、次にインデックスプロセスのチューニングの基準として達成するタイミングを使用することが推奨されます。blackhole をワーカーバックエンドとして設定し、インデックスルーチンを開始します。このバックエンドは、Hibernate Search を無効にしません。インデックスに必要な変更セットが生成されますが、それらをインデックスにフラッシュするのではなく破棄します。hibernate.search.indexing_strategy を manual に設定するのとは対照的に、blackhole を使用すると、関連するエンティティーも再インデックス化されるため、データベースがより多くのデータを読み込む可能性があります。
hibernate.search.[default|<indexname>].worker.backend blackhole
blackhole バックエンドは 、インデックスのボトルネックを特定する診断ツールとしてのみ、実稼働環境で使用することは意図されていません。
7.2.5.5. コントロールセグメントサイズ
以下のオプションは、作成されるセグメントの最大サイズを設定します。
-
merge_max_size -
merge_max_optimize_size -
merge_calibrate_by_deletes
コントロールセグメントサイズ
//to be fairly confident no files grow above 15MB, use: hibernate.search.default.indexwriter.ram_buffer_size = 10 hibernate.search.default.indexwriter.merge_max_optimize_size = 7 hibernate.search.default.indexwriter.merge_max_size = 7
マージセグメントが 2 つの大きなセグメントに結合するため、マージ操作の max_size はハード制限セグメントサイズの半分未満に設定します。
新しいセグメントは、当初は予想よりも大きくなる場合がありますが、セグメントが ram_buffer_size よりも大きく作成されることは決してありません。このしきい値は予測としてチェックされます。
7.2.6. LockFactory 設定
Lucene ディレクトリーは、Hibernate Search によって管理される各インデックスの LockingFactory を介してカスタムロックストラテジーで設定できます。
一部のロックストラテジーには、ファイルシステムレベルのロックが必要で、RAM ベースのインデックスで使用できます。このストラテジーを使用する場合は、IndexBase 設定オプションを指定して、ロックマーカーファイルを保存するファイルシステムの場所を指定する必要があります。
ロックファクトリーを選択するには、hibernate.search.<index>.locking_strategy オプションを以下のオプションのいずれかに設定します。
- ˆsimple
- native
- single
- none
表7.6 利用可能な LockFactory 実装の一覧
| 名前 | クラス | 説明 |
|---|---|---|
|
LockFactory Configuration | org.apache.lucene.store.SimpleFSLockFactory | Java の File API に基づく安全な実装では、マーカーファイルを作成してインデックスの使用をマークします。 何らかの理由でアプリケーションを強制終了する必要がある場合には、このファイルを削除してから再起動する必要があります。 |
|
| org.apache.lucene.store.NativeFSLockFactory |
この実装では、NFS で既知の問題があるため、ネットワーク共有で使用しないでください。
|
|
| org.apache.lucene.store.SingleInstanceLockFactory | この LockFactory はファイルマーカーを使用しませんが、メモリーに保持される Java オブジェクトロックであるため、インデックスが他のプロセスで共有されないことが確実な場合にのみ使用できます。
これは、 |
|
| org.apache.lucene.store.NoLockFactory | このインデックスへの変更は、ロックによって調整されません。 |
以下は、ロックストラテジーの設定例です。
hibernate.search.default.locking_strategy = simple hibernate.search.Animals.locking_strategy = native hibernate.search.Books.locking_strategy = org.custom.components.MyLockingFactory
7.2.7. インデックス形式の互換性
Hibernate Search では現在、アプリケーションを新しいバージョンへの移植を容易にする後方互換性の API やツールは提供されていません。API は、インデックスの書き込みおよび検索に Apache Lucene を使用します。インデックス形式の更新が必要になる場合があります。この場合、Lucene が古い形式を読み取れない場合は、データのインデックスを再作成する必要があります。
インデックス形式を更新する前にインデックスをバックアップします。
Hibernate Search は、hibernate.search.lucene_version 設定プロパティーを公開します。このプロパティーは、古いバージョンの Lucene に定義されている動作に準拠するように Analyzers およびその他の Lucene クラスに指示します。lucene-core.jar に含まれる org.apache.lucene.util.Version も参照してください。このオプションを指定しないと、Hibernate Search はバージョンのデフォルトを使用するよう Lucene に指示します。使用されるバージョンは、アップグレード時に自動的に変更されないように設定に明示的に定義することが推奨されます。アップグレード後、必要に応じて設定値を明示的に更新できます。
Lucene 3.0 の Created Index と互換性を持たせるようにアナライザーを強制する
hibernate.search.lucene_version = LUCENE_30
設定した SearchFactory はグローバルであり、関連するパラメーターが含まれるすべての Lucene API に影響します。Lucene が使用され、Hibernate Search がバイパスされる場合には、一貫した結果を得るために同じ値を適用してください。
