サポートコンソール開発者トライアルの開始お問い合わせ

第4章 キャッシュ内の値のクエリー

Data Grid を使用すると、クエリーを実行して、埋め込み Data Grid クラスターまたはリモート Data Grid サーバークラスターの両方で、データセット内の値を効率的かつ迅速に検索できます。

注記

Plain Old Java Object(POJO) として格納されているキャッシュ値、または プロトコルバッファー としてのみエンコードされているオブジェクトに、インデックスを付けてクエリーを実行できます。

4.1. キャッシュをインデックス化するための Data Grid の設定

キャッシュに値のインデックスを作成して、クエリーのパフォーマンスを向上させ、全文検索機能を使用します。

注記

Data Grid は、Apache Lucene テクノロジーを使用して、キャッシュ内の値にインデックスを付けます。

手順

  1. キャッシュ設定でのインデックス作成を有効にします。 

    <distributed-cache name="my-cache">
  <indexing>
    <!-- Indexing configuration goes here. -->
  </indexing>
</distributed-cache>

    <indexing> 要素を追加すると、自動的にインデックスが有効になります。設定スキーマでは enabled 属性のデフォルト値が false であっても、enabled 属性を含める必要はありません。

  2. インデックスを作成する各エンティティーを、indexed-entity 要素の値として指定します。 

    <distributed-cache name="my-cache">
  <indexing>
    <indexed-entities>
      <indexed-entity>...</indexed-entity>
    </indexed-entities>
  </indexing>
</distributed-cache>

古い Java オブジェクト

POJO を保存するキャッシュの場合、@Indexed でアノテーションが付けられた完全修飾クラス名を指定します。以下に例を示します。 

<indexed-entities>
  <indexed-entity>org.infinispan.sample.Car</indexed-entity>
  <indexed-entity>org.infinispan.sample.Truck</indexed-entity>
</indexed-entities>

Protobuf

Protobuf-encoded エントリーを保存するキャッシュの場合、Protobuf スキーマで宣言された Message を指定します。

たとえば、以下の Protobuf スキーマを使用します。 

package book_sample;

/* @Indexed */
message Book {

    /* @Field(store = Store.YES, analyze = Analyze.YES */
    optional string title = 1;

    /* @Field(store = Store.YES, analyze = Analyze.YES */
    optional string description = 2;
    optional int32 publicationYear = 3; // no native Date type available in Protobuf

    repeated Author authors = 4;
}

message Author {
    optional string name = 1;
    optional string surname = 2;
}

次に、indexed-entity 要素に以下の値を指定する必要があります。 

<indexed-entities>
  <indexed-entity>book_sample.Book</indexed-entity>
</indexed-entities>

4.1.1. プログラムによるキャッシュインデックスの有効化

Data Grid API 経由でプログラムを使用してキャッシュのインデックスを設定します。

手順

  • Data Grid を組み込みライブラリーとして使用する場合は、以下の例のように IndexingConfigurationBuilder クラスでキャッシュのインデックス作成を有効にし、設定します。 
import org.infinispan.configuration.cache.*;

ConfigurationBuilder config=new ConfigurationBuilder();
config.indexing().enable().storage(FILESYSTEM).path("/some/folder").addIndexedEntity(Book.class);

参照資料

4.1.2. インデックスアノテーション

Data Grid キャッシュでインデックス作成を有効にする場合、以下のアノテーションを使用します。

  • @indexed は、インデックスを作成する Java オブジェクトを示します。
  • @field は、オブジェクト内のフィールドがインデックス化される方法を制御します。

埋め込みライブラリーとしての Data Grid の場合は、これらのアノテーションを Java クラスに追加します。

Data Grid Server の場合は、これらのアノテーションを含む Protobuf スキーマ、.proto ファイルを定義します。

4.1.3. インデックス設定

Data Grid 設定は、インデックスの保存および構築方法を制御します。

4.1.3.1. インデックスストレージ

Data Grid がインデックスを保存する方法を設定できます。

  • ホストファイルシステム上。これはデフォルトであり、再起動間でインデックスを保持します。
  • JVM ヒープメモリー。これはインデックスが再起動後も存続しないことを意味します。
    インデックスは、小さなデータセットの場合にのみ、JVM ヒープメモリーに格納する必要があります。

ファイルシステム

<distributed-cache name="my-cache">
  <indexing storage="filesystem" path="${java.io.tmpdir}/baseDir">
    <!-- Indexing configuration goes here. -->
  </indexing>
</distributed-cache>

JVM ヒープメモリー

<distributed-cache name="my-cache">
  <indexing storage="local-heap">
    <!-- Additional indexing configuration goes here. -->
  </indexing>
</distributed-cache>

4.1.3.2. インデックスリーダー

インデックスリーダーは、クエリーを実行するためにインデックスへのアクセスを提供する内部コンポーネントです。インデックスのコンテンツが変更されると、Data Grid はリーダーを更新し、検索結果が最新の状態になるようにする必要があります。インデックスリーダーの更新間隔を設定できます。デフォルトでは、インデックスが最終更新以降に変更された場合、各クエリーの前に Data Grid はインデックスを読み取ります。 

<distributed-cache name="my-cache">
  <indexing storage="filesystem" path="${java.io.tmpdir}/baseDir">
    <!-- Sets an interval of one second for the index reader. -->
    <index-reader refresh-interval="1000"/>
    <!-- Additional indexing configuration goes here. -->
  </indexing>
</distributed-cache>

4.1.3.3. インデックスライター

インデックスライターは、パフォーマンスを改善するために時間の経過とともにマージできる 1 つ以上のセグメント (サブインデックス) で設定されるインデックスを構築する内部コンポーネントです。インデックスリーダーの操作では、すべてのセグメントを考慮する必要があるため、通常、セグメントが少ないということは、クエリー中のオーバーヘッドが少ないことを意味します。

Data Grid は Apache Lucene を内部的に使用し、メモリーとストレージという 2 つの層でエントリーにインデックスを付けます。新規エントリーは、最初にメモリーインデックスに移動してから、フラッシュが実行されると、設定されたインデックスストレージに移動します。定期的なコミット操作は、フラッシュしたデータからセグメントを作成し、すべてのインデックス変更を永続化します。

注記

index-writer 設定は任意です。デフォルトはほとんどの場合に機能するはずであり、カスタム設定はパフォーマンスを調整するためにのみ使用する必要があります。 

<distributed-cache name="my-cache">
  <indexing storage="filesystem" path="${java.io.tmpdir}/baseDir">
    <index-writer commit-interval="2000"
                  low-level-trace="false"
                  max-buffered-entries="32"
                  queue-count="1"
                  queue-size="10000"
                  ram-buffer-size="400"
                  thread-pool-size="2">
      <index-merge calibrate-by-deletes="true"
                   factor="3"
                   max-entries="2000"
                   min-size="10"
                   max-size="20"/>
    </index-writer>
    <!-- Additional indexing configuration goes here. -->
  </indexing>
</distributed-cache>
表4.1 インデックスライター設定属性
属性説明

commit-interval

メモリーにバッファーリングされたインデックスの変更がインデックスストレージにフラッシュされ、コミットが実行される時間 (ミリ秒単位)。操作にはコストがかかるため、小さな値は避けてください。デフォルトは 1000 ミリ秒 (1 秒) です。

max-buffered-entries

インデックスストレージにフラッシュされる前に、インメモリーにバッファーリングできるエントリーの最大数。値が大きくなると、インデックスが高速になりますが、より多くのメモリーが使用されます。ram-buffer-size 属性と組み合わせて使用すると、フラッシュは、最初に発生するイベントに対して発生します。

ram-buffer-size

追加されたエントリーと削除をインデックスストレージにフラッシュする前にバッファーリングするために使用できるメモリーの最大量。値が大きくなると、インデックスが高速になりますが、より多くのメモリーが使用されます。インデックス作成のパフォーマンスを向上させるには、max-buffered-entries の代わりに、この属性を設定する必要があります。max-buffered-entries 属性と組み合わせて使用すると、最初に発生したイベントに対してフラッシュが発生します。

thread-pool-size

インデックスへの書き込み操作を実行するスレッドの数。

queue-count

それぞれのインデックス化されたタイプに使用する内部キューの数。各キューは、インデックスに適用される変更のバッチを保持し、キューは並行して処理されます。キューの数を増やすと、インデックスのスループットが増えますが、ボトルネックが CPU である場合に限ります。最適な結果を得るには、thread-pool-size 値よりも大きい queue-count の 値を設定しないでください。

queue-size

各キューが保持できる要素の最大数。queue-size の値を増やすと、インデックス操作中に使用されるメモリー量が増えます。小さすぎる値を設定すると、インデックス作成操作がブロックされる可能性があります。

low-level-trace

インデックス化操作の低レベルのトレース情報を有効にします。この属性を有効にすると、パフォーマンスが大幅に低下します。この低レベルのトレースは、トラブルシューティングの最後のリソースとしてのみ使用する必要があります。

Data Grid がインデックスセグメントをマージする方法を設定するには、index-merge サブ要素を使用します。

表4.2 インデックスのマージ設定属性
属性説明

max-entries

インデックスセグメントがマージする前に持つことができるエントリーの最大数。この数を超えるエントリーを持つセグメントはマージされません。値を小さくすると、頻繁に変更されるインデックスでのパフォーマンスが向上します。値を大きくすると、インデックスが頻繁に変更されない場合に検索パフォーマンスが向上します。

factor

一度にマージされるセグメントの数。値が小さいほど、マージが頻繁に発生し、より多くのリソースが使用されますが、セグメントの総数は平均して少なくなり、検索パフォーマンスが向上します。より大きな値 (10 より大きい値) は、大量の書き込みシナリオに最適です。

min-size

バックグラウンドマージのセグメントの最小ターゲットサイズ (MB 単位)。このサイズよりも小さなセグメントは積極的にマージされます。値が大きすぎると、頻度は低くなりますが、マージ操作のコストが高くなる可能性があります。

max-size

バックグラウンドマージのセグメントの最大サイズ (MB 単位)。このサイズよりも大きなセグメントは、バックグラウンドでマージされることはありません。これを低い値に設定すると、メモリー要件が軽減され、最適な検索速度を犠牲にして、一部のマージ操作が回避されます。インデックスを強制的にマージする場合、この属性は無視され、代わりに max-forced-size が適用されます。

max-forced-size

強制マージのセグメントの最大サイズ (MB 単位) で、max-size 属性をオーバーライドします。これを max-size 以下の同じ値に設定します。ただし、値を低く設定しすぎると、ドキュメントが削除されるため、検索パフォーマンスが低下します。

calibrate-by-deletes

セグメントのエントリーをカウントする際に、インデックスで削除されたエントリーの数が考慮されるかどうか。false を設定すると、max-entries によってマージが頻繁に発生しますが、削除されたドキュメントが多いセグメントをより積極的にマージして、クエリーのパフォーマンスを向上させます。

参照資料

インデックス化要素および属性の詳細は、Data Grid Configuration Schema を参照してください。

4.1.4. インデックスの再構築

インデックスを再構築すると、キャッシュに保存されているデータから再構築されます。インデックス付きタイプやアナライザーの定義などを変更する場合は、インデックスを再構築します。同様に、何らかの理由でインデックスが削除されている場合は、インデックスを再構築する必要がある場合があります。

重要

インデックスの再構築プロセスは、グリッド内のすべてのデータに対して行われるため、完了するまでに長い時間がかかる場合があります。再構築操作の進行中は、クエリーが返す結果も少なくなる可能性があります。

インデックスを再構築する際に Data Grid は以下の警告メッセージをログに記録します。 

WARN: Rebuilding indexes also affect queries, that can return less results than expected.

手順

  • 以下のように reindexCache() メソッドを呼び出して、リモート Data Grid サーバーでインデックスを再構築します。 

    remoteCacheManager.administration().reindexCache("MyCache");

  • 以下のように、Data Grid を組み込みライブラリーとして使用する場合にインデックスを再構築します。 

    Indexer indexer = Search.getIndexer(cache);
CompletionStage<Void> future = index.run();
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.