ローカルのメモリー内のキャッシュ

最も単純なケースでは、WebSphere® eXtreme Scale は、ローカルの (非分散型の) メモリー内のデータ・グリッド・キャッシュとして使用できます。 ローカルのケースは、特に複数のスレッドにより一時データにアクセスして変更する必要がある、高い並行性を持つアプリケーションで有効になります。 ローカル・データ・グリッドに保持されるデータは、索引を付け、照会を使用して検索することができます。照会は、大規模なメモリー内データ・セットを処理するのに役立ちます。Java 仮想マシン (JVM)で提供されるサポートは、すぐに使用する準備ができているものの、データ構造に制限があります。

WebSphere eXtreme Scale でのローカルのメモリー内キャッシュ・トポロジーは、単一 Java 仮想マシン内で、一時データへの整合した トランザクション・アクセスを可能にするために使用されます。

図 1. ローカルのメモリー内のキャッシュ・シナリオ
ローカルのメモリー内のキャッシュ・シナリオ

利点

  • セットアップが簡単: ObjectGrid は、プログラマチックに作成することも、ObjectGrid デプロイメント記述子 XML ファイルまたは Spring などのその他のフレームワークを使用して宣言的に作成することもできます。
  • 高速: 各 BackingMap は、最適のメモリー使用効率および並行性が得られるように独立して調整できます。
  • 扱うデータ・セットが小さい単一 Java 仮想マシン・トポロジー、また頻繁にアクセスされるデータの キャッシングに最適。
  • トランザクション型。BackingMap 更新は、単一の作業単位にまとめることができ、Java Transaction Architecture (JTA) トランザクションなどの 2 フェーズ・トランザクションの最終参加者として統合することができます。

欠点

  • フォールト・トレラントでない。
  • データは複製されない。メモリー内キャッシュは読み取り専用参照データに最適。
  • スケーラブルでない。データベースが必要とするメモリーの量が Java 仮想マシンを 圧倒するおそれがある。
  • Java 仮想マシンを追加するときに、次のような問題が発生する。
    • データを簡単には区画化できない
    • Java 仮想マシン間で状態を手動で複製しなければならない。そうしないと、各キャッシュ・インスタンスが 同一データの別バージョンを保持するようになります
    • 無効化にかかるコストが高い。
    • 各キャッシュは個別にウォームアップが必要になる。ウォームアップは、有効なデータがキャッシュに設定されるようにデータをロードする 期間です。

使用する場合

ローカルのメモリー内キャッシュのデプロイメント・トポロジーは、キャッシュに入れるデータ量が小さく (1 つの Java 仮想マシンに収まる場合)、比較的安定している場合に限って使用するようにしてください。このアプローチの場合、不整合データの存在を 許容する必要があります。Evictor を使用して、最も使用頻度が高いデータまたは 最近使用されたデータをキャッシュに保持するようにすると、キャッシュ・サイズを小さく維持し、 データの関連性を高くすることができます。