最も単純なケースでは、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 を使用して、最も使用頻度が高いデータまたは
最近使用されたデータをキャッシュに保持するようにすると、キャッシュ・サイズを小さく維持し、
データの関連性を高くすることができます。