| Oracle Coherence開発者ガイド リリース3.5 B56039-01 |
|
 戻る |
 次へ |
この章では、一連の単純なキャッシュ・スキーム構成について説明します。サンプルのビルドは相互に行われ、他のサンプルをネスト・スキームとして再利用する際は、多くの場合scheme-ref要素が使用されます。<scheme-ref>の例については、「スキームの継承」を参照してください。
キャッシュ・スキームは、キャッシュ・コンフィギュレーション・ディスクリプタcoherence-cache-config.xmlのcaching-schemes要素で指定します。これについては、付録D「キャッシュ・コンフィギュレーションの要素」を参照してください。紹介するサンプルでは、最小数の設定のみを指定しています。オプションの全セットを参照するには、スキームのドキュメントへの埋込みリンクを辿ってください。
この章では、次のキャッシング・シナリオの構成について説明します。
この項では、一連のローカル・キャッシュ・スキームを定義します。ここでいうローカルとは、キャッシュに直接アクセスできるJVMが1つのみであることを意味します。このドキュメントの後述部分で、ローカル・キャッシュはクラスタ・キャッシュの構成要素として使用されます。「クラスタ・キャッシュ（複数のJVMからアクセス可能）」を参照してください。
例F-1では、local-schemeを使用して、インメモリー・キャッシュを定義します。このキャッシュには、JVMヒープで許容される量だけ格納されます。
例F-2では、external-schemeを使用して、nio-memory-managerによるインメモリー・キャッシュを定義します。NIOメモリー・ベース・キャッシュの利点は、JVMのGC回数に悪影響を与えずに、大きなインメモリー・キャッシュ記憶域に対応できることです。キャッシュのサイズは、NIOメモリー・リージョンの最大サイズによって制限されます。nio-memory-managerの<maximum-size>サブ要素を参照してください。
<local-scheme>に<high-units>サブ要素を追加すると、キャッシュのサイズが制限されます。この例では、キャッシュのサイズが1000エントリに制限されます。制限を超えると、スキームの<eviction-policy>によって、キャッシュからの削除対象となる要素が決定されます。
<local-scheme>に<expiry-delay>サブ要素を追加すると、指定した時間間隔内に更新されなかったキャッシュ・エントリが自動的に期限切れとなります。期限切れになるとそのエントリは無効化され、キャッシュから削除されます。
external-schemeに<high-units>サブ要素を追加すると、キャッシュのサイズが制限されます。この例では、キャッシュのサイズが100万エントリに制限されます。制限を超えると、LRUエビクションが使用され、キャッシュからの削除対象となる要素が決定されます。代替のサイズ制限がある外部キャッシング・アプローチについては、「paged-external-scheme」を参照してください。
例F-7では、external-schemeを使用して、単一のJVMの長期記憶域としての使用に適したキャッシュを実装します。
外部キャッシュは一般的に、大きなデータセットの一時記憶域に使用され、JVMのシャットダウン時に自動的に削除されます。ストレージ・マネージャとしてlh-file-managerとbdb-store-managerのいずれかを使用した場合は、非クラスタ・キャッシュで外部キャッシュを長期記憶域として使用できます（「永続性（長期記憶域）」を参照）。クラスタ化の永続性については、「データベースのパーティション・キャッシュ」にあるサンプルを参照してください。
{cache-name}マクロを使用して、データが格納されるファイルの名前を指定します。このマクロの詳細は、付録E「キャッシュ・コンフィギュレーションのパラメータ・マクロ」を参照してください。
例F-7 オンディスク永続キャッシュの構成
<external-scheme>
<scheme-name>SampleDiskPersistentScheme</scheme-name>
<lh-file-manager>
<directory>/my/storage/directory</directory>
<file-name>{cache-name}.store</file-name>
</lh-file-manager>
</external-scheme>
例F-8に、LHではなくBerkeley DBを使用した場合を示します。
例F-9では、overflow-schemeを使用して、サイズが制限されたインメモリー・キャッシュを定義します。インメモリー（<front-scheme>）のサイズ制限に達すると、キャッシュの内容の一部がディスク（<back-scheme>）に移動されます。front-schemeの<eviction-policy>によって、フロントからバックへの移動対象となる要素が決定されます。
この例では、キャッシュのフロントおよびバックの実装に「サイズ制限があるオンディスク・キャッシュ」と「オンディスク・キャッシュ」の例が再利用されています。
例F-9 ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュの構成
<overflow-scheme>
<scheme-name>SampleOverflowScheme</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>SampleMemoryLimitedScheme</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<external-scheme>
<scheme-ref>SampleDiskScheme</scheme-ref>
</external-scheme>
</back-scheme>
</overflow-scheme>
例F-10では、read-write-backing-map-schemeを使用して、データベースのキャッシュを定義します。このスキームでは、データベースの内容の一部であるローカル・キャッシュが保持されます。キャッシュ・ミスによってデータベース全体が読み取られ、元のデータベースにキャッシュが書き込まれます。
cachestore-scheme要素は、インタフェースとしてcom.tangosol.net.cache.CacheLoaderとcom.tangosol.net.cache.CacheStoreのいずれかを実装するカスタム・クラスによって構成されます。このクラスは、キャッシュ・エントリの読取りや書込みなど、データベースに対するすべての操作を担当します。キャッシュ・ストアの書込みの例については、付録G「CacheStoreのサンプル」を参照してください。
{cache-name}マクロを使用して、キャッシュ・ストアの実装に対して、バッキングされるキャッシュの名前を通知します。このマクロの詳細は、付録E「キャッシュ・コンフィギュレーションのパラメータ・マクロ」を参照してください。
例F-10 データベースのキャッシュの構成
<read-write-backing-map-scheme>
<scheme-name>SampleDatabaseScheme</scheme-name>
<internal-cache-scheme>
<local-scheme>
<scheme-ref>SampleMemoryScheme</scheme-ref>
</local-scheme>
</internal-cache-scheme>
<cachestore-scheme>
<class-scheme>
<class-name>com.tangosol.examples.coherence.DBCacheStore</class-name>
<init-params>
<init-param>
<param-type>java.lang.String</param-type>
<param-value>{cache-name}</param-value>
</init-param>
</init-params>
</class-scheme>
</cachestore-scheme>
</read-write-backing-map-scheme>
この項では、一連のクラスタ・キャッシュのサンプルを定義します。クラスタ・キャッシュは、複数のJVM（同じキャッシュ・サービスを実行する任意のクラスタ・ノード）からアクセスできます。各クラスタ・ノード上の内部キャッシュ記憶域（backing-map）は、ローカル・キャッシュを使用して定義します（「ローカル・キャッシュ（単一のJVMからアクセス可能）」を参照）。キャッシュ・サービスには、他のクラスタ・ノードのローカル・キャッシュにアクセスする機能があります。
例F-11では、replicated-scheme要素を使用して、クラスタ・キャッシュを定義します。このキャッシュでは、キャッシュ・エントリのそれぞれのコピーがすべてのクラスタ・ノードに格納されます。
「インメモリー・キャッシュ」のサンプルを使用して、各クラスタ・ノードのキャッシュ記憶域を定義します。キャッシュのサイズは、JVMヒープが最小のクラスタ・ノードによってのみ制限されます。
backing-map-scheme要素では、他のローカル・キャッシュのサンプルのいずれでも簡単に指定できます。たとえば、「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を使用した場合は、クラスタ・ノードのそれぞれにローカル・オーバーフロー・キャッシュが設定され、より大量の記憶域容量を利用できます。
例F-13では、distributed-schemeを使用して、クラスタ・キャッシュを定義します。このキャッシュの記憶域は、すべてのクラスタ・ノードにわたってパーティション化されます。
「インメモリー・キャッシュ」を使用して、各クラスタ・ノードのキャッシュ記憶域を定義します。キャッシュの記憶域の合計容量は、パーティション・キャッシュ・サービスを実行する、記憶域が有効なクラスタ・ノードの合計です。「distributed-scheme」の<local-storage>サブ要素を参照してください。
backing-map-scheme要素では、他のローカル・キャッシュのサンプルのいずれでも簡単に指定できます。たとえば、「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を使用した場合は、記憶域が有効なクラスタ・ノードのそれぞれにローカル・オーバーフロー・キャッシュが設定され、より大量の記憶域容量を利用できます。キャッシュのバックアップ記憶域も同じオーバーフロー・スキームを使用するため、バックアップ・データをディスクにオーバーフローできます。
例F-14 オーバーフローが設定されたパーティション・キャッシュの構成
<distributed-scheme>
<scheme-name>SamplePartitionedOverflowScheme</scheme-name>
<backing-map-scheme>
<overflow-scheme>
<scheme-ref>SampleOverflowScheme</scheme-ref>
</overflow-scheme>
</backing-map-scheme>
<backup-storage>
<type>scheme</type>
<scheme-name>SampleOverflowScheme</scheme-name>
</backup-storage>
</distributed-scheme>
backing-map-scheme要素を切り替えてread-write-backing-map-schemeを使用すると、キャッシュではデータベースなどの外部ソースに対して、エントリのロードおよび格納が可能になります。
例F-15では、「データベースのキャッシュ」を再利用して、データベース・アクセスを定義します。
例F-16では、distributed-schemeのシリアライザ要素を使用して、ユーザー定義型のシリアライズおよびデシリアライズに使用されるシリアライザを定義します。この例では、パーティション・キャッシュのシリアライズ形式としてPOF（ConfigurablePofContext）が使用されます。POFを使用し、アプリケーションでカスタムのユーザー定義型クラスを使用する場合は、そのクラス用にカスタムのPOF構成も定義する必要があります。POFの要素の詳細は、付録J「POFユーザー定義型の構成要素」を参照してください。
例F-16 シリアライザが設定されたパーティション・キャッシュの構成
<distributed-scheme>
<scheme-name>SamplePartitionedPofScheme</scheme-name>
<service-name>PartitionedPofCache</service-name>
<serializer>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
</serializer>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
例F-17では、near-schemeを使用して、パーティション・キャッシュのサブセットであるローカルのインメモリー・キャッシュを定義します。この定義によって、パーティション・キャッシュにアクセスするクラスタ・ノードに、アクセス頻度の高い要素のローカル・コピーが保持されます。この結果、読取りパフォーマンスはreplicated-schemeベースのキャッシュに近づき、distributed-schemeベースのキャッシュと同様の高いスケーラビリティも得られます。
ニア（<front-scheme>）キャッシュの定義には「サイズ制限があるインメモリー・キャッシュ」のサンプルを、near-schemeの定義には「パーティション・キャッシュ」のサンプルを再利用します。
front-schemeのサイズ制限付きの構成によって、back-schemeキャッシュがローカルにキャッシュされる量の制限が指定されます。
例F-17 パーティション・キャッシュのローカル・キャッシュの構成
<near-scheme>
<scheme-name>SampleNearScheme</scheme-name>
<front-scheme>
<local-scheme>
<scheme-ref>SampleLimitedMemoryScheme</scheme-ref>
</local-scheme>
</front-scheme>
<back-scheme>
<distributed-scheme>
<scheme-ref>SamplePartitionedScheme</scheme-ref>
</distributed-scheme>
</back-scheme>
</near-scheme>
