JPA レベル 2 (L2) キャッシュ・プラグイン

WebSphere® eXtreme Scale には、OpenJPA と Hibernate Java Persistence API (JPA) プロバイダーの両方に対するレベル 2 (L2) のキャッシュ・プラグインが組み込まれています。これらのプラグインのいずれかを使用すると、アプリケーションは JPA API を使用します。データ・グリッドがアプリケーションとデータベースとの間に導入されて、応答時間が短縮されます。

eXtreme Scale を L2 キャッシュ・プロバイダーとして使用することにより、データ読み取りおよび照会時のパフォーマンスが向上し、データベースに対する負荷が軽減します。WebSphere eXtreme Scale ではキャッシュが すべてのプロセスで自動的に複製されるので、組み込みキャッシュ実装をしのぐ 利点があります。あるクライアントが値をキャッシュすると、他のすべてのクライアントが、そのキャッシュされた値をローカルのメモリー内で使用できるようになります。

L2 キャッシュ・プロバイダーのトポロジーおよびプロパティーは、persistence.xml ファイルで構成できます。これらのプロパティーの構成について詳しくは、JPA キャッシュ構成プロパティーを参照してください。

ヒント: JPA L2 キャッシュ・プラグインは、JPA API を使用するアプリケーションを必要とします。WebSphere eXtreme Scale API を使用して JPA データ・ソースにアクセスする場合は、JPA ローダーを使用します。詳しくは、JPA ローダーを参照してください。

JPA L2 キャッシュ・トポロジーに関する考慮事項

次の要因が、構成するトポロジーのタイプに影響を与えます。
  1. キャッシュに入れられる予想データ量
  2. 予想される読み取り/書き込み率
    読み取り/書き込み率は、L2 キャッシュのパフォーマンスに影響します。トポロジーごとに、読み取り操作および書き込み操作の処理は異なります。 ほとんどが読み取りのみのアプリケーションの場合、可能であれば、組み込みトポロジーおよびイントラドメイン・トポロジーを使用します。書き込みの方が多いアプリケーションの場合、イントラドメイン・トポロジーを使用します。
  3. データのキーによる検索に対する照会のパーセンテージ

    JPA 照会キャッシュが使用可能に設定されている場合、照会操作は JPA 照会キャッシュを使用します。読み取り/書き込み率が高いアプリケーションに対してのみ JPA 照会キャッシュを使用可能に設定します。例えば、読み取り操作が 99% に迫る場合です。JPA 照会キャッシュを使用する場合、組み込みトポロジーまたはイントラドメイン・トポロジーを使用する必要があります。

    キーによる検索操作では、ターゲット・エンティティーにリレーションシップがなければ、ターゲット・エンティティーが取り出されます。ターゲット・エンティティーに EAGER フェッチ・タイプとのリレーションシップがあれば、これらのリレーションシップがターゲット・エンティティーと一緒に取り出されます。JPA データ・キャッシュの中でこれらのリレーションシップを取り出すと、少数のキャッシュのヒットですべてのリレーションシップ・データを取得することになります。

  4. 容認されるデータの失効性レベル

    JVM がほとんどないシステムでは、書き込み操作でデータのレプリカ生成の待ち時間が発生します。 キャッシュの目的は、同期化された最終データ・ビューをすべての JVM にわたって保守することです。 イントラドメイン・トポロジーを使用している場合、書き込み操作ではデータのレプリカ生成で遅延が発生します。 このトポロジーを使用しているアプリケーションの場合、データを上書きする可能性のある失効読み取りと同時書き込みを容認できる必要があります。

イントラドメイン・トポロジー

イントラドメイン・トポロジーを使用すると、プライマリー断片がトポロジー内のすべてのコンテナー・サーバーに置かれます。これらのプライマリー断片には、区画のデータの全セットが含まれています。これらのプライマリー断片はすべて、キャッシュ書き込み操作も実行できます。この構成を使用すると、すべてのキャッシュ書き込み操作が単一のプライマリー断片を経由しなければならない組み込みトポロジーのボトルネックが解決します。

イントラドメイン・トポロジーでは、構成ファイルでレプリカを定義していたとしても、レプリカ断片は作成されません。それぞれの冗長プライマリー断片にはデータの全コピーが含まれているため、それぞれのプライマリー断片をレプリカ断片とみなすこともできます。この構成は、単一区画を使用し、組み込みトポロジーと似ています。

図 1. JPA イントラドメイン・トポロジー
JPA 組み込み区画化トポロジー
イントラドメイン・トポロジーでの関連 JPA キャッシュ構成プロパティー:
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,PlacementScope=CONTAINER_SCOPE,PlacementScopeTopology=HUB | RING

利点:

  • キャッシュ読み取りおよび更新がローカルで行われる。
  • 構成が簡単である。

制約:

  • このトポロジーは、コンテナー・サーバーに区画データの全セットを含めることができる場合に最適です。
  • すべてのコンテナー・サーバーはプライマリー断片をホストするため、レプリカ断片は、構成済みであったとしても配置されることはありません。ただし、すべてのプライマリー断片は、 他のプライマリー断片を使用して複製されることになるため、これらのプライマリー断片は互いのレプリカとなります。

組み込みトポロジー

ヒント: 最高のパフォーマンスのためにイントラドメイン・トポロジーを使用することを検討してください。

組み込みトポロジーでは、各アプリケーションのプロセス・スペース内にコンテナー・サーバーを作成します。OpenJPA および Hibernate が、キャッシュのメモリー内コピーで直接読み取りを行い、他のすべてのコピーに書き込みを行います。非同期レプリカ生成 を使用することによって、書き込みのパフォーマンスを向上させることができます。このデフォルト・トポロジーは、キャッシュ・データの量が少なく、1 つのプロセスに十分収まる場合に最も良く機能します。組み込みトポロジーを使用して、データの単一区画を作成します。

図 2. JPA 組み込みトポロジー
JPA 組み込みトポロジー
組み込みトポロジーでの関連 JPA キャッシュ構成プロパティー:
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED,MaxNumberOfReplicas=num_replicas,ReplicaMode=SYNC | ASYNC | NONE
利点:
  • すべてのキャッシュ読み取りが高速のローカル・アクセスである。
  • 構成が簡単である。
制約:
  • データ量が、プロセスのサイズに限られる。
  • すべてのキャッシュ更新は、1 つのプライマリー断片を通じて送信される。これにより、ボトルネックが発生する。

組み込みの区画化トポロジー

ヒント: 最高のパフォーマンスのためにイントラドメイン・トポロジーを使用することを検討してください。
注意:
組み込み区画化トポロジーで JPA 照会キャッシュを使用しないでください。 照会キャッシュは、エンティティー・キーのコレクションである照会結果を保管します。照会キャッシュはデータ・キャッシュからすべてのエンティティー・データを取り出します。 データ・キャッシュは複数のプロセス間で分割されるため、これらの追加呼び出しによって L2 キャッシュの利点が失われる可能性があります。

キャッシュ・データの量が多すぎて 1 つのプロセスに収まらないときは、組み込み区画化トポロジーを使用できます。 このトポロジーでは、データを複数のプロセス間で分割します。 データはプライマリー断片間で分割されるため、それぞれのプライマリー断片にデータのサブセットが含まれます。データベース待ち時間が大きい場合でも、このオプションを 使用できます。

図 3. JPA 組み込み区画化トポロジー
JPA 組み込み区画化トポロジー
組み込みの区画化トポロジーでの関連 JPA キャッシュ構成プロパティー:
ObjectGridName=objectgrid_name,ObjectGridType=EMBEDDED_PARTITION,ReplicaMode=SYNC | ASYNC | NONE,
NumberOfPartitions=num_partitions,ReplicaReadEnabled=TRUE | FALSE

利点:

  • 大容量のデータを保管できる。
  • 構成が簡単である。
  • キャッシュ更新が複数のプロセスに分散される。

制約:

  • ほとんどのキャッシュ読み取りおよび更新がリモートで行われる。

例えば、JVM あたり最大 1 GB で 10 GB のデータをキャッシュに入れる場合、Java 仮想マシンが 10 必要になります。したがって、区画数は 10 以上に設定されます。理想的には、区画数を素数に設定しなければなりません。そうすると、各断片が適当な量のメモリーを保管するようになります。通常、numberOfPartitions は、Java 仮想マシン の数に等しくなるようにします。このように設定すれば、各 JVM に 1 つの区画が格納されます。 レプリカ生成を使用可能にする場合、システム内の Java 仮想マシンの数を増やす必要があります。 そうでないと、各 JVM ごとに 1 つのレプリカ区画も格納することになり、この区画はプライマリー区画と同量のメモリーを消費します。

選択された構成のパフォーマンスを最大化するには、メモリー・サイズ設定および区画数の計算を参照してください。

例えば、4 つの Java 仮想マシン があるシステムで numberOfPartitions 設定値が 4 の場合、各 JVM は 1 つのプライマリー区画をホストします。読み取り操作では、25 パーセントの確率でローカルで使用可能な区画からデータを取り出すことができ、これは、リモート JVM からデータを取得する場合と比較してはるかに速くなります。照会の実行などの読み取り操作で 4 つの区画が均等に関わるデータ・コレクションを取り出す必要がある場合、呼び出しの 75 パーセントがリモートで、呼び出しの 25 パーセントがローカルです。ReplicaMode が SYNC または ASYNC に設定され、ReplicaReadEnabled が true に設定されている場合、4 つのレプリカ区画が作成され、これが 4 つの Java 仮想マシン に分散されます。各 JVM は、1 つのプライマリー区画と 1 つのレプリカ区画をホストします。 読み取り操作をローカルで実行する確率は、50 パーセントに増えます。4 つの区画が均等に関わるデータ・コレクションを取り出す読み取り操作では、50 パーセントのリモート呼び出しと 50 パーセントのローカル呼び出しがあります。ローカル呼び出しは、リモート呼び出しよりはるかに高速です。リモート呼び出しが行われると、パフォーマンスは落ちます。

リモート・トポロジー

注意:
リモート・トポロジーで JPA 照会キャッシュを使用しないでください。照会キャッシュは、エンティティー・キーのコレクションである照会結果を保管します。照会キャッシュはデータ・キャッシュからすべてのエンティティー・データを取り出します。 データ・キャッシュはリモートであるため、これらの追加呼び出しによって L2 キャッシュの利点が失われる可能性があります。
ヒント: 最高のパフォーマンスのためにイントラドメイン・トポロジーを使用することを検討してください。

リモート・トポロジーでは、すべてのキャッシュ・データを 1 つ以上の個別のプロセスに保管し、アプリケーション・プロセスのメモリー使用を減らします。区画化され、複製された eXtreme Scale データ・グリッドをデプロイすることによって、個別のプロセスへデータ配布するという利点が生かせます。 前のセクションで説明した組み込み構成および組み込み区画化構成とは対照的に、リモート・データ・グリッドを管理する場合は、アプリケーションおよび JPA プロバイダーから独立して管理する必要があります。

図 4. JPA リモート・トポロジー
JPA リモート・トポロジー
リモート・トポロジーでの関連 JPA キャッシュ構成プロパティー:
ObjectGridName=objectgrid_name,ObjectGridType=REMOTE

REMOTE ObjectGrid タイプでは、ObjectGrid およびデプロイメント・ポリシーが JPA アプリケーションとは別に定義されるため、プロパティー設定は必要ありません。JPA キャッシュ・プラグインは、リモートで、既存のリモート ObjectGrid に接続します。

ObjectGrid とのすべての対話がリモートで行われるため、このトポロジーは、すべての ObjectGrid タイプの中で、パフォーマンスが最も遅くなります。

利点:

  • 大容量のデータを保管できる。
  • アプリケーション・プロセスがキャッシュ・データから解放される。
  • キャッシュ更新が複数のプロセスに分散される。
  • 柔軟な構成オプションがある。

制約:

  • すべてのキャッシュ読み取りおよび更新がリモートで行われる。