JP2006511876A - トランスペアレントなネットワークのエッジ・データ・キャッシュ - Google Patents

Abstract

ローカル・アプリケーションによって実行される照会に基づいて、データを動的にキャッシュに入れるためのシステム（１００）、装置（２００）、及び方法（３００）が提供され、ここで、このシステムは、完全なデータベース（１０１）を有する遠隔サーバ（１０８）と、該完全なデータベースのサブセットを含み、該遠隔サーバと信号通信状態にあるエッジ・サーバ（１０９）上のローカル・データベース（１０４）と、該完全なデータベースからの結果をキャッシュに入れ、局所的に生成されたデータを受信し、該ローカル・データベースと遠隔データベースとの間のデータの整合性を確保しながら、使用可能な格納要件に基づいてキャッシュ（６００）のコンテンツを調整するための、該エッジ・サーバ上の該ローカル・データベース内にある共有テーブル（５０３、６０３）とを含む。この装置は、照会エバリュエータ（２０４）と、全てが該照会エバリュエータと信号通信状態にある、キャッシュ索引（２０６）と、キャッシュ・リポジトリ（２０８）と、リソース・マネージャ（２０９）と、包含関係チェッカ（２０７）と、照会パーサ（２０５）と、整合性マネージャ（２１０）とを含むエッジ・データ・キャッシュ（２０２）を含み、ローカル・サーバ（１０９、１１０）が少なくとも１つの遠隔サーバ（１０８）用のデータベース照会（４００）に応じる方法は、該遠隔サーバの従前のデータベース照会の結果（４１２）を動的にキャッシュに入れ、ローカル・データベースを該ローカル・サーバと関連付け、複数のキャッシュ結果を該ローカル・データベース内の共有テーブル（５０３）に格納し、該ローカル・サーバを用いて新しいデータベース照会（４１０）に応じる際に複数のキャッシュ結果を使用する段階を含む。

Description

本開示は、分散ネットワーク上でデータベースをキャッシュに入れること向けられる。

分散ウェブ・アプリケーションの普及により、遠隔データベース・サーバにアプリケーションを照会する頻度が増加している。こうした照会の性能を改善し、データ可用性を高めるために、こうしたアプリケーションは、ローカル・データベース・キャッシュを用いることができる。例えば、コンテンツ分散ネットワーク内のエッジ・サーバは、データ・アクセスをスピードアップし、ネットワーク・エッジにおいて動的なウェブコンテンツをより迅速に生成するために、近くのデータベース・キャッシュを用いることができる。

エッジ・サーバ上でデータをキャッシュに入れるための典型的な技術は、（ｉ）ローカル・マシン上でのデータベース全体又は該データベースの明示的部分の明示的複製、或いは（ｉｉ）従前の照会応答をキャッシュに入れること及び前にキャッシュに入れられた応答に対する新しい照会ステートメントの完全一致、のいずれかに依存している。複製手法において、キャッシュのコンテンツは、データベース・テーブルのどの部分をエッジ・ノード上で複製すべきかを判断しなければならない管理者によって、明示的に特定される。キャッシュ・コンテンツが、テーブル名又は「実体化ビュー」定義として特定されると、データが、起点サーバからエッジ・キャッシュにコピーされる。

照会応答キャッシュ手法において、アプリケーション照会の応答を用いて、データがキャッシュに動的に取り込まれる。キャッシュ内のデータは、各々の応答が、該応答を生成した照会ステートメントでタグ付けされた状態で、照会応答リストによって記載される。応答を使用し、一般的には文字列の比較によって、その照会がキャッシュに入れられた応答に対応する照会文字列と一致する場合に限り、次の照会に応答させる。照会応答キャッシュは、データを動的にキャッシュに入れることによって管理者制御に対する必要性を排除するが、データを別個の領域、すなわち照会応答ごとに１つの領域に非効率的に格納するというものである。多くの照会応答において同じ基本データを複製できるため、このことにより、大きなスペース・オーバーヘッドがもたらされる。これは、多くの場合、一般的に、基礎となるデータベースの重要な部分及び共通部分を含む照会応答が重複しているためである。さらに、キャッシュに入れられた照会応答は、同じ照会のまさにその再実行要求に応じるためだけに用いられ、該応答に含めることができる他の照会には応じないので、この手法の性能利点が制限されたものになる。例えば、３０歳未満の全従業員の社会保障番号を見つけ出すために最初の照会が与えられる。ＳＱＬステートメントは、
ＳＥＬＥＣＴ ｅｍｐｌｏｙｅｅ．ｓｓｎ ＦＲＯＭ ｅｍｐｌｏｙｅｅ ＷＨＥＲＥ ｅｍｐｌｏｙｅｅ．ａｇｅ＜３０
となる。

この照会に対する応答がキャッシュに入れられ、キャッシュが、２５歳未満の全従業員の社会保障番号を見つけ出すために新しい照会を受け取ると仮定すると、そのＳＱＬステートンメントは、
ＳＥＬＥＣＴ ｅｍｐｌｏｙｅｅ．ｓｓｎ ＦＲＯＭ ｅｍｐｌｏｙｅｅ ＷＨＥＲＥ ｅｍｐｌｏｙｅｅ．ａｇｅ＜２５
となる。

２５歳未満の全従業員は、３０歳未満でもあるので、新しい照会の応答は、第１の応答内に含まれるが、完全一致検索に基づいた照会応答キャッシュは、該キャッシュからの該照会を処理することができない。

手短に言えば、明示的な管理者定義のデータ・キャッシュは、手動の介入を必要とし、該管理者が、各エッジ・サーバ上の作業負荷及びリソースについての詳細な知識を有することを想定している。照会応答キャッシュは、管理者のオーバーヘッドを排除するが、限定された有効性が限定され、スペース・オーバーヘッドが大きくなる。さらに、整合性の管理は、キャッシュに入れられたデータの表示と起点サーバ内の基本データとの間の不一致のために複雑なものとなる。整合性の制御は、一般に、いずれかの基本テーブルが変わるときに全ての照会応答を無効にするか、又は複雑な依存グラフを維持するかのいずれかを必要とする。

したがって、作業負荷の変更又はキャッシュが常駐するマシン上のリソース可用性の変更に従って、管理者がそのコンテンツを指定し、或いは仕様を適合させることが望ましい。キャッシュの格納オーバーヘッド及び整合性の維持が効率的であることがさらに望ましい。

従来技術のこれら及び他の欠点及び不利な点は、ローカル・アプリケーションによって実行される照会に基づいてデータを動的にキャッシュに入れることをサポートするための、コンピュータ・システム及び対応する方法によって対処される。

例示的なシステムは、完全なデータベースを有する遠隔サーバと、該完全なデータベースのサブセットを含み、該遠隔サーバと信号通信状態にあるエッジ・サーバ上のローカル・データベースと、該完全なデータベースからの結果をキャッシュに入れ、局所的に生成されたデータを受信し、該ローカル・データベースと遠隔データベースとの間のデータの整合性を保証しながら、使用可能な格納要件に基づいてキャッシュのコンテンツを調整するための、該エッジ・サーバ上の該ローカル・データベース内にある共有テーブルとを含む。

例示的な装置は、照会エバリュエータと、全てが該照会エバリュエータと信号通信状態にあるキャッシュ索引と、キャッシュ・リポジトリと、リソース・マネージャと、包含関係チェッカと、照会パーサと、整合性マネージャとを有するエッジ・データ・キャッシュを含む。

少なくとも１つの遠隔サーバに向けられたデータベース照会にローカル・サーバが応じるための、対応する例示的な対応方法が、該遠隔サーバの従前のデータベース照会の結果を動的にキャッシュに入れ、ローカル・データベースを該ローカル・サーバと関連付け、複数のキャッシュ結果を該ローカル・データベース内の共有テーブルに格納し、該ローカル・サーバによって新しいデータベース照会に応じる際に該複数のキャッシュ結果を使用する段階を含む。

本開示のこれら及び他の態様、特徴及び利点は、添付の図面と併せて読まれるべきである例示的な実施形態の以下の説明から明らかになるであろう。

本開示の実施形態は、以下の例示的な図面によるネットワーク・エッジでのトランスペアレントなデータのキャッシュ処理を教示する。

本開示の実施形態は、遠隔サーバに向けられたデータベース照会をローカル・マシンによって処理することを可能にする動的なデータベースのキャッシュ処理を提供するものである。キャッシュ処理は、ローカル・データベース・エンジンを利用して、部分的にではあるが意味的に整合性のある、従前の照会結果の「実体化ビュー」を維持する。アプリケーション照会のストリームに基づいて、データがキャッシュに動的に取り込まれる。照会述部上で作動する包含関係チェッカを用いて、新しい照会結果が、キャッシュに入れられた結果のユニオン内に含まれるかどうかを確定する。共通のローカル・テーブルを用いて、可能であれば重複する照会結果の間で物理的格納部を共有する。起点データベースから、挿入、削除、及び更新をキャッシュに入れられたローカル・データベースに伝えることによって、データ整合性が維持される。バックグラウンド・クリーニング・アルゴリズムが、整合性プロトコルによって伝えられる過剰な行並びにキャッシュから追い出すように印が付けられた照会に属する行を追い出すことによって、共通のローカル・テーブルのコンテンツを継続的又は周期的に整理する。この開示において、「照会応答」及び「照会結果」という用語は、互換性をもって用いられる。

以下の説明において、次の定義が、例示的な実施形態の原理及び／又は演算の理解の助けとなるであろう。

データベース・テーブルとは、リレーショナル・データベース・システムによって定義されるリレーショナル・テーブルである。

照会述部とは、照会結果において基本テーブル内のどの行を戻すかを選択するための基準として用いられる、照会において特定される制約（例えば、ＳＱＬステートメントのＷＨＥＲＥ節）である。

照会結果とは、ＳＱＬ照会によってデータベース・システムに戻される応答である。照会結果は、行と列を有するテーブルに似ている。

照会結果の組とは、多数の照会に対応する複数の結果の組である。

データ整合性とは、データベース・キャッシュ内のデータが、起点データベース内のデータに対して、所与の時間窓の範囲内で整合しているという要件である。正確には、現在時間Ｔｃでキャッシュに入れられたデータ状態が、過去の時間Ｔｐで起点データベース状態と整合していることを意味する。ここで、Ｔｐは、所与の最大時間窓の範囲内である。

照会／トランザクション・タイムスタンプとは、単調に増加し、起点サーバで実行する全ての照会及びトランザクションと関連付けられる、サーバによって生成された固有の数である。タイムスタンプは、並行操作に対してトランザクション又は照会の逐次化順序を反映する。

リフレッシュ・メッセージとは、起点データベース内のテーブルへの新しい変更（例えば、挿入、更新、削除ステートメント）を反映する、起点サーバによってエッジ・キャッシュに送られるメッセージである。多数のリフレッシュ・メッセージにおいて、基本テーブルへの変更をバッチ処理することができるが、該リフレッシュ・メッセージは、これらが報告する変更が生じた順序で伝えられる。

即時更新の可視性とは、同じアプリケーションによる更新がうまく完了した後に、アプリケーション照会が、データベースへの更新の結果を監視しなければならない特性である。

単調状態遷移とは、第１の照会への応答を受信した後に、第２の照会が実行依頼される場合に、アプリケーションによってキャッシュに実行依頼される２つの連続する照会が、前進するデータベースの状態を、時を違えず監視する特性である。すなわち、第２の照会は、第１の照会によって監視された状態より新しいか又はより新しいデータベースの状態を、時を違えず監視する。

図１に示されるように、「エッジ・データ・キャッシュ」を用いる例示的なネットワークの実施形態が、全体を参照符号１００で示される。ネットワーク１００は、より大きなアプリケーション・システムの一部とすることができる。ネットワーク１００は２つのエッジ・サーバ１０９及び１１０を含み、これらエッジ・サーバは、ウェブ要求を実行するクライアント・マシンに接続され、かつ、起点サーバ１０８にも接続されており、該起点サーバにおいて、主データベース及びウェブ・サイトがネットワーク接続１０７を介してホストされる。起点サーバ１０８は、データベース１０１と、アプリケーション・サーバ１０２と、ウェブ・サーバ１０３とを含む。エッジ・サーバ１０９、１１０の各々は、アプリケーション・サーバ１０５及びウェブ・サーバ１０６を含む。しかしながら、エッジ・サーバは、起点サイトに格納されたデータベース全体のレプリカを有するわけではない。代わりに、エッジ・サーバは、新規なエッジ・データ・キャッシュ１０４を使用する。動的コンテンツについての要求が、エッジ・サーバによって受信され、エッジ・アプリケーション・サーバ１０５の内部でホストされるアプリケーション・コンポーネントによって処理される。これらのコンポーネントは、データベース照会を発し、該データベース照会は、可能であれば、エッジ・データ・キャッシュ１０４によってインターセプトされ、ローカル・データベースにおいて処理される。ローカル・データベースによって照会を処理することができない場合には、エッジ・データ・キャッシュ１０４は、要求を起点データベース１０１に転送し、そこから結果を検索する。

図２を参照すると、エッジ・データ・キャッシュが、全体を参照符号２００で示される。エッジ・データ・キャッシュ２００は、主部分２０２と結合されたＪａｖａ（商標）サーブレット２０１を含む。主部分２０２は、照会パーサ２０５と信号通信状態で結合されたＪＤＢＣインタフェース２０３と、包含関係チェッカ２０７と、照会エバリュエータ２０４と、キャッシュ索引２０６と、ローカル・リポジトリ２０８と、整合性マネージャ２１０と、リソース・マネージャ２０９とを含む。キャッシュの機能は、以下のコンポーネントとして実装される。

照会パーサ２０５は、ＳＱＬ文字列を、「照会ステートメント」データ構造体、列のリストを特定する構文解析ツリー、ターゲット・テーブル、及び照会によってアクセスされる種々の節に変換する。特に、ＷＨＥＲＥ節は、ＡＮＤ−ＯＲ標準形態で格納されるブール述部に構文解析される。これが、包含関係チェッカにより、照会述部の対に等価演算及び包含関係演算を行うことを可能にする。

照会包含関係チェッカ２０７は、新しい照会の結果が前にキャッシュに入れられた照会結果に含まれるかどうかを判断する。従前の照会、従前の照会の適切なサブセット、又は多数の従前の照会のユニオンの適切なサブセットに対する完全一致として、包含関係をチェックすることができる。

キャッシュ索引２０６は、包含関係のチェックを提供する。照会述部が複雑であるか、又はキャッシュに入れられた照会の組が長過ぎるとき、包含関係のチェックは、計算に費用がかかることになる。新しい照会が受信されると、キャッシュ索引２０６は、前にキャッシュに入れられた照会の全てをチェックする代わりに、同じテーブル及び列上で作動する照会だけに焦点を合わせる。キャッシュ索引は、テーブル名及び列名に基づいて、キャッシュに入れられた照会を多重レベルのハッシュ・テーブル内に構成する。

照会エバリュエータ２０４は、キャッシュのコア・モジュールであり、キャッシュ論理を含む。照会エバリュエータ２０４は、アクセスがヒットであるかミスであるか、ミスの際にバックエンドによって戻された結果をキャッシュ内に挿入すべきかどうかを判断する。照会エバリュエータ２０４はまた、データを前もって取得し、キャッシュ性能を改善するために、照会をバックエンドに送る前にキャッシュ内に欠落している照会を再書き込みすることもできる。

リソース・マネージャ２０９は、ヒット率及び応答時間についての統計値と、キャッシュ構成パラメータとを維持する。収集された統計値がそうした必要性を示す場合には、リソース・マネージャ２０９は、特定の作業負荷に適合させるように構成パラメータを変えることができる。

キャッシュ・リポジトリ２０８は、結果を格納する。キャッシュ・ミスの際の照会結果は、キャッシュ・エバリュエータによって判断されるローカル・データベース・テーブルに格納される。本開示の実施形態は、ハイブリッドの物理的格納ポリシーを用いる。幾つかの照会は、照会結果モデルごとに１つのテーブルを用い、他の照会は、データがバックエンドの基本テーブルに部分的に取り込まれたローカル・レプリカを通じて、物理的格納部を共有する。

整合性マネージャ２１０は、バックエンド・データベースから受信したリフレッシュ・メッセージに応答して、局所的にキャッシュに入れられたデータに更新を適用する。

操作において、照会は、Ｊａｖａ（商標）サーブレット２０１のようなアプリケーション又はアプリケーション・コンポーネントから送出される。照会は、データベース・キャッシュ２０２によって受信される。具体的には、キャッシュ２０３内のＪＤＢＣインタフェース・アダプタが、アプリケーションとの接続を担当する。インタフェース・アダプタは、Ｊａｖａ（商標）ＪＤＢＣ規格によって定義され、必要とされるクラスの組の実装である。次に、「照会ステートメント」が、照会エバリュエータ２０４に送られる。照会エバリュエータは、照会を局所的又は遠隔的に実行するかどうかの決定と、キャッシュ操作の制御とを担当するモジュールである。照会ステートメントを受信すると、照会エバリュエータは、照会パーサ２０５を呼び出すことによって、受信したステートメントを構文解析する。パーサは、ステートメントを４つのカテゴリの１つに分類する。ステートメントの処理は、その照会カテゴリによって決まる。

ここで図３を参照すると、照会ツリーが、全体を参照符号３００で示されている。照会ツリー３００は、異なる照会カテゴリを示す。キャッシュ３０１によって受信された照会は、包含関係チェック可能照会３０２及び包含関係チェック不能照会３０３の２つのクラスに構成される。キャッシュに入れられた包含関係チェック可能照会が、後の任意の照会に応じることができ、その結果は、キャッシュに入れられた照会の結果のサブセットとなることが分かる。単一のテーブル上で作動し、又は多数のテーブルを結合させるが、ｇｒｏｕｐ−ｂｙ節も集約演算子も含まない照会が、包含関係チェック可能照会としてキャッシュに入れられる。これらは、全体の結果すなわち単純照会３０４と、部分的結果すなわち上位Ｎ個の照会３０５の２つのカテゴリにさらに分けることができる。

包含関係チェック不能照会は、キャッシュに入れることができるが、ＳＱＬ文字列の完全一致検索を用いてマッチングが行なわれる。これらはさらに、集約照会３０６及び複合照会３０７の２つのカテゴリに分けられる。ＵＤＦ、サブ照会、又はｇｒｏｕｐ−ｂｙ節を使用する複合照会は、包含関係チェッカによっては処理されず、完全一致するものとしてキャッシュに入れられる。選択リスト内のＭＩＮ、ＭＡＸ、及びＡＶＧなどの集約演算子を用いてデータを集約する照会も、完全一致するものとしてキャッシュに入れられる。しかしながら、集約照会３０６は、その選択リスト内の集約演算子をドロップすることによって、包含関係チェック可能照会３０２に変換することができる。この最適化は、推測される利点が重要である場合に、キャッシュによって行なわれる。

単純照会の処理は、次のように進行する。単純照会は、その結果が基本テーブルの行及び列のサブセットであるというものである。したがって、単純照会は、「ＧＲＯＵＰ ＢＹ」節、サブ照会、又はユーザ定義機能のいずれをももたない。単純照会は、上位Ｎ個の照会ではなく、基本的な比較基本形を用いるＷＨＥＲＥ節に基づいて、単に、単一のテーブルの一部又は多数のテーブルの結合を選択するというものである。単純照会の例が下記に与えられる。
ＳＥＬＥＣＴ ｅｍｐｌｏｙｅｅ．ｉｄ ＦＲＯＭ ｅｍｐｌｏｙｅｅ ＷＨＥＲＥ ｅｍｐｌｏｙｅｅ．ａｇｅ＜２５

図４に示されるように、高レベルの処理アルゴリズムが、全体を参照符号４００で示される。高レベルの処理アルゴリズム４００は、キャッシュ・ヒット又はキャッシュ・ミスの処理を提供するものである。照会を受信すると、キャッシュ索引を用いて、同じテーブル・リスト及び列のリスト上にある照会を検索する。次に、決定ブロック４１０において、包含関係チェッカを呼び出し、この照会が前にキャッシュに入れられたこれらの照会内に含まれるかどうかを確定する。

キャッシュ・ヒットの場合には、機能ブロック４１２において、照会がローカル・キャッシュ上で実行され、結果が戻される。機能ブロック４１２はまた、キャッシュ・リポジトリ４１４にも照会を送信し、該キャッシュ・リポジトリ４１４から結果を受信する。キャッシュ・ミスの場合には、照会は、バックエンド・サーバに該照会を送信する前に、機能ブロック４１６及び４１８において再書き込みされる。次の最適化が行われる。第１に、ＷＨＥＲＥ文節、ｏｒｄｅｒ−ｂｙ節、及びｈａｖｉｎｇ節内に記載される列を含むように、選択リストが拡張される。この拡張の目的は、キャッシュにおいてヒットする将来の照会を実行できる可能性を最大化することである。第２に、一次キー列も選択リストに加えられる。重複する結果を有する多数の照会が同じ基本テーブルの同じ行を検索するとき、重複する行がキャッシュに挿入されるのを防止するために、一次キー列をキャッシュに入れることが必要とされる。バックエンドによって戻される結果は、ミスの際に常にキャッシュに挿入されるわけではない。決定ブロック４２０において高度な履歴ベースのアルゴリズムを用い、機能ブロック４２２において、どの照会がキャッシュに入れるに値するのかを決定することができる。結果は、出力として与えられ、キャッシュ・リポジトリ４１４に送信される。

上位Ｎ個の照会の処理は、次のように進行する。上位Ｎ個の照会は、通常、ｏｒｄｅｒ−ｂｙ節に従ってソートされた結果の組の最初から、指定された数の行を取得する。照会包含関係及び評価アルゴリズムは、単純な全体結果の照会のものとは異なる。上位Ｎ個の照会は、Ｆｅｔｃｈ節を落とすことによって、単純照会に変換される。上述のように、包含関係は、これらの単純照会において実行される。最終ステップにおいて、Ｆｅｔｃｈ節が考慮される。基本照会（Ｆｅｔｃｈ節をもたない）はキャッシュ・ヒットであるが、Ｆｅｔｃｈ節は、該基本照会をキャッシュ・ミスにすることがあることに注目されたい。例えば、下記の２つの照会Ｑ１及びＱ２、すなわち
Ｑ１：ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ ｉｔｅｍ ＷＨＥＲＥ ｃｏｓｔ＜１５ ＯＲＤＥＲ ＢＹ ｃｏｓｔ ＦＦＮＲＯ ２０
Ｑ２：ＳＥＬＥＣＴ ｉｄ ＦＲＯＭ ｉｔｅｍ ＷＨＥＲＥ ｃｏｓｔ＜５ ＯＲＤＥＲ ＢＹ ｃｏｓｔ ＦＦＮＲＯ ２０
を考える。

ＦＥＴＣＨ ＦＩＲＳＴ ２０ ＲＯＷＳ ＯＮＬＹアルゴリズム（ＦＦＮＲＯ ２０）節が、両方の照会に存在しない場合には、第２の照会の結果を、第１の照会の結果すなわちキャッシュ・ヒット内に含めることができる。しかしながら、その節が存在するときには、キャッシュ・ヒットは、単なる照会ステートメントの検査によって保証されるわけではない。したがって、上位Ｎ個の照会について包含関係チェックを処理する際の第２のステップは、キャッシュに入れられたデータ上で局所的な実行を試みることである。十分な行が検索される場合には、照会はキャッシュ・ヒットと考えられ、他の場合には、キャッシュ・ミスと考えられる。結果の一部だけがローカル・キャッシュ内に見出されるので、このタイプのキャッシュ・ミスは、「部分的ヒット」と呼ばれる。

包含関係チェックがいずれのマッチング照会も見出さないか、又は結果の組が十分な行を有していない場合には、元の照会ＱＮが、修正された照会ＱＮ´に変換され、ここで、Ｆｅｔｃｈ節内のＮの値は、より大きなＮ´（Ｎ´＝Ｎ^＊Ｅｘｐａｎｓｉｏｎ−Ｆａｃｔｏｒ）によって置き換えられる。例えば、実験におけるデフォルト係数値が２である場合には、要求される行数の２倍をフェッチする。要求されるアプリケーションより多くの行を検索することは、後の「部分的ヒット」照会、すなわち包含関係チェック・ステップを通過するが、要求されている行数を見出すことができない照会のイベントを減少させることを狙いとした発見的方法である。

集約照会の処理は、次のように進行する。集約照会は、その選択リスト内に集約演算子（例えば、ＭＡＸ、ＭＩＮ、ＡＶＧ、ＳＵＭ）を有し、他の場合には包含関係チェックが可能になる。次の照会Ｑ３：
Ｑ３：ＳＥＬＥＣＴ ＭＡＸ（ｃｏｓｔ） ＦＲＯＭ ｉｔｅｍ ＷＨＥＲＥ ｉｄ＝１０
を考える。

ヒットのためのマッチングが、２つのステップで進行する。まず、ＳＱＬ文字列に基づいてＱ３の完全一致についてのチェックが行われ、結果の組の全体がアプリケーションに戻される。次に、何らの完全一致が見出されなかった場合には、集約演算子を取り除くことによって、元の照会Ｑ３が、照会Ｑ４に修正される。
Ｑ４：ＳＥＬＥＣＴ ｃｏｓｔ ＦＲＯＭ ｉｔｅｍ ＷＨＥＲＥ ｉｄ＝１０

修正された照会Ｑ４について包含関係の一致が見出された場合には、元の照会Ｑ３が、ローカル・キャッシュ上で実行され、コストを局所的に集約し、結果をアプリケーションに戻す。ミスの際には、修正された照会Ｑ４が、バックエンドで実行される。結果の組のサイズが閾値内である場合には、結果は、対応するローカル・テーブルに格納され、元の照会が局所的に実行される。このことは、異なる集約演算子を有する将来の照会をキャッシュにおいて処理することを可能にする。結果の組のサイズが大きすぎることが判明した場合には、元の照会Ｑ３がバックエンドに送信され、その結果は、新しい完全一致テーブルに格納される。このことは、全く同じ集約条件を有する何らかの将来の照会をキャッシュから処理することを可能にする。この発見的方法は、キャッシュのサイズを必要以上に増大させることなく、キャッシュ・ヒットを増大させること目的としたものである。

複合照会は、複合節（例えば、ユーザ定義機能又はＷＨＥＲＥ節におけるサブ照会）、或いはｇｒｏｕｐ−ｂｙ節のいずれかのために、包含関係チェックが可能ではない。ｇｒｏｕｐ−ｂｙ節は、全く同じｇｒｏｕｐ−ｂｙ節及びＷＨＥＲＥ節を有する照会によってのみ用いることができる集約データを生成する。このように、包含関係チェックを行うことは、不適切である。代わりに、こうした照会の結果は、照会のＳＱＬ文字列によって索引が付けられた別個の結果テーブルに格納される。こうした照会についての包含関係チェックは、ＳＱＬ文字列の完全一致に基づいている。このルックアップ・プロセスは、キーとしてＳＱＬ文字列を有するハッシュ・テーブルに基づいているので、非常に高速である。正確なＳＱＬ文字列がキャッシュに実行依頼される場合には、対応する結果テーブルにおいて、局所的な照会が実行され、テーブル全体を検索する（すなわち、「ＳＥＬＥＣＴ^＊ＦＲＯＭ ＬＯＣＴＡＢ」が局所的に実行される）。こうした照会は、費用がかからず、エッジ・サーバ上での処理時間が最小であることに注目されたい。

図５を参照すると、ローカル・リポジトリが、全体を参照符号５００で示される。ローカル・リポジトリ５００は、照会結果がどのようにローカル・キャッシュ・リポジトリ５０１に格納されるかを示す。リポジトリ５０１は、２つの区画、すなわち、一方は複合又は完全一致照会の格納のための区画５０２と、もう一方は包含関係チェック可能照会の格納のための区画５０３とに分けられる。完全一致照会は、別個のテーブルに格納され、その仕様がキャッシュに入れられた照会のＳＱＬ文字列に一致する新しい照会に応答するためだけに用いられる。例えば、照会Ｑ５ ５０４及びＱ６ ５０５は、これらの結果が重複するどうかに関係なく、別個のテーブルに格納される。

包含関係チェック可能照会は、共通のテーブルに格納される。同じ基本テーブル上の照会は、同じテーブルのローカル・コピーに格納される。例えば、図は、２つの照会Ｑ７及びＱ８が同じテーブルから「ＳＥＬＥＣＴ（選択）」されると仮定する。まず、照会Ｑ７ ５０６によって検索されたタプルが、キャッシュに挿入される。次に、第２の照会Ｑ８によってフェッチされた行が、同じテーブルに挿入される５０７。Ｑ８の結果が挿入されると、既存の行が、新たにフェッチされた値で更新される。そのため、２つの異なる照会によってフェッチされた同じ行は、キャッシュ内で複写されない。全ての照会は、それらをバックエンド・サーバに送信する前に、一次キーを取得するように再書き込みされるので、同一の行が発見される。

ここで、図６を参照すると、キャッシュ・テーブル構造が、全体を参照符号６００で示される。キャッシュ・テーブル構造６００は、ここでは「従業員」と呼ばれる、同じデータ・テーブル上の２つの照会の特定の例を示し、それらの結果データ構造６０１、６０２が、どのようにエッジ・データベース・キャッシュ内の同じローカル・テーブル６０３に格納されるかを示す。

図７には、整合性プロトコルが、全体を参照符号７００で示されている。整合性プロトコル７００は、バックエンド・サーバ部分７０２と信号通信状態にあるエッジ・サーバ部分７０１を含む。エッジ・サーバ部分７０１は、照会結果を挿入し、照会を実行するための、キャッシュ・リポジトリ７０４と信号通信状態にあるＤＢＰｒｏｘｙユニットを含む。変更ＡＰＰＬＹユニット７０５が、テーブルをリフレッシュするために、キャッシュ・リポジトリ７０４と信号通信状態にある。

バックエンド・サーバ部分７０２は、照会を受信し、結果を提供するためのＤＢＰｒｏｘｙユニット７０３と信号通信状態にあるＤＢＭＳユニット７０６を含む。ＤＢＭＳユニット７０６はさらに、キャッシュ・リポジトリ７０７に書き込み、該キャッシュ・リポジトリ７０７から読み取るための別のキャッシュ・リポジトリ７０７と信号通信状態にある。キャッシュ・リポジトリ７０７は、最後に書き込まれたデータを読み取るための、変更ＣＡＰＴＵＲＥユニット７０８と信号通信状態にある。次に、変更ＣＡＰＴＵＲＥユニット７０８は、メッセージをリフレッシュするための変更ＡＰＰＬＹ装置７０５と信号通信した状態で接続される。

このように、起点サーバによって伝えられる更新のストリームを利用することによって、データ整合性が確保される。従来の実体化ビュー手法は、基本データ内の変更に対するビュー定義（「データ」）を再実行することによって、キャッシュに入れられたビューを更新するというものである。しかしながら、キャッシュに入れる照会（「ビュー」）の数が潜在的に多数であるため、エッジ・データ・キャッシュは、より効率的な機構を必要とする。キャッシュに入れられたデータは、データが部分的に取り込まれたバックエンド・テーブルのコピーとして維持されるため、起点において基本テーブルにコミットされた変更は、照会を再実行する必要なく、単に、「現状のままで」キャッシュに入れられたバージョンに伝えることができる。基本テーブルへの更新、削除、及び挿入（「ＵＤＩ」）は、データが部分的に取り込まれたエッジ上のものに伝えられ、適用される。キャッシュ上で実行することになる将来の照会が、これらの新しく伝えられた変更から、何らかのマッチング・タプルを検索する。この解法は、一般的に大部分のウェブ環境の遅い速度で変化するデータを想定したものであり、キャッシュに入れられたビューをどのように更新すべきかを判断する処理オーバーヘッドを低減させるために、潜在的に不必要なデータの伝搬をあきらめる。しかしながら、テーブルに大量の更新作業負荷がかかっている場合には、キャッシュ・リソース・マネージャが、指定期間の間だけ、ローカル・コピーを使用不可にすることができる。

エッジ・アプリケーションによって発せられる読み取り専用照会は、可能ならいつでもキャッシュから応じられる。更新トランザクションは、常に、最初に該更新トランザクションをローカル・キャッシュに適用することなく、実行のためにバックエンド・データベースに経路指定される。エッジ・データ・キャッシュは、大規模展開向けに設計されているので、整合性プロトコルは、可能な限り起点から疎結合されたものにしなければならない。その結果、キャッシュの整合性を確保する負担が、できる限り、リソースがより自然に拡大縮小するエッジ・キャッシュにかかるようにしなければならない。バックエンド・サーバは、周期的な更新の伝搬、別個のプロセス又はマシンに対して負担を軽減できるタスクを担当するだけにすべきである。強力な整合性保証を与えることは、キャッシュの有効性を制限し、高いコストを招くが、即時更新可視性及びデータ整合性のような幾つかの重要な整合性保証を確保できるかが、まもなく説明される。本開示は、起点において全てのＵＤＩをテーブルに捕捉し、それらを「リフレッシュ・メッセージ」内にパッケージされた状態で、エッジ・キャッシュに転送するデータ・プロパゲータに依存している。データの変更は、トランザクション識別子によってタグ付けされたエッジに伝えられ、トランザクション・コミット順にエッジ・キャッシュに適用される。起点サイトでコミットされるトランザクションの効果を反映させる、入ってくるＵＤＩのストリームが、局所的にキャッシュに入れられたテーブルに適用される。

ＵＤＩが伝えられ、タイムスタンプ順にキャッシュに適用されるので、このセクションに用いられる全てのタイムスタンプは、バックエンド・サーバ側のコミット・タイムスタンプを指し、キャッシュ内のタプル値は、起点からの最後の伝搬メッセージのタイムスタンプに対応するデータベースの状態を反映していなければならない。より正確には、伝搬メッセージのタイムスタンプは、そのメッセージ内に含まれるあらゆる更新トランザクションのうちの最大タイムスタンプである。データ整合性を確保する際の問題は、伝播メッセージ及びミスの際の照会結果の挿入によって、ローカル・テーブルを更新できることから生じる。

保証された整合性特性。キャッシュは、エッジ・アプリケーションについての幾つかの重要な整合性特性、すなわちデータ整合性、単調遷移、及び即時更新可視性を保証する。キャッシュは、本物のバックエンド・データベースのようなアプリケーションのように見える。しかしながら、キャッシュのコンテンツは、通常、バックエンド・データベースに格納されるものと同程度に最新のものではない。したがって、キャッシュは、現在の状態と異なる可能性がある状態をアプリケーションに反映するので、データベースの所与の状態を「エクスポート」するものである。データ整合性特性は、その時点におけるキャッシュによってエクスポートされたデータベースの状態が、常に、従前の時点におけるデータベースの過去の状態に対応することを要求する。エクスポートされた状態と実際の状態との間のずれも制限される。単調状態の遷移特性は、キャッシュによってエクスポートされたデータベースの状態が、時を違えずに前進することだけを示す。即時更新可視性の特性は、アプリケーションが更新をコミットし、後に照会を発する場合に、該照会が該更新（及び従前の更新の全て）の結果を監視することを要求する。

データ整合性及び単調遷移を保証すること。最初に、キャッシュが１分前のデータベース状態と一致すると仮定する。キャッシュ内に欠落し、起点で実行される新しい照会の結果が挿入された場合には、該キャッシュは、古いデータと新しいデータの混合物を含むことになる。データ整合性は、キャッシュに入れられたデータが、常にデータベースの単一の過去のバージョンと一致することを要求する。照会が起点において原子的に実行されると仮定する。照会が失敗し、遠隔式に実行される場合には、サーバは、該照会が実行されたときに、その最後のコミット・タイムスタンプｔｑを結果と共に戻す。

図８を参照すると、照会処理アルゴリズムが、全体を参照符号８００で示される。照会処理アルゴリズム８００は、整合性を考慮し、照会の包含関係チェックに基づいてキャッシュ・ヒットを登録するための機能ブロック８０１を含む。機能ブロック８０１は、ヒットが生じたかどうかを判断するために、決定ブロック８０２に制御を渡す。ヒットが生じた場合には、機能ブロック８０３に制御を渡し、共有キャッシュのロック、照会の局所的実行、及び共有キャッシュのロック解除を行う。しかしながら、ブロック８０２においてヒットが生じなかった場合には、機能ブロック８０４に制御を渡し、照会を遠隔的に実行し、決定ブロック８０５に制御を渡す。ブロック８０５は、遠隔的に実行された照会がうまくいかなかったのかどうかを判断する。うまくいった場合には、戻しブロック８０６に制御が渡り、キャッシュに入れられた結果「ｒｃ」を戻す。うまくいかなかった場合には、決定ブロック８０７に制御が渡り、結果が部分的なものでしかないのかどうかを判断する。部分的なものでしかない場合には、機能ブロック８０８に制御が渡り、キャッシュを排他的にロックし、結果を結果の組に挿入し、サーバからの付加的な情報を伝え、該キャッシュをロック解除する。機能ブロック８０８は、戻しブロック８０９に制御を渡し、結果の組「ｒｓ」を戻す。ブロック８０７の結果が偽であるか又はノーである場合には、制御は、戻しブロック８０９に直接渡る。

作動において、結果の挿入は、ブロック８０７において、照会のタイムスタンプを、起点サーバｃａｃｈｅ＿ｔｓから受信した最後の伝搬メッセージのタイムスタンプと比較することによって開始される。照会及びキャッシュのタイムスタンプは、図では、それぞれｑｕｅｒｙ＿ｔｓ（「ｔｑ」）及びｃａｃｈｅ＿ｔｓ（「ｔｃ」）という長い名前によって、また、他の場所では、長い名前又は短い名前で呼ばれることに注意されたい。ｑｕｅｒｙ＿ｔｓがｃａｃｈｅ＿ｔｓより大きい場合には、照会は、キャッシュのものより新しい状態を監視したものである。この通常の場合においては、ブロック８０８において、まずミスの結果が挿入され、あらゆる保留の伝搬メッセージが起点サーバから引き出され、キャッシュ全体を後の時間に早送りする。最後に、照会が索引に加えられる。しかしながら、ｃａｃｈｅ＿ｔｓがｑｕｅｒｙ＿ｔｓより大きい場合には、ミスの結果を即座に挿入することで、キャッシュに入れられたデータを過去の値に戻すことができ、伝搬メッセージによって適用される変更を逆にし、単調性要件に失敗する。これは、まれな競合状態であるため、こうした場合には、結果の挿入を省略することができる。これは、通常、後のミスの１つが、結果の挿入に成功するまで、照会をキャッシュに入れるのを遅らせるだけであり、キャッシュの有効性を著しく損なうものではない。
ブロック８０８におけるｐｒｏｐａｇａｔｅ＿ｆｒｏｍ＿ｓｅｒｖｅｒ（）の副次的作用として、ｃａｃｈｅ＿ｔｓを増加させることができることに注目されたい。

ここで、図９を参照すると、結果をキャッシュに挿入するためのアルゴリズムが、全体を参照符号９００で示される。ループ・ブロック９０１が、照会結果内の各タプルについてループを実行する。ブロック９０１のためのループは、タプルがキャッシュ内にあるかどうかを判断するための決定ブロック９０２を含む。タプルがキャッシュ内にある場合には、機能ブロック９０３に制御が渡り、該タプルを更新する。タプルがキャッシュ内にない場合には、機能ブロック９０４に制御が渡り、該タプルを挿入する。このように、操作において、キャッシュへの結果の組の挿入は、次のように進行する。すなわち、結果の組をキャッシュに挿入したとき、ブロック９０３において、既存の行が新しい値で上書きされ、一方、ブロック９０４において、既存のものでない行がテーブルに挿入される。

図１０には、更新トランザクションを実行するためのアルゴリズムが、全体を参照符号１０００で示される。機能ブロック１００１が、結果「ｒｃ」についての遠隔照会を実行し、決定ブロック１００２に制御を渡す。照会がうまくいった場合には、ブロック１００２は、戻しブロック１００３に制御を渡し、結果「ｒｃ」を戻す。照会がうまくいかなかった場合には、ブロック１００２は、機能ブロック１００４に制御を渡し、サーバからデータを伝える。ブロック１００４は、戻しブロック１００５に制御を渡し、結果「ｒｃ」を戻す。

このように、即時更新可視性が保証される。キャッシュへのエッジ・アプリケーションによって実行依頼された更新トランザクションは、起点データベース１００１に経路指定される。さらに、更新トランザクションが完了した後に、アプリケーションに戻す前に該更新トランザクションを起点１００４から引き出すことによって、更新の効果を迅速にフェッチすることができる。

キャッシュのスペース・オーバーヘッドが、キャッシュ置換えによって調整される。スペース・オーバーヘッドを制限し、通常制限されるエッジ・リソースの使用を最適化するために、エッジ・データのキャッシュは、データ整合性を保持しながら、キャッシュから未使用のデータを安全に追い出すバックグラウンドのガーベッジ・コレクション・プロセスに依存する。具体的には、キャッシュ置換えの目的は、制限された使用可能なスペース量に対するキャッシュの利点を最大化することである。ファイル及びメモリ・ページの従来の置換えとは対照的に、基礎となる行を多数の照会にわたって共有することができる。

キャッシュ置換えは、ローカル・データベースのスペース使用が高い水位線（「ＨＷＭ」）値に達するときにトリガされる。次に、スペースが十分に空けられ、低い水位線（「ＬＷＭ」）値より下に達するまで、置換えが始まる。置換えは、より多くの行をローカル・テーブルに挿入するためのスペース、又は新しいテーブルを作成するためのスペースがないときに、照会ミスについての要求に応じてトリガされるわけでない。置換えは、バックグラウンド・プロセスであり、照会処理及び更新操作と同時進行することが予想できる。

図１１を参照すると、キャッシュ・クリーニング・アルゴリズムが、全体を参照符号１１００で示される。アルゴリズム１１００は、テーブルを拡張して新しい列「ａｃｃｅｓｓｅｄＦｌａｇ」を付加するための機能ブロック１１０１を含む。ブロック１１０１は、機能ブロック１１０２に制御を渡し、ローカル・テーブル内の全ての列について「ａｃｃｅｓｓｅｄＦｌａｇ」を偽に再設定する。ブロック１１０２は、機能ブロック１１０３に制御を渡し、キャッシュ内に留まる照会の組「Ｓ」を判断する。次に、機能ブロック１１０３は、機能ブロック１１０４に制御を渡し、組「Ｓ」内の全ての照会を再実行し、いずれかの選択された行の「ａｃｃｅｓｓｅｄＦｌａｇ」を真に設定する。次に、ブロック１１０４は、機能ブロック１１０５に制御を渡し、「ａｃｃｅｓｓｅｄＦｌａｇ」が偽である全ての行を削除する。

キャッシュ・クリーニングのためのアルゴリズム１１００は、グループ置換えと呼ばれる。このアルゴリズムは、実装が簡単であり、ヒット、ミス、又は更新の伝搬時にオーバーヘッドを付加するものではない。ブロック１１０３において、置換えポリシーに基づいて、１組の「犠牲」照会に印が付けられ、キャッシュから削除される。「犠牲」照会だけに属する重複しない行に適正に印が付けられることを保証するために、次のステップが実行される。最初に、ブロック１１０２において、ローカル・テーブルの生成時に定義された制御列として実装されるａｃｃｅｓｓｅｄ ｆｌａｇが、キャッシュに入れられた全ての行と関連付けられ、偽に設定される。次に、ブロック１１０４において、非犠牲照会がバックグラウンドにおいて実行される。このバックグラウンド実行は、フォアグラウンド照会の性能に影響を及ぼさないように、長期間にわたって行われる。照会が実行されるときはいつも、制御列内の対応するエントリが、あらゆる選択された行について真に設定される。ブロック１１０５において、この命令実行段階の終わりに、制御列（ａｃｃｅｓｓｅｄ ｆｌａｇ）が依然として偽の状態で、任意の行を安全に削除することができる。ガーベッジ・コレクション・サイクルが実行を開始した後に、キャッシュ・ミス又は整合性マネージャによって挿入又は更新される行の削除を防止するために、更新されるか又はローカル・テーブルに挿入される任意の行について制御列が設定される。

本開示の実施形態は、ある意味では、具体的には管理しやすさ及び作業負荷又はリソースの可用性の変更に適合する能力である照会応答キャッシュの利点と、具体的には非冗長データ格納のスペース効率及び効率的な更新ベースの整合性プロトコルをサポートする能力である基本テーブル・レプリケーションの利点との両方の世界の最良のものを達成する。

従って、本開示の実施形態の１つの態様は、ローカル・マシンを使用し、従前の照会の結果を動的にキャッシュに入れる際にキャッシュ・ポリシーを用いることによって、少なくとも１つの遠隔サーバ用のデータベース照会に応じることである。本開示の実施形態の別の態様は、ローカル・データベースをローカル・マシンと関連付け、該ローカル・データベースを使用して複数の照会結果を共有テーブルに格納することである。本開示の実施形態のさらに別の態様は、照会述部で作動する包含関係チェッカを用いることによって、新しい照会に応じる際に、局所的に格納された照会結果を使用することである。包含関係チェッカは、照会述部によって定められる新しい照会が必要とするデータが、論理的に、従前の照会の述部のユニオンによって記載されるキャッシュに入れられた複数の結果内のデータの組に含まれることを保証する。

本開示の実施形態の別の態様は、エッジ・キャッシュに格納されたデータが、可能ならいつでも、起点データベースにおいて定義されたテーブルの「部分的レプリカ」内に構成されることである。起点サーバから受信した照会結果は、ローカル・データベースに挿入される。同じ基本テーブルに対して行われる照会の結果は、該基本テーブルの局所的にキャッシュに入れられた同じバージョンに挿入される。本開示の実施形態のさらに別の態様は、結果が基本テーブルの行及び列の単純なサブセットでない場合に、サブ照会、集約、又はユーザ定義機能を含む照会のような複合照会の結果を、結果ごとに１つずつ、多数のテーブルとして局所的に格納することである。

本開示の実施形態のさらに別の態様は、トランスペアレントであり、アプリケーションへの変更を必要としないことである。また、キャッシュ論理が、データベースの外に常駐するので、バックエンド又はローカル・データベースのいずれとも両立性があり、データベース・サーバへの変更を必要としない。本開示の実施形態の別の態様は、起点において基本テーブルに生じる変更をエッジ・キャッシュに伝えることによって、また、入ってくる照会を処理する際に整合性認識アルゴリズムを用いることによって、局所的にキャッシュに入れられたデータの整合性が維持されることである。本開示の実施形態のさらに別の態様は、キャッシュが、整合性又は正確性を損なうことなく、ローカル・データベースから有用性が少ない照会結果を追い出すことによって、局所的に使用されるスペース量を調整できることである。

本開示のこれら及び他の特徴及び利点は、当業者であれば、本明細書内の教示に基づいて容易に確認することができる。本開示の教示は、ハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、又はこれらの組み合わせの種々の形態で実装できることを理解すべきである。

本開示の教示は、例えば、ハードウェア及びソフトウェアの組み合わせとして実装することができる。さらに、ソフトウェアは、プログラム格納ユニット上で明白に具体化されたファームウェアとして実装されることが好ましい。ソフトウェアは、何らかの適切なアーキテクチャを含むマシンによってアップロードし、実行することができる。マシンは、１つ又はそれ以上の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（「ＲＡＭ」）、及び入力／出力（「Ｉ／Ｏ」）インタフェースのような、ハードウェアを有するコンピュータ・プラトフォーム上に実装されることが好ましい。コンピュータ・プラトフォームはまた、オペレーティング・システム及びマイクロ命令コードを含むこともできる。ここに記載された種々のプロセス及び機能は、ハードウェアによって実行することができるマイクロ命令コードの一部、又はソフトウェアの一部、或いはそれらの任意の組み合わせのいずれかとすることができる。さらに、他の種々の周辺装置を、付加的なデータ格納ユニットのようなコンピュータ・プラットフォームに接続することもできる。

さらに、添付の図面に示された構成システム・コポーネント及び方法の幾つかは、ソフトウェアとして実装されることが好ましいので、該システム・コンポーネント又はプロセス機能ブロック間の実際の接続は、本開示がプログラムされる方法によって異なり得ることを理解すべきである。本明細書の教示を考慮すれば、当業者には、これら及び本開示と同様の実装又は構成を考えることができるであろう。

例証となる実施形態は、ここでは添付の図面と関連して説明されるが、本開示が、それらの精密な実施形態に限定されないこと、及び、当業者であれば、本開示の範囲又は精神から逸脱することなく、種々の変更及び修正をもたらし得ることを理解すべきである。そのような変更及び修正の全ては、添付の特許請求の範囲に述べられる本開示の範囲内に含まれることが意図されている。

起点サーバに接続された２つのエッジ・サーバの概略図を示す。 図１のエッジ・サーバのデータ・キャッシュのブロック図を示す。 図２のエッジ・サーバのデータベース・キャッシュにおける異なるクラスの照会の樹形図を示す。 図１のエッジ・サーバについての照会処理全体の流れ図を示す。 図２のデータ・キャッシュによって用いられる共通スキーマの共有格納技術の概略図を示す。 図１の起点サーバ内の同じテーブル上の２つの照会に関するデータ・テーブルの例を示す。 整合性保守プロトコルの概略図を示す。 整合性が考慮された照会処理アルゴリズムの流れ図を示す。 結果をキャッシュに挿入するためのアルゴリズムの流れ図を示す。 更新トランザクションを実行するアルゴリズムの流れ図を示す。 キャッシュが占めるスペースを調整するために用いられるバックグラウンド・キャッシュ・クリーニング・アルゴリズムの流れ図を示す。

Claims (26)

1. 照会エバリュエータ（２０４）と、
   前記照会エバリュエータと信号通信状態にあるキャッシュ索引（２０６）と、
   前記照会エバリュエータと信号通信状態にあるキャッシュ・リポジトリ（２０８）と、
   前記照会エバリュエータと信号通信状態にあるリソース・マネージャ（２０９）と、
   前記照会エバリュエータと信号通信状態にある包含関係チェッカ（２０７）と、
   前記照会エバリュエータと信号通信状態にある照会パーサ（２０５）と、
   前記照会エバリュエータと信号通信状態にある整合性マネージャ（２１０）と、
   を含むエッジ・データ・キャッシュ（２０２）。
2. 前記エッジ・データ・キャッシュと信号通信状態にあるサーブレット（２０１）をさらに含む、請求項１に記載のデータ・キャッシュを含むエッジ・サーバ（２００）。
3. ローカル・アプリケーションによって実行される照会に基づいてデータを動的にキャッシュに入れるための、請求項２に記載のエッジ・サーバ（１０９、１１０）を含むシステム（１００）であって、
   完全なデータベース（１０１）を有する遠隔サーバ（１０８）と、
   前記遠隔サーバと信号通信状態にあり、前記完全なデータベースのサブセットを含む前記エッジ・サーバ上のローカル・データベース（１０４）と、
   前記ローカル・データベースと前記遠隔サーバとの間の前記データの整合性を確保しながら、前記完全なデータベースからの結果をキャッシュに入れ、局所的に生成されたデータを受信し、利用可能な格納要件に基づいて前記キャッシュのコンテンツ（２０８）を調整するための、前記エッジ・サーバ上の該ローカル・データベース内の複数の共有テーブル（５０３、６０３）と、
   をさらに含むシステム（１００）。
4. ローカル・アプリケーションによって実行される照会に基づいてデータを動的にキャッシュに入れるための、エッジ・サーバ（１０９）を含むシステム（１００）であって、
   遠隔サーバの従前のデータベース照会の結果を動的にキャッシュに入れるための手段と、
   ローカル・データベースをローカル・サーバと関連付けるための手段と、
   共有テーブル内の複数のキャッシュ結果を前記ローカル・データベースに格納するための手段と、
   前記ローカル・サーバによって新しいデータベース照会に応じる際に前記複数のキャッシュ結果を用いるための手段と、
   をさらに含むシステム（１００）。
5. ローカル・アプリケーションによって実行される照会に基づいてデータを動的にキャッシュに入れるためのプログラムであって、前記プログラムが、コンピュータに、
   遠隔サーバの従前のデータベース照会の結果を動的にキャッシュに入れ（４１４）、
   ローカル・データベースを前記ローカル・サーバと関連付け（４２０）、
   共有テーブル内の複数のキャッシュ結果を前記ローカル・データベースに格納し（４２２）、
   前記ローカル・サーバによって新しいデータベース照会に応じる（４１２）際に前記複数のキャッシュ結果を用いる、
   機能を実行させるプログラム。
6. 少なくとも１つの遠隔サーバに向けられたデータベース照会にローカル・サーバが応じるための方法（４００）であって、
   前記遠隔サーバの従前のデータベース照会の結果を動的にキャッシュに入れ（４１４）、
   ローカル・データベースを前記ローカル・サーバと関連付け（４２０）、
   共有テーブル内の複数のキャッシュ結果を前記ローカル・データベースに格納し（４２２）、
   前記ローカル・サーバによって新しいデータベース照会に応じる（４１２）際に前記複数のキャッシュ結果を用いる、
   段階を含む方法（４００）。
7. 前記複数のキャッシュ結果及び前記ローカル・データベースに挿入された他のいずれかのデータから、キャッシュに入れられたデータを形成し（７０５）、
   前記キャッシュに入れられたデータの整合性を確保する（７０８）、
   段階をさらに含む、請求項６に記載の方法。
8. 少なくとも１つの調整基準に基づいて、前記共有テーブルのコンテンツを調整する（１１０３、１１０５）段階をさらに含む、請求項６に記載の方法。
9. 前記少なくとも１つの調整基準が、前記ローカル・サーバ内の利用可能なスペース、前記照会の格納要件、該照会の実行コスト、該ローカル・サーバと前記遠隔サーバとの間のネットワーク性能、該ローカル・サーバ及び該遠隔サーバにかかる負荷、前記キャッシュに入れられた照会のアクセス速度、及びこれらのいずれの組み合わせをも含む基準のグループから取られた基準を含む、請求項８に記載の方法。
10. 前記用いる段階が、前記少なくとも１つの遠隔サーバへの前記照会を加速させる段階を含む、請求項６に記載の方法。
11. 前記格納する段階が、
    単一のデータベース・テーブル上の簡単な照会（３０４）及び上位Ｎ個の照会（３０５）の結果を共有基本テーブルに挿入し、
    結合照会の結果を共有結合テーブル内に保管し、
    全ての前記共有基本テーブル及び共有結合テーブルを含む共有テーブル・リポジトリを形成し、
    複合照会の結果を、照会結果ごとに１つずつ別個のテーブルに格納し、
    前記複数の別個のテーブルから完全一致リポジトリを形成する、
    段階を含む、請求項６に記載の方法。
12. 前記挿入する段階が、
    単純照会が最初に基本テーブルに受信されるたびに、起点サーバ内の基本テーブルに対応するように、前記キャッシュ内に単一のローカル・テーブルを作成し、
    前記単純照会の結果を前記ローカル・テーブルに挿入し、
    前記基本テーブルへの次の単純照会の全ての結果を前記ローカル・テーブルに挿入する、
    段階を含む、請求項１１に記載の方法。
13. 前記保管する段階が、
    結合照会における各々の結合条件及びテーブル・リストに対応するように、前記キャッシュ内にローカル結合テーブルを作成し、
    同じ前記テーブル・リスト上にあり、同じ前記結合条件を有する次の前記結合照会の全ての結果を前記ローカル結合テーブルに挿入する、
    段階を含む、請求項１１に記載の方法。
14. 前記用いる段階が、
    前記照会が複雑な場合に、完全一致リポジトリにおいて前記新しい照会への応答を検索し、
    前記新しい照会が複雑でない場合に、共有テーブル・リポジトリにおいて前記データから該新しい照会への応答をサブ選択する、
    段階の少なくとも１つを含む、請求項６に記載の方法。
15. 前記検索する段階が、
    前記新しい照会の前記ＳＱＬ文字列が前記完全一致リポジトリ内に見出された場合に、該ＳＱＬ文字列に対応する前記キャッシュ内の照会結果を前記アプリケーションに戻し、
    前記新しい照会の前記ＳＱＬ文字列が前記完全一致リポジトリ内に見出されない場合に、該新しい照会を前記起点サーバに送信し、
    前記新しい照会の前記ＳＱＬ文字列が前記完全一致リポジトリ内に見出されない場合に、受信した前記照会結果を前記完全一致リポジトリに挿入し、
    前記新しい照会の前記ＳＱＬ文字列が前記完全一致リポジトリ内に見出されない場合に、キャッシュ内の前記照会結果を前記新しい照会のＳＱＬ文字列と関連付ける、
    段階を含む、請求項１４に記載の方法。
16. 前記サブ選択する段階が、
    前記新しい照会の結果の組の結果が、包含関係チェッカを有するキャッシュに入れられた照会結果のユニオン内に含まれることを証明しようと試み、
    前記証明を試みる段階がうまく完了した場合に、前記新しい照会において記載される前記テーブルをローカル・テーブル名に置き換え、
    前記証明を試みる段階がうまく完了した場合に、前記共有テーブル・リポジトリ上の前記新しい照会を評価し、
    前記照会が上位Ｎ個の照会である場合に、ローカル・キャッシュから受信した行数を数え、前記行数が、前記アプリケーションによって要求される行数を超えない場合に、前記新しい照会を再書き込みし、再書き込みされた照会を作成し、前記再書き込みされた照会を起点に送信し、前記起点サーバから受信した前記結果を共有テーブル・リポジトリに格納し、該再書き込みされた照会の述部を該共有テーブル・リポジトリの索引に付加し、該共有テーブル・リポジトリ上の該照会を評価し、前記評価段階の結果を前記アプリケーションに戻す、
    段階を含む、請求項１４に記載の方法。
17. 前記試みる段階が、
    前記新しい照会の選択リスト内の列のリストがマッチング照会のものに含まれ、該新しい照会の述部がマッチング照会の述部のものを論理的に含み、該新しい照会の種々の節において記載される全ての列が、前記マッチング照会の前記選択リスト内に含まれるという条件を満たす、キャッシュに入れられたマッチング照会を見つけ出し、
    前記新しい照会の選択リスト内の列の前記リストが、前記マッチング照会の各々の１つのものに含まれ、全ての述部が論理ＯＲ演算子によって接続されるとき、該新しい照会の述部が、前記マッチング照会述部の全ての分離によって形成された述部のものを論理的に含み、該新しい照会の種々の節において記載される全ての列が、マッチング照会の各々の前記選択リスト内に含まれるという条件を満たす、キャッシュに入れられたマッチング照会の組を見つけ出す、
    段階の少なくとも１つを含む、請求項１２に記載の方法。
18. 前記再書き込みする段階が、
    アクセスされたテーブルの一次キーを前記照会の選択リストに付加し、
    リソース・マネージャが、結果として生じる結果の組が大きすぎないか又はキャッシュに入れる価値があると推定する場合に、集約演算子を前記選択リストから落とし、
    前記照会によって要求される行数（Ｎ）を拡張し、より多くの行を検索する、
    段階を含む、請求項１６に記載の方法。
19. 前記確保する段階が、
    データ整合性、即時更新可視性、及び単調状態遷移を含むものとして、前記アプリケーションによって特定される整合性要件のグループの少なくとも１つを保証する段階を含む、請求項７に記載の方法。
20. 従前の照会結果のデータ整合性を確保する段階をさらに含む請求項６に記載の方法であって、
    起点によって伝えられ、バックエンド・テーブルに適用された更新、削除、及び挿入を含むリフレッシュ・メッセージにデータ・キャッシュをサブスクライブし、
    前記リフレッシュ・メッセージを受信するたびに、前記更新、削除、及び挿入を共有テーブル・リポジトリ内の局所的にキャッシュに入れられたテーブルに適用し、
    リフレッシュ・メッセージにおいて参照される、前記完全一致リポジトリ内のいずれかの共有結合テーブルを変更されたものとして無効にし、
    リフレッシュ・メッセージのタイムスタンプを、その効果が前記メッセージ内に含まれるいずれかのトランザクションの最大のタイムスタンプと等しいリフレッシュ・メッセージと関連付け、
    キャッシュに入れられた組のタイムスタンプを、前記キャッシュに適用された最後のリフレッシュ・メッセージのタイムスタンプと等しい従前の照会結果と関連付け、
    新しい照会のタイムスタンプを新しい照会と関連付け、
    前記新しい照会のタイムスタンプを前記キャッシュに入れられた組のタイムスタンプと比較し、
    前記新しい照会のタイムスタンプが前記キャッシュに入れられた組のタイムスタンプを超える場合に、応答を該新しい照会に挿入し、
    前記新しい照会のタイムスタンプが前記キャッシュに入れられた組のタイムスタンプを超える場合に、データベース・サーバから保留のリフレッシュ・メッセージを検索する、
    段階を含む方法。
21. 即時更新可視性を確保する段階をさらに含む請求項６に記載の方法であって、
    エッジ・データ・キャッシュによって受信される更新トランザクションを起点サーバに経路指定し、
    更新完了通知を前記起点サーバから受信した後及び完了状態を有する前記アプリケーションに応答する前に、該起点サーバからリフレッシュ・メッセージを引き出し、
    上記経路指定する段階及び引き出す段階が進行中である間に、前記アプリケーションによってキャッシュに入れられたデータへの一切のアクセスを確保しない、
    段階を含む方法。
22. 前記調整する段階が、格納スペース管理ポリシーに従って、共有テーブルのクリーニングを開始する段階を含む、請求項８に記載の方法。
23. 前記共有テーブルのクリーニングが、
    前記共有テーブルから各テーブル内の制御列を形成し、
    前記制御列内のエントリを偽に設定し、
    前記共有テーブル内で維持されることになる良好な照会を特定し、
    前記良好な照会についての応答に属する行に対応する、前記制御列内の全てのエントリに印を付け、
    前記制御列のエントリが依然として偽である前記共有テーブル内のいずれかの行を削除する、
    段階を含む、請求項１５に記載の方法。
24. データベース・サーバから検索された照会結果の組のデータ整合性を確保する方法（８００）であって、
    起点によって伝えられ、バックエンド・テーブル（７０７）に適用された更新、削除、及び挿入を含むリフレッシュ・メッセージに前記データ・キャッシュをサブスクライブし、
    前記リフレッシュ・メッセージを受信するたびに、前記更新、削除、及び挿入を局所的にキャッシュに入れられたテーブル（７０４）に適用し、
    タイムスタンプを、その効果が前記メッセージ内に含まれるいずれかのトランザクションの最大のタイムスタンプと等しいリフレッシュ・メッセージと関連付け、
    一組のタイムスタンプを、前記キャッシュに適用された最後のリフレッシュ・メッセージの前記タイムスタンプと等しい従前の照会結果と関連付け、
    新しい照会のタイムスタンプを新しい照会と関連付け、
    前記新しい照会のタイムスタンプを前記組のタイムスタンプと比較し、
    前記新しい照会のタイムスタンプが該組のタイムスタンプを超える場合に、該新しい照会への応答を挿入し、
    前記新しい照会のタイムスタンプが前記組のタイムスタンプを超える場合に、前記データベース・サーバから保留のリフレッシュ・メッセージを検索する、
    段階を含むことを特徴とする方法。
25. データベース・サーバから検索された照会結果の組のデータ整合性を確保するためのエッジ・サーバを含む請求項４に記載のシステムであって、前記システムが、
    起点によって伝えられ、バックエンド・テーブルに適用された更新、削除、及び挿入を含むリフレッシュ・メッセージにデータ・キャッシュをサブスクライブするための手段と、
    前記リフレッシュ・メッセージを受信するたびに、前記更新、削除、及び挿入を局所的に前記キャッシュに入れられたテーブルに適用するための手段と、
    タイムスタンプを、その結果が前記メッセージ内に含まれるトランザクションのいずれかの最大の前記タイムスタンプに等しいリフレッシュ・メッセージと関連付けるための手段と、
    一組のタイムスタンプを、前記キャッシュに適用される最後のリフレッシュ・メッセージの前記タイムスタンプと等しい従前の照会結果と関連付けるための手段と、
    新しい照会のタイムスタンプを新しい照会と関連付けるための手段と、
    前記新しい照会のタイムスタンプを前記組のタイムスタンプと比較するための手段と、
    前記新しい照会のタイムスタンプが前記組のタイムスタンプを超える場合に、該新しい照会への応答を挿入するための手段と、
    前記新しい照会のタイムスタンプが前記組のタイムスタンプを超える場合に、前記データベース・サーバから保留のリフレッシュ・メッセージを検索するための手段と、
    をさらに含むシステム。
26. データベース・サーバから検索された照会結果の組のデータ整合性を確保するための請求項５に記載のプログラムであって、コンピュータに、
    起点によって伝えられ、バックエンド・テーブルに適用された更新、削除、及び挿入を含むリフレッシュ・メッセージにデータ・キャッシュをサブスクライブし、
    前記リフレッシュ・メッセージを受信するたびに、前記更新、削除、及び挿入を局所的にキャッシュに入れられたテーブルに適用し、
    タイムスタンプを、その効果が前記メッセージ内に含まれるいずれかのトランザクションの最大のタイムスタンプと等しいリフレッシュ・メッセージと関連付け、
    一組のタイムスタンプを前記キャッシュに適用された最後のリフレッシュ・メッセージの前記タイムスタンプと等しい従前の照会の結果と関連付け、
    新しい照会のタイムスタンプを新しい照会と関連付け、
    前記新しい照会のタイムスタンプを前記組のタイムスタンプと比較し、
    前記新しい照会のタイムスタンプが前記組のタイムスタンプを超える場合に、該新しい照会への応答を挿入し、
    前記新しい照会のタイムスタンプが前記組のタイムスタンプを超える場合に、前記データベース・サーバから保留のリフレッシュ・メッセージを検索する、
    機能をさらに実行させるプログラム。
    

Images