JP4489292B2 - 高性能オブジェクト・キャッシュ - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は情報配信に関し、より詳しく述べれば、ネットワークを介して効率的かつ高速にクライアントに配信される情報オブジェクト用のキャッシュに関する。
【０００２】
【発明の背景】
いくつもの重要なコンピュータ・テクノロジが、かなりの範囲にわたって中央格納場所からリモート・デバイスへの迅速な情報の配信に頼っている。たとえば、クライアント／サーバ・モデルのコンピューティングにおいては、１ないしは複数のサーバが情報のストアに使用される。クライアント・コンピュータまたはプロセスは、サーバから分離されて、ネットワークを使用してこれらのサーバに接続される。クライアントは、必要な情報のネットワーク・アドレスを指定することによって、これらのサーバの１つにその情報を要求する。サーバは、指定されたネットワーク・アドレスに基づいて情報を見つけ出し、ネットワークを介してそれをクライアントに送信し、トランザクションを完了する。
【０００３】
ワールド・ワイド・ウェブは、広く使用されているクライアント／サーバ・コンピューティング・モデルの応用である。図１は、ウェブ・システムにおいて使用されるエレメント間の関係を簡潔に示したブロック図である。それぞれをコンピュータもしくはブラウザ等のソフトウエア・プロセスとする１ないしは複数のウェブ・クライアント１０ａ、１０ｂが、直接もしくはインターネット・サービス・プロバイダ等の仲介者を介して、あるいはオンライン情報サービスを介してインターネットと呼ばれるグローバル情報ネットワーク２０に接続されている。
【０００４】
ウェブ・サーバ４０は、ネットワーク・リンク４２によって同様にインターネット２０に接続されている。ウェブ・サーバ４０は、中央のドメイン・ネーム・サーバ（ＤＮＳ）においてインデクス付けされた合意に基づくフォーマットを用いて関連付けされている１ないしは複数のインターネット・ネットワーク・アドレスならびに逐語的なホスト名を有する。サーバは、ドキュメントおよびイメージ等の、要求に応じてクライアントに提供するためのマルチメディア情報リソースを擁している。ウェブ・サーバ４０が、それに加えて、もしくはそれに代えて、要求に応答してこの種のリソースを動的に生成するためのソフトウエアを有していることもある。
【０００５】
クライアント１０ａ、１０ｂおよびウェブ・サーバ４０は、伝達する情報のフォーマットを指定する、１ないしは複数の合意に基づくプロトコルを使用して通信する。クライアント１０ａは、ＤＮＳを使用して特定のサーバのネットワーク・アドレスをルックアップし、ハイパーテキスト・トランスファ・プロトコル（ＨＴＴＰ）と呼ばれる通信プロトコルを使用して当該サーバとの接続を確立する。ユニフォーム・リソース・ロケータ（ＵＲＬ）は、ウェブ・サーバ４０にストアされた、あるいはそれによって動的に生成されたそれぞれの情報オブジェクトを固有識別する。ＵＲＬは、ネットワーク・アドレスの一形式であり、ネットワーク内にストアされた情報の場所を識別する。
【０００６】
ワールド・ワイド・ウェブのパフォーマンスを制限する主要な要因は、インターネット２０を介してウェブ・サーバ４０からクライアントに情報を供給し得る速度である。パフォーマンスは、インターネットを通るネットワーク・ルートの速度、信頼性、および輻輳のレベルによって、地理的な距離がもたらす遅延によって、さらにはサーバの負荷レベルによって制限を受ける。したがって、サーバから地理的に離れたリポジトリ内に一般的な情報オブジェクトのレプリカをストアしておくことにより、クライアントのトランザクション時間を節約することができる。オブジェクトのレプリカのための各ローカル・リポジトリは、一般にキャッシュと呼ばれている。クライアントがオリジナルのウェブ・サーバにアクセスするより、位相的にもっとも近いキャッシュにあるレプリカにアクセスする方が高速になるだけでなく、インターネット・サーバのトラフィックを低減することができる。
【０００７】
一構成におけるキャッシュは、図１に示されるように、論理的にウェブ・クライアント１０ａ、１０ｂと、ウェブ・サーバ４０の間に介挿されるプロキシ・サーバ３０内に置かれる。プロキシ・サーバは、クライアントに対してはサーバとして、サーバに対してはクライアントとして作用する「仲介人」のゲートウエイ・サービスを提供する。キャッシュを備えたプロキシ・サーバは、キャッシング・プロキシ・サーバもしくは、一般的に「プロキシ・キャッシュ」と呼ばれている。
【０００８】
プロキシ・キャッシュ３０は、ウェブ・クライアント１０ａ、１０ｂからウェブ・サーバ４０に向けられたリソースの要求をインターセプトする。プロキシ３０内のキャッシュが、要求されたリソースのレプリカを有し、それが特定の新しさに関する制約に適合するとき、プロキシがウェブ・クライアント１０ａ、１０ｂに応答してそのリソースを直接提供する。この構成においては、リンク４２を介して行われるデータ転送の数ならびに量が大きく抑えられる。この結果、ネットワーク・リソースまたはオブジェクトが、より迅速にウェブ・クライアント１０ａ、１０ｂに提供されることになる。
【０００９】
この種のキャッシングにおける主要な問題は、キャッシュ内のオブジェクトに関する効率的なストア、配置、および取り出しである。この明細書は、キャッシュ内におけるマルチメディア・オブジェクトのストア、配置、および取り出しに関連するテクノロジに関連する。キャッシュ内のオブジェクト用ストレージ装備は、「キャッシュ・オブジェクト・ストア」もしくは「オブジェクト・ストア」と呼ばれている。
【００１０】
ワールド・ワイド・ウェブ等の重いトラフィック環境を効果的に取り扱うために、キャッシュ・オブジェクト・ストアには、数千万ないしは数億の異なるオブジェクトを取り扱えるだけでなく、同時にオブジェクトのストア、削除、およびフェッチが可能であることが要求される。このため、キャッシュのパフォーマンスは、オブジェクトの数により大きく低下するようであってはならない。パフォーマンスは、キャッシュ・オブジェクト・ストアが目指す目標である。
【００１１】
キャッシュ内のオブジェクトを見つけ出すことは、もっとも一般的なオペレーションであり、したがってキャッシュは、サーチの実行において極めて高速でなければならない。キャッシュのパフォーマンスを制限する主要因は、ルックアップ時間である。オブジェクトがキャッシュ内に存在するか（「ヒット」）あるいは存在しないか（「ミス」）を可能な限り高速に決定し得るキャッシュがあると望ましい。過去のアプローチにおいては、数百万のオブジェクトをストアし得るキャッシュが、伝統的なファイル・システム・ストレージ構造に使用されている。伝統的なファイル・システムは、マルチメディア・オブジェクトのキャッシュに対する適合性が低いが、これはファイル・システムが特定のオブジェクト・サイズに調整されていること、およびファイル・システムのメタデータを調べるためには複数のディスク・ヘッドを動作させる必要があることを理由とする。オブジェクト・ストアは、オブジェクトのルックアップ・タスクに専用ＤＲＡＭメモリを使用することにより、より高いルックアップ・パフォーマンスを得ることができるが、数千万ないしは数百万のオブジェクトが存在することから、メモリ・ルックアップ・テーブルを非常にコンパクトにしなければならない。
【００１２】
オブジェクトを見つけた後は、クライアントにそれを効率的に転送する必要がある。最近のディスク・ドライブは、連続データの読み出しおよび書き込みにおいて高いパフォーマンスを提供するが、ディスク・ヘッドがディスク上の各部に移動しなければならないとき、大きなパフォーマンスの遅れを招く。これらのディスク・ヘッドの動きを「シーク」と呼んでいる。ディスクのパフォーマンスは、一般にドライブの１秒当たりの定格シーク数に拘束される。キャッシュのパフォーマンスを最適化するためには、連続したデータのブロックの読み出しおよび書き込みを行うことによって、ディスクのシーク数を最小化することが望ましい。
【００１３】
いずれにしても最終的にはオブジェクト・ストアが満杯になり、特定のオブジェクトを消去して新しいコンテンツのためにスペースを開ける必要が生じる。これが「ガーベジ・コレクション」と呼ばれるプロセスである。ガーベジ・コレクションは、充分に効率的であり、システムのパフォーマンスを大きく低下させることなく連続的に動作し、その一方で将来的なキャッシュのパフォーマンスにおいてもっとも影響の少ないオブジェクトを削除し得るものでなければならない。
【００１４】
【過去のアプローチ】
過去においてはキャッシュ・オブジェクト・ストアの構成に４つのアプローチが使用されている：すなわち、ネイティブ・ファイル・システムの使用、メモリ‐ブロック「ページ」キャッシュの使用、データベースの使用、および「サイクロン」の使用である。これらの従来的なアプローチのそれぞれには、無視できない欠点が存在する。
【００１５】
ネイティブ・ファイル・システムを用いるアプローチは、サーバ上で走るオペレーティング・システムのファイル・システムを使用してキャッシュを作成し、管理する。ファイル・システムは、そこで考慮されている特定のアプリケーション用に、つまり、ユーザ・データ・ファイルおよびシステム・データ・ファイルのストアおよび取り出し用に設計されている。ファイル・システムは、ファイル・マネジメント・アプリケーション用の設計および最適化がなされる。これらは、代表的なデータ・ファイル・サイズ用に、かつ比較的少ないファイル数（合計および１フォルダ／ディレクトリ内の両方における数）用に最適化される。伝統的なファイル・システムは、ファイルを開き、読み出し／書き込みを行い、それを閉じるためのシーク数を最小化すべく最適化されてはいない。多くのファイル・システムは、大量のファイルが存在するとき、ファイルを見つけ出し、それを開く上で著しいパフォーマンスの低下を招く。代表的なファイル・システムは、ドライブの表面に小さなディスク・ブロックが散在してしまうフラグメンテーションを生じ、データのアクセスに必要なディスク・シーク数の増加をもたらしているだけでなく、ストレージ空間の無駄を招いている。
【００１６】
またファイル・システムは、ユーザのデータ・ファイル・マネジメント用に設計されていることから、キャッシュ・オブジェクト・ストアに無関係な装備を含み、この応用にとって反生産的であることは疑いようがない。例を挙げると次のようなものがある：すなわち、ランダム・アクセスおよび選択的修正のサポート、ファイル許可、ファイルの名称変更のサポート、および時間を隔てたファイルに対する追加のサポートである。さらにファイル・システムは、データの喪失を最小化するために、書き込み時および、障害後のファイル・システムの再構築時に、パフォーマンスの犠牲の上に多大なエネルギを投資する。結局ファイル・システムは、ウェブ・オブジェクトのキャッシュに存在し得る数百万のファイルの取り扱いにあまり適していない。ファイル・システムは、サイズが大きく変動するインターネット・マルチメディア・オブジェクトを効率的にサポートしない ―― 特に、非常に小さいオブジェクトもしくは非常に大きいオブジェクトのサポートが一般に効率的でない。ファイル・システムは、メタデータの検索およびブロックのチェーニングに非常に多くのディスク・シークを必要とし、ガーベジ・コレクションのサポートが貧弱であり、データ保全およびリスタートに際してのファイル・システムのリペアに多くの時間を必要とする。
【００１７】
ページ・キャッシュは、固定サイズのメモリ・バッファのセットを用いてファイル・システムを拡張する。データは、ネットワークを介した送信の前にこれらのバッファの内外に置かれる。このアプローチは、遅い接続を介して大きなオブジェクトを送るとき、大量のメモリを無駄にする。
【００１８】
データベース・システム・アプローチは、データベース・システムをキャッシュとして使用する。一般に、データベースの構築により達成される目標は、オブジェクト・キャッシュとしての使用に適していない。たとえばデータベースは、トランザクション処理を最適化するために構築される。各トランザクションの保全性を確保するために、そこでは大規模なロックが使用される。その結果、設計目標として、速度等のパフォーマンス要因よりデータ保全が優先されることになる。これとは対照的に、オブジェクト・キャッシュにとっては、データのオリジナルのソースであるサーバからデータを随時取り出すことができるため、キャッシュがオブジェクトを改ざんしない限り、まれに発生するデータの喪失は許容される。データベースは、書き込み速度がトランザクションの処理速度を制限することから、高速書き込みパフォーマンス用に最適化されることが少なくない。しかしながら、オブジェクト・キャッシュにおいては、読み出し速度も同程度に重要である。さらに、データベースは、仮想メモリ内におけるストリーミング、パイプラインＩ／Ｏをサポートしつつ、広い範囲にわたって各種のサイズを有するオブジェクトをストアすることを本質的に不得手としている。一般に固定レコード・サイズに最適化されたデータベースは、一定の大きさのレコードを作る。データベースが各種のレコード・サイズをサポートしている場合、冗長なオブジェクト関係のサポートが含まれ、通常は遅い、仮想メモリ・ページング技法を使用してストリーミング、パイプラインＩ／Ｏをサポートする。
【００１９】
サイクロン・ファイル・システムにおいては、データが環状ストレージ構造に割り当てられる。スペースがいっぱいになると、単純にもっとも古いデータが削除される。このアプローチは迅速なオブジェクトの割り当てを考慮しているが、大きなオブジェクトを最初にメモリ内に置くことなくこれらをサポートすることが困難であり、データのフラグメンテーションを伴う問題を招き、通常は、もっとも古いオブジェクトをその「人気」と無関係に削除するという単純素朴なガーベジ・コレクションを伴う。多様なワーキング・セットを伴う中程度のアクティブ・キャッシュの場合、この種のファースト‐イン‐ファースト‐アウトのガーベジ・コレクションは、オブジェクトが再利用される前にそれを破棄してしまう可能性がある。
【００２０】
キャッシュ・オブジェクト・ストアの設計における上記のアプローチに付随する基本的な問題は、問題の制約に関して解決策が最適化されないことである。これらのアプローチは、すべて、新しい応用に向けた、現存するテクノロジの再応用に過ぎない。上記の応用の中に、マルチメディア、ストリーミング、オブジェクト・キャッシュに固有の制約に対して理想的に適合しているものはない。上記の解決策は、不完全な再応用に起因して本質的にオブジェクト・キャッシュを妨げるだけでなく、マルチメディア・オブジェクト・キャッシュにおける、より固有の要件の効率的なサポートを不可能にする。これらの固有の要件には、同一であるが異なる名前を有する冗長なコンテンツを明確化し、かつ共有する能力、またそれとは逆の、特定のクライアント、言語、データ型等に向けられた、同一の名前を有するコンテンツの複数の変化型(variants)をストアする能力が含まれる。
EP-A-0811939から、分散型ネットワークにおいて、ドキュメントをプロキシし、転送変換(transcoding)することが知られており、ここでは、クライアントの要求に応じて、遠隔サーバから取得されたウェブ・ドキュメントは、この要求ドキュメントに関連した格納情報を用いて転送変換される。ドキュメントは、種々の目的、すなわちドキュメント内で見つかるバグや不適当な記述(quirks)を回避する、テレビの画面にドキュメントを合わせる、転送効率を改善する、待ち時間を削減する等のために転送変換される。
【００２１】
以上に基づくと、これらの従来アプローチの欠点を克服し、かつマルチメディア・オブジェクト・キャッシュの固有の要件により理想的に適合するオブジェクト・キャッシュを提供する必要があることは明らかである。
特に：
１． 多様なサイズを有する数億のオブジェクト、およびテラバイトのコンテンツ・サイズを効率的な態様でメモリ内にストアし得るオブジェクト・キャッシュが必要とされている。
２． 時間を要するファイル・ディレクトリ・ルックアップを必要とせずに、迅速にドキュメントが「ヒット」であるか「ミス」であるかを決定できるオブジェクト・キャッシュが求められている。
３． オブジェクトの読み出しおよび書き込みのためのディスク・シーク数を最小化するキャッシュが必要とされている。
４． キャッシュからの、およびキャッシュへのデータの効率的なストリーミングを可能にするオブジェクト・ストアが必要とされている。
５． 同一の名前で指定された複数の異なるバージョンの選択肢をサポートするオブジェクト・ストアが必要とされている。
６． コンテンツの重複を招くことなく大量のオブジェクトを効率的にストアするオブジェクト・ストアが必要とされている。
７． 影響を考慮して置換するドキュメントを選択しつつリアルタイムで迅速かつ効率的なガーベジ・コレクションを行い、ユーザの応答速度を向上し、トラフィックを軽くすることができるオブジェクト・ストアが必要とされている。
８． ソフトウエアもしくはハードウエアの障害後にリスタートしたとき、データの改ざんを招くことなく、かつデータの喪失を最小限にして数秒内に完全な動作能力に復帰できるオブジェクト・ストアが必要とされている。
【００２２】
本明細書は、前述の目的の達成に向けられたテクノロジに関連する。特に本明細書では、大きなオブジェクト・ストアにおいて時間効率が高くかつ空間効率の高い、オブジェクトの格納、取り出しおよびメンテナンスに関連する方法および装置について説明されている。ここで説明するテクノロジは、高性能、高負荷の応用のためのキャッシュ・オブジェクト・ストアを提供し、これは次に示す一般的な特性を有している。
１．高性能：オブジェクトのストア操作に関して待ち時間が小さく、高いスループットが得られ、かつ多数の同時操作が得られる。
２．大型キャッシュのサポート：テラバイト台のキャッシュおよび数十億のオブジェクトをサポートし、インターネットの指数関数的なコンテンツの増加レートを扱うことができる。
３．メモリのストレージ空間の効率化：高価な半導体メモリを節約し、効果的に使用する。
４．ディスクのストレージ空間の効率化：オブジェクト・ストアの有限なディスク容量内に大量のインターネット・オブジェクトのレプリカをストアすることができる。
５．エイリアスの自由度：名前は異なるが、コンテンツが等しい同一オブジェクト・コンテンツを有する複数のオブジェクトまたはオブジェクトの変化型は、オブジェクト・コンテンツが１回だけキャッシュされ、異なる名前の間で共有される。
６．マルチメディアの多様性をサポート：数百バイトからメガバイトに至る６桁にわたるサイズ範囲で多数のタイプの多様なマルチメディア・オブジェクトを効率的にサポートする。
７．高速かつ用法を意識したガーベジ・コレクション：有用性の低いオブジェクトをオブジェクト・ストアから効率的に削除し、新しいオブジェクトのためのスペースを確保する。
８．データの一貫性：プログラム上のエラーおよびハードウエアの障害によりデータの信頼性を失うことがない。
９．高速リスタートが可能：時間を要するデータベースまたはファイル・システムのチェック・オペレーションを必要とすることなく、リスタート後数秒内にオブジェクト・キャッシュが要求に対するサービスを開始することができる。
１０．ストリーミング：大きなオブジェクト全体をメモリ内に置くことなく、オブジェクト・ストアから遅いクライアントに、効率的にパイプラインさせることができる。
１１．コンテンツ・ネゴシエーションのサポート：プロキシ・キャッシュは、クライアントのブラウザ、言語、またはその他のクライアントの要求の属性に向けられた、同一ＵＲＬのオブジェクトの変化型を効率的かつ柔軟にストアすることができる。
１２．汎用適用可能性：オブジェクト・ストアのインターフェースは、充分に柔軟であり、将来的なメディア・タイプおよびプロトコルに適合することができる。
【００２３】
【発明の要約】
以上のニーズおよびそこに示さなかった他のニーズは、本発明によって解決され、それにおいては、１側面として、情報オブジェクトの名前に基づくキー値によって識別される情報オブジェクト用のキャッシュ内に、当該キー値に基づくセット・サブキー値を用いて情報オブジェクトをインデクス付けするタグ・テーブル、前述のキー値に基づく第２のサブキー値によって当該タグ・テーブル内のセットにインデクス付けされた複数のブロックを有するディレクトリ・テーブル、および、当該ディレクトリ・テーブル内のブロックによって参照されるデータ・ストレージ・エリアを備え、要求のあった情報オブジェクトをサーバのキャッシュからクライアントに配信する方法において：要求された情報オブジェクトを識別する名前を受け取るステップ；前記名前に基づき、複数のサブキーからなる固定サイズのキー値を演算するステップ；ディレクトリ・テーブル内において、前記サブキーをルックアップ・キーとして使用し、前記要求された情報オブジェクトをルックアップするステップ；および、前記ディレクトリ・テーブルの一致ブロック内に包含されている参照を使用して前記要求された情報オブジェクトのコピーをデータ・ストレージ・エリアから取り出すステップ；を包含することを特徴とする。
【００２４】
本発明のこの側面の特徴は、前記キャッシュ内の、前記要求された情報オブジェクトの複数のバージョンのリストから、要求された情報オブジェクトのバージョンを選択するステップ；前記キャッシュ内の、前記要求された情報オブジェクトの格納場所を、最初のバージョンに関連して前記リスト内にストアされたオブジェクト・キーに基づいて識別するステップ；前記格納場所から前記要求された情報オブジェクトを取り出すステップ；および、取り出した情報オブジェクトをクライアントに配信するステップ；を含む。
【００２５】
別の特徴は、情報オブジェクトを連続させて大容量ストレージ・デバイスにストアするステップを含む。さらに別の特徴は、それぞれの情報オブジェクトを大容量ストレージ・デバイスの連続するプールにストアするステップを含む。さらにまた別の特徴は、それぞれの情報オブジェクトを、前記プール内のアリーナの１つにストアするステップを含む。さらに別の特徴は、それぞれの情報オブジェクトを、前記アリーナから割り当てられた１ないしは複数のフラグメントにストアするステップを含む。
【００２６】
本発明の別の特徴によれば、情報オブジェクトを含むフラグメントは、それより前のフラグメント・キーからリンクされる。別の特徴は、要求された情報オブジェクトの、複数のバージョンのそれぞれとともにリストを連続させてストアするステップ；ブロックのそれぞれに、当該ブロックに関連して要求された情報オブジェクトのサイズ値であって、リストのストレージ・サイズを示すサイズ値および情報オブジェクトの複数のバージョンをストアするステップ；を含み、それにおいてステップ（Ｄ）は、リストおよび複数のバージョンを同時に読み出すステップを含む。さらに別の特徴は、異なる速度のストリーミング・データ転送を書き込み集成バッファ内に統合する。
【００２７】
本発明のさらに別の特徴によれば、前記情報オブジェクトをストアするステップは、別の情報オブジェクトに関してステップ（Ａ）〜（Ｄ）を実行しつつ同時に、情報オブジェクトを、前記大容量ストレージ・デバイスの連続した使用可能なストレージ空間内に書き込むステップを含む。
【００２８】
また本発明は、前述の側面ならびにその他の側面に従って構成された装置、コンピュータ・システム、コンピュータ・プログラム・プロダクト、および搬送波に埋め込まれたコンピュータ・データ信号を包含している。
【００２９】
【好ましい実施例の詳細な説明】
次に、情報オブジェクトをキャッシュするための方法および装置について説明する。以下の説明においては、本発明の完全な理解を提供するため、説明を目的として、各種の具体的な詳細が説明されている。しかしながら、当業者においては明らかになろうが、これらの特定の詳細を用いなくとも本発明を実施することは可能である。一方、周知の構造およびデバイスについては、ブロック図形式により示し、本発明が不必要に不明瞭になることを防止している。
【００３０】
（トラフィック・サーバ）
図２に、プロキシ３０の特定エレメントの一般的な構造をブロック図の形で示す。一実施例においてプロキシ３０は、トラフィック・サーバと呼ばれ、詳細を後述するタイプのコンピュータ・ワークステーション上で動作する１ないしは複数のコンピュータ・プログラムまたはプロセスを含む。クライアント１０ａは、インターネット２０を介してオブジェクトを求める要求５０をプロキシ３０に送る。この関係において用語「オブジェクト」は、ネットワーク・リソースもしくはサーバから配信される情報の任意の離散的エレメントを意味する。オブジェクトの例としては、ウェブ・ページまたはドキュメント、グラフィック・イメージ、ファイル、テキスト・ドキュメント、およびウェブ・アプリケーション・プログラムによってプログラム実行間に作成されたオブジェクト、あるいはインターネット２０を介してアクセス可能なサーバ上にストアされたその他の要素が挙げられる。これとは別に、インターネット以外のネットワークを介してクライアント１０ａがプロキシ３０に接続されることもある。
【００３１】
到来した要求５０は、プロキシ３０の入力／出力（Ｉ／Ｏ）コア６０に到達する。Ｉ／Ｏコア６０は、プロキシにより受け取られるデータまたは配信されるデータのレートを調整し、クライアント１０ａとインターネット２０の間におけるリンクのデータ転送速度に整合させる。好ましい実施例においては、Ｉ／Ｏコア６０が、プロキシ３０およびインターネット２０に接続される、入力バッファと出力バッファの間に配置された、循環式に配列されるバケットのセットとして実装される。プロキシ３０と１ないしは複数のクライアント１０ａの間の接続は、これらのバケット内にストアされる。セット内の各バケットは、連続して調べられ、バケット内の各接続がポーリングされる。ポーリングの間、最後のポーリング以降に当該接続に関連付けされているバッファ内に蓄積された情報の量が判断される。この量に基づいて、その接続に関連付けされた周期の値が調整される。その後、概して現在のバケット数の合計および周期値によって識別される別のバケット内に接続がストアされる。ポーリングは、次の接続および次のバケットに続く。このようにして、連続する接続のポーリングの経過時間によって、実際の動作帯域幅、つまりその接続のデータ通信速度に自動的に調整される。
【００３２】
Ｉ／Ｏコア６０は、この要求５０を、Ｉ／Ｏコア６０およびキャッシュ８０に接続されたプロトコル・エンジン７０に渡す。プロトコル・エンジン７０は、要求５０を構文解釈し、要求５０内に埋め込まれている明文化されたアクションのタイプを決定する。プロトコル・エンジン７０は、要求５０内の情報に基づいて特定のオペレーションを実行するコマンドをキャッシュ８０に提供する。一実施例においては、キャッシュ８０が、アプリケーション・プログラミング・インターフェース（ＡＰＩ）を使用し、プロトコル・エンジン７０にアクセス可能な１ないしは複数のコンピュータ・プログラム内に実装される。この実施例の場合は、プロトコル・エンジンが要求５０をデコードし、キャッシュ８０のＡＰＩに対してファンクション呼び出しを行う。このファンクション呼び出しには、パラメータ値、要求５０から導き出した情報が含まれる。
【００３３】
キャッシュ８０は、プロトコル・エンジン７０に接続されてそれとの間において情報の送受を行い、また不揮発性大容量ストレージ・デバイス９０ａ〜９０ｎに接続されてそれと双方向通信する。一実施例においては、大容量ストレージ・デバイス９０ａ〜９０ｎが大容量高速ディスク・ドライブである。キャッシュ８０は、データ・テーブル８２とも双方向通信するが、それについての詳細は後述する。
【００３４】
（オブジェクト・キャッシュのインデクス化）
（コンテンツのインデクス化）
好ましい実施例においては、キャッシュ８０がオブジェクトをストレージ・デバイス９０ａ〜９０ｎにストアする。「人気のある」オブジェクトについては、キャッシュ内にもレプリカが作られる。この好ましい実施例の場合、キャッシュのサイズは有限であり、主としてプロキシ３０のメモリまたはＲＡＭにストアされる。
【００３５】
ディスク上のオブジェクトは、キーと呼ばれる固定サイズのロケータによってインデクス付けされる。キーは、ディレクトリ内にインデクス付けするために使用され、ディスク上のオブジェクトの位置および当該オブジェクトに関するメタデータをポイントする。キーには、それぞれ「名前キー」および「オブジェクト・キー」と呼ばれる２つのタイプがある。名前キーは、名前付きオブジェクトに関するメタデータをインデクス付けするために使用され、オブジェクト・キーは、真のオブジェクトのコンテンツをインデクス付けするために使用される。名前キーは、ＵＲＬならびにその他の情報リソースの名前を、そのオブジェクト・データ用のオブジェクト・キーを含むメタデータ構造に変換するために使用される。次に説明するように、この２レベルのインデクス構造は、複数の代替オブジェクトを単一の名前に関連付けする機能を容易にする一方、同時に、あらゆるオブジェクトのコンテンツのコピーを重複させることなくディスク上で維持し、複数の異なる名前または選択肢の間でそれを共有する。
【００３６】
名前またはＵＲＬをキーとして使用し、それによりオブジェクトを参照するほかのキャッシュ・システムとは異なり、本発明の実施例は、オブジェクト自体を構成する「指紋」を使用してオブジェクトを見出す。インデクス済みのオブジェクトのコンテンツから生成されたキーを、ここではオブジェクト・キーと呼んでいる。厳密に述べれば、オブジェクト・キー５６は、固有の指紋、つまりオブジェクト５２のコンテンツの圧縮された表現である。好ましくは、オブジェクト５２のコピーを入力としてハッシュ関数５４に与え、その出力をオブジェクト・キー５６とする。たとえば、オブジェクト５２のファイルもしくはその他の表現をハッシュ関数の入力として与えると、それが当該ファイルの各バイトを読み込み、ファイル全体の読み込みを完了するまで、オブジェクト・キー５６の一部の生成を繰り返す。このようにしてオブジェクト・キー５６は、その名前ではなく、オブジェクト５２のコンテンツ全体に基づいて生成される。キーがコンテンツ・ベースであり、キャッシュ８０のテーブルに対するインデクスとして機能することから、このキャッシュは、コンテンツ・インデクス付きキャッシュと呼ばれる。コンテンツの指紋キーが与えられれば、コンテンツを容易に見つけることができる。
【００３７】
この実施例においては、コンテンツのインデクス化が、キャッシュ８０による、名前は異なるが同一のコンテンツを有する複製オブジェクトの検出を可能にする。まったく同じコンテンツを有するオブジェクトが、異なる名前を有している場合であっても、ハッシュによりそれらが同一のキー値をもたらすことから、この種の複製が検出される。
【００３８】
たとえばサーバ４０が、あるサブディレクトリ内に、「IE4.exe」という名前を付けたサイズが１０メガバイトの実行可能ファイルからなるソフトウエア・プログラムをストアしている場合を考える。それにおいて、さらにサーバ４０が、同一ファイルのコピーに「Internet Explorer.exe」という名前を付けて別のサブディレクトリ内にストアしているとする。サーバ４０は、匿名ＦＴＰサーバであり、ＦＴＰプロトコルを使用し、ＨＴＴＰ接続を介してファイルのコピーを配信することができる。過去のアプローチにおいては、１ないしは複数のクライアントがこれら２つのファイルを要求すると、キャッシュがそれぞれのファイルのコピーをキャッシュ・ストレージにストアし、キャッシュ内の各ファイルをそれぞれの名前を使用してインデクス付けするということが行われている。この結果、キャッシュは、名前を除けばすべてが等しい２つのオブジェクトのために、２０メガバイトを使用しなければならない。
【００３９】
本発明の実施例においては、さらに詳細に述べるが、これらのオブジェクトのそれぞれについて、キャッシュが名前キーおよびオブジェクト・キーを作成する。名前キーは、オブジェクトの名前にハッシュ関数を適用することによって作成される。オブジェクト・キーは、オブジェクトのコンテンツにハッシュ関数を適用することによって作成される。この結果、上記の例に示した２つのオブジェクトの場合であれば、作成された２つの名前キーは異なるが、オブジェクト・キーは同一になる。最初のオブジェクトをキャッシュ内にストアするとき、その名前キーおよびオブジェクト・キーをキャッシュ内にストアする。その後２番目のオブジェクトをキャッシュ内にストアするとき、その名前キーをキャッシュ内にストアする。しかしながらキャッシュは、以前のまったく等しいオブジェクト・キーのエントリを検出し、重複するオブジェクト・キーのエントリをストアしない；それに代えてキャッシュは、同一のオブジェクト・キーのエントリに対する参照を、名前キーに関連させてストアし、新しい冗長なオブジェクトを削除する。結果的に、オブジェクトのストアに必要となるストレージは１０メガバイトだけになる。このようにキャッシュは、異なる名前を有するオブジェクトの複製を検出し、その種のオブジェクトに対して永続させるコピーを１つだけストアする。
【００４０】
図３Ａは、オブジェクト５２用のオブジェクト・キー５６を生成するために使用されるメカニズムのブロック図を示している。クライアント１０ａからオブジェクト５２の要求があったが、ここに述べるプロセスを使用してキャッシュ８０内にそのオブジェクトが見つからないとき、キャッシュはサーバからそのオブジェクトを取り出し、キャッシュ内にそのオブジェクトをストアするためのオブジェクト・キー５６を生成する。
【００４１】
ディレクトリは、ディスク上の位置にキーをマップするデータ構造である。高速ルックアップに備えるためには、ディレクトリのコンテンツのすべて、もしくはそのほとんどをメモリ内に維持しておくことが望ましい。これには、大量のエントリが適当な量のメモリに収まるようにディレクトリのエントリを小さくする必要がある。また、アクセスの５０％がキャッシュにストアされないと予測されることから、貴重なディスク・シーク時間を費やすことなくキャッシュのミスを迅速に判断したい。この種の迅速なキャッシュミスの最適化は、実際のデータ転送に少ないディスク・ヘッドの動きをもたらし、成功を導かない不確かなルックアップを抑える。最後に、ハッシュ・サーチ技法を介してルックアップを高速にするため、ディレクトリのエントリを固定サイズにする。
【００４２】
キーは、前述の理由から小さく、固定されたサイズとなるように慎重に構成される。さらにキーは、ストレージ効率および迅速なルックアップを目的としてサブキーに分割される。キーの小さな一部において相違を検出することにより、迅速にキャッシュミスを識別することができる。この理由から、完全なキーを収めた完全なディレクトリ・テーブルをサーチする代わりに、「タグ・テーブル」と呼ばれる小さなサブキーのテーブルを使用して迅速にキャッシュミスのフィルタリングを行う。さらに、大きなビット・ベクトルの統計プロパティを利用して空間効率の高いキーを作成することが可能であり、それにより小さい必要空間を用いて大量のキャッシュ・オブジェクトをサポートすることができる。
【００４３】
一実施例によれば、オブジェクト・キー５６はセット・サブキー５８およびタグ・サブキー５９からなる。セット・サブキー５８およびタグ・サブキー５９は、完全なオブジェクト・キー５６を構成するビットのサブセットを構成する。たとえば、完全なオブジェクト・キー５６が１２８ビットの長さを有するとき、サブキー５８、５９をそれぞれ１６ビット、２７ビットとし、あるいは完全なキーの別の任意部分とすることができる。サブキー５８、５９は、後述する特定の操作に使用され、それにおいてこれらのサブキーは、完全なキーを使用した場合に近い正確な結果をもたらす。ただしこれにおいて「正確な」とは、サブキーの使用が、完全なキーの使用時と同程度の頻度でキャッシュ内におけるヒットを導くことを意味している。
【００４４】
この精度プロパティは、「滑らかさ(smoothness)」として知られ、ハッシュ関数の特定の好ましいサブセットにおける特性となる。実施例における使用に適したハッシュ関数の例としてＭＤ５があり、これについてはB. Schneier（Ｂ．シュナイザー）著「Applied Cryptography（応用暗号学）」（ニューヨーク：John Wiley & Sons, Inc.（ジョン・ウィリー・アンド・サンズ・インク）第２版，１９９６年）の４２９〜４３１ページおよび４３６〜４４１ページに解説されている。ＭＤ５ハッシュ関数は、任意長を有する入力データ・ストリームから１２８ビットのキーを生成する。概してＭＤ５ハッシュ関数およびそのほかの一方向ハッシュ関数は、暗号分野において、安全なチャンネルを介して送信する必要のあるメッセージまたはドキュメントのための安全キーを生成するために使用される。一般的なハッシュ・テーブルの構成およびサーチ技法については、D. Knuth（Ｄ．クナス）著「The Art of Computer Programming（コンピュータ・プログラミングの技法）第３巻，Sorting and Searching（ソーティングおよびサーチ）」（マサチューセッツ州レディング：Addison-Wesley（アディソン‐ウェズレー）１９７３年）の５０６〜５４９ページに詳しい解説がある。
【００４５】
（名前のインデクス化）
残念ながら、一般にはオブジェクトの要求において、要求オブジェクトの識別に、そのオブジェクト用のオブジェクト・キーが使用されることがない。むしろ要求は、通常、名前によって要求オブジェクトを識別する。名前のフォーマットは、キャッシュが使用される環境に応じて実装ごとに異なることがある。たとえば、オブジェクト名にファイル・システムの名前、ネットワーク・アドレス、あるいはＵＲＬが使用されることもある。
【００４６】
本発明の一側面によれば、要求オブジェクト用のオブジェクト・キーが、オブジェクト名に基づいて生成された「名前キー」の下にインデクス付けされる。つまり、要求に応答したオブジェクトの取り出しは、２段階プロセスとなり、それにおいては名前キーがオブジェクト・キーの発見に使用され、オブジェクト・キーがオブジェクトそのものの発見に使用される。
【００４７】
図３Ｂは、オブジェクト名５３に基づいて名前キー６２を生成するとき使用されるメカニズムを示したブロック図である。一実施例によれば、オブジェクト・キーに使用したものと同じハッシュ関数５４が名前キーの生成に使用される。したがって、名前キーは、オブジェクト・キーと同じ長さおよび滑らかさ特性を有することになる。
【００４８】
オブジェクト・キー５６と同様に、名前キー６２もセット・サブキー６４およびタグ・サブキー６６からなる。サブキー６４、６６は、完全な名前キー６２を構成するビットのサブセットを構成する。たとえば、完全な名前キー６２が１２８ビットの長さを有するとき、第１および第２のサブキー６４、６６をそれぞれ１６ビット、２７ビットとし、あるいは完全なキーの別の任意部分とすることができる。
【００４９】
（オブジェクト・キーまたは名前キーによるサーチ）
好ましくはキャッシュ８０が、コンピュータ・システムのメモリまたはその不揮発性ストレージ、たとえばディスク等にストアされる特定のデータ構造からなるものとする。図４は、キャッシュ８０の概略の構成を示すブロック図である。キャッシュ８０は、概してタグ・テーブル１０２、ディレクトリ・テーブル１１０、オープン・ディレクトリ・テーブル１３０、および一連のプール２００ａ〜２００ｎを含み、次に詳細を述べるように論理参照を使用して互いに連結されている。
【００５０】
タグ・テーブル１０２およびディレクトリ・テーブル１１０は、セット連想ハッシュ・テーブル(set associative hash tables)として組織化されている。タグ・テーブル１０２、ディレクトリ・テーブル１１０、およびオープン・ディレクトリ・テーブル１３０は、図２に示したテーブル８２に対応している。ここでは説明の便宜から、インデクス・サーチがオブジェクト・キー５６に基づいて実行されるものとする。しかしながらタグ・テーブル１０２およびディレクトリ・テーブル１１０は、名前キー６２に基づいて検索を行った場合にも同じ態様において動作する。
【００５１】
タグ・テーブル１０２は、セット１０４ａ、１０４ｂ、．．．１０４ｎのセット連想配列である。タグ・テーブルは、メイン・メモリに収まる程度に充分小ささく設計されている。この目的は迅速にキャッシュミスを検出することであり、キーを構成するビットの小さなサブセットのみを用いて、キーがキャッシュ内にストアされていないことを判断できるようにする。なお、１０４ｎという表示は、タグ・テーブル１０２内に必要なセット数が特定されていないことを示している。セット１０４ｎの例に示されているように、各セット１０４ａ〜１０４ｎは、複数のブロック１０６からなる。
【００５２】
好ましい実施例においては、オブジェクト・キー５６が１２８ビットの長さを有する。セット・サブキー５８は、セット１０４ａ〜１０４ｎの１つを識別して選択するために使用される。好ましくは、セット・サブキー５８の長さを概略で１８ビットとする。タグ・サブキー５９は、選択したセット内のエントリ１０６の１つを参照するために使用される。好ましくは、タグ・サブキー５９の長さを概略で１６ビットとするが、多くのセットが存在する場合には、ゼロ・ビットまで小さくすることができる。その場合、タグ・テーブルがビット・ベクトルになる。
【００５３】
エレメントの識別もしくは参照に使用されるメカニズムは、実装ごとに異なることがあり、連想参照、ポインタ、またはこれらの組み合わせを含んでいることもある。このため「参照」という用語は、あるエレメントが別のエレメントを識別もしくは参照することを示す。残余サブキー５６'は、キー５６の残りのビットからなる。これらのセット・サブキー、タグ・サブキー、および残余サブキーを、それぞれｓ、ｔ、およびｒを用いて表すこともある。
【００５４】
各エントリが比較的小さい情報量を含むタグ・テーブル１０２の好ましい構造においては、ＲＡＭ等の揮発性メイン・メモリにタグ・テーブルを高速にストアすることが可能になる。したがってこのタグ・テーブル１０２の構造は、キャッシュの迅速な動作を促進する。一方、ディレクトリ・テーブル１１０内のブロックは、以下述べるようにはるかに多くの情報を含んでおり、結局ディレクトリ・テーブルの一部は、高速なＤＲＡＭメモリとは対照的となる磁気ディスク・媒体上に常駐することになる。
【００５５】
ディレクトリ・テーブル１１０は、複数のセット１１０ａ〜１１０ｎを包含している。各セット１１０ａ〜１１０ｎは固定されたサイズを有し、それぞれは複数のブロック１１２ａ〜１１２ｎからなる。好ましい実施例においては、あらかじめ決定済みの一定数のセットが存在し、各セット内にはあらかじめ決定済みの一定数のブロックが存在する。ブロック１１２ｎの例に示されるように、ブロック１１２ａ〜１１２ｎのそれぞれは、第３の、残余サブキー値１１６、ディスク・ロケーション値１１８、およびサイズ値１２０をストアしている。この好ましい実施例においては、残余サブキー値１１６が、１２８ビットの完全なオブジェクト・キー５６の２７ビット部分であり、セット・サブキー５８またはタグ・サブキー５９を構成するビットと互いに素となって、完全なオブジェクト・キー５６のビットを構成する。
【００５６】
サーチにおいては、図４においてエントリ１０６をセット１１０ｄに接続する矢印により示されるように、タグ・テーブル１０２のエントリ内にストアされているサブキー値がセット１１０ａ〜１１０ｎの１つに一致するか、それを参照する。一例として、前述したような１２ビットのキーおよび４ビットの第１および第２のサブキーを考える。ここで、セット・サブキー値「１１１１」がタグ・テーブル１０２のセット１０４ｎに一致し、タグ・サブキー値「００００」がセット１０４ｎのエントリ１０６に一致したとする。タグ・サブキー値「００００」の一致は、キー・プレフィクス「１１１１００００」に関連付けされたディレクトリ・テーブル１１０のセット１１０ｄ内に、対応するエントリが存在することを示す。このようにしてセット１１０ａ〜１１０ｎの１つを選択すると、選択したセット内のブロックの線形サーチを行って、ブロック１１２ａ等の、オブジェクト・キー５６の対応する部分に一致する残余サブキー値１１６を含むブロックを見つけ出す。一致が見つかると、ほとんど必ずキャッシュ内にヒットが存在すると言える。ただし第１、第２および第３のサブキーが完全なキーを構成しないときは、わずかではあるがミスの可能性がある。ヒットがあると、ブロックに含まれている情報に基づいて参照オブジェクトを見つけ出し、ストレージ・デバイス９０ａ〜９０ｎの１つからそれを取り出し、クライアント１０ａに提供するが、それについては後述する。
【００５７】
ＲＡＭメモリの使用を最小に抑えて迅速にミスを除外することを役割とするタグ・テーブルと異なり、ディレクトリ・テーブル１１０内の各ブロックは、ディスク・ロケーションに対する完全なポインタを包含している。ディスク・ロケーション値１１８によって参照されるアイテムは、キーが生成されたソースによって異なる。前述のようにオブジェクトのコンテンツに基づいて生成されたキーの場合には、ディスク・ロケーション値１１８が、図４においてブロック１１２ｂのキャッシュ内のストア済みオブジェクト１２４として示されてように、その（もしくはその最初のフラグメントの）位置を表す。キーが名前キーの場合には、ブロック１１２ｎとして示されるように、ディスク・ロケーション値１１８は、１ないしは複数の選択肢のベクトル１２２の位置を示し、そのそれぞれは、名前キーの生成に使用した名前を持ったオブジェクトに対応する１ないしは複数のオブジェクト・キーをストアしている。図４には、例として単一のタグ・テーブル１０２および単一のディレクトリ・テーブル１１０を示した。しかしながら、追加のストレージならびにインデクスのレベルを提供する追加のテーブルを使用する別の実施例も考えられる。
【００５８】
好ましい構成においては、キャッシュのサーチを行うとき、タグ・テーブル１０２内で非常に迅速にヒットもしくはミスが得られる。タグ・テーブル１０２内にヒットが存在するときは、非常に高い確率で対応するエントリがディレクトリ・テーブル１１０内に存在する。この高い確率は、タグ・テーブル１０２内のヒットが、キャッシュがオブジェクト、つまりその完全なキーが、受け取ったキーとまったく等しいＸビットを共有しているオブジェクトを保持していることを意味するという事実からもたらされ、それにおいてＸは、セット・サブキー５８とタグ・サブキー５９を連結したビット数である。ミスが迅速に識別され得ることから、またディレクトリ・テーブル１１０全体をメイン・メモリ内に常駐させることを必要とせずにヒットおよびミスがメモリ内のタグ・テーブル１０２を使用して迅速に検出されることから、キャッシュ８０が高速かつ効率的に動作する。
【００５９】
キャッシュをオブジェクト・キー５６に基づいてサーチする場合、セット・サブキー５８を使用してタグ・テーブル１０２内のセット１０４ａ〜１０４ｎの１つをインデクス付けする。セット・サブキー５８に関連付けされたセットを識別した後は、セット内のエレメントに対する線形サーチを行って、タグがタグ・サブキー５９に一致するエントリを識別する。
【００６０】
キャッシュ８０からクライアント１０ａによって要求されたオブジェクト５２を求めるサーチにおいては、セット・サブキー５８を用いてセット１０４ａ〜１０４ｎの１つを選択すると、そのセット内の全エレメント１０６に対する線形サーチを実行する。このサーチは、タグ・サブキー５９とエントリの１つとの一致を求める。一致が見つかると、要求オブジェクトに関してタグ・テーブル１０２内にヒットが存在することになり、キャッシュ８０は、先に進んでディレクトリ・テーブル１１０内のヒットを求める。
【００６１】
ここで説明のために、オブジェクト・キーを、値「１１１１００００１０１０」を有する１２ビットのキーとし、セット・サブキーをオブジェクト・キーの最初の４ビット、つまり値「１１１１」からなるものとし、タグ・サブキーをオブジェクト・キーの次の４ビット、つまり値「００００」からなるものとする。実際の使用においては、残余ビットがセット・ビットおよびタグ・ビットよりはるかに大きくなり、メモリの節約に影響を及ぼす。キャッシュは、セット「１５（１１１１）」を、タグ・テーブル１０２を調べるためのセットとして識別する。キャッシュは、そのセット内の、タグ「００００」を含むエントリをサーチする。その種のエントリが存在しなければ、タグ・テーブル１０２内においてミスが発生する。その種のエントリが存在すれば、キャッシュは、ディレクトリ・テーブル１１０内の残りのビットの一致についてチェックする。
【００６２】
（マルチレベル・ディレクトリ・テーブル）
一実施例においては、ディレクトリ・テーブル１１０が、それぞれが固定数のエレメントからなる複数のセットを含んでいる。各エレメントは、残余タグおよびディスク・ポインタを含む。大きなキャッシュは大量のオブジェクトを含み、それによりディレクトリ・テーブル内に多数のエレメントが必要になる。これによってテーブルが非常に大きくなり、メイン・メモリ内においてコスト効果に関して有利なストアが得られなくなる。
【００６３】
たとえば、キャッシュが１億２８００万のディレクトリ・テーブル・エントリからなり、それぞれのエレメントが控えめ値として８バイトのストレージによって表されるとき、ディレクトリ・テーブルのストアに１ギガバイトのメモリが必要になるが、これは現在のワークステーション・コンピュータに一般的なメモリ容量を超えている。これらのオブジェクトのうち、実際に常時アクセスされるものがほとんどないことから、頻繁に使用されるエントリをメイン・メモリ上に残し、使用頻度の低いエントリをディスクに移動することが望ましい。
【００６４】
図４Ｃに、マルチレベル・ディレクトリ・メカニズムのブロック図を示す。ディレクトリ・テーブル１１０は、セグメント１１１ａ、１１１ｂ、１１１ｃに分割されている。好ましい実施例においては、２ないしは３のセグメント１１１ａ〜１１１ｃが存在するが、それより多くのセグメントを使用してもよい。最初のセグメント１１１ａはもっとも小さく、図１１に示した、詳細を後述するコンピュータ・システムのメイン・メモリ１１０６等のメイン・メモリに適合する。第２および第３のセグメント１１１ｂ、１１１ｃは、順次大きくなる。第２および第３のセグメント１１１ｂ、１１１ｃは、ページング・メカニズムを介してディスク等の大容量ストレージ・デバイス１１１０に結合される。第２および第３のセグメント１１１ｂ、１１１ｃは、要求データがメイン・メモリ１１０６内に存在しないとき、ディスクとの間で動的にデータのページングを行う。
【００６５】
より頻繁にディレクトリ・エレメントがアクセスされるときは、ディレクトリ・エレメントが、マルチレベル・ディレクトリのセグメント１１１ａ〜１１１ｃの中を逐次より高いセグメントへと移動する。つまり、頻繁にアクセスされたディレクトリ・エレメントは、メイン・メモリ１１０６内にストアされる可能性がより高くなる。もっとも「人気のある」エレメントは、ディレクトリ内のもっとも高く、もっとも小さいセグメント１１１ａに現れ、常時メイン・メモリ１１０６内に存在することになる。エントリの「人気」は、長さが数ビットの小さいカウンタによって追跡される。このカウンタは、「スケーリング付きカウンタの更新」セクションににおいて説明しているように更新される。このマルチレベル・ディレクトリは、メモリ内ハッシュ・テーブルのパフォーマンスに近く、その一方でアクティブでないエレメントをディスク上に置くことによって、テラバイト・サイズのキャッシュに代わるコスト効果の高い総合ストレージ容量を提供する。
【００６６】
（ディレクトリのページング）
すでに述べたように、好ましい実施例においては、ディレクトリ・テーブル１１０がマルチレベルのハッシュ・テーブルとして実装される。ディレクトリ・テーブルの一部はメイン・メモリの外、つまりディスク上に常駐することもある。ディレクトリ・テーブル用のデータは、要求に応じてディスクに、またディスクからページングされる。このメカニズムの好ましい実施例は、ダイレクト・ディスクＩ／Ｏを使用してディスクへのページングならびにディスクからのページングを行うタイミング、およびページングする情報量を慎重にコントロールしている。
【００６７】
このアプローチの別の実施例においては、ＵＮＩＸタイプのオペレーティング・システムの機能を利用して、ファイルを直接仮想メモリ・セグメントにマップする。このアプローチの場合、キャッシュがＵＮＩＸのmmap()機能を使用してディレクトリ・テーブルを仮想メモリ内にマップする。たとえば、ファイルもしくはディスクの位置に対するポインタをパラメータとして伴うmmap要求がオペレーティング・システムに与えられる。mmap要求は、参照されたファイルもしくはディスクの位置をメモリ位置にマップする要求として機能する。その後オペレーティング・システムは、必要に応じて、参照されたファイルもしくはディスクの位置の部分をディスクからメモリに自動的にロードする。
【００６８】
さらに、メモリ位置が更新され、もしくはアクセスされると、そのオブジェクトのメモリ・バージョンが必要に応じてディスクに書き戻される。このようにして、ネイティブ・オペレーティング・システム・メカニズムを使用し、不揮発性デバイス内においてテーブルのバックアップ・ストレージを管理する。しかしながら、メイン・メモリ内に常時存在するのは、通常、ディレクトリ・テーブル１１０の一部だけとなる。
【００６９】
典型的な実施例においては、ディレクトリ・テーブルおよびオープン・ディレクトリは、「ストライピング」技法を使用してストアされる。テーブルの各セットは、異なる物理的ディスク・ドライブ上にストアされる。たとえば、ディレクトリ・テーブル１１０のセット１１０ａがストレージ・デバイス９０ａにストアされ、セット１１０ｂがストレージ・デバイス１１０ｂにストアされるといった形になる。この構成においては、セットに到達するまでのディスク・ドライブ・ヘッドに必要なシーク・オペレーションの数が抑えられ、その結果、キャッシュの速度ならびに効率が向上する。
【００７０】
ここで、ディスクとメモリの間においてデータのページングを行う場合、ある種の保護が行われ、メモリ内にストアされている情報と不揮発性ストレージ・デバイス内にストアされている対応する情報が矛盾しないことが保証される点に注意されたい。オブジェクト・キャッシュ内に効率のよい一貫性をもたらすために使用される技法ついては、「同期および一貫性の強化」セクションにおいて、ガーベジ・コレクションに関する説明に要約されている。
【００７１】
（選択肢のベクトル）
前述したように、単一のＵＲＬが多数のバージョンを有する１つのオブジェクトをマップすることが可能である。これらのバージョンは、「選択肢(alternates)」と呼ばれる。オブジェクト・キャッシュを使用しないシステムにおいては、バージョンが次のようにして選択される。クライアント１０ａがインターネット２０を介してサーバ４０に対するＨＴＴＰ接続を確立する。クライアントは、サーバからオブジェクトを要求するＨＴＴＰメッセージ内において、それ自体に関する情報を提供する。たとえば、オブジェクトを求めるＨＴＴＰ要求は、クライアントによって使用されているウェブ・ブラウザを識別する情報、当該ブラウザのバージョン、クライアントによって好ましいとされる言語、およびクライアントによって好ましいとされるメディア内容のタイプを識別するヘッダを含んでいる。サーバ４０は、このＨＴＴＰ要求を受け取ると、ヘッダ情報を抽出し、ヘッダ情報の値に基づいてオブジェクト５２の変化型を選択する。選択された選択肢は、応答メッセージ内においてクライアント１０ａに返される。このタイプの変化型選択は、新生のＨＴＴＰ／１．１ハイパーテキスト・トランスファ・プロトコルによって奨励されている。
【００７２】
効率的にＵＲＬに関する選択肢のコピーを維持することは、キャッシュ・オブジェクト・ストアにとって重要である。すべてのＵＲＬ要求に応答してキャッシュから単一のオブジェクトが常に提供されるとすれば、ブラウザは、サーバから直接獲得したものと異なるコンテンツを受け取る可能性がある。この理由から、ディレクトリ・テーブル１１０内のそれぞれの名前キーが選択肢のベクトル１２２ａ〜１２２ｎの１つをマップし、それによってキャッシュ８０が複数の関連バージョンの中からオブジェクトの特定のバージョンを選択できるようにしている。たとえば、オブジェクト５２をウェブ・ページとすれば、サーバ４０は、英語、フランス語および日本語のバージョンのそのオブジェクトをストアすることができる。
【００７３】
選択肢のベクトル１２２ａ〜１２２ｎのそれぞれは、複数の選択肢レコード１２３ａ〜１２３ｎをストアする構造である。選択肢レコード１２３ａ〜１２３ｎのそれぞれは、要求オブジェクト５２の選択肢バージョンを記述する情報をストアしているデータ構造である。たとえば、この情報は、特定のブラウザのバージョン、オブジェクトに用いられている人間の言語等を記述する。選択肢レコードもまた、それぞれ選択肢バージョンを含むオブジェクトを識別する完全なオブジェクト・キーをストアしている。好ましい実施例においては、選択肢レコード１２３ａ〜１２３ｎのそれぞれが要求情報、応答情報、およびオブジェクト・キー５６をストアしている。
【００７４】
「人気のある」単一のオブジェクト名が多くの選択肢をマップしていることがあるため、一実施例においては、キャッシュがオブジェクト名を用いて明示的もしくは暗示的な要求のコンテキストを組み立て、ベクトルのエレメント数を低減している。たとえば、ウェブ・クライアント要求のユーザ‐エージェント・ヘッダ（特定のブラウザ・アプリケーションを示す）をウェブＵＲＬと結合して名前キーを形成すればよい。コンテキスト情報をキー内に直接包含させることによって、ディレクトリ・テーブル内のエントリ数が増加するが、各ベクトル内の選択肢の数は減少する。実際問題として、特定のヘッダおよび情報オブジェクト名を結合させた暗示的なコンテキストは構成可能である。
【００７５】
これらの選択肢のベクトル１２２ａ〜１２２ｎは、ＨＴＴＰ／１．１によってネゴシエーションが行われるコンテンツの適正な処理をサポートする。ＨＴＴＰ／１．１メッセージのヘッダに含まれる要求情報および応答情報は、特定の要求を満たすために使用する選択肢レコード１２３ａ〜１２３ｎのうちの１つを決定する上で使用される。キャッシュ８０がオブジェクトを求める要求を受け取ったとき、その要求には通常、希望のオブジェクトの名前（またはＵＲＬ）に加えてヘッダ情報が含まれている。すでに説明したように、名前は適切な選択肢のベクトルを見つけ出すために使用される。適切な選択肢のベクトルが見つかった後は、ヘッダ情報を使用し、その要求に適切な選択肢レコードを選択する。
【００７６】
より具体的に述べれば、キャッシュ８０内において、ヘッダ情報が受け取られて解析される。キャッシュ８０は、ヘッダ情報内に見つかった値と、選択肢レコード１２３ａ〜１２３ｎの１つの要求情報の一致を求める。たとえば、キャッシュ８０がワールド・ワイド・ウェブとの関連において使用されているとき、オブジェクトを求める要求がＨＴＴＰ要求の形式のキャッシュを含むサーバに対して提供される。
【００７７】
キャッシュ８０は、ＨＴＴＰ要求内の情報を調べ、選択肢レコード１２３ａ〜１２３ｎのいずれを使用するかを決定する。たとえば、要求しているクライアント１０ａがバージョン３．０のNetscape Navigator（ネットスケープ・ナビゲータ）ブラウザ・プログラムを走らせており、ドイツ語のテキストの選択を要求していることを示す要求情報がＨＴＴＰ要求に含まれていることが考えられる。キャッシュ８０は、この情報を使用して選択肢レコード１２３ａ〜１２３ｎをサーチし、要求情報から得たブラウザのバージョンおよびクライアントの場所に適合する応答情報を探す。一致が見つかると、一致した選択肢からオブジェクト・キーを取り出し、そのオブジェクト・キーを使用して対応するオブジェクトをキャッシュから取り出す。
【００７８】
キャッシュは、クライアントの要求の中で指定されている基準との一致によって選択されるオブジェクトを最適化する。クライアントの要求においては、最小受理基準（たとえば、ドキュメントはＪＰＥＧイメージでなければならない、あるいはドキュメントはラテン語でなければならない等）が指定されることもある。また、クライアントの要求が、一致に関する比較用重み付け基準（たとえば、ＧＩＦイメージを受け入れる重み付けを０．５、それより好ましいＪＰＥＧイメージを受け入れる重み付けを０．７５とする）を指定することもある。数字による重み付けは、すべての制限軸にわたって累算され、最適化された最終的な重み付けが作り出される。
【００７９】
オブジェクト・キーは、上記の態様においてオブジェクトを取り出すために使用される。具体的には、オブジェクト・キーのサブキー部分を使用してタグ・テーブル１０２およびディレクトリ・テーブル１１０の別のサーチを開始し、そのサブキー値に関するヒットを求める。タグ・テーブルおよびディレクトリ・テーブルのいずれにもヒットが存在するときは、サブキー値を使用して到達したディレクトリ・テーブル内のブロックは、常にストア済みのオブジェクト（たとえばストア済みのオブジェクト１２４）を参照する。つまりキャッシュ８０は、選択肢のベクトル１２２を使用し、複数のバージョンを有するオブジェクトに関する要求を処理することにより、要求しているクライアント１０ａに対して適切なバージョンを配信することができる。
【００８０】
図４には、一例の選択肢のベクトル１２２が１つ、一例のストア済みオブジェクト１２４が１つだけ示されている。しかしながら実際には、インデクス付けされているオブジェクトの数およびオブジェクトに関連付けされた選択肢バージョンの数に応じて、キャッシュ８０が任意数のベクトルおよびディスク・ブロックを含むことになる。
【００８１】
（先読み）
図４Ｂは、一例の選択肢のベクトル１２２ａ〜１２２ｎに関するストレージ構成を示したブロック図である。システムは、メタデータの後に続けてデータ・オブジェクトを統合しようと試みる。シークは時間を要するが、連続した読み出しが読み出しを高速化することから、データとメタデータを整理統合し、メタデータに続いてデータの先読みを行うことによってパフォーマンスを向上することができる。
【００８２】
ストレージ・デバイス９０ａ〜９０ｎの１つにおいては、選択肢のベクトル１２２ａ〜１２２ｎのそれぞれが、ベクトル内に表された選択肢レコード１２３ａ〜１２３ｎに関連付けされているストア済みオブジェクト１２４ａ〜１２４ｂに隣接する位置にストアされる。たとえば、選択肢のベクトル１２２ａは、選択肢レコード１２３ａ〜１２３ｃをストアしている。選択肢レコード１２３ａは、選択肢レコードに関連付けされたストア済みオブジェクト１２４ａが英語用に準備されていることを示す要求情報および応答情報をストアしている。別の選択肢レコード１２３ｂは、関連するストア済みオブジェクト１２４ｂがMicrosoft Internet Explorer（マイクロソフト・インターネット・エクスプローラ）ブラウザとともに使用すべく意図されていることを示す情報をストアしている。選択肢レコード１２３ａ、１２３ｂによって参照されるストア済みオブジェクト１２４ａ、１２４ｂは、選択肢のベクトル１２２ａ〜１２２ｎと隣接してストアされる。
【００８３】
各選択肢レコード内のサイズ値１２０は、関連する選択肢のベクトル１２２ａ〜１２２ｎの１つとストア済みオブジェクト１２４の合計サイズをバイト数で表す。キャッシュ８０がディスク・ロケーション値１１８に基づいて選択肢のベクトル１２２ａを参照するとき、キャッシュはサイズ値によって示されるバイト数を読み出す。たとえば、図４Ｂに示した選択肢のベクトルのキャッシュにおいて、サイズ値は、選択肢のベクトル１２２ａの長さに、関連するストア済みオブジェクト１２４ａの長さを加えた長さを表す。つまりキャッシュ８０は、サイズ値を参照することによって、ベクトルだけでなくストア済みオブジェクトを読み出す。この方法によりキャッシュ８０は、選択肢のベクトル１２２の「先読み」を行い、ストレージ・デバイス９０ａ〜９０ｎからオブジェクト５２をすべて取り出す。この結果、ストレージ・デバイスによる単一のシーク・オペレーションを使用して、ストレージ・デバイスから選択肢のベクトルおよびオブジェクト５２がともに読み出される。したがって、キャッシュ８０内にヒットが存在するとき、大抵の場合（単一の選択肢が存在する場合）は、要求されたオブジェクト５２が単一のシークを使用してストレージ・デバイスから取り出される。
【００８４】
ディスク・ロケーション値１１８が、選択肢のベクトル１２２ではなく直接ストア済みオブジェクト１２４を参照しているときは、サイズ値１２０がディスク・ブロック内にストアされたオブジェクトのサイズを示す。この値は、ここで詳細を述べているように、単一シークによるオブジェクトの取り出しを容易にするために使用される。
【００８５】
（オープン・ディレクトリ）
一実施例においては、キャッシュ８０がさらにオープン・ディレクトリ１３０を備えている。このオープン・ディレクトリ１３０は、それぞれが複数のリスト・エントリ１３１ａ〜１３１ｎからなる複数のリンクされたリスト１３２ａ〜１３２ｎをストアしている。リンクされたリスト１３２ａ〜１３２ｎのそれぞれは、ディレクトリ・テーブル１１０内のセット１１０ａ〜１１０ｎのいずれか１つに関連付けされている。オープン・ディレクトリ１３０は、揮発性のメイン・メモリにストアされる。好ましくは、オープン・ディレクトリ１３０のそれぞれのリスト・エントリ１３１ａ〜１３１ｎが、情報オブジェクトの連想ルックアップを容易にするオブジェクト・キーをストアする。たとえば、リンクされたリスト１３２ａ〜１３２ｎのそれぞれの中の各アイテムが、オブジェクト５２に関する完全なオブジェクト・キー５６をストアする。
【００８６】
オープン・ディレクトリは、現在トランザクションを受けているオブジェクトを捕まえて、衝突をもたらすオペレーションに抗する相互除外を提供する。たとえば、現在読み出しが行われているオブジェクトに対する上書きまたは削除に対する保護にオープン・ディレクトリが有用となる。またオープン・ディレクトリは、ディレクトリ・テーブル１１０に対する変更がディレクトリ・テーブル１１０内において固定される前に、それをバッファする。後述するように、適切なポイントにおいて同期オペレーションが実行され、オープン・ディレクトリ１３０内に反映されたこの変更がディレクトリ・テーブル１１０に移動される。これにより、予期しないシステムの異常またはクラッシュが生じた場合にディレクトリ・テーブル１１０の改ざんを防ぐことができる。
【００８７】
さらに一実施例においては、キャッシュ８０からオブジェクトが要求されたとき、最初にオープン・ディレクトリ１３０が調べられる；オープン・ディレクトリには、もっとも最近に使用された情報オブジェクトに対する参照が含まれていることから、それがヒットをもたらす可能性がもっとも高いと考えられる。この形式のオープン・ディレクトリは、「人気のある」データに関するメイン・メモリ内のキャッシュとして機能する。
【００８８】
（ディスク・データのレイアウトおよび集成）
オープン・ディレクトリ１３０、タグ・テーブル１０２およびディレクトリ・テーブル１１０がアクセスされてストア済みオブジェクト１２４の位置を決定した後は、ストレージからそのオブジェクトを読み出し、そのオブジェクトを要求したユーザにそれを送信しなければならない。キャッシュ８０からオブジェクト５２を取り出すために使用される読み出しオペレーションの効率を向上させるために、最初にデータをストアするとき、一定のデータ集成技法が使用される。ディスク上にデータを最初にストアするとき、ここに示すデータ集成技法に従っていれば、その後の読み出しの効率が大きく改善される。図６は、キャッシュ８０およびストレージ・デバイス９０ａ〜９０ｎとともに使用するためのデータ・ストレージ構成を示すブロック図である。ストレージ・デバイス９０ａは、ディスク・ドライブ等であり、複数のプール２００ａ〜２００ｎにデータをストアする。プールは、連続するディスク空間のセグメントまたはチャンクであり、好ましくは最大で４ギガバイトのサイズを有する。プールは、複数のファイルの断片から、あるいは生のディスク・パーティションのセグメントから割り当てることができる。
【００８９】
プール２００ｎ等の各プールは、ヘッダ２０２および、ここで「アリーナ」と呼んでいる複数の固定サイズのストレージ空間２０４ａ〜２０４ｎを含んでいる。アリーナのサイズは、好ましくは構成可能もしくは変更可能とし、キャッシュ８０のパフォーマンスの最適化を可能にする。好ましい実施例においては、アリーナ２０４ａ〜２０４ｎのそれぞれを概略で５１２キロバイトから２メガバイトまでのサイズを有するブロックとしている。
【００９０】
アリーナに書き込むデータは、メモリ内の「書き込み集成バッファ」に置かれ、あるいは一時的にストアもしくは一時的に置かれる。このバッファは、データを蓄積し、いっぱいになると、１回のシークにおいてディスク上の１つのアリーナに連続的に書き込む。書き込み集成バッファは、書き込みのパフォーマンスを向上させ、データ・アイテムを生のディスク・ドライブから直接読み出すことができるデータのセクタ配列を可能にする。
【００９１】
書き込み集成バッファは、アリーナの全コンテンツを保持する充分な大きさを有する。データは、ディスク上の（空の）アリーナに落とされる前に、まず書き込み集成バッファに置かれて整理統合される。また書き込み集成バッファは、集成バッファを満たすとき、それ以外のストレージを割り当てるために使用されるフリー・トップ・ポインタ、それがカバーしているアリーナに名前を設定する識別名、およびそのアリーナのアクティブ・ユーザ数に関する参照カウントを含んでいる。
【００９２】
各プール・ヘッダ２０２は、マジック・ナンバ、バージョン番号値、アリーナ数の値、および１ないしは複数のアリーナ・ヘッダ２０６ａ〜２０６ｎをストアしている。マジック・ナンバは、単独で内部の一貫性チェックに使用される。バージョン番号値は、プール内にアリーナ２０６ａ〜２０６ｎを生成したプログラムまたはプロセスのバージョン番号をストアする。これは、現在実行中のキャッシュ８０のバージョンが適切にアリーナを読み書きできることを保証するための一貫性チェックに使用される。アリーナ数の値は、プール内に含まれているアリーナの数のカウント値をストアする。
【００９３】
プール・ヘッダ２０２には、アリーナ・ヘッダ２０６ａ〜２０６ｎのそれぞれに、プール内のそれぞれのアリーナに関する情報がストアされる。各アリーナ・ヘッダは、対応するアリーナが空であるか否か、およびそのアリーナの信頼性が失われているか否か（たとえば、物理的なディスク表面のダメージ、あるいはアプリケーションのエラーによって）を示す２つの１ビット値をストアしている。
【００９４】
図６にアリーナ２０４ａの場合を例に示したように、各アリーナは、１ないしは複数のデータのフラグメント２０８ａ〜２０８ｎを含む。それぞれのフラグメント２０８ａ〜２０８ｎは、フラグメント・ヘッダ２０８ｄおよびフラグメント・データ２０８ｅを含んでいる。フラグメント・データ２０８ｅは、キャッシュ８０にストアされるオブジェクトに関する実際のデータである。ストア済みオブジェクト全体に対応するデータは、単一のフラグメント内に存在することもあれば、複数のフラグメントの中にストアされることもあり、またそれが複数のアリーナにわたって存在することもある。フラグメント・ヘッダ２０８ｄは、マジック・ナンバ値２０６ｃ、キー値２０６ａおよび長さ値２０６ｂをストアしている。
【００９５】
長さ値２０６ｂは、フラグメント・ヘッダ２０８ｄおよびフラグメント・データ２０８ｅを含めたフラグメントの長さをバイト数で表す。キー値２０６ａは、このフラグメント内にデータが含まれているオブジェクトのオブジェクト・キーのコピーであり、その全体がストアされている。したがって、キー値２０６ａを使用して、このフラグメント内にデータが含まれているオブジェクトのデータを保持している最初のフラグメントをポイントするディレクトリ・ブロックをルックアップすることができる。
【００９６】
一実施例によれば、特定のオブジェクトに関連付けされた最後のフラグメントに関連して、完全なオブジェクト・キー５６がストアされる。オブジェクト５２を最初にキャッシュ８０にストアするとき、発信サーバ４０からのオブジェクト・データの読み取りに従って漸増的にオブジェクト・キー５６を演算する。つまり、オブジェクト・キー５６の最終値は、オブジェクト５２全体の読み取りが完了するまで明らかにならない。オブジェクト・キー５６は、最後のフラグメントの書き込みまでキーの値が明らかにならないことから、またディスク上の既存のデータに対する修正が時間を要することから、そのオブジェクトのストアに使用されるフラグメントのチェーンの最後に書き込まれる。これとは異なる実施例においては、フラグメント・ヘッダがフラグメントもしくはオブジェクトを記述する別のメタデータをストアすることができる。
【００９７】
書き込み集成バッファは、バッファ２０４ａのもっとも上の空きエリアを示す「フリー・トップ・ポインタ」２１０を含んでいる。トップ・ポインタ２１０は、バッファ２０４ａ内における使用済み空間と使用可能空間の現在の境界を示す。トップ・ポインタ２１０は、キャッシュ８０がバッファ内に追加のフラグメントを書き込む位置を決定できるようにストアされている。トップ・ポインタ２１０より下（図６においては、その左）は、すべて有効なデータを含んでいるか、あるいはそれを受け取るためにすでに割り当てられている。トップ・ポインタ２１０より上の（図６においてはその右の）アリーナ２０４ａのエリアは、他の情報オブジェクトを割り当てるために使用することができる。好ましくは、各フラグメントが最大３２キロバイトのデータを含む。フラグメントの開始および終了は、ストレージ・デバイス９０ａの標準的な５１２バイト境界上となる。ワールド・ワイド・ウェブの関係においては、ほとんどのオブジェクトが比較的小さく、概してそのサイズは３２キロバイトに満たない。
【００９８】
各アリーナは、必ず２つの状態のうちのいずれかになる：つまり空状態または占有状態である。アリーナの現在の状態は、アリーナ・ヘッダ２０６ａ〜２０６ｎにストアされるエンプティ値に反映される。占有状態は、そのアリーナのいずれかの部分に有効なデータがストアされている状態である。現在エンプティであるアリーナ、つまり空いているすべてのアリーナのリストは、メモリ内にストアされている。たとえば、キャッシュ８０を走らせているワークステーションのメイン・メモリが、空のアリーナに対するポインタの配列をストアしている。別の実施例においては、各アリーナのヘッダ２０６ａ〜ｎに追加の情報をストアすることができる。たとえばこれらのヘッダに、そのアリーナに包含されていた削除済み情報オブジェクトの数、およびそのアリーナに対して最後にガーベジ・コレクションが実行された時を示すタイムスタンプを含めることが考えられる。
【００９９】
図６には、例として３つのフラグメントを示したが、実際にはアリーナの容量に達するまで任意数のフラグメントを１つのアリーナにストアすることが許される。それに加えて、図６に示したプールの数およびアリーナの数は、例示のみを目的としたものであり、これらには任意の数を使用することができる。
【０１００】
上記のアリーナの構造は、アリーナのフラグメントにストアされるオブジェクトに関するデータ更新の特定の一貫性メカニズムおよび安全メカニズムを容易にする。図７に、図６に示したアリーナ２０４ａ〜２０４ｎの１つの更新に関係するブロック図を示す。図７は、ヘッダ２０６およびデータ・フラグメント２０８ａ〜２０８ｃを有する第１の情報オブジェクト２０８ｂを包含するアリーナ２０４ａを示している。トップ・ポインタ２１０は、アリーナ２０４ａのもっとも上のアクティブ部分、つまりデータ・セグメント２０８ｃの末尾をポイントする。好ましくは、１つのアリーナに対する完全な情報オブジェクトの書き込みが完了した後に限り、かつアリーナのトップ・ポインタを異常なく移動させた後に限ってディレクトリ・テーブルを更新する。たとえば、アリーナ２０４ａのトップ・ポインタ２１０より上に完全な情報オブジェクトを書き込み、トップ・ポインタを移動してアリーナの空き位置の新しいトップを表示させる。その後初めてディレクトリ・テーブルを更新する。
【０１０１】
ディレクトリ・テーブルの更新を遅らせることにより、それ以外のステップのいずれかを行う間に、破局的なシステムの障害が生じた場合においてもディレクトリ・テーブルの正確性が保証される。たとえば、いずれかのステップを完了する前に、ディスク・ドライブまたはその他のシステムのエレメントがクラッシュしたとしても悪影響は生じない。その場合、アリーナ２０４ａは、信頼性のない、もしくは不完全なデータを含むことになるが、ディレクトリ・テーブル１１０、インデクス、またはハッシュ・テーブル内に信頼性を失ったデータに対する参照がまったく存在しないことから、キャッシュ８０は実質的にそれを無視する。それに加えて、信頼性のない、もしくは不完全なデータは、ここに述べるガーベジ・コレクション・プロセスを使用して最終的に再利用される。
【０１０２】
（マルチフラグメント・オブジェクト）
図３において、オブジェクト５２のオブジェクト・キーに基づいて到達したディレクトリ・テーブル・ブロック１１２ｂは、オブジェクト５２がストアされているフラグメントに対するポインタ・ディレクトリを含んでいる。これには、オブジェクト５２が単一のフラグメントにストアされていることが前提となる。しかしながら大きなオブジェクトは、必ずしも単一のフラグメントに収まるわけではなく、その理由は２つある。第１は、フラグメントは最大サイズが固定されている（好ましい値を３２ＫＢとする）ことである。したがって、３２ＫＢを超えるオブジェクトは分断される。第２は、システムが、新しいオブジェクトのために、書き込み集成バッファ内に空間をあらかじめ予約しなければならないことである。到来するオブジェクトのサイズがオブジェクト・ストアにとって未知であれば、推定を誤る可能性がある。サーバがオブジェクトの真の（実際には大きい）サイズを誤って表すこともある。いずれの場合においてもオブジェクト・ストアは、フラグメントのチェーンを構成してオーバーフローを処理する。
【０１０３】
したがって、フラグメント間において分断されたオブジェクトからのデータを含むフラグメントを追跡するためのメカニズムが提供されている。図５は、関連するフラグメントを追跡するための好ましい構造を示したブロック図である。
【０１０４】
説明のため、ここではオブジェクトＸがストレージ・デバイス９０ａ〜９０ｎ上の３つのフラグメント２０８ａ、２０８ｂ、および２０８ｃにストアされているものと仮定する。キャッシュは、オブジェクトＸ用のオブジェクト・キーを使用してタグ・テーブルを調べ、ディレクトリ・テーブル１１０内の特定のブロック１４１ａに到達する。ブロック１４１ａは、オブジェクトＸを包含している連続するフラグメントを識別するブロックのヘッドである。ここに示した例においては、このチェーンに、ブロック１４１ａ、１４１ｂ、１４１ｃ、１４１ｄおよび１４１ｅが含まれ、ポインタ１２８ａ〜１２８ｄによってそのチェーンが形成されている。
【０１０５】
一実施例によれば、ヘッド・ブロック１４１ａは、サブキー値１２６およびブロック・ポインタ１２８ａを備える。好ましくは、サブキー値１２６の長さを９６ビットとし、オブジェクトＸ用のオブジェクト・キー５６の値のサブセットから構成する。ブロック・ポインタ１２８ａの値は、チェーン内の次のブロック１４１ｂを参照する。
【０１０６】
ディレクトリ・テーブルのブロック１４１ｂは、フラグメント・ポインタ１３０ａおよびブロック・ポインタ１２８ｂを含む。フラグメント・ポインタ１３０ａは、フラグメント２０８ａを参照し、そこにはオブジェクトＸに関するデータの最初の部分がストアされている。ポインタ・ブロック１４１ｂのブロック・ポインタ１２８ｂは、このチェーン内の次のポインタ・ブロック１４１ｃを参照する。ポインタ・ブロック１４１ｂと同様に、ポインタ・ブロック１４１ｃも、フラグメント２０８ｂを参照するフラグメント・ポインタ１３０ｂを含む。ポインタ・ブロック１４１ｃのブロック・ポインタ１２８ｃは、このチェーン内の次のポインタ・ブロック１４１ｄを参照する。ポインタ・ブロック１４１ｃと同様に、ポインタ・ブロック１４１ｄも、フラグメント２０８ｃを参照するフラグメント・ポインタ１３０ｂを含む。
【０１０７】
オブジェクト・ストアは、フラグメントを互いにつなぐためのメカニズムを必要とする。従来のディスク・ブロックのチェーニング・スキームは、ディスク上にすでに存在しているデータを修正し、直前のチェーン・リンク・ポインタがその次の新しいブロック値をポイントするように変更する必要がある。すでに存在してディスク・データの修正は時間を要し、前もって終了が知らされないプロセスに抗して一貫性を確保することに関連する複雑性がもたらされる。
【０１０８】
本発明の一実施例に従えば、「反復関数ポインタ」を使用することによって新しいフラグメント・ポインタを現存するフラグメントにパッチする必要がなくなる。各フラグメントにはキーが割り当てられ、次のフラグメントのキーが、直前のフラグメントのキーの単純な反復関数として割り当てられる。この方法によれば、直前のフラグメントのポインタを修正するのではなく、次のフラグメントのキーを定義するだけで単純にフラグメントをつなぐことができる。
【０１０９】
たとえばここで、サブキー１２６の値に関数を適用することによってブロック・ポインタ１２８ａを演算する。ブロック・ポインタ値１２８ｂは、ブロック・ポインタ１２８ａの値に関数を適用することによって演算される。ポインタ値の演算に使用されるこの関数は、重大なものではなく、多くの各種関数を使用し得る。この関数は、次のような単純な累加関数とすることができる。
【０１１０】
key_n = key_n-1 + 1
あるいは、この関数をＭＤ５ハッシュ関数等の複雑な関数とすることもできる。
【０１１１】
key_n = MD5(key_n-1)
唯一求められる要件は、可能性のあるキーの値の範囲が充分に大きく、その反復に充分な選択があり、範囲の衝突または周期的なルーピングの可能性が小さいことである。可能性は非常に低いがキーの衝突を生じた場合には、オブジェクトがキャッシュから削除される。
【０１１２】
このチェーン内の最後のポインタ・ブロック１４１ｄは、テール・ブロック１４１ｅをポイントするブロック・ポインタ１２８ｄを有している。テール・ブロック１４１ｅは、このチェーン内の最初のブロック１４１ａに対する参照を含む。一実施例によれば、テール・ブロック１４１ｅに包含されている参照は、オブジェクトＸのオブジェクト・キーの、９６ビットのサブキー１３２である。キャッシュは、この９６ビットのサブキー１３２を使用してヘッド・ブロック１２８ａを見つけ出すことができる。テール・ブロック１４１ｅおよびそれによって提供されるポインタのループ構成により、キャッシュ８０は、チェーン内の任意のブロックから開始してすべてのブロックを見つけ出すことができる。
【０１１３】
図５に示した３つのフラグメント２０８ａ、２０８ｂ、および２０８ｃは、単に例示のみを目的とする。実際には、情報オブジェクトが任意数のフラグメントを占有し、あるいは参照し、そのそれぞれが、ディレクトリ・テーブル１１０内のそれ独自のポインタ・ブロックによって識別されることになる。
【０１１４】
オブジェクト５２をストレージ・デバイスから読み出すとき、最後のフラグメントにストアされているコンテンツのＭＤ５キーがディレクトリ・キー値に一致することを保証するために、それが最初に読み出される。このテストは、適正なオブジェクトが見つけ出されたことを保証するための「健全性」チェックとして行われる。一致がなければ、衝突が生じ、異常が発生していることになる。
【０１１５】
（空間割り当て）
図１０Ａは、新しくキャッシュに入れられたオブジェクトに空間を割り当て、そのオブジェクトを割り当てた空間に書き込むための方法を示したフローチャートである。割り当ておよび書き込みの方法は、参照番号６４０によって包括的に示されている。概して、図１０Ａに示したステップは、たとえば図８Ｆのステップ８９８における場合のように、ディレクトリ・テーブルおよびタグ・テーブル内においてミスが生じたときに実行される。
【０１１６】
つまり、情報オブジェクトがクライアントから要求されたがキャッシュ内に見つからなかったとき、ステップ６４２においてその情報オブジェクトをルックアップし、その発信ロケーションからそれを取り出す。ネットワーク環境においては、発信ロケーションがサーバ４０、クラスタ、またはディスクになる。オブジェクトを取り出すと、ステップ６４４において、そのオブジェクトのタイプおよびサイズがキャッシュ内にストア可能か否か、つまり「キャッシュ可能であるか」について評価する。
【０１１７】
キャッシュ可能でないオブジェクトの例としては、サーバ・アプリケーションによって動的に生成されるウェブ・ページ、クライアント側アプレットによって生成されるウェブ・ページのペインまたは部分、データベースからの動的データに基づいて構築されるオブジェクト、およびその他の非静的オブジェクトが挙げられる。そういったオブジェクトは、それらが生成されるごとにそのフォームとコンテンツが変化することからキャッシュ内にストアすることができない。その種のオブジェクトをキャッシュ内にストアした場合には、キャッシュのアクセスとアクセスの間にその基礎をなす動的データが変更されると、オブジェクトの信頼性が失われるか、正しくなくなる。プロセスは、サーバ４０またはその他のオブジェクトのソースからのＨＴＴＰ応答内に含まれている情報を調べて、そのオブジェクトがキャッシュ可能か否か判断する。
【０１１８】
そのオブジェクトがキャッシュ可能であれば、この方法では、ステップ６４６においてそのオブジェクトのバイト数で表される長さを獲得する。たとえば、ワールド・ワイド・ウェブに関連して本発明の適用があるときは、ＨＴＴＰトランザクションにおいて運ばれるメタデータ内に、そのウェブ・ページの長さを含ませることができる。その場合キャッシュは、情報オブジェクトを含むＨＴＴＰメッセージ内の応答情報から、その情報オブジェクトの長さを抽出する。長さが含まれていないときには、推定が行われる。この推定が正しくないこともあり、それによってオブジェクトのフラグメント化を招くことになる。
【０１１９】
ブロック６４８として示したように、続いてメモリ常駐の書き込み集成バッファ内に空間を割り当て、書き込みをおこなうオブジェクトを、割り当てられたバッファ・ロケーション内に流し込む。好ましい実施例においては、ブロック６４８が、充分な空間を有し、オブジェクトの保持に使用できる書き込み集成バッファ内の空間割り当てを伴う。ブロック６５０においてキャッシュは、書き込み集成バッファに空き空間が残っているか否かを評価する。残っていれば、割り当ておよび書き込みプロセスを完了し、キャッシュ８０は別のタスクを実行することが可能になる。書き込み集成バッファがいっぱいになると、ブロック６５０の内容が肯定されてコントロールがブロック６５６に移される。
【０１２０】
ブロック６５６においてキャッシュは、集成バッファを、それがシャドーイング(shadowing)しているアリーナに書き込む。ステップ６６０においては、ディレクトリが更新されて、新しい情報オブジェクトの位置が反映される。
【０１２１】
以上の一連のステップは、キャッシュに書き込まれる情報オブジェクトの完全性が保証される形に整理されている。たとえば、ディレクトリは、ヘッダおよびデータを含めて完全な情報オブジェクトがアリーナに書き込まれた後にのみ更新される。またたとえば、ステップ６５２またはステップ６５８の完了前に、ディスク・ドライブまたはシステムのその他のエレメントがクラッシュした場合にも悪影響が生じない。その場合アリーナは、信頼性のない、もしくは不完全なデータを含むことになるが、インデクス、またはハッシュ・テーブル内に信頼性を失ったデータに対する参照がまったく存在しないことから、実質的にキャッシュによってそれが無視される。それに加えて、信頼性のない、もしくは不完全なデータは、次に述べるガーベジ・コレクション・プロセスを使用して最終的に再利用される。
【０１２２】
（ガーベジ・コレクション）
図８Ａは、キャッシュ８０に使用可能なガーベジ・コレクションの方法を示したフローチャートである。図８Ｂは、図８Ａに示したステップの細部を示したフローチャートであり、図８Ａとともに説明する。好ましくは、ガーベジ・コレクション方法を、キャッシュに関連のある別のプロセスと並行に走る独立なプロセスとして実装する。これにより、このガーベジ・コレクション方法は、キャッシュのオペレーションに割り込み、あるいはそれに影響を与えることなく、定期的にキャッシュのストレージ・エリアをクリーン・アップすることができる。
【０１２３】
（１．全般プロセス）
好ましい実施例においては、「ガーベジ・コレクション」は、ターゲット・アリーナのスキャン、アクティブ・フラグメントの識別またはフラグメントを削除すべきか否かの決定、隣接する新しいアリーナへのアクティブ・フラグメントの書き込み、およびフラグメントの新しいロケーションを参照すべく行うディレクトリ・テーブルの更新からなるプロセスを意味する。つまり、非常に広い意味でこの方法は「退避」タイプであり、それにおいては古いもしくは不必要なフラグメントが削除されてアクティブ・フラグメントが別の場所に書き込まれ、その結果、特定のアリーナに対するガーベジ・コレクション・オペレーションが完了したとき、そのアリーナが空になる。好ましくは、ターゲット・アリーナおよび新しいアリーナがともに、揮発性メモリ内においてストアされ、操作される。ガーベジ・コレクションが完了すると、同期化と呼ばれるプロセスにおいて、ディスク等の不揮発性ストレージにストアされる、対応するアリーナにガーベジ・コレクションにおいて生じた変更が書き込まれる。
【０１２４】
ステップ８０２において、プール２００ａ〜２００ｎの１つがガーベジ・コレクション・オペレーション用に選択される。好ましくは、ストレージ・デバイス９０ａのそれぞれのプール２００ａ〜２００ｎごとに、キャッシュが、現在アクティブ・データをストアしているプール内のディスク空間の量を示す値をストアしているか、あるいはそれにアクセスできるものとする。またキャッシュは、ブロック８０３に示されるように、一定の「低水位」および「高水位」値をストアしている。特定プールのアクティブ・ストレージの量が「高水位」値を超えると、ガーベジ・コレクションが開始され、そのプール内のアクティブ・ストレージの量が「低水位」を下回るまで繰り返される。「低水位」値は、ゼロより大きくなるように選択され、「高水位」値は、プールの合計容量より約２０％少なくなるように選択される。このようにしてプールがオーバーフローする前に、あるいはストレージ・デバイス９０ａの容量超過を招く前にガーベジ・コレクションが実行される。
【０１２５】
（２．用法を意識したガーベジ・コレクション）
ステップ８０４においては、ガーベジ・コレクションを実行するターゲットとしてアリーナの１つが選択される。このアリーナは、各種の要因を考慮した選択アルゴリズムによって選択される。ブロック８０５として示したように、この要因には、たとえばキャッシュ８０によってアクセスされた最後のアリーナであるか否か、およびそのアリーナに対する合計アクセス回数が含まれる。別の実施例においては、この要因として、各アリーナから削除された情報オブジェクトの数、また最後にそのアリーナが使用されたのはいつか、各アリーナに対して最後にガーベジ・コレクションが行われたのはいつか、さらに現在アリーナに読み出しまたは書き込みのロックがセットされているか、といったことを含めてもよい。ガーベジ・コレクション用にアリーナを選択した後は、そのオブジェクト内のすべてのフラグメントをガーベジ・コレクションの対象として個別に考慮する。
【０１２６】
ステップ８０６においては、選択したアリーナ内のフラグメントの１つをガーベジ・コレクションの対象として選択する。いずれのフラグメント（１ないしは複数）を選択するかの決定において、キャッシュ８０は、ブロック８０７に示されるようにいくつかの選択要因を考慮する。好ましい実施例においては、この要因に次のものが含まれる：すなわち、そのフラグメントに最後にアクセスした時刻；そのフラグメント内にデータを有するオブジェクトに対して発生したヒットの数；そのフラグメントからクライアントにデータをダウンロードするために必要な時間；および、そのフラグメントを一部として構成されるオブジェクトのサイズである。別の実施例においては別の要因が考慮される。これらの要因に関する値は、そのフラグメントがデータをストアしているオブジェクトに関連付けされたブロック１１２ａ〜１１２ｎにストアされている。
【０１２７】
ブロック８０８においてキャッシュは、そのフラグメントを削除すべきか否かを判断する。好ましい実施例においては、ブロック８０８が、ある種のパフォーマンス要因および最適化の考慮事項の評価を伴う。
【０１２８】
キャッシュは、主に２つの理由から使用されるが、これらの理由は衝突の可能性を抱えている。最初の理由は、クライアントのパフォーマンス向上である。クライアントのパフォーマンスを向上させるためには、ガーベジ・コレクタにとって、サーバのダウンロード時間を最小にするオブジェクトを保持しておくことが望ましい。これは、遅い外部サーバから受け取ったドキュメントをキャッシュさせる方向にガーベジ・コレクタを偏らせる傾向がある。第２の理由は、サーバのネットワーク・トラフィックの最小化である。サーバ・トラフィックを最小化するためには、ガーベジ・コレクタにとって、大きなオブジェクトを保持しておくことが望ましい。これらの最適化はしばしば衝突する。
【０１２９】
オブジェクトをダウンロードするために必要な時間、そのオブジェクトのサイズ、およびキャッシュ内においてそのオブジェクトがヒットした回数を識別する値をストアすることによって、ガーベジ・コレクタは、それぞれのオブジェクトについて、オリジナルのサーバからフェッチする代わりにキャッシュしたコピーを提供した結果、どの程度サーバのダウンロード時間が回避されたか、またどの程度のサーバ・トラフィックが不要になったかを評価することができる。この測定は、キャッシュされたオブジェクトの「固有値」を評価する。
【０１３０】
キャッシュ・アドミニストレータは、続いて時間のセーブまたはトラフィックのセーブのためにキャッシュを最適化する程度を表す０から１までの範囲のパラメータを設定する。上記の値は、そのアリーナ内の別のオブジェクトとの関連から、そのオブジェクトが消費している空間の量との関連から、および最近ガーベジ・コレクションの対象となったオブジェクトとの関連から評価される。この種の評価に基づいて、キャッシュ８０は、ステップ８０８に示されるようにフラグメントを削除すべきか否かを判断する。
【０１３１】
そのフラグメントを削除すべきと判断した場合には、ステップ８１２において削除済みとマークを付け、そのフラグメント内にデータを上書きすることによってそれを削除する。オブジェクト５２が複数のフラグメント内にストアされており、ガーベジ・コレクション・プロセスがそのフラグメントの１つを削除すべきであると判断したときは、プロセスは、そのオブジェクトに関連付けされたすべてのフラグメントを削除する。これには、図５に示したタイプの、別のアリーナに、さらには別のプールに続くフラグメントのチェーンが関係することもある。
【０１３２】
そのフラグメントを削除すべきでないと判断した場合には、ステップ８１０においてそのフラグメントを新しいアリーナに書き込む。次に説明する図８Ｂは、ステップ８１０の実行に関連する好ましいサブステップを示している。
【０１３３】
フラグメントを削除し、あるいは別のアリーナに移動した後は、ステップ８１４においてディレクトリ・テーブル１１０を更新してフラグメントの新しい位置を反映させる。ステップ８１４は、そのフラグメントに関連付けされているブロック１１２ａ〜１１２ｎをルックアップするために更新すべきフラグメント２０８ｎに関連付けされたフラグメント・ヘッダ２０８ｄ内のキー値２０６ａの使用を必要とする。適正なディレクトリ・テーブル・ブロック１１２ａ〜１１２ｎが識別されると、ブロック内のディスク・ロケーション値１１８を更新してフラグメントの新しい位置を反映させる。フラグメントを削除した場合には、続いて対応するディレクトリ・テーブルのエントリを削除する。
【０１３４】
ステップ８１６は、この方法がディレクトリ・テーブル１１０の更新後に完了することを示している。しかしながらここで、図８Ａに示したステップがすべてのプール、各プール内のすべてのアリーナ、さらに各アリーナ内のすべてのフラグメントに対して実行されることを理解されたい。
【０１３５】
（３．新しいアリーナへのフラグメントの書き込み）
図８Ｂは、ステップ８１０の実行に関連するステップ、つまり新しいアリーナへの、保存すべきフラグメントの書き込みに関連するステップを表したフローチャートである。退避するフラグメントを新しいアリーナに書き込むプロセスは、オリジナルのフラグメントに書き込むプロセスと完全に類似している。データは、書き込み集成バッファに書き込まれ、いっぱいになるとディスクのアリーナに落とされる。
【０１３６】
ステップ５９０においては、ディレクトリ・テーブルを更新し、そのフラグメントの位置の変更を反映させる。好ましい実施例においては、ステップ５９０が、ディレクトリ・テーブル１１０に対する直接的な更新ではなく、オープン・ディレクトリ１３０への更新情報の書き込みを伴う。その後、プロセスによって、そのフラグメント・データ２０８ｅが異常なくストレージ・デバイス９０ａ〜９０ｎの１つに書き込まれたことが確認できたとき、オープン・ディレクトリ１３０内に反映されている変更をディレクトリ・テーブル１１０内に書き込み、つまりそれを同期させる。
【０１３７】
このプロセスは、ディレクトリ・テーブル１１０の完全性が常に保護されることを保証するために使用される。前述したように、バッファされたストレージは、フラグメントのために使用される；つまり、フラグメントが更新され、あるいは新しいフラグメントが書き込まれたとき、フラグメント・データがバッファに書き込まれ、その後、将来においてディスクまたはその他のストレージ・デバイスに引き渡される。したがって、ガーベジ・コレクション・プロセスがディレクトリ・テーブルの更新の準備が整ったとき、ガーベジ・コレクションの間に新しいアリーナに移動されたフラグメントが、実際にストレージ・デバイスの１つに書き込まれていないということがあり得る。そこで、変更がディスクに引き渡されるまで、変更に関する情報をオープン・ディレクトリ１３０内にストアしておく。
【０１３８】
ステップ５９２においては、オリジナルのアリーナを調べて再利用、もしくは新しいアリーナへの移動を必要とするフラグメントが残っているか否かを評価する。ほかのオブジェクトが存在するときは、コントロールを図８Ａのステップ８０６に戻し、その結果、次のオブジェクトの処理が可能になる。現在のアリーナ内にほかのオブジェクトが存在しない場合には、ステップ５９４において、現在のアリーナのトップ・ポインタをリセットする。
【０１３９】
（４．バッファリング）
好ましい実施例においては、読み出しおよび書き込みのオペレーションがキャッシュ８０によって実行され、ガーベジ・コレクション・プロセスが２とおりにバッファされる。
【０１４０】
まず、キャッシュ８０と、ブラウザからオブジェクトを要求しているクライアント１０ａの間の通信が「Ｖコネクション（VConnection）」と呼ばれるデータ構造のフロー・コントロール、ストリーミング、およびバッファリングを介してバッファされる。好ましい実施例においては、キャッシュ８０がオブジェクト指向プログラム言語により準備されたコンピュータ・プログラムのセット内において実装される。この実施例においてＶコネクションは、プログラムの１つによって宣言されたオブジェクトであり、Ｖコネクションは、メモリ内においてバッファをカプセル化する。好ましくはこのバッファはＦＩＦＯバッファであり、そのサイズを３２キロバイトとする。
【０１４１】
クライアント１０ａ〜１０ｃがキャッシュ８０に接続すると、キャッシュはそのクライアントをＶコネクションに割り当てる。クライアント１０ａから受け取ったデータは、Ｖコネクションを介してキャッシュ８０に渡され、キャッシュが情報をクライアント１０ａに送る必要があるときには、キャッシュはその情報をＶコネクションに書き込む。Ｖコネクションは、キャッシュ８０からのデータのフローを、クライアント１０ａによってキャッシュとの通信に使用される送信速度と整合させるべく調整する。このようにして、Ｖコネクションの使用は、メイン・メモリ・ストレージの不必要な無駄を回避する。この種の無駄は、クライアント１０ａに送信するオブジェクトの全体をメモリにコピーし、その後それをクライアントに送信する場合に生じ、遅いクライアントへの送信の間、メイン・メモリが不必要に拘束される。これらのメカニズムを使用するバッファ付きＩ／Ｏは、ディスクに対して実行される連続した読み出しおよび書き込みのオペレーションの回数を低減する傾向にある。
【０１４２】
（５．同期および一貫性の強化）
ガーベジ・コレクション・プロセスの間およびキャッシュ８０のオペレーションの間は、規則的に同期化プロセスが実行される。同期化プロセスは、オープン・ディレクトリ１３０内に反映されている変更をディレクトリ・テーブル１１０および、ストレージ・デバイス９０ａ〜９０ｎの１つもしくはいくつかに含まれる不揮発性ストレージ等の安定したストレージに渡す。その目的は、ディスク上のデータの一貫性を常に維持することにある。つまり、任意の瞬間において、ディスク上のデータ構造の状態が１００％無矛盾であり、キャッシュが、チェックを必要とすることなくスタート・アップできることである。これは、ディスクに対するデータならびにメタデータの書き込みおよび同期を慎重に定めることによって達成される。
【０１４３】
説明のため、このセクションにおいては、キャッシュに対してストアが要求された実際のオブジェクトを「データ」とする。たとえば、キャッシュがＨＴＭＬドキュメントをストアしているとき、データはそのドキュメントそのものとなる。「メタデータ」は、キャッシュが「データ」をインデクスし、その後のｌｏｏｋｕｐ（）オペレーション（ルックアップ・オペレーション）の間に見つけられるようにするためにストアを必要とする追加の情報、およびキャッシュが「データ」用の空間を割り当てるために必要とする情報を指す。「メタデータ」は、ディレクトリおよびプール・ヘッダからなる。ディレクトリは、キー（名前）をディスク上の特定の位置（データ）に関連付けするためにキャッシュによって使用されるインデクスである。キャッシュは、プール・ヘッダを使用してキャッシュ内に割り当てられたディスク空間を追跡している。
【０１４４】
キャッシュは、ディスク上のデータ構造の一貫性を維持するために２つの規則を使用する。最初の規則は、メタデータを、必ずそれがポイントしているデータの後に書き込むというものである。この最初の規則は、メタデータが書き込まれるまで、キャッシュがキャッシュ内のオブジェクトについて「不変の」知識を持つことがないことを理論的根拠とする。キャッシュがデータに先行してメタデータを書き込み、その時点でクラッシュした場合を考えると、そのメタデータは、ディスク上の無効なオブジェクト・データを伴うオブジェクト名に関連付けされることになる。これによりキャッシュが、ヒューリスティック・アプローチを使用して試行を繰り返し、良好なデータをポイントするメタデータおよび不良データをポイントするメタデータを決定しなければならなくなくことから、これは望ましくない。
【０１４５】
２番目の規則は、アリーナをポイントするすべてのディレクトリ・メタデータが削除され、ディスクに書き込まれるまで、空であるとしてプール・ヘッダ内においてプール・アリーナをマークすることができないというものである。これは、クラッシュによって、ディレクトリ・メタデータがポイントする空のアリーナが存在してしまうことを防止するために必要である。これによってもたらされる可能性のある問題は、その空のアリーナが、それが空であることから新しいデータによって満たすことができるようになり、その結果、それが新しいデータの書き込みに使用できるようになることである。しかしながら「古い」ディレクトリ・メタデータは、この新しいデータと同じ位置をポイントしている。その場合、古いディレクトリ・メタデータへのアクセスが、古いデータもしくはフェイルを返さずに新しいデータを返すことが起こり得る。
【０１４６】
図８Ｃは、上記の２つの規則を実装する好ましい同期化方法８２０を示すフローチャートである。ブロック８２２において、オブジェクトをキャッシュに書き込む。ブロック８２２は、ブロック８２４およびブロック８２６に示したステップ、つまりオープン・ディレクトリ内にメタデータを作成するステップ、およびそのオブジェクト・データをディスクに書き込み、同期させるステップを伴う。
【０１４７】
ブロック８２８〜８２０'のステップは、周期的に実行される。ブロック８２８に示されるようにオープン・ディレクトリ・テーブル内のメタデータを個別に注目し、ブロック８２１に示されるように、それぞれのメタデータごとに、そのメタデータがポイントするデータがすでにディスクと同期されているか否かを判断する。同期されていれば、ブロック８２３においてキャッシュは、安定したデータをポイントするそのメタデータをオープン・ディレクトリからディレクトリ・テーブルにコピーする。ブロック８２５においては、ディスクに対してこの変更を同期させる。
【０１４８】
ブロック８２７においては、アリーナに対するガーベジ・コレクションを実行する。ブロック８２７は、図８Ａに示したステップを包含するものとすることができる。それに代えて、ガーベジ・コレクションを概してブロック８２９、ブロック８３１、およびブロック８２０'に示したステップを含むものとしてもよい。ブロック８２９においては、これに示されるようにアリーナ内の各フラグメントについて、キャッシュが、そのセグメントをポイントするディレクトリ・メタデータを削除し、ディレクトリ・メタデータをディスクに書き込む。ブロック８３１においては、そのアリーナが空であるとマークされるように、メモリ内においてプール・ヘッダを修正する。ブロック８２０'においては、プール・ヘッダをディスクに書き込み、同期させる。
【０１４９】
ディスクに対する情報の書き込みに関連するステップは、好ましくは、キャッシュ８０を走らせているワークステーションのオペレーティング・システムに提供されている「フラッシュ」オペレーションを使用する。「フラッシュ」オペレーションは、オブジェクト・データをストアするために使用されたバッファ内の任意のデータを不揮発性ストレージ・デバイス９０ａ〜９０ｃに書き込む。
【０１５０】
上記の方法を用いると、変更を記述したデータがディスクまたはその他の不揮発性ストレージに実際に書き込まれるまで、オープン・ディレクトリ内の変更によってディレクトリ・テーブルが更新されることがない。またキャッシュ８０は、ガーベジ・コレクション・プロセスによって行われた変更がディスクに渡されるまで、ディスク上のアリーナの更新を延期する。これは、オープン・ディレクトリからディレクトリ・テーブルを更新する前にシステムのクラッシュを生じた場合にも、アリーナが継続的に有効なデータをストアすることを保証する。
【０１５１】
（６．再更新）
好ましい実施例においては、キャッシュ内の古い情報オブジェクトを再更新し、ガーベジ・コレクション・プロセスにおいてそれらが破壊されないようにする方法が提供される。
【０１５２】
図１２は、好ましい再更新プロセスを示したフローチャートである。ブロック１２０２においては、外部プログラムまたはプロセスがキャッシュに要求を渡し、特定の情報オブジェクトが最近クライアントによってロードされたか否かを問い合わせる。キャッシュは、この要求に応答して、ブロック１２０４に示されるようにキャッシュ内のその情報オブジェクトを見つけ出す。ブロック１２０６においては、ディレクトリ・テーブル内のその情報に関連付けされた読み出しカウンタ値を読み取る。ブロック１２０８においては、この読み出しカウンタ値が高いか否かをキャッシュが評価する。
【０１５３】
読み出しカウンタ値が高いときは、最近その情報オブジェクトのロードがあったことになる。その場合、ブロック１２１０において、要求を行っているプロセスに対し、問い合わせ内容を肯定する応答メッセージを送る。読み出しカウンタ値が高くないときは、ブロック１２１２に示されるように、その情報オブジェクトは最近ロードされていない。したがって、ブロック１２１４に示されるように、呼び出しを行っているプログラムまたはプロセスに対して、キャッシュは問い合わせ内容を否定する応答メッセージを送る。ブロック１２１６においてキャッシュは、その情報オブジェクトに関連してストアしている期限値を更新し、現在の日付または時刻を反映させる。キャッシュが期限を更新することによって、更新後のそのオブジェクトが古いと見なされなくなることから、ガーベジ・コレクション・プロセスにおいてそのオブジェクトの削除が回避されることが保証される。このようにしてキャッシュ内の古いオブジェクトをリフレッシュし、それによって発信元からそれを取り出し、キャッシュに書き込み、かつ期限切れとなったそのオブジェクトのコピーを削除することを回避している。
【０１５４】
（スケーリング付きカウンタの更新）
図１０Ｂは、スケーリング付きカウンタを更新する方法を示したフローチャートである。好ましい実施例においては、図３Ａに示したディレクトリ・テーブルのセット内の各ブロック１１２ａ〜１１２ｎにストアされる読み出しカウンタ値を管理するために、図１０Ｂに示した方法が使用される。しかしながら、図１０Ｂに示した方法をその範囲に限定する意図はない。図１０Ｂに示した方法は、それぞれカウンタを有する複数オブジェクトの管理を含み、かつもっとも最近使用されたオブジェクトないしは最近ほとんど使用されないオブジェクトを追跡することが望ましい任意のアプリケーションに適用できる。過去のアプローチと比較した図１０Ｂに示した方法の主な利点は、この方法によって小さなストレージ・エリア内において大きなカウンタ値の追跡が可能になることである。
【０１５５】
好ましい実施例においては、ブロック１１２ａ〜１１２ｎにストアされる読み出しカウンタ値が、それぞれ３ビットの量としてストアされる。キャッシュ８０のオペレーションの間、ブロックがアクセスされると、そのブロックの読み出しカウンタ値が１つインクリメントされる。３ビットを用いて表すことができる最大の値を１０進数で表すと７である。したがって、読み出しカウンタ値は、７回インクリメントされるとオーバーフローする。カウンタのオーバーフローを回避しつつ、カウンタに、それをインクリメントするオペレーションを無制限に追跡させるために、図１０Ｂに示した方法が周期的に実行される。
【０１５６】
以下に示す図１０Ｂのステップに関する説明は、次の表１を参照することによってより明確に理解されよう。
【０１５７】
表１ ― 連続的なカウンタ値
イベント カウンタ
Ａ Ｂ Ｃ
１：スタート １ １ １
２：インクリメント ２ １ １
３：インクリメント ７ ３ １
４：デクリメント ６ ２ ０
５：再利用 ６ ２ −
【０１５８】
表１においてイベント列は、一連のカウンタ値に影響を与える連続的なイベントを識別し、そのイベントの性質を簡単に示している。カウンタの列タイトルは、カウンタ値Ａ、Ｂ、およびＣが表されている個別の列を示している。各カウンタ値Ａ、Ｂ、およびＣは、それぞれディレクトリ・テーブル１１０の異なるブロック１１２ａ〜１１２ｎにストアされるカウンタ値に対応する。つまり、表１の各行は、時間的に連続するスナップショットにおける３つのカウンタ値の内容を表している。
【０１５９】
表１のイベント１は、時間的な任意のスタート・ポイントを表し、それにおいてハッシュ・テーブルのカウンタ値Ａ、Ｂ、Ｃを含む各エントリは、１回だけアクセスされている。したがって、各カウンタＡ、Ｂ、Ｃの値は１である。イベント２においては、キャッシュが、カウンタ値Ａをストアしているハッシュ・テーブルのエントリに対してアクセスした。この結果、カウンタＡがインクリメントされてその値が２になるが、残りのカウンタＢおよびＣには変更がない。その後ハッシュ・テーブルのエントリに対するアクセスが何回か行われ、それぞれのアクセスごとにカウンタＡ、ＢまたはＣのいずれかがインクリメントされたとする。それにより、イベント３においてはカウンタＡ、Ｂ、Ｃの値が、それぞれ７、３、あるいは１となっている。つまり、カウンタＡは、それが表すことができる最大の値、すなわち２進数の１１１すなわち１０進数の７をストアしており、この値をさらにインクリメントしようとするとオーバーフローを生じることになる。
【０１６０】
この時点において、図１０Ｂに示した方法がカウンタＡ、Ｂ、Ｃに適用される。ステップ６２２においては、すべてのカウンタの値を読み取る。ステップ６２４においては、すべてのカウンタ値の合計を計算する。表１の場合であれば、この合計は７＋３＋１＝１１となる。ステップ６２６においては、すべてのカウンタによって表すことができる最大の合計値を、カウンタ値のビット長に基づいて求める。３ビットの値の場合は、１つのカウンタが表すことができる最大値は７であり、３つの３ビット・カウンタを合計した最大値は７×３＝２１となる。ステップ６２６は省略することも可能であり、その場合は上記に代えてスケーリング付きカウンタの方法６２０が使用できる定数として最大値をストアし、必要に応じてそれを取り出せばよい。
【０１６１】
ステップ６２８においては、値（最大値／２）の小数点以下を切り捨てた値を計算し、それと全カウンタの合計を比較する。前述の例であれば、この関係は次のようになる。
【０１６２】
合計＝１１
最大値＝２１
最大値／２＝１０
（合計＞最大値／２）＝真
【０１６３】
結果が真であることから、コントロールがステップ６３０に進み、すべてのカウンタ値を１つデクリメントする。このステップの後のカウンタＡ、Ｂ、Ｃの状態をイベント４の「デクリメント」として示す。ここで、最近ほとんど使用されていないハッシュ・テーブルのエントリを表すカウンタＣがゼロにデクリメントされていることに注意されたい。この時点において、対応するカウンタ値をスキャンし、ゼロの値をサーチすることによって最近ほとんど使用されていないハッシュ・テーブルのエントリを再利用、あるいは削除することができる。表１においては、このステップの結果をイベント５の「再利用」として示している。カウンタＡおよびＢの値には変更がないが、カウンタＣの値は、それに対応するハッシュ・テーブルのエントリがハッシュ・テーブルから削除されたために未定義となる。
【０１６４】
図１０Ｂに示した方法を周期的、かつ規則的に繰り返すことにより、「人気のある」カウンタの値がオーバーフローすることがない。また、値がゼロのカウンタ値によって、最近ほとんど使用されていないエントリが迅速に識別され、キャッシュから容易に削除することができる。カウンタ値は、ハッシュ・テーブルのエントリに対するアクセスが１００万回に上るときでも数ビット内に維持することができる。つまり、図１０Ｂに示した方法は、最近ほとんど使用されていないエントリをリストから迅速かつ効率的に削除する方法を提供する。
【０１６５】
（キャッシュのオペレーション）
好ましい実施例においては、読み出しおよび書き込みのオペレーションをサポートするＡＰＩを介して外部のプログラムがアクセス可能な１ないしは複数のコンピュータ・プログラム内においてキャッシュ８０が実装される。読み出しおよび書き込みオペレーションは、外部のプログラムもしくはプロセスにとって「見ることができる」キャッシュ８０内の唯一の構造であるオープン・ディレクトリ１３０上で実行される。読み出しオペレーションは、キャッシュ内のオブジェクトの発見を希望する外部プログラムによって起動される。書き込みオペレーションは、キャッシュ内へのオブジェクトのストアを希望する外部プログラムによって起動される。
【０１６６】
キャッシュ８０を構成するプログラム内においては、ルックアップ、削除、チェックアウト（請け出し）、およびチェックイン（戻し）と呼ばれるオペレーションがサポートされている。ルックアップ・オペレーションは、キーに基づいてオープン・ディレクトリ内においてオブジェクトをルックアップする。削除オペレーションは、キーに基づいてオープン・ディレクトリからオブジェクトを削除する。チェックアウト・オペレーションは、データの一貫性を保証するように順序立てた方法を使用してディレクトリ・テーブル１１０からブロックのコピーを獲得する。チェックイン・オペレーションは、ブロックのコピー（別のオペレーションによってそれが修正されていることもある）をディレクトリ・テーブル１１０に返す。これとは異なる実施例においては、単一のキャッシュ・ルックアップ・オペレーションが、これらのオペレーションの側面を兼ねる。
【０１６７】
（１．ルックアップ）
別の実施例においては、ルックアップ・オペレーションを使用して、特定の名前によって識別された特定のオブジェクトが、現在のキャッシュ８０内にストアされているか否かを判断する。図９Ａに、ルックアップ・オペレーションの一実施例において実行されるステップのフローチャートを示すが、それにおいては番号９０２を用いてこのオペレーションを包括的に示している。ルックアップ・オペレーションは、クライアント１０ａからの要求メッセージが、特定のオブジェクトをサーバ４０から取り出すことを求めているとき、プロトコル・エンジン７０からキャッシュ８０にコマンドを与えることによって開始される。クライアント１０ａからのこの要求メッセージは、要求しているオブジェクトをその名前によって識別する。
【０１６８】
ワールド・ワイド・ウェブに関してこのプロセスが適用される場合は、その名前がユニフォーム・リソース・ロケータ（ＵＲＬ）になる。ステップ９０４においては、キャッシュ８０がオブジェクトの名前をキー値に変換する。好ましい実施例においては、この変換ステップが図３Ｂに示した態様で実行される。つまり、ＭＤ５一方向ハッシュ関数等のハッシュ関数にオブジェクト名５３を渡す。このハッシュ関数の出力がオブジェクトの名前キー６２になる。オブジェクトの名前キー６２は、１ないしは複数のサブキー６４、６６に分割することができる。
【０１６９】
ステップ９０６においてキャッシュ８０は、要求キー値を用いてオープン・ディレクトリ１３０内をルックアップする。オープン・ディレクトリには、もっとも最近に要求されたオブジェクトがストアされており、したがってクライアントの要求にあったオブジェクトが含まれている可能性がもっとも高いと期待されることから、そこが最初に調べられる。好ましくは、ステップ９０６に、ルックアップ・キーとしてサブキー値の１つの使用を含める。たとえば、このルックアップに１７ビットもしくは１８ビットのサブキー値を使用することができる。
【０１７０】
ステップ９０８においては、キャッシュ８０によって、サブキー値がオープン・ディレクトリ内に見つかったか否かが評価される。サブキー値がオープン・ディレクトリ内に見つかった場合には、ステップ９１０において、キャッシュ８０がストレージ・デバイスの１つからそのオブジェクトを取り出し、そのオブジェクトをクライアントに配信する。この取り出しのサブステップには、ストレージ・デバイス９０ａ〜９０ｎ内の不揮発性ストレージのプール、アリーナ、およびフラグメントにあるオブジェクトの位置に関連して前述したサブステップが含まれる。また配信するサブステップには、そのオブジェクトのデータを含む、クライアントに対するＨＴＴＰ応答の作成、クライアントに対するＨＴＴＰ接続の開設、およびクライアントに対するＨＴＴＰ要求の送信が含まれる。
【０１７１】
サブキー値がオープン・ディレクトリ内に見つからないとき、キャッシュ８０は、ステップ９１２において要求サブキー値を用いてタグ・テーブル１０２内をルックアップする。ステップ９１４においてキャッシュ８０は、そのサブキー値がタグ・テーブル１０２内に見つかったか否かを評価する。一致が見つからなければ、ステップ９１６においてキャッシュ８０は、後述する後の使用のために、一致が得られなかった事実についての情報をストアする。この情報は、タグ・テーブル１０２内にミスが発生したことを示す１ビットとすることができる。
【０１７２】
ステップ９１８においてキャッシュ８０は、そのサブキー値を用いてディレクトリ・テーブル内をルックアップする。ステップ９１４の評価が肯定的であった場合にキャッシュ８０は、タグ・テーブル１０２のエントリ１０６の１つから、要求サブキー値に一致するサブキー値を取り出す。この値は、ディレクトリ・テーブル内において要求キー値をルックアップするためのキーとして使用される。ステップ９２０においてキャッシュ８０は、ディレクトリ・テーブル内に要求キー値が見つかったか否かを評価する。ヒットが生じ、かつステップ９１６においてストアされた情報によってタグ・テーブル内にミスが生じていることが示されている場合、キャッシュ８０は、ステップ９２２において、ディレクトリ・テーブルのヒットに関連する情報を用いてオープン・ディレクトリを更新する。この後、コントロールがステップ９１０に渡され、前述した方法に従ってオブジェクトが獲得され、クライアントに配信される。
【０１７３】
ステップ９２０の評価が否定的である場合は、要求されたオブジェクトはキャッシュ内になく、ステップ９２４に示されるように、キャッシュのミス条件が成立する。ミス条件に応答してキャッシュ８０は、ステップ９２６において、要求されたオブジェクトのソースであるサーバからそのコピーを獲得する。たとえば、ウェブ関連においては、キャッシュ８０が、クライアントの要求に含まれていたＵＲＬに対するＨＴＴＰ接続を開き、オブジェクトをダウンロードする。このオブジェクトは、続いてクライアントに提供されるとともに、後の参照のためにキャッシュ内にストアされる。
【０１７４】
好ましい実施例においては、キー値をパラメータとして受け取る、オブジェクト指向プログラミング言語におけるオブジェクトのメソッドとしてルックアップ・オペレーションが実装される。
【０１７５】
（２．キャッシュのオープン・リード・プロセス）
図９Ｅは、オブジェクト名（たとえばＵＲＬ等）によって識別されるオブジェクトをキャッシュから読み出す好ましいプロセスを示したフローチャートである。好ましい実施例においては、図９Ｅに示したプロセスが「open_read（オープン・リード）」と呼ばれ、キャッシュ８０が有する唯一の外部インターフェースを表す。キャッシュ内のデータのコントロールおよび一貫性を保証するために、外部プログラムに対して、オープン・ディレクトリ１３０を使用ないしは修正するオペレーションへのアクセスだけを許可するほうが有利である。好ましくは、オブジェクト名、およびユーザの特定の要求に関する情報を入力パラメータとして受け取るプログラムもしくはプログラム・オブジェクトとして図９Ｅに示したプロセスを実装する。この読み出しプロセスは、ルックアップ・プロセスの使用によってキャッシュ内に見つかったキーに関連付けされたオブジェクトのコピーを返す。つまりこの読み出しプロセスおよび、それによって起動されあるいは呼び出されたそのほかのプロセスは、図９Ａとの関連から前述したルックアップ・オペレーションに代わるものとなる。
【０１７６】
ステップ９６４においてプロセスは、選択肢のベクトルを請け出し、ベクトル内の選択肢が読み出せるようにする。好ましくは、ステップ９６４に、図８Ｄとの関連からここに述べる、オブジェクト名から導かれたキーをパラメータとして提供するcheckout_read（チェックアウト＿リード）プロセスの起動を包含する。ベクトルの請け出しには、そのベクトルに対するポインタを有するオープン・ディレクトリからブロックを請け出し、またキャッシュからそのブロックへ到達することが含まれる。
【０１７７】
チェックアウト・オペレーションが成功した場合にプロセスは、ステップ９６６において要求情報を使用してベクトル内の選択肢の中から１つの選択肢を選択する。この選択は、選択肢のベクトル１２２に関連して説明した前述の方法に従って行われる。一実施例においては、この選択が別のプログラムまたはプログラム・オブジェクトによって実行され、それによって適切な選択肢が見つけ出されたか否かに応じて成功／失敗の表示が返される。選択が成功すれば、ステップ９６８においてプロセスは選択肢のベクトルを戻す。ステップ９７０においてプロセスは、選択した選択肢によってポイントされるオブジェクトを読み出す。
【０１７８】
ステップ９６４もしくはステップ９６６が失敗するときは、要求されたドキュメントがキャッシュ内に存在しない。したがってプロセスは、ステップ９７２において「ドキュメントなし」エラー・メッセージを、このプロセスの呼び出しを行っているプログラムまたはプロセスに返す。
【０１７９】
（３．キャッシュのオープン・ライト・プロセス）
図９Ｆは、キャッシュ内にオブジェクトを書き込むプロセスを示すフローチャートである。図９Ｅとの関連から説明した前述の読み出しプロセスの場合と同様に、この書き込みプロセスも、好ましくは、キャッシュ内にオブジェクトのストアを必要とする外部プログラムに対してキャッシュ８０が有する唯一のインターフェースである「open_write（オープン＿ライト）」メソッドとして実装する。好ましくは、オブジェクト名、要求情報、および応答情報を入力パラメータとして受け取るプログラムもしくはメソッドとして図９Ｆに示したプロセスを実装する。オブジェクト名はキャッシュ内に書き込まれるオブジェクトを識別する；好ましい実施例においては、このオブジェクト名を、図３Ｂに示したメカニズムを使用してＵＲＬから導かれた名前キー６２とする。
【０１８０】
書き込みプロセスは、クライアント１０ａがオブジェクト５２を要求し、それがキャッシュ８０内に見つからなかったときに開始される。この結果、キャッシュ８０は、そのオブジェクトをストアしているサーバ４０とのＨＴＴＰトランザクションを開き、そこからそのオブジェクトのコピーを獲得する。キャッシュ書き込みプロセスに提供される要求情報は、クライアントから到来したＨＴＴＰ要求から導かれる。応答情報は、オブジェクトのコピーを供給するサーバ４０からキャッシュ８０への応答から導かれる。
【０１８１】
ステップ９７４においてこのプロセスは、選択肢のベクトルを請け出す。このステップには、オブジェクト名に基づくキー値の演算、そのキー値をマップしているオープン・ディレクトリ内のセットおよびブロックのルックアップ、および、そのブロックに対応する選択肢のベクトルがある場合にはそのロケートが含まれる。ベクトルが存在しない場合には、ステップ９８４に示したように、新しいベクトルが作られる。
【０１８２】
ベクトルの請け出しに成功するか、あるいはそれを作成すると、続いてステップ９７６においてプロセスは、要求情報を使用して新しい選択肢レコード１２３ａ〜１２３ｎを現在の選択肢内に定義する。新しい選択肢レコードは、このオブジェクトの位置を参照し、また、要求情報および応答情報のコピーを含んでいる。新しい選択肢は、選択肢のベクトルに追加される。選択肢レコードの複製は許容されている；つまり選択肢のベクトルは、同一の要求情報および応答情報を含む複数の選択肢レコードを包含することができる。現存する選択肢レコードを調べて複製を識別することは、複製の選択肢レコードによって占有されるストレージの増加がほとんどわずかであることから、必要ないと考えられる。
【０１８３】
ステップ９７８においては、前述のステップを使用し、修正したベクトルをキャッシュに戻す。ステップ９８０においては、キー値を使用し、前述した方法に従ってデータ・ストレージ・デバイス９０ａ〜９０ｃの１つにオブジェクトを書き込む。ステップ９８０の間にそのキーが使用中であることがわかると、書き込みオペレーションが失敗する。これにより、キーによって識別される更新中のオブジェクトの上書きが回避される。
【０１８４】
（４．キャッシュの更新プロセス）
図９Ｇは、キャッシュの更新プロセスを示すフローチャートである。この更新プロセスは、選択肢のベクトルを修正し、異なる要求情報または応答情報をストアするために使用される。概して更新プロセスは、キャッシュ８０がクライアント１０ａからの要求に一致するオブジェクト５２を現在ストアしているが、プロトコル・エンジンによってそれが期限切れもしくはすでに有効でないと判断されたとき、プロトコル・エンジン７０によって起動される。この種の状況においては、プロトコル・エンジン７０がオリジナルのオブジェクト５２を提供したサーバ４０とのＨＴＴＰトランザクションを開き、サーバ上でそのオブジェクトの変更がなされているか否かについてサーバに問い合わせるメッセージを送る。このプロセスは、オブジェクト５２の「再更新」と呼ばれている。サーバ４０がこの問い合わせに対して否定的に応答する場合には、サーバから変更がないことを示すヘッダとともに短いＨＴＴＰメッセージが提供され、さらに新しい応答情報が提供される。その場合プロトコル・エンジン７０は、オブジェクト５２に関する新しい応答情報をキャッシュ８０に移すためにキャッシュの更新プロセスを起動する。
【０１８５】
キャッシュ８０内のそのオブジェクト５２の期限日または時刻以降にその変更があり、問い合わせに対する肯定的な応答がサーバ４０からある場合には、更新プロセスは起動されない。その場合サーバ４０は、更新済みのオブジェクト５２のコピーを、新しい期限日およびその他の応答情報とともに返す。一方プロトコル・エンジン７０は、上記に代えて前述したキャッシュの書き込みプロセスおよび作成プロセスを起動し、新しいオブジェクト５２をキャッシュ８０に追加する。
【０１８６】
更新プロセスは、図９Ｇに示したようにオブジェクト名、「古い」識別名、要求情報および応答情報を含む入力パラメータを受け取る。このオブジェクト名は、ＵＲＬもしくはＵＲＬから導かれたキーである。要求情報は、キャッシュ８０からオブジェクト５２を求めるクライアントのＨＴＴＰ要求から、また応答情報はキャッシュから更新済みのコピーをキャッシュが獲得したときの、サーバ４０の応答情報からそれぞれ導かれる。
【０１８７】
「古い」識別名は、要求情報と応答情報のペアを固有識別する値である。好ましい実施例においては、キャッシュにミスが生じた結果としてキャッシュ８０が新しいオブジェクトをキャッシュに書き込むとき、クライアントからの要求情報と、そのオブジェクトのコピーを提供したサーバからの応答情報をペアにする。各ペアには、固有の識別値が与えられる。
【０１８８】
ステップ９８６においてプロセスは、キャッシュからそのオブジェクト名に対応する選択肢のベクトルを請け出す。好ましくはこれが、ここで説明しているcheckout_write（チェックアウト＿ライト）プロセスを起動することによって行われるものとする。これは、オブジェクト名またはＵＲＬを使用したオープン・ディレクトリ、タグ・テーブルおよびディレクトリ・インデクスのオブジェクトのルックアップを含み、その結果、対応する選択肢のベクトルが獲得される。チェックアウト・プロセスがフェイルした場合には、ステップ９９６においてプロセスが適切なエラー・メッセージを返す。
【０１８９】
チェックアウトが成功すると、ステップ９８８においてベクトルのコピーまたはクローンがメイン・メモリ内に作成される。要求／応答識別名の値は、このプロセスに対する入力として受け取った古い識別名の値にそれを整合させることによって、このベクトル内に配置される。それにおいては、古い識別名の値が削除され、それに代えて新しい識別名が同じ場所に書き込まれる。この新しい識別名は、入力としてこのプロセスに提供された新しい要求情報と応答情報を固有に識別する。
【０１９０】
ステップ９９０においては、新しいベクトルがストレージ・デバイス９０ａ〜９０ｃの１つに書き込まれ、ステップ９９２においては新しいベクトルがキャッシュに戻される。これらのステップの実行においては、ベクトルのクローンを完全にストレージ・デバイスに書き込んだ後にそのベクトルを戻すことが望ましい。これは、書き込みオペレーションが成功した後にそのクローン・ベクトルを参照すべくディレクトリ・テーブルが修正されることを保証する。またこれは、古いベクトルへのアクセスを必要とするプロセスもしくはプログラムがあるとき、それを使用可能にすることについても保証する。
【０１９１】
（５．ディレクトリのルックアップ）
図９Ｃは、好ましい実施例のオープン・ディレクトリ１３０内において行われる情報のルックアップのプロセスを示したフローチャートである。図９Ｃのプロセスは、入力パラメータとして名前キー６２のサブキー部分を受け取るプログラム・プロセスまたはメソッドとして実装される。ここで、先行する図示していないステップにおいて、プロトコル・エンジン７０がＵＲＬ等のオブジェクト名を受け取っていることを理解されよう。たとえば、クライアントからキャッシュを動作させているサーバに対して発行されたＨＴＴＰ要求内においてＵＲＬが提供される。プロトコル・エンジン７０は、このオブジェクト名に対してハッシュ関数を適用する。このハッシュ関数は、その結果として、あるいはその出力としてキャッシュ内のセットを識別する名前キーを生じる。
【０１９２】
ステップ９４８においてこのプロセスは、ディレクトリ・インデクスからのサブキーによって識別される１ないしは複数のブロックの請け出しを試みる。ブロックのチェックアウト・ステップは、好ましくはこれにおいて説明しているcheckout_read（チェックアウト＿リード）プロセスの起動を含むものとする。すなわち：
【０１９３】
チェックアウトの試みが失敗状態をもたらしたとき、ステップ９５０においてプロセスは、それを呼び出したプログラムまたはプロセスに対して、入力サブキーに一致するブロックがキャッシュ内に見つからなかったことを示すエラー・メッセージを返す。その後コントロールがステップ９５２に渡され、それにおいてこのプロセスが終了する。
【０１９４】
チェックアウトの試みが成功した場合には、このプロセスを呼び出したプログラムによるブロックのコピーの使用が可能になる。ステップ９５４においては、請け出したブロックを再び戻す。ステップ９５６においてプロセスは、それを呼び出したプログラムに対し、要求されたブロックが見つかったことを示すメッセージを返す。その後ステップ９５２においてこのプロセスが終了する。
【０１９５】
このように、キャッシュのサーチ・オペレーションは、オープン・ディレクトリからキーによって識別されるブロックの請け出しを求める、より基本的なプロセスの呼び出しを伴う。基本的なプロセスによりオープン・ディレクトリ内においてそのブロックが見つからなかったときは、ディレクトリ・インデクスがサーチされる。
【０１９６】
ブロックが見つかったときは、それがクライアントに配信される。たとえば、本発明をワールド・ワイド・ウェブ関連に適用する場合、クライアントに対するＨＴＴＰ接続を開き、ＨＴＴＰトランザクションを使用してデータ・ブロックをそのクライアントに送信することによって、そのデータ・ブロックが配信される。このステップは、トランザクションを開く前にいくつかのデータ・ブロックのバッファリングを伴うこともある。
【０１９７】
（６．キャッシュの削除プロセス）
図９Ｄは、キャッシュからオブジェクトに関連するブロックを削除するプロセスを示したフローチャートである。チェックアウト・オペレーションの場合と同様に、キャッシュの削除プロセスは、入力としてキー値を受け取る。このプロセスは、ステップ９５８〜９６２からなる。これらのステップは、図９Ｃに示したステップ９４８、９５４および９５２のオペレーションと実質的に類似するオペレーションを実行する。しかしながら、キャッシュ内に見つかったブロックの削除を行うためにこのプロセスは、ステップ９６０において、削除フラグをセットし、削除フラグをセットした状態でそのブロックを戻す。チェックイン・プロセスに関連してここで述べているように（図９Ｂのステップ９３８および９４４）、削除フラグがセットされているときは、そのブロックが削除済みとしてマークされることになる。その後、オープン・ディレクトリ内に反映された変更がディレクトリ・インデクスと同期されたとき、このブロックが最終的にディレクトリ・インデクスから削除される。
【０１９８】
（７．チェックアウト・リード・オペレーション）
図８Ｄは、ディレクトリ・テーブル１１０に関連して使用されるcheckout_read（チェックアウト＿リード）オペレーションを示すフローチャートである。このcheckout_read（チェックアウト＿リード）オペレーションは、特定のキーに一致するディレクトリ・テーブル１１０のブロックからコピーを獲得するために使用される。ディレクトリ・テーブル１１０からそのブロックを請け出した後は、そのブロックを請け出したプロセスに限って、それを読み出して使用することが可能、つまりほかのプロセスにはそれができない。その後、別のプロセスがそのブロックを使用できるようにするためには、そのブロックを戻す必要がある。相補的なチェックアウト‐チェックイン（請け出しおよび戻し）のプロセスは、ディレクトリ・テーブルのブロックを修正できるプロセスを１度に１つに限ることを保証するために使用され、このメカニズムは、ディレクトリ・テーブルが常にキャッシュ内のオブジェクトに関する正確な情報をストアしていることを保証するために欠くことができない。つまり、いずれ明らかになろうが、チェックアウト・プロセスおよびチェックイン・プロセスは、特定のオブジェクトに関するキャッシュのサーチを補助する基本的なプロセスである。
【０１９９】
図８Ｄに示されるようにcheckout_read（チェックアウト＿リード）オペレーションは、入力としてキー値を受け取る。好ましい実施例においては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部分になる。
【０２００】
オブジェクト・ストアがメモリおよびディスクのデータ構造の一部を修正しようとしていることから、一貫性のある結果を達成するために、キャッシュ・データ構造のサブセットに対する短期間の相互排他を保証する必要がある。キャッシュ・データ構造は、２５６の仮想「スライス」に分割されており、８ビットのキーによって選択される。各スライスは、関連するｍｕｔｅｘロックを有している。ステップ８３２においてプロセスは、入力キー用のロックを探してそれを獲得する。ロックが獲得できない場合、プロセスは、それが入手可能になるまで短時間の待機を行う。別のトランザクションが、同一のスライスに至るキーに関連付けされた小部分のメモリの状態を修正しているときは、ロックが入手不可能となり得る。
【０２０１】
ロックの獲得後は、別のプロセスによるこの入力キーの使用ができなくなる。ステップ８３４においてプロセスは、ディレクトリ・テーブル１１０のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する。続いてこのプロセスは、ディレクトリ・テーブル１１０のセットに対応するオープン・ディレクトリ１３０のブロック・リスト１３２ａ、１３２ｂのいずれか１つを、入力キーのサブキーの値をブロック・リストの１つに関連付けすることによって見つける。このプロセスは、ステップ８３６においてオープン・ディレクトリ１３０の選択したブロック・リスト内のブロックをスキャンし、入力キーに一致するキーをストアしているブロックを探す。
【０２０２】
一致が見つかるとこのプロセスは、ステップ８３８において、一致したブロックが別のプロセスによって現在、作成中であるか、あるいは壊れているか否かについて評価する。一致したブロックが現在、作成中もしくは壊れている場合には、ステップ８４０において、現在のブロックは使用不可能であることを示すエラー・メッセージをプロトコル・エンジン７０に返す。
【０２０３】
これに対して、一致したブロックが現在、作成中でなく、壊れていなければ、そのブロックを使用することができる。その場合プロセスは、ステップ８４２において読み出しカウンタをインクリメントする。読み出しカウンタは、そのブロックに関連付けされた内部変数であり、そのブロックを読み出しているプロセスもしくはプログラム・オブジェクトのインスタンスの数を示す。この種のプロセスもしくはオブジェクトは、「リーダー」と呼ばれる。ステップ８４４においてプロセスは、そのブロックのコピーを獲得し、呼び出しているプログラムまたはプロセスにそれを返す。
【０２０４】
ステップ８３６のスキャンにおいて一致が見つからないと、このプロセスは、ステップ８４６においてディレクトリ・テーブルのサーチを起動し、ここで詳しく説明しているプロセスを使用してこのキーに一致するディレクトリ・テーブルのセットおよびブロックを探す。このサーチにおいてもキーとの一致が見つからなかったときは、ステップ８４８において、このプロセスから、それを呼び出しているプログラムもしくはプロセスに対し、要求されたオブジェクトがキャッシュ内に存在しない旨を表すエラー・メッセージを返す。このプロセスを呼び出しているプログラムもしくはプロセスは、この種のメッセージに対する具体的な応答を決定するが、ワールド・ワイド・ウェブに関して言えば、一般にプロキシ３０がＨＴＴＰ要求を使用してオブジェクトをストアしているサーバ４０にコンタクトし、要求されているオブジェクトのコピーを獲得する。
【０２０５】
ステップ８４６においてディレクトリ・インデクスをルックアップする間に一致が見つかると、ステップ８５０において対応するブロックをオープン・ディレクトリに追加する。これにおいては、メイン・メモリ内に新しいオープン・ディレクトリ・ブロックを作成し；対応するディレクトリ・インデクスのブロックから情報をコピーすることによってそのブロックを初期化し；さらに、新しいブロックに対する参照を対応するブロック１３２ａ、１３２ｂのリストに追加する。
【０２０６】
（８．チェックアウト・ライト・オペレーション）
図８Ｅは、オープン・ディレクトリ１３０に関連して使用されるcheckout_write（チェックアウト＿ライト）プロセスまたはオペレーションを示すフローチャートである。checkout_write（チェックアウト＿ライト）オペレーションは、このプロセスに渡されたキーに一致するブロックのコピーをオープン・ディレクトリ１３０から獲得し、そのブロックのコンテンツ、またはそのブロックに関連付けされたオブジェクトないしはベクトルを修正または更新するために使用される。checkout_write（チェックアウト＿ライト）を使用してオープン・ディレクトリ１３０からブロックを請け出した後は、別のプロセスがそのブロックまたは、その関連オブジェクトないしはベクトルを修正することができる。その後ブロックは、ここに説明のあるチェックイン・プロセスを使用して戻される。これらのオペレーションを使用して、オープン・ディレクトリに変更がストアされ、続いて規則に従ってそれがディレクトリ・テーブルに伝えられる。
【０２０７】
図８Ｅに示すようにcheckout_write（チェックアウト＿ライト）プロセスは、入力としてキー値を受け取る。好ましい実施例においては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部分になる。ステップ８５４においてこのプロセスは、指定されたキーに係るロックを探して獲得する。ロックが獲得できない場合、プロセスは、それが入手可能になるまで待機する。
【０２０８】
ロックの獲得後は、別のプロセスによるこのキーの使用ができなくなる。ステップ８５６においてプロセスは、ディレクトリ・テーブル１１０のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する。続いてこのプロセスは、ディレクトリ・テーブル１１０のセットに対応するオープン・ディレクトリ１３０のブロック・リスト１３２ａ、１３２ｂのいずれか１つを見つける。ステップ８５８においてこのプロセスは、オープン・ディレクトリ１３０の、選択したブロック・リスト内のブロックをスキャンし、入力キーに一致するキーをストアしているブロックを探す。
【０２０９】
一致が見つかるとこのプロセスは、ステップ８６４において、一致したブロックが別のプロセスによって現在、作成中であるか、あるいは壊れているか否かについて評価する。それに該当する場合には、ステップ８６６において、現在のブロックは使用不可能であることを示すエラー・メッセージをプロトコル・エンジン７０またはキャッシュ８０に返す。一致したブロックが現在、作成中でなく、壊されていなければ、そのブロックを使用することができる。その場合このプロセスは、ステップ８６８において書き込みカウンタをインクリメントする。この書き込みカウンタは、そのブロックに関連付けてストアされる内部変数であり、そのブロックに書き込みを行っているプロセスもしくはプログラム・オブジェクトの数を示す。ステップ８７０においてプロセスは、ブロックのコピーを獲得し、呼び出しているプログラムまたはプロセスにそれを返すとともに、そのコピーに修正中である旨のマークを付する。このマーク付けは、オープン・ディレクトリをディレクトリ・インデクスに同期させるとき、そのブロックに加えられた変更がディレクトリ・インデクス内に反映されることを保証する。
【０２１０】
ステップ８５８のスキャンにおいて一致が見つからないとき、このプロセスはステップ８６０において、ここで詳しく説明しているプロセスを使用したディレクトリ・インデクスのサーチを起動する。このサーチにおいても一致が見つからなかったときは、ステップ８６２において、このプロセスから、それを呼び出しているプログラムもしくはプロセスに対し、要求されたオブジェクトがキャッシュ内に存在しない旨を表すエラー・メッセージを返す。ワールド・ワイド・ウェブに関して言えば、通常、呼び出しているプログラムがＨＴＴＰ要求を使用してそのオブジェクトをストアしている発信サーバにコンタクトし、要求されたオブジェクトのコピーを獲得する。
【０２１１】
ステップ８６０においてディレクトリ・インデクスをルックアップする間に一致が見つかると、ステップ８７４において対応するブロックをオープン・ディレクトリに追加する。これにおいては、メイン・メモリ内に新しいオープン・ディレクトリ・ブロックを作成し；対応するディレクトリ・インデクスのブロックから情報をコピーすることによってそのブロックを初期化し；さらに、新しいブロックに対する参照を対応するブロック１３２ａ、１３２ｂのリストに追加する。その後コントロールがステップ８６８に渡され、それにおいて書き込みカウントがインクリメントされ、ステップ８６８〜８７０との関連で説明したようにこのプロセスが継続される。
【０２１２】
（９．チェックアウト・クリエイト・オペレーション）
図８Ｆは、オープン・ディレクトリ１３０に関連して使用するためにサポートされているcheckout_create（チェックアウト＿クリエイト）オペレーションを示すフローチャートである。checkout_create（チェックアウト＿クリエイト）オペレーションは、キャッシュに追加される新しいオブジェクトに対応する名前キーに関して、オープン・ディレクトリ１３０内に新しいブロックを作成するために使用される。オープン・ディレクトリ１３０内にブロックが作成された後は、ユーザがオープン・ディレクトリ１３０を介してキャッシュからそのオブジェクトを獲得することができる。
【０２１３】
図８Ｆに示されるように、checkout_create（チェックアウト＿クリエイト）プロセスは、入力としてキー値を受け取る。好ましい実施例においては、この入力キー値が、オブジェクト名に対応する名前キー６２のサブキー部分になる。ステップ８７６においてこのプロセスは、指定されたキーに係るロックを探して獲得する。ロックが獲得できない場合、プロセスは、それが入手可能になるまで待機する。
【０２１４】
ロックの獲得後は、別のプロセスによるこのキーの使用ができなくなる。ステップ８７８においてプロセスは、ディレクトリ・テーブル１１０のセット１１０ａ〜１１０ｎのうち、いずれがこのキーに対応するかを決定する。続いてこのプロセスは、入力キーのセット・サブキー・ビットを使用して、ディレクトリ・テーブル１１０のセットに対応するオープン・ディレクトリ１３０のセットを見つける。ステップ８８０においてこのプロセスは、オープン・ディレクトリ１３０の選択したブロック・リスト内のブロックをスキャンし、入力キーに一致するキーをストアしているブロックを探す。
【０２１５】
一致が見つかった場合には、すでに存在しているブロックの作成を試みていることになる。そこでこのプロセスは、ステップ８８２において一致したブロックが削除済みとしてマークされているか、また現在、それの読み出しあるいは書き込みを行っているほかのプロセスがないかを評価する。リーダー・カウンタおよびライター・カウンタの値がともにゼロであれば、ほかのプロセスによるそのブロックの読み出しあるいは書き込みはない。リーダー・カウンタおよびライター・カウンタの値のいずれかがゼロでないとき、あるいは一致したブロックが削除済みとマークされていないとき、そのブロックはすでに現存する有効なブロックであり、それを作成することはできない。その場合、ステップ８８４において、現在のブロックを作成する要求に応じることができない旨を示すエラー・メッセージをプロトコル・エンジン７０またはキャッシュ８０に返す。
【０２１６】
一致したブロックが削除されており、それにアクセスしているライターないしはリーダーがまったくない場合、プロセスは、一致している、以前作成されたブロックを作成し、初期化することによって、事実上、新しいブロックを作成することができる。そこでこのプロセスは、ステップ８８６において一致しているブロックをクリアする。ステップ８８８においてこのプロセスは、特定のフィールドにゼロを書き込み、ブロックのキー値を現在のキーにセットすることによってクリアしたブロックを初期化する。ブロック８９０においてプロセスは、そのブロックに関連付けされているライター・カウンタをインクリメントし、そのブロックを作成済みとしてマークする。ステップ８９２においてプロセスは、それを呼び出しているプロセスまたはプログラム・オブジェクトにそのブロックのコピーを返し、そのブロックを修正中としてマークする。
【０２１７】
ステップ８８０のスキャンにおいて一致が見つからなかった場合は、現在、オープン・ディレクトリ１３０内に一致するブロックが存在していない。その場合このプロセスは、ステップ８９４において、ここで詳しく説明しているプロセスを使用してディレクトリ・インデクスのサーチを行う。そのサーチにより一致が見つかると、ステップ８９６においてプロセスは、それを呼び出しているプログラムまたはプロセスに対し、作成しようとしているブロックがキャッシュ内にすでに存在し、削除することができない旨を示すエラー・メッセージを返す。
【０２１８】
一致が見つからなかったときは、キャッシュ全体にわたり、一致するブロックがまったく存在しないことになる。そこでこのプロセスは、ステップ８９８において、新しいオープン・ディレクトリのブロックを作成し、そのブロックに対する参照を、ステップ８７８において演算したセット値に関連付けされたリスト１３２ａ、１３２ｂに追加する。その後コントロールがステップ８９０に渡され、ステップ８９０〜８９２に関連して前述した説明のとおりにステップが継続される。
【０２１９】
（１０．チェックイン・プロセス）
図９Ｂにブロックのチェックイン・プロセスのフローチャートを示す。キャッシュ８０は、ブロックの読み出し、修正、または削除を行った後、図９Ｂに示したプロセスを実行してそのブロックをオープン・ディレクトリ１３０に戻す。一実施例においては図９Ｂに示したプロセスが、ブロックの識別名をパラメータとして受け取るプログラム・プロセスまたはオブジェクトとして実装される。このキーが、請け出したブロック内に存在することから、引数としてこのキーを渡す必要はない。
【０２２０】
このプロセスは、ステップ９３０においてブロックに関連付けされたキーに対応するロックの獲得を試みる。入手可能なロックが存在しないときは、プロセスが待機ループに入り、ロックが入手可能になるまでの待機を設定する。ロックが入手できたとき、ステップ９３２においてこのプロセスは、そのブロックが修正され、それを戻そうとしているか否かを評価する。それに該当するときは、ステップ９３４においてそのブロック用のライター・カウントをデクリメントし、プロセスがそのブロックに対する書き込みを完了したことを示す。
【０２２１】
ステップ９３６においてプロセスは、チェックイン・プロセスの実行が成功したか否かを評価する。このとき成功であると評価されるときは、続いてステップ９４２においてプロセスは、現在のブロック内の情報を、オープン・ディレクトリ内の対応するオリジナルのブロックにコピーする。このようにして、チェックアウト・プロセスにおいて獲得したブロックのコピーを修正するプロセスによって実行された変更を用いてオープン・ディレクトリが更新される。その後、あるいはステップ９３６の評価が否定であった場合に、プロセスは削除チェックイン・フラグがセットされているか否かを評価する。この削除チェックイン・フラグは、チェックインの後にそのブロックを削除することを示す。削除フラグは、チェックイン・オペレーションに対する引数である。このフラグがセットされているとき、ステップ９４４においてプロセスは、そのブロックを削除済みとしてマークを付ける。このプロセスは、ステップ９４０において終了する。
【０２２２】
ステップ９３２の評価が否定であった場合には、このブロックは修正されていない。その結果、可能性のある唯一の状態は、このブロックが読み出されたこととなる。したがって、ステップ９４６においてリーダー・カウントをデクリメントする。
【０２２３】
（方法の実装）
好ましい実施例においては、ここで説明している方法が図１１に示すタイプの汎用プログラマブル・ディジタル・コンピュータ・システムを使用して実行される。これらの方法のそれぞれは、いくつかの異なるやり方で実装することができる。たとえば、シングル・プロセス、またはマルチスレッド、マルチプロセッシング・システムにおいて、手続き型コンピュータ・プログラム、オブジェクト指向プログラム、プロセス、アプレット等の形式によりこれらの方法を実装することができる。
【０２２４】
好ましい実施例においては、プロセスのそれぞれが独立かつ再入可能であり、したがってキャッシュが動作しているときは、各プロセスのインスタンスを複数回にわたって作ることができる。たとえば、ガーベジ・コレクション・プロセスは、割り当ておよび書き込みプロセスと同時に、かつ独立させて実行される。
【０２２５】
（ハードウエア概要）
図１１は、本発明の実施例が実装されると考えられるコンピュータ・システム１１００を示したブロック図である。コンピュータ・システム１１００は、バス１１０２もしくはその他の、情報を伝達するためのメカニズム、およびバス１１０２に接続された、情報を処理するためのプロセッサ１１０４を備える。またコンピュータ・システム１１００においては、ランダム・アクセス・メモリ（ＲＡＭ）もしくはその他の動的ストレージ・デバイス等とするメイン・メモリ１１０６がバス１１０２に接続されており、そこには情報およびプロセッサ１１０４によって実行されるインストラクションがストアされている。メイン・メモリ１１０６は、プロセッサ１１０４によるインストラクションの実行間に、一時変数もしくはその他の中間情報をストアするために使用されることもある。さらにコンピュータ・システム１１００には、情報およびプロセッサ１１０４用の命令をストアするための読み出し専用メモリ（ＲＯＭ）１１０８もしくはその他の静的ストレージ・デバイスが備わり、バス１１０２に接続されている。ストレージ・デバイス１１１０は、磁気ディスクまたは光ディスク等であり、情報および命令をストアするために備えられ、バス１１０２に接続されている。
【０２２６】
コンピュータ・システム１１００には、バス１１０２を介して陰極線管（ＣＲＴ）等の、コンピュータのユーザに情報を表示するためのディスプレイ１１１２が接続されることもある。英数字キーおよびその他のキーを含む入力デバイス１１１４は、バス１１０２に接続されて、プロセッサ１１０４に情報およびコマンドの選択を伝える。別のタイプのユーザ入力デバイスとして、マウス、トラックボール、あるいはカーソル移動キーといったカーソル・コントロール１１１６も備わっており、方向情報およびコマンドの選択をプロセッサ１１０４に伝え、またディスプレイ１１１２上のカーソルの動きをコントロールするために使用される。この入力デバイスは、通常、第１の軸（たとえばｘ軸）および第２の軸（たとえばｙ軸）を含む２軸に自由度を有し、それによりこのデバイスを用いた平面内のポジションの指定が可能になる。
【０２２７】
本発明は、情報オブジェクトをキャッシュするためのコンピュータ・システム１１００の使用に関する。本発明の一実施例によれば、情報オブジェクトのキャッシが、メイン・メモリ１１０６内に収められている１ないしは複数の命令からなる１ないしは複数のシーケンスを実行するプロセッサ１１０４に応答してコンピュータ・システム１１００によって提供される。この種の命令は、ストレージ・デバイス１１１０等の別のコンピュータ読み取り可能な媒体から、メイン・メモリ１１０６内に読み込むことができる。メイン・メモリ１１０６内に含まれる命令のシーケンスの実行によってプロセッサ１１０４は、ここに説明したプロセスのステップを実行する。別の実施例においては、ソフトウエア命令に代えて、あるいはそれとの組み合わせによりハードワイヤード回路が使用され、本発明が実装されることもある。つまり、本発明の実施は、いかなる特定のハードウエア回路およびソフトウエアの組み合わせにも限定されない。
【０２２８】
「コンピュータ読み取り可能な媒体」という用語は、ここで用いる限り、実行のためのプロセッサ１１０４へのインストラクションの提供に関与する任意の媒体を指す。この種の媒体は各種の形式をとることがあり、限定する意図ではないが、それには不揮発性媒体、揮発性媒体、伝送媒体が含まれる。不揮発性媒体には、たとえば、ストレージ・デバイス１１１０等の光または磁気ディスクが含まれる。揮発性媒体には、メイン・メモリ１１０６等の動的メモリが含まれる。伝送媒体には、同軸ケーブル、銅線ワイヤおよび光ファイバが含まれ、バス１１０２を構成するワイヤもこれに含まれる。また伝送媒体は、音波または光の形式をとることも可能であり、たとえば電波および赤外線データ通信の間にそれが生成される。
【０２２９】
コンピュータ読み取り可能な媒体の一般的な形としては、たとえばフロッピーディスク、フレキシブル・ディスク、ハードディスク、磁気テープ、もしくはその他の磁気媒体、ＣＤ−ＲＯＭ、もしくはその他の光媒体、パンチカード、紙テープ、もしくはその他の鑽孔パターンを伴う物理媒体、ＲＡＭ、ＰＲＯＭ、およびＥＰＲＯＭ、フラッシュＥＰＲＯＭ、その他のメモリ・チップもしくはカートリッジ、後述する搬送波、またはコンピュータが読み取ることができるこのほかのあらゆる媒体が挙げられる。
【０２３０】
各種形式のコンピュータ読み取り可能な媒体が関連して、実行のための１ないしは複数の命令からなる１ないしは複数のシーケンスをプロセッサ１１０４に運ぶことができる。たとえば、当初命令がリモート・コンピュータの磁気ディスク上に乗っているとする。リモート・コンピュータは、この命令をその動的メモリにロードし、さらにモデムを使用してその命令を、電話回線を介して送ることができる。コンピュータ・システム１１００の近傍にあるモデムは、電話回線上でそのデータを受け取り、赤外線送信機を使用してそのデータを赤外線信号に変換することができる。バス１１０２に接続された赤外線検出器は、赤外線信号内に含まれて運ばれてきたデータを受信し、データをバス１１０２に渡すことができる。バス１１０２は、データをメイン・メモリ１１０６まで運び、そこからプロセッサ１１０４が命令を取り出して実行する。メイン・メモリ１１０６によって受け取られたインストラクションは、選択肢の１つとして、プロセッサ１１０４による実行の前もしくはその後に、ストレージ・デバイス１１１０にストアしてもよい。
【０２３１】
コンピュータ・システム１１００は、バス１１０２に接続された通信インターフェース１１１８を包含している。通信インターフェース１１１８は、ローカル・ネットワーク１１２２に接続された通信リンク１１２０を結合する双方向データ通信を提供する。たとえば通信インターフェース１１１８を統合ディジタル通信サービス網（ＩＳＤＮ）カードまたはモデムとし、対応するタイプの電話回線に対するデータ通信接続を提供することが考えられる。別の例において、通信インターフェース１１１８をローカル・エリア・ネットワーク（ＬＡＮ）カードとして、互換性のあるＬＡＮに対するデータ通信接続を提供してもよい。ワイヤレス・リンクの実装も考えられる。これらの実装のいずれにおいても、通信インターフェース１１１８は、各種タイプの情報を表すディジタル・データ・ストリームを搬送する電気的、電磁気的あるいは光学的信号を送受する。
【０２３２】
ネットワーク・リンク１１２０は、通常、１ないしは複数のネットワークを介してほかのデータ・デバイスに対するデータ通信を提供する。たとえばネットワーク・リンク１１２０が、ローカル・ネットワーク１１２２を介してホスト・コンピュータ１１２４への接続、あるいはインターネット・サービス・プロバイダ（ＩＳＰ）１１２６への接続の接続を提供することがある。一方ＩＳＰ１１２６は、現在一般的に「インターネット」１１２８と呼ばれているワールド・ワイドなパケット・データ通信を介したデータ通信サービスを提供する。ローカル・ネットワーク１１２２およびインターネット１１２８は、いずれもディジタル・データ・ストリームを搬送する電気的、電磁気的、あるいは光学的信号を使用する。コンピュータ・システム１１００へ、またそこからディジタル・データを運ぶ、これらの各種ネットワークを介した信号およびネットワーク・リンク１１２０上の信号ならびに通信インターフェース１１１８を介した信号は、情報を伝達する搬送波の形式の例である。
【０２３３】
コンピュータ・システム１１００は、プログラム・コードを含めて、ネットワーク（１ないしは複数）、ネットワーク・リンク１１２０、および通信インターフェース１１１８を介してメッセージを送りデータを受け取ることができる。インターネットの例においては、サーバ１１３０が、要求されたアプリケーション・プログラム用のコードをインターネット１１２８、ＩＳＰ １１２６、ローカル・ネットワーク１１２２および通信インターフェース１１１８を介して送信することが考えられる。本発明によれば、この種のダウンロードされたアプリケーションの１つが、ここで説明している情報オブジェクトのキャッシュを提供する。
【０２３４】
受信したコードは、プロセッサ１１０４によってその受信時に実行されることもあれば、それとともに、あるいはそれに代えて、後の実行のためにストレージ・デバイス１１１０もしくは別の不揮発性ストレージにストアされることもある。このようにして１１００は、搬送波の形式においてアプリケーション・コードを獲得することができる。
【０２３５】
以上のとおり、従来のアプローチに対して明確な利点を有するオブジェクト・キャッシュについて説明してきた。特にここでは、オブジェクトのストア・オペレーションについて遅れ時間が小さく、高いスループットが得られ、かつ多数の同時オペレーションが得られるという意味において高いパフォーマンスを提供するオブジェクト・キャッシュについて説明している。ここに説明されているメカニズムは、テラバイト台の情報、およびその成長レートに比例して増える数十億のオブジェクトをストアする大きなオブジェクト・キャッシュに適用することができる。
【０２３６】
このオブジェクト・キャッシュは、メモリのストレージ空間を効率的に利用することから、高価な半導体メモリが有効にかつ効果的に使用される。またこのキャッシュは、ディスク・ストレージ空間の効率性をもたらし、その結果、オブジェクト・ストアの有限なディスク容量内に多数のインターネット・オブジェクトのレプリカをストアすることができる。このキャッシュはエイリアス・フリーであり、名前はそれぞれ異なるが同一のオブジェクト・コンテンツを有する複数のオブジェクトもしくはオブジェクトのバリアントは、オブジェクトのコンテンツを１回だけキャッシュし、異なる名前の間においてそれを共有する。
【０２３７】
ここに説明したキャッシュは、マルチメディアの多様性に関するサポートを有し、数百バイトからメガバイトに至る６桁にわたるサイズ範囲で多数のタイプの多様なマルチメディア・オブジェクトを効率的にサポートする。このキャッシュは、高速かつ用法を意識したガーベジ・コレクションを備え、有用性の低いオブジェクトをオブジェクト・ストアから効率的に削除し、新しいオブジェクトのためのスペースを確保する。またこのキャッシュは、データの一貫性を特徴とし、プログラム上のエラーおよびハードウエアの障害によりデータの信頼性を失うことがない。
【０２３８】
このキャッシュは、高速リスタートが可能であり、時間を要するデータベースまたはファイル・システムのチェック・オペレーションを必要とすることなく、リスタート後数秒内にオブジェクト・キャッシュが要求に対するサービスを開始することができる。キャッシュは、ストリーミングＩ／Ｏを使用しているため、大きなオブジェクト全体をメモリ内にステージすることなく、オブジェクト・ストアから遅いクライアントに、効率的にパイプラインさせることができる。このキャッシュはまた、コンテンツ・ネゴシエーションのサポートを有し、プロキシ・キャッシュは、クライアントのブラウザ、言語、またはその他のクライアントの要求の属性に向けられた、同一ＵＲＬを有するオブジェクトのバリアントを効率的かつ柔軟にストアすることができる。このキャッシュは汎用であり、オブジェクト・ストアのインターフェースは、将来的なメディア・タイプおよびプロトコルに適合できる充分な柔軟性を有している。
【０２３９】
これらの利点ならびに特性は、この明細書における技術的説明の特徴として考えるべきである；しかしながら、この種の利点ならびに特性が、本発明の一部を構成する必要はなく、またそれがこの明細書に述べる特許請求の範囲のいずれかによって求められる必要もない。
【０２４０】
以上、この明細書においては、具体的な実施例を参照し、かつ特定の目的ならびに利点を参照して本発明を説明した。しかしながら、本発明から逸脱することなく、各種の変更がそれに加え得ることは明らかである。したがって、この明細書の説明および図面は、限定を意味するものではなく例示のみを提供するものと考えるべきである。
【図面の簡単な説明】
以下、本発明を添付図面に示した例により説明するが、これに限定する意図はなく、また図面においては、類似の要素に類似の参照番号を使用している。
【図１】図１は、クライアント／サーバ関係を示すブロック図である。
【図２】図２は、トラフィック・サーバのブロック図である。
【図３Ａ】図３Ａは、オブジェクトをキーに変換するステップを示すブロック図である。
【図３Ｂ】図３Ｂは、オブジェクト名をキーに変換するステップを示すブロック図である。
【図４Ａ】図４Ａは、キャッシュのブロック図である。
【図４Ｂ】図４Ｂは、「選択肢のベクトル」のためのストレージ・メカニズムを示すブロック図である。
【図４Ｃ】図４Ｃは、マルチセグメント・ディレクトリ・テーブルのブロック図である。
【図５】図５は、データ・フラグメントに関連するポインタのブロック図である。
【図６】図６は、ストレージ・デバイスおよびそのコンテンツを示すブロック図である。
【図７】図７は、プールの構成を示すブロック図である。
【図８Ａ】図８Ａは、ガーベジ・コレクションのプロセスを示すフローチャートである。
【図８Ｂ】図８Ｂは、ストレージ・デバイスに情報を書き込むプロセスを示すフローチャートである。
【図８Ｃ】図８Ｃは、同期化のプロセスを示すフローチャートである。
【図８Ｄ】図８Ｄは、「checkout_read」プロセスを示すフローチャートである。
【図８Ｅ】図８Ｅは、「checkout_write」プロセスを示すフローチャートである。
【図８Ｆ】図８Ｆは、「checkout_create」プロセスを示すフローチャートである。
【図９Ａ】 図９Ａは、キャッシュのルックアップ・プロセスを示すフローチャートである。
【図９Ｂ】 図９Ｂは、「checkin」プロセスを示すフローチャートである。
【図９Ｃ】 図９Ｃは、キャッシュのルックアップ・プロセスを示すフローチャートである。
【図９Ｄ】 図９Ｄは、キャッシュの削除プロセスを示すフローチャートである。
【図９Ｅ】 図９Ｅは、キャッシュの読み出しプロセスを示すフローチャートである。
【図９Ｆ】 図９Ｆは、キャッシュの書き込みプロセスを示すフローチャートである。
【図９Ｇ】 図９Ｇは、キャッシュの更新プロセスを示すフローチャートである。
【図１０Ａ】 図１０Ａは、ストレージ・デバイス内におけるオブジェクトの書き込みおよび割り当てを行うプロセスを示すフローチャートである。
【図１０Ｂ】 図１０Ｂは、スケーリングされたカウンタ更新のプロセスを示すフローチャートである。
【図１１】 図１１は、本発明のインプリメンテーションに使用できるコンピュータ・システムのブロック図である。
【図１２】 図１２は、オブジェクトの再更新のプロセスを示すフローチャートである。

Claims (22)

1. 情報オブジェクトに関連付けられたキー値によって識別される情報オブジェクトのためのキャッシュから情報オブジェクトを配信する方法において、前記キャッシュは、第１のサブキー値のセットを用いて前記情報オブジェクトをインデクス付けするタグ・テーブルを備え、ここで、前記第１のサブキー値のセット内の各サブキー値が、対応するキー値の一部であり、ディレクトリ・テーブルが、前記タグ・テーブル内の前記第１のサブキー値のセットへインデクス付けされると共にデータ・ストレージ・エリアへの参照を有する複数のブロックを備え、前記方法が、
   （Ａ）要求された情報オブジェクトを識別する名前及びその他の所定情報を含むリクエストを受け取るステップと、
   （Ｂ）前記要求された情報オブジェクトのために、前記名前に所定のハッシュ関数を適用することにより、複数のサブキーを備えた固定サイズのキー値を計算するステップであって、前記複数のサブキーにおける各サブキーが、前記固定サイズのキー値の一部であるものと、
   （Ｃ）前記タグ・テーブル及び前記複数のサブキーをルックアップキーとして用いて、ディレクトリ・テーブル内の前記要求された情報オブジェクトの一致ブロックをルックアップするステップと、
   （Ｄ）前記ディレクトリ・テーブル内の前記一致ブロックに含まれる参照を用いて、前記データ・ストレージ・エリアから前記要求された情報オブジェクトのコピーを取り出すステップと、
   を備えた方法。
2. 請求項１に記載の方法において、更に、
   前記その他の所定情報に基づいて、前記要求された情報オブジェクトの複数のバージョンの前記キャッシュ内のリストから、前記要求された情報オブジェクトのバージョンを選択するステップと、
   前記選択されたバージョンに関連付けられて前記リストにストアされた前記サブキーからなるオブジェクトキーに基づいて、前記キャッシュ内の前記要求された情報オブジェクトの格納場所を特定するステップと、
   前記格納場所から前記要求された情報オブジェクトを取り出すステップと、
   前記要求された情報オブジェクトを前記クライアントへ配信するステップと、
   を備えた方法。
3. 請求項１に記載の方法において、更に、前記情報オブジェクトを、大容量ストレージ・デバイスに連続的にストアするステップを備えた方法。
4. 請求項３に記載の方法において、更に、前記各情報オブジェクトを、前記大容量ストレージ・デバイスの連続したプールにストアするステップを備えた方法。
5. 請求項４に記載の方法において、更に、前記各情報オブジェクトを、前記連続したプールにおける複数のアリーナの１つにストアするステップを備えた方法。
6. 請求項５に記載の方法において、更に、前記各情報オブジェクトを、前記複数のアリーナから割り当てられた１又は複数のフラグメントにストアするステップを備えた方法。
7. 情報オブジェクトを備えた前記フラグメントが、前のフラグメントキーからリンクされている請求項６に記載の方法。
8. 請求項２に記載の方法において、更に、
   前記要求された情報オブジェクトの前記複数のバージョンのそれぞれに連続して前記リストをストアするステップと、
   前記各ブロックにおいて、前記要求された情報オブジェクトのサイズ値をそのブロックに関連付けてストアするステップであって、前記サイズ値が前記リスト及び前記情報オブジェクトの前記複数のバージョンの格納サイズを示すものと、
   を備え、ステップ（Ｄ）において、前記リスト及び前記複数のバージョンを同時に読み出すステップを備えた方法。
9. 請求項５に記載の方法において、更に、書き込み集成バッファに異なる速度のストリーミング・データ転送を統合するステップを備えた方法。
10. 請求項３に記載の方法において、前記情報オブジェクトをストアするステップは、別の情報オブジェクトに関してステップ（Ａ）〜（Ｄ）を実行するのと並行して、前記情報オブジェクトを、前記大容量ストレージ・デバイスの連続した使用可能なストレージ空間内に書き込むステップを備えた方法。
11. 請求項１に記載の方法において、
    前記タグ・テーブルは、第２のサブキーのセットにより前記第１のサブキーのセットをインデクス付けし、ここで、前記第２のサブキーのセットの各サブキーが、対応するキー値の一部であり、
    前記複数のサブキーが、第１のサブキー及び第２のサブキーを含み、
    前記方法が、前記タグ・テーブルが前記第２のサブキーを備えるか否かを判断するための前記タグ・テーブルを調べるステップを実行することにより、キャッシュ・ヒットを判断するステップを含む方法。
12. 情報オブジェクトをキャッシングするための１又は複数の命令シーケンスを備えたコンピュータ読み取り可能な記録媒体であって、１又は複数のプロセッサに以下の方法の各手順を実行させるためのプログラムを記録した記録媒体。
    情報オブジェクトに関連付けられたキー値によって識別される情報オブジェクトのためのキャッシュから情報オブジェクトを配信する方法であって、前記キャッシュは、第１のサブキー値のセットを用いて前記情報オブジェクトをインデクス付けするタグ・テーブルを備え、ここで、前記第１のサブキー値のセット内の各サブキー値が、対応するキー値の一部であり、ディレクトリ・テーブルが、前記タグ・テーブル内の前記第１のサブキー値のセットへインデクス付けされると共にデータ・ストレージ・エリアへの参照を有する複数のブロックを備え、前記方法が、
    （Ａ）要求された情報オブジェクトを識別する名前及びその他の所定情報を含むリクエストを受け取るステップと、
    （Ｂ）前記要求された情報オブジェクトのために、前記名前に所定のハッシュ関数を適用することにより、複数のサブキーを備えた固定サイズのキー値を計算するステップであって、前記複数のサブキーにおける各サブキーが、前記固定サイズのキー値の一部であるものと、
    （Ｃ）前記タグ・テーブル及び前記複数のサブキーをルックアップキーとして用いて、ディレクトリ・テーブル内の前記要求された情報オブジェクトの一致ブロックをルックアップするステップと、
    （Ｄ）前記ディレクトリ・テーブル内の前記一致ブロックに含まれる参照を用いて、前記データ・ストレージ・エリアから前記要求された情報オブジェクトのコピーを取り出すステップと、を備える。
13. 請求項１２に記載のコンピュータ読み取り可能な記録媒体において、更に、
    前記その他の所定情報に基づいて、前記要求された情報オブジェクトの複数のバージョンの前記キャッシュ内のリストから、前記要求された情報オブジェクトのバージョンを選択するステップと、
    前記選択されたバージョンに関連付けられて前記リストに格納された前記サブキーからなるオブジェクトキーに基づいて、前記キャッシュ内の前記要求された情報オブジェクトの格納場所を特定するステップと、
    前記格納場所から前記要求された情報オブジェクトを取り出すステップと、
    前記要求された情報オブジェクトを前記クライアントへ配信するステップと、
    を前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
14. 請求項１２に記載のコンピュータ読み取り可能な記録媒体において、更に、前記情報オブジェクトを、大容量ストレージ・デバイスに連続的にストアするステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
15. 請求項１４に記載のコンピュータ読み取り可能な記録媒体において、更に、前記各情報オブジェクトを、前記大容量ストレージ・デバイスの連続したプールにストアするステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
16. 請求項１５に記載のコンピュータ読み取り可能な記録媒体において、更に、前記各情報オブジェクトを、前記連続したプールにおける複数のアリーナの１つにストアするステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
17. 請求項１６に記載のコンピュータ読み取り可能な記録媒体において、更に、前記各情報オブジェクトを、前記複数のアリーナから割り当てられた１又は複数のフラグメントにストアするステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
18. 情報オブジェクトを備えた前記フラグメントが、前のフラグメントキーからリンクされている請求項１７に記載のコンピュータ読み取り可能な記録媒体。
19. 請求項１３に記載のコンピュータ読み取り可能な記録媒体において、更に、
    前記要求された情報オブジェクトの前記複数のバージョンのそれぞれに連続して前記リストをストアするステップと、
    前記各ブロックにおいて、前記要求された情報オブジェクトのサイズ値をそのブロックに関連付けてストアするステップであって、前記サイズ値が前記リスト及び前記情報オブジェクトの前記複数のバージョンの格納サイズを示すものと、
    を備え、ステップ（Ｄ）において、前記リスト及び前記複数のバージョンを同時に読み出すステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
20. 請求項１６に記載のコンピュータ読み取り可能な記録媒体において、更に、書き込み集成バッファに異なる速度のストリーミング・データ転送を統合するステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
21. 請求項１４に記載のコンピュータ読み取り可能な記録媒体において、前記情報オブジェクトをストアするステップは、別の情報オブジェクトに関してステップ（Ａ）〜（Ｄ）を実行するのと並行して、前記情報オブジェクトを、前記大容量ストレージ・デバイスの連続した使用可能なストレージ空間内に書き込むステップを前記１又は複数のプロセッサに実行させるためのプログラムを記録した記録媒体。
22. 請求項１１に記載の方法において、キャッシュ・ヒットを判断する前記ステップが、更に、前記第１のサブキーが前記第２のサブキーにインデックス化されているか否かを判断するステップを含む方法。

Images