| Oracle® Coherence開発者ガイド リリース3.7.1 B65026-01 |
|
 前 |
 次 |
この項では、一連の基本的なキャッシュ・スキーム定義について説明します。これらの定義は必要に応じて使用または変更できます。キャッシュの構成方法の詳細は、第12章「キャッシュの構成」を参照してください。また、この章で紹介するサンプルのビルドは相互に依存しており、他のサンプルをネスト・スキームとして再使用する際は、多くの場合<scheme-ref>要素が使用されます。<scheme-ref>要素の使用方法の詳細は、「スキームの継承の使用方法」を参照してください。紹介するサンプルでは、最小数の設定のみを指定しています。すべてのオプションを参照するには、スキームのドキュメントへの埋込みリンクを使用してください。
この章では、次のキャッシング・シナリオの構成について説明します。
この項では、一連のローカル・キャッシュ・スキームを定義します。ここでいうローカルとは、キャッシュに直接アクセスできるJVMが1つのみであることを意味します。このドキュメントの後述部分で、ローカル・キャッシュはクラスタ・キャッシュの構成要素として使用されます。「クラスタ・キャッシュ(複数のJVMからアクセス可能)」を参照してください。
例17-1では、local-schemeを使用して、インメモリー・キャッシュを定義します。キャッシュには、JVMヒープで可能なかぎりの容量が保存されます。
例17-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>サブ要素を追加すると、指定した期間内に更新されなかったキャッシュ・エントリが自動的に期限切れになります。期限切れになるとそのエントリは無効化され、キャッシュから削除されます。
例17-5では、external-schemeを使用して、オンディスク・キャッシュを定義します。キャッシュには、ファイル・システムで可能なかぎりの容量が保存されます。
external-schemeに<high-units>サブ要素を追加すると、キャッシュのサイズが制限されます。この例では、キャッシュのサイズが100万エントリに制限されます。制限を超えると、LRUエビクションが使用され、キャッシュからの削除対象となる要素が決定されます。これ以外のサイズ制限がある外部キャッシング方法については、「paged-external-scheme」を参照してください。
例17-7では、external-schemeを使用して、単一のJVMの長期記憶域としての使用に適したキャッシュを実装します。
外部キャッシュは一般的に、大きなデータセットの一時記憶域に使用され、JVMのシャットダウン時に自動的に削除されます。lh-file-managerまたはbdb-store-managerのいずれかのストレージ・マネージャを使用した場合は、非クラスタ・キャッシュで外部キャッシュを長期記憶域として使用できます(「永続性(長期記憶域)」を参照)。クラスタ化の永続性については、「データベースのパーティション・キャッシュ」にあるサンプルを参照してください。
データが格納されるファイルの名前を指定するには、{cache-name}マクロを使用します。。このマクロの詳細は、「パラメータ・マクロの使用方法」を参照してください。
例17-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>
例17-8は、LHではなくBerkeley DBを使用した場合を示しています。
例17-9では、overflow-schemeを使用して、サイズが制限されたインメモリー・キャッシュを定義します。インメモリー(<front-scheme>)のサイズの上限に達すると、キャッシュの内容の一部がディスク(<back-scheme>)に移動されます。front-schemeの<eviction-policy>によって、フロントからバックへの移動対象となる要素が決定されます。
この例では、キャッシュのフロントおよびバックの実装に「サイズ制限があるオンディスク・キャッシュ」と「オンディスク・キャッシュ」の例が再利用されています。
例17-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>
例17-10では、read-write-backing-map-schemeを使用して、データベースのキャッシュを定義します。このスキームでは、データベースの内容の一部であるローカル・キャッシュが保持されます。キャッシュ・ミスによってデータベース全体が読み取られ、元のデータベースにキャッシュが書き込まれます。
cachestore-scheme要素は、com.tangosol.net.cache.CacheLoaderまたはcom.tangosol.net.cache.CacheStoreのいずれかのインタフェースを実装するカスタム・クラスによって構成されます。このクラスは、キャッシュ・エントリの読取りや書込みなど、データベースに対するすべての操作を担当します。キャッシュ・ストアの書込みの例については、「CacheStoreのサンプル」を参照してください。
キャッシュ・ストアの実装に対して、バッキングされるキャッシュの名前を通知するには、{cache-name}マクロを使用します。。このマクロの詳細は、「パラメータ・マクロの使用方法」を参照してください。
例17-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からアクセス可能)」を参照)。キャッシュ・サービスには、他のクラスタ・ノードのローカル・キャッシュにアクセスする機能があります。
例17-11では、replicated-scheme要素を使用してクラスタ・キャッシュを定義します。このキャッシュでは、各キャッシュ・エントリのコピーがすべてのクラスタ・ノードに格納されます。
「インメモリー・キャッシュ」のサンプルを使用して、各クラスタ・ノードのキャッシュ記憶域を定義します。キャッシュのサイズは、JVMヒープが最小のクラスタ・ノードによってのみ制限されます。
backing-map-scheme要素では、他のローカル・キャッシュのサンプルのいずれでも簡単に指定できます。たとえば、「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を使用した場合は、クラスタ・ノードのそれぞれにローカル・オーバーフロー・キャッシュが設定され、より大量の記憶域容量を利用できます。
例17-13では、distributed-schemeを使用して、クラスタ・キャッシュを定義します。このキャッシュでは、キャッシュ記憶域がクラスタ・ノード全体にわたってパーティション化されます。
「インメモリー・キャッシュ」を使用して、各クラスタ・ノードのキャッシュ記憶域を定義します。キャッシュの記憶域の合計容量は、パーティション・キャッシュ・サービスを実行する、記憶域が有効なクラスタ・ノードの合計です。「distributed-scheme」の<local-storage>サブ要素を参照してください。
backing-map-scheme要素では、他のローカル・キャッシュのサンプルのいずれでも簡単に指定できます。たとえば、「ディスク・ベースのオーバーフローが設定されたインメモリー・キャッシュ」を使用した場合は、記憶域が有効なクラスタ・ノードのそれぞれにローカル・オーバーフロー・キャッシュが設定され、より大量の記憶域容量を利用できます。キャッシュのバックアップ記憶域も同じオーバーフロー・スキームを使用するため、バックアップ・データをディスクにオーバーフローできます。
例17-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を使用すると、キャッシュでの、データベースなどの外部ソースに対するエントリのロードおよび格納が可能になります。
例17-15では、「データベースのキャッシュ」を再利用して、データベース・アクセスを定義しています。
例17-16では、distributed-schemeのシリアライザ要素を使用して、ユーザー定義型のシリアライズおよびデシリアライズに使用されるシリアライザを定義します。この場合、パーティション・キャッシュはPOF(ConfigurablePofContext)をシリアライズ形式として使用します。POFを使用し、アプリケーションでカスタムのユーザー定義型クラスを使用する場合は、そのクラス用にカスタムのPOF構成も定義する必要があります。POFの要素の詳細は、付録D「POFユーザー定義型の構成要素」を参照してください。
例17-16 シリアライザが設定されたパーティション・キャッシュの構成
<distributed-scheme>
<scheme-name>SamplePartitionedPofScheme</scheme-name>
<service-name>PartitionedPofCache</service-name>
<serializer>
<instance>
<class-name>com.tangosol.io.pof.ConfigurablePofContext</class-name>
</instance>
</serializer>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
tangosol-coherence.xmlデプロイメント・ディスクリプタで定義されるシリアライザも参照できます。
例17-17 シリアライザを参照するパーティション・キャッシュ
<distributed-scheme>
<scheme-name>SamplePartitionedPofScheme</scheme-name>
<service-name>PartitionedPofCache</service-name>
<serializer>pof</serializer>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
最後に、すべてのスキームにデフォルトのシリアライザを定義することで、それぞれのキャッシュ・スキーム定義に明示的に<serializer>要素を含める必要がなくなります。グローバル・シリアライザの定義により、tangosol-coherence.xmlデプロイメント・ディスクリプタで定義されたシリアライザを参照することもできます。
例17-18 デフォルト・シリアライザの定義
<?xml version='1.0'?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config
coherence-cache-config.xsd">
<defaults>
<serializer>pof</serializer>
</defaults>
...
例17-19では、near-schemeを使用して、パーティション・キャッシュのサブセットのローカル・インメモリー・キャッシュを定義します。この定義によって、パーティション・キャッシュにアクセスするクラスタ・ノードに、アクセス頻度の高い要素のローカル・コピーが保持されます。その結果、読取りパフォーマンスはreplicated-schemeベースのキャッシュに近づき、distributed-schemeベースのキャッシュと同様の高いスケーラビリティも得られます。
ニア(<front-scheme>)キャッシュの定義には「サイズ制限があるインメモリー・キャッシュ」のサンプルが再利用され、near-schemeの定義には「パーティション・キャッシュ」のサンプルが再利用されます。
front-schemeのサイズ制限付きの構成によって、back-schemeキャッシュがローカルにキャッシュされる量の制限が指定されます。
例17-19 パーティション・キャッシュのローカル・キャッシュの構成
<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>
