プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Coherenceでのアプリケーションの開発
12c (12.2.1.3.0)
E90213-04
目次へ移動
目次

前
次

15 シリアライズ・ページ・キャッシュ

Coherenceでは、大量のバイナリ・データがヒープ・キャッシュにキャッシュされます。

この章の内容は次のとおりです。

15.1 シリアライズ・ページ・キャッシュの理解

Coherenceでは、ディスク・ファイルなどの潜在的に高レイテンシの記憶域メカニズムを使用して、自動的に失効する大規模データの効率的なキャッシュ処理がサポートされます。利点としては、メモリー内では管理できないほど大量のデータ・セットをサポートできるのみでなく、そのデータの管理のタイムアウトの失効メカニズムの効率性が保持されること(および管理に関連するリソースが自動的に解放されること)などが挙げられます。最適な使用シナリオとしては、キャッシュされたデータがディスクにページングされている場合に、アクセス頻度が非常に低いか、待機時間が長くてもアクセスが可能なラージ・オブジェクト、XMLドキュメントまたはコンテンツを数多く格納できることなどがあります。記憶域およびバッキング・マップの実装を参照してください。

シリアライズ・ページ・キャッシュは、次のように定義されます。

  • シリアライズは、キャッシュに格納されたオブジェクトがシリアライズされ、バイナリ・ストアに格納されることを意味します。既存の機能であるシリアライズ・マップおよびシリアライズ・キャッシュを参照してください。

  • ページは、キャッシュに格納されたオブジェクトをセグメント化して管理を効率化することを意味します。

  • キャッシュは、キャッシュのサイズに指定された制限が存在することを意味し、この制限はキャッシュが同時に管理するページの最大数で、この最大限度を超えると最も古いページから失効します。

これらをまとめると、データがキャッシュに格納された時刻を基準にしてデータをキャッシュ内に配列してから、ページ全体を単位として効率的にキャッシュ内のデータを失効させる機能ということになり、通常はディスクからデータをリロードする必要はありません。

15.2 シリアライズ・ページ・キャッシュの構成

シリアライズ・ページ・キャッシュの主な構成は、キャッシュで管理するページ数とページがアクティブな時間長の2つのパラメータで成り立っています。たとえば、1日のデータをキャッシュに格納する場合、それぞれが1時間に相当する24のページで構成したり、それぞれが15分に相当する96のページで構成できます。

キャッシュ内のデータの各ページは、別々のバイナリ・ストアで管理されます。キャッシュにはバイナリ・ストア・マネージャが必要です。これによってバイナリ・ストアの作成および破棄が可能になります。Coherenceでは、Berkley DBなど、組込みのバイナリ・ストア実装のすべてに対してバイナリ・ストア・マネージャが提供されます。

シリアライズ・ページ・キャッシュは、キャッシュ構成ファイルの<external-scheme>および<paged-external-scheme>要素の中で構成されます。external-schemeおよびpaged-external-schemeを参照してください。

15.3 パーティション・キャッシュ・サービスの最適化

Coherenceでは、シリアライズされたマップおよびキャッシュのいずれかに格納されているデータが完全にバイナリ形式であることを利用して、パーティション・キャッシュ・サービスが最適化されます。これはバイナリ・マップの最適化と呼ばれ、有効にした場合は、シリアライズ・マップ、シリアライズ・キャッシュおよびシリアライズ・ページ・キャッシュに権限が付与され、キャッシュに格納されるすべてのデータがバイナリであると見なされます。この最適化の結果、CPUおよびメモリーの使用量が減少し、パフォーマンスもやや向上します。external-schemeおよびpaged-external-schemeを参照してください。

15.4 高可用性のための構成

シリアライズ・ページ・キャッシュには、データのプライマリ記憶域に使用可能な構成およびデータのバックアップ記憶域向けに最適化された構成があり、パーティション・キャッシュ・サービスの高可用性機能がサポートされます。バックアップ記憶域の構成は、パッシブ・モデルと呼ばれています。これは記憶域内のデータをアクティブに失効させるのではなく、プライマリ・キャッシュ記憶域で発生する失効が反映されるためです。パーティション・キャッシュ・サービスに高可用性データ機能(1つ以上のバックアップ数、デフォルト値は1)を使用し、シリアライズ・ページ・キャッシュをそのサービスの主要バッキング記憶域に使用する場合は、シリアライズ・ページ・キャッシュをバックアップ・ストアとしても使用し、passiveオプションを指定してバックアップを構成することをお薦めします。paged-external-schemeを参照してください。

15.5 ロード・バランシングおよびフェイルオーバーの構成

分散キャッシュ・サービスでシリアライズ・ページ・キャッシュを使用する場合は、ロード・バランシングおよびフェイルオーバーのために特別な考慮が必要です。キャッシュ・データが大量にある場合は、分散キャッシュ・サービスのpartition-countパラメータを通常より大きく設定します。パーティション数が大きいと、キャッシュ全体が小さなチャンクに分割されて、ロード・バランシングおよびフェイルオーバーによるリカバリ処理が行われます。たとえば、キャッシュのサイズが1TBと予測され、2万個のパーティションがあるとすると、キャッシュは平均で約50MBの単位に分割されます。単位(パーティションのサイズ)が大きすぎると、キャッシュのロード・バランシング時にメモリー不足状態が発生します。(パーティション数が素数であることを必ず確認してください。使用可能な素数のリストについては、http://primes.utm.edu/lists/small/を参照してください。)

15.6 巨大なキャッシュのサポート

失効データの巨大なキャッシュ(たとえばテラバイト単位)をサポートするため、失効処理はキャッシュ処理への割込みを発生することなく、デーモン・スレッド上で同時実行されます。このため、単一のキャッシュ・ページに何千または何百万ものオブジェクトが存在し、これらを非同期で失効させることができ、これによってサービスの中断を回避できます。デーモン・スレッドは、デフォルトで有効に設定されたオプションですが、無効にすることもできます。external-schemeおよびpaged-external-schemeを参照してください。

大量のデータに対してキャッシュが使用される場合、通常はページがディスクによってバッキングされます。キャッシュは最終的に各ページを失効させてディスク・リソースを解放するため、キャッシュはデフォルトでは仮想削除の最適化を使用します。このため、キャッシュから明示的に削除されたデータや失効したデータは、実際には基礎となるバイナリ・ストアから削除されず、ページ(バイナリ・ストア)が完全に空になったときにすべてが消去されます。これによって、特にクラスタ内の大量のデータの再分散が必要な失効処理およびロード・バランシングなどの操作の際に、I/Oが大幅に減少します。この最適化の代償として、ディスク・ファイル(ディスクベースのバイナリ・ストア・オプションを使用する場合)が、それらが管理しているデータが示唆するよりも大きくなる傾向があります。ディスク領域は応答時間などの他の要素と比較して安価と見なされるため、仮想削除の最適化はデフォルトで有効になっていますが、無効にすることもできます。一般に、ディスク領域はローカルで各サーバーに割り当てられ、テラバイトのキャッシュも100台以上のサーバーでパーティション化されるため、使用されるディスク領域はサーバー1台当たり約20GBにすぎません(プライマリ・ストアに10GB、バックアップのレベルが1とした場合にバックアップ・ストアに10GB。)