(57)【特許請求の範囲】
【請求項１】
データの作成、更新、削除が行われるたびに同一の識別情報が付与された当該データのレコードを追加するデータベースにおいて、
前記データベースから読み出されたデータをキャッシュする保持部と、
前記保持部にキャッシュされるデータを管理する管理部とを備え、
前記保持部は、
データの前記識別情報を登録するテーブルと、
前記テーブルに登録された前記識別情報に個別に対応付けられ、前記データベースにおける当該識別情報を持つレコードを示すエントリを格納するマップとを備え、
前記管理部は、
前記識別情報およびレコードを指定する情報を含むクエリを受け付けて前記保持部を検索し、
該当するデータがキャッシュされていれば当該データを読み出し、
該当するデータがキャッシュされていなければ、当該データを前記データベースから取得し、前記保持部の前記マップにおける当該クエリにより指定された識別情報およびレコードに対応する前記エントリに関連付けて当該データをキャッシュさせる、システム。
【請求項２】
前記マップは、前記データベースに格納されており、前記テーブルに登録されていない所定の識別情報を持つデータに対して初めてアクセスが行われた際に生成される、請求項１に記載のシステム。
【請求項３】
前記マップの前記エントリには、前記レコードが作成された際に当該レコードに付与される時間情報が記録され、
前記管理部は、前記レコードを指定する情報として前記時間情報が一意に定まる条件を記載したクエリを受け付け、当該条件にしたがって特定される時間情報を持つエントリを、当該クエリにより指定されたレコードを示すエントリとする、請求項１に記載のシステム。
【請求項４】
前記時間情報は、前記レコードが作成される原因となった前記データに対する操作が行われた時刻を表すタイムスタンプである、請求項３に記載のシステム。
【請求項５】
クエリにより指定された前記識別情報を持つデータが前記データベースに存在しない場合、その旨を示す情報が、前記テーブルに登録された当該識別情報に対応付けられて前記保持部に保持される、請求項１に記載のシステム。
【請求項６】
クエリの実行により前記識別情報が段階的に指定される場合、前記テーブルと前記マップの間に補助エントリが設けられ、当該クエリに記述された最上位の識別情報が当該テーブルに登録され、当該クエリの実行により得られる下位の識別情報が当該テーブルの識別情報に対応付けられて当該補助エントリに登録され、当該補助エントリに登録された最下位の識別情報に当該マップが対応付けられる、請求項１に記載のシステム。
【請求項７】
前記データベースにおいて所定の識別情報を持つデータのレコードが追加された場合に、前記保持部において、前記テーブルに登録された当該識別情報および当該識別情報に対応付けられた前記マップが削除され、当該マップのエントリに関連付けられたデータがキャッシュされているときはキャッシュされている当該データも削除される、請求項１に記載のシステム。
【請求項８】
前記データベースにおいて所定の識別情報を持つデータのレコードが追加された場合に、当該識別情報に対応付けられた前記マップに、当該レコードに関連付けられたエントリが追加される、請求項１に記載のシステム。
【請求項９】
データの作成、更新、削除が行われるたびに同一の識別情報が付与された当該データのレコードを追加するデータベースのキャッシュ方法であって、
前記識別情報およびレコードを指定する情報を含むクエリを受け付け、データの前記識別情報を登録するテーブルに対して、当該クエリにより指定された識別情報を検索するステップと、
前記テーブルに前記クエリにより指定された識別情報が存在しない場合、当該識別情報を当該テーブルに登録し、当該識別情報に対応づけて前記データベースにおける当該識別情報を持つレコードを示すエントリを格納するマップを生成するステップと、
前記テーブルに前記クエリにより指定された識別情報が存在する場合、当該識別情報に対応付けられた前記マップの前記エントリに関連付けられたデータがキャッシュされているならば当該データを読み出し、当該エントリに関連付けられたデータがキャッシュされていないならば前記データベースから読み出された当該データを当該エントリに関連付けてキャッシュさせるステップと
を含む、方法。
【請求項１０】
データの作成、更新、削除が行われるたびに同一の識別情報が付与された当該データのレコードを追加するデータベースシステムを制御するコンピュータに、
前記識別情報およびレコードを指定する情報を含むクエリを受け付け、データの前記識別情報を登録するテーブルに対して、当該クエリにより指定された識別情報を検索する処理と、
前記テーブルに前記クエリにより指定された識別情報が存在しない場合、当該識別情報を当該テーブルに登録し、当該識別情報に対応づけてデータベースにおける当該識別情報を持つレコードを示すエントリを格納するマップを生成する処理と、
前記テーブルに前記クエリにより指定された識別情報が存在する場合、当該識別情報に対応付けられた前記マップの前記エントリに関連付けられたデータがキャッシュされているならば当該データを読み出し、当該エントリに関連付けられたデータがキャッシュされていないならば前記データベースから読み出された当該データを当該エントリに関連付けてキャッシュさせる処理と
を実行させる、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースのキャッシュシステムに関し、特に、インサート・オンリー方式のデータベースに適用できるキャッシュシステムに関する。
【背景技術】
【０００２】
データベースへのアクセス方式において、インサート・オンリー（insert only）と呼ばれる方式がある。この方式は、データベース・テーブルへの更新操作を、既存レコードに対して更新（update）や削除（delete）を実際に行うのではなく、常に、新規レコードの挿入（insert）によって行うものである。この方式では、データベース・テーブルの各レコードに、データの識別情報であるキー識別子（key identifier）と共に、ＣＲＵＤ値（CRUD value）と呼ばれる操作内容を示す情報と、操作が行われた時刻を示す情報（タイムスタンプ）とが格納される。そして、変更操作の度に新たなレコードが挿入されるため、同一のキー識別子を持ちタイムスタンプの値（以下、タイムスタンプ情報と呼ぶ）が異なる複数のレコードが変更履歴の数だけ存在することとなる。ここで、ＣＲＵＤ値の「ＣＲＵＤ」は、「作成（CReate）」、「更新（Update）」、「削除（Delete）」の頭文字である。
【０００３】
このインサート・オンリー方式は、過去の変更履歴を全て保存するという監査要求事項（auditing requirement）を満たす必要以外にも、ロック・コンテンション（lock contention）の確率を減らすという設計上の要求から採用されることも多い。例えば、金融に関わるアプリケーションを例に考えると、オンラインによる処理は、一般に、現在の口座残高その他の情報を表示したり振替処理をしたりするなど、最新のデータを使って処理が行われる。これに対して、バッチ処理では、過去のある時点における残高に対して利率計算を行ったり、月次報告書を作成したりする処理が行われる。すなわち、オンライン処理とバッチ処理における起点となるタイムスタンプ情報が各々異なるため、これらの処理を同時に実行し、同一のキー識別子を持つデータにアクセスする場合でも、別々のレコードにアクセスすることになる。そのため、ロック・コンテンションが起きにくくなる。
【０００４】
ところで、データベースに対するアクセス等の処理を高速化するための一般的な手段として、キャッシュメモリを用いる方法がある（例えば、特許文献１参照）。すなわち、データベースからフェッチしたデータをサーバにおいてキャッシュしておく。そして、繰り返し発行されるクエリに対しては、パラメータに基づきハッシュ・テーブルを引くなどして、対象とするデータがキャッシュ内で利用可能かどうかチェックする。
【０００５】
【特許文献１】特表２００６−５１１８７６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
インサート・オンリー方式では、次のような問題がある。
第１に、データベースへのアクセスにおいて、常にタイムスタンプ情報を指定したり、ＣＲＵＤ値をチェックしたりしなければならない。そのため、副照会を使うなどの操作が必要となり、クエリ処理が複雑で重くなる。
第２に、データの一部分のみを変更する場合においても、データベース・テーブルにおける対象となるカラム（column）だけを選択的にフェッチして書き出すことはできない。そのため、一旦は全てのカラム内容をフェッチする必要がある。
さらに、単にデータベース中に今あるデータの中から最新のものを１レコードフェッチしたいという場合でも、タイムスタンプ情報を指定する必要があるため、呼び出し側で現在のタイムスタンプ情報（currentTimeStamp）を生成して渡してやらなければならない。
【０００７】
アプリケーションの内容によっては、これらのオーバーヘッドがシステム全体の性能低下を引き起こす原因となる。特に、バッチ処理などのようにビジネスロジックが繰り返し実行される場合には、このオーバーヘッドは無視できないものとなる。また、更新がほとんど行われないようなテーブルでも、トランザクションの度にコストのかかるデータベースアクセスを繰り返すのは、アプリケーションの性能面で問題となる。
【０００８】
このような問題に対し、通常のデータベースアクセスであれば、キャッシュメモリを用いて高速化を図ることが考えられる。上記のように、インサート・オンリー方式のアプリケーションでは、キー識別子とタイムスタンプ情報の組み合わせでレコードが特定されるので、この組み合わせでクエリがかけられ、またこの組み合わせを検索キーとしてハッシュ・テーブルにデータがキャッシュされることとなる。そして、タイムスタンプ情報はクエリ作成のための読み出しごとに毎回異なるデータが渡される。そのため、単にハッシュ・テーブルに基づいて行われる従来の検索方法ではキャッシュはヒットせず、冗長な読み出しに対して有効な手段とならなかった。例えば、あるキー識別子の最新のレコードを読み出そうとする場合、そのキー識別子を持つデータがキャッシュされている場合でも、そのキャッシュデータがそのキー識別子を持つレコードの中で最新のレコードか否かを判断することはできない。
【０００９】
本発明は、これらの課題を解決し、インサート・オンリー方式のアプリケーションにおいても有効なキャッシュシステムを実現することを目的とする。
【課題を解決するための手段】
【００１０】
上記の目的を達成するため、本発明は、次のようなシステムとして構成される。このシステムは、データの作成、更新、削除が行われるたびに同一の識別情報が付与されたデータのレコードを追加するデータベースにおいて、このデータベースから読み出されたデータをキャッシュする保持部と、この保持部にキャッシュされるデータを管理する管理部とを備える。保持部は、データの識別情報を登録するテーブルと、このテーブルに登録された識別情報に個別に対応付けられ、データベースにおけるこの識別情報を持つレコードを示すエントリを格納するマップとを備える。管理部は、識別情報およびレコードを指定する情報を含むクエリを受け付けて保持部を検索し、該当するデータがキャッシュされていればそのデータを読み出し、該当するデータがキャッシュされていなければ、そのデータをデータベースから取得し、保持部のマップにおけるクエリにより指定された識別情報およびレコードに対応するエントリに関連付けてこのデータをキャッシュさせる。
【００１１】
ここで、マップは、データベースに格納されており、テーブルに登録されていない所定の識別情報を持つデータに対して初めてアクセスが行われた際に生成される。
マップのエントリには、レコードが作成された際にレコードに付与される時間情報が記録される。そして、管理部は、レコードを指定する情報としてこの時間情報が一意に定まる条件を記載したクエリを受け付け、この条件にしたがって特定される時間情報を持つエントリを、このクエリにより指定されたレコードを示すエントリとする。
より詳細には、この時間情報は、レコードが作成される原因となったデータに対する操作が行われた時刻を表すタイムスタンプである。
クエリにより指定された識別情報を持つデータがデータベースに存在しない場合、その旨を示す情報が、テーブルに登録された識別情報に対応付けられて保持部に保持される。
クエリの実行により識別情報が段階的に指定される場合、テーブルとマップの間に補助エントリが設けられ、クエリに記述された最上位の識別情報がテーブルに登録され、クエリの実行により得られる下位の識別情報がテーブルの識別情報に対応付けられて補助エントリに登録され、補助エントリに登録された最下位の識別情報にマップが対応付けられる。
データベースにおいて所定の識別情報を持つデータのレコードが追加された場合に、保持部において、テーブルに登録された識別情報および識別情報に対応付けられたマップが削除され、マップのエントリに関連付けられたデータがキャッシュされているときはキャッシュされているデータも削除される。
あるいは、データベースにおいて所定の識別情報を持つデータのレコードが追加された場合に、識別情報に対応付けられたマップに、このレコードに関連付けられたエントリが追加される。
【００１２】
また、本発明は、次のようなデータ構造としても実現される。このデータ構造は、データの作成、更新、削除が行われるたびに同一の識別情報が付与されたデータのレコードを追加するデータベースにおける、識別情報を登録するテーブルと、テーブルに登録された識別情報に個別に対応付けられ、データベースにおける識別情報を持つレコードを示すエントリを格納するマップとを備え、所定のクエリに基づきデータベースから取得されたデータが、マップにおけるクエリにより指定された識別情報およびレコードに対応するエントリに関連付けられてキャッシュされる。
このマップには、データベースのレコードが作成された際にレコードに付与される時間情報に基づき、エントリが時系列に並べられて格納される。
また、テーブルに登録された識別情報を持つデータがデータベースに存在しない場合、マップに代えて、データが存在しない旨を示す情報が保持される。
【００１３】
また、本発明は、次のような方法としても実現される。この方法は、データの作成、更新、削除が行われるたびに同一の識別情報が付与されたデータのレコードを追加するデータベースのキャッシュ方法であって、識別情報およびレコードを指定する情報を含むクエリを受け付け、データの識別情報を登録するテーブルに対して、クエリにより指定された識別情報を検索するステップと、テーブルにクエリにより指定された識別情報が存在しない場合、この識別情報をテーブルに登録し、この識別情報に対応づけてデータベースにおけるこの識別情報を持つレコードを示すエントリを格納するマップを生成するステップと、テーブルにクエリにより指定された識別情報が存在する場合、この識別情報に対応付けられたマップのエントリに関連付けられたデータがキャッシュされているならばそのデータを読み出し、エントリに関連付けられたデータがキャッシュされていないならばデータベースから読み出されたデータをこのエントリに関連付けてキャッシュさせるステップとを含む。
【００１４】
さらに本発明は、コンピュータを制御して上記のシステムにおける各機能を実現するプログラムや、上記の方法における各ステップに対応する処理をコンピュータに実行させるプログラムとして実現することもできる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。
【発明の効果】
【００１５】
以上のように構成された本発明によれば、データベースにおけるインサート・オンリー方式のアプリケーションにおいても有効なキャッシュシステムを実現できる。
【発明を実施するための最良の形態】
【００１６】
以下、添付図面を参照して、本発明の実施形態について詳細に説明する。
＜システム構成＞
図１は、本実施形態が適用されるデータベースシステムの機能構成例を示す図である。
図１に示すように、本実施形態のデータベースシステム１００は、データベース１１０と、アクセス部１２０とを備え、かつキャッシュシステムを実現するためのデータ保持部１３０と、キャッシュ管理部１４０と、マップ作成部１５０とを備える。また別の構成例として、キャッシュシステムの各構成部１３０、１４０、１５０は、データベースシステムの一部とせず、データベースをアクセスするアプリケーションシステムの一部として実現しても良い。さらに、アプリケーションシステムとデータベースシステムの中間にある独立したレイヤーとして実現することもできる。これらの場合、アクセス部１２０は、アプリケーションシステムにおいてデータをアクセスする部分を指す。
【００１７】
図２は、データベースシステム１００を構成するコンピュータのハードウェア構成例を示す図である。
図２に示すコンピュータ１０は、演算手段であるＣＰＵ（Central Processing Unit）１０ａと、記憶手段であるメイン・メモリ１０ｃおよび磁気ディスク装置（ＨＤＤ：Hard Disk Drive）１０ｇを備える。また、ネットワークを介して外部装置に接続するためのネットワーク・インタフェース・カード１０ｆと、表示出力を行うためのビデオ・カード１０ｄおよび表示装置１０ｊと、音声出力を行うための音声機構１０ｈとを備える。さらに、キーボードやマウス等の入力デバイス１０ｉを備える。
【００１８】
図２に示すように、メイン・メモリ１０ｃおよびビデオ・カード１０ｄは、システム・コントローラ１０ｂを介してＣＰＵ１０ａに接続されている。また、ネットワーク・インタフェース・カード１０ｆ、磁気ディスク装置１０ｇ、音声機構１０ｈおよび入力デバイス１０ｉは、Ｉ／Ｏコントローラ１０ｅを介してシステム・コントローラ１０ｂと接続されている。各構成要素は、システム・バスや入出力バス等の各種のバスによって接続される。例えば、ＣＰＵ１０ａとメイン・メモリ１０ｃの間は、システム・バスやメモリ・バスにより接続される。また、ＣＰＵ１０ａと磁気ディスク装置１０ｇ、ネットワーク・インタフェース・カード１０ｆ、ビデオ・カード１０ｄ、音声機構１０ｈ、入力デバイス１０ｉ等との間は、ＰＣＩ（Peripheral Components Interconnect）、ＰＣＩ  Ｅｘｐｒｅｓｓ、シリアルＡＴＡ（AT Attachment）、ＵＳＢ（Universal Serial Bus）、ＡＧＰ（Accelerated Graphics Port）等の入出力バスにより接続される。
【００１９】
なお、図２は、本実施形態が適用されるのに好適なコンピュータのハードウェア構成を例示するに過ぎず、実際の各サーバが図示の構成に限定されないことは言うまでもない。例えば、ビデオ・カード１０ｄを設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０ａにてイメージ・データを処理する構成としても良い。また、音声機構１０ｈを独立した構成とせず、システム・コントローラ１０ｂやＩ／Ｏコントローラ１０ｅを構成するチップセットの機能として備えるようにしても良い。また、補助記憶装置として磁気ディスク装置１０ｇの他に、各種の光学ディスクやフレキシブル・ディスクをメディアとするドライブを設けても良い。表示装置１０ｊとしては、主として液晶ディスプレイが用いられるが、その他、ＣＲＴディスプレイやプラズマ・ディスプレイ等、任意の方式のディスプレイを用いて良い。
【００２０】
図１に示したデータベースシステム１００において、アクセス部１２０、キャッシュ管理部１４０、マップ作成部１５０の各機能は、例えば図２に示したコンピュータにおいて、メイン・メモリ１０ｃに読み込まれたプログラムをＣＰＵ１０ａが実行することにより実現される。データベース１１０は、例えば磁気ディスク装置１０ｇにより実現され、キャッシュシステムのデータ保持部１３０は、例えばメイン・メモリ１０ｃにキャッシュ領域を設けて実現される。
【００２１】
図１において、データベース１１０は、検索対象のデータを格納する。本実施形態において、データベース１１０に対するアクセスは、インサート・オンリー方式で行われる。この方式では、データの更新操作の度にデータベース１１０に新規レコードが追加作成される。そして、作成されたレコードには、データを識別するためのキー識別子と、レコードが作成される原因となった操作が行われた時刻を示すタイムスタンプ情報が記録される。したがって、データベース１１０には、同一のキー識別子であってもタイムスタンプ情報の異なる複数のレコードが変更履歴の数だけ存在する。すなわち、タイムスタンプ情報は、同一のキー識別子を持つレコードの識別情報として用いることができる。また、各レコードには、操作内容を表すＣＲＵＤ値が記録される。なお、データの読み出しでは、データベース１１０の状態は変更されないので、新たなレコードが生成（インサート）されることはない。したがって、ＣＲＵＤ値の欄（カラム）には「作成」、「更新」、「削除」のいずれかが記録されることとなる。
【００２２】
図３は、データベース１１０の構成例を示す図である。
図３に示すデータベース１１０には、キー識別子「１００３２７５２０４６９２５」に関して、タイムスタンプ情報の異なる３つのレコードが存在している。これらの各レコードのＣＲＵＤ値は、タイムスタンプ情報の古いものから順に「Ｃ」、「Ｕ」、「Ｄ」であり、「Ｃ」は作成（Create）、「Ｕ」は更新（Update）、「Ｄ」は削除（Delete）を表している。すなわち、図３の例では、キー識別子「１００３２７５２０４６９２５」のデータが、作成され、１回更新された後に削除されたことが示されている。
【００２３】
アクセス部１２０は、ＳＱＬ等で記述されたクエリを受け付けてデータベース１１０にアクセスし、レコードの作成、読み出し、更新、削除等の処理を実行する。また、アクセス部１２０は、データベース１１０へのアクセスを行う際に、キャッシュ管理部１４０にキャッシュの操作を指示する。
【００２４】
データ保持部１３０は、キャッシュデータを保持する。本実施形態では、キー識別子に対するハッシュ・テーブルと、キー識別子ごとの全変更履歴を表現するマップと呼ぶデータ構造とを組み合わせたデータ構造により、キャッシュデータが保持される。このデータ構造の詳細については後述する。
【００２５】
キャッシュ管理部１４０は、データ保持部１３０に保持されるキャッシュデータを管理する。そして、アクセス部１２０からの指示に応じて、データのキャッシュに関する操作を行う。具体的には、アクセス部１２０による読み出し要求のクエリに該当するレコードを検索し、検索結果に応じて応答を返す。該当のレコードがキャッシュされていない場合は、読み出されたレコードをキャッシュする。また、クエリに該当するキー識別子がデータ保持部１３０のハッシュ・テーブルに存在しない場合は、ハッシュ・テーブルにキー識別子を登録し、そのキー識別子に関するマップをマップ作成部１５０に作成させる。
【００２６】
マップ作成部１５０は、キャッシュ管理部１４０の制御により、指示されたキー識別子のレコードのマップを作成する。マップは、キー識別子ごとにレコードの変更履歴を時系列に記録したものである。このマップを含むキャッシュのデータ構造について、以下に説明する。
【００２７】
＜キャッシュのデータ構造＞
図４は、本実施形態におけるキャッシュのデータ構造の例を示す図である。図５は、図４におけるマップエントリのデータ構造の例を示す図である。
図４に示すように、本実施形態のキャッシュはハッシュ・テーブル４１０とマップ４２０とを組み合わせたデータ構造を持つ。図４において、ハッシュ・テーブル４１０には、少なくとも１回以上読み出しが行われたキー識別子とそのキー識別子に対応付けられたマップ４２０が登録される。図４のハッシュ・テーブル４１０において、灰色で示された箇所を、キー識別子が登録された箇所とする。
【００２８】
ハッシュ・テーブル４１０にキー識別子が登録されると、このキー識別子のマップ４２０が作成される。このマップ４２０には、タイムスタンプ情報（ｔｉｍｅＳｔａｍｐ）、ＣＲＵＤ値（ｃｒｕｄＶａｌ）、データオブジェクト（ｅｎｔｒｙＯｂｊ）が記録されたマップエントリがタイムスタンプ情報の降順（すなわち時系列）で並べられている。データオブジェクトは、マップエントリに対応するキャッシュされたレコードの内容へのポインタであり、初期的には「ｎｕｌｌ」となる。例えば、図４に示すマップエントリ４２１には、タイムスタンプ情報「ＴＳ１」、ＣＲＵＤ値「Ｕ（更新）」、データオブジェクト「ｎｕｌｌ」が記録されている。
【００２９】
マップ４２０は、データベース１１０に格納されているデータであって、ハッシュ・テーブル４１０に登録されていない所定のキー識別子を持つデータが、アクセス部１２０により初めてアクセスされた際に作成される。この際、各マップエントリのデータオブジェクトの項目には「ｎｕｌｌ」が記録される。これ以降、このキー識別子を持ち、所定のタイムスタンプ情報を持つレコードが読み出されると、キー識別子およびタイムスタンプ情報が対応するマップエントリのデータオブジェクトの項目に、データベース１１０から読み出されてデータ保持部１３０にキャッシュされたレコードの内容へのポインタが記録される。図４に示す例では、マップエントリ４２２において、データオブジェクトに、対応するレコードの内容が記録されている。
【００３０】
クエリにて指定されたキー識別子を持つデータが存在しない場合、キャッシュ管理部１４０は、そのキー識別子のマップを作成することができない。この場合、キャッシュ管理部１４０は、そのキー識別子をハッシュ・テーブル４１０に登録し、マップ４２０の代わりに、そのキー識別子を持つデータが存在しないことを示すデータを対応付けてデータ保持部１３０に保持させる。図４に示す例では、データ４２３が、該当するキー識別子を持つデータが存在しないことを示している。
【００３１】
上記のマップの作成は、キャッシュ管理部１４０が、対象とするキー識別子を持つ各レコードからタイムスタンプ情報とＣＲＵＤ値だけをフェッチする専用のクエリを発行することで実行される。マップ作成用のクエリの具体的な内容は、元のデータフェッチの内容（クエリ）によって異なる。例えば、「主照会でバインドされたキー識別子を持つ（複数の）レコードに対して、指定されたタイムスタンプ情報以前で最新の１レコードを副照会で選択し、そのＣＲＵＤ値が「Ｄ（削除）」でないものを返す」というようなデータフェッチが行われる場合を考える。このようなアクセスが行われる際のクエリ（ＳＱＬ文）は、例えば図６に示すようなものになる。そして、これに対応するマップを作成するための専用のクエリとクエリ結果からデータ構造を生成するコードは、図７のようになる。
【００３２】
ところで、ハッシュ・テーブル４１０にキー識別子およびマップ４２０が存在するデータに対して、読み出し以外のアクセスが行われた場合は、データベース１１０における新たなレコードの生成（インサート）を伴うため、データベース１１０に格納されているレコードとマップ４２０の内容とが整合しなくなる。この場合、キャッシュ管理部１４０は、そのキー識別子についてのキャッシュを一旦解放する。すなわち、ハッシュ・テーブル４１０のキー識別子およびキー識別子に対応付けられたマップ４２０を削除し、さらにマップ４２０のマップエントリに対応付けられて保持されたレコードも削除する。そして、同一のキー識別子について次にアクセスが行われた際に、再びハッシュ・テーブル４１０への登録およびマップの作成を行う。
【００３３】
また、データベース１１０に新しいレコードが生成された際にキャッシュを解放するのではなく、マップ４２０を更新して対応することも可能である。データベース１１０に対するレコードの生成は最新のタイムスタンプ情報を付して行われる。そこで、キャッシュ管理部１４０は、新しいマップエントリを作成し、タイムスタンプ情報、ＣＲＵＤ値、データオブジェクトをセットした後、データ保持部１３０内の該当するマップ４２０の先頭に、この新たなマップエントリを追加する。
【００３４】
ここで、データベース１１０が更新されたか否かのチェックは、従来技術をそのまま適用可能であるが、本実施形態における、マップ４２０によってキャッシュを管理するという構造を利用して、次のような簡単な方法でも行うことができる。すなわち、データベース１１０内で、与えられたキー識別子をもつレコードの数を返す軽量なクエリを発行し、キャッシュされているデータが使用可能かチェックするという方法である。クエリからの戻り値が、現在のマップ４２０のエントリ数と合致すれば、このキー識別子に関し、マップ４２０の作成以後データベース１１０の更新はないと判断できる。したがって、キャッシュされているデータはそのまま使用可能である。一方、戻り値がマップ４２０のエントリ数よりも大きい場合は、マップ４２０の作成以後データベース１１０に変更があったと判断できる。したがって、上記のような処理（キャッシュの解放またはマップ４２０の更新）が行われる。なお、レコード数を返す軽量なクエリは、例えば図７で示されるようなマップ４２０の作成手続きの場合、
“select count(*) from TABLE where KEY_IDFR = ?”
のようになる。
【００３５】
図４に示したデータ構造を用いれば、ハッシュ・テーブル４１０にキー識別子が登録されたデータに関しては、データベース１１０においてそのキー識別子を持つ全てのレコードに関するタイムスタンプ情報を含む情報がマップ４２０に記録される。したがって、クエリに付与されたタイムスタンプ情報を基準としてどのようなレコードを取得しようとする場合にも、そのレコードがマップ４２０上のどのエントリに対応し、そのレコードの内容がキャッシュされているか否かを判断することができる。したがって、該当するレコードがキャッシュされていれば、そのレコードを読み出して返し、該当するレコードがキャッシュされていなければ、アクセス部１２０によるデータベース１１０の検索に移行した後、検索結果を取得してデータ保持部１３０にキャッシュすれば良い。また、既に検索が行われたもののデータベース１１０にデータが存在しないことが分かっている所定のキー識別子に関して、ハッシュ・テーブル４１０にデータが存在しないことを示す情報を対応付けることで、データベース１１０を実際に検索することなく、所望のデータが存在しないことを認識することができる。
【００３６】
＜キャッシュシステムの動作＞
次に、データ保持部１３０、キャッシュ管理部１４０およびマップ作成部１５０により構成されるキャッシュシステムの動作について説明する。
図８は、キャッシュシステムの動作の流れを示すフローチャートである。
キー識別子およびタイムスタンプ情報が指定されたクエリによりデータの読み出しが行われると、アクセス部１２０は、キャッシュ管理部１４０に該当するデータのキャッシュ検索を行わせる（ステップ８０１）。キャッシュ管理部１４０は、アクセス部１２０の指示に基づき、まず、クエリで指定されているキー識別子がハッシュ・テーブル４１０に登録されているか否かを調べる。
【００３７】
クエリで指定されたキー識別子がハッシュ・テーブル４１０に登録されている場合（ステップ８０２でＹｅｓ）、次にキャッシュ管理部１４０は、そのキー識別子に対応付けられたマップ４２０を探索する（ステップ８０３）。クエリで指定されたタイムスタンプ情報に基づく条件に合致するレコードがキャッシュされているならば（ステップ８０４でＹｅｓ）、キャッシュ管理部１４０は、そのレコードを読み出してアクセス部１２０に返す（ステップ８０５）。
【００３８】
一方、マップ４２０を探索した結果、クエリで指定されたタイムスタンプ情報に基づく条件に合致するレコードがキャッシュされていない場合（ステップ８０４でＮｏ）、すなわちデータオブジェクトが「ｎｕｌｌ」の場合は、キャッシュ管理部１４０は、その結果をアクセス部１２０に返す。そして、アクセス部１２０によるデータベース１１０の検索結果を取得し（ステップ８０６）、データベース１１０から読み出されたレコードをマップ４２０のマップエントリに対応付けてキャッシュする（ステップ８０７）。
【００３９】
これに対し、クエリで指定されたキー識別子がハッシュ・テーブル４１０に登録されていない場合（ステップ８０２でＮｏ）、キャッシュ管理部１４０は、クエリに合致するレコードがキャッシュされていないことをアクセス部１２０に通知して、そのキー識別子をハッシュ・テーブル４１０に登録する（ステップ８０８）。また、キャッシュ管理部１４０は、マップ４２０を作成するための専用のクエリを発行する（ステップ８０９）。
【００４０】
クエリで指定されたキー識別子を持つデータがデータベース１１０に存在するならば（ステップ８１０でＹｅｓ）、そのキー識別子を持つレコードのタイムスタンプ情報等の情報が得られる。この場合、キャッシュ管理部１４０は、得られた情報に基づいてマップ４２０を作成する（ステップ８１１）。次に、キャッシュ管理部１４０は、アクセス部１２０によるデータベース１１０の検索結果を取得し（ステップ８１２）、データベース１１０から読み出されたレコードをマップ４２０のマップエントリに対応付けてキャッシュする（ステップ８１３）。
【００４１】
一方、クエリで指定されたキー識別子を持つデータがデータベース１１０に存在しない場合（ステップ８１０でＮｏ）、そのキー識別子に対するマップ４２０を作成することはできない。この場合、キャッシュ管理部１４０は、ステップ８０８でハッシュ・テーブル４１０に登録したキー識別子に対応付けて、データが存在しないことを示す情報をデータ保持部１３０に保持させる（ステップ８１４）。
【００４２】
＜キャッシュのデータ構造の他の例＞
本実施形態によるキャッシュシステムにおけるキャッシュのデータ構造は、キー識別子を登録するハッシュ・テーブル４１０と、同一のキー識別子を持つレコードを時系列に管理するマップ４２０との組み合わせで構成される。ここで、ハッシュ・テーブル４１０やマップ４２０の構成自体は、データフェッチの内容に応じた変更が可能である。
【００４３】
図９に示すクエリ（ＳＱＬ文）を考える。このクエリは、キー識別子とタイムスタンプ情報を与えてフェッチするのは図６の例と同じであるが、副照会の中で、主照会で指定のないカラム（ＩＤＦＲ２）をバインドしている。これは、指定したキー識別子を持つレコードのうち、ＩＤＦＲ２値が同じものの中で最新のタイムスタンプを持つレコードのセットを副照会が返すので、このうちＣＲＵＤ値が「Ｄ（削除）」でないものだけを最終的に返す。
【００４４】
図１０は、このようなクエリに対応するキャッシュのデータ構造の例を示す図である。
図１０に示すデータ構造では、ハッシュ・テーブル４１０とマップ４２０の間に補助エントリ（Auxiliary entries）４３０が設けられ、クエリの実行に伴って段階的に指定されるキー識別子が、ハッシュ・テーブル４１０と補助エントリ４３０により階層的に登録される。そして、補助エントリ４３０に登録された最下層のキー識別子に対応付けてマップ４２０が登録される。
【００４５】
図１０に示すデータ構造におけるマップを作成するための専用のクエリおよびクエリ結果からデータ構造を生成するコードは、図１１のようになる。図１１のクエリが実行されると、ハッシュ・テーブル４１０のエントリから、ＩＤＦＲ２が昇順に並んだ補助エントリ４３０のリストを経由して、各ＩＤＦＲ２の値ごとにタイムスタンプ順で並んだマップ４２０が作成される。この状態のキャッシュに対して、所定のキー識別子およびタイムスタンプ情報が指定されたクエリが受け付けられると、例えば、図１０の一点鎖線で囲まれたエントリの集合が特定される。そして、必要ならばデータベース１１０にアクセスして、クエリに対応するデータオブジェクト（ｅｎｔｒｙＯｂｊ）のレコードを取得した後、ＣＲＵＤ値が「Ｄ（削除）」のものを除外したオブジェクトの集合が返される。
【００４６】
以上、クエリの実行に伴って段階的にキー識別子が指定される場合に適したデータ構造について説明した。クエリの内容によっては、さらに数段階にわたって補助エントリ４３０を設けることも可能である。
【００４７】
以上、本実施形態について説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。例えば、上記実施形態では、クエリがキー識別子とタイムスタンプ情報を指定して発行されるために、マップにおいて各マップエントリをレコードに対応付けるためにタイムスタンプ情報を用いた。これに対し、クエリに対応するレコードを一意に特定できる他の情報を適宜用いてマップを作成しても良い。その他、上記実施形態に、種々の変更または改良を加えたものも、本発明の技術的範囲に含まれることは、特許請求の範囲の記載から明らかである。
【図面の簡単な説明】
【００４８】
【図１】本実施形態が適用されるデータベースシステムの機能構成例を示す図である。
【図２】データベースシステムを構成するコンピュータのハードウェア構成例を示す図である。
【図３】本実施形態のデータベースの構成例を示す図である。
【図４】本実施形態におけるキャッシュのデータ構造の例を示す図である。
【図５】図４におけるマップエントリのデータ構造の例を示す図である。
【図６】データフェッチのためのクエリの例を示す図である。
【図７】図６のクエリに対応する本実施形態のマップを作成するための専用のクエリとクエリ結果からデータ構造を生成するコードの例を示す図である。
【図８】本実施形態のキャッシュシステムの動作の流れを示すフローチャートである。
【図９】データフェッチのためのクエリの他の例を示す図である。
【図１０】図９のクエリに対応する本実施形態のキャッシュのデータ構造の例を示す図である。
【図１１】図１０に示すデータ構造におけるマップを作成するための専用のクエリおよびクエリ結果からデータ構造を生成するコードの例を示す図である。
【符号の説明】
【００４９】
１００…データベースシステム、１１０…データベース、１２０…アクセス部、１３０…データ保持部、１４０…キャッシュ管理部、１５０…マップ作成部、４１０…ハッシュ・テーブル、４２０…マップ、４２１、４２２…マップエントリ
【図１】
0005186270.tif 000002
【図２】
0005186270.tif 000003
【図３】
0005186270.tif 000004
【図４】
0005186270.tif 000005
【図５】
0005186270.tif 000006
【図６】
0005186270.tif 000007
【図７】
0005186270.tif 000008
【図８】
0005186270.tif 000009
【図９】
0005186270.tif 000010
【図１０】
0005186270.tif 000011
【図１１】
0005186270.tif 000012