JP5071990B2 - データベース装置、データベースシステム、キャッシュメンテナンス方法およびそのプログラム - Google Patents

Description

本発明は、データベースにおけるデータのキャッシュエントリをメンテナンスするキャッシュメンテナンス技術に関する。

今日、インターネットの爆発的な普及に伴い、多くのサービスがインターネットを通じて提供されている。インターネットを通じて提供されるサービスとしては、例えば、オンラインショッピング、オンラインバンキング、ソーシャルネットワーキングサービス（ＳＮＳ）等があげられる。これらのサービスを提供するシステムは、殆どの場合、ユーザのアカウント情報や商品情報、ユーザによる投稿記事等のデータを保管するデータベース（ＤＢ）と、アプリケーションとで構成される。このアプリケーションは、サービスに合わせてデータベースに問い合わせ（クエリ）を発行し、データベースから返却されるデータを用いて、ユーザに提示する結果を作成する。

これらのシステムでは、ユーザの増加等の原因によりデータベースヘのアクセス数が大
きく増加した場合、データベースの帯域幅やＣＰＵ(Central Processing Unit）資源を使い果たし、パフォーマンスの低下やサーバダウンが発生することがある。また、これらのシステムでは、アクセス数が増加しない場合でも、データベースへの問い合わせが複雑な場合、問い合わせの結果を返却するのに長い時間がかかってしまう。

そこで、上記のデータベースの処理負荷や参照性能の問題を解決する手法として、データベースとは別に、高速なアクセスが可能な記憶領域（キャッシュ）に、このデータベースヘの問い合わせ結果を利用して作られたデータを格納することが行われている。

ここで、キャッシュからデータを取得する場合、アプリケーションは、必要なデータがキャッシュ上に存在するか否かを確認する。キャッシュ上に当該データが存在しなかった場合、データベースからデータを取得するのと同時に、キャッシュにユーザからのリクエストを関連付けたデータを格納する。以降、同じデータが必要になった場合、アプリケーションは、キャッシュからこのデータを読み出して利用する。これによって、データベースにアクセスする必要がなくなるため、キャッシュを用いたシステムでは、高速にデータを参照可能とする他、データベースヘのアクセス数を低減してデータベースの負荷を軽減することができる。

一方、キャッシュを利用する場合、データベースに更新処理（登録、更新、削除）が発生すると、キャッシュに保存されたデータとデータベースに格納されたデータとに不整合が発生する可能性がある。例えば、データベースで更新されたデータをキャッシュで参照する場合、キャッシュに保存されたデータは更新されていないため、アプリケーションは、更新前の古いデータを参照してしまう。

従来から、この問題を解決するために、データベースに対して更新が行われた際、キャッシュの一貫性(cache consistency)を保つためのキャッシュメンテナンス技術が提案さ
れている。

この技術としては、キャッシュを破棄するものが提案されている（例えば、非特許文献１参照）。この非特許文献１に記載の方式では、データベースに対してキャッシュに不整合が発生するような更新が行われた場合、データベースがキャッシュに対して破棄メッセージを送信して、キャッシュで不整合が発生するデータを破棄し、キャッシュに保存された更新前のデータが参照されてしまうことを防止する。

また、このキャッシュ破棄後に、データベースに再度問い合わせを行うことでキャッシュに保存された全データを入れ替えて最新に保つ、再問い合わせ方式も提案されている（例えば、非特許文献２参照）。

Greg Barish，Katia obraczka，"World Wide Web Caching: Trens and techniques"，IEEE Communications Magazine 2000.5 James Gwertzman，Margo Seltzer,"World Wide Web Cache Consistency"，USENIX technical Conference，1996

しかし、前記した技術のいずれもが、データベースに対してキャッシュに不整合が発生するような更新が行われるたび、データベースがキャッシュに対して破棄メッセージを送信しなければならず処理負荷が大きかった。また、データベースは、データベースの更新内容およびデータベースを元に破棄メッセージの対象となるキャッシュを求めていた。このため、データベースは、実際にはキャッシュ上に存在しないキャッシュエントリの特定や、キャッシュエントリの破棄メッセージの送信処理を行う必要もあり、キャッシュメンテナンスの処理負荷が大きかった。

そこで、本発明は、前記した課題を解決し、データベースのキャッシュメンテナンス処理の負荷を軽減することを目的とする。

前記した課題を解決するため、本発明は、
データベース装置から読み出されたデータのキャッシュを備えるキャッシュ装置と、前記キャッシュ装置とネットワーク経由で接続された前記データベース装置とを有するデータベースシステムにおいて、自身のデータベース装置のデータの更新処理が行われたとき、前記ネットワーク経由で前記キャッシュ装置におけるキャッシュの破棄メッセージを送信するデータベース装置であって、
前記データを記憶する複数のベーステーブルと、このベーステーブルに記憶されたデータのうち、前記キャッシュにキャッシュエントリのあるデータを示したキャッシュ管理テーブルとを記憶する記憶部と、
前記ネットワーク経由で、前記キャッシュ装置との間で各種情報の送受信を司る入出力部と、
前記ベーステーブルの更新処理が発生したとき、前記キャッシュ装置に格納するキャッシュエントリを作成するための、前記複数のベーステーブルを対象としたキャッシュ作成用クエリを用いて、当該キャッシュ作成用クエリに記載の特定のベーステーブルの属性を示すパラメータ属性によってベーステーブルおよび属性を特定し、前記キャッシュ管理テーブルを用いて、特定したベーステーブルからレコードを絞り込み、前記ベーステーブルの更新処理内容を参照して、前記ベーステーブルの更新処理の影響を受けるデータのうち、前記キャッシュにキャッシュエントリが存在するデータを特定するキャッシュエントリ特定部と、
前記入出力部経由で、前記キャッシュ装置に対し、前記特定したデータのキャッシュエントリの破棄メッセージを送信するキャッシュメンテナンス部と、
前記入出力部経由で、前記キャッシュ装置におけるキャッシュエントリの更新情報を受信したとき、当該更新情報に基づき、前記キャッシュ管理テーブルを更新するキャッシュ管理テーブル更新部とを備える。

このようなデータベース装置は、ベーステーブルの更新処理の発生時、この更新処理の影響を受けるデータのうち、キャッシュ上にキャッシュエントリが存在するデータを特定する。そして、データベース装置は、この特定したデータのキャッシュエントリの破棄メッセージを、キャッシュ装置へ送信する。つまり、データベース装置は、キャッシュ装置のキャッシュ上に存在するキャッシュエントリを対象として破棄メッセージを送信するので、実際にはキャッシュ上に存在しないキャッシュエントリの特定を行う必要がなくなる。また、無駄な破棄メッセージを送信することがない。よって、データベース装置によるキャッシュメンテナンスの処理負荷を軽減することができる。

また、本発明は、前記したデータベース装置と、前記キャッシュの更新処理を監視し、前記ネットワーク経由で、前記キャッシュエントリの更新情報を前記データベース装置へ送信するキャッシュトラック部を備えるキャッシュ装置を１以上とを含んでなることを特徴とするデータベースシステムとした。

このようにすることで、データベース装置によるキャッシュメンテナンスの処理負荷を軽減するデータベースシステムを実現することができる。また、データベース装置は、キャッシュ装置のキャッシュが更新されたとき、キャッシュ装置からその更新情報を受信できるので、キャッシュ上に存在する最新のキャッシュエントリを把握することができる。

また、本発明は、キャッシュメンテナンス方法を、コンピュータであるデータベース装置に実行させるためのプログラムとした。

このようにすることで、一般的なデータベース装置に、前記したキャッシュメンテナンス方法を実行させることができる。

本発明によれば、データベースにおけるキャッシュメンテナンスの負荷を軽減することができる。

本実施の形態のデータベースシステムの構成例を示した図である。 図１のデータベースシステムの概要を概念的に示した図である。 （ａ）は、図１のベーステーブルを例示した図であり、（ｂ）は、キャッシュ作成用クエリを例示した図である。 図１のキャッシュ管理テーブルを例示した図である。 図１のキャッシュを例示した図である。 図１のデータベース装置の処理手順を示した図である。 図１のベーステーブル更新時の処理（Ｓ３３０）の詳細フローを示した図である。 図１のベーステーブルの更新処理により影響を受けるキャッシュエントリの特定処理の例を説明した図である。 図７のベーステーブルの絞り込み処理（Ｓ４２０）の詳細フローを示した図である。 図７のベーステーブルの絞り込み処理の例を示した図である。 （ａ）は、図１のキャッシュ管理テーブルによるベーステーブルの絞り込みの問い合わせを例示した図であり、（ｂ）は、絞り込み結果を例示した図である。 本実施の形態のデータベースシステムの構成例を示した図である。

以下、本発明を実施するための形態（以下、実施の形態とする）について説明する。まず、図１を用いて本実施の形態のデータベースシステムの概要を説明する。データベースシステムは、データベース装置１００と、キャッシュ２３１を備えるキャッシュ装置２００と、データベース装置１００のデータの更新リクエストや読み出しリクエストを送信する端末装置３００とを含んで構成される。このデータベース装置１００、キャッシュ装置２００および端末装置３００は、インターネット等のネットワーク４００により接続される。キャッシュ装置２００のキャッシュ２３１には、端末装置３００からデータベース装置１００ヘの読み出し結果を利用して作られたデータ（キャッシュエントリ）が格納される。そして、端末装置３００が、キャッシュ２３１からデータを読み出す場合、キャッシュ２３１に当該データがあるか否かを判断し、当該データがない場合、データベース装置１００からデータを読み出す。そして、キャッシュ装置２００は、キャッシュ２３１に、端末装置３００からのリクエストを関連付けたデータ（キャッシュエントリ）を格納する。以降、端末装置３００からのリクエストが同じデータのリクエストであれば、キャッシュ２３１から、そのデータのキャッシュエントリを読み出して利用する。このデータベースシステムの詳細は後記する。

次に、このようなデータベースシステムの動作概要を、図２を用いて説明する。まず、データベースシステムのデータベース装置１００は、ベーステーブル１３１１の更新リクエストを受け付けると、（１）ベーステーブル１３１１のデータのうち、キャッシュ装置２００のキャッシュ２３１上にキャッシュエントリがあるデータを絞り込む。ここでキャッシュ２３１上にキャッシュエントリがあるデータについては、キャッシュ管理テーブル１３１２に記録されている。よって、データベース装置１００は、このキャッシュ管理テーブル１３１２を参照することで、ベーステーブル１３１１のどのデータに絞り込めばよいかが分かる。例えば、キャッシュ管理テーブル１３１２にkey値＝d，e，fの記録があれば、これに基づき、ベーステーブル１３１１のデータのうち、このkey値＝d，e，fを持つデータに絞り込めばよいことが分かる。

次に、（２）データベース装置１００は、ベーステーブル１３１１の更新処理の内容を参照して、ベーステーブル１３１１の更新処理により影響を受けるデータを特定する。例えば、更新処理の内容が、ベーステーブル１３１１に、author_uid＝bのデータを挿入、というものであれば、更新処理により影響を受けるデータは、ベーステーブル１３１１のto_uid＝bを持つデータである。よって、（１）で絞り込まれたベーステーブル１３１１のデータの中から、このto_uid＝bを持つデータ（from_uid＝d，fを持つデータ）を特定する。

そして、（３）データベース装置１００は、（２）で特定したデータを参照して、キャッシュ２３１から破棄するキャッシュエントリのkey値のリスト（例えば、key値＝d，f）を作成し、キャッシュ装置２００へ送信する。この後、キャッシュ装置２００は、このリストに示されるキャッシュエントリを、キャッシュ２３１から破棄する。例えば、キャッシュ装置２００は、データベース装置１００から、key値＝d，fを示したリスト（破棄メッセージ）を受信すると、このキャッシュ２３１から、このd，fをkey値とするキャッシュエントリを破棄する。

このように、データベース装置１００はベーステーブル１３１１の更新処理の発生時、この更新処理の影響を受けるデータのうち、キャッシュ２３１上にキャッシュエントリが存在するデータを特定し、このデータのキャッシュエントリの破棄メッセージを、キャッシュ装置２００へ送信する。つまり、データベース装置１００は、キャッシュ装置２００のキャッシュ２３１上に存在するキャッシュエントリを対象として破棄メッセージを送信するので、実際にはキャッシュ２３１上に存在しないキャッシュエントリの特定を行う必要がなくなる。また、無駄な破棄メッセージを送信することがなくなる。よって、データベース装置によるキャッシュメンテナンスの処理負荷を軽減することができる。

次に、図１に戻り、データベースシステムの構成を詳細に説明する。
＜データベース装置＞
データベース装置１００は、ネットワーク４００経由で通信可能なコンピュータにより実現され、入出力部１１０、記憶部１３０および処理部１２０を備える。入出力部１１０は、ネットワーク４００経由で、端末装置３００等から、このデータベース装置１００のベーステーブル１３１１の更新リクエストや読み出しリクエストの入力を受け付けたり、キャッシュ２３１上のキャッシュエントリの破棄メッセージを送信したりするためのインタフェースである。記憶部１３０は、ベーステーブル１３１１およびキャッシュ管理テーブル１３１２からなるデータベース部１３１を備える。処理部１２０は、このデータベース装置１００全体の制御を司り、ここでは主に、キャッシュ管理テーブル１３１２の更新や、ベーステーブル１３１１の更新処理後、この更新処理により影響を受けるデータを特定し、キャッシュ装置２００へ、このデータのキャッシュエントリの破棄メッセージを送信する。

入出力部１１０は、通信インタフェースや入出力インタフェースから構成される。また、処理部１２０は、このデータベース装置１００が備えるＣＰＵ（Central Processing Unit）によるプログラム実行処理や、専用回路等により実現される。さらに、記憶部１３０は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等の記憶媒体から構成される。なお、処理部１２０の機能をプログラム実行処理により実現する場合、記憶部１３０には、このデータベース装置１００の機能を実現するためのプログラムが格納される。

記憶部１３０は、前記したとおりベーステーブル１３１１およびキャッシュ管理テーブル１３１２からなるデータベース部１３１を備える。

ベーステーブル１３１１は、１以上のデータを記憶するテーブルである。ベーステーブル１３１１は、例えば、図３（ａ）に示すmessageテーブル、followerテーブルのように複数であってもよい。なお、図３（ａ）に示すmessageテーブルはmessage_idごとに、そのメッセージのauthor_uid（作成者）およびbody（本文）を示したテーブルである。followerテーブルはfrom_uid（メッセージの送信元ユーザ）ごとに、to_uid（メッセージの送信先ユーザ）を示したテーブルである。なお、このベーステーブル１３１１に対し、ベーステーブル処理部１２１は、キャッシュ作成用クエリ（キャッシュ２３１に格納するキャッシュエントリを作成するためのクエリ）として、例えば、図３（ｂ）に示すクエリを作成する。このキャッシュ作成用クエリは、［UID］をパラメータとするプリペアードクエリであり、messageテーブルおよびfollowerテーブルから、followerテーブルのfrom_uidが、［UID］（指定されたユーザＩＤ）のデータで、かつ、そのデータのto_uidが、messageテーブルのauthor_uidと同じuidであるデータのmessage_idを探すというクエリである。なお、パラメータ（例えば、［UID］）で指定されたベーステーブル１３１１の属性をパラメータ属性という。前記した例では、followerテーブルのfrom_uidがパラメータ属性である。

図１のキャッシュ管理テーブル１３１２は、キャッシュ装置２００のキャッシュ２３１上に存在するキャッシュエントリを示した情報である。このキャッシュ管理テーブル１３１２は、例えば、図４に示すようにキャッシュ２３１上に存在するキャッシュエントリのkey値を示した情報である。このキャッシュ管理テーブル１３１２は、キャッシュエントリ特定部１２３（後記）が、ベーステーブル１３１１のデータの絞り込みを行う際に参照される。

図１の処理部１２０は、ベーステーブル処理部１２１と、キャッシュ管理テーブル更新部１２２と、キャッシュエントリ特定部１２３と、キャッシュメンテナンス部１２４とを備える。

ベーステーブル処理部１２１は、入出力部１１０経由で、端末装置３００等からベーステーブル１３１１のデータの更新リクエスト（更新問い合わせ）や読み出しリクエストを受け付ける。そしてこれらのリクエストに応じて、ベーステーブル１３１１のデータの更新や読み出しを実行する。そして、ベーステーブル処理部１２１は、その実行結果を、キャッシュ装置２００へ送信し、キャッシュ装置２００は、キャッシュ２３１上にキャッシュエントリを追加する。なお、更新リクエスト（更新問い合わせ）は、例えば、ベーステーブル１３１１に対するINSERT、UPDATE、DELETE等である。

キャッシュ管理テーブル更新部１２２は、キャッシュ装置２００のキャッシュトラック部２２３（後記）により、キャッシュ２３１上に存在するキャッシュエントリの情報を取得し、この情報をキャッシュ管理テーブル１３１２に記録する。つまり、キャッシュ管理テーブル１３１２を更新する。

キャッシュエントリ特定部１２３は、ベーステーブル１３１１を監視し、ベーステーブル１３１１の更新処理が発生すると、その更新処理内容（例えば、更新されたベーステーブル１３１１の識別情報およびこのベーステーブル１３１１において更新されたレコード）を、記憶部１３０の所定領域に記憶する。そして、キャッシュ管理テーブル１３１２と、ベーステーブル１３１１の更新処理内容とを参照して、キャッシュ２３１に記憶されたデータのうち、この更新処理の対象となるデータに関するキャッシュエントリを特定する。具体的には、キャッシュエントリ特定部１２３は、まず、キャッシュ管理テーブル１３１２を参照して、ベーステーブル１３１１のデータのうち、キャッシュ２３１上にキャッシュエントリのあるデータ（レコード）を絞り込む。そして、キャッシュエントリ特定部１２３は、ベーステーブル１３１１の更新処理内容から、ベーステーブル１３１１の更新により影響を受けるデータ（例えば、更新されるデータのkey値と同じkey値を持つデータ）のキャッシュエントリを特定する。

キャッシュメンテナンス部１２４は、キャッシュエントリ特定部１２３が特定したキャッシュエントリの破棄を指示する破棄メッセージをキャッシュ装置２００へ送信する。また、キャッシュメンテナンス部１２４は、ベーステーブル処理部１２１において、端末装置３００からのリクエストに応じ、ベーステーブル１３１１のデータの更新や読み出しを実行したとき、その実行結果を示すキャッシュエントリの追加を指示する追加メッセージをキャッシュ装置２００へ送信する。

＜キャッシュ装置＞
キャッシュ装置２００は、データベース装置１００のキャッシュ２３１を備え、このキャッシュ２３１上に新たなキャッシュエントリを追加（セット）したり、所定のキャッシュエントリを破棄（エクスパイヤ）したり、読み出し（ゲットし）たりする。このキャッシュ装置２００は、ネットワーク４００経由で通信可能なコンピュータにより実現され、入出力部２１０、記憶部２３０および処理部２２０を備える。

入出力部２１０は、ネットワーク４００経由で、端末装置３００等から、データの更新や読み出しのリクエストの入力を受け付けたり、データベース装置１００から、キャッシュエントリの破棄メッセージや追加メッセージ、キャッシュイン・アウト結果（キャッシュ２３１の更新処理結果）を出力したりするためのインタフェースである。記憶部２３０は、キャッシュ２３１を記憶する。処理部２２０は、キャッシュ装置２００全体の制御を司り、ここでは主に、データベース装置１００からの指示に従いキャッシュ２３１上のキャッシュエントリの追加や削除を行う。また、処理部２２０は、このキャッシュ２３１上のキャッシュエントリを監視し、その監視結果をデータベース装置１００へ送信する。

入出力部２１０は、通信インタフェースや入出力インタフェースから構成される。また、処理部２２０は、このキャッシュ装置２００が備えるＣＰＵによるプログラム実行処理や、専用回路等により実現される。さらに、記憶部２３０は、ＲＡＭやＨＤＤ等の記憶媒体から構成される。なお、キャッシュ２３１は、例えば、この記憶部２３０のＲＡＭ上に形成される。キャッシュ装置２００の処理部２２０の機能をプログラム実行処理により実現する場合、記憶部２３０には、処理部２２０の機能を実現するためのプログラムが格納される。

記憶部２３０は、１以上のキャッシュエントリからなるキャッシュ２３１を備える。キャッシュエントリとは、キャッシュ２３１における記憶単位である。このキャッシュ２３１は、例えば、図５に示すように、key値（ベーステーブル１３１１のデータの読み出し要求に用いたkey値）ごとに、そのkey値に用いて読み出したデータの値（value）を示した情報である。ここでは、１つのkey値に対するvalueを１つのキャッシュエントリとする。

処理部２２０は、キャッシュ処理部２２１と、キャッシュ更新部２２２と、キャッシュトラック部２２３とを備える。

キャッシュ処理部２２１は、端末装置３００等からのリクエストに応じて、キャッシュ２３１のキャッシュエントリを読み出し処理等を実行する。そして、その結果をリクエストの送信元へ返す。なお、キャッシュ２３１上にリクエストの対象データのキャッシュエントリがなかった場合、その旨をリクエストの送信元へ返す。

キャッシュ更新部２２２は、データベース装置１００からの破棄メッセージに従い、キャッシュ２３１上のキャッシュエントリを破棄（エクスパイヤ）する。また、データベース装置１００から追加メッセージを受信したときには、これに従い、キャッシュ２３１上にキャッシュエントリを追加（セット）する。なお、キャッシュ更新部２２２は、キャッシュ２３１上のキャッシュエントリの総容量が所定量を超えたときに、一部のキャッシュエントリを破棄するようにしてもよい。このときのアルゴリズムは、例えば、ＬＲＵ（Least Recently Used）やＭＲＵ（Most Recently Used）を用いる。なお、以下の説明において、キャッシュ２３１上に新たなキャッシュエントリが追加されることをキャッシュインといい、キャッシュ２３１上のキャッシュエントリが破棄されることをキャッシュアウトという。また、キャッシュインまたはキャッシュアウトが行われることを、まとめてキャッシュイン・アウトと表記する。

キャッシュトラック部２２３は、キャッシュ２３１を監視し、キャッシュ２３１上に存在するキャッシュエントリの情報をデータベース装置１００へ送信する。例えば、キャッシュ２３１の更新処理が行われたとき、この更新処理後のキャッシュ２３１上のキャッシュエントリの情報をデータベース装置１００へ送信する。なお、データベース装置１００のキャッシュ管理テーブル更新部１２２は、このキャッシュエントリの情報を受信すると、この情報をキャッシュ管理テーブル１３１２に記録する。

＜処理手順＞
次に、図６を用いて図１のデータベース装置１００の処理手順を説明する。まず、データベース装置１００は、ベーステーブル１３１１の更新か、キャッシュ装置２００のキャッシュ２３１のキャッシュ更新（キャッシュイン・アウト）が発生するまで待機し（Ｓ３１０）、ベーステーブル１３１１の更新発生を検出したとき（Ｓ３２０の“ベーステーブルの更新が発生”）、ベーステーブル１３１１の更新時の処理を実行する（Ｓ３３０）。つまり、データベース装置１００のベーステーブル処理部１２１が、端末装置３００等から、ベーステーブル１３１１の更新処理要求を受信し、これに基づきベーステーブル１３１１の更新処理したとき、Ｓ３３０の処理を実行する。そして、Ｓ３５０へ進む。

一方、データベース装置１００は、キャッシュ装置２００のキャッシュ２３１の更新処理（キャッシュイン・アウト）の発生を検出したとき（Ｓ３２０の“キャッシュ更新が発生”）、データベース装置１００のキャッシュ管理テーブル更新部１２２は、キャッシュ管理テーブル１３１２を更新する（Ｓ３４０）。つまり、キャッシュ装置２００のキャッシュトラック部２２３は、キャッシュ２３１のキャッシュイン・アウトを監視し、キャッシュイン・アウトの発生を検出すると、そのキャッシュイン・アウト結果を、データベース装置１００へ通知する。データベース装置１００のキャッシュ管理テーブル更新部１２２は、このキャッシュイン・アウト結果に基づき、キャッシュ管理テーブル１３１２（図４参照）に、キャッシュ２３１上に存在するキャッシュエントリの情報を記録する。

そして、データベース装置１００は処理の終了命令等の入力があると（Ｓ３５０のＹｅｓ）、処理を終了し、終了命令等の入力がなければ（Ｓ３５０のＮｏ）、Ｓ３１０へ戻る。

次に、図７を用いて、図６のベーステーブル更新時の処理（Ｓ３３０）の詳細を説明する。まず、図１のデータベース装置１００のベーステーブル処理部１２１は、ベーステーブル１３１１の更新を受け付ける（Ｓ４１０）。そして、ベーステーブル処理部１２１は、これに基づきベーステーブル１３１１を更新する。ここで、キャッシュエントリ特定部１２３は、ベーステーブル１３１１を監視し、ベーステーブル１３１１の更新処理内容（例えば、更新されたベーステーブル１３１１の識別情報および更新されたレコード）を、記憶部１３０の所定領域に記憶する。

続いて、データベース装置１００のキャッシュエントリ特定部１２３は、キャッシュ管理テーブル１３１２を用いて、ベーステーブル１３１１中からレコード（データ）を絞り込む（Ｓ４２０）。すなわち、キャッシュ管理テーブル１３１２を用いて、ベーステーブル１３１１中から、キャッシュ２３１上に存在するキャッシュエントリに関するレコードを絞り込む。このレコードの絞り込み処理の詳細は後記する。

次に、キャッシュエントリ特定部１２３は、ベーステーブル１３１１の更新により影響を受けるキャッシュエントリを特定する（Ｓ４３０）。すなわち、キャッシュエントリ特定部１２３は、記憶部１３０に記憶されたベーステーブル１３１１の更新処理内容およびＳ４２０におけるベーステーブル１３１１の絞り込み結果をもとに、ベーステーブル１３１１の更新処理により影響を受けるキャッシュエントリを特定する。

例えば、図８の（ａ）に示すように、messageテーブルに符号１００１に示すレコードが挿入され、図７のＳ４２０で、絞り込まれたfollowerテーブルのデータが符号１００２に示すデータであった場合、キャッシュエントリ特定部１２３は、例えば、図８の（ｂ）に示すようなキャッシュ破棄用クエリを発行する。このキャッシュ破棄用クエリは、絞り込まれたfollowerテーブルのto_uid＝bをパラメータとし、このto_uid＝bを持つレコードのfrom_uidの値からkey値を選択することを指示するプリペアードクエリである。ここで、followerテーブルから、to_uid＝bの値を持つレコードのfrom_uidの値は「d，f」であるので、破棄対象のキャッシュエントリの特定結果として「d，f」を得る。

図７の説明に戻る。Ｓ４３０で、キャッシュエントリ特定部１２３が、キャッシュエントリの特定をした後、キャッシュメンテナンス部１２４は、キャッシュ装置２００に対して、Ｓ４３０で特定した破棄メッセージを送信する（Ｓ４４０）。この破棄メッセージを受信したキャッシュ装置２００は、この破棄メッセージに示されるキャッシュエントリを破棄する。そして、ベーステーブル１３１１の更新処理がまだ終了していなければ（Ｓ４５０のＮｏ）、Ｓ４１０へ戻り、ベーステーブル１３１１の更新処理が終了していれば（Ｓ４５０のＹｅｓ）、処理を終了する。

このようにすることで、データベース装置１００は、キャッシュ装置２００に対し、キャッシュ装置２００のキャッシュ２３１上に存在するキャッシュエントリのうち、ベーステーブル１３１１の更新により影響を受けるキャッシュエントリを破棄させることができる。

ここで、図９を用いて、図７のＳ４２０の処理の詳細を説明する。まず、図１のデータベース装置１００のキャッシュエントリ特定部１２３は、キャッシュ管理テーブル１３１２を読み出す（Ｓ１０１０）。つまり、キャッシュ２３１上に存在するキャッシュエントリのkey値のリストを読み出す。そして、キャッシュエントリ特定部１２３は、パラメータ属性を含むベーステーブル１３１１を選択する（Ｓ１０２０）。例えば、図３（ｂ）に示すキャッシュ作成用クエリにおけるパラメータ属性は、followerテーブルのfrom_uidなので、キャッシュ管理テーブル１３１２は、followerテーブルを選択する。そして、選択したベーステーブル１３１１のレコードをキャッシュ管理テーブル１３１２の内容に基づいて選択（ＳＥＬＥＣＴ）する（Ｓ１０３０）。例えば、キャッシュエントリ特定部１２３が、図１０に示すキャッシュ管理テーブル１３１２を用いて、ベーステーブル１３１１（followerテーブル）のレコードの絞り込みを行う場合、図１１（ａ）に示すようなベーステーブル１３１１の絞り込みの問い合わせを発行する。つまり、followerテーブルを選択し、このfollowerテーブルのfrom_uidをパラメータ属性として、キャッシュ管理テーブル１３１２に記録されるkey値と同じ値のレコードを絞り込む問い合わせを発行する。この問い合わせをもとに、followerテーブルから、from_uid＝d，e，fのレコードを検索し、図１１の（ｂ）に示すような絞り込み結果を得る。

図９の説明に戻る。データベース装置１００のキャッシュエントリ特定部１２３は、すべてのベーステーブル１３１１の処理を終了すると（Ｓ１０４０のＹｅｓ）、Ｓ４２０の処理を終了する。一方、まだ処理していないベーステーブル１３１１があれば（Ｓ１０４０のＮｏ）、Ｓ１０１０へ戻る。

このようにすることで、キャッシュエントリ特定部１２３は、ベーステーブル１３１１のレコードを、キャッシュ２３１上に存在するキャッシュエントリに関するレコードに絞り込むことができる。

以上説明したデータベース装置１００によれば、ベーステーブル１３１１の更新処理により影響を受けるデータのキャッシュエントリのうち、実際にキャッシュ２３１に存在するキャッシュエントリの破棄メッセージを、キャッシュ装置２００へ送信することができる。つまり、データベース装置１００はキャッシュ装置２００に対し、必要以上に多くのキャッシュエントリの破棄メッセージを送信する必要がなくなるので、キャッシュ２３１のキャッシュメンテナンスの負荷を軽減することができる。

なお、データベースシステムにおけるキャッシュ装置２００は、図１２に示すように複数台用あってもよい。この場合、データベース装置１００は、各キャッシュ装置２００のキャッシュトラック部２２３から、送信元のキャッシュ装置２００の識別情報と、そのキャッシュ装置２００のキャッシュ２３１のキャッシュイン・アウト結果とを受信し、キャッシュ管理テーブル１３１２を更新する。これにより、キャッシュ管理テーブル１３１２には、各キャッシュ２３１上に存在するキャッシュエントリの情報とともに、各キャッシュエントリがどのキャッシュ装置２００に存在するかが記録される。このようなキャッシュ管理テーブル１３１２を参照することで、データベース装置１００は、当該キャッシュエントリのあるキャッシュ装置２００に対し破棄メッセージを送信することができる。

１００ データベース装置
１１０，２１０ 入出力部
１２０，２２０ 処理部
１２１ ベーステーブル処理部
１２２ キャッシュ管理テーブル更新部
１２３ キャッシュエントリ特定部
１２４ キャッシュメンテナンス部
１３０，２３０ 記憶部
１３１ データベース部
２００ キャッシュ装置
２２１ キャッシュ処理部
２２２ キャッシュ更新部
２２３ キャッシュトラック部
２３１ キャッシュ
３００ 端末装置
４００ ネットワーク
１３１１ ベーステーブル
１３１２ キャッシュ管理テーブル

Claims (4)

1. データベース装置から読み出されたデータのキャッシュを備えるキャッシュ装置と、前記キャッシュ装置とネットワーク経由で接続された前記データベース装置とを有するデータベースシステムにおいて、自身のデータベース装置のデータの更新処理が行われたとき、前記ネットワーク経由で前記キャッシュ装置におけるキャッシュの破棄メッセージを送信するデータベース装置であって、
   前記データを記憶する複数のベーステーブルと、このベーステーブルに記憶されたデータのうち、前記キャッシュにキャッシュエントリのあるデータを示したキャッシュ管理テーブルとを記憶する記憶部と、
   前記ネットワーク経由で、前記キャッシュ装置との間で各種情報の送受信を司る入出力部と、
   前記ベーステーブルの更新処理が発生したとき、前記キャッシュ装置に格納するキャッシュエントリを作成するための、前記複数のベーステーブルを対象としたキャッシュ作成用クエリを用いて、当該キャッシュ作成用クエリに記載の特定のベーステーブルの属性を示すパラメータ属性によってベーステーブルおよび属性を特定し、前記キャッシュ管理テーブルを用いて、特定したベーステーブルからレコードを絞り込み、前記ベーステーブルの更新処理内容を参照して、前記ベーステーブルの更新処理の影響を受けるデータのうち、前記キャッシュにキャッシュエントリが存在するデータを特定するキャッシュエントリ特定部と、
   前記入出力部経由で、前記キャッシュ装置に対し、前記特定したデータのキャッシュエントリの破棄メッセージを送信するキャッシュメンテナンス部と、
   前記入出力部経由で、前記キャッシュ装置におけるキャッシュエントリの更新情報を受信したとき、当該更新情報に基づき、前記キャッシュ管理テーブルを更新するキャッシュ管理テーブル更新部とを備えることを特徴とするデータベース装置。
2. 請求項１に記載のデータベース装置と、前記キャッシュの更新処理を監視し、前記ネットワーク経由で、前記キャッシュエントリの更新情報を前記データベース装置へ送信するキャッシュトラック部を備えるキャッシュ装置を１以上とを含んでなることを特徴とするデータベースシステム。
3. データベース装置から読み出されたデータのキャッシュを備えるキャッシュ装置と、前記キャッシュ装置とネットワーク経由で接続された前記データベース装置とを有するデータベースシステムにおいて、自身のデータベース装置のデータの更新処理が行われたとき、前記ネットワーク経由で前記キャッシュ装置におけるキャッシュの破棄メッセージを送信し、前記データを記憶する複数のベーステーブルと、このベーステーブルに記憶されたデータのうち、前記キャッシュにキャッシュエントリのあるデータを示したキャッシュ管理テーブルとを記憶する記憶部を備えるデータベース装置が、
   前記ベーステーブルの更新処理が発生したとき、前記キャッシュ装置に格納するキャッシュエントリを作成するための、前記複数のベーステーブルを対象としたキャッシュ作成用クエリを用いて、当該キャッシュ作成用クエリに記載の特定のベーステーブルの属性を示すパラメータ属性によってベーステーブルおよび属性を特定し、前記キャッシュ管理テーブルを用いて、特定したベーステーブルからレコードを絞り込み、前記ベーステーブルの更新処理内容を参照して、前記ベーステーブルの更新処理の影響を受けるデータのうち、前記キャッシュにキャッシュエントリが存在するデータを特定するステップと、
   前記キャッシュ装置に対し、前記特定したデータのキャッシュエントリの破棄メッセージを送信するステップと、
   前記キャッシュ装置におけるキャッシュエントリの更新情報を受信したとき、当該更新情報に基づき、前記キャッシュ管理テーブルを更新するステップとを実行することを特徴とするキャッシュメンテナンス方法。
4. 請求項３に記載のキャッシュメンテナンス方法を、コンピュータである前記データベース装置に実行させるためのプログラム。
   

Images