| Oracle® Coherence開発者ガイド リリース3.7.1 B65026-01 |
|
 前 |
 次 |
この章では、バッキング・マップを使用した記憶域について説明します。この章は次の各項で構成されています。
Coherenceのパーティション(分散)キャッシュ・サービスは、次の3つのレイヤーに分かれています。
クライアント・ビュー: 基礎となるパーティション化されたデータへのアクセスを可能にする仮想レイヤー。この層へのアクセスには、 NamedCacheインタフェースが使用されます。このレイヤーでは、NearCacheやContinuousQueryCacheなどの統合データ構造も作成できます。
ストレージ・マネージャ: クライアント層からのキャッシュ関連リクエストを処理するサーバー側の層です。実際のキャッシュ・データ(プライマリ・コピーおよびバックアップ・コピー)、およびロック、イベント・リスナー、マップ・トリガーなどに関する情報を格納するデータ構造を管理します。
バッキング・マップ: 実際のデータを格納するサーバー側のデータ構造。
Coherenceでは、出荷状態のまま使用できるいくつかのバッキング・マップの実装を構成することも、カスタム構成を使用することもできます。基本的に、これらすべてのマップ実装における唯一の制約は、ストレージ・マネージャではキーと値がすべて内部(バイナリ)形式で指定されるということであり、その点に留意する必要があります。内部データとオブジェクト形式との間の変換を処理するため、ストレージ・マネージャでは、BackingMapManagerContext参照によるバッキング・マップの実装が可能です。
図13-1は、バッキング・マップの概念図です。
ローカル記憶域は、Coherenceで管理されるデータを実際に保存またはキャッシュするデータ構造です。ローカル記憶域を提供するオブジェクトは、同じ標準のコレクション・インタフェースであるjava.util.Mapをサポートする必要があります。Coherenceのローカル記憶域の実装を使用して、レプリケートされたデータや分散データを保存する場合、その機能をバッキング・マップと呼びます。これは、Coherenceがローカル記憶域の実装によって実際に支援(バックアップ)されるためです。その他、ローカル記憶域の一般的な使用法としては、分散キャッシュの前に配置したり、分散キャッシュの後方でバックアップを行うことがあります。
Coherenceは、次のローカル記憶域の実装をサポートします。
セーフなHashMap: デフォルトのロスレス実装です。ロスレス実装には、JavaのHashtableクラス同様、サイズ制限も自動失効もありません。つまり、自身に含まれるキャッシュ項目を削除する(損失する)ことのない実装です。この特殊なHashMap実装は、非常に高度なスレッドレベルの並行性にあわせて最適化されていますデフォルト実装にはcom.tangosol.util.SafeHashMapクラスを、キャッシュ・イベントの送信が必要な実装にはcom.tangosol.util.ObservableHashMapを使用します。これらの実装はスレッドセーフです。
ローカル・キャッシュ: デフォルトのサイズ制限および自動失効の実装です。ローカル・キャッシュについては後で詳しく説明しますが、ここで覚えておくべき重要な点は、キャッシュ・サイズを制限できること、および一定期間後にキャッシュ項目を自動失効できることですデフォルト実装にはcom.tangosol.net.cache.LocalCacheを使用します。この実装はスレッド・セーフであり、キャッシュ・イベント、com.tangosol.net.CacheLoader、CacheStore、および構成可能でプラッガブルなエビクション・ポリシーがサポートされます。
読取り/書込みバッキング・マップ: これは、キャッシュ・ミスの際にデータベースからロードするキャッシュのデフォルトのバッキング・マップの実装です。これは、読取り専用キャッシュ(コンシューマ・モデル)として構成することも、ライトスルーまたはライトビハインド・キャッシュ(コンシューマ/プロデューサ・モデル)として構成することもできます。ライトスルーおよびライトビハインド・モードは、分散キャッシュ・サービスで使用することのみを目的としています。ニア・キャッシュとともに使用する場合、ニア・キャッシュと分散キャッシュの同期を維持する必要があるのであれば、(ニア・キャッシュを無効化する目的で)このバッキング・マップをSeppukuベースのニア・キャッシュと組み合せて使用できます。デフォルト実装にはcom.tangosol.net.cache.ReadWriteBackingMapクラスを使用します。
バイナリ・マップ(Java NIO): 自身の情報をメモリー内(ただしJavaヒープ外)に保存したり、メモリー・マップ・ファイルにも保存できるバッキング・マップ実装です。つまり、Javaヒープ・サイズには影響せず、アプリケーションの一時停止の原因となり得る関連したJVMガベージ・コレクションのパフォーマンスにも影響しないことを意味します。この実装はまた、分散キャッシュのバックアップにも使用できます。これは高可用性を実現するためにバックアップを必要とする、読取り専用(または読取りを主体とする)キャッシュで特に有用です。このバックアップがJavaヒープ・サイズに影響しないにもかかわらず、フェイルオーバー時には瞬時に使用できるためです。
シリアライズ・マップ: これは、ディスクに保存できる形式にデータを変換するバッキング・マップの実装です。この形式は、シリアライズされた形式と呼ばれています。これには、データのシリアライズされた形式を保存するための個別のcom.tangosol.io.BinaryStoreオブジェクトが必要になります。これは通常、組込みのLHディスクの実装になりますが、シリアライズ・マップでは、任意のカスタムのBinaryStoreの実装をサポートします。シリアライズ・マップのデフォルト実装にはcom.tangosol.net.cache.SerializationMapを使用します。
シリアライズ・キャッシュ: LRUエビクション・ポリシーをサポートするSerializationMapの拡張機能です。たとえば、シリアライズ・キャッシュによって、ディスク・ファイルのサイズを制限できます。シリアライズ・キャッシュのデフォルト実装にはcom.tangosol.net.cache.SerializationCacheを使用します。
オーバーフロー・マップ: オーバーフロー・マップは実際には記憶域を提供しませんが、2つのローカル記憶域の実装を結合し、最初の記憶域がいっぱいになると、オーバーフローを行って次の記憶域にデータを保存することから、この項で紹介していますOverflowMapのデフォルト実装にはcom.tangosol.net.cache.OverflowMapを使用します。
バッキング・マップに対して実行される操作にはいくつかのタイプがあります。
アプリケーションの使用によって必然的に発生するアクセスおよび更新操作。たとえば、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()操作によって発生する挿入操作(リードスルー機能またはリードアヘッド機能が構成されたバッキング・マップの場合)
パーティション分散によって発生する統合アクセスおよび更新(クラスタ・ノードのフェイルオーバーまたはフェイルバックから発生する場合もあります)。この場合は、アプリケーション層のコールがなくても、バッキング・マップのいくつかのエントリが挿入または削除されることがあります。
バッキング・マップでは、実際の実装方法に応じて、次の方法でキャッシュ・データが格納されます。
ヒープ上メモリー
ヒープ外メモリー
ディスク(メモリーマップ・ファイルまたはインプロセスDB)
ソリッド・ステート・デバイス(ジャーナル・ファイル)
上述のいずれかの組合せ
データをメモリーに格納することで、アクセスおよび更新の待機時間が大幅に短縮されます。また、これは最も一般的に使用される方法でもあります。
たいていの場合、アプリケーションでは、データ・グリッドに配置されるデータの合計量が事前設定されたメモリー量を超えないようにする必要があります。これは、アプリケーション層ロジックによって直接制御することも、サイズ・ベースまたは有効期限ベースのエビクションによって自動的に制御することもできます。その結果、当然のことながら、Coherenceのキャッシュに保持されるデータの合計量は、対応するすべてのバッキング・マップ(対応するパーティション・キャッシュ・サービスを記憶域有効モードで実行するクラスタ・ノードごとに1つ)のデータの合計量と等しくなります。
次のキャッシュ構成の抜粋について検討してみましょう。
<backing-map-scheme> <local-scheme/> </backing-map-scheme>
このバッキング・マップはcom.tangosol.net.cache.LocalCacheのインスタンスであり、事前設定されたサイズの制約がなく、明示的に制御する必要があります。制御できない場合は、JVMがメモリー不足になります。
<backing-map-scheme>
<local-scheme>
<eviction-policy>LRU</eviction-policy>
<high-units>100m</high-units>
<unit-calculator>BINARY</unit-calculator>
</local-scheme>
</backing-map-scheme>
このバッキング・マップもcom.tangosol.net.cache.LocalCacheですが、100MBの容量制限があります。このバッキング・マップで保持されるデータの合計量が高水位標を超えると、バッキング・マップから一部のエントリが削除され、データの量が低水位標値(<low-units>構成要素、デフォルトでは<high-units>の75%)まで減少します。削除されるエントリの選択方法は、LRU(最低使用頻度)エビクション・ポリシーに従います。その他のオプションには、LFU(最低アクセス頻度)および混合(LRUとLFUの組合せ)があります。<high-units>の値は2GBに制限されます。この制限を解除するため(ただし下位互換性は保持)、Coherenceでは<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時間以上経過していればいつでもエントリが削除される可能性があります。保証されるのは、1時間を超過したエントリがコール元に返されないことのみです。
次のバッキング・マップは、com.tangosol.net.cache.SerializationCacheのインスタンスであり、拡張(nio)メモリーに値を格納しますが、100MB(100*1048576)の容量制限があります。
<backing-map-scheme>
<external-scheme>
<nio-memory-manager>
<initial-size>1MB</initial-size>
<maximum-size>100MB</maximum-size>
</nio-memory-manager>
<high-units>100</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
</external-scheme>
</backing-map-scheme>
このキャッシュのバックアップ記憶域は、off-heap(またはfile-mapped)で構成します。
<backup-storage> <type>off-heap</type> <initial-size>1MB</initial-size> <maximum-size>100MB</maximum-size> </backup-storage>
従来のバッキング・マップの実装には、対応するノードが所有するすべてのパーティションのエントリが含まれていました。(パーティション送信時に、クライアントから見て一時的に所有者の存在しない「未完了」エントリも保持されることがありました)。
図13-2は、従来のバッキング・マップ実装の概念図です。
パーティション・バッキング・マップは、基本的には実際のマップ実装の多重化であり、それぞれのマップには同じパーティションに属するエントリのみが格納されるようになりました。
図13-3は、パーティション・バッキング・マップ実装の概念図です。
パーティション・バッキング・マップを構成するには、<partitioned>要素を、値をtrueに設定して追加します。例:
<backing-map-scheme>
<partitioned>true</partitioned>
<external-scheme>
<nio-memory-manager>
<initial-size>1MB</initial-size>
<maximum-size>50MB</maximum-size>
</nio-memory-manager>
<high-units>8192</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
</external-scheme>
</backing-map-scheme>
このバッキング・マップはcom.tangosol.net.partition.PartitionSplittingBackingMapのインスタンスであり、マップを保持する個別のパーティションであるcom.tangosol.net.cache.SerializationCacheのインスタンスから構成され、各パーティションの拡張(nio)メモリーに値が格納されます。nioバッファにはそれぞれ50MBの制限がありますが、バッキング・マップ全体の容量制限は8GB(8192*1048576)です。この場合も、このキャッシュのバックアップ記憶域はoff-heapまたはfile-mappedで構成する必要があります。
エラスティック・データ機能は、メモリーとディスクベースのデバイス間で、シームレスにデータを保存するために使用されます。この機能は、特にSSD (Solid State Disk)などの高速ディスクベースのデバイスを使用する場合に調整され、SSDからデータを読書きする際にメモリーと同等の速度でアクセスできるようにします。エラスティック・データ機能では、ジャーナルという技術を使用して、メモリーとディスク間の保存操作を最適化します。
エラスティック・データには、メモリー内にデータを保存するRAMジャーナルと、ディスクベースのデバイスにデータを保存するフラッシュ・ジャーナルという2つのコンポーネントが含まれます。これらを様々に組み合せ、一般的にはバッキング・マップやバックアップ記憶域に使用しますが、複合キャッシュにも使用できます(たとえば、ニア・キャッシュなど)。RAMジャーナルは、常にフラッシュ・ジャーナルとともに機能し、ディスクへのシームレスなオーバーフローを実現します。
RAMジャーナルおよびフラッシュ・ジャーナルを使用するキャッシュは、キャッシュ構成ファイル内にキャッシュ・スキーム定義の一部として構成されます。必要に応じて、オペレーション・オーバーライド・ファイルを使用して出荷状態の構成を上書きし、ジャーナルの動作を構成します。
この項の内容は次のとおりです。
ジャーナル機能とは、ジャーナルと呼ばれる一連の変更において状態の変化を記録する技術です。変更が発生すると、ジャーナルは特定のキーの各値を記録し、メモリー内に保存されるツリー構造により、特定のキーの現在の値を含むジャーナル・エントリが追跡されます。エントリの値を検索するには、最新の値を含むジャーナル・エントリへのポインタを含むツリーでキーを検索します。
キーに新しい値が書き込まれることによりジャーナルの変更情報が古くなると、ジャーナルには古い値が累積されます。一定の間隔で古い値を削除すると、新しい値をジャーナルに書き込むスペースができます。
エラスティック・データ機能には、RAMジャーナル実装とフラッシュ・ジャーナル実装が含まれ、相互にシームレスに機能します。たとえば、RAMジャーナルでメモリーを使用し尽くした場合、フラッシュ・ジャーナルがRAMジャーナルからのオーバーフローを自動的に受け入れることで、キャッシュをRAMのサイズより格段に大きなサイズにまで拡張できます。
|
注意: ジャーナルを有効にした場合、大きな結果セットでデータ・グリッド操作(問合せや集計など)を実行する際に追加の容量計画が必要になります。詳細は、Oracle Coherence管理者ガイドを参照してください。 |
リソース・マネージャはジャーナルを制御します。リソース・マネージャはバイナリ・ストアを作成および使用して、ジャーナルの操作を実行します。バイナリ・ストアは、JournalBinaryStoreクラスで実装されます。バイナリ・ストアを介したすべての読書きは、リソース・マネージャで処理されます。RAMジャーナル用のリソース・マネージャ(RamJournalRM)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM)があります。最後に、ジャーナルではバッキング・マップ実装としてSimpleSerializationMapクラスを使用します。必要に応じて、SimpleSerializationMapのカスタム実装も作成できます。これらのAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。
キャッシュ構成ファイルでは、<ramjournal-scheme>および<flashjournal-scheme>要素を使用して、それぞれRAMジャーナルおよびフラッシュ・ジャーナルを構成します。これらのスキーム・タイプの詳細な構成オプションについては、「ramjournal-scheme」および「flashjournal-scheme」を参照してください。
この項の内容は次のとおりです。
RAMジャーナル・バッキング・マップを構成するには、キャッシュ定義の<backing-map-scheme>要素の中に<ramjournal-scheme>要素を追加します。次の例では、バッキング・マップにRAMジャーナルを使用する分散キャッシュを作成します。RAMジャーナルは、構成されたメモリー・サイズを超えると、自動的にフラッシュ・ジャーナルに委任します。メモリー設定の変更については、「ジャーナルの動作の変更」を参照してください。
<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheRAMJournal</service-name>
<backing-map-scheme>
<ramjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
フラッシュ・ジャーナル・バッキング・マップを構成するには、キャッシュ定義の<backing-map-scheme>要素の中に<flashjournal-scheme>要素を追加します。次の例では、バッキング・マップにフラッシュ・ジャーナルを使用する分散スキームを作成します。
<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheFlashJournal</service-name>
<backing-map-scheme>
<flashjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
RAMジャーナル・スキームおよびフラッシュ・ジャーナル・スキームでは、スキーム定義を再利用するためのスキーム参照の使用をサポートします。次の例では、default-ramというRAMスキーム定義を参照することで、分散キャッシュを作成して、RAMジャーナル・バッキング・マップを構成しています。
<caching-schemes>
<distributed-scheme>
<scheme-name>distributed-journal</scheme-name>
<service-name>DistributedCacheJournal</service-name>
<backing-map-scheme>
<ramjournal-scheme>
<scheme-ref>default-ram</scheme-ref>
</ramjournal-scheme>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<ramjournal-scheme>
<scheme-name>default-ram</scheme-name>
</ramjournal-scheme>
</caching-schemes>
ジャーナル・スキームは、バックアップ記憶域およびバッキング・マップに使用されます。デフォルトでは、バッキング・マップとしてRAMジャーナルを使用するように構成された分散スキームは、バックアップ記憶域にRAMジャーナルを使用します。同様に、バッキング・マップにフラッシュ・ジャーナルを使用する分散スキームは、バックアップ記憶域にフラッシュ・ジャーナルを使用します。このデフォルトの動作は、<backup-storage>要素の中のストレージ・タイプを明示的に指定することで、変更できます。次の構成ではバッキング・マップにRAMジャーナルを使用し、明示的にバックアップ記憶域にフラッシュ・ジャーナルを構成しています。
<caching-schemes>
<distributed-scheme>
<scheme-name>default-distributed-journal</scheme-name>
<service-name>DistributedCacheJournal</service-name>
<backup-storage>
<type>scheme</type>
<scheme-name>example-flash</scheme-name>
</backup-storage>
<backing-map-scheme>
<ramjournal-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
<flashjournal-scheme>
<scheme-name>example-flash</scheme-name>
</flashjournal-scheme>
</caching-schemes>
必要に応じて、カスタム・マップを使用するようにジャーナル・スキームを構成できます。カスタム・マップ実装では、SimpleSerializationMapクラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。カスタム実装を有効にするには、<class-scheme>要素を追加し、その値をカスタム・クラスの完全修飾名に指定します。カスタム・クラスに必要な任意のパラメータは、<init-params>要素を使用して定義できます。次の例では、MySimpleSerializationMapというカスタム・マップ実装を有効にします。
<flashjournal-scheme> <scheme-name>example-flash</scheme-name> <class-name>package.MySimpleSerializationMap</class-name> </flashjournal-scheme>
リソース・マネージャはジャーナルの動作を制御します。RAMジャーナル用のリソース・マネージャ(RamJournalRM)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM)があります。クラスタのリソース・マネージャは、tangosol-coherence-override.xmlオペレーション・オーバーライド・ファイルで構成されます。構成オーバーライドが設定されていないと、リソース・マネージャの出荷時のデフォルト設定が使用されます。
この項の内容は次のとおりです。
<ramjournal-manager>要素は、RAMジャーナルの動作を構成するために使用されます。次のリストは、リソース・マネージャで設定されているデフォルトについて簡潔にまとめたものです。すべての使用可能な設定およびそのデフォルト値の詳細は、「ramjournal-manager」を参照してください。
バイナリ値は、デフォルトでは64KBに制限されています(最大は4MB)。
個々のバッファ(ジャーナル・ファイル)は、デフォルトでは2MBに制限されています(最大は2GB)。
ジャーナルは、最大512のファイルで構成されます。
ジャーナルで使用される合計メモリーは、デフォルトでは1GBに制限されています(最大は64GB)。
|
注意: バイナリ値またはメモリーの設定、あるいはその両方を超過すると、フラッシュ・ジャーナルが自動的に使用されます。 |
RAMジャーナル・リソース・マネージャを構成するには、<ramjournal-manager>要素を<journaling-config>要素の中に追加して、オーバーライドするサブ要素を定義します。次の例では、それぞれの使用可能なサブ要素のオーバーライドを示しています。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<journaling-config>
<ramjournal-manager>
<maximum-value-size>64K</maximum-value-size>
<maximum-size>2G</maximum-size>
</ramjournal-manager>
</journaling-config>
</cluster-config>
</coherence>
<flashjournal-manager>要素は、フラッシュ・ジャーナルの動作を構成するために使用されます。次のリストは、リソース・マネージャで設定されているデフォルトについて簡潔にまとめたものです。すべての使用可能な設定およびそのデフォルト値の詳細は、「flashjournal-manager」を参照してください。
バイナリ値は、デフォルトでは64MBに制限されています。
個々のバッファ(ジャーナル・ファイル)は、デフォルトでは2GBに制限されています(最大は4GB)。
ジャーナルは、最大512のファイルで構成されます。
そのため、ジャーナルはデフォルトでは1TBに制限され、理論上最大2TBとなります。
フラッシュ・ジャーナル・リソース・マネージャを構成するには、<flashjournal-manager>要素を<journaling-config>要素の中に追加して、オーバーライドするサブ要素を定義します。次の例では、それぞれの使用可能なサブ要素のオーバーライドを示しています。
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<journaling-config>
<flashjournal-manager>
<maximum-value-size>64K</maximum-value-size>
<maximum-file-size>8M</maximum-file-size>
<block-size>512K</block-size>
<maximum-pool-size>32M</maximum-pool-size>
<directory>/coherence_storage</directory>
<async-limit>32M</async-limit>
</flashjournal-manager>
</journaling-config>
</cluster-config>
</coherence>
|
注意: ジャーナル・ファイルを保存するために指定されたディレクトリが存在する必要があります。ディレクトリが存在しない場合、警告がログに記録され、JVMで指定されたデフォルトの一時ファイル・ディレクトリが使用されます。 |
デルタ・バックアップとは、プライマリ・エントリが変更されたときに、エントリ全体を置き換えるのではなく、バックアップ・バイナリ・エントリに変更を適用するために使用される技術です。デルタ・バックアップは、更新されるエントリは大きいが変更は小さい場合に最適です。そのような場合、エントリ全体の書換えに関するコストよりエントリの一部分のみを変更するコストの方が一般的には小さいので、パフォーマンスが向上します。一般的に、エントリに50%を超える変更があると、デルタ・バックアップを使用しても、パフォーマンスの向上はほとんどまたはまったくありません。
デルタ・バックアップでは、新旧の値を持つ2つのインメモリー・バッファを比較するコンプレッサを使用し、古い値に適用して新しい値を作成できる結果(デルタといいます)を生成します。Coherenceでは、POFおよび非POF形式の標準のデルタ・コンプレッサを備えています。必要に応じて、カスタム・コンプレッサを作成することもできます。
デルタ・バックアップは分散キャッシュでのみ使用可能で、デフォルトでは無効です。デルタ・バックアップは、それぞれの分散キャッシュで個別に有効にするか、分散キャッシュ・サービス・タイプのすべてのインスタンスに有効にします。
分散キャッシュでデルタ・バックアップを有効にするには、<compressor>要素を<distributed-scheme>要素の中に追加して、standardに設定します。例:
<distributed-scheme> ... <compressor>standard</compressor> ... </distributed-scheme>
分散キャッシュ・サービス・タイプのすべてのインスタンスにデルタ・バックアップを有効にするには、オペレーション・オーバーライド・ファイルで、パーティション・キャッシュ・サービスのcompressor初期化パラメータを上書きします。例:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/
coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<services>
<service id="3">
<init-params>
<init-param id="22">
<param-name>compressor</param-name>
<param-value
system-property="tangosol.coherence.distributed.compressor">
standard</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.distributed.compressorシステム・プロパティを使用して、分散キャッシュ・サービス・タイプのすべてのインスタンスにデルタ・バックアップを有効にすることもできます。例:
-Dtangosol.coherence.distributed.compressor=standard
カスタム・コンプレッサを使用してデルタ・バックアップを実行するには、<instance>サブ要素を追加して、DeltaCompressorインタフェースを実装するクラスの完全修飾名を指定します。<instance>要素の使用の詳細は、「instance」を参照してください。次の例では、MyDeltaCompressorクラスに実装されているカスタム・コンプレッサが有効になります。
<distributed-scheme>
...
<compressor>
<instance>
<class-name>package.MyDeltaCompressor</class-name>
</instance>
</compressor>
...
</distributed-scheme>
代替案として、<instance>要素では、DeltaCompressorインスタンスを作成するためのファクトリ・クラスを使用する<class-factory-name>要素、およびオブジェクトのインスタンス化を実行するファクトリ・クラス上で静的なファクトリ・メソッドを指定する<method-name>要素の使用がサポートされています。次の例では、MyCompressorFactoryクラスのgetCompressorメソッドを使用するカスタム・コンプレッサ・インスタンスを取得します。
<distributed-scheme>
...
<compressor>
<instance>
<class-factory-name>package.MyCompressorFactory</class-factory-name>
<method-name>getCompressor</method-name>
</instance>
</compressor>
...
</distributed-scheme>
実装に必要な初期化パラメータはすべて、<init-params>要素を使用して指定できます。次の例では、iMaxTimeパラメータが2000に設定されます。
<distributed-scheme>
...
<compressor>
<instance>
<class-name>package.MyDeltaCompressor</class-name>
<init-params>
<init-param>
<param-name>iMaxTime</param-name>
<param-value>2000</param-value>
</init-param>
</init-params>
</instance>
</compressor>
...
</distributed-scheme>
