| Oracle® Coherenceスタート・ガイド リリース3.6 B61369-01 |
|
 戻る |
 次へ |
この章では、バッキング・マップを使用したCoherence記憶域について説明します。この章は次の各項で構成されています。
Coherenceのパーティション（分散）キャッシュ・サービスには、3つの個別の層があります。
クライアント・ビュー: クライアント・ビューは、基礎となるパーティション・データにアクセスできる仮想層を表します。この層へはNamedCacheインタフェースを使用してアクセスします。この層では、NearCache、ContinuousQueryCacheなどの統合データ構造も作成できます。
ストレージ・マネージャ: ストレージ・マネージャは、クライアント層からのキャッシュ関連リクエストを処理するサーバー側の層です。これは、実際のキャッシュ・データ（プライマリ・コピーおよびバックアップ・コピー）、およびロック、イベントリスナー、マップ・トリガーなどに関する情報を保持するデータ構造を管理します。
バッキング・マップ: バッキング・マップは、実際のデータを保持するサーバー側のデータ構造です。
Coherence 3.xを使用すると、多くのすぐに使えるバッキング・マップ実装およびカスタム・バッキング・マップ実装を構成できます。基本的には、これらのすべてのマップ実装で把握が必要な唯一の制約は、ストレージ・マネージャではすべてのキーと値が内部（バイナリ）形式で提供されていることです。その内部データをオブジェクト形式との変換に対応させるために、ストレージ・マネージャではBackingMapManagerContext参照でバッキング・マップを実装できます。
図14-1は、バッキング・マップの概念的なビューを示しています。
次のような多数の操作タイプがバッキング・マップに対して実行されます。
アプリケーションの使用によって実行される通常のアクセスと更新操作。たとえば、NamedCache.get()コールは、対応するバッキング・マップ上のMap.get()コールを自動的に実行します。NamedCache.invoke()コールは、Map.get()のシーケンスを実行してからMap.put()が続く場合があります。NamedCache.keySet(filter)コールは、Map.entrySet().iterator()ループを実行する場合があります。
時間ベースの有効期限またはサイズベースのエビクションによって実行される削除操作。たとえば、クライアント層からのNamedCache.get()コールまたはNamedCache.size()コールは、エントリ有効期限のタイムアウトによってMap.remove()コールを呼び出すことがあります。また、バッキング・マップ内のデータ合計量が構成済の高水位標値に達して、NamedCache.put()コールが多数のMap.remove()コール（異なるキーに対して）を呼び出すことがあります。
（リードスルー機能またはリードアヘッド機能で構成されたバッキング・マップに対する）CacheStore.load()操作によって実行される挿入操作。
パーティション分散による統合アクセスと更新（クラスタ・ノードのフェイルオーバーまたはフェイルバックによって発生する場合もあります）。この場合、アプリケーション層のコールがなくても、多数のエントリがバッキング・マップに対して挿入されたり削除されることがあります。
実際の実装に応じて、バッキング・マップは次のいずれかの方法でキャッシュ・データを保存します。
on-heapメモリー
off-heapメモリー
ディスク（メモリーマップ・ファイルまたはインプロセス・データベース）
前述のいずれかの組合せ
データをメモリーに保存しておくと、アクセスと更新の待機時間が大幅に短縮されて使用頻度が最も高まります。
大半の場合、データ・グリッドに配置されたデータの合計量がメモリーの既定量を超えていないことをアプリケーションで確認する必要があります。これはアプリケーション層ロジックで直接実行するか、サイズベースまたは有効期間ベースのエビクションを自動的に使用して実行できます。当然、Coherenceキャッシュに保持されるデータの合計量は、すべての対応バッキング・マップのデータ量の合計と同じです（対応するパーティション・キャッシュ・サービスを記憶域有効モードで実行するクラスタ・ノードごとに1つ）。
キャッシュ構成に関して次の抜粋を考慮してください。
<backing-map-scheme> <local-scheme/> </backing-map-scheme>
前述のバッキング・マップはcom.tangosol.net.cache.LocalCacheのインスタンスであり、事前設定されたサイズ制限はなく、明示的に管理する必要があります。そのようにしないと、JMVでメモリー不足が発生する場合があります。
<backing-map-scheme>
<local-scheme>
<high-units>100m</high-units>
<unit-calculator>BINARY</unit-calculator>
<eviction-policy>LRU</eviction-policy>
</local-scheme>
</backing-map-scheme>
このバッキング・マップはcom.tangosol.net.cache.LocalCacheでもあり、最大容量が100MBの制限があります。このバッキング・マップに保持されるデータの合計量が高水位標を超えると、エントリの一部がバッキング・マップから削除され、低水位標値まで量を減らします（<low-units>構成要素: これは<high-units>の75%にデフォルト設定されています）。削除されるエントリの選択は、LRU（最低使用頻度（Least Recently Used））エビクション・ポリシーに基づきます。その他のオプションは、LFU（最低アクセス頻度（Least Frequently Used））およびハイブリッド（LRUとLFUの組合せ）です。<high-units>の値は2GBまでに制限されています。その制限を克服するために（ただし下位互換性は保持して）、Coherence 3.5では<unit-factor>要素が導入されました。たとえば、<high-units>値が8192で<unit-factor>が1048576の場合、高水位標値は8GBになります（次の構成引用を参照）。
<backing-map-scheme>
<local-scheme>
<expiry-delay>1h</expiry-delay>
</local-scheme>
</backing-map-scheme>
このバッキング・マップは、1時間以上にわたって更新されなかったエントリを自動的に削除します。その場合の削除は遅延型であり、最新の更新から1時間後にいつでも発生する可能性があることに注意してください。Coherenceの仕様では、1時間前より古いエントリはコール側に返されません。
<backing-map-scheme>
<external-scheme>
<high-units>100</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
<nio-memory-manager>
<initial-size>1MB</initial-size>
<maximum-size>100MB</maximum-size>
</nio-memory-manager>
</external-scheme>
</backing-map-scheme>
このバッキング・マップは、com.tangosol.net.cache.SerializationCacheのインスタンスで、拡張（nio）メモリーに値を保存し、最大100MB（100×1048576）の容量制限があります。当然のことながら、off-heap（またはfile-mapped）であるこのキャッシュのバックアップ記憶域は次のように構成します。
<backup-storage> <type>off-heap</type> <initial-size>1MB</initial-size> <maximum-size>100MB</maximum-size> </backup-storage>
Coherence 3.5以前では、バッキング・マップには対応ノードに所有されるすべてのパーティションに対するエントリが含まれていました（パーティション送信の際、クライアントの見地からすると一時的に所有されていない稼働中エントリも保持されることがありました）。
図14-2は、従来のバッキング・マップ実装の概念的なビューを示しています。
Coherence 3.5にはパーティション・バッキング・マップの概念が導入されています。これは、基本的には、実際のマップ実装の多重化で、それぞれ同じパーティションに属するエントリのみが含まれます。
図14-3は、パーティション・バッキング・マップ実装の概念的なビューを示しています。
パーティション・バッキング・マップを構成するには、trueの値を持つ<partitioned>要素を追加します。次に例を示します。
<backing-map-scheme>
<partitioned>true</partitioned>
<external-scheme>
<high-units>8192</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
<nio-memory-manager>
<initial-size>1MB</initial-size>
<maximum-size>50MB</maximum-size>
</nio-memory-manager>
</external-scheme>
</backing-map-scheme>
このバッキング・マップは、com.tangosol.net.partition.PartitionSplittingBackingMapのインスタンスで、個々のパーティションでは拡張（nio）メモリーに値を格納するcom.tangosol.net.cache.SerializationCacheのインスタンスとしてマップが保持されます。個々のnioバッファには50MBの制限がありますが、バッキング・マップ全体の最大容量は8GB（8192×1048576）です。ここでも、off-heapまたはfile-mappedのこのキャッシュに対してバックアップ記憶域を構成する必要があります。
