この章の内容は次のとおりです。
親トピック: キャッシュの使用
クライアント・ビュー - 基礎となるパーティション化されたデータへのアクセスを可能にする仮想レイヤー。この層へのアクセスには、 NamedCache
インタフェースが使用されます。このレイヤーでは、NearCache
やContinuousQueryCache
などの統合データ構造も作成できます。
ストレージ・マネージャ - クライアント層からのキャッシュ関連リクエストを処理するサーバー側の層です。実際のキャッシュ・データ(プライマリ・コピーおよびバックアップ・コピー)、およびロック、イベント・リスナー、マップ・トリガーなどに関する情報を格納するデータ構造を管理します。
バッキング・マップ - 実際のデータを格納するサーバー側のデータ構造。
Coherenceでは、即時利用可能なバッキング・マップ実装およびカスタム実装を構成できます。マップ実装における唯一の制約は、ストレージ・マネージャではキーと値がすべて内部(バイナリ)形式で指定されるという点を理解することです。内部データとオブジェクト形式との間の変換を処理するため、ストレージ・マネージャでは、BackingMapManagerContext
参照によるバッキング・マップの実装が可能です。
図13-1は、バッキング・マップの概念図です。
親トピック: ストレージおよびバッキング・マップの実装
java.util.Map
をサポートする必要があります。Coherenceのローカル記憶域の実装を使用して、レプリケートされたデータや分散データを保存する場合、その機能をバッキング・マップと呼びます。これは、Coherenceがローカル記憶域の実装によって実際に支援(バックアップ)されるためです。その他、ローカル記憶域の一般的な使用法としては、分散キャッシュの前に配置したり、分散キャッシュの後方でバックアップを行うことがあります。注意:
データをヒープに格納しないバッキング・マップを使用する際には注意してください。特に、実際にヒープに収めるには格納データが多すぎる場合が当てはまります。あるキャッシュ操作(索引なしの問合せなど)では、多数のエントリが横断される可能性があります。これにより、バッキング・マップがそれらのエントリをヒープに格納するようになります。また、パーティション転送(バックアップからのリストアや新規メンバーが参加した場合のパーティション所有権の転送など)によって、バッキング・マップが多数のエントリをヒープに格納するようになります。これは、GC問題とOutOfMemory
エラーの発生の原因になる可能性があります。
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
オブジェクトが必要です。シリアライズ・マップは、BinaryStore
のすべてのカスタム実装をサポートします。シリアライズ・マップのデフォルト実装にはcom.tangosol.net.cache.SerializationMap
を使用します。
シリアライズ・キャッシュ: LRUエビクション・ポリシーをサポートするSerializationMap
の拡張機能です。たとえば、シリアライズ・キャッシュによって、ディスク・ファイルのサイズを制限できます。シリアライズ・キャッシュのデフォルト実装にはcom.tangosol.net.cache.SerializationCache
を使用します。
ジャーナル: これは、RAM、ディスクのいずれかまたは両方にデータを格納するバッキング・マップの実装です。ジャーナルには、com.tangosol.io.journal.JournalBinaryStore
クラスが使用されます。エラスティック・データ機能を使用したデータの保存を参照してください。
オーバーフロー・マップ: オーバーフロー・マップは実際には記憶域を提供しませんが、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()
操作によって発生する挿入操作(リードスルー機能またはリードアヘッド機能が構成されたバッキング・マップの場合)
パーティション分散によって発生する統合アクセスおよび更新(クラスタ・ノードのフェイルオーバーまたはフェイルバックから発生する場合もあります)。この場合は、アプリケーション層のコールがなくても、バッキング・マップのいくつかのエントリが挿入または削除されることがあります。
親トピック: ストレージおよびバッキング・マップの実装
その結果、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>100</high-units> <unit-calculator>BINARY</unit-calculator> </local-scheme> </backing-map-scheme>
このバッキング・マップもcom.tangosol.net.cache.LocalCache
ですが、100MBの容量制限があります。このバッキング・マップで保持されるデータの合計量が高水位標を超えると、バッキング・マップから一部のエントリが削除され、データの量が低水位標値(<low-units>
構成要素、デフォルトでは<high-units>
の80%)まで減少します。値がInteger.MAX_VALUE
を超えると、ユニット・ファクタが自動的に使用され、それ応じて<high-units>
および<low-units>
値が調整されます。削除されるエントリの選択方法は、LRU(最低使用頻度)エビクション・ポリシーに従います。その他のオプションには、LFU(最低アクセス頻度)および混合(LRUとLFUの組合せ)があります。
次のバッキング・マップは、未更新の状態のまま1時間を超えたエントリを自動的に削除します。1時間を超えるエントリはコール元には返されず、キャッシュから遅延削除されます。
<backing-map-scheme> <local-scheme> <expiry-delay>1h</expiry-delay> </local-scheme> </backing-map-scheme>
分散スキーム内のバッキング・マップはスライディング失効もサポートしています。有効な場合:
読取り操作により、アクセスされるキャッシュ・エントリの有効期限が延長されます。読取り操作には、get
、getAll
、invoke
およびinvokeAll
が含まれ、エントリは変更されません(たとえば、エントリ・プロセッサのentry.getValue
のみ)。
変更されない参加済のエントリ(たとえば、インターセプタまたはトリガーから)の有効期限も延長されます。
操作が読取りアクセスのみの場合、バックアップ(有効期限が変更される場合)は非同期で実行されます。変更操作が含まれる場合(たとえば、get
or getAll
操作中にエビクションが発生)、バックアップは同期で実行されます。
ノート:
スライディング失効は、aggregate
やquery
操作などの問合せリクエストに基づいてアクセスされるエントリに対しては実行されません。
スライディング失効を有効にするには、<backing-map-scheme>
要素内で<sliding-expiry>
要素をtrue
に設定し、<expiry-delay>
要素がゼロより大きい値に設定されていることを確認します。たとえば、
<distributed-scheme> <scheme-name>dist-expiry</scheme-name> <service-name>DistributedExpiry</service-name> <backing-map-scheme> <sliding-expiry>true</sliding-expiry> <local-scheme> <expiry-delay>3s</expiry-delay> </local-scheme> </backing-map-scheme> </distributed-scheme>
親トピック: ストレージおよびバッキング・マップの実装
図13-2は、従来のバッキング・マップ実装の概念図です。
パーティション・バッキング・マップは、実際のMap
実装の多重化であり、それぞれのマップには同じパーティションに属するエントリのみが格納されます。パーティション・バッキング・マップは、記憶域の上限(java.util.Map
APIで発生)をバッキング・マップの2Gから各パーティションの2Gに上げます。パーティション・バッキング・マップは、一般にソリューションが2Gのバッキング・マップの上限に達すると使用され、多くの場合、エラスティック・データ機能の使用時に可能になります。エラスティック・データ機能を使用したデータの保存を参照してください。
図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> </external-scheme> </backing-map-scheme>
このバッキング・マップはcom.tangosol.net.partition.PartitionSplittingBackingMap
のインスタンスであり、マップを保持する個別のパーティションであるcom.tangosol.net.cache.SerializationCache
のインスタンスから構成され、各パーティションの拡張(nio)メモリーに値が格納されます。nioバッファにはそれぞれ50MBの制限がありますが、バッキング・マップ全体の容量制限は8GB (8192*1048576)です。
親トピック: ストレージおよびバッキング・マップの実装
エラスティック・データには、メモリー内にデータを保存するRAMジャーナルと、ディスクベースのデバイスにデータを保存するフラッシュ・ジャーナルという2つのコンポーネントが含まれます。これらを様々に組み合せ、一般的にはバッキング・マップやバックアップ記憶域に使用しますが、複合キャッシュにも使用できます(たとえば、ニア・キャッシュなど)。RAMジャーナルは、フラッシュ・ジャーナルとともに機能し、ディスクへのシームレスなオーバーフローを実現します。
RAMジャーナルおよびフラッシュ・ジャーナルを使用するキャッシュは、キャッシュ構成ファイル内にキャッシュ・スキーム定義の一部として構成されます。必要に応じて、オペレーション・オーバーライド・ファイルを使用して初期状態の構成をオーバーライドし、ジャーナルの動作を構成します。
この項には次のトピックが含まれます:
ジャーナル機能とは、ジャーナルと呼ばれる一連の変更において状態の変化を記録する技術です。変更が発生すると、ジャーナルは特定のキーの各値を記録し、メモリー内に保存されるツリー構造により、特定のキーの現在の値を含むジャーナル・エントリが追跡されます。エントリの値を検索するには、最新の値を含むジャーナル・エントリへのポインタを含むツリーでキーを検索します。
キーに新しい値が書き込まれることによりジャーナルの変更情報が古くなると、ジャーナルには古い値が累積されます。一定の間隔で古い値を削除すると、新しい値をジャーナルに書き込むスペースができます。
エラスティック・データ機能には、RAMジャーナル実装とフラッシュ・ジャーナル実装が含まれ、相互にシームレスに機能します。たとえば、RAMジャーナルでメモリーを使用し尽くした場合、フラッシュ・ジャーナルがRAMジャーナルからのオーバーフローを自動的に受け入れ、キャッシュをRAMのサイズより格段に大きなサイズにまで拡張できます。
ノート:
エラスティック・データはキーベース操作を実行する際には理想的ですが、一般的に大規模なフィルタベース操作での使用はお薦めしません。ジャーナルを有効にした場合、大きな結果セットでデータ・グリッド操作(問合せや集計など)を実行する際に追加のキャパシティ・プランニングが必要になります。Oracle Coherenceの管理の一般的なガイドラインを参照してください。
リソース・マネージャはジャーナルを制御します。リソース・マネージャはバイナリ・ストアを作成および使用して、ジャーナルの操作を実行します。バイナリ・ストアは、JournalBinaryStore
クラスで実装されます。バイナリ・ストアを介したすべての読書きは、リソース・マネージャで処理されます。RAMジャーナル用のリソース・マネージャ(RamJournalRM
)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM
)があります。
親トピック: エラスティック・データ機能を使用したデータの保存
キャッシュ構成ファイルでは、<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ジャーナルの失効およびエビクション設定を定義しています。
<distributed-scheme> <scheme-name>distributed-journal</scheme-name> <service-name>DistributedCacheFlashJournal</service-name> <backing-map-scheme> <ramjournal-scheme> <eviction-policy>LFU</eviction-policy> <high-units>100</high-units> <low-units>80</low-units> <unit-calculator>Binary</unit-calculator> <expiry-delay>0</expiry-delay> </ramjournal-scheme> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme>
親トピック: ジャーナル・スキームの定義
ジャーナル・スキームは、バックアップ記憶域およびバッキング・マップに使用されます。デフォルトでは、バッキング記憶域としてフラッシュ・ジャーナルが使用されます。このデフォルトの動作は、<backup-storage>
要素の中のストレージ・タイプを明示的に指定することで、変更できます。次の構成ではバッキング・マップにRAMジャーナルを使用し、明示的にバックアップ記憶域に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-ram</scheme-name> </backup-storage> <backing-map-scheme> <ramjournal-scheme/> </backing-map-scheme> <autostart>true</autostart> </distributed-scheme> <ramjournal-scheme> <scheme-name>example-ram</scheme-name> </ramjournal-scheme> </caching-schemes>
親トピック: ジャーナル・スキームの定義
必要に応じて、カスタム・バッキング・マップを使用するようにジャーナル・スキームを構成できます。カスタム・マップ実装では、CompactSerializationCache
クラスを拡張し、完全に同一のpublicなコンストラクタのセットを宣言する必要があります。
カスタム実装を有効にするには、<class-scheme>
要素を追加し、その値をカスタム・クラスの完全修飾名に指定します。カスタム・クラスに必要な任意のパラメータは、<init-params>
要素を使用して定義できます。次の例では、MyCompactSerializationCache
というカスタム・マップ実装を有効にします。
<flashjournal-scheme> <scheme-name>example-flash</scheme-name> <class-name>package.MyCompactSerializationCache</class-name> </flashjournal-scheme>
親トピック: ジャーナル・スキームの定義
リソース・マネージャはジャーナルの動作を制御します。RAMジャーナル用のリソース・マネージャ(RamJournalRM
)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM
)があります。クラスタのリソース・マネージャは、tangosol-coherence-override.xml
オペレーション・オーバーライド・ファイルで構成されます。構成オーバーライドが設定されていないと、リソース・マネージャのデフォルトの即時利用可能な設定が使用されます。
この項には次のトピックが含まれます:
<ramjournal-manager>
要素は、RAMジャーナルの動作を構成するために使用されます。次のリストは、RAMジャーナルのデフォルト特性を示しています。ramjournal-managerを参照してください。
バイナリ値は、デフォルトでは64KBに制限されています(最大は4MB)。フラッシュ・ジャーナルは、バイナリ値が構成済制限を超えると自動的に使用されます。
個々のバッファ(ジャーナル・ファイル)は、デフォルトでは2MBに制限されています(最大は2GB)。最大ファイル・サイズは変更しないでください。
ジャーナルは最大512個のファイルで構成されています。511個のファイルは使用可能なファイルで、1個のファイルはデプリート状態ために予約されています。
ジャーナルで使用される合計メモリーは、デフォルトでは1GBに制限されています(最大は64GB)。フラッシュ・ジャーナルは、ジャーナルの合計メモリーが構成済制限を超えると自動的に使用されます。
RAMジャーナル・リソース・マネージャを構成するには、<ramjournal-manager>
要素を<journaling-config>
要素の中に追加して、オーバーライドするサブ要素を定義します。次の例では、RAMジャーナル・サブ要素のオーバーライドを示しています。
<?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 system-property="coherence.ramjournal.size"> 2G</maximum-size> </ramjournal-manager> </journaling-config> </cluster-config> </coherence>
親トピック: ジャーナルの動作の変更
<flashjournal-manager>
要素は、フラッシュ・ジャーナルの動作を構成するために使用されます。次のリストは、フラッシュ・ジャーナルのデフォルト特性を示しています。flashjournal-managerを参照してください。
バイナリ値は、デフォルトでは64MBに制限されています。
個々のバッファ(ジャーナル・ファイル)は、デフォルトでは2GBに制限されています(最大は4GB)。
ジャーナルは最大512個のファイルで構成されています。511個のファイルは使用可能なファイルで、1個のファイルはデプリート状態ために予約されています。ジャーナルはデフォルトでは1TBに制限され、理論上最大2TBとなります。
ジャーナルには、デフォルトで11GBの高いジャーナル・サイズが設定されています。この高いサイズによって、ジャーナルから失効した値の削除を開始するタイミングが決定されます。これは、ジャーナル・サイズの強い制限ではなく、依然として最大ファイル数(512)まで大きくなることができます。
キーは、圧縮された形式でメモリー内に残ります。値については、書き込まれていない(キューに入れられているか非同期に書き込まれる)データのみがメモリーに残ります。ヒープのサイズを決定するときの合理的な見積りは、キー・データを保持するエントリごとに50バイトを許可し(これは、RAMとフラッシュの両方のジャーナルに当てはまります)、バッファ用の追加の容量(16MB)を含めることです。失効またはエビクションを構成すると、エントリ・サイズは増加します。
フラッシュ・ジャーナルは、RAMジャーナルの容量に到達すると、オーバーフローとして自動的に使用されます。フラッシュ・ジャーナルは、フラッシュ・ジャーナルの最大サイズを0 (ジャーナルがRAMジャーナルを排他的に使用)に設定することで無効にできます。
フラッシュ・ジャーナル・リソース・マネージャを構成するには、<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> <high-journal-size system-property="coherence.flashjournal.highjournalsize"> 11GB</high-journal-size> </flashjournal-manager> </journaling-config> </cluster-config> </coherence>
ノート:
ジャーナル・ファイルを保存するために指定されたディレクトリが存在する必要があります。ディレクトリが存在しない場合、警告がログに記録され、JVMで指定されたデフォルトの一時ファイル・ディレクトリが使用されます。
親トピック: ジャーナルの動作の変更
非同期バックアップは、通常、クライアントのパフォーマンスを向上させるために使用されます。ただし、非同期バックアップを使用するアプリケーションは、データの整合性に対して発生しうる影響に対処する必要があります。特に、バックアップ操作が(成功または失敗して)完了する前にキャッシュ操作が完了する場合があり、バックアップ操作の完了順序は決まっていません。アプリケーションでバックアップが不要な場合(つまり、損失したデータを記録システムからリストアできる場合)は、非同期バックアップの使用を検討してください。しかし、この場合でも、ノード障害の発生時における迅速なリカバリをアプリケーションで提供する必要があります。
ノート:
非同期バックアップをローリング再起動とともに使用するには、stop
メソッドまたはkill -9
ではなく、shutdown
メソッドを使用して、クラスタ・メンバーのシャットダウンを正しい順序で実行する必要があります。そうしないと、非同期バックアップの完了前にメンバーがシャットダウンされる場合があります。shutdown
メソッドは、すべての更新が完了することを保証します。
分散キャッシュの非同期バックアップを有効化するには、true
に設定した<async-backup>
要素を<distributed-scheme>
要素内に追加します。たとえば:
<distributed-scheme> ... <async-backup>true</async-backup> ... </distributed-scheme>
分散キャッシュ・サービス・タイプのすべてのインスタンスに対して非同期バックアップを有効にするには、オペレーション・オーバーライド・ファイルで、パーティション・キャッシュ・サービスのasync-backup
初期化パラメータをオーバーライドします。たとえば:
<?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="27"> <param-name>async-backup</param-name> <param-value system-property="coherence.distributed.asyncbackup"> false </param-value> </init-param> </init-params> </service> </services> </cluster-config> </coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.distributed.asyncbackup
システム・プロパティを使用して、分散キャッシュ・サービス・タイプのすべてのインスタンスに対して非同期バックアップを有効にできます。たとえば:
-Dcoherence.distributed.asyncbackup=true
親トピック: ストレージおよびバッキング・マップの実装
デルタ・バックアップでは、新旧の値を持つ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="coherence.distributed.compressor"> standard</param-value> </init-param> </init-params> </service> </services> </cluster-config> </coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、coherence.distributed.compressor
システム・プロパティを使用して、分散キャッシュ・サービス・タイプのすべてのインスタンスに対してデルタ・バックアップを有効にできます。たとえば:
-Dcoherence.distributed.compressor=standard
親トピック: デルタ・バックアップの使用
カスタム・コンプレッサを使用してデルタ・バックアップを実行するには、<instance>
サブ要素を追加して、DeltaCompressor
インタフェースを実装するクラスの完全修飾名を指定します。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>
親トピック: デルタ・バックアップの使用