(57)【要約】【課題】キャッシュデータの参照性能を向上することができるキャッシュサーバを提供する。【解決手段】キャッシュサーバ１２０は、クライアントから要求を受理する更新要求受付部１４３と、参照要求の検索条件と検索条件に合致した検索結果を関連付けてキャッシュデータを記憶する記憶装置１５１と、更新要求受付部１４３が更新要求のうちの登録要求を受理すると、登録要求の登録データが記憶装置１５１に記憶されている検索条件を満たすか否かを判定し、検索条件を満たすとき、登録データを、検索条件と関連付けて記憶装置１５１に登録する登録部１４５とを有する。このような構成によれば、クライアント１１０から受付けた更新要求をキャッシュデータに反映することで、キャッシュを最新の状態に更新することができる。【選択図】図１
2008287660.tif 000002
【特許請求の範囲】
【請求項１】
クライアントからの要求に対しデータサーバを代行し、前記要求のうちの参照要求の検索条件と前記検索条件に合致した検索結果を関連付けたキャッシュデータを記憶する記憶装置を備えるキャッシュサーバであって、
前記要求を受付ける受付部が前記要求のうちの登録要求を受理すると、前記登録要求の登録データが前記記憶装置に記憶されている検索条件を満たすか否かを判定し、前記検索条件を満たすとき、前記登録データを、前記検索条件と関連付けて前記記憶装置に登録する登録部を有する
ことを特徴とするキャッシュサーバ。
【請求項２】
前記キャッシュサーバは、さらに、
前記受付部が前記要求のうちの上書き要求を受理すると、前記上書き要求に上書き条件があるか否かを判定し、上書き条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを上書きし、指定されたデータ構造が前記キャッシュデータにないとき、前記キャッシュデータを削除する上書き部を有する
ことを特徴とする請求項１に記載のキャッシュサーバ。
【請求項３】
前記キャッシュサーバは、さらに、
前記受付部が前記要求のうちの削除要求を受理すると、前記削除要求に削除条件があるか否かを判定し、削除条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを削除し、指定されたデータ構造が前記キャッシュデータにないとき、前記キャッシュデータを削除する削除部を有する
ことを特徴とする請求項１に記載のキャッシュサーバ。
【請求項４】
前記キャッシュサーバは、登録要求、上書き要求、削除要求のいずれかである更新要求を受付けた際に、前記キャッシュデータを更新するとともに、前記データサーバに更新要求を指令する
ことを特徴とする請求項１に記載のキャッシュサーバ。
【請求項５】
前記キャッシュサーバは、さらに、
前記受付部が前記要求のうちの参照要求を受理すると、前記参照要求に検索条件があるか否かを判定し、検索条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを取得し、指定されたデータ構造が前記キャッシュデータにないとき、前記データサーバから取得し前記キャッシュデータに追加する参照要求部を有する
ことを特徴とする請求項１に記載のキャッシュサーバ。
【請求項６】
前記キャッシュサーバは、前記クライアントからＳＱＬ又はＸＱｕｅｒｙのデータベースアクセス言語を用いて更新要求又は参照要求される
ことを特徴とする請求項１に記載のキャッシュサーバ。
【請求項７】
前記キャッシュサーバは、前記キャッシュデータとして、ＸＭＬ形式、テキスト形式、バイナリ形式の少なくともいずれかのデータ形式で前記記憶装置に記憶する
ことを特徴とする請求項１に記載のキャッシュサーバ。
【請求項８】
前記キャッシュサーバは、複数のキャッシュサーバで構成され、
各前記キャッシュサーバは、各前記キャッシュサーバを識別する識別子が記憶される割当情報を有し、
前記クライアントから更新要求があった際に、前記更新要求に含まれる前記識別子が
前記割当情報を参照して該当するキャッシュサーバを特定し、特定されたキャッシュサーバに前記更新要求を送信する
ことを特徴とする請求項１から請求項７のいずれか１項に記載のキャッシュサーバ。
【請求項９】
クライアントからの要求に対しデータサーバを代行し、前記要求のうちの参照要求の検索条件と前記検索条件に合致した検索結果とを関連付けたキャッシュデータを記憶する記憶装置を備えるキャッシュサーバのキャッシュ管理方法であって、
前記キャッシュサーバは、前記要求を受付ける受付部と、登録部とを備え、
前記登録部は、前記受付部が前記要求のうちの登録要求を受理すると、前記登録要求の登録データが前記記憶装置に記憶されている検索条件を満たすか否かを判定し、前記検索条件を満たすとき、前記登録データを、前記検索条件と関連付けて前記記憶装置に記憶する
ことを特徴とするキャッシュ管理方法。
【請求項１０】
前記キャッシュサーバは、さらに、上書き部と、削除部とを備え、
前記上書き部は、前記受付部が前記要求のうちの上書き要求を受理すると、前記上書き要求に上書き条件があるか否かを判定し、上書き条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを上書きし、指定されたデータ構造が前記キャッシュデータにないとき、前記キャッシュデータを削除し、
前記削除部は、前記受付部が前記要求のうちの削除要求を受理すると、前記削除要求に削除条件があるか否かを判定し、削除条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを削除し、指定されたデータ構造が前記キャッシュデータにないとき、前記キャッシュデータを削除する
ことを特徴とする請求項９に記載のキャッシュ管理方法。
【請求項１１】
前記キャッシュサーバは、登録要求、上書き要求、削除要求のいずれかである更新要求を受付けた際に、前記キャッシュデータを更新するとともに、前記データサーバに更新要求を指令する
ことを特徴とする請求項９に記載のキャッシュ管理方法。
【請求項１２】
前記キャッシュサーバは、さらに、参照要求部を備え、
前記参照要求部は、前記受付部が前記要求のうちの参照要求を受理すると、前記参照要求に検索条件があるか否かを判定し、検索条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを取得し、指定されたデータ構造が前記キャッシュデータにないとき、前記データサーバから取得し前記キャッシュデータに追加する
ことを特徴とする請求項９に記載のキャッシュ管理方法。
【請求項１３】
前記キャッシュサーバは、前記クライアントからＳＱＬ又はＸＱｕｅｒｙのデータベースアクセス言語を用いて更新要求又は参照要求される
ことを特徴とする請求項９に記載のキャッシュ管理方法。
【請求項１４】
前記キャッシュサーバは、前記キャッシュデータとして、ＸＭＬ形式、テキスト形式、バイナリ形式の少なくともいずれかのデータ形式で前記記憶装置に記憶する
ことを特徴とする請求項９に記載のキャッシュ管理方法。
【請求項１５】
前記キャッシュサーバは、複数のキャッシュサーバで構成され、
各前記キャッシュサーバは、各前記キャッシュサーバを識別する識別子が記憶される割当情報を有し、
前記クライアントから更新要求があった際に、前記更新要求に含まれる前記識別子が
前記割当情報を参照して該当するキャッシュサーバを特定し、特定されたキャッシュサーバに前記更新要求を送信する
ことを特徴とする請求項９から請求項１４のいずれか１項に記載のキャッシュ管理方法。
【請求項１６】
クライアントからの要求に対しデータサーバを代行し、前記要求のうちの参照要求の検索条件と前記検索条件に合致した検索結果とを関連付けたキャッシュデータを記憶する記憶装置を備えるキャッシュサーバのキャッシュ管理プログラムであって、
コンピュータに、
クライアントから要求を受理する受付処理と、
前記要求のうちの登録要求を受理すると、前記登録要求の登録データが前記記憶装置に記憶されている検索条件を満たすか否かを判定し、前記検索条件を満たすとき、前記登録データを、前記検索条件と関連付けて前記記憶装置に記憶する登録処理と、
前記要求のうちの上書き要求を受理すると、前記上書き要求に上書き条件があるか否かを判定し、上書き条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを上書きし、指定されたデータ構造が前記キャッシュデータにないとき、前記キャッシュデータを削除する上書き処理と、
前記要求のうちの削除要求を受理すると、前記削除要求に削除条件があるか否かを判定し、削除条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを削除し、指定されたデータ構造が前記キャッシュデータにないとき、前記キャッシュデータを削除する削除処理と、
前記要求のうちの参照要求を受理すると、前記参照要求に検索条件があるか否かを判定し、検索条件があるときには指定されたデータ構造が前記キャッシュデータにあるか否かを判定し、指定されたデータ構造が前記キャッシュデータにあるとき、前記キャッシュデータのうち前記指定されたデータ構造に該当するキャッシュデータを取得し、指定されたデータ構造が前記キャッシュデータにないとき、前記データサーバから取得し前記キャッシュデータに追加する参照要求処理と、を
実行させることを特徴とするキャッシュ管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キャッシュデータの参照性能を向上することができるキャッシュサーバ、キャッシュ管理方法、およびキャッシュ管理プログラムに関するものである。
【背景技術】
【０００２】
ＩＴ環境を取り巻くインターネット技術、ソフトウェア技術などの進化によって、様々な分野における業務のＩＴ化が進んでいる。それに伴い、業務において利用されるデータが電子化され、その利用頻度が高まっている。今後もデータ量の増大、データ利用者の増加が進むと見込まれる中で、データ利用者がストレスを感じない時間でデータを参照できる性能がデータベースには要求される。
【０００３】
従来からデータの参照性能を確保するために様々のアプローチが成されてきた。具体的なアプローチの１つとして、高速にデータアクセス可能な２次領域（キャッシュ）を活用する手段が存在する。その手段の概要は、一度参照したデータをキャッシュに保存し、２度目以降の参照において、当該キャッシュから読み出したデータを返すことで、参照性能を向上させるというものである。
【０００４】
キャッシュを活用するシステムの構成として、原本となるデータは堅牢に管理されたサーバマシン（オリジナルサーバ）のディスク領域上に、キャッシュはデータ利用者がアクセスするサーバマシン（キャッシュサーバ）のメモリ領域上に配置する構成が挙げられる。
【０００５】
キャッシュサーバは、データ利用者から検索条件を受付けると、該当するデータがキャッシュに存在するか否かを確認する。該当するデータが存在しない場合、オリジナルサーバからデータを取得し、データ利用者に返すとともに、検索条件に関連付けてキャッシュに保存する。
【０００６】
それ以降、データ利用者から同一の検索条件を再度受付けた場合、該当するデータがキャッシュに存在するため、キャッシュから取り出して返す。これにより、オリジナルサーバにアクセスする必要がなくなり、高速にデータを参照することができる。また、オリジナルサーバに対する処理負荷を軽減する効果もある。
【０００７】
キャッシュを活用することによって、オリジナルサーバにデータが更新（以下、更新とは、登録、上書き、あるいは、削除を示す。）された場合、キャッシュデータに不整合が発生してしまう可能性がある。つまり、キャッシュに保存されているデータが、オリジナルサーバ上で更新されると、キャッシュには古い検索結果が保持されていることになる。結果として、キャッシュサーバは、検索条件に該当する古い検索結果をキャッシュから返してしまい、データ利用者は最新のデータを参照できない。
【０００８】
そこで、この問題を解決するメモリ無効化登録システムが知られている（例えば、特許文献１参照）。このキャッシュサーバは、キャッシュデータの整合性に影響を与える更新が行われたとき、オリジナルサーバは当該キャッシュサーバに対して、無効化メッセージを送信して、キャッシュサーバに保存されているキャッシュをフラッシュ（無効化）する。これにより、キャッシュから古い検索結果が使用されることを防ぐことができる。
【０００９】
さらに、特許文献１によれば、自動再クエリ技術を使用して、古いキャッシュデータを自動的に更新することができる。自動再クエリ技術とは、キャッシュのフラッシュに伴い、オリジナルサーバに対して任意の検索を実行するというものである。これにより、キャッシュから最新のデータを参照することができる。
【００１０】
一方、更新として登録する場合に、先にキャッシュサーバに登録し、その後オリジナルサーバに登録する方法も開示されている（例えば、特許文献２参照）。
【特許文献１】特開２００４−３０３２１１号公報
【特許文献２】特開２００２−３５１７２９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
特許文献１のシステムにおいては、上記のようなキャッシュをフラッシュする制御において、同一の検索条件が集中し、当該検索結果に対する更新頻度が高いケースではキャッシュを有効に活用できない。つまり、データが頻繁に更新され、キャッシュのフラッシュが多発することで、過去と同じ検索条件を受付けても、その時点ではキャッシュを利用できず、オリジナルサーバに検索を実行しなければならない問題がある。
【００１２】
また、自動再クエリ技術においては、キャッシュデータとの整合性に影響を与える更新が発生した場合に、オリジナルサーバに対して検索を実行するため、更新の頻度が高くなると、オリジナルサーバへの検索要求の増加に伴い、オリジナルサーバに対する処理負荷が増大し、強いては参照時の性能劣化を引き起こす問題がある。
【００１３】
同一の検索条件が集中し、当該検索結果に対する更新頻度が高いケースとして、同一の識別子の値をもつデータ集合に対する参照、および当該データ集合に対する更新が、頻繁に発生する例が挙げられる。この場合、同一の識別子の値をもつデータ集合が検索結果として頻繁に参照されるにも関わらず、当該検索結果が頻繁に更新されるため、キャッシュデータとの整合性を確保するための処理が頻繁に発生する問題がある。
【００１４】
特許文献２のシステムにおいては、登録するときにキャッシュサーバに先に無条件に登録しているので、キャッシュのヒット率に貢献しない、多数の新規登録がある場合には、キャッシュサーバに負担がかかるという問題がある。
【００１５】
本発明は、前記の課題を解決するための発明であって、キャッシュデータの参照性能を向上することができるキャッシュサーバ、キャッシュ管理方法、およびキャッシュ管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
前記目的を達成するため、クライアント（例えば、クライアント１１０）からの要求に対しデータサーバ（例えば、オリジナルサーバ１７０）を代行し、要求のうちの参照要求の検索条件と検索条件に合致した検索結果とを関連付けたキャッシュデータを記憶する記憶装置（例えば、記憶装置１５１）を備えるキャッシュサーバ（例えば、キャッシュサーバ１２０）であって、キャッシュサーバは、受付部が要求のうちの登録要求を受理すると、登録要求の登録データが記憶装置に記憶されている検索条件を満たすか否かを判定し、検索条件を満たすとき、登録データを、検索条件と関連付けて記憶装置に登録する登録部（例えば、登録部１４５）と、受付部が要求のうちの上書き要求を受理すると、上書き要求に上書き条件があるか否かを判定し、上書き条件があるときには指定されたデータ構造がキャッシュデータにあるか否かを判定し、指定されたデータ構造がキャッシュデータにあるとき、キャッシュデータのうち指定されたデータ構造に該当するキャッシュデータを上書きし、指定されたデータ構造がキャッシュデータにないとき、キャッシュデータを削除する上書き部（例えば、上書き部１４６）と、受付部が要求のうちの削除要求を受理すると、削除要求に削除条件があるか否かを判定し、削除条件があるときには指定されたデータ構造がキャッシュデータにあるか否かを判定し、指定されたデータ構造がキャッシュデータにあるとき、キャッシュデータのうち指定されたデータ構造に該当するキャッシュデータを削除し、指定されたデータ構造がキャッシュデータにないとき、キャッシュデータを削除する削除部（例えば、削除部１４７）と、受付部が要求のうちの参照要求を受理すると、参照要求に検索条件があるか否かを判定し、検索条件があるときには指定されたデータ構造がキャッシュデータにあるか否かを判定し、指定されたデータ構造がキャッシュデータにあるとき、キャッシュデータのうち指定されたデータ構造に該当するキャッシュデータを取得し、指定されたデータ構造がキャッシュデータにないとき、データサーバから取得しキャッシュデータに追加する参照要求部（例えば、検索部１４８）を有することを特徴とする。
【発明の効果】
【００１７】
本発明によれば、キャッシュデータの参照性能を向上することができる。
【発明を実施するための最良の形態】
【００１８】
以下、本発明の実施形態について図面を参照して説明する。
《実施形態１》
図１は、実施形態１のサーバシステムの構成を示すブロック図である。サーバシステムは、クライアント１１０、キャッシュサーバ１２０、オリジナルサーバ１７０を有し、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）などのネットワーク１０に接続することにより、相互に通信することができる。キャッシュサーバ１２０は、プロセッサ（ＣＰＵ）１３０、メモリ１４０、記憶装置１５１、ディスクインターフェイス１５０、通信インターフェイス１６０、およびこれらを接続するバス１６１などから構成される。キャッシュサーバ１２０は、通信インターフェイス１６０を介してＬＡＮ、ＷＡＮなどのネットワークに接続される。また、キャッシュサーバ１２０の記憶装置１５１は、ハードディスクドライブなどで構成され、ディスクインターフェイス１５０を介して接続される。プロセッサ１３０は、メモリ１４０に格納される各種プログラムを実行する。記憶装置１５１は、キャッシュサーバ１２０が処理を実行するための各種データ、特にキャッシュデータを含むキャッシュ管理テーブル１５２（図２参照）を保存する。メモリ１４０は、キャッシュサーバ１２０が処理を実行する各種プログラムおよび一時的なデータを保持する。
【００１９】
なお、キャッシュサーバ１２０は、キャッシュ機能を持たせたプロキシサーバ（代理サーバ）のことを意味し、一度アクセスされたデータのキャッシュを行うことにより(キャッシング）、以降に同じデータをアクセスした同じまたは異なるクライアントに対して、キャッシュに保持していたデータを返すことができる。本来のオリジナルサーバ１７０にアクセスする必要がなくなるため、ネットワーク１０のトラフィックおよびオリジナルサーバ１７０の負荷の軽減、クライアント１１０から見た応答時間の短縮が期待できる。
【００２０】
キャッシュサーバ１２０は、メモリ１４０に格納されたキャッシュ制御プログラム１４２などのプログラム１４１をプロセッサ１３０が実行することで、キャッシュ制御の処理を行う。キャッシュ制御の処理は、プログラム１４１をプロセッサ１３０で実行することにより実現するが、これらはキャッシュ制御プログラム１４２などの各処理を行う処理部として集積回路化するなどしてハードウェアで実現することもできる。
【００２１】
クライアント１１０およびオリジナルサーバ１７０は、それぞれ１台以上のコンピュータで構成される。オリジナルサーバ１７０は、記憶装置１７１を有し、更新あるいは参照における原本となるデータであるオリジナルデータ１７２を保持する。
【００２２】
キャッシュ制御プログラム１４２には、処理内容別に、更新要求受付部１４３、参照要求受付部１４４、登録部１４５、上書き部１４６、削除部１４７、および検索部１４８を有する。更新要求受付部１４３は、クライアント１１０からの更新要求を受付けると、更新処理を開始する。更新要求には、登録要求、上書き要求、および削除要求がある。具体的には、更新要求には、更新系ＳＱＬである、登録（ＩＮＳＥＲＴ文）、上書き（ＵＰＤＡＴＥ文）、削除（ＤＥＬＥＴＥ文）がある。なお、ＳＱＬは、リレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）において、データの操作や定義を行うためのデータベース言語（問い合わせ言語）である。
【００２３】
参照要求受付部１４４は、クライアント１１０からの参照要求を受付けると、参照処理を開始する。参照要求には、参照系ＳＱＬである、選択（ＳＥＬＥＣＴ文）が格納されている。参照要求に、参照系ＳＱＬが格納されていない場合、エラーコードやエラーメッセージなどをクライアント１１０に応答する。
【００２４】
登録部１４５は、ＩＮＳＥＲＴ文に指定された登録データをキャッシュデータに追加する。上書き部１４６は、ＵＰＤＡＴＥ文に応じてキャッシュデータを上書きする。削除部１４７は、ＤＥＬＥＴＥ文に応じてキャッシュデータを削除する。検索部１４８は、ＳＥＬＥＣＴ文に応じて、検索結果を記憶装置１５１から取得することを試み、できない場合は記憶装置１７１から検索結果を取得する。
【００２５】
以下、説明を簡略化するため、各種のプログラム１４１をプロセッサ１３０が実行することで実現される各処理部を各処理の主体として説明する。なお各処理部をハードウェアで実現した場合にはその各処理部が主体となって各処理を行う。
【００２６】
図２は、キャッシュ管理テーブルの一例を示す説明図である。キャッシュ管理テーブル１５２には、検索条件２１０、およびキャッシュデータ２２０からなり、両者が双方向に関連付けて管理されている。つまり、ある検索条件２１０から、それに対応するキャッシュデータ２２０を取得できる。逆に、あるキャッシュデータ２２０から、それに対応する検索条件２１０を取得できる。
【００２７】
検索条件２１０は、左辺に比較元、右辺に比較先、およびその間に両者を比較する比較演算子により構成される。比較元あるいは比較先に利用される／（スラッシュ）は、ＸＭＬ（Extensible Markup Language）の階層構造を表す。例えば、”商品／価格”は、要素”商品”の子要素”価格”を示す。
【００２８】
また、比較演算子に使用される＝（イコール）、＞（大なり）、および＜（小なり）は、それぞれ比較元と比較先が一致、比較元が比較先より大きい、比較元が比較先より小さいことを表す。その他、＞＝（以上）、＜＝（以下）、＜＞（等しくない）なども比較演算子として使用できる。
【００２９】
具体的な検索条件の一例として、在庫管理データを例に説明する。在庫管理データには、商品毎に、価格、在庫数、商品名、原価、入荷予定数、出荷予定数、在庫回転率などが含まれる。このとき、検索条件には、要素として、価格、在庫数、商品名などが用いられる。
【００３０】
検索条件”商品／価格＝１５００”は、比較元である要素”商品”の子要素である”価格”の値が、比較先である１５００と一致することを表す。
【００３１】
また、比較演算子が＝（イコール）の場合、比較先に文字列を指定することで、文字列が一致するか否かを判定できる。検索条件”商品／商品名＝ＺＹ００５５”は、要素”商品”の子要素である”商品名”の値が、”ＺＹ００５５”に一致することを表す。
【００３２】
キャッシュデータ２２０には、検索条件２１０ごとに、過去にオリジナルサーバ１７０から取得された検索結果がＸＭＬ形式で格納されている。検索条件を満たすＸＭＬが２つ以上になる可能性があり、その場合は１つの検索条件に対して複数のＸＭＬが対応付けて管理される。例えば、図２に示すように、検索条件”商品／価格＝１５００”の場合、キャッシュデータ２２０には、価格１５００を含むデータが３つある。また、検索条件”商品／在庫数＞５００”の場合、在庫５５０のデータと在庫７５０のデータがある。さらに、検索条件”商品／商品名＝ＺＹ００５５”の場合、商品名ＺＹ００５５を含むデータが２つある。以上説明したように、キャッシュデータ２２０には、ＸＭＬ形式や文字列などのテキスト形式のほかに、画像や音楽データなどのバイナリ形式など多様なデータ形式が格納されてもよい。
【００３３】
次に、各部の処理について、図３〜図６のフローチャートに沿いつつ、適宜図１および図２を参照して説明する。
【００３４】
図３は、更新要求受付部の処理を示すフローチャートである。更新要求受付部１４３は、クライアント１１０からの更新要求を受付けると、更新処理を開始する。更新要求には、更新系ＳＱＬである、登録（ＩＮＳＥＲＴ文）、上書き（ＵＰＤＡＴＥ文）、削除（ＤＥＬＥＴＥ文）のいずれかが格納されている。更新要求に、更新系ＳＱＬが格納されていない場合、エラーコードやエラーメッセージなどをクライアント１１０に応答する。
【００３５】
本実施形態では、ＸＭＬ形式を扱うため、更新対象のデータ構造を指定する際にはＸＰａｔｈなどのＸＭＬパス言語を使用する。その他、ＸＱｕｅｒｙ（静的型付け機能を持つＸＭＬデータ問合せのための関数型言語）や、リレーショナルデータベースにおいてはＳＱＬなどのデータアクセス言語が使用される。
【００３６】
更新要求受付部１４３は、更新要求を解析し、そこに格納されている更新系ＳＱＬがデータの登録（ＩＮＳＥＲＴ文）要求であるか否かを判定する（ステップＳ３１０）。更新要求受付部１４３は、ステップＳ３１０において、データの登録要求である場合（ステップＳ３１０，Ｙｅｓ）、当該ＩＮＳＥＲＴ文を指定して登録部１４５を呼び出す。登録部１４５は、ＩＮＳＥＲＴ文に指定された登録データをキャッシュデータに追加し（ステップＳ３２０）、ステップＳ３６０へ進む。ステップＳ３２０の詳細は、図４において説明する。
【００３７】
図４は、登録部の処理を示すフローチャートである。登録部１４５は、ＩＮＳＥＲＴ文を指定されて処理を開始する。ＩＮＳＥＲＴ文に格納されているＸＭＬ形式の登録データを取り出す（ステップＳ４００）。続いて、当該登録データが、キャッシュ管理テーブル１５２に存在する検索条件２１０を満たすか否かを判定する（ステップＳ４１０）。
【００３８】
登録部１４５は、ステップＳ４１０において、検索条件２１０において比較先が数値である場合、登録データから比較元の数値を取り出し、比較先の数値と比較演算子に基づいて評価した結果が真であれば、検索条件２１０を満たすと判定する。
【００３９】
また、比較先が文字列で、比較演算子が＝（イコール）である場合、比較元の文字列と、比較先の文字列が一致すれば、検索条件２１０を満たすと判定する。上記以外の場合、登録データは検索条件２１０を満たさないと判定する。
【００４０】
登録部１４５は、ステップＳ４１０において、登録データがキャッシュ管理テーブル１５２に存在する検索条件２１０を満たす場合（ステップＳ４１０，Ｙｅｓ）、登録データを当該検索条件の関連付けに追加してキャッシュデータ２２０を追加更新する（ステップＳ４２０）。登録部１４５は、ステップＳ４１０において、登録データがキャッシュ管理テーブル１５２に存在する検索条件２１０を満たさない場合（ステップＳ４１０，Ｎｏ）、キャッシュデータ２２０を更新しない。なお、登録部１４５は、検索条件２１０が２つ以上存在する場合、上記の処理をキャッシュ管理テーブル１５２に存在するすべての検索条件２１０に対して繰り返し行う。
【００４１】
具体的には、キャッシュデータ２２０を更新する一例として、登録データの”商品／価格”に１５００が格納されており、図２に示すように、検索条件２１０が”商品／価格＝１５００”の場合、当該登録データは検索条件を満たすため、キャッシュデータ２２０に追加する。また、キャッシュデータ２２０を更新しない一例として、登録データの”商品／価格”に２０００が格納されており、図２に示すように、検索条件２１０が”商品／価格＝１５００”の場合、当該登録データは検索条件を満たさないため、キャッシュデータ２２０に追加しない。
【００４２】
本実施形態によれば、キャッシュサーバ１２０は、クライアント１１０から更新要求のうちの登録要求があった際に、登録部１４５は、キャッシュ管理テーブル１５２にある検索条件が、登録データに含まれているか否かを判定し、検索条件が含まれている場合に、検索条件と登録データとを関連付けて、キャッシュデータ２２０に登録しているので、次回参照要求があった際に、キャッシュのヒット率が高まり、参照性能が向上できる。
【００４３】
図３に戻り、更新要求受付部１４３は、ステップＳ３１０において、更新要求がデータの登録要求ではない場合（ステップＳ３１０，Ｎｏ）、更新要求に格納される更新系ＳＱＬがデータの上書き（ＵＰＤＡＴＥ）要求であるか否かを判定する（ステップＳ３３０）。更新要求受付部１４３は、ステップＳ３３０において、データの上書き要求である場合（ステップＳ３３０，Ｙｅｓ）、当該ＵＰＤＡＴＥ文を指定して、上書き部１４６を呼び出す。上書き部１４６は、ＵＰＤＡＴＥ文に応じてキャッシュデータを上書きし（ステップＳ３４０）、ステップＳ３６０へ進む。ステップＳ３４０の詳細は、図５において説明する。
【００４４】
図５は、上書き部の処理を示すフローチャートである。上書き部１４６は、ＵＰＤＡＴＥ文を指定されて処理を開始する。ＵＰＤＡＴＥ文に上書き条件、つまり上書きの対象となるデータの範囲が指定されているか否かを判定する（ステップＳ５１０）。具体的には、上書き条件の指定方法の一例として、ＵＰＤＡＴＥ文におけるＷＨＥＲＥ句が挙げられる。ＷＨＥＲＥ句には検索条件２１０と同じ形式で条件を指定することができ、そこで指定された条件を満たすキャッシュデータ２２０が上書きの対象となる。
【００４５】
上書き部１４６は、ステップＳ５１０において、ＵＰＤＡＴＥ文に上書き条件が指定されている場合（ステップＳ５１０，Ｙｅｓ）、上書き条件に指定されたデータ構造がキャッシュデータ２２０に存在するか否かを判定する（ステップＳ５２０）。言い換えると、上書き条件の比較元あるいは比較先にＸＰａｔｈなどを用いてデータ構造が指定された場合、当該データ構造がキャッシュデータ２２０に存在するか否かを判定する。一方、ステップＳ５１０において、上書き条件が指定されていない場合（ステップＳ５１０，Nｏ）、ステップＳ５３０へ進む。
【００４６】
上書き部１４６は、ステップＳ５２０において、上書き条件に指定されたデータ構造がキャッシュデータ２２０に存在する場合（ステップＳ５２０，Ｙｅｓ）、ステップＳ５３０へ進む。上書き条件に指定されたデータ構造がキャッシュデータ２２０に存在しない場合（ステップＳ５２０，Ｎｏ）、ステップＳ５６０へ進む。
【００４７】
具体的には、上書き条件に指定されたデータ構造がキャッシュデータに存在しない一例として、”ＵＰＤＡＴＥ  商品／価格＝商品／価格＋５００  ＷＨＥＲＥ  商品／原価＞１０００”のＵＰＤＡＴＥ文が指定された場合、上書き条件には”商品／原価＞１０００”が指定されており、指定されたデータ構造”商品／原価”がキャッシュデータ２２０（図２参照）に存在しない。この場合、上書き条件を満たすキャッシュデータを特定することができない。
【００４８】
上書き部１４６は、ステップＳ５３０において、上書き対象のキャッシュデータ２２０を特定できる否かを判定する。上書き対象のキャッシュデータ２２０を特定できる場合（ステップＳ５３０，Ｙｅｓ）、ステップＳ５４０へ進む。上書き対象のキャッシュデータ２２０を特定できない場合（ステップＳ５３０，Ｎｏ）、ステップＳ５６０へ進む。
【００４９】
具体的には、図２において、上書き対象を特定できる一例として、”ＵＰＤＡＴＥ商品／価格＝１６００  ＷＨＥＲＥ  商品／商品名＝ＴＡ００１８”のＵＰＤＡＴＥ文が指定された場合、ステップＳ５１０において上書き条件（ＷＨＥＲＥ  商品／商品名＝ＴＡ００１８）が指定されており、ステップ５２０において指定されたデータ構造がキャッシュデータ（商品／商品名）に存在している。このとき、ステップＳ５３０において上書き対象（商品／価格）を特定することができる。これにより、後記するステップＳ５５０において、商品名ＴＡ００１８の価格を、１５００から１６００へ上書きすることができる。
【００５０】
上書き部１４６は、ステップＳ５４０において、ＵＰＤＡＴＥ文に指定された上書きデータの値を算出できるか否かを判定する。すなわち、上書きデータの値が、指定されたデータ構造から演算により算出することが指定された場合、当該データ構造がキャッシュデータ２２０に存在するか否かを判定する。
【００５１】
上書きデータの値を算出できる場合（ステップＳ５４０，Ｙｅｓ）、すなわち、当該データ構造がキャッシュデータ２２０に存在する場合、上書き対象のキャッシュデータを上書きする（ステップＳ５５０）。具体的には、上書きデータの値を算出できる一例として、”ＵＰＤＡＴＥ商品／在庫数＝商品／在庫数＋２００”のＵＰＤＡＴＥ文が指定された場合、上書きデータの値には”商品／在庫数＋２００”が指定されており、指定されたデータ構造”商品／在庫数”がキャッシュデータ２２０に存在するため、上書きデータの値を算出できる。すなわち、図２において、指定されたデータ構造”商品／在庫数”のあるキャッシュデータ２２０に対して、在庫数に２００を加算し上書きすることになる。
【００５２】
上書きデータの値を算出できない場合（ステップＳ５４０，Ｎｏ）、すなわち、当該データ構造がキャッシュデータ２２０に存在しない場合、ステップＳ５６０へ進む。具体的には、上書きデータの値を算出できない一例として、上書きデータの値に”商品／入荷予定数＝商品／入荷予定数＋１０００”が指定された場合、指定されたデータ構造”商品／入荷予定数”がキャッシュデータ２２０に存在しないため、上書きデータの値を算出できないことになる。
【００５３】
上書き部１４６は、ステップＳ５２０において上書き条件に指定されたデータ構造がキャッシュデータに存在しない場合、ステップＳ５３０において上書き対象を特定できない場合、およびステップＳ５４０において上書きデータの値に指定されるデータ構造がキャッシュデータ２２０に存在しない場合、当該キャッシュデータ２２０を削除する（ステップＳ５６０）。
【００５４】
なお、ステップＳ５６０の他の実現方式として、上書き部１４６は、オリジナルサーバ１７０から最新データを取得することも考えられる。具体的には、上書き部１４６は、ステップＳ５２０あるいはステップＳ５４０において、削除するキャッシュデータ２２０が存在した場合、オリジナルサーバ１７０に対して当該キャッシュデータ２２０に対応する検索条件２１０を満たすデータの取得を要求する。オリジナルサーバ１７０から当該検索条件２１０を満たすデータを、対応するキャッシュデータ２２０に反映する。これにより、更新のタイミングでキャッシュデータ２２０を最新の状態に保つことができる。
【００５５】
本実施形態によれば、キャッシュサーバ１２０は、クライアントから更新要求のうちの上書き要求があった際に、上書き部１４６は、上書き条件を満たし、上書きデータを算出できる場合に、キャッシュ管理テーブル１５２にあるキャッシュデータ２２０を上書きしているので、次回参照要求があった際に、キャッシュのヒット率が高まり、参照性能が向上できる。
【００５６】
図３に戻り、更新要求受付部１４３は、ステップＳ３３０において、更新要求がデータの上書き要求でない場合（ステップＳ３３０，Ｎｏ）、ステップＳ３５０へ進む。この場合、更新要求のうちのデータ削除（ＤＥＬＥＴＥ文）要求であるので、当該ＤＥＬＥＴＥ文を指定して、削除部１４７を呼び出す。削除部１４７は、ＤＥＬＥＴＥ文に応じてキャッシュデータを削除し（ステップＳ３５０）、ステップＳ３６０へ進む。ステップＳ３５０の詳細は、図６において説明する。
【００５７】
図６は、削除部の処理を示すフローチャートである。削除部１４７は、ＤＥＬＥＴＥ文を指定されて処理を開始する。ＤＥＬＥＴＥ文に削除条件、つまり削除の対象となるデータの範囲が指定されているか否かを判定する（ステップＳ６１０）。
【００５８】
具体的には、削除条件の指定方法の一例として、ＤＥＬＥＴＥ文におけるＷＨＥＲＥ句が挙げられる。ＷＨＥＲＥ句には検索条件２１０と同じ形式で条件を指定することができ、そこで指定された条件を満たすキャッシュデータ２２０が削除の対象となる。
【００５９】
削除部１４７は、ステップＳ６１０において、ＤＥＬＥＴＥ文に削除条件が指定されている場合（ステップＳ６１０，Ｙｅｓ）、削除条件に指定されたデータ構造がキャッシュデータ２２０に存在するか否かを判定する（ステップＳ６２０）。すなわち、削除条件の比較元あるいは比較先の中にＸＭＬのデータ構造が指定された場合、当該ＸＭＬのデータ構造がキャッシュデータ２２０に存在するか否かを判定する。一方、ステップＳ６１０において、削除条件が指定されていない場合（ステップＳ６１０，Ｎｏ）、ステップＳ６３０へ進む。
【００６０】
具体的には、削除条件に指定されたデータ構造がキャッシュデータに存在しない一例として、削除条件として”商品／入荷予定数＞３０００”が指定された場合、キャッシュ管理テーブル１５２のキャッシュデータ２２０に”商品／入荷予定数”が存在しない。この場合、キャッシュデータ２２０が削除条件を満たすか否かを判定できず、削除条件に指定されたデータ構造がキャッシュデータに存在しない。
【００６１】
削除部１４７は、ステップＳ６２０において、削除条件に指定されたデータ構造がキャッシュデータ２２０に存在する場合（ステップＳ６２０，Ｙｅｓ）、削除対象（削除条件を満たす）のキャッシュデータ２２０を削除して（ステップＳ６３０）、処理を終了する。削除部１４７は、削除条件を満たすキャッシュデータが存在しない場合（ステップＳ６２０，Ｎｏ）、当該キャッシュデータ２２０を削除する（ステップＳ６４０）。
【００６２】
なお、ステップＳ６４０の他の実現方式として、削除部１４７は、オリジナルサーバ１７０から最新データを取得することも考えられる。具体的には、削除部１４７は、ステップＳ６２０において、削除するキャッシュデータ２２０が存在した場合、オリジナルサーバ１７０に対して当該キャッシュデータ２２０に対応する検索条件２１０を満たすデータの取得を要求する。オリジナルサーバ１７０から当該検索条件２１０を満たすデータを、対応するキャッシュデータ２２０に反映する。これにより、更新のタイミングでキャッシュデータ２２０を最新の状態に保つことができる。
【００６３】
本実施形態によれば、キャッシュサーバ１２０は、クライアント１１０から更新要求のうちの削除要求があった際に、削除部１４７は、削除条件を満たし、削除データを算出できる場合に、キャッシュ管理テーブル１５２にあるキャッシュデータ２２０を削除しているので、キャッシュデータ２２０を最新の状態に保つことができる。
【００６４】
図３に戻り、ステップＳ３６０において、更新要求受付部１４３は、オリジナルサーバ１７０に更新要求を送信し、データの更新を要求する。オリジナルサーバ１７０は、更新要求に基づいて、オリジナルデータ１７２を最新の状態に更新する。更新要求受付部１４３は、最後に、更新結果をクライアント１１０に応答し（ステップＳ３７０）、一連の処理を終了する。更新処理が正常に終了した場合は正常に終了した旨を応答する。更新処理中に何からのエラーが発生した場合はエラーコードやエラーメッセージなどをクライアント１１０に応答する。以上の処理により、更新要求に対してキャッシュサーバ１２０が管理するキャッシュデータ２２０、およびオリジナルサーバ１７０が管理するオリジナルデータ１７２を更新することができる。
【００６５】
図７は、参照要求受付部の処理を示すフローチャートである。参照要求受付部１４４は、クライアント１１０からの参照要求を受付けると、参照処理を開始する。参照要求には、参照系ＳＱＬである、選択（ＳＥＬＥＣＴ文）が格納されている。参照要求に、参照系ＳＱＬが格納されていない場合、エラーコードやエラーメッセージなどをクライアント１１０に応答する。
【００６６】
本実施形態では、ＸＭＬ形式を扱うため、参照対象のデータ構造を指定する際にはＸＰａｔｈなどのＸＭＬパス言語を利用する。その他、ＸＱｕｅｒｙや、リレーショナルデータベースにおいてはＳＱＬなどのデータベースアクセス言語が使用される。
【００６７】
参照要求受付部１４４は、ＳＥＬＥＣＴ文を指定して、検索部１４８を呼び出す。検索部１４８は、ＳＥＬＥＣＴ文に対する検索結果をキャッシュデータ２２０から取得し、取得できない場合はオリジナルデータ１７２から検索結果を取得する（ステップＳ７１０）。そして、参照要求受付部１４４は、検索結果をクライアント１１０に応答し（ステップＳ７２０）、一連の処理を終了する。検索処理が正常に終了した場合は正常に終了した旨を応答する。検索処理中に何からのエラーが発生した場合はエラーコードやエラーメッセージなどを応答する。以上の処理により、参照要求に対してキャッシュサーバ１２０が管理するキャッシュデータ２２０、あるいはオリジナルサーバ１７０が管理するオリジナルデータ１７２から検索結果を取得することができる。なお、ステップＳ７１０の詳細は、図８において説明する。
【００６８】
図８は、検索部の処理を示すフローチャートである。検索部１４８は、ＳＥＬＥＣＴ文を指定されて処理を開始する。ＳＥＬＥＣＴ文に検索条件、つまり検索の対象となるデータの範囲が指定されているか否かを判定する（ステップＳ８１０）。
【００６９】
具体的には、検索条件の指定方法の一例として、ＳＥＬＥＣＴ文におけるＷＨＥＲＥ句が挙げられる。ＷＨＥＲＥ句には検索条件２１０と同じ形式で条件を指定することができ、そこで指定された条件を満たすキャッシュデータ２２０が検索の対象となる。
【００７０】
検索部１４８は、ステップＳ８１０において、ＳＥＬＥＣＴ文に検索条件が指定されている場合（ステップＳ８１０，Ｙｅｓ）、当該検索条件がキャッシュ内に存在するか否か、つまりキャッシュ管理テーブル１５２の検索条件２１０に合致するか否かを判定する（ステップＳ８２０）。検索条件２１０に合致するということは、当該検索条件に対する検索結果がキャッシュデータ２２０に存在することを意味する。検索部１４８は、当該検索条件が検索条件２１０に合致する場合（ステップＳ８２０，Ｙｅｓ）、当該検索条件２１０に対応するキャッシュデータ２２０を検索結果として取得して（ステップＳ８３０）、一連の処理を終了する。
【００７１】
具体的には、検索結果を取得できる一例として、検索条件に”商品／価格＝１５００”が指定された場合、検索条件２１０に当該検索条件に合致するエントリが存在する。この場合、当該検索条件に対するキャッシュデータ２２０を検索結果として取得する。
【００７２】
検索部１４８は、ステップＳ８１０において、ＳＥＬＥＣＴ文に検索条件が指定されていない場合（ステップＳ８１０，Ｎｏ）、オリジナルサーバ１７０から検索結果を取得する（ステップＳ８４０）。また、検索部１４８は、ステップＳ８２０において、ＳＥＬＥＣＴ文に指定された検索条件がキャッシュ内に存在しない場合（ステップＳ８２０，Ｎｏ）、当該検索条件を指定してオリジナルサーバ１７０から検索結果を取得する（ステップＳ８４０）。そして、ＳＥＬＥＣＴ文に指定された検索条件、およびオリジナルサーバ１７０から取得した検索結果を、それぞれ検索条件２１０、およびキャッシュデータ２２０に追加し（ステップＳ８５０）、一連の処理を終了する。
【００７３】
以上の処理により、以降同一の検索条件を受付けた時には、当該検索条件２１０に対する検索結果をキャッシュデータ２２０から取得できるようになる。
【００７４】
本実施形態は、クライアント１１０と、オリジナルサーバ１７０と、クライアント１１０からの要求に対しオリジナルサーバを代行するキャッシュサーバ１２０とを含んで構成されるサーバシステムであって、キャッシュサーバ１２０は、参照要求の検索条件と検索条件に合致した検索結果とを関連付けたキャッシュデータを記憶する記憶装置１５１と、クライアントから要求を受理する受付部（例えば、更新要求受付部１４３）と、受付部が更新要求のうちの登録要求を受理すると、登録要求の登録データが記憶装置に記憶されている検索条件を満たすか否かを判定し、検索条件を満たすとき、登録データを、検索条件と関連付けて記憶装置に登録する登録部１４５と、を有する。
【００７５】
キャッシュサーバ１２０は、さらに、受付部が上書き要求を受理すると、上書き要求に上書き条件があるか否かを判定し、上書き条件があるとき指定されたデータ構造がキャッシュデータにあるか否かを判定し、指定されたデータ構造がキャッシュデータにあるとき、キャッシュデータのうち指定されたデータ構造に該当するキャッシュデータを上書きし、指定されたデータ構造がキャッシュデータにないとき、キャッシュデータを削除する上書き部１４６を有する。
【００７６】
キャッシュサーバ１２０は、さらに、受付部が削除要求を受理すると、削除要求に削除条件があるか否かを判定し、削除条件があるとき指定されたデータ構造がキャッシュデータにあるか否かを判定し、指定されたデータ構造がキャッシュデータにあるとき、キャッシュデータのうち指定されたデータ構造に該当するキャッシュデータを削除し、指定されたデータ構造がキャッシュデータにないとき、キャッシュデータを削除する削除部１４７を有する。
【００７７】
キャッシュサーバ１２０は、登録要求、上書き要求、削除要求のいずれかである更新要求を受付けた際に、キャッシュデータを更新するとともに、データベースに更新要求を指令する。
【００７８】
キャッシュサーバ１２０は、さらに、受付部が参照要求を受理すると、参照要求に検索条件があるか否かを判定し、検索条件があるとき指定されたデータ構造がキャッシュデータにあるか否かを判定し、指定されたデータ構造がキャッシュデータにあるとき、キャッシュデータのうち指定されたデータ構造に該当するキャッシュデータを取得し、指定されたデータ構造がキャッシュデータにないとき、データサーバから取得しキャッシュデータに追加する参照要求部（例えば、検索部１４８）を有する。
【００７９】
このような構成によれば、更新要求に対する登録処理、上書き処理、削除処理に対して、キャッシュサーバ１２０のキャッシュデータ２２０を最新状態に更新することができる。これにより、参照要求に対して、キャッシュのヒット率を高め、参照性能を向上させることができる。
【００８０】
《実施形態２》
図９は、実施形態２のサーバシステムの構成を示すブロック図である。本実施形態は、実施形態１と比較して、クライアント１１０、オリジナルサーバ１７０の構成は同じであるが、複数台のキャッシュサーバ１２０がネットワーク１０に接続される構成である。複数台のキャッシュサーバ１２０を並列化することで、各キャッシュサーバ１２０に対するアクセス負荷を分散でき、かつ、キャッシュ容量を増強することができる。なお、実施形態１と同一構成品については、同一番号を付しており、説明は省略する。
【００８１】
キャッシュサーバ１２０は、キャッシュサーバ（１）〜キャッシュサーバ（１０）から構成されている。記憶装置１５１には、キャッシュ管理テーブル１５２に加えて、キャッシュ割当テーブル９２０（図１０参照）を有する。また、キャッシュ制御プログラム１４２には、処理内容として、更新要求受付部１４３、参照要求受付部１４４、登録部１４５、上書き部１４６、削除部１４７、検索部１４８に加えて、キャッシュ所在判定部９１０（図１３参照）を有する。キャッシュ割当テーブル９２０およびキャッシュ所在判定部９１０については、図１０および図１３において説明する。
【００８２】
本実施形態では、更新あるいは参照の各要求が対象とするＸＭＬの集合は、ＸＭＬの特定のデータ構造において同じ値をもつＸＭＬの集合に等しいとする。当該ＸＭＬの集合を表現する一例として、すべてのＸＭＬに共通なデータ構造を導入し、そこに識別子を格納する。その識別子の値は、更新あるいは参照の各要求が対象とするＸＭＬの集合を一意に識別可能な値とする。
【００８３】
本実施形態では、すべてのＸＭＬに共通なデータ構造として”商品／分類ＩＤ”、つまり、要素”商品”の子要素”分類ＩＤ”を導入し、当該要素の内容に識別子を格納する。その識別子は、００００以上かつ９９９９以下の４桁の整数値とする。識別子には、ＧＵＩＤ（Globally Unique IDentifier）など、重複することがなく、ユニークであることが保証されたランダムな数値などを利用することもできる。
【００８４】
具体的には、更新要求の一例として、ＵＰＤＡＴＥ文のＷＨＥＲＥ句に”商品／分類ＩＤ＝０３００”が指定された場合、要素”商品”の子要素”分類ＩＤ”の値が０３００であるＸＭＬの集合が更新の対象となる。
【００８５】
なお、識別子として、要素の内容をそのまま利用する代わりに、要素の内容にハッシュ関数をほどこし、そのハッシュ値を利用することもできる。これにより、要素の内容が文字列の場合であっても、数値に変換することができるため、以降で述べるレンジ分割やその定義が容易になる。
【００８６】
本実施形態は、図９に示すように、複数台のキャッシュサーバで構成されることが特徴であり、各キャッシュサーバ１２０は、識別子のレンジに応じたキャッシュデータ２２０を保持する役割をもつ。言い換えると、識別子のレンジと、キャッシュサーバ１２０の対応関係を定義することで、どの識別子に対してどのキャッシュサーバ１２０が検索結果を保持する役割をもつかがわかる。
【００８７】
図１０は、キャッシュ割当テーブルの一例を示す説明図である。記憶装置１５１に格納されたキャッシュ割当テーブル９２０には、識別子所在１０１０、識別子レンジ１０２０、およびキャッシュサーバ所在１０３０が関連付けて管理されている。識別子所在１０１０には、識別子が存在するＸＭＬのデータ構造が格納される。識別子レンジ１０２０には、識別子の値が、一定間隔で重複なくレンジに分割される。キャッシュサーバ所在１０３０には、識別子レンジ１０２０における各レンジに対して、キャッシュデータを保持する役割をもつキャッシュサーバが関連付けられている。例えば、識別子レンジが００００以上、０９９９以下の場合は、キャッシュサーバ（１）に対応し、識別子レンジが１０００以上、１９９９以下の場合は、キャッシュサーバ（２）に対応する。
【００８８】
図１１は、更新要求受付部の他の処理を示すフローチャートである。更新要求受付部１４３（図９参照）は、クライアント１１０からの更新要求を受付けると、更新処理を開始する。
【００８９】
更新要求受付部１４３は、更新要求に格納されている更新系ＳＱＬである、登録（ＩＮＳＥＲＴ文）、上書き（ＵＰＤＡＴＥ文）、削除（ＩＮＳＥＲＴ文）を指定して、キャッシュ所在判定部９１０（図９参照）を呼び出し、キャッシュの所在を判定する（ステップＳ１１１０）。キャッシュ所在判定部９１０は、更新系ＳＱＬを解析して、キャッシュデータ２２０を更新する役割をもつキャッシュサーバ１２０を特定する。キャッシュデータ２２０を保持する役割をもつキャッシュサーバ１２０が自サーバ以外である場合、当該キャッシュサーバ１２０に処理を委譲する。そして、ステップＳ３１０へ進む。ステップＳ３１０以降は、図３と同様であるので、説明を省略する。なお、ステップＳ１１１０の詳細は、図１３において説明する。
【００９０】
図１２は、参照要求受付部の他の処理を示すフローチャートである。参照要求受付部１４４は、クライアント１１０からの参照要求を受付けると、検索処理を開始する。
【００９１】
参照要求受付部１４４は、参照要求に格納されている参照系ＳＱＬである、検索（ＳＥＬＥＣＴ文）を指定して、キャッシュ所在判定部９１０を呼び出す（ステップＳ１２１０）。キャッシュ所在判定部９１０は、参照系ＳＱＬを解析して、キャッシュデータ２２０を検索する役割をもつキャッシュサーバ１２０を特定する。キャッシュデータ２２０を保持する役割をもつキャッシュサーバ１２０が自マシン以外である場合、当該キャッシュサーバ１２０に処理を委譲する。そして、ステップＳ７１０へ進む。ステップＳ７１０以降は、図７と同様であるので、説明を省略する。なお、ステップＳ１２１０の詳細は、図１３において説明する。
【００９２】
図１３は、キャッシュ所在判定部の処理を示すフローチャートである。キャッシュ所在判定部９１０は、更新系ＳＱＬあるいは参照系ＳＱＬを解析して、識別子を取得できるか否かを判定する（ステップＳ１３１０）。キャッシュ所在判定部９１０は、更新系ＳＱＬであり、かつ、ＩＮＳＥＲＴ文の場合、当該ＩＮＳＥＲＴ文に格納されている登録データから更新の対象となる識別子を取り出す。更新系ＳＱＬであり、かつ、ＵＰＤＡＴＥ文あるいはＤＥＬＥＴＥ文の場合、それぞれ上書き条件あるいは削除条件から更新の対象となる識別子を取り出す。一方、参照系ＳＱＬの場合、検索条件から検索の対象となる識別子を取り出す。
【００９３】
具体的には、更新系ＳＱＬから識別子を取り出す一例として、ＵＰＤＡＴＥ文におけるＷＨＥＲＥ句において、”商品／分類ＩＤ＝４０００”が指定されている場合、識別子は４０００となる。
【００９４】
キャッシュ所在判定部９１０は、ステップＳ１３１０において、識別子を取得できる場合（ステップＳ１３１０，Ｙｅｓ）、キャッシュデータ２２０を更新あるいは参照する役割をもつキャッシュサーバ１２０を特定する（ステップＳ１３２０）。キャッシュ所在判定部９１０は、キャッシュ割当テーブル９２０において、取得した識別子に対応する識別子レンジ１０２０を選定する。続いて、キャッシュサーバ所在１０３０において、当該識別子レンジ１０２０に対応するキャッシュサーバ１２０を特定する。
【００９５】
具体的には、キャッシュサーバを特定する一例として、識別子が４０００であった場合、識別子レンジ１０２０から４０００以上かつ４９９９以下のレンジに該当することが分かる。そして、キャッシュサーバ（４）が当該レンジに対応するキャッシュサーバとなる。
【００９６】
キャッシュ所在判定部９１０は、ステップＳ１３２０において、特定されたキャッシュサーバ１２０から自サーバであるか否かを判定する（ステップＳ１３３０）。キャッシュ所在判定部９１０は、ステップＳ１３３０において、自サーバである場合（ステップＳ１３３０，Ｙｅｓ）、処理を終了する。以降は、自サーバにて以降の処理を継続する。キャッシュ所在判定部９１０は、ステップＳ１３３０において、自サーバでない場合（ステップＳ１３３０，Ｎｏ）、つまり他のキャッシュサーバ１２０である場合、当該キャッシュサーバ１２０に更新要求あるいは参照要求を送信し、以降の処理を委譲する（ステップＳ１３６０）。
【００９７】
キャッシュ所在判定部９１０は、ステップＳ１３１０において、識別子を取得できない場合（ステップＳ１３１０，Ｎｏ）、更新要求であるか否かを判定する（ステップＳ１３４０）。キャッシュ所在判定部９１０は、ステップＳ１３４０において、更新要求である場合（ステップＳ１３４０，Ｙｅｓ）、更新の対象となるキャッシュデータ２２０を特定できない。このとき、キャッシュデータ２２０を更新しないと、参照要求に対して古い検索結果が参照されてしまう可能性がある。そこで、すべてのキャッシュサーバ１２０にキャッシュの無効化を要求し、キャッシュデータ２２０の全体を消去して（ステップＳ１３５０）、処理を終了する。
【００９８】
キャッシュ所在判定部９１０は、ステップＳ１３４０において、更新要求でない場合、つまり参照要求である場合（ステップＳ１３４０，Ｎｏ）、検索の対象となるキャッシュデータ２２０を特定できない。そこで、自サーバにて以降の処理を継続する。
【００９９】
図１４は、キャッシュ管理テーブルの他の例を示す説明図である。キャッシュ管理テーブル１５２には、検索条件２１０には、識別子を指定した検索条件が格納されている。
【０１００】
例えば、識別子である”商品／分類ＩＤ”の値が０３００および０７００に対して、それぞれ該当するキャッシュデータ２２０が格納されている。この場合、識別子が００００以上であり０９９９以下であることから、キャッシュ割当テーブル８２０に基づいて、当該キャッシュデータ２２０はキャッシュサーバ（１）に対応するものであることがわかる。
【０１０１】
本実施形態によれば、キャッシュサーバ１２０は、複数のキャッシュサーバ（例えば、キャッシュサーバ（１）〜キャッシュサーバ（１０）で構成され、各キャッシュサーバ１２０は、各キャッシュサーバ１２０を識別する識別子が記憶される割当情報（例えば、キャッシュ割当テーブル９２０）を有し、クライアント１１０から更新要求があった際に、更新要求に含まれる識別子が割当情報を参照して該当するキャッシュサーバを特定し、特定されたキャッシュサーバに更新要求を送信している。すなわち、更新要求に対して、識別子が指定されている限りは、キャッシュサーバ１２０を特定することができ、キャッシュデータ２２０を最新状態に更新することができる。これにより、複数のキャッシュサーバ構成においても、参照要求に対して、キャッシュのヒット率を高め、参照性能を向上させることができる。
【０１０２】
本発明は、大規模データベース構成におけるキャッシュ管理システムに適用することができる。同一の検索条件が集中し、検索結果に対する更新頻度が高いケースにおいても、キャッシュのヒット率を高め、参照性能を向上させることができる。
【図面の簡単な説明】
【０１０３】
【図１】実施形態１のサーバシステムの構成を示すブロック図である。
【図２】キャッシュ管理テーブルの一例を示す説明図である。
【図３】更新要求受付部の処理を示すフローチャートである。
【図４】登録部の処理を示すフローチャートである。
【図５】上書き部の処理を示すフローチャートである。
【図６】削除部の処理を示すフローチャートである。
【図７】参照要求受付部の処理を示すフローチャートである。
【図８】検索部の処理を示すフローチャートである。
【図９】実施形態２のサーバシステムの構成を示すブロック図である。
【図１０】キャッシュ割当テーブルの一例を示す説明図である。
【図１１】更新要求受付部の他の処理を示すフローチャートである。
【図１２】参照要求受付部の他の処理を示すフローチャートである。
【図１３】キャッシュ所在判定部の処理を示すフローチャートである。
【図１４】キャッシュ管理テーブルの他の例を示す説明図である。
【符号の説明】
【０１０４】
１１０    クライアント
１２０    キャッシュサーバ
１３０    プロセッサ
１４０    メモリ
１４１    プログラム
１４２    キャッシュ制御プログラム
１４３    更新要求受付部
１４４    参照要求受付部
１４５    登録部
１４６    上書き部
１４７    削除部
１４８    検索部
１５０    ディスクインタフェイス
１５１，１７１    記憶装置
１５２    キャッシュ管理テーブル
１６０    通信インタフェイス
１７０    オリジナルサーバ
１７２    オリジナルデータ
９１０    キャッシュ所在判定部
９２０    キャッシュ割当テーブル
【図１】
2008287660.tif 000003
【図２】
2008287660.tif 000004
【図３】
2008287660.tif 000005
【図４】
2008287660.tif 000006
【図５】
2008287660.tif 000007
【図６】
2008287660.tif 000008
【図７】
2008287660.tif 000009
【図８】
2008287660.tif 000010
【図９】
2008287660.tif 000011
【図１０】
2008287660.tif 000012
【図１１】
2008287660.tif 000013
【図１２】
2008287660.tif 000014
【図１３】
2008287660.tif 000015
【図１４】
2008287660.tif 000016