JP6158361B2

JP6158361B2 - 情報処理装置及び方法

Info

Publication number: JP6158361B2
Application number: JP2015561117A
Authority: JP
Inventors: 明文村田
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2014-02-07
Filing date: 2014-02-07
Publication date: 2017-07-05
Anticipated expiration: 2034-02-07
Also published as: JPWO2015118662A1; US20160335313A1; US10303680B2; WO2015118662A1

Description

本発明の実施形態は、一般的に情報処理装置及び方法に関する。

近年、データの管理方法として、リレーショナルデータベース（RDB: Relational Database）とインメモリのキーバリューストア（KVS: Key Value Store）とを組み合せて使用するデータ管理方法が普及しつつある。このデータ管理方法によれば、ＲＤＢだけを使用したデータ管理方法にくらべて、クライアント端末が所望のデータを取得するまでに要する時間を短縮することができる。

一般に、ＲＤＢだけを使用したデータ管理方法の場合、クライアント端末からのアクセスに応じて、ＲＤＢに格納された多量のテーブルの中から所望のデータを含むテーブルを検索し、このテーブルから所望のデータを取得する必要があり、クライアント端末が所望のデータを取得するまでに時間がかかってしまう。

一方で、ＲＤＢとインメモリのＫＶＳとを組み合せて使用するデータ管理方法の場合、まずインメモリのＫＶＳに所望のデータがキャッシュとして格納されているか否かを確認する。インメモリのＫＶＳには、所望のデータを取得するためのキーと所望のデータとが１対１に対応付けられて格納されているため、所望のデータがキャッシュとして格納されている場合は、クライアント端末は、ＲＤＢだけを使用したデータ管理方法にくらべて格段に早く所望のデータを取得することができる。また、所望のデータがキャッシュとして格納されていない場合は、クライアント端末は、アクセス対象をＲＤＢに変更して、ＲＤＢから所望のデータを取得することになるが、このときに取得した所望のデータをインメモリのＫＶＳのキャッシュとして登録しておくことにより、クライアント端末が所望のデータを取得するまでにかかる次回以降の時間を短縮することができる。

以上のように、ＲＤＢとインメモリのＫＶＳとを組み合せて使用するデータ管理方法によれば、ＲＤＢだけを使用したデータ管理方法にくらべて、クライアント端末が所望のデータを取得するまでに要する時間を短縮することができる。

しかしながら、上述したように、ＲＤＢとインメモリのＫＶＳとを組み合せて使用する場合であって、インメモリのＫＶＳにキャッシュとして所望のデータが格納されていない場合に、クライアント端末自身が、アクセス対象をＲＤＢに変更する必要があるという不都合がある。すなわち、アクセス対象をインメモリのＫＶＳからＲＤＢに変更するというクライアント端末の動作の記述を、クライアント端末を操作するユーザが行う必要があるという不都合がある。

また、ＲＤＢとインメモリのＫＶＳとを組み合せて使用するデータ管理方法の場合、ＲＤＢに格納されたデータを更新した際に不都合が生じる恐れがある。一般に、ＲＤＢに格納されたデータを更新した際には、もし更新前のデータがインメモリのＫＶＳにキャッシュとして格納されている場合はこのキャッシュのデータも更新する必要がある。しかしながら、ＲＤＢに格納されたデータの更新に応じて、インメモリのＫＶＳのキャッシュの更新を行わせるという動作の記述は複雑であり、この動作が一般的には行われていないという現状がある。これにより、ＲＤＢに格納されたデータが更新されているにも関わらず、インメモリのＫＶＳのキャッシュのデータが更新されていないことに起因して、クライアント端末に更新前のデータを取得させてしまう恐れがある。

特開２０１３−１５２５５７号公報

本発明の一形態の目的は、ＲＤＢとインメモリのＫＶＳとを組み合せて使用する好適なデータ管理方法を実現し得る情報処理装置及び方法を提供することである。

実施形態によれば、情報処理装置は、クライアント端末と、複数のカラム名と各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えた第１記憶媒体と、前記第１記憶媒体に格納された各テーブル内の一部のデータと当該データを読み出す際に用いるキーとを対応付けて格納する第２記憶媒体とに通信可能に接続され、データ管理システムに適用される。この情報処理装置は、前記クライアント端末から前記第１記憶媒体に格納された各テーブル内のデータを書きかえる旨の更新要求を受けると、前記第１記憶媒体を検索して、前記更新要求による更新対象のデータのカラム名とカラムとを取得する取得手段と、前記取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込む第１書込手段と、前記受信された更新要求にしたがって、前記更新対象のデータのカラムを更新する更新手段と、更新の後に、前記クライアント端末から前記更新を確定させる旨の更新確定要求を受けると、前記第１記憶媒体に格納された前記更新対象のデータのカラムへの更新を確定させると共に、前記一時メモリに格納された前記更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与する更新確定手段と、前記第２記憶媒体に格納されたデータ群から、前記更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する削除手段とを具備する。

図１は、第１実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。図２は、同実施形態に係る情報処理装置によって実行されるデータ更新処理の手順の一例を示すフローチャートである。図３は、第２実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。図４は、同実施形態に係る情報処理装置によって実行されるデータ更新処理の手順の一例を示すフローチャートである。

以下、実施の形態について図面を参照して説明する。
［第１実施形態］
図１は、第１実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。データ管理システム１は、ＲＤＢ１１、インメモリＫＶＳ１２、クライアント端末１３及び情報処理装置１４等を備えている。

ＲＤＢ１１は、複数のカラム名と、各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えており、クライアント端末１３から情報処理装置１４を介して受けた取得要求ＳＱＬを受けると、この取得要求ＳＱＬに応じた戻り値を送出する機能をもっている。ＲＤＢ１１は、所謂ハードディスクドライブ（HDD: Hard Disk Drive）等によって構成される。

インメモリＫＶＳ１２は、データを識別するためのキー（例えば、取得要求ＳＱＬ等）とデータとを１対１に対応付けて格納する記憶媒体である。尚、本実施形態では、インメモリＫＶＳ１２はデータ保存領域として所謂ＨＤＤを使用するＫＶＳではなく、データ保存領域をメモリ上に置くことにより高速に処理が可能なＫＶＳを想定する。

クライアント端末１３は、ＲＤＢ１１に格納されたデータを取得するための取得要求ＳＱＬを発行し、この取得要求ＳＱＬに応じた戻り値を受信する機能をもっている。また、クライアント端末１３は、ＲＤＢ１１に格納されたデータを更新するための更新要求ＳＱＬ（例えば、変更要求ＳＱＬ、挿入要求ＳＱＬ等）を発行する機能をもっている。さらに、クライアント端末１３は、更新要求ＳＱＬにしたがって実行された更新を確定させるための確定要求ＳＱＬや、上述の更新を元に戻すための巻き戻し要求ＳＱＬを発行する機能をもっている。

情報処理装置１４は、図１に示すように、クライアント通信部１４１、キャッシュ制御部１４２、ＲＤＢ通信部１４３及び更新用ワークメモリ１４４等をさらに含む。以下の説明では、まずデータ取得処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について述べた後に、データ更新処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明する。
まずデータ取得処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明する。

クライアント通信部１４１は、クライアント端末１３によって発行された取得要求ＳＱＬを受信し、この取得要求ＳＱＬをキャッシュ制御部１４２に送出する機能と、取得要求ＳＱＬに応じた戻り値をクライアント端末１３に送出する機能とをもっている。

キャッシュ制御部１４２は、クライアント通信部１４１から送出された取得要求ＳＱＬを受けると、当該取得要求ＳＱＬをキーとしてインメモリＫＶＳ１２を検索する機能をもっている。また、キャッシュ制御部１４２は、検索の結果、取得要求ＳＱＬに応じた戻り値がインメモリＫＶＳ１２から得られた場合に、当該戻り値をクライアント通信部１４１に送出する機能をもっている。さらに、キャッシュ制御部１４２は、検索の結果、取得要求ＳＱＬに応じた戻り値がインメモリＫＶＳ１２から得られなかった場合に、当該取得要求ＳＱＬをＲＤＢ通信部１４３に送出（転送）する機能をもっている。

ＲＤＢ通信部１４３は、キャッシュ制御部１４２から送出された取得要求ＳＱＬを受けると、当該取得要求ＳＱＬをＲＤＢ１１に送出して、当該取得要求ＳＱＬに応じた戻り値を取得すると共に、キャッシュ制御部１４２を介して、当該取得した戻り値を当該取得要求ＳＱＬをキーとしてインメモリＫＶＳ１２に登録する。取得された戻り値はクライアント通信部１４１に送出される。

尚、更新用ワークメモリ１４４は、データ取得処理時には使用されないものとする。

次に、データ更新処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明する。尚、データ更新処理には、変更要求ＳＱＬにしたがって実行されるデータ更新処理と、挿入要求ＳＱＬにしたがって実行されるデータ更新処理とがある。以下の説明では、まず変更要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明した後に、挿入要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明する。
まず変更要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明する。

クライアント通信部１４１は、クライアント端末１３によって発行された行ロック要求ＳＱＬを受信し、この行ロック要求ＳＱＬをＲＤＢ通信部１４３に送出する機能をもっている。行ロック要求ＳＱＬとは、主に、ＲＤＢ１１に格納されたデータを変更（更新）する前にクライアント端末１３から発行される要求ＳＱＬであり、更新対象のデータを含む行（又はテーブル）への他のリソースのアクセスを制限することを要求するものである。尚、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された行ロック要求ＳＱＬを受けると、当該行ロック要求ＳＱＬをＲＤＢ１１に送出して、更新対象のデータを含む行への他のリソースのアクセスを制限する（当該行をロックする）と共に、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む。

また、クライアント通信部１４１は、クライアント端末１３によって発行された変更要求ＳＱＬを受信し、この変更要求ＳＱＬをＲＤＢ通信部１４３に送出する機能をもっている。

ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された変更要求ＳＱＬを受けると、更新用ワークメモリ１４４を参照して、当該変更要求ＳＱＬにしたがって更新する（ＲＤＢ１１内の）データを含む行（又はテーブル）が事前にロックされているか否かを確認する機能をもっている。

確認の結果、事前にロックされていない場合には、ＲＤＢ通信部１４３は、変更要求ＳＱＬにしたがって更新するデータを含む行への他のリソースのアクセスを制限した後に、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する。このとき、ＲＤＢ通信部１４３は、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む。一方で、確認の結果、事前にロックされている場合には、ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索する処理だけを実行する。

ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索すると、当該更新対象のデータのカラム名とカラムとを更新用ワークメモリ１４４に書き込む機能をもっている。また、ＲＤＢ通信部１４３は、変更要求ＳＱＬをＲＤＢ１１に送出して、更新対象のデータを更新する機能をもっている。

さらに、ＲＤＢ通信部１４３は、クライアント端末１３から発行された確定要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の変更要求ＳＱＬにしたがって実行された更新を確定させる処理を実行すると共に、更新用ワークメモリ１４４に格納された更新前のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する処理を実行する。一方で、ＲＤＢ通信部１４３は、クライアント端末１３から発行された巻き戻し要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の変更要求ＳＱＬにしたがって実行された更新を元に戻す処理を実行する。

キャッシュ制御部１４２は、インメモリＫＶＳ１２に格納されたデータ群から、更新用ワークメモリ１４４内で更新確定情報が付与されたカラム名とカラムとを含むデータを削除する機能をもっている。また、キャッシュ制御部１４２は、更新用ワークメモリ１４４に格納されたロック情報と更新確定情報が付与されたデータとを適宜削除する機能をもっている。尚、上述のような更新用ワークメモリ１４４に格納された各種データを削除する機能は、ＲＤＢ通信部１４３が有していてもよい。

次に、挿入要求ＳＱＬにしたがって実行されるデータ更新処理時に使用される情報処理装置１４内の各部１４１〜１４４の機能について説明する。

クライアント通信部１４１は、クライアント端末１３によって発行された挿入要求ＳＱＬを受信し、この挿入要求ＳＱＬをＲＤＢ通信部１４３に送出する機能をもっている。

ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された挿入要求ＳＱＬを受けると、当該挿入要求ＳＱＬをＲＤＢ１１に送出して、挿入対象のデータをＲＤＢ１１に格納された所望のテーブルに挿入する機能をもっている。また、ＲＤＢ通信部１４３は、挿入対象のデータを挿入要求ＳＱＬにしたがって挿入すると（挿入が成功すると）、挿入されたデータのカラム名とカラムとを全て更新用ワークメモリ１４４に書き込む機能をもっている。

さらに、ＲＤＢ通信部１４３は、クライアント端末１３から発行された確定要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の挿入要求ＳＱＬにしたがって実行された更新を確定させる処理を実行すると共に、更新用ワークメモリ１４４に格納された挿入対象のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する処理を実行する。一方で、ＲＤＢ通信部１４３は、クライアント端末１３から発行された巻き戻し要求ＳＱＬをクライアント通信部１４１を介して受けると、上述の挿入要求ＳＱＬにしたがって実行された更新を元に戻す処理を実行する。

キャッシュ制御部１４２は、更新用ワークメモリ１４４に格納された更新確定情報が付与されたデータを適宜削除する機能をもっている。尚、上述のような更新用ワークメモリ１４４に格納された各種データを削除する機能は、ＲＤＢ通信部１４３が有していてもよい。

次に、以上のように構成された情報処理装置１４によって実行されるデータ更新処理の手順の一例について、図２のフローチャートを参照しながら説明する。ここでは、変更要求ＳＱＬにしたがって実行されるデータ更新処理の手順について説明する。

始めに、クライアント通信部１４１は、クライアント端末１３によって発行された変更要求ＳＱＬを受信し、この変更要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ１）。

次に、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された変更要求ＳＱＬを受けると、更新用ワークメモリ１４４を参照して、当該変更要求ＳＱＬにしたがって更新する（ＲＤＢ１１内の）データを含む行（又はテーブル）が事前にロックされているか否かを確認する（ステップＳ２）。

ステップＳ２の確認の結果が事前にロックされている旨を示す場合（ステップＳ２のＹＥＳ）、ＲＤＢ通信部１４３は、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する（ステップＳ３）。尚、ステップＳ３の処理が終了すると、後述するステップＳ５の処理に進む。

一方、ステップＳ２の確認の結果が否を示す場合（ステップＳ２のＮＯ）、ＲＤＢ通信部１４３は、変更要求ＳＱＬにしたがって更新するデータを含む行をロックした後に、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する。そして、ＲＤＢ通信部１４３は、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む（ステップＳ４）。

続いて、ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索すると、当該更新対象のデータのカラム名とカラムとを更新用ワークメモリ１４４に書き込む（ステップＳ５）。次に、ＲＤＢ通信部１４３は、変更要求ＳＱＬをＲＤＢ１１に送出して、更新対象のデータを更新する（ステップＳ６）。

上述のステップＳ１〜Ｓ６の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ７）。すなわち、クライアント通信部１４１は、変更要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。

続いて、クライアント通信部１４１は、クライアント端末１３から発行された要求ＳＱＬを受信し、当該要求ＳＱＬが巻き戻し要求ＳＱＬ又は確定要求ＳＱＬのどちらであるかを確認する（ステップＳ８）。尚、ステップＳ８の確認の結果が確定要求ＳＱＬである場合は、後述するステップＳ１３の処理に進む。

ステップＳ８の確認の結果が巻き戻し要求ＳＱＬである場合（ステップＳ８の巻き戻し要求ＳＱＬ）、クライアント通信部１４１は、この巻き戻し要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ９）。

次に、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された巻き戻し要求ＳＱＬを受けると、当該巻き戻し要求ＳＱＬをＲＤＢ１１に送出して、変更要求ＳＱＬにしたがって実行された更新を元に戻す処理を実行する。なお、巻き戻し要求ＳＱＬにしたがって更新を元に戻す処理が実行されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ１０）。続いて、ＲＤＢ通信部１４３は、更新用ワークメモリ１４４に格納されたロック情報及び更新対象のデータのカラム名とカラムとを削除する（ステップＳ１１）。

しかる後、クライアント通信部１４１は、クライアント端末１３に応答する、すなわち、巻き戻し要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知し（ステップＳ１２）、データ更新処理を終了させる。

ステップＳ８の確認の結果が確定要求ＳＱＬである場合（ステップＳ７の確定要求ＳＱＬ）、クライアント通信部１４１は、この確定要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ１３）。

続いて、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された確定要求ＳＱＬを受けると、当該確定要求ＳＱＬをＲＤＢ１１に送出して、変更要求ＳＱＬにしたがって実行された更新を確定させる処理を実行する。なお、確定要求ＳＱＬにしたがって更新を確定させる処理が実行されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ１４）。次に、ＲＤＢ通信部１４３は、更新用ワークメモリ１４４に格納された更新対象のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する（ステップＳ１５）。

上述のステップＳ８，Ｓ１３〜Ｓ１５の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ１６）。すなわち、クライアント通信部１４１は、確定要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。

続いて、キャッシュ制御部１４２は、インメモリＫＶＳ１２に格納されたデータ群から、更新用ワークメモリ１４４内で更新確定情報が付与されたカラム名とカラムとを含むデータを削除する（ステップＳ１７）。

しかる後、キャッシュ制御部１４２は、更新用ワークメモリ１４４に格納されたロック情報及び更新確定情報が付与されたデータのカラム名とカラムとを削除し（ステップＳ１８）、データ更新処理を終了させる。

以上説明した第１実施形態によれば、データ取得処理時に、まずインメモリＫＶＳ１２を確認し、インメモリＫＶＳ１２から所望のデータが得られない場合にはＲＤＢ１１にアクセスするという処理を情報処理装置１４が実行するため、クライアント端末１３を操作するユーザがわざわざアクセス対象を変更しなくても所望のデータを素早く取得することができる。

また、本実施形態によれば、データ更新処理時に、インメモリＫＶＳ１２に格納された更新前のデータを削除するという処理を情報処理装置１４が実行するため、データ更新処理後に、クライアント端末１３がインメモリＫＶＳ１２から更新前のデータを取得してしまうことを防ぐことができる。

［第２実施形態］
図３は、第２実施形態に係る情報処理装置を適用するデータ管理システムの概略構成例を示すブロック図である。図３のデータ管理システム１は、図１に示した構成に加えて、ＫＶＳジャーナル１５をさらに備えると共に、情報処理装置１４が遅延更新処理部１４５をさらに含む構成になっている。ここでは主に、上述した第１実施形態とは異なる機能について説明する。

まずＫＶＳジャーナル１５について説明する。
ＫＶＳジャーナル１５は、情報処理装置１４によって実行されるデータ更新処理に関するログファイルを格納する記憶媒体であり、インメモリＫＶＳ１２と通信可能に接続される。尚、ＫＶＳジャーナル１５は、ＲＤＢ１１と同様に、所謂ＨＤＤ等によって構成される。このため、データ管理システム１の停止等に起因して、インメモリＫＶＳ１２に格納されたデータが削除されてしまったとしても、ＫＶＳジャーナル１５に格納されたログファイルが削除されることはない。本実施形態では、ＫＶＳジャーナル１５は情報処理装置１４外に設けられるとしたが、ＫＶＳジャーナル１５は情報処理装置１４内に設けられるとしてもよい。

遅延更新処理部１４５は、データ管理システム１が停止した際に、クライアント端末１３から既に発行されて、インメモリＫＶＳ１２に一度格納された各種要求ＳＱＬ（例えば、変更要求ＳＱＬ、確定要求ＳＱＬ等）を、ＫＶＳジャーナル１５に格納されたログファイルに基づいて再構成するようインメモリＫＶＳ１２に要求する機能をもっている。また、遅延更新処理部１４５は、インメモリＫＶＳ１２により再構成された各種要求ＳＱＬにしたがって、データ管理システム１の停止に起因して中断されてしまったデータ更新処理を再度実行する機能をもっている。

次に、本実施形態に係る情報処理装置１４によって実行されるデータ更新処理の手順の一例について、図４のフローチャートを参照しながら説明する。ここでは、変更要求ＳＱＬにしたがって実行されるデータ更新処理の手順について説明する。

始めに、クライアント通信部１４１は、クライアント端末１３によって発行された変更要求ＳＱＬを受信し、この変更要求ＳＱＬをＲＤＢ通信部１４３に送出する（ステップＳ２１）。尚、ここでは、クライアント通信部１４１は、受信した変更要求ＳＱＬをキャッシュ制御部１４２にも適宜送出するものとする。

次に、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された変更要求ＳＱＬを受けると、更新用ワークメモリ１４４を参照して、当該変更要求ＳＱＬにしたがって更新する（ＲＤＢ１１内の）データを含む行（又はテーブル）が事前にロックされているか否かを確認する（ステップＳ２２）。

ステップＳ２２の確認の結果が事前にロックされている旨を示す場合（ステップＳ２２のＹＥＳ）、ＲＤＢ通信部１４３は、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する（ステップＳ２３）。尚、ステップＳ２３の処理が終了すると、後述するステップＳ２５の処理に進む。

一方、ステップＳ２２の確認の結果が否を示す場合（ステップＳ２２のＮＯ）、ＲＤＢ通信部１４３は、変更要求ＳＱＬにしたがって更新するデータを含む行をロックした後に、ＲＤＢ１１に格納された複数のテーブルから更新対象のデータを含む行を検索する。そして、ＲＤＢ通信部１４３は、ロックした行を示すロック情報を更新用ワークメモリ１４４に書き込む（ステップＳ２４）。

続いて、ＲＤＢ通信部１４３は、更新対象のデータを含む行を検索すると、当該更新対象のデータのカラム名とカラムとを更新用ワークメモリ１４４に書き込む（ステップＳ２５）。

更新対象のデータのカラム名とカラムとが更新用ワークメモリ１４４に書き込まれると、キャッシュ制御部１４２は、クライアント通信部１４１から送出され、受信した変更要求ＳＱＬをインメモリＫＶＳ１２に書き込む（ステップＳ２６）。尚、インメモリＫＶＳ１２に変更要求ＳＱＬが書き込まれると、ＫＶＳジャーナル１５には、変更要求ＳＱＬがインメモリＫＶＳ１２に書き込まれた旨のログファイルが適宜記録される。

上述のステップＳ２１〜Ｓ２６の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ２７）。すなわち、クライアント通信部１４１は、変更要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。

次に、クライアント通信部１４１は、クライアント端末１３から発行された要求ＳＱＬを受信し、当該要求ＳＱＬが巻き戻し要求ＳＱＬ又は確定要求ＳＱＬのどちらであるかを確認する（ステップＳ２８）。尚、ステップＳ２８の確認の結果が確定要求ＳＱＬである場合、後述するステップＳ３３の処理に進む。

ステップＳ２８の確認の結果が巻き戻し要求ＳＱＬである場合（ステップＳ２８の巻き戻し要求ＳＱＬ）、クライアント通信部１４１は、この巻き戻し要求ＳＱＬをＲＤＢ通信部１４３に送出する。なお、巻き戻し要求ＳＱＬがＲＤＢ通信部１４３に送出されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ２９）。

続いて、ＲＤＢ通信部１４３は、クライアント通信部１４１から送出された巻き戻し要求ＳＱＬを受けると、当該巻き戻し要求ＳＱＬにしたがって、更新用ワークメモリ１４４に格納されたロック情報及び更新対象のデータのカラム名とカラムとを削除する（ステップＳ３０）。

更新用ワークメモリ１４４に格納された各種データが削除されると、キャッシュ制御部１４２は、インメモリＫＶＳ１２に格納された変更要求ＳＱＬを削除する（ステップＳ３１）。

しかる後、クライアント通信部１４１は、クライアント端末１３に応答する、すなわち、巻き戻し要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知し（ステップＳ３２）、データ更新処理を終了させる。

上述したステップＳ２８の確認の結果が確定要求ＳＱＬである場合（ステップＳ２８の確定要求ＳＱＬ）、クライアント通信部１４１は、この確定要求ＳＱＬをキャッシュ制御部１４２に送出する（ステップＳ３３）。

次に、キャッシュ制御部１４２は、クライアント通信部１４１から送出された確定要求ＳＱＬを受けると、当該確定要求ＳＱＬをインメモリＫＶＳ１２に書き込む（ステップＳ３４）。尚、インメモリＫＶＳ１２に確定要求ＳＱＬが書き込まれると、ＫＶＳジャーナル１５には、確定要求ＳＱＬがインメモリＫＶＳ１２に書き込まれた旨のログファイルが適宜記録される。

確定要求ＳＱＬがインメモリＫＶＳ１２に書き込まれると、ＲＤＢ通信部１４３は、更新用ワークメモリ１４４に格納された更新対象のデータのカラム名とカラムとに対して更新が確定された旨を示す更新確定情報を付与する（ステップＳ３５）。

上述のステップＳ２８，Ｓ３３〜Ｓ３５の処理が実行されると、クライアント通信部１４１は、クライアント端末１３に応答する（ステップＳ３６）。すなわち、クライアント通信部１４１は、確定要求ＳＱＬにしたがって実行する処理が終了した旨をクライアント端末１３に通知する。

続いて、遅延更新処理部１４５は、上述したクライアント端末１３への応答とは非同期に、キャッシュ制御部１４２を介して、インメモリＫＶＳ１２に格納された変更要求ＳＱＬ及び確定要求ＳＱＬを取得し、これら要求ＳＱＬをＲＤＢ１１に送出して、ＲＤＢ１１に格納された更新対象のデータを更新し、この更新を確定させる処理を実行する。なお、確定要求ＳＱＬにしたがって更新を確定させる処理が実行されると、ＲＤＢ１１側では、更新対象のデータを含む行に対して行われたロックが自動的に解放される（ステップＳ３７）。

更新対象のデータの更新処理及び更新確定処理が実行されると、遅延更新処理部１４５は、インメモリＫＶＳ１２に格納された変更要求ＳＱＬ及び確定要求ＳＱＬを削除する（ステップＳ３８）。また、遅延更新処理部１４５は、インメモリＫＶＳに格納されたデータ群から、更新用ワークメモリ１４４内で更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する（ステップＳ３９）。

しかる後、遅延更新処理部１４５は、更新用ワークメモリ１４４に格納されたロック情報及び更新確定情報が付与されたデータのカラム名とカラムとを削除し（ステップＳ４０）、データ更新処理を終了させる。

以上説明した第２実施形態によれば、データ更新処理の途中でデータ管理システム１が停止したとしても、システム再起動後に、ＫＶＳジャーナル１５に格納されたログファイルに基づいて、インメモリＫＶＳ１２に格納されていた変更要求ＳＱＬや確定要求ＳＱＬを再構成することができる。これに伴い、クライアント端末１３から各種要求ＳＱＬを再度発行し直してもらわなくても、データ更新処理を再度実行することができる。また、ＲＤＢ１１に対するデータ更新として最も応答時間がかかるデータ更新処理とデータ更新確定処理とを、データの変更を保障したまま、クライアント端末１３に対する応答の後に実行させることにより、クライアント端末１３への応答時間を早めることができる。

以上説明した少なくとも１つの実施形態によれば、ＲＤＢ１１とインメモリのＫＶＳ１２とを組み合せて使用する好適なデータ管理方法を実現させることができる。

なお、本実施形態の処理は、コンピュータプログラムによって実現することができるので、このコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体を通じてこのコンピュータプログラムをコンピュータにインストールして実行するだけで、本実施形態と同様の効果を容易に実現することができる。

なお、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims

クライアント端末と、複数のカラム名と各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えた第１記憶媒体と、前記第１記憶媒体に格納された各テーブル内の一部のデータと当該データを読み出す際に用いるキーとを対応付けて格納する第２記憶媒体とに通信可能に接続され、データ管理システムに適用される情報処理装置であって、
前記クライアント端末から前記第１記憶媒体に格納された各テーブル内のデータを書きかえる旨の更新要求を受けると、前記第１記憶媒体を検索して、前記更新要求による更新対象のデータのカラム名とカラムとを取得する取得手段と、
前記取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込む第１書込手段と、
前記受信された更新要求にしたがって、前記更新対象のデータのカラムを更新する更新手段と、
更新の後に、前記クライアント端末から前記更新を確定させる旨の更新確定要求を受けると、前記第１記憶媒体に格納された前記更新対象のデータのカラムへの更新を確定させると共に、前記一時メモリに格納された前記更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与する更新確定手段と、
前記第２記憶媒体に格納されたデータ群から、前記更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除する削除手段と
を具備する情報処理装置。
更新の後に、前記クライアント端末から前記更新を巻き戻す旨の巻き戻し要求を受けると、前記更新対象のデータのカラムを更新前のカラムに戻す巻き戻し手段をさらに具備する請求項１に記載の情報処理装置。
前記データ管理システムは、データ更新処理に関するログファイルを格納する第３記憶媒体をさらに含み、
前記情報処理装置は、
前記更新要求及び前記更新確定要求を受信した際に、当該更新要求及び当該更新確定要求を前記第２記憶媒体に各々書き込む第２書込手段と、
前記データ管理システムが停止した際に、前記第２記憶媒体に前記更新要求及び前記更新確定要求を書き込んだ旨の前記第３記憶媒体内のログファイルに基づいて、当該更新要求及び当該更新確定要求を再構成する再構成手段と、
前記再構成された更新要求及び更新確定要求にしたがってデータ更新処理を再度実行する再実行手段と
をさらに具備する請求項１に記載の情報処理装置。
前記クライアント端末からの取得要求を受けると、当該取得要求を前記キーとして前記第２記憶媒体を検索する検索手段と、
検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られた場合、当該戻り値を前記クライアント端末に送出する送出手段と、
検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られなかった場合、当該戻り値を前記第１記憶媒体から取得して、前記クライアント端末に送出すると共に、当該戻り値を前記取得要求と対応付けて前記第２記憶媒体に書き込む第３書込手段と
をさらに具備する請求項１に記載の情報処理装置。
クライアント端末と、複数のカラム名と各カラム名に対応するカラムとを有してテーブル名により識別される複数のテーブルを備えた第１記憶媒体と、前記第１記憶媒体に格納された各テーブル内の一部のデータと当該データを読み出す際に用いるキーとを対応付けて格納する第２記憶媒体とに通信可能に接続され、データ管理システムに適用される情報処理装置が実行する方法であって、
前記クライアント端末から前記第１記憶媒体に格納された各テーブル内のデータを書きかえる旨の更新要求を受けると、前記第１記憶媒体を検索して、前記更新要求による更新対象のデータのカラム名とカラムとを取得することと、
前記取得されたカラム名とカラムとが対応付けられたデータを一時メモリに書き込むことと、
前記受信された更新要求にしたがって、前記更新対象のデータのカラムを更新することと、
更新の後に、前記クライアント端末から前記更新を確定させる旨の更新確定要求を受けると、前記第１記憶媒体に格納された前記更新対象のデータのカラムへの更新を確定させると共に、前記一時メモリに格納された前記更新対象のデータのカラムを含むデータに対して更新を確定させた旨の更新確定情報を付与することと、
前記第２記憶媒体に格納されたデータ群から、前記更新確定情報が付与されたデータのカラム名とカラムとを含むデータを削除することと
を具備する方法。
更新の後に、前記クライアント端末から前記更新を巻き戻す旨の巻き戻し要求を受けると、前記更新対象のデータのカラムを更新前のカラムに戻すことをさらに具備する請求項５に記載の方法。
前記データ管理システムは、データ更新処理に関するログファイルを格納する第３記憶媒体をさらに含み、
前記更新要求及び前記更新確定要求を受信した際に、当該更新要求及び当該更新確定要求を前記第２記憶媒体に各々書き込むことと、
前記データ管理システムが停止した際に、前記第２記憶媒体に前記更新要求及び前記更新確定要求を書き込んだ旨の前記第３記憶媒体内のログファイルに基づいて、当該更新要求及び当該更新確定要求を再構成することと、
前記再構成された更新要求及び更新確定要求にしたがってデータ更新処理を再度実行することと
をさらに具備する請求項５に記載の方法。
前記クライアント端末からの取得要求を受けると、当該取得要求を前記キーとして前記第２記憶媒体を検索することと、
検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られた場合、当該戻り値を前記クライアント端末に送出することと、
検索の結果、前記取得要求に応じた戻り値が前記第２記憶媒体から得られなかった場合、当該戻り値を前記第１記憶媒体から取得して、前記クライアント端末に送出すると共に、当該戻り値を前記取得要求と対応付けて前記第２記憶媒体に書き込むことと
をさらに具備する請求項５に記載の方法。