| Oracle® Coherence開発者ガイド リリース3.7.1 B65026-01 |
|
 前 |
 次 |
この章では、大量のバイナリ・データのヒープ外のキャッシュに関する一般情報について説明します。
この章の内容は次のとおりです。
Coherenceは、ディスク・ファイルなどの潜在的に待機時間の長い記憶域メカニズムを使用して、自動的に失効する大量のデータのキャッシュ処理の効率化を確実にサポートします。利点としては、メモリー内では管理できないほど大量のデータセットをサポートできるのみでなく、そのデータの管理のタイムアウトの失効メカニズムの効率性が保持されること(および管理に関連するリソースが自動的に解放されること)などが挙げられます。最適な使用シナリオとしては、キャッシュされたデータがディスクにページングされている場合に、アクセス頻度が非常に低いか、待機時間が長くてもアクセスが可能なラージ・オブジェクト、XMLドキュメントまたはコンテンツを数多く格納できることなどがあります。第13章「記憶域およびバッキング・マップの実装」を参照してください。
シリアライズ・ページ・キャッシュは、次のように定義されます。
シリアライズは、キャッシュに格納されたオブジェクトがシリアライズされ、バイナリ・ストアに格納されることを意味します。既存の機能であるシリアライズ・マップおよびシリアライズ・キャッシュを参照してください。
ページは、キャッシュに格納されたオブジェクトをセグメント化して管理を効率化することを意味します。
キャッシュは、キャッシュのサイズに指定された制限が存在することを意味し、この制限はキャッシュが同時に管理するページの最大数で、この最大限度を超えると最も古いページから失効します。
これらをまとめると、データがキャッシュに格納された時刻を基準にしてデータをキャッシュ内に配列してから、ページ全体を単位として効率的にキャッシュ内のデータを失効させる機能ということになり、通常はディスクからデータをリロードする必要はありません。
シリアライズ・ページ・キャッシュの主な構成は、キャッシュで管理するページ数とページがアクティブな時間長の2つのパラメータで成り立っています。たとえば、1日のデータをキャッシュに格納する場合、それぞれが1時間に相当する24のページで構成したり、それぞれが15分に相当する96のページで構成できます。
キャッシュ内のデータの各ページは、別々のバイナリ・ストアで管理されます。キャッシュにはバイナリ・ストア・マネージャが必要です。これによってバイナリ・ストアの作成および破棄が可能になります。Coherenceでは、Berkley DB(「BDB」とします)や各種のNIO実装など、組込みのバイナリ・ストア実装のすべてに対してバイナリ・ストア・マネージャが提供されます。
シリアライズ・ページ・キャッシュは、キャッシュ構成ファイルの<external-scheme>および<paged-external-scheme>要素の中で構成されます。詳細は、「external-scheme」および「paged-external-scheme」を参照してください。
Coherenceをパーティション・キャッシュのバッキングに使用した場合は、シリアライズ・マップおよびシリアライズ・キャッシュのいずれかに格納されるデータのすべてがバイナリ形式になるため、パーティション・キャッシュ・サービスを最適化できます。これはバイナリ・マップの最適化と呼ばれ、有効にした場合は、シリアライズ・マップ、シリアライズ・キャッシュおよびシリアライズ・ページ・キャッシュに権限が付与され、キャッシュに格納されるすべてのデータがバイナリであると見なされます。この最適化の結果、CPUおよびメモリーの使用量が減少し、パフォーマンスもやや向上します。キャッシュ構成要素<external-scheme>および<paged-external-scheme>を参照してください。
シリアライズ・ページ・キャッシュには、データのプライマリ記憶域に使用可能な構成およびデータのバックアップ記憶域向けに最適化された構成があり、パーティション・キャッシュ・サービスの高可用性機能も明確にサポートされます。バックアップ記憶域の構成は、パッシブ・モデルと呼ばれています。これは記憶域内のデータをアクティブに失効させるのではなく、プライマリ・キャッシュ記憶域で発生する失効が反映されるためです。パーティション・キャッシュ・サービスに高可用性データ機能(1つ以上のバックアップ数、デフォルト値は1)を使用し、シリアライズ・ページ・キャッシュをそのサービスの主要バッキング記憶域に使用する場合は、シリアライズ・ページ・キャッシュをバックアップ・ストアとしても使用し、passiveオプションを指定してバックアップを構成することをお薦めします。<paged-external-scheme>のキャッシュ構成要素の説明を参照してください。
分散キャッシュ・サービスで使用する場合は、ロード・バランシングおよびフェイルオーバーに特に注意が必要です。キャッシュ・データが大量にある場合は、分散キャッシュ・サービスのpartition-countパラメータを通常より大きく設定します。パーティション数が大きいと、キャッシュ全体が小さなチャンクに分割されて、ロード・バランシングおよびフェイルオーバーによるリカバリ処理が行われます。たとえば、キャッシュのサイズが1TBと予測され、2万個のパーティションがあるとすると、キャッシュは平均で約50MBの単位に分割されます。単位(パーティションのサイズ)が大きすぎると、キャッシュのロード・バランシング時にメモリー不足状態が発生します(パーティション数が素数であることを必ず確認してください。使用可能な素数のリストについては、http://primes.utm.edu/lists/small/を参照してください)。
巨大なデータ失効キャッシュ(例、テラバイト、TB)をサポートするため、失効処理はキャッシュ処理への割込みを発生することなく、デーモン・スレッド上で同時実行されます。このため、単一のキャッシュ・ページに何千または何百万ものオブジェクトが存在し、これらを非同期で失効させることができ、これによってサービスの中断を回避できます。デーモン・スレッドは、デフォルトで有効に設定されたオプションですが、無効にすることもできます。キャッシュ構成要素<external-scheme>および<paged-external-scheme>を参照してください。
大量のデータに対してキャッシュが使用される場合、通常はページがディスクによってバッキングされます。キャッシュは最終的に各ページを失効させてディスク・リソースを解放するため、キャッシュはデフォルトで仮想削除の最適化を使用することになります。このため、キャッシュから明示的に削除されたデータや失効されたデータは、実際には基礎となるバイナリ・ストアから削除されず、ページ(バイナリ・ストア)が完全に空になったときにすべてが消去されます。これによって、特にクラスタ内の大量のデータの再分散が必要な失効処理およびロード・バランシングなどの操作の際に、I/Oが大幅に減少します。この最適化の代償として、ディスク・ファイル(ディスクベースのバイナリ・ストア・オプションの使用時)は管理対象のデータより大きくなる傾向がありますが、ディスク領域は応答時間などの要素と比較して安価と見なされるため、仮想削除の最適化はデフォルトで有効になっていますが、無効にもできます。一般に、ディスク領域はローカルで各サーバーに割り当てられ、テラバイトのキャッシュも100台以上のサーバーでパーティション化されるため、使用されるディスク領域はサーバー1台当たり約20GBに過ぎません(プライマリ・ストアに10GB、バックアップのレベルが1とした場合にバックアップ・ストアに10GB)。
