| Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発 12c (12.1.3) E56206-04 |
|
 前 |
 次 |
この章では、Coherenceにおける記憶域の実装方法と、Coherenceバッキング・マップの構成方法について説明します。
この章には次の項が含まれます:
Coherenceのパーティション(分散)キャッシュ・サービスは、次の3つのレイヤーに分かれています。
クライアント・ビュー - 基礎となるパーティション化されたデータへのアクセスを可能にする仮想レイヤー。この層へのアクセスには、 NamedCacheインタフェースが使用されます。このレイヤーでは、NearCacheやContinuousQueryCacheなどの統合データ構造も作成できます。
ストレージ・マネージャ - クライアント層からのキャッシュ関連リクエストを処理するサーバー側の層です。実際のキャッシュ・データ(プライマリ・コピーおよびバックアップ・コピー)、およびロック、イベント・リスナー、マップ・トリガーなどに関する情報を格納するデータ構造を管理します。
バッキング・マップ - 実際のデータを格納するサーバー側のデータ構造。
Coherenceでは、即時利用可能なバッキング・マップ実装およびカスタム実装を構成できます。マップ実装における唯一の制約は、ストレージ・マネージャではキーと値がすべて内部(バイナリ)形式で指定されるという点を理解することです。内部データとオブジェクト形式との間の変換を処理するため、ストレージ・マネージャでは、BackingMapManagerContext参照によるバッキング・マップの実装が可能です。
図14-1はバッキング・マップの概念図です。
ローカル記憶域は、Coherenceで管理されるデータを実際に保存またはキャッシュするデータ構造です。ローカル記憶域を提供するオブジェクトは、同じ標準のコレクション・インタフェースである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()操作によって発生する挿入操作(リードスルー機能またはリードアヘッド機能が構成されたバッキング・マップの場合)
パーティション分散によって発生する統合アクセスおよび更新(クラスタ・ノードのフェイルオーバーまたはフェイルバックから発生する場合もあります)。この場合は、アプリケーション層のコールがなくても、バッキング・マップのいくつかのエントリが挿入または削除されることがあります。
バッキング・マップでは、実際の実装方法に応じて、次の方法でキャッシュ・データが格納されます。
ヒープ上メモリー
ヒープ外メモリー
ディスク(メモリーマップ・ファイルまたはインプロセス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>100</high-units>
<unit-calculator>BINARY</unit-calculator>
<unit-factor>1048576</unit-factor>
</local-scheme>
</backing-map-scheme>
このバッキング・マップもcom.tangosol.net.cache.LocalCacheですが、100MBの容量制限があります。このバッキング・マップで保持されるデータの合計量が高水位標を超えると、バッキング・マップから一部のエントリが削除され、データの量が低水位標値(<low-units>構成要素、デフォルトでは<high-units>の80%)まで減少します。削除されるエントリの選択方法は、LRU(最低使用頻度)エビクション・ポリシーに従います。その他のオプションには、LFU(最低アクセス頻度)および混合(LRUとLFUの組合せ)があります。<high-units>の値はInteger.MAX_VALUE (約2GB)に制限されます。この制限を解除するため(ただし後方互換性は保持)、Coherenceでは<unit-factor>要素が使用されます。たとえば、<high-units>値が8192で<unit-factor>が1048576の場合、高水位標値は8GBになります。
次のバッキング・マップは、未更新の状態のまま1時間を超えたエントリを自動的に削除します。ただし、これは「安易な」削除方法であり、最終更新から1時間以上経過していればいつでも発生する可能性があります。保証されるのは、1時間を超過したエントリがコール元に返されないことのみです。
<backing-map-scheme>
<local-scheme>
<expiry-delay>1h</expiry-delay>
</local-scheme>
</backing-map-scheme>
次のバッキング・マップは、com.tangosol.net.cache.SerializationCacheのインスタンスであり、拡張(nio)メモリーに値を格納しますが、100MB (100*1048576)の容量制限があります。
|
注意: NIOメモリー・マネージャの実装は非推奨です。現在の実装では、かわりにジャーナル・バイナリ・ストアを使用する必要があります。「エラスティック・データ機能を使用したデータの保存」を参照してください。 |
<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>
従来のバッキング・マップの実装には、対応するノードが所有するすべてのパーティションのエントリが含まれていました。(パーティション送信時に、クライアントから見て一時的に所有者の存在しない「未完了」エントリも保持されることがありました)。
図14-2は、従来のバッキング・マップ実装の概念図です。
パーティション・バッキング・マップは、基本的には実際のマップ実装の多重化であり、それぞれのマップには同じパーティションに属するエントリのみが格納されるようになりました。
図14-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)です。
エラスティック・データ機能は、メモリーとディスクベースのデバイス間で、シームレスにデータを保存するために使用されます。この機能は、特にSSD (Solid State Disk)などの高速ディスクベースのデバイスを使用する場合に調整され、SSDからデータを読書きする際にメモリーと同等の速度でアクセスできるようにします。エラスティック・データ機能では、ジャーナルという技術を使用して、メモリーとディスク間の保存操作を最適化します。
エラスティック・データには、メモリー内にデータを保存するRAMジャーナルと、ディスクベースのデバイスにデータを保存するフラッシュ・ジャーナルという2つのコンポーネントが含まれます。これらを様々に組み合せ、一般的にはバッキング・マップやバックアップ記憶域に使用しますが、複合キャッシュにも使用できます(たとえば、ニア・キャッシュなど)。RAMジャーナルは、常にフラッシュ・ジャーナルとともに機能し、ディスクへのシームレスなオーバーフローを実現します。
RAMジャーナルおよびフラッシュ・ジャーナルを使用するキャッシュは、キャッシュ構成ファイル内にキャッシュ・スキーム定義の一部として構成されます。必要に応じて、オペレーション・オーバーライド・ファイルを使用して初期状態の構成をオーバーライドし、ジャーナルの動作を構成します。
この項には次のトピックが含まれます:
ジャーナル機能とは、ジャーナルと呼ばれる一連の変更において状態の変化を記録する技術です。変更が発生すると、ジャーナルは特定のキーの各値を記録し、メモリー内に保存されるツリー構造により、特定のキーの現在の値を含むジャーナル・エントリが追跡されます。エントリの値を検索するには、最新の値を含むジャーナル・エントリへのポインタを含むツリーでキーを検索します。
キーに新しい値が書き込まれることによりジャーナルの変更情報が古くなると、ジャーナルには古い値が累積されます。一定の間隔で古い値を削除すると、新しい値をジャーナルに書き込むスペースができます。
エラスティック・データ機能には、RAMジャーナル実装とフラッシュ・ジャーナル実装が含まれ、相互にシームレスに機能します。たとえば、RAMジャーナルでメモリーを使用し尽くした場合、フラッシュ・ジャーナルがRAMジャーナルからのオーバーフローを自動的に受け入れることで、キャッシュをRAMのサイズより格段に大きなサイズにまで拡張できます。
|
注意: エラスティック・データはキーベース操作を実行する際には理想的ですが、一般的に大規模なフィルタベース操作での使用はお薦めしません。ジャーナルを有効にした場合、大きな結果セットでデータ・グリッド操作(問合せや集計など)を実行する際に追加のキャパシティ・プランニングが必要になります。詳細は、『Oracle Coherenceの管理』を参照してください。 |
リソース・マネージャはジャーナルを制御します。リソース・マネージャはバイナリ・ストアを作成および使用して、ジャーナルの操作を実行します。バイナリ・ストアは、JournalBinaryStoreクラスで実装されます。バイナリ・ストアを介したすべての読書きは、リソース・マネージャで処理されます。RAMジャーナル用のリソース・マネージャ(RamJournalRM)とフラッシュ・ジャーナル用のリソース・マネージャ(FlashJournalRM)があります。これらの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ジャーナルの失効およびエビクション設定を定義しています。
<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>
<unit-factor>1</unit-factor>
<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なコンストラクタのセットを宣言する必要があります。このAPIの詳細は、Oracle Coherence Java APIリファレンスを参照してください。
カスタム実装を有効にするには、<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="tangosol.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)を含めることです。失効またはエビクションを構成すると、エントリ・サイズは増加します。
フラッシュ・ジャーナル・リソース・マネージャを構成するには、<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="tangosol.coherence.flashjournal.highjournalsize">
11GB</high-journal-size>
</flashjournal-manager>
</journaling-config>
</cluster-config>
</coherence>
|
注意: ジャーナル・ファイルを保存するために指定されたディレクトリが存在する必要があります。ディレクトリが存在しない場合、警告がログに記録され、JVMで指定されたデフォルトの一時ファイル・ディレクトリが使用されます。 |
分散キャッシュでは、同期と非同期の両方のバックアップがサポートされています。同期バックアップでは、バックアップ操作が完了するまでクライアントはブロックされます。非同期バックアップでは、バックアップ操作中にクライアントはリクエストへの応答を続行します。バックアップは、非同期バックアップが明示的に有効化されていないかぎり、同期で実行されます。
非同期バックアップは、通常、クライアントのパフォーマンスを向上させるために使用されます。ただし、非同期バックアップを使用するアプリケーションは、データの整合性に対して発生しうる影響に対処する必要があります。特に、バックアップ操作が(成功または失敗して)完了する前にキャッシュ操作が完了する場合があり、バックアップ操作の完了順序は決まっていません。アプリケーションでバックアップが不要な場合(つまり、損失したデータを記録システムからリストアできる場合)は、非同期バックアップの使用を検討してください。しかし、この場合でも、ノード障害の発生時における迅速なリカバリをアプリケーションで提供する必要があります。
分散キャッシュの非同期バックアップを有効化するには、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="tangosol.coherence.distributed.asyncbackup">
false
</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>
オペレーション・オーバーライド・ファイルを使用するかわりに、tangosol.coherence.distributed.asyncbackupシステム・プロパティを使用して、分散キャッシュ・サービス・タイプのすべてのインスタンスに対して非同期バックアップを有効にすることもできます。例:
-Dtangosol.coherence.distributed.asyncbackup=true
デルタ・バックアップとは、プライマリ・エントリが変更されたときに、エントリ全体を置き換えるのではなく、バックアップ・バイナリ・エントリに変更を適用するために使用される技術です。デルタ・バックアップは、更新されるエントリは大きいが変更は小さい場合に最適です。そのような場合、エントリ全体の書換えに関するコストよりエントリの一部分のみを変更するコストの方が一般的には小さいので、パフォーマンスが向上します。ただし、一般的に、エントリに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>
