(57)【特許請求の範囲】
【請求項１】
クライアント計算機システムからの要求を受け付け、自システム内もしくは他の計算機システムに処理を転送して結果を取得し、該結果を前記クライアントに対する結果として返すＷｅｂサーバ計算機システム（以下，Ｗｅｂサーバ）とネットワークで接続され、該Ｗｅｂサーバから転送された要求を処理するアプリケーションを実行する、少なくとも１個のアプリケーションサーバ計算機システム（以下、アプリケーションサーバ）と、
該アプリケーションサーバとネットワークで接続され、前記アプリケーションが処理に必要とするデータを管理し、該アプリケーションからの要求に従って、データを参照・更新するデータベースを含む少なくとも１個のデータベースサーバ計算機（以下、データベースサーバ）と、
前記アプリケーションサーバと前記データベースサーバにネットワークで接続され、該データベースサーバのデータの一部をキャッシュし、該アプリケーションサーバからの該データベースサーバへの要求のうち、自システムで処理可能な要求を処理し、処理が不可能な要求はデータベースサーバに転送するキャッシュデータベースを備える少なくとも１個のキャッシュデータベースサーバ計算機（以下、キャッシュデータベースサーバ）を含み、
前記キャッシュデータベースサーバは、
前記キャッシュデータベース上でのデータの更新の可否を指定するカラムを有するデータ管理テーブルと、
前記データ管理テーブルの前記カラムの指定値に応じてキャッシュデータベース上でのデータの更新可否を決定する機構とを有することを特徴とするＷｅｂシステム。
【請求項２】
前記データ管理テーブルは前記キャッシュデータベースに実際にキャッシュされているデータを特定する第１の条件を格納し、
前記キャッシュデータベースサーバは、前記キャッシュデータベースサーバは、前記実際にキャッシュされているデータを特定する第１の条件と、アプリケーションから転送された問合せ中の第２の条件を比較し、第１の条件が第２の条件を包含する場合には、前記問合せをキャッシュデータベース中のデータを用いて処理するように書き換える問合せ変換部と、
該変換された問合せを前記キャッシュデータベースに対して発行する問合せ発行部と、
該発行された問合せを受け付け、キャッシュデータベース中のデータを検索・更新するデータ検索・更新部と、
前記第１の条件が前記第２の条件を包含しない場合には、前記アプリケーションから転送された問合せを、前記格納データ管理テーブル中に指定されているキャッシュするデータの形式で必要なデータを全て取得するように変換する問合せ変換部と、
該変換された問合せをデータベースサーバに対して発行する問合せ発行部と、
を有することを特徴とする請求項１に記載のＷｅｂシステム。
【請求項３】
前記データベースサーバは、
（１）自データベースで管理するデータと、（２）該データをキャッシュするキャッシュデータベース名もしくは該キャッシュデータベースを識別するＩＤと、（３）該キャッシュデータベースでキャッシュされるデータの範囲を指定するキャッシュ対象データ条件と、（４）キャッシュ先のキャッシュデータベースでのキャッシュデータの更新可否と、（５）該キャッシュデータベースの稼動状況と、（６）キャッシュデータベースにキャッシュ済みのデータの範囲とを格納するキャッシュデータベース管理テーブル、および
該キャッシュデータベース管理テーブル中のデータに基づきトランザクション処理を行うトランザクション管理部、
を有することを特徴とする請求項１に記載のＷｅｂシステム。
【請求項４】
前記トランザクション管理部は、
データベースサーバで実行すべきトランザクションが参照するデータの範囲を示す第１の条件と、前記キャッシュデータベース管理テーブル中のキャッシュ対象条件である第２の条件を比較し、
前記第１の条件と前記第２の条件に共通部分が存在しない場合、もしくはトランザクションが参照処理のみからなり、かつ前記第１の条件と共通部分を持つ前記第２の条件が含まれるテーブル中のレコードのキャッシュデータベースでの更新可否欄が全て更新否の場合には、キャッシュデータベースの同期・閉塞処理を行わずにトランザクションを実行し、
それ以外の場合には、前記第１の条件１と共通部分を持つ前記第２の条件が含まれるキャッシュデータベース管理テーブル中のキャッシュデータベース名に含まれる全てのキャッシュデータベースの同期・閉塞処理を行ってからトランザクションを実行することを特徴とする請求項３に記載のＷｅｂシステム。
【請求項５】
少なくとも１個のアプリケーションサーバと、該アプリケーションサーバ上のアプリケーションが処理に必要とするデータを管理し、該アプリケーションからの要求に従ってデータを更新・参照するデータベースを含む少なくとも１個のデータベースサーバとに接続して用いられ、前記データベースのデータの一部をキャッシュするキャッシュデータベースを管理するキャッシュデータベースサーバで実行される問合せ処理方法であり、
前記キャッシュデータベースにキャッシュするデータ形式、および該キャッシュデータベースに実際にキャッシュされているデータを特定する第１の条件を格納データ管理テーブルに格納し、
前記アプリケーションサーバから転送された問合せ中の第２の条件を前記第１の条件と比較し、
前記第１の条件が前記第２の条件を包含する場合は、前記問合せを前記キャッシュデータベースのデータを用いて処理するうに変換し、かつ変換した問合せを前記キャッシュデータベースに発行し、
前記第１の条件が前記第２の条件を包含しない場合は、前記転送された問合せを、前記格納テーブル中に指定されているキャッシュするデータ形式で必要なデータを全て要求する問合せに変換し、
変換した問合せを前記データベースサーバに再転送することを特徴とするキャッシュデータベースサーバの問合せ処理方法。
【請求項６】
請求項５に記載の問合せ処理方法において、前記キャッシュデータベースに発行する問合せの処理に伴う該キャッシュデータベースの更新処理の手順として、
更新処理実行のための十分な領域が前記キャッシュデータベース上に存在する場合には、キャッシュデータベースへの更新履歴をキャッシュデータベースログに記録して、キャッシュデータベース上でのみデータの更新を行い、
前記キャッシュデータベース上で空き領域が不足した場合には、必要な領域を確保するためにキャッシュ上から削除するデータを決定し、
該削除対象データがキャッシュ上で更新されていた場合のみ、該削除対象データの更新履歴をおよび更新データをサーバへコミットし、
該コミット処理が成功した場合に該削除対象データをキャッシュデータベースより削除し、
該削除対象データの削除処理によって生成された空き領域を利用して更新処理を実行する、
との手順を更に有することを特徴とするキャッシュデータベースの問合せ処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、アプリケーションサーバのクラスタ化方法、およびデータベースサーバのデータをキャッシュするキャッシュデータベースクラスタの構成方法、およびこれら方法を用いて構成されたＷｅｂシステムに関する。
【０００２】
【従来の技術】
Ｗｅｂ環境でのシステム構築では、大規模構成での性能確保、およびシステム負荷の急激な変動に柔軟に対応できる運用性向上という２つの観点から、スケーラビリティの確保が重要な課題となっている。特に近年、多数のユーザが実時間処理に近いシステムレスポンスを要求する大規模なＥＣサイトや、ユーザごとにカスタマイズされたページを動的に生成するポータルサイトが盛んに構築されつつある。これらのシステムではデータベースに対するアクセス数が従来よりも著しく増加することが予想され、スケーラビリティの確保はますます重要な課題となっている。
Ｗｅｂシステムの構築では現在、図３に示すようにＷｅｂサーバ（３０４、３０５）−アプリケーションサーバ（３０７）−データベースサーバ（３０９）の３階層構成が用いられるのが普通である。クライアントからの該Ｗｅｂシステム利用セッションの例を図３を用いて説明する。クライアント計算機３０１、３０２（以下、クライアント）はネットワーク３０３を介して前記Ｗｅｂサーバにリクエストを発行する。該リクエストを受け付けたＷｅｂサーバは、ネットワーク３０６を介して、該リクエストを前記アプリケーションサーバに転送する。アプリケーションサーバでは前記リクエストを処理するアプリケーションを実行して処理結果を生成し、該処理結果をＷｅｂサーバに返す。Ｗｅｂサーバはアプリケーションサーバより受け取った処理結果を埋め込んだＷｅｂページを作成してクライアントに返し、１回のセッションが終了する。さらに、前記アプリケーションが前記データベースサーバ中のデータベース（３１１）へのアクセスを必要とする場合、アプリケーションサーバはネットワーク３０８を介してデータベースサーバ３０９にアクセスし、データベースサーバ内のデータベースシステム３１０を介してデータベース３１１内のデータを取得もしくは更新する。
図３のシステム構成で示す通り、ＷｅｂシステムではＷｅｂサーバをクラスタシステムで構成することが多い。例えば図３ではＷｅｂサーバ１（３０４）からＷｅｂサーバＬ（３０５）のＬ個のクラスタが用いられている。Ｗｅｂサーバのクラスタ化は、主にクライアントの増加等の負荷増大に対応するスケーラビリティ確保の目的で行われる。Ｗｅｂサーバのクラスタ化が容易な理由として、クライアントとＷｅｂサーバ間の通信で用いられるＨｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（以下、ＨＴＴＰ）が状態を保持しない（ｓｔａｔｅｌｅｓｓ）ことがあげられる。ＨＴＴＰが状態を持たないということは、クライアントとＷｅｂサーバ間の通信は通信が行われる毎に新たなセッションとすればよいため、そのセッションをクラスタ中の任意のＷｅｂサーバに割り当てればよいことを意味する。すなわち、ユーザの増加等の負荷増大に対して、ラックマウントタイプの薄型のサーバを順次追加してシステムを増強するというような対応が可能となる。
これに対してアプリケーションサーバは、アプリケーションが状態（ｓｔａｔｅ）を持つため、単純にサーバ（ハードウェア）をクラスタ化してもうまくいかなかった。具体例を挙げてその理由を説明する。負荷を分散させるために複数のアプリケーションサーバで同一のアプリケーションを実行させた環境を想定する。Ｗｅｂシステムではユーザとのインタラクションによって処理を進めるのが普通である。例えば、Ｗｅｂサイトで本を購入する処理を考えた場合、（１）最初に本を検索し、次に（２）検索した中から購入する本を決定し、（３）購入した本の送付先を入力し、（４）最後にクレジットカード等で決済を行う。この論理的なセッション（以下論理セッションと呼ぶ）である購入処理（１）〜（４）が１つのアプリケーションとして実現されているとすると、該アプリケーションは（１）〜（４）のそれぞれのフェーズでクライアント−Ｗｅｂブラウザ間のＨＴＴＰプロトコルを用いたＷｅｂセッション（以下、Ｗｅｂセッションと呼ぶ）を伴う。
アプリケーションサーバが１つだけの場合には、例えＷｅｂサーバがクラスタ化され、複数であったとしてもアプリケーションサーバ中に（１）〜（４）の論理セッションの状態を保存することにより処理を継続できる。例えば、特開平１１−１４９４４９には、データベースサーバで、処理を行う際にセッションＩＤを付与してその処理状態を保持し、継続が必要な処理に対してはクライアントにセッションＩＤを転送し、クライアントからのリクエストにセッションＩＤが含まれている場合には保持した状態から処理を継続する方法が開示されている。該方法ではセッションを実行するスレッドを停止することによって状態を保持し、リクエストによって該スレッドの実行を再開することで処理を継続する。しかしながら該方法を用いた場合にも、アプリケーションを継続実行するサーバの変更は困難である。なぜならば、前記（１）〜（４）の各Ｗｅｂセッションが異なるＷｅｂサーバに割り当てられ、該Ｗｅｂサーバから前回処理を行っていたアプリケーションサーバと異なるサーバにリクエストが転送された場合に、前回までの論理セッション状態を得ることができず、該論理セッションを継続することができないためである。
データベースサーバに関してはデータの一貫性確保のため、通常１つのデータベース管理システムで全データを集中管理する。このため、アプリケーションサーバと同様にクラスタ化によるスケーラビリティ向上は困難であった。文献"Ｏｒａｃｌｅ  ９ｉ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ  Ｄａｔａｂａｓｅ  ｃａｃｈｅ"には、アプリケーションサーの性能向上のための方法を開示している。該方法では、データベースサーバ中のデータをテーブル単位でＷｅｂサーバにキャッシュし、必要に応じて該キャッシュデータを利用してデータベースサーバへのアクセスを回避する。これにより、データベースサーバの負荷を削減し、スケーラビリティを向上させる。しかしながら、該方法では更新処理が発生した場合にはキャッシュでは処理が行えず、結局データベースサーバでの処理が必要となり性能が低下する。また、通常データベースサーバ上のテーブルはそのサイズが非常に大きいため、Ｗｅｂサーバで通常用いられる安価なクラスタサーバを用いた場合にはテーブル単位のキャッシングは不可能な場面も多い。
【０００３】
【発明が解決しようとする課題】
大規模構成のＷｅｂシステム構築においては、アプリケーションサーバおよびデータベースサーバのスケーラビリティの確保が困難であり、ユーザの増加、システム負荷の急激な増加への対応が課題となっていた。
さらに、スケーラビリティの確保が困難であることに起因して、Ｗｅｂシステムの性能を確保するために、処理のボトルネックとなるアプリケーションサーバやデータベースサーバに高価な高多重ＳＭＰサーバを用いる必要があり、が不可能となっていた。
本発明の一つの目的は、システムのスケーラビリティを高め、ひいては要求される規模の大小によらず性能を確保が容易なＷｅｂシステムを提供するにある。
本発明の具体的な目的は、アプリケーションサーバのクラスタ化を可能とする方法を提供することである。
本発明の別の具体的な目的は、データベースサーバのクラスタ化されたキャッシュ（以下、キャッシュデータベースクラスタと呼ぶ）を提供することである。
さらに別の具体的な目的は、アプリケーションサーバやデータベースサーバに効果な項多重ＳＭＰサーバではなくクラスタを用い、ストパフォーマンスの高いＷｅｂシステム構築方法を提供することである。
【０００４】
【課題を解決するための手段】
前記の目的を達成するための本発明の代表的構成を以下に列挙する。
まず、本発明ではアプリケーションの論理セッション状態を必要に応じてクラスタ化したキャッシュデータベースに保存し、該セッション状態をキャッシュデータベースから読み出す機構を提供する。本機構を利用することにより、前記アプリケーションの処理を異なるクラスタサーバ上で動作する該アプリケーションで継続実行することができ、アプリケーションサーバのクラスタ化が可能となる。また、本発明ではクラスタサーバ上に更新が可能なキャッシュデータベースクラスタを作成し、データベースサーバの負荷を削減する。該更新処理の整合性を確保するために、必要に応じてデータベースサーバと同期させる機構を提供する。キャッシュデータベースクラスタ内のキャッシュデータベースは、テーブルを部分的にキャッシュすることも可能であり、キャッシュの空き容量に応じて最適なキャッシングを実現する。本機構により、更新処理時のデータベースサーバへのアクセスも削減でき、データベースサーバのスケーラビリティを高めることができる。
また、前記アプリケーションサーバのクラスタ化方法、前記キャッシュデータベースクラスタ構成方法に加えて、本発明ではキャッシュデータベースクラスタに対するキャッシュデータベースの自動追加機構を提供する。本機構を用いることにより、容易にコストパフォーマンスが高く、しかもスケーラビリティが高いクラスタシステムが構築できる。
【０００５】
【発明の実施の形態】
本発明を適用した好適なＷｅｂシステムの実施形態を図１に示す。図１ではクライアント計算機１（１０１）〜クライアント計算機Ｋ（１０２）がネットワーク１０３を介してＷｅｂサーバ１（１０４）〜ＷｅｂサーバＬ（１０５）に接続されている。Ｗｅｂサーバはさらに、ネットワーク１０９を介してアプリケーションサーバ１（１０７）〜アプリケーションサーバＭ（１０８）に接続されている。また、前記アプリケーションサーバはネットワーク１０９を介してキャッシュデータベースクラスタ１１０に接続されている。
キャッシュデータベースクラスタは複数のキャッシュデータベースサーバで構成される。例えば、図１では前記キャッシュデータベースクラスタにはキャッシュデータベースサーバ１（１１１）〜キャッシュデータベースサーバＮ（１１３）のＮ個のクラスタサーバが含まれている。それぞれのキャッシュデータベースサーバは、内部にキャッシュデータベース（１１２、１１８）を含む。キャッシュデータベースサーバの内部構成に関しては後述する。
さらに、前記キャッシュデータベースクラスタはネットワーク１１７を介してデータベースサーバ１（１１４）〜データベースサーバＯ（１２０）に接続されている。該データベースサーバはその内部に、元データを管理するデータベース１１６、１２０を含む。データベースサーバの内部構成に関しても後述する。
ネットワーク１０３、１０６、１０９、および１１７はイーサネット、光ファイバ等で接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。クライアント計算機は、（株）日立製作所のＨｉｔａｃｈｉ  ＦＬＯＲＡなどのパーソナルコンピュータ、（株）日立製作所のＨｉｔａｃｈｉ  ９０００ＶワークステーションシリーズＪ６０００などの任意のコンピュータシステム、（株）日立製作所のＰｅｒｓｏｎａなどの携帯端末、もしくは問合せインタフェースを持つ携帯電話でも差し支えない。また、前記Ｗｅｂサーバ、前記アプリケーションサーバ、前記キャッシュデータベースサーバは（株）日立製作所のＨｉｔａｃｈｉ  ９０００ＶワークステーションシリーズＪ６０００などの任意のワークステーション、（株）日立製作所のＨｉｔａｃｈｉ  ９０００Ｖ  Ａ５００などの省スペースローエンドサーバで差し支えない。前記データベースサーバは（株）日立製作所のＨｉｔａｃｈｉ  ９０００ＶハイエンドサーバＶＴ８５０もしくはミッドレンジサーバＮ４０００で差し支えない。
以下では、図１の構成のＷｅｂシステムにおける、（１）アプリケーションサーバクラスタ化方法、（２）キャッシュデータベースクラスタ構成方法および利用方法を説明する。（２）に関してはさらに、（ｉ）キャッシュデータベースクラスタを用いた問合せ処理方法、（ｉｉ）データベースサーバでのトランザクション処理方法、そして（ｉｉｉ）キャッシュデータベース追加処理方法の順に例に基づいて説明する。
なお、Ｗｅｂシステムにおいては、ユーザはクライアント計算機上で稼動する専用プログラム、もしくはＭｉｃｒｏｓｏｆｔ社のＩｎｔｅｒｎｅｔ  ＥｘｐｌｏｒｅｒやＮｅｔｓｃａｐｅ社のＮｅｔｓｃａｐｅ  ＣｏｍｍｕｎｉｃａｔｏｒなどのＷｅｂブラウザを利用してシステムに対して問合せを発行し、該問合せに対する結果を取得するのが普通である。そのため、厳密には問合せの発行元および最終結果取得先はユーザとなるが、以降の説明では簡単のため、問合せの発行元、最終結果の取得先をクライアントと考える。本単純化は、本発明の本質には影響を及ぼさない。
最初にアプリケーションサーバクラスタ化方法を説明する。本発明の好適な実施例では、図１で示すようにクライアントから発行された問合せはＷｅｂサーバで受け付けられ、処理に必要なアプリケーションを実行するアプリケーションサーバに転送される。従来の技術で述べた通り、通常アプリケーションは状態を保持するため、任意のアプリケーションサーバ上で稼動するアプリケーションに処理を割り当てても該処理を継続できず、Ｗｅｂシステムでのアプリケーションサーバのクラスタ化は困難であった。そこで、本実施例では論理セッションの状態をキャッシュデータベースクラスタ１１０中のいずれかのキャッシュデータベース（１１２、１１８）に保存し、該保存状態をアプリケーションで読み出す機構を提供することにより、任意のアプリケーションサーバ上のアプリケーションで処理の継続を可能とする。以下では、アプリケーションのキャッシュデータベースへの状態保存方法、および該保存状態を用いた論理セッション継続処理の詳細を説明する。
アプリケーションサーバ１（１０７）上で稼動するアプリケーションが論理セッション状態を保存する処理を説明する。処理の流れを示すフローチャートを図１４に示す。最初に、状態を保存しようとするアプリケーションは、状態を保存するキャッシュデータベースを決定する（ステップ１４０２）。該キャッシュデータベースの決定方法としては、例えばシステム内でユニークな値となるセッションＩＤにハッシュ関数を適用して保存先のキャッシュデータベースを決定すればよい。システム内でユニークな値となるセッションＩＤの生成方法としては、例えばＷｅｂサーバの固有ＩＤと該Ｗｅｂサーバ内で生成したユニークなＩＤの連結を行えばよい。
本の購入セッションの例で説明したように、論理セッション内には複数のＨＴＴＰセッションが含まれる。クラスタ化したＷｅｂサーバで、論理セッション毎にユニークなセッションＩＤを付与するためには、（１）クライアントからのリクエストにセッションＩＤが含まれていない場合には前述のユニークなセッションＩＤを生成し、論理セッションの途中でクライアントとＨＴＴＰセッションを行う際には、前記セッションＩＤを付与した値を返す。（２）クライアントからリクエストにセッションＩＤが含まれている場合には、該セッションＩＤを用いる、という方法を用いればよい。
状態保存先キャッシュデータベースの決定後、アプリケーションの状態をキャッシュデータベースに書き込む（ステップ１４０３）。キャッシュデータベースでの状態書き込み、および該状態の読み出し処理は、図２に示すキャッシュデータベースサーバ内のセッション管理部（２０７）が行い、書き込まれるデータはセッション管理テーブル２２２として保持される。該セッション管理テーブルは、キャッシュデータベース１１２内にデータベーステーブルとして保持しても、もしくはキャッシュデータベースサーバのメモリ上に保持しても、もしくはキャッシュデータベースサーバ上のファイルとして保持するのでも差し支えない。
セッション管理テーブルの例を図１６に示す。保持する情報はセッションＩＤ、継続対象のアプリケーション名とその継続チェックポイント、および継続時に利用する変数とその値の組である。例えばセッションＩＤが１００２１の論理セッションに関しては、そのアプリケーション名がｃｕｓｔｏｍｅｒ＿ｍａｎａｇｅｍｅｎｔ、セッションの進行状況を表すチェックポイントが１５、該チェックポイントで保存すべき変数はｃ＿ｉｄおよびｃ＿ｎａｍｅで、その値はそれぞれ、１０、"Ｉｔａｒｕ  Ｎｉｓｈｉｚａｗａ"である。状態の書き込み後、アプリケーションはクライアントに現在のセッションＩＤを返し（ステップ１４０４）、論理セッション状態保存処理を終了する（ステップ１４０５）。
次に、キャッシュデータベースに保存された論理セッション状態を利用してアプリケーションを継続するための方法を図１５のフローチャートを用いて説明する。アプリケーションサーバはＷｅｂサーバからリクエストを受け付けると、該リクエストにセッションＩＤが含まれているか否かをチェックする。セッションＩＤが含まれている場合、該セッションＩＤから論理セッション状態を書き込んだ場合と同様の方法でキャッシュデータベースを特定し（ステップ１５０８）、該キャッシュデータベース中の論理セッション状態を検索する（ステップ１５０２）。キャッシュデータベース中に論理セッションの状態が保存されていなかった場合（ステップ１５０３でＮｏが選択された場合）、継続処理はアボートする（ステップ１５０８）。論理セッションの状態が保存されていた場合（ステップ１５０３でＹｅｓが選択された場合）には、キャッシュデータベースから該論理セッション状態を読み出す（ステップ１５０４）。例えば、セッションＩＤとして１００２１が指定されたとすると、図１６のセッション管理テーブルの検索により、アプリケーションｃｕｓｔｏｍｅｒ＿ｍａｎａｇｅｍｅｎｔがチェックポイント１５で停止しており、該チェックポイントでの変数とその値がｃ＿ｉｄ＝１０、ｃ＿ｎａｍｅ＝"Ｉｔａｒｕ  Ｎｉｓｈｉｚａｗａ"であることがわかる。状態読み出し後、キャッシュデータベースから該論理セッション状態を削除する（ステップ１５０５）。そして読み出した状態を利用してアプリケーションセッション（論理セッション）を継続する（ステップ１５０６）。
以上で、キャッシュデータベースへの状態保存し、該保存データ読み出し機構を利用したアプリケーションの処理継続方法を説明した。該方法によって、アプリケーションサーバのクラスタ化が可能となり、アプリケーションサーバのスケーラビリティが向上する。
次に、データベースサーバのスケーラビリティを向上させるためのキャッシュデータベースクラスタの構成方法、およびその利用方法について説明する。
最初にキャッシュデータベースクラスタを用いた問合せ処理方法を説明する。前述した通り、キャッシュデータベースクラスタ中の各キャッシュデータベースは、アプリケーションからのデータベースサーバへのアクセスの際にデータをキャッシュし、データベースサーバへのアクセスを削減することによって、システム全体のスケーラビリティを向上させる。
図１の構成のＷｅｂシステムでは、アプリケーションサーバは所望のデータを取得するためにキャッシュデータベースクラスタ１１０にアクセスする。該アプリケーションが該キャッシュデータベースクラスタ中のどのキャッシュデータベースにアクセスするかを決定するための方法としては、例えば図１７に示すような、アプリケーションで利用するデータと該データを格納するキャッシュデータベースの組合せを記述する、アプリケーション−キャッシュデータベースマッピングテーブルをアプリケーションサーバに保持し（１２１、１２２）、該テーブルを参照すればよい。例えば、図１７の該テーブルの参照により、アプリケーションｃｕｓｔｏｍｅｒ＿ｍａｎａｇｅｍｅｎｔが参照するテーブルｃ＿ａｄｄｒｅｓｓのｃ＿ｉｄ＝１００のデータを参照するためには、キャッシュデータベースサーバのキャッシュデータベース１を参照すればよいことがわかる。本発明のキャッシュデータベースクラスタでは、各キャッシュデータベースへ格納されるデータ自体は頻繁に更新されるが、キャッシュされるべきデータの範囲の変更は頻繁には行われない。そのため、該テーブルの更新は後述するキャッシュデータベース再編成処理時に実行するので差し支えない。
アクセス対象となるキャッシュデータベースを決定した後の、キャッシュデータベースサーバでの問合せ処理ステップを図２、および図４のフローチャートを用いて説明する。但し、以下の例ではアプリケーションがアクセス対象のキャッシュデータベースとして、キャッシュデータベース１を選択したと仮定する。アプリケーションサーバより転送された問合せは、キャッシュデータベースサーバ１（１１１）のネットワークインタフェース部２０２を介して、キャッシュ利用可否判定部（２０３）に送られる。該キャッシュ利用可否判定部では、キャッシュデータベース内に所望のデータが存在するか否かを、格納データ管理テーブル２２３を用いてチェックする。該格納データ管理テーブルの具体例を図５に示す。格納データ管理テーブル２２３には、キャッシュデータベース１で管理されるキャッシュデータに関する情報が格納されている。データベースサーバ名（５０２）およびデータベース名（５０３）は、キャッシング対象のデータベースサーバ名と該データベースサーバ中のデータベース名を、テーブル名および属性名（５０４）はキャッシュ対象のテーブル名と属性名を、分割キー（５０５）は該テーブルをキャッシュデータベースクラスタ間で分割格納する際の分割キーを、キャッシュ対象データ条件（５０６）はキャッシュ対象となるデータの条件を、キャッシュ済みデータ条件（５０７）は前記キャッシュ対象データ条件を満たし、かつ実際にキャッシュデータベース１にキャッシュされているデータの範囲を、リフレッシュポリシー（５０８）はキャッシュデータのリフレッシュを行う際の置き換えポリシーを、そして更新可否（５０９）は、キャッシュデータベース１上でキャッシュデータに関する更新の可否を表している。例えば、格納データ管理テーブル２０３の１行目のレコードは、キャッシュデータベース１のキャッシングの対象が、データベースサーバ１のＣｕｓｔｏｍｅｒデータベース中のｃ＿ａｄｄｒｅｓｓテーブルのｃ＿ｉｄ、ｃ＿ｎａｍｅ、ｃ＿ａｄｄｒｅｓｓ、ｃ＿ｐｈｏｎｅの４つの属性からなり、かつ１＜＝ｃ＿ｉｄ＜１０００００の条件を満たすレコードであること、また現在は該キャッシング対象のうち１＜＝ｃ＿ｉｄ＜５００００の条件を満たすレコードが実際にキャッシングされていること、そして該キャッシングデータをリフレッシュする際のポリシーがＬＲＵで、該データのキャッシュデータベース１上での更新は可であることを示している。該格納データ管理テーブルにおいて、キャッシュ済みデータ条件は範囲指定の条件で示されているが、格納データを表すビットマップを用いる実現も可能である。
図４に戻って、キャッシュデータベース内にデータが存在する場合（ステップ４０２でＹｅｓが選択された場合）には、アプリケーションからデータベースサーバ向けの発行された問合せをキャッシュデータベース中のデータを参照するように変換する（ステップ４０３）。キャッシュデータベース内に存在するデータで、与えられた問合せを処理可能か否かの判定は、問合せと前記キャッシュ済みデータ条件を比較することによって行うことができる。判定のための方法としては、例えばＪｅｆｆｒｅｙ  Ｄ．Ｕｌｌｍａｎ著、"ＰＲＩＮＣＩＰＬＥＳ  ＯＦＤＡＴＡＢＡＳＥ  ＡＮＤ  ＫＮＯＷＬＥＤＧＥ−ＢＡＳＥ  ＳＹＳＴＥＭＳ"、ＶＯＬＵＭＥ  ＩＩ，ＣＯＭＰＵＴＥＲ  ＳＣＩＥＮＣＥ  ＰＲＥＳＳ，ＩＳＢＮ  ０−７１６７−８１６２−Ｘ，第１４章"Ｏｐｔｉｍｉｚａｔｉｏｎ  ｆｏｒ  Ｃｏｎｊｕｎｃｔｉｖｅ  Ｑｕｅｒｉｅｓ"（文献４）に開示されている、Ｑｕｅｒｙ  Ｅｑｕｉｖａｌｅｎｃｅ、Ｑｕｅｒｙ  Ｃｏｎｔａｉｎｍｅｎｔと呼ばれる方式を用いることにより、条件間の同値関係および包含関係を調べることができる。該方式を用いて前記キャッシュ済みデータ条件と問合せの条件の関係を判定し、キャッシュ済みデータ条件が問合せ条件を包含する、もしくは等しい場合にはキャッシュ内のデータを用いて問合せが処理可能と判定できる。該問合せが参照処理のみを含む場合（ステップ４０４でＮｏが選択された場合）には、キャッシュデータベースより結果を取得し、アプリケーションに返して（ステップ４０５）、問合せ処理を終了する（ステップ４０６）。前記問合せ変換処理は図２における問合せ変換部２０４で、キャッシュデータベースに対する問合せ発行および結果取得は、問合せ発行部２０５で発行した問合せをデータ検索・更新部２０６がキャッシュデータベース１１２中のキャッシュ済みデータ２１０を検索し、その値を取得することで実行する。
前記問合せがデータベースに対するデータ更新、データ削除、データ追加のいずれかの処理（データベースの標準問合せ言語ＳＱＬではＵＰＤＡＴＥ，ＩＮＳＥＲＴ，ＤＥＬＥＴＥに相当する）を含む場合（ステップ４０４でＹｅｓが選択された場合）には、キャッシュデータベース更新処理を実行し（ステップ４０７）、更新処理結果のステータスをアプリケーションに返して（ステップ４０８）、キャッシュデータベースサーバでの問合せ処理を終了する（ステップ４０６）。前記キャッシュデータベース更新処理を図７のフローチャートを用いて説明する。先に述べた通り、本発明で想定するデータベースの更新処理はデータ更新、データ削除、もしくはデータ追加のいずれかである。もし更新処理がデータ更新の場合（ステップ７０２でＹｅｓ、ステップ７０３でＮｏが選択された場合）、更新データサイズが更新前の元データサイズと等しいかそれよりも小さいかをチェックする（ステップ７０４）。もし更新データサイズが元データサイズと等しいかそれよりも小さい場合（ステップ７０４でＹｅｓが選択された場合、キャッシュデータベースに更新後の値を保存することができるため、更新内容をキャッシュデータベースログ（但し図７および図８では単にログと表す）に記録し（ステップ７１３）、キャッシュデータベースのデータを更新し（ステップ７１４）、図５の格納データ管理テーブルのキャッシュ済みデータ条件（５０７）のエントリが存在する場合にはその値を更新して（ステップ７０８）、キャッシュデータベース更新処理を終了する（ステップ７０９）。前記更新内容を記録したキャッシュデータベースログ２１１は、図２のキャッシュデータベース１１２中に保持され、キャッシュデータベースに対する更新の履歴を全て管理する。該キャッシュデータベースログ管理機構は、例えば（株）日立製作所のＨｉＲＤＢなどの汎用ＤＢＭＳ製品を用いて実現することができる。
図７のステップ７０４に戻り、更新データサイズが更新前の元データサイズよりも大きい場合（ステップ７０４でＮｏが選択された場合）には、キャッシュスロット確保処理を実行し（ステップ７０５）、更新内容を前記キャッシュデータベースログに記録し（ステップ７０６）、キャッシュデータベースのデータを更新し（ステップ７０７）、前記格納データ管理テーブルのキャッシュ済みデータ条件（図５の５０７）のエントリが存在する場合にはその値を更新して（ステップ７０８）、キャッシュデータベース更新処理を終了する（ステップ７０９）。キャッシュスロット確保処理に関しては後述する。
更新処理がデータ削除の場合（ステップ７０２、７０３でともにＹｅｓが選択された場合）、更新内容を前記キャッシュデータベースログに記録し（ステップ７１１）、キャッシュデータベースから該当するデータを削除して（ステップ７１２）、前記格納データ管理テーブルのキャッシュ済みデータ条件（図５の５０７）のエントリが存在する場合にはその値を更新して（ステップ７０８）、キャッシュデータベース更新処理を終了する（ステップ７０９）。
最後に、更新処理がデータ追加の場合（ステップ７０２でＮｏが選択された場合）、追加のための領域が存在するか否かをチェックする（ステップ７１０）。追加のための領域が存在する場合（ステップ７１０でＹｅｓが選択された場合）には、更新内容を前記キャッシュデータベースログに記録し（ステップ７１６）、キャッシュデータベースにデータを追加して（ステップ７１７）、前記格納データ管理テーブルのキャッシュ済みデータ条件（５０７）のエントリが存在する場合にはその値を更新して（ステップ７０８）、キャッシュデータベース更新処理を終了する（ステップ７０９）。追加のための領域が存在しない場合（ステップ７１０でＮｏが選択された場合）には、キャッシュスロット確保処理を実行し（ステップ７１５）、更新内容を前記キャッシュデータベースログに記録し（７１６）、キャッシュデータベースにデータを追加して（ステップ７１７）、前記格納データ管理テーブルのキャッシュ済みデータ条件（５０７）のエントリが存在する場合にはその値を更新して（ステップ７０８）、キャッシュデータベース更新処理を終了する（ステップ７０９）。
前記キャッシュスロット確保処理を図８のフローチャートを用いて説明する。キャッシュスロット確保処理とは、キャッシュデータベースに新たなデータをキャッシュするための領域が不足している場合に、該データをキャッシュするための空き領域を作成するための処理である。最初に新しいデータをキャッシュするために必要な領域のサイズを計算し、現在キャッシュ中にあるデータのうち、キャッシュから削除するデータ（以下、書き戻し対象データと呼ぶ）を決定する（ステップ８０２）。該決定は、図２の格納データ管理テーブル２２３を用いてキャッシュ管理部２０８が行う。図５の格納データ管理テーブルの具体例を用いて、書き戻し対象データの決定方法を説明する。前記格納データ管理テーブルには、リフレッシュポリシー（５０７）のエントリが存在する。書き戻し対象データの決定は、該エントリのポリシーに従って実行する。例えば、テーブルｃ＿ａｄｄｒｅｓｓのキャッシュデータ中から１つのレコードを削除したい場合、該テーブルのリフレッシュポリシーはＬＲＵであるので、キャッシュ中のデータのうち、最も参照された日時が古いものを削除対象として選択する。
書き戻し対象データを決定した後、該書き戻し対象データに関するエントリが前記キャッシュデータベースログ中に存在するか否かをチェックする（ステップ８０３）。キャッシュデータベースログ中にエントリが存在するということは、該書き戻し対象データがキャッシュ上で更新されていることを示しており、該書き戻し対象データをキャッシュデータベースから削除する際には、該変更をデータベースサーバに反映する必要がある。よって、キャッシュデータベースログ中にエントリが存在する場合（ステップ８０３でＹｅｓが選択された場合）には、該書き戻し対象データおよび該データに関するキャッシュデータベースログをデータベースサーバにコミットする（ステップ８０４）。書き戻し対象データの変更の有無をキャッシュデータベースログの解析により判定するコストを削減するためには、レコードの更新の有無を判定するビットマップを準備し、ビットマップのチェックで更新を確認した場合のみキャッシュデータベースログを解析する実現例が考えられる。
図８に戻り、前記コミットが成功した場合（ステップ８０５でＹｅｓが選択された場合）には、キャッシュデータベースから書き戻し対象データを削除し（ステップ８０６）、キャッシュスロット確保処理を終了する（ステップ８０７）。データベースサーバへのコミットが失敗した場合（ステップ８０５でＮｏが選択された場合）には、書き戻し対象として他のデータを選択してリトライするか否かを選択する（ステップ８０８）。リトライする場合（ステップ８０８でＹｅｓが選択された場合）にはステップ８０２に戻り、前述の処理を繰り返す。リトライしない場合（ステップ８０８でＮｏが選択された場合）には、キャッシュスロット確保処理をアボートする（ステップ８０９）。
再び図４のキャッシュデータベースサーバでの問合せ処理のステップ４０２に戻って、キャッシュデータベース内にデータが存在しない場合（ステップ４０２でＮｏが選択された場合）には、データベースサーバ向けに問合せを変換（ステップ４１３）、転送し（ステップ４０９）、該問合せに対する結果を取得して（ステップ４１０）、アプリケーションに該取得した値を返す（ステップ４１１）。前記問合せ変換、および転送処理はそれぞれ、図２の問合せ変換部２０４および問合せ発行部２０５、ネットワークインタフェース部２０２で実行される。ステップ４１３のサーバ向けの問合せ変換に関して、図５の格納データ管理テーブルを用いて具体例を説明する。キャッシュデータベース１に対してアプリケーションから、図１８の１８０１に示す問合せが発行された場合を考える。該問合せは顧客ＩＤ（ｃ＿ｉｄ）が６００００の顧客の氏名（ｃ＿ｎａｍｅ）を求めることに相当する。図５の１行目のレコードのキャッシュ済みデータ条件（５０７）が示す通り、該顧客氏名はキャッシュデータベース中にはなく、データベースサーバへの転送が必要となる。データベースサーバ１１４では、前記キャッシュデータベースサーバから転送された問合せをネットワークインタフェース部で受け付け、データ管理・検査部２１８がデータベース１１８を検索し、格納されている元データ２２１から問合せの条件を満足するレコードを取り出し、キャッシュデータベースサーバに返す。
しかしながら、問合せ１８０１をそのままデータベースサーバに転送して結果を取得すると、取得結果はｃ＿ｎａｍｅのみを含むことになり、図５のキャッシュしているテーブルおよび属性名を示す「テーブル名および属性名」のエントリ（５０４）のエントリとして必要な他の３つの属性（ｃ＿ｉｄ，ｃ＿ａｄｄｒｅｓｓ，ｃ＿ｐｈｏｎｅ）の値を含まず、そのままではキャッシングが不可能である。そこで、問合せ１８０１はデータベースサーバに転送される前に、１８０２に示すようにキャッシングに必要な他の属性も含む形に変換される。
問合せ処理は、該変換後の問合せによって取得したレコードを用いて、キャッシュデータベースリフレッシュ処理を実行して（ステップ４１２）、終了する（ステップ４０６）。該リフレッシュ処理とは、問合せ処理の結果取得したレコードを必要に応じてキャッシュデータベースに反映する処理である。該キャッシュデータベースリフレッシュ処理を図６のフローチャートを用いて説明する。最初にキャッシュデータベース内に新たにデータベースサーバより取得したデータを格納するための空き領域が存在するか否かをチェックする（ステップ６０２）。空き領域がある場合（ステップ６０２でＹｅｓが選択された場合）には、該空き領域にデータをキャッシュし（ステップ６０６）、キャッシュデータベースリフレッシュ処理を終了する（ステップ６０７）。キャッシュデータベース内に空き領域が存在しない場合（ステップ６０２でＮｏが選択された場合）には、新たにデータベースサーバより取得したデータと、キャッシュ中に存在するデータに対して前記リフレッシュポリシーに従った置き換え可否判定を行う（ステップ６０３）。該リフレッシュポリシーとは、図５の格納データ管理テーブルの５０８に示すように、キャッシュの置き換えポリシーを指定する項目であり、（１）使用された日時が最も古いデータを置き換え対象とするＬＲＵ、（２）キャッシュ中の利用頻度の小さいデータを置き換える利用頻度、（３）そしてキャッシュ中のデータにユーザ指定の優先度を付与し置き換え対象を決定する優先度指定、そして（４）データベースサーバの書き戻しが必要ないデータを置き換え対象とする書き戻し削減などがその例である。該リフレッシュポリシーに従って置き換え可否判定を行った結果、データベースサーバから取得したデータでキャッシュデータを置き換える場合（ステップ６０４でＹｅｓが選択された場合）には、前記キャッシュスロット確保処理（ステップ６０５）を実行し、空き領域にデータをキャッシュして（ステップ６０６）、キャッシュデータベースリフレッシュ処理を終了する（ステップ６０７）。リフレッシュポリシーに従って置き換え可否判定を行った結果、データベースサーバから取得したデータでキャッシュデータを置き換えないと判定された場合（ステップ６０４でＮｏが選択された場合）には、キャッシュの置き換えを行うことなくキャッシュデータベースリフレッシュ処理を終了する（ステップ６０７）。
以上で、キャッシュデータベースクラスタを用いた問合せ処理方法の説明を終了する。なお、本実現例では問合せをキャッシュされたデータで処理するか否かの判定を、図５のキャッシュ済みデータ条件（５０７）に基づいて行った。しかしながら、アプリケーションの種類によっては、前記キャッシュ済みデータ条件（５０７）のかわりにキャッシュ対象データ条件（５０６）を用いて判定を行い、実際にキャッシュデータベースに検索を行って値が取得できない場合に、改めてデータベースサーバに問合せを発行するという実施形態も可能である。本実施形態では、キャッシュ済みデータ条件のメンテナンスコストを削減できるというメリットがある。
次は、データベースサーバ側でのトランザクション処理方法を図９のフローチャートを用いて説明する。該トランザクション処理は図２に示すデータベースサーバ１１４のトランザクション管理部２１７が同図のキャッシュデータベース管理部２１６が保持するキャッシュデータベース管理テーブル２１９の情報を用いて実行する。該キャッシュデータベース管理テーブルの具体例を図１０に示す。キャッシュデータベース管理テーブル２１９はキャッシュデータベースサーバ名（１００２）、データベースサーバ内データベース名（１００３）、テーブル名および属性名（１００４）、分割キー（１００５）、キャッシュ対象データ条件（１００６）、キャッシュ済みデータ条件（１００７）、更新可否（１００８）、および稼動状態（１００９）を含む。該テーブルの１行目のレコードを用いてその意味を説明する。該レコードは、データベースサーバ中のデータベースＣｕｓｔｏｍｅｒに含まれるテーブルｃ＿ａｄｄｒｅｓｓのｃ＿ｉｄが１＜＝ｃ＿ｉｄ＜１０００００の条件を満たすレコードの属性ｃ＿ｉｄ，ｃ＿ｎａｍｅ，ｃ＿ａｄｄｒｅｓｓ，ｃ＿ｐｈｏｎｅをキャッシュデータベースサーバ１中のキャッシュデータベース１にキャッシュすること，そして実際には現在１＜＝ｃ＿ｉｄ＜５００００を満たす前記のレコードがキャッシュされており，キャッシュデータベースは稼動中であること、そしてキャッシュでの更新が可であることを表している。なお、前記キャッシュ済みデータ条件に関しては、図１０の＃１および＃２のレコードが示すようにその範囲を指定しても、もしくは＃３のようにキャッシュ済みレコードのＩＤを保持するビットマップを指定してもよい。さらに、該キャッシュ済みデータ条件に関しては、データベースサーバ側でキャッシュ済みレコードを記録せず、そのエントリを空（ＮＵＬＬ）としておくことも可能である。この場合、本発明ではキャッシュ済みデータ条件に関する判定処理をキャッシュ対象データ条件で置き換えて行う。これにより、データベースサーバ側ではキャッシュデータベース側で実際にキャッシングを行っているデータよりも多くのデータがキャッシュデータベース側に存在すると認識することとなり、トランザクション処理が実行できる場合が少なくなるが、キャッシュデータベース側のキャッシュが更新される毎に該キャッシュデータベース管理テーブルを更新する必要がなくなるというメリットがある。
図９に戻って、キャッシュデータベース管理テーブルから、トランザクションで参照するデータの範囲と該テーブルの"キャッシュ済みデータ条件"（該エントリがＮＵＬＬの場合には"キャッシュ対象データ条件"を用いる）に重なりのあるレコードを抽出する（ステップ９０２）。例えば、キャッシュ管理テーブルが図１０に示す通りであるとし、データベースサーバのトランザクションが、「顧客ＩＤが１０の顧客の電話番号を変更する」であったとする。この時、該トランザクションはｃ＿ａｄｄｒｅｓｓテーブルのｃ＿ｉｄ＝１０のレコードを参照、更新する。この場合、該トランザクションと重なりのあるキャッシュデータベースサーバはキャッシュデータベースサーバ１となる。
次にステップ９０３でステップ９０２の結果抽出されたレコードをチェックする。抽出レコードが１つもない場合（ステップ９０３でＹｅｓが選択された場合）には、サーバのトランザクションで参照もしくは更新しようとするテーブルのキャッシュがどのキャッシュデータベースにも存在しないため、トランザクション処理を実行し（ステップ９０６）、終了する（ステップ９０７）。ステップ９０２の結果抽出されたレコードが存在する場合（ステップ９０３でＮｏが選択された場合）、トランザクションが参照処理のみを含むか否か（ステップ９０４）および抽出レコードの更新可否欄に１つでもＹｅｓが存在するか否か（ステップ９０５）をチェックする。トランザクションが参照処理のみをふくみ、かつ抽出レコードの更新可否欄が全てＮｏの場合（ステップ９０４でＹｅｓ、ステップ９０５でＮｏが選択された場合）には、トランザクションが参照するデータはキャッシュデータベース側でも更新されていないことが保証されるため、トランザクションを実行し（ステップ９０６）、処理を終了する（ステップ９０７）。
トランザクションが更新処理を含む場合、もしくは抽出レコードの更新可否欄にＹｅｓが含まれる場合（ステップ９０４でＮｏが選択されるか、もしくはステップ９０４とステップ９０５の両方でＹｅｓが選択された場合）には、キャッシュデータベース上にキャッシュしているデータをデータベースサーバ上で更新してしまう、もしくはキャッシュデータベースサーバ上での更新をデータベースサーバ上で無視してしまうという不整合が発生するため、これを避けるために抽出レコードの"キャッシュデータベース名"に含まれる前キャッシュデータベースの同期・閉塞処理を実行し（ステップ９０８）、該同期・閉塞処理が成功した場合（ステップ９０９でＹｅｓが選択された場合）には、トランザクションを実行し（ステップ９０６）、処理を終了する（ステップ９０７）。該同期・閉塞処理が失敗した場合（ステップ９０９でＮｏが選択された場合）には、トランザクションをアボートする（ステップ９１０）。
前記キャッシュデータベースの同期・閉塞処理を図１１のフローチャートを用いて説明する。ここではｉ番目のキャッシュデータベースｉでのデータベースサーバｊに関する同期・閉塞処理を説明する。但し、図１１のフローチャートではスペースの都合で、「データベースｊに関する」という文は省略している。最初にキャッシュデータベースｉで、データベースサーバｊ中のキャッシュデータにアクセスするトランザクション（以下ではデータベースサーバｊに関するトランザクションと呼ぶ）の受付を停止する（ステップ１１０２）。データベースサーバｊに関する全てのトランザクションが終了した後（ステップ１１０３でＹｅｓが選択された場合）、キャッシュデータベース内の格納データ管理テーブル中の"データベースサーバ名"がデータベースサーバｊで、かつその"更新可否"欄に少なくとも１つＹｅｓが存在するか否かをチェックする。Ｙｅｓが１つも存在しない場合（ステップ１１０４でＮｏが選択された場合）には、キャッシュデータベースｉではデータベースサーバｊに関する更新処理が行われないため、データベースサーバｊに関するキャッシュデータベース中のデータを削除して（ステップ１１０７）、同期・閉塞処理を終了する（ステップ１１０８）。前記"更新可否"エントリ欄に少なくとも１つＹｅｓが存在する場合（ステップ１１０４でＹｅｓが選択された場合）、該"更新可否"エントリ欄がＹｅｓの全テーブルに関して、キャッシュデータベース上での更新をデータベースサーバｊに反映する。該反映処理は、更新後のデータイメージだけでなく、更新履歴であるキャッシュデータベースログに関しても行う（ステップ１１０５）。該反映処理が成功した場合（ステップ１１０６でＹｅｓが選択された場合）、キャッシュデータベース中のデータベースサーバｊに関するデータを削除して（ステップ１１０７）、同期・閉塞処理を終了する（ステップ１１０８）。前記反映処理が失敗した場合（ステップ１１０６でＮｏが選択された場合）には、同期・閉塞処理はアボートする（ステップ１１０９）。なお、本実施形態ではデータベースサーバｊに関するトランザクションのみを停止したが、トランザクションを選択的に停止できない場合には、キャッシュデータベースｉで全てのトランザクションを停止せざるを得ない。この場合にはデータベースサーバｊ以外のキャッシュデータを一時的に利用できなくなるという制限が発生するが、本発明が適用可能であることはいうまでもない。
以上で、データベースサーバでのトランザクション処理方法の説明を終了する。最後に、キャッシュデータベース追加処理方法を説明する。
キャッシュデータベースクラスタに新たなサーバを追加する場合、図１３に示す通り、サーバをクラスタに追加し（１３０２）、キャッシュデータベース再編成処理を実行すればよい（１３０３）。
該キャッシュデータベース再編成処理を図１２のフローチャートを用いて説明する。最初に全キャッシュデータベースに対し、同期・閉塞処理を実行する（ステップ１２０６）。該同期・閉塞処理が失敗した場合（ステップ１２０２でＮｏが選択された場合）、キャッシュデータベース再編成処理はアボートする（ステップ１２０５）。前記同期・閉塞処理が成功した場合（ステップ１２０２でＹｅｓが選択された場合）には、キャッシュデータベース管理テーブルおよびアプリケーション−キャッシュデータベースマッピングテーブルを再構成し（ステップ１２０３およびステップ１２０７）、キャッシュデータベース再編成処理を終了する（ステップ１２０４）。
【０００６】
【発明の効果】
本発明を用いることにより、アプリケーションサーバのクラスタ化、および更新が可能なキャッシュデータベースクラスタの構成が可能となり、スケーラビリティの高いＷｅｂシステムが実現できる。さらに、高多重のＳＭＰサーバではなく、安価なクラスタサーバを用いてシステム構築が可能となり、システムのコストパフォーマンスが向上する。
【図面の簡単な説明】
【図１】本発明におけるアプリケーションサーバのクラスタ化、キャッシュデータベースクラスタを備えたＷｅｂシステムの構成を示す図。
【図２】データベースサーバとキャッシュデータベースサーバの構成を示す図。
【図３】従来方式での標準的なＷｅｂシステムの構成を示す図。
【図４】キャッシュデータベースサーバでの問合せ処理ステップを示すフローチャート。
【図５】キャッシュデータベースサーバの格納データ管理テーブルの例を示す図。
【図６】キャッシュデータベースのリフレッシュ処理ステップを示すフローチャート。
【図７】キャッシュデータベースの更新処理ステップを示すフローチャート。
【図８】キャッシュデータベースのキャッシュスロット確保処理ステップを示すフローチャート。
【図９】データベースサーバでのトランザクションステップを示すフローチャート。
【図１０】データベースサーバのキャッシュデータベース管理テーブルの例を示す図。
【図１１】キャッシュデータベースの同期・閉塞処理ステップを示すフローチャート。
【図１２】キャッシュデータベースの再編成処理ステップを示すフローチャート。
【図１３】キャッシュデータベースの追加処理ステップを示すフローチャート。
【図１４】アプリケーションのセッション状態保存処理ステップを示すフローチャート。
【図１５】アプリケーションのセッション継続処理ステップを示すフローチャート。
【図１６】キャッシュデータベースサーバのセッション管理テーブルの例を示す図。
【図１７】アプリケーションサーバのアプリケーション−キャッシュデータベースマッピングテーブルの例を示す図。
【図１８】サーバ向け問合せ変換の例を示す図。
【符号の説明】
１２１，１２２…アプリケーション−キャッシュデータベースマッピングテーブル，
２１０…キャッシュ済みデータ，
２１１…キャッシュデータベースログ，
２１９…キャッシュデータベース管理テーブル，
２２１…データベースサーバ中の元データ，
２２２…セッション管理テーブル，
２２３…格納データ管理テーブル。
【図１】
0004306152.tif 000002
【図２】
0004306152.tif 000003
【図３】
0004306152.tif 000004
【図４】
0004306152.tif 000005
【図５】
0004306152.tif 000006
【図６】
0004306152.tif 000007
【図７】
0004306152.tif 000008
【図８】
0004306152.tif 000009
【図９】
0004306152.tif 000010
【図１０】
0004306152.tif 000011
【図１１】
0004306152.tif 000012
【図１２】
0004306152.tif 000013
【図１３】
0004306152.tif 000014
【図１４】
0004306152.tif 000015
【図１５】
0004306152.tif 000016
【図１６】
0004306152.tif 000017
【図１７】
0004306152.tif 000018
【図１８】
0004306152.tif 000019