JP5385874B2 - キャッシュ管理装置、キャッシュ管理プログラム及び記録媒体 - Google Patents

Description

本発明は、データベースの検索結果をキャッシュとして保存し利用する検索システムにおいて、データベースとキャッシュの不整合を軽減する技術に関する。

検索システムにおいては、リクエストに応じてデータベースを検索し、その検索結果をレスポンスとして返却する。この際、同様のリクエストがあった場合、その都度、データベースを検索することはレスポンス時間やサーバ負荷を増大することとなる。そこで、リクエストに対するレスポンスをキャッシュデータとしてメモリなどの高速な記憶装置に蓄えておき、同様のリクエストがあった場合、レスポンス時間の短縮やサーバ負荷の軽減を実現している。

"RFC 2616, Hypertext Transfer Protocol - HTTP/1.1: Caching in HTTP", [online],［平成２２年８月９日検索］、インターネット〈ＵＲＬ：http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html〉

検索結果をキャッシュとして保存する場合、データベースとの整合性を保つことが重要となる。つまり、データベースに変更（データの追加／削除／更新）があり、キャッシュに含まれる情報と最新のデータベース内の情報に不整合が生じると、ある検索クエリに対する最新の検索結果とキャッシュとして保存した検索結果が異なるという問題が生じる。

そこで、一般的には、各キャッシュデータに有効期限を設定することで十分に新鮮であるもののみをキャッシュとして用いる形にしたり、定期的にキャッシュとデータベースとの差分をチェックすることで対処している。しかしながら、前者の方法では、有効期限の設定によっては不整合が大きくなり、後者は全キャッシュをチェックするため、キャッシュ更新に要する処理が大きくなるという問題がある。

また、データベースへの変更に応じてキャッシュを更新する方法も考えられるが、検索クエリに対応する検索結果をキャッシュとして保存する場合、あるデータが複数の異なる検索結果のキャッシュに含まれることがある。そのため、あるデータが更新／削除された場合、そのデータが含まれるキャッシュを全て探し出して無効化する必要が生じる。また、データが追加／更新された場合、そのデータが関連するキャッシュを探すためには、検索クエリとデータを内容レベル（例えば、検索クエリで指定されたキーワードとデータ内容に含まれるテキスト情報）で照合する必要が生じ、全キャッシュに対してこのような処理を行うことは処理量が非常に大きくなり、非効率である。

他にも、データベースへの変更に応じ、保持するキャッシュを全削除する方法も考えられるが、データベースの更新頻度、キャッシュの生成頻度によっては、処理のみが増え、キャッシュが有効的に利用されなくなり、無駄が多く、非効率なキャッシュ管理となる。

本発明は、上記に鑑みてなされたものであり、キャッシュを用いた検索システムにおいて、データベースへの変更に伴うデータベースとキャッシュとの不整合を軽減し、かつ、キャッシュを効率的に管理することを実現することを目的とする。

第１の本発明に係るキャッシュ管理装置は、データベースに格納されたデータを検索クエリを用いて検索した検索結果をキャッシュデータとしてキャッシュに格納するキャッシュ管理装置であって、前記データベースに格納されたデータを一意に識別するデータＩＤ、当該データに対する操作内容を示す管理フラグを関連付けた変更履歴を蓄積する変更履歴蓄積手段と、前記キャッシュに格納されたキャッシュデータを一意に識別するキャッシュＩＤ、当該キャッシュデータに対応する検索クエリ、当該キャッシュデータに含まれるデータのデータＩＤを記載した検索結果リスト、当該キャッシュデータの生成日時を関連付けたキャッシュレコードを蓄積するキャッシュ管理テーブルと、検索クエリを受信したときに、当該検索クエリに一致する検索クエリを持つ前記キャッシュレコードを前記キャッシュ管理テーブルから検索し、検索したキャッシュレコードから前記検索結果リストと前記生成日時を取得する取得手段と、前記取得手段が取得した前記検索結果リストに記載されたデータＩＤと一致するデータＩＤを持つ前記変更履歴を前記変更履歴蓄積手段から検索し、該当する変更履歴が検索されない場合及び検索された前記変更履歴すべての管理フラグがデータの追加を示している場合は、前記取得手段が検索した前記キャッシュレコードに対応する前記キュッシュデータは有効であると判定し、それ以外の場合は当該キャッシュデータは無効であると判定する判定手段と、前記判定手段が前記キャッシュデータは有効であると判定した場合は、当該キャッシュデータを検索結果として返却し、受信した検索クエリに一致する検索クエリを持つ前記キャッシュレコードが検索できない場合、及び前記判定手段が前記キャッシュデータは無効であると判定した場合は、受信した検索クエリを用いて前記データベースを検索して検索結果を返却し、当該検索結果を前記キャッシュにキャッシュデータとして格納するとともに、前記キャッシュ管理テーブルに当該キャッシュデータのキャッシュＩＤ、検索に用いた検索クエリ、当該キャッシュデータに含まれるデータのデータＩＤを記載した検索結果リスト、当該キャッシュデータの生成日時を関連付けたキャッシュレコードを追加する検索手段と、前記変更履歴蓄積手段から各変更履歴の管理フラグを取得し、当該管理フラグがデータの追加を示している場合はデータが追加された件数をカウントし、それ以外の場合はその変更履歴のデータＩＤを削除対象リストに追加し、前記変更履歴蓄積手段から全変更履歴を削除する変更履歴更新手段と、前記件数に基づいて算出した不整合の程度が所定の閾値を超えた場合、前記キャッシュ管理テーブルの全キャッシュレコード及び前記キャッシュの格納された全キャッシュデータを削除し、前記件数に基づいて算出した不整合の程度が所定の閾値を超えない場合、前記削除対象リストに記載されているデータＩＤを有する前記キャッシュレコードを前記キャッシュ管理テーブルから削除するとともに、当該キャッシュレコードに対応するキャッシュデータを前記キャッシュから削除するキャッシュ削除手段と、を有することを特徴とする。

上記第１の本発明に係るキャッシュ管理装置において、前記データベースにデータが追加されたときは、前記変更履歴蓄積手段に変更履歴を追加して当該変更履歴に前記データＩＤ、データの追加を示す管理フラグを登録し、前記データベースのデータが変更あるいは削除されたときは、変更あるいは削除されたデータのデータＩＤを有する変更履歴を前記変更履歴蓄積手段から検索し、該当する変更履歴がない場合及び管理フラグがデータの追加を示す変更履歴のみが検索された場合は、前記変更履歴蓄積手段に変更履歴を追加して当該変更履歴に前記データＩＤ、データの変更あるいは削除を示す管理フラグを登録し、管理フラグがデータの変更あるいは削除を示す変更履歴が検索された場合は、当該変更履歴の管理フラグを更新する変更履歴管理手段を有することを特徴とする。

第２の本発明に係るキャッシュ管理プログラムは、上記キャッシュ管理装置を構成する各手段としてコンピュータを機能させることを特徴とする。

第３の本発明に係る記録媒体は、上記キャッシュ管理プログラムを記録したことを特徴とする。

本発明によれば、キャッシュを用いた検索システムにおいて、データベースへの変更に伴うデータベースとキャッシュとの不整合を軽減し、かつ、キャッシュを効率的に管理することを実現することができる。

第１の実施の形態におけるキャッシュ管理装置を含む検索システムの構成を示すブロック図である。 データベース管理テーブルの保持する情報の例を示す図である。 キャッシュ管理テーブルの保持する情報の例を示す図である。 第１の実施の形態におけるデータベース変更時の処理の流れを示すフローチャートである。 第１の実施の形態における検索時の処理の流れを示すフローチャートである。 第１の実施の形態における有効期限切れキャッシュデータを削除する処理の流れを示すフローチャートである。 第２の実施の形態におけるキャッシュ管理装置を含む検索システムの構成を示すブロック図である。 データベース変更履歴の保持する情報の例を示す図である。 第２の実施の形態におけるデータベース変更時の処理の流れを示すフローチャートである。 第２の実施の形態における検索時の処理の流れを示すフローチャートである。 第２の実施の形態におけるキャッシュデータを削除する処理の流れを示すフローチャートである。 第２の実施の形態におけるキャッシュデータを削除する別の処理の流れを示すフローチャートである。 第３の実施の形態におけるデータベースにデータを追加したときの処理の流れを示すフローチャートである。 第４の実施の形態におけるキャッシュデータの有効性確認に無効期間を設けた場合の検索時の処理の流れを示すフローチャートである。

以下、本発明の実施の形態について図面を用いて説明する。

［第１の実施の形態］
図１は、第１の実施の形態におけるキャッシュ管理装置を含む検索システムの構成を示すブロック図である。同図に示す検索システムは、データ登録処理部１００、検索処理部２００、キャッシュ管理部３００、データベース管理テーブル４００、データベース４１０、キャッシュ管理テーブル５００、およびキャッシュ５１０を備える。検索システムが備える各部は、演算処理装置、記憶装置等を備えたコンピュータにより構成して、各部の処理がプログラムによって実行されるものとしてもよい。このプログラムは検索システムが備える記憶装置に記憶されており、磁気ディスク、光ディスク、半導体メモリ等の記録媒体に記録することも、ネットワークを通して提供することも可能である。以下、各部について説明する。

データ登録処理部１００は、データベース４１０への登録要求を受信し、データベース４１０への変更（データの追加／更新／削除）処理を行うとともに、データベース４１０への変更内容をデータベース管理テーブル４００に登録する。

検索処理部２００は、検索クエリの受信、検索結果の返却といった検索処理を行う。

キャッシュ管理部３００は、キャッシュ５１０が保持するキャッシュデータの管理・削除を行うとともに、検索時にキャッシュの有効性を確認する。

データベース管理テーブル４００は、データベース４１０に格納されたデータの情報を管理する。図２に、データベース管理テーブル４００の保持する情報の例を示す。同図に示すように、データベース管理テーブル４００の各レコードは、データベース４１０に格納されたデータを一意に識別するデータＩＤ、データ自体を格納するデータ内容、およびデータベースへの変更が発生した日時を示す登録日時で構成される。

キャッシュ管理テーブル５００は、キャッシュ５１０に保存されたキャッシュデータの情報を管理する。図３に、キャッシュ管理テーブル５００の保持する情報の例を示す。同図に示すように、キャッシュ管理テーブル５００の各レコードは、キャッシュ５１０が保持するキャッシュデータを一意に識別するキャッシュＩＤ、キャッシュデータに対応する検索クエリ、キャッシュデータに含まれるデータのデータＩＤが記載された検索結果ＩＤリスト、およびキャッシュデータを生成した日時を示す生成日時で構成される。なお、キャッシュＩＤは、後述する検索時の処理において、受信した検索クエリとキャッシュ管理テーブル５００の検索クエリとの照合を高速に行うため、検索クエリの文字列から生成するハッシュ値を用いるとよい。また、キャッシュ５１０においては、検索クエリに対する検索結果をキャッシュデータとして保管するが、そのキャッシュデータをキャッシュＩＤに対応する形で保管するとよい。例えば、図３の項番ｃ１のキャッシュデータは、"cache_000010010" というファイル名とする。

次に、データベース変更時の処理について説明する。図４は、データベース変更時の処理の流れを示すフローチャートである。

まず、データ登録処理部１００がデータベース４１０への登録要求を受信すると、その登録要求をデータベース４１０に送信するとともに、その登録要求がデータの追加／更新であるか、データの削除であるかを判定する（ステップＳ１０１）。

登録要求が追加／更新の場合、データ登録処理部１００は、データベース管理テーブル４００から登録要求のデータに該当するレコードを検索し（ステップＳ１０２）、該当レコードの有無を判定する（ステップＳ１０３）。該当するレコードは、データベース４１０に格納されたデータを一意に識別するデータＩＤをキーに検索する。

該当レコードが無い場合は、データベース管理テーブル４００にレコードを追加し（ステップＳ１０４）、そのレコードにデータベース４１０に追加した内容（データＩＤ、データ内容、登録日時）を登録する（ステップＳ１０５）。

該当レコードが有る場合は、そのレコードをデータベース４１０を更新した内容（データ内容、登録日時）で更新する。

一方、登録要求が「削除」の場合は、データベース管理テーブル４００から登録要求のデータに該当するレコードを検索し（ステップＳ１０７）、そのレコードを削除する（ステップＳ１０８）。

次に、検索時の処理について説明する。図５は、検索時の処理の流れを示すフローチャートである。

まず、検索処理部２００が検索クエリを受信すると、キャッシュ管理部３００は、受信した検索クエリとキャッシュ管理テーブル５００の検索クエリを照合し（ステップＳ２０１）、該当するレコードが有るか否か判定する（ステップＳ２０２）。このとき、キャッシュＩＤを検索クエリの文字列から生成したハッシュ値としている場合、受信した検索クエリをハッシュ値に変換し、キャッシュＩＤと照合してもよい。

検索クエリを照合した結果、キャッシュ管理テーブル５００に該当レコードがある場合、当該レコードからキャッシュデータの生成日時を取得し（ステップＳ２０３）、当該レコードが示すキャッシュデータが有効期限内か否か確認する（ステップＳ２０４）。キャッシュデータの有効期限は運用に応じて設定されるものとし、例えば生成日時から１ヶ月を有効期限として設定する。

キャッシュデータが有効期限切れの場合、受信した検索クエリに対応するキャッシュデータを「無効」と判断し（ステップＳ２１３）、キャッシュ管理テーブル５００から当該レコードを削除するとともに、当該レコードが示すキャッシュデータをキャッシュ５１０から削除する（ステップＳ２１４）。そして、ステップＳ２２１へ進み受信した検索クエリでデータベースを検索する。

キャッシュデータが有効期限内の場合は、当該レコードから検索結果ＩＤリストを取得する（ステップＳ２０５）。

そして、検索結果ＩＤリストに記載されたデータＩＤをキーとして、各データＩＤに対応するデータベース管理テーブル４００のレコードを検索し（ステップＳ２０６）、該当するレコードが有るか否か判定する（ステップＳ２０７）。

データベース管理テーブル４００に該当するレコードが無い場合、つまり、該当するデータがデータベース４１０から削除されていた場合、キャッシュが「無効」である場合の処理を行って（ステップＳ２１３，Ｓ２１４）、ステップＳ２２１へ進み受信した検索クエリでデータベースを検索する。

データベース管理テーブル４００に該当するレコードがある場合、当該レコードの登録日時を取得し、ステップＳ２０３で取得した生成日時と照合し（ステップＳ２０８）、キャッシュデータの生成日時がデータの登録日時以前であるか否か判定する（ステップＳ２０９）。

キャッシュデータの生成日時がデータの登録日時以前の場合、つまり、キャッシュデータの生成後にデータが更新されている場合、キャッシュが「無効」である場合の処理を行って（ステップＳ２１３，Ｓ２１４）、ステップＳ２２１へ進みデータベースへの検索処理を行う。

キャッシュデータの生成日時がデータの登録日時以降の場合、つまり、キャッシュデータの生成後に該当するデータが更新されていない場合、検索結果ＩＤリストに記載されたデータＩＤすべてについて処理を行ったか否か判定し（ステップＳ２１０）、まだ処理していないデータＩＤが存在する場合はステップＳ２０６に戻り、検索結果ＩＤリストに記載された全てのデータＩＤに対して上記ステップＳ２０６〜Ｓ２０９の処理を繰り返す。

検索結果ＩＤリストに記載された全てのデータＩＤがそれぞれ示すデータが、受信した検索クエリに対応するキャッシュデータの生成後に更新／削除されていない場合、つまり、検索結果ＩＤリストに記載されたすべてのデータＩＤについて該当するデータレコードが存在し、そのデータレコードすべての登録日時が生成日時よりも古い場合、そのキャッシュデータを「有効」と判断し（ステップＳ２１１）、検索結果としてそのキャッシュデータを返却する（ステップＳ２１２）。

一方、受信した検索クエリに対応するキャッシュデータが無い場合、あるいは受信した検索クエリに対応するキャッシュデータが無効の場合は、受信した検索クエリでデータベース４１０を検索する（ステップＳ２２１）。そして、キャッシュ管理テーブル５００にレコードを追加し、追加したレコードにキャッシュデータの情報、検索結果の情報（キャッシュＩＤ、検索クエリ、検索結果ＩＤリスト、生成日時）を登録するとともに（ステップＳ２２２）、取得した検索結果をキャッシュデータとしてキャッシュ５１０に保存する（ステップＳ２２３）。そして、検索結果を返却する（ステップＳ２２４）。

次に、有効期限切れキャッシュデータを削除する処理について説明する。図６は、有効期限切れキャッシュデータを削除する処理の流れを示すフローチャートである。本処理は、運用に応じた設定に従って定期的（例えば、一週間毎）に実施されるものとする。

まず、キャッシュ管理部３００は、キャッシュ管理テーブル５００の各レコードの生成日時を取得し（ステップＳ３０１）、当該レコードが示すキャッシュデータが有効期限内か否か確認する（ステップＳ３０２）。キャッシュの有効期限は前述したように運用に応じて設定されるものである。

有効期限の確認の結果、キャッシュデータが有効期限切れであった場合、キャッシュ管理テーブル５００から当該レコードを削除するとともに、該当するキャッシュデータをキャッシュ５１０から削除する（ステップＳ３０３）。

キャッシュ管理テーブル５００の有する全てのレコードに対して処理を行ったか否か判定し（ステップＳ３０４）、全レコードに対して上記ステップＳ３０１〜Ｓ３０３の処理を繰り返す。

以上説明したように、本実施の形態によれば、データベース管理テーブル４００に、データベース４１０へ登録したデータを一意に識別するデータＩＤ、およびデータを追加／更新した登録日時を格納するとともに、キャッシュ管理テーブル５００に、キャッシュデータ生成時の検索クエリ、キャッシュデータに含まれるデータのデータＩＤを有する検索結果ＩＤリスト、およびキュッシュデータを生成した日時を示す生成日時を格納しておき、検索時に、検索クエリと合致する検索クエリを有するレコードをキャッシュ管理テーブル５００から検索し、検索されたレコードから検索結果ＩＤリストと生成日時を取得し、検索結果ＩＤリストに記載されたデータＩＤそれぞれについて一致するデータＩＤを持つレコードをデータベース管理テーブル４００から検索し、検索結果ＩＤリストに記載されたデータＩＤを有するレコードがデータベース管理テーブル４００に存在しない場合、あるいは、検索されたレコードの登録日時がキャッシュデータの生成日時よりも新しい場合は、検索クエリに対応するキャッシュデータは無効であると判断し、検索結果ＩＤリストに記載されたデータＩＤのすべてについて、一致するデータＩＤを有するレコードがデータベース管理テーブル４００に存在し、そのレコードすべての登録日時がキャッシュデータの生成日時よりも古い場合は、検索クエリに対応するキャッシュデータは有効であると判断することにより、データベース４１０からデータを削除すること、並びに、データベース４１０のデータを更新することで生じるデータベース４１０とキャッシュ５１０との不整合を無くすことができる。

本実施の形態によれば、検索時にその検索クエリに対応するキャッシュデータのみ有効性を判断するので、キャッシュデータの有効性を判断する処理コストを抑えることができ、効率的なキャッシュ管理が可能となる。

［第２の実施の形態］
第１の実施の形態では、キャッシュ管理テーブル５００のレコードが保持する検索結果ＩＤリストに記載された各データＩＤが示すデータに更新／削除の操作があったか否かをデータベース管理テーブル４００に照会することでキャッシュデータの有効性を判断した（図５のステップＳ２０６〜Ｓ２０９）。この際、データベース管理テーブル４００の保持するレコード数が多くなれば照会に要する時間も長くなり、検索結果の応答時間を増加させることになる。

そこで、第２の実施の形態では、ある期間内に実施されたデータベースへの変更内容を管理し、キャッシュ管理テーブル５００の検索結果ＩＤリストに記載された各データＩＤとデータベースへの変更内容を照合し、キャッシュデータ生成後にそのキャッシュデータに関連するデータに変更があったか否か判定し、キャッシュデータの有効性を確認する。

図７は、第２の実施の形態におけるキャッシュ管理装置を含む検索システムの構成を示すブロック図である。同図に示す検索システムは、図１に示したものに対してデータベース変更履歴６００を追加したものである。

データベース変更履歴６００は、データベース４１０への変更情報を管理する。図８に、データベース変更履歴６００の保持する情報の例を示す。同図に示すように、データベース変更履歴６００の各レコードは、データベース４１０への変更が発生した登録日時、データベース４１０に格納されたデータを一意に識別するデータＩＤ、およびデータベース４１０への変更内容を表す管理フラグで構成される。管理フラグは、データの追加／更新／削除をそれぞれ”０”，”１”，”２”で表す。データベース変更履歴６００は、キャッシュ管理テーブル５００の検索結果ＩＤリストとの照合処理を高速に実施できるようにメモリで保持するとよい。

次に、データベース変更時の処理について説明する。図９は、データベース変更時の処理の流れを示すフローチャートである。図９のステップＳ６０１〜Ｓ６０８のデータベース管理テーブル４００にレコードを追加／更新／削除する処理は図４のステップＳ１０１〜Ｓ１０８と同様であるのでここでの説明は省略する。以下、本実施の形態の拡張部分である、データベース変更履歴６００に関する処理について説明する。

データベース４１０にデータが追加されたときは、データベース管理テーブル４００にレコードが追加される（ステップＳ６０４，Ｓ６０５）。そして、データ登録処理部１００は、データベース変更履歴６００にレコードを追加し（ステップＳ６１１）、追加したレコードに履歴情報（登録日時、データＩＤ、管理フラグ”０”）を登録する（ステップＳ６１２）。なお、管理フラグの”０”は、データが追加されたことを表す。

データベース４１０のデータが更新されたときは、データベース管理テーブル４００のレコードを更新する（ステップＳ６０６）。そして、データ登録処理部１００は、更新したデータのＩＤを有する履歴情報をデータベース変更履歴６００から検索し（ステップＳ６２１）、その履歴情報の管理フラグを確認する（ステップＳ６２２）。管理フラグが”１”か”２”の場合、つまり、その履歴情報がデータの更新／削除を示す場合は、当該レコードの登録日時と管理フラグ（”１”を記載）を更新して処理を終了する（ステップＳ６２６）。管理フラグが”０”の場合、つまり、その履歴情報がデータの追加を示す場合は、全履歴情報を処理したか否か判定し（ステップＳ６２３）、まだ処理していない履歴情報がある場合はステップＳ６２１に戻り処理を繰り返す。上記の処理の結果、更新したデータのデータＩＤを有する履歴情報に管理フラグが”１”または”２”のものが無い場合は、データベース変更履歴６００にレコードを追加し（ステップＳ６２４）、追加したレコードに履歴情報（登録日時、データＩＤ、管理フラグ”１”）を登録する（ステップＳ６２５）。

データベース４１０のデータが削除されたときは、データベース管理テーブル４００のレコードを削除する（ステップＳ６０８）。そして、データ登録処理部１００は、削除したデータのＩＤを有する履歴情報をデータベース変更履歴６００から検索し（ステップＳ６３１）、その履歴情報の管理フラグを確認する（ステップＳ６３２）。管理フラグが”１”か”２”の場合、つまり、その履歴情報がデータの更新／削除を示す場合は、当該レコードの登録日時と管理フラグ（”２”を記載）を更新して処理を終了する（ステップＳ６３６）。管理フラグが”０”の場合、つまり、その履歴情報がデータの追加を示す場合は、全履歴情報を処理したか否か判定し（ステップＳ６２３）、まだ処理していない履歴情報がある場合はステップＳ６２１に戻り処理を繰り返す。上記の処理の結果、削除したデータのデータＩＤを有する履歴情報に管理フラグが”１”または”２”のものが無い場合は、データベース変更履歴６００にレコードを追加し（ステップＳ６３４）、追加したレコードに履歴情報（登録日時、データＩＤ、管理フラグ”２”）を登録する（ステップＳ６３５）。

このように、データベース変更履歴６００は、データベースへのデータの追加履歴とデータの変更／削除履歴を別々に管理する。また、データの変更／削除履歴に関しては、履歴情報を最新の情報に上書きすることで、データベースへの変更が頻繁に発生した場合でもデータベース変更履歴６００のサイズを抑えることができ、あるキャッシュデータに関連するデータの変更／削除の履歴を照合する処理を高速に実施することが可能となる。

次に、検索時の処理について説明する。図１０は、検索時の処理の流れを示すフローチャートである。同図に示す検索時の処理は、第１の実施の形態における検索時の処理（図５参照）と比べると、データベース管理テーブル４００を利用する代わりに、データベース変更履歴６００を利用する点で異なる。具体的には、図５のステップＳ２０６〜Ｓ２０９と、図１０のステップＳ７０６〜Ｓ７０８が相違する部分である。

検索処理部２００が検索クエリを受信すると、キャッシュ管理部３００は、受信した検索クエリとキャッシュ管理テーブル５００の検索クエリを照合し（ステップＳ７０１）、該当するレコードが有るか否か判定する（ステップＳ７０２）。該当するレコードが無い場合は、受信した検索クエリでデータベース４１０を検索し、検索結果をキャッシュデータとして保存し、検索結果を返却する（ステップＳ７２１〜Ｓ７２４）。

キャッシュ管理テーブル５００に該当するレコードが有る場合は、当該レコードからキャッシュデータの生成日時を取得し（ステップＳ７０３）、当該レコードが示すキャッシュデータが有効期限内か否か確認する（ステップＳ７０４）。キャッシュデータが有効期限切れの場合は、受信した検索クエリに対応するキャッシュデータを「無効」と判断し（ステップＳ７１２）、キャッシュ管理テーブル５００から当該レコードを削除するとともに、当該レコードが示すキャッシュデータをキャッシュ５１０から削除する（ステップＳ７１３）。そして、ステップＳ７２１へ進み受信した検索クエリでデータベースを検索する。

キャッシュデータが有効期限内の場合は、当該レコードから検索結果ＩＤリストを取得する（ステップＳ７０５）。

そして、検索結果ＩＤリストに記載されたデータＩＤをキーとして、各データＩＤを含む履歴情報をデータベース変更履歴６００から検索し（ステップＳ７０６）、履歴情報が存在するか否か判定する（ステップＳ７０７）。

データベース変更履歴６００に履歴情報が存在する場合、検索された履歴情報の中に管理フラグか”１”または”２”のものが存在するか否か判定する（ステップＳ７０８）。データベース変更履歴６００は、１つのデータＩＤに対して管理フラグが異なる履歴情報が複数記載される場合があるので、ステップＳ７０６では、複数の履歴情報が検索されることがある。このステップＳ７０８の処理では、それら複数の履歴情報に対して処理を実施する。

検索された履歴情報の中に管理フラグが”１”または”２”の履歴情報がある場合、つまり、ある期間内に該当するデータが更新または削除されていた場合、キャッシュが「無効」である場合の処理を行って（ステップＳ７１２〜Ｓ７１３）、ステップＳ７２１へ進み受信した検索クエリでデータベースを検索する。

一方、データベース変更履歴６００に履歴情報が存在しない場合、つまり、ある期間内に該当するデータの追加／変更／削除が無かった場合、及び、検索された履歴情報の中に管理フラグが”１”または”２”のものが存在しない場合、つまり、ある期間内に該当するデータは追加のみであった場合、検索結果ＩＤリストに記載されたデータＩＤすべてについて処理を行ったか否か判定し（ステップＳ７０９）、まだ処理していないデータＩＤが存在する場合はステップＳ７０６に戻り、検索結果ＩＤリストに記載された全てのデータＩＤに対して上記ステップＳ７０６〜Ｓ７０８の処理を繰り返す。

そして、検索結果ＩＤリストに記載された全データＩＤに対して処理した結果、データベース変更履歴６００に検索結果ＩＤリストに記載されたデータＩＤに関係する履歴情報が無いか、あるいは、関係する履歴情報はあるが管理フラグが”１”または”２”の履歴情報が無い場合、つまり、ある期間内に、受信した検索クエリに対応するキャッシュデータに関係する全データが更新も、削除もされていなかった場合、そのキャッシュデータを「有効」と判断し（ステップＳ７１０）、検索結果としてそのキャッシュデータを返却する（ステップＳ７１１）。

次に、キャッシュデータを削除する処理について説明する。図１１は、キャッシュデータを削除する処理の流れを示すフローチャートである。本処理は、運用に応じた設定に従って定期的（例えば、一日毎）に実施されるものとする。

まず、キャッシュ管理部３００は、データベース変更履歴６００の履歴情報毎にデータＩＤと管理フラグを取得し（ステップＳ８０１）、管理フラグの値を判定する（ステップＳ８０２）。

管理フラグが”０”の場合、キャッシュ管理部３００で管理する追加件数をカウントする（ステップＳ８０３）。

管理フラグが”１”または”２”の場合、キャッシュ管理部３００で管理するキャッシュ削除対象ＩＤリストに当該データＩＤを追加し（ステップＳ８０４）、データベース変更履歴６００から当該履歴情報を削除する（ステップＳ８０５）。

そして、データベース変更履歴６００の全ての履歴情報について処理したか否か判定し（ステップＳ８０６）、全ての履歴情報についてステップＳ８０１〜Ｓ８０５を繰り返す。

データベース変更履歴６００の全履歴情報の処理後、カウントされた追加件数をもとにデータベースとキャッシュとの不整合の程度を判定する（ステップＳ８０７）。不整合の程度を判定する方法としては、追加件数が所定の閾値を超えたか否かで判断する方法、総データ数に対する追加件数の比率が所定の閾値を超えたか否かで判断する方法が考えられる。他にも、データベース変更履歴６００から登録日時を取得し、登録日時が予め定める閾値よりも古いか否かで判断する方法もある。

不整合の程度が所定の閾値を超えている場合、データベース変更履歴６００の全履歴情報を削除し（ステップＳ８０８）、キャッシュ管理テーブル５００の全レコード、並びに、キャッシュ５１０の保持する全キャッシュデータを削除する（ステップＳ８０９）。なお、追加件数はキャッシュデータを削除する処理のときに随時カウントするので、キャッシュ管理部３００が永続的に管理する必要はない。

不整合の程度が所定の閾値を超えていない場合は、キャッシュ管理テーブル５００の各レコードの検索結果ＩＤリストを取得し（ステップＳ８１０）、ステップＳ８０４で作成したキャッシュ削除対象ＩＤリストと取得した検索結果ＩＤリストを照合する（ステップＳ８１１）。

照合の結果、一致するデータＩＤがある場合、つまり、ある期間内に該当するデータが更新、または、削除されていた場合、キャッシュ管理テーブル５００の当該レコードが示す検索クエリに対応するキャッシュデータを「無効」と判断し、キャッシュ管理テーブル５００の当該レコードを削除するとともに、該当するキャッシュデータをキャッシュ５１０から削除する（ステップＳ８１３）。

そして、キャッシュ管理テーブル５００の全レコードについて処理したか否か判定し（ステップＳ８１４）、キャッシュ管理テーブル５００の全てのレコードについて上記ステップＳ８１０〜Ｓ８１３の処理を繰り返す。

このように、データベース変更履歴６００では、データベース４１０へデータを追加した場合の履歴情報はその数が増加し、データベースとキャッシュとの不整合の程度が所定の閾値を超えるまで保持される。一方、データベース４１０のデータを変更／削除した場合の履歴情報は、上記キャッシュデータを削除する処理が実行されるときに削除されるので、データベース変更履歴６００のサイズの増大を抑えることができ、データベース変更履歴６００との照合処理を高速に実施することが可能となる。

次に、上記のキャッシュデータを削除する処理において、キャッシュデータの有効期限切れ処理を追加した例について説明する。図１２は、図１１に示したフローチャートのステップＳ８１０〜Ｓ８１４の不整合の程度が閾値内であったときの処理に、キャッシュデータの有効期限切れ処理を追加したフローチャートである。他の処理は、図１１と同様であるのでここでの説明は省略する。

不整合の程度が所定の閾値を超えていない場合は、キャッシュ管理テーブル５００の各レコードの検索結果ＩＤリストに加えて生成日時を取得し（ステップＳ８２０）、当該レコードが示すキャッシュデータが有効期限内であるか否か判定する（ステップＳ８２１）。キャッシュデータの有効期限は、運用に応じて設定されるものとし、例えば、生成日時が１ヶ月以内の場合は有効期限内であると判定する。

キャッシュデータが有効期限切れであった場合は、キャッシュ管理テーブル５００から当該レコードを削除するとともに、該当するキャッシュデータをキャッシュ５１０から削除する（ステップＳ８２４）。

キャッシュデータが有効期限内の場合は、キャッシュ削除対象ＩＤリストと取得した検索結果ＩＤリストを照合し（ステップＳ８２２）、一致するデータＩＤがあるか否か判定する（ステップＳ８２３）。一致するデータＩＤがある場合は、キャッシュ管理テーブル５００から当該レコードを削除するとともに、該当するキャッシュデータをキャッシュ５１０から削除する（ステップＳ８２４）。

そして、キャッシュ管理テーブル５００の全レコードについて処理したか否か判定し（ステップＳ８２５）、キャッシュ管理テーブル５００の全てのレコードについて上記ステップＳ８２０〜Ｓ８２４の処理を繰り返す。

もちろん、有効期限切れのキャッシュデータの処理として図６の処理を用いるものでもよい。

以上説明したように、本実施の形態によれば、データベース変更履歴６００に、データベース４１０への変更が発生したデータのデータＩＤ、変更内容を表す管理フラグを格納しておき、検索時にキャッシュデータの有効性を判断するときに、検索クエリに対応するキャッシュデータの検索結果ＩＤリストに記載されたデータＩＤが示すデータについて、データベース変更履歴６００に変更／削除された履歴情報が存在する場合は、そのキャッシュデータは無効であると判断することにより、データベース管理テーブル４００を参照する場合と比べて、処理コスト、処理時間を抑えることができる。

［第３の実施の形態］
第１の実施の形態を用いることで、データの更新、削除に伴うデータベースとキャッシュとの不整合を無くすことができる。しかしながら、データの追加に伴うデータベースとキャッシュとの不整合は、キャッシュデータの有効期限切れ、または、検索時のキャッシュ無効判断によるキャッシュデータの削除が実施され、その後、新たにキャッシュデータが生成されるまで解消されない。また、追加されたデータが関連するキャッシュデータを探す場合、検索クエリとデータを内容レベル（例えば、検索クエリで指定されたキーワードとデータ内容に含まれるテキスト情報）で照合する必要が生じ、全キャッシュデータに対してこのような処理を行うことは処理量が非常に大きくなり、非効率である。

そこで、第３の実施の形態では、データベース４１０へのデータ追加時に追加件数の累積をカウントし、その追加件数をもとにデータベースとキャッシュとの不整合の程度を判断し、不整合の程度が所定の閾値を超えた場合に、キャッシュ５１０が保持する全キャッシュデータを削除する。

図１３は、データベース４１０にデータを追加したときの処理の流れを示すフローチャートであり、図４のステップＳ１０５以降に実施される。データの更新、削除の処理については図４に示す処理と同様である。

データ登録処理部１００は、データベース４１０にデータを登録した後、データベース管理テーブル４００にレコードを追加し、そのレコードにデータベース４１０に追加した内容を登録する（図４のステップＳ１０４，Ｓ１０５）。

その後、本実施の形態では、データ登録処理部１００で管理する追加件数をカウントし（ステップＳ４０１）、不整合の程度を判定する（ステップＳ４０２）。不整合の程度を判定する方法としては、追加件数が所定の閾値を超えたか否かで判断する方法、あるいは、総データ数に対する追加件数の比率が所定の閾値を超えたか否かで判定する方法が考えられる。

不整合の程度が所定の閾値を超えている場合、追加件数をクリアし（ステップＳ４０３）、キャッシュ管理テーブル５００の全レコード、並びに、キャッシュ５１０が保持する全キャッシュデータを削除する（ステップＳ４０４）。

また、データの追加によるデータベースとキャッシュの不整合を減らす方法として、データベースへの登録要求として「追加（キャッシュクリア）」を新たに設け、データ登録処理部１００がその登録要求を受信した場合、データベースとキャッシュとの不整合の程度を判断することなく、キャッシュ管理テーブル５００の全レコード、並びに、キャッシュ５１０が保持する全キャッシュデータを削除する方法も考えられる。

以上説明したように、本実施の形態によれば、データベース４１０へのデータの追加時に追加件数の累積をカウントし、その追加件数をもとにデータベースとキャッシュとの不整合の程度を判断し、不整合の程度が所定の閾値を超えた場合に全キャッシュデータを削除することにより、データの追加に伴うデータベースとキャッシュとの不整合についてもある程度軽減することができる。

なお、本実施の形態におけるキャッシュデータの削除は、第２の実施の形態にも適用でき、その場合、キャッシュデータを削除するときに全履歴情報を削除する。

［第４の実施の形態］
第１の実施の形態では、検索時にキャッシュの無効／有効を判定することで、データベースとキャッシュデータの不整合を軽減している。その際、受信した検索クエリに対するキュッシュデータのみの有効性を判断することで、キャッシュチェックに要する処理コストの軽減を図っている。しかしながら、同じ検索クエリが頻繁に来る場合にもその都度キャッシュデータの確認を実施するため、処理が冗長である。

そこで、第４の実施の形態では、キャッシュデータの生成から一定期間内（例えば１時間）にそのキャッシュデータに対応する検索クエリを受信した場合、保持するキャッシュデータは十分に新鮮で有効性の確認処理は不要であるとみなし、当該キャッシュデータを検索結果として返却する。

図１４は、キャッシュデータの有効性確認に無効期間を設けた場合の検索時の処理の流れを示すフローチャートである。図１４に示す処理は、図５，１０に示す処理にキャッシュデータの生成日時から一定期間内であるか否か判断する処理を加えたものである。

検索処理部２００が検索クエリを受信すると、キャッシュ管理部３００は、受信した検索クエリとキャッシュ管理テーブル５００の検索クエリを照合し（ステップＳ９０１）、該当するレコードが有るか否か判定する（ステップＳ９０２）。該当するレコードが無い場合は、受信した検索クエリでデータベース４１０を検索し、検索結果をキャッシュデータとして保存し、検索結果を返却する（ステップＳ９０８〜Ｓ９１１）。

該当するレコードが有る場合は、そのレコードからキャッシュデータの生成日時を取得する（ステップＳ９０３）。そして、生成日時と現在時刻を比較し（ステップＳ９０４）、現在時刻が生成日時から一定期間内であるか否か判定する（ステップＳ９０５）。

現在時刻が生成日時から一定期間内である場合は、キャッシュデータは十分に新鮮で有効性の確認処理は不要と判断し、ステップＳ９０６のキャッシュデータの有効性確認の処理を実施せず、検索結果として当該キャッシュデータを返却する（ステップＳ９０７）。

現在時刻が生成日時から一定期間以上離れている場合は、キャッシュデータの有効性を判定する（ステップＳ９０６）。キャッシュデータが有効の場合は、検索結果としてキャッシュデータを返却する（ステップＳ９０７）。キャッシュデータが無効の場合は、ステップＳ９０９へ進み受信した検索クエリでデータベースを検索する（ステップＳ９０８〜Ｓ９１１）。ステップＳ９０６のキャッシュデータの有効性の判定は、図５のステップＳ２０４〜Ｓ２１４、あるいは図１０のステップＳ７０４〜Ｓ７１３の処理を用いる。

以上説明したように、本実施の形態によれば、検索時にキャッシュ管理テーブル５００からキャッシュデータの生成日時を取得し、現在時刻が生成日時から一定期間内である場合は、そのキャッシュデータは十分に新鮮で有効性の確認処理は不要であると判断することにより、同じ検索クエリを頻繁に受信する場合に、その検索クエリに対応するキャッシュデータの有効性判断をその都度行わなくて済み、キャッシュ管理にかかる総体的な処理コストを軽減することができる。

１００…データ登録処理部
２００…検索処理部
３００…キャッシュ管理部
４００…データベース管理テーブル
４１０…データベース
５００…キャッシュ管理テーブル
５１０…キャッシュ
６００…データベース変更履歴

Claims (4)

1. データベースに格納されたデータを検索クエリを用いて検索した検索結果をキャッシュデータとしてキャッシュに格納するキャッシュ管理装置であって、
   前記データベースに格納されたデータを一意に識別するデータＩＤ、当該データに対する操作内容を示す管理フラグを関連付けた変更履歴を蓄積する変更履歴蓄積手段と、
   前記キャッシュに格納されたキャッシュデータを一意に識別するキャッシュＩＤ、当該キャッシュデータに対応する検索クエリ、当該キャッシュデータに含まれるデータのデータＩＤを記載した検索結果リスト、当該キャッシュデータの生成日時を関連付けたキャッシュレコードを蓄積するキャッシュ管理テーブルと、
   検索クエリを受信したときに、当該検索クエリに一致する検索クエリを持つ前記キャッシュレコードを前記キャッシュ管理テーブルから検索し、検索したキャッシュレコードから前記検索結果リストと前記生成日時を取得する取得手段と、
   前記取得手段が取得した前記検索結果リストに記載されたデータＩＤと一致するデータＩＤを持つ前記変更履歴を前記変更履歴蓄積手段から検索し、該当する変更履歴が検索されない場合及び検索された前記変更履歴すべての管理フラグがデータの追加を示している場合は、前記取得手段が検索した前記キャッシュレコードに対応する前記キャッシュデータは有効であると判定し、それ以外の場合は当該キャッシュデータは無効であると判定する判定手段と、
   前記判定手段が前記キャッシュデータは有効であると判定した場合は、当該キャッシュデータを検索結果として返却し、受信した検索クエリに一致する検索クエリを持つ前記キャッシュレコードが検索できない場合、及び前記判定手段が前記キャッシュデータは無効であると判定した場合は、受信した検索クエリを用いて前記データベースを検索して検索結果を返却し、当該検索結果を前記キャッシュにキャッシュデータとして格納するとともに、前記キャッシュ管理テーブルに当該キャッシュデータのキャッシュＩＤ、検索に用いた検索クエリ、当該キャッシュデータに含まれるデータのデータＩＤを記載した検索結果リスト、当該キャッシュデータの生成日時を関連付けたキャッシュレコードを追加する検索手段と、
   前記変更履歴蓄積手段から各変更履歴の管理フラグを取得し、当該管理フラグがデータの追加を示している場合はデータが追加された件数をカウントし、それ以外の場合はその変更履歴のデータＩＤを削除対象リストに追加し、前記変更履歴蓄積手段から全変更履歴を削除する変更履歴更新手段と、
   前記件数に基づいて算出した不整合の程度が所定の閾値を超えた場合、前記キャッシュ管理テーブルの全キャッシュレコード及び前記キャッシュの格納された全キャッシュデータを削除し、前記件数に基づいて算出した不整合の程度が所定の閾値を超えない場合、前記削除対象リストに記載されているデータＩＤを有する前記キャッシュレコードを前記キャッシュ管理テーブルから削除するとともに、当該キャッシュレコードに対応するキャッシュデータを前記キャッシュから削除するキャッシュ削除手段と、
   を有することを特徴とするキャッシュ管理装置。
2. 前記データベースにデータが追加されたときは、前記変更履歴蓄積手段に変更履歴を追加して当該変更履歴に前記データＩＤ、データの追加を示す管理フラグを登録し、
   前記データベースのデータが変更あるいは削除されたときは、変更あるいは削除されたデータのデータＩＤを有する変更履歴を前記変更履歴蓄積手段から検索し、該当する変更履歴がない場合及び管理フラグがデータの追加を示す変更履歴のみが検索された場合は、前記変更履歴蓄積手段に変更履歴を追加して当該変更履歴に前記データＩＤ、データの変更あるいは削除を示す管理フラグを登録し、管理フラグがデータの変更あるいは削除を示す変更履歴が検索された場合は、当該変更履歴の管理フラグを更新する変更履歴管理手段を有することを特徴とする請求項１記載のキャッシュ管理装置。
3. 請求項１又は２に記載のキャッシュ管理装置を構成する各手段としてコンピュータを機能させるためのキャッシュ管理プログラム。
4. 請求項３記載のキャッシュ管理プログラムを記録した記録媒体。

Images