JP7095800B2 - 情報処理プログラム、情報処理方法及び情報処理装置 - Google Patents

Description

本発明は、情報処理プログラム、情報処理方法及び情報処理装置に関する。

ＸＭＬ（Extensible Markup Language）データなどのデータをレコードとして記憶するデータベースは、レコードに対する操作を記録するＲｏｗＩＤファイルを保持する。図１４は、ＲｏｗＩＤファイルを説明するための図である。図１４に示すように、レコードに対する追加、更新又は削除の操作が行われると、操作情報がＲｏｗＩＤファイル９に追記される。操作情報には、命令区分、ＲｏｗＩＤ、レコードの物理位置などが含まれる。命令区分は、「追加（ＡＤＤ）」、「更新（ＵＰＤ）」又は「削除（ＤＥＬ）」である。ＲｏｗＩＤは、操作を識別する識別子である。レコードの物理位置は、レコードがＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）に格納される物理的な格納位置情報である。

ＲｏｗＩＤファイル９は、データベースの再起動時に、各レコードの最新状態をメモリ５１上に保持するＲｏｗＩＤヒドラ３６を復元するために用いられる。ＲｏｗＩＤヒドラ３６は、ＲｏｗＩＤに関する木構造のデータであり、木の葉の部分はＲｏｗＩＤヒドラ葉と呼ばれ、レコードの物理位置を含むレコード情報を記憶する。ＲｏｗＩＤヒドラ３６は、ＲｏｗＩＤからレコードの物理位置を取得する際に用いられる。

例えば、ＲｏｗＩＤを０００～９９９までの数とし、ＲｏｗＩＤヒドラ３６をルート（ｒｏｏｔ）を除いて３階層とすると、第１階層はＲｏｗＩＤの百の桁の数の０～９それぞれに対応する１０個のノードで構成される。第２階層は、第１階層の各ノードに対してＲｏｗＩＤの十の桁の数の０～９それぞれに対応する合計１００個のノードで構成される。第３階層すなわち葉の階層は、第２階層の各ノードに対してＲｏｗＩＤの一の桁の数の０～９それぞれに対応する合計１０００個のノードで構成される。なお、ＲｏｗＩＤヒドラ３６の詳細については、特開２００３－４４２６７に記載されている。

図１４に示すＲｏｗＩＤファイル９の例では、ＲｏｗＩＤが「＃１」であるレコードとＲｏｗＩＤが「＃２」であるレコードがデータベースに追加され、ＲｏｗＩＤが「＃２」であるレコードが更新され、ＲｏｗＩＤが「＃１」であるレコードが削除される。このＲｏｗＩＤファイル９が再起動時に読み込まれると、ＲｏｗＩＤが「＃１」であるレコードの情報とＲｏｗＩＤが「＃２」であるレコードの情報を記憶するＲｏｗＩＤヒドラ葉がＲｏｗＩＤヒドラ３６に作成される。そして、ＲｏｗＩＤが「＃２」であるレコードの情報を記憶するＲｏｗＩＤヒドラ葉が更新され、ＲｏｗＩＤが「＃１」であるレコードの情報を記憶するＲｏｗＩＤヒドラ葉が削除される。

なお、過去から現在まで同一の起源を持つデータを更新する毎に更新済のデータを時系列にしたがって格納するデータベースファイルから不要な時系列データを削除する際、自動的に必要時点の時系列データを同一データベースファイルに保持する従来技術がある。この従来技術のシステムは、データベースファイルとデータベース管理システムとデータベース管理情報入出力装置を備える。データベース管理システムは、データ検索とデータ更新とデータ削除とを含めデータベースファイルに対する一連の動作を管理する。データベース管理情報入出力装置は、データベース管理システムに対し任意の最新データの更新及び時系列にしたがって格納した更新済のデータの中の任意のデータの削除を指定し命令する。

また、従来技術として、セーフログ域と、バッファ域と、データベース格納域と、データベースアクセス部と、コミットレコード収集部と、バッファ制御部とを備え、ヒストリカルなデータ蓄積処理に適したデータベース管理処理方式がある。セーフログ域には、追加レコードのログが格納される。バッファ域には、コミットされたレコードが格納される。データベース格納域は、二次記憶上に設けられる。データベースアクセス部は、レコードの追加時に、セーフログ域に当該レコードのログデータを採取する。コミットレコード収集部は、コミット済みのログデータをセーフログ域から取り出し、バッファ域に格納する。バッファ制御部は、バッファ域の内容をトランザクションの処理とは非同期にデータベース格納域に書き出す。そして、このデータベース管理処理方式は、追加レコードのディスクロージャをバッファ域への転送で行う。

特開平７－７３０８６号公報 特開平４－２４７５０号公報 特開２００３－４４２６７号公報

記憶するデータの数が増大すると、全データを検索する手法では、検索性能が劣化し、リソース使用量が増大する。そこで、データを分類してデータベースに格納し、検索時には分類を用いて検索対象を絞り込むパーティショニング機能が求められる。

図１５は、パーティショニング機能を説明するための図である。図１５では、ＸＭＬデータをデータベースに記憶する場合を示す。利用者は、パーティション定義を用いてパーティションを定義する。図１５では、／ｒｏｏｔ／月度タグを用いてＸＭＬデータが分割管理される。すなわち、ＸＭＬデータは、＜月度＞が「１」であるデータ、＜月度＞が「２」であるデータ、・・・、＜月度＞が「１２」であるデータに分割されて管理される。

検索では、パーティションが指定される。図１５では、＜月度＞が「４」であることが検索式４で指定される。データベース管理システムは、検索式４からパーティションを特定し、特定したパーティションの範囲で検索を実行することができる。

しかしながら、パーティショニング機能を備えても、データの数が増えると、再起動時のＲｏｗＩＤヒドラ３６の復元に時間がかかり、再起動に時間がかかるという問題がある。図１６は、ＲｏｗＩＤヒドラ３６の復元を示す図である。図１６に示すように、データベース管理システムは、ＲｏｗＩＤファイル９をシーケンシャルに読み込み、ＲｏｗＩＤヒドラ３６を復元する。このため、追加によりデータベースに大量のレコードを格納した場合には、ＲｏｗＩＤヒドラ３６の復元に時間がかかる。特に、パーティショニング機能を備えた場合、パーティション単位の削除や移動により一度に大量のレコードを操作する運用が増え、ＲｏｗＩＤファイル９の操作情報の数が増大する。

本発明は、１つの側面では、ＲｏｗＩＤヒドラ３６の復元時間を短縮して再起動性能を向上することを目的とする。

１つの態様では、情報処理プログラムは、データを複数のデータ領域に分割してデータベースに記憶する処理をコンピュータに実行させる。また、前記情報処理プログラムは、前記データ領域の少なくとも一つに対する追加、更新、削除のいずれかの操作を受け付けた際に、前記受け付けた操作が、前記追加の操作である場合に、追加操作処理を前記コンピュータに実行させる。前記追加操作処理では、前記追加の操作に関する情報を前記追加の対象となるデータ領域に対応付けて記憶する。また、前記情報処理プログラムは、前記受け付けた操作が前記更新又は前記削除のいずれかの操作である場合に、前記更新又は削除の操作に関する情報を前記データに対応付けて記憶する処理を前記コンピュータに実行させる。そして、前記情報処理プログラムは、全データの格納位置を示す全格納位置情報を復元する際に、前記追加に関する復元処理を前記複数のデータ領域に関して並列で実行する処理を前記コンピュータに実行させる。前記追加に関する復元処理は、前記複数のデータ領域それぞれに対応付けられた操作に関する情報に基づいて実行される。そして、前記情報処理プログラムは、前記追加に関する復元処理の実行後に前記更新又は削除の操作に関する情報に基づいて、前記更新又は前記削除に関する復元処理を実行する処理を前記コンピュータに実行させる。

本発明は、１つの側面では、ＲｏｗＩＤヒドラ３６の復元時間を短縮して再起動性能を向上することができる。

図１は、実施例に係るデータベース管理システムが管理するのＲｏｗＩＤファイルを説明するための図である。 図２は、実施例に係るデータベース管理システムによるＲｏｗＩＤヒドラの復元を説明するための図である。 図３は、実施例に係るデータベース管理システムの構成を示す図である。 図４は、操作部による処理のフローを示すフローチャートである。 図５は、復元部による処理のフローを示すフローチャートである。 図６は、レコード追加の処理例を示す図である。 図７は、レコード更新の処理例を示す図である。 図８は、レコード削除の処理例を示す図である。 図９は、パーティション削除の処理例を示す図である。 図１０Ａは、追加命令の操作情報を用いたＲｏｗＩＤヒドラの復元を示す図である。 図１０Ｂは、更新命令の操作情報のＲｏｗＩＤヒドラへの反映を示す図である。 図１０Ｃは、削除命令の操作情報のＲｏｗＩＤヒドラへの反映を示す図である。 図１１Ａは、登録データの例を示す図である。 図１１Ｂは、レコード＃１の更新を示す図である。 図１１Ｃは、レコード＃２の更新を示す図である。 図１１Ｄは、東京パーティションの削除を示す図である。 図１２Ａは、追加命令の操作情報を用いた復元処理を示す図である。 図１２Ｂは、レコード＃１の更新命令の操作情報を用いた復元処理を示す第１の図である。 図１２Ｃは、レコード＃１の更新命令の操作情報を用いた復元処理を示す第２の図である。 図１２Ｄは、レコード＃２の更新命令の操作情報を用いた復元処理を示す第１の図である。 図１２Ｅは、レコード＃２の更新命令の操作情報を用いた復元処理を示す第２の図である。 図１３は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。 図１４は、ＲｏｗＩＤファイルを説明するための図である。 図１５は、パーティショニング機能を説明するための図である。 図１６は、ＲｏｗＩＤヒドラの復元を示す図である。

以下に、本願の開示する情報処理プログラム、情報処理方法及び情報処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

まず、実施例に係るデータベース管理システムが管理するＲｏｗＩＤファイルについて説明する。図１は、実施例に係るデータベース管理システムが管理するのＲｏｗＩＤファイルを説明するための図である。図１に示すように、実施例に係るデータベース管理システムは、蓄積データ３２をパーティションに分割して管理し、各パーティションに対応付けてパーティション毎ＲｏｗＩＤファイル３３を有する。

実施例に係るデータベース管理システムは、追加命令については操作情報をパーティション毎ＲｏｗＩＤファイル３３に格納する。例えば、パーティションＡに含まれるレコードの追加命令の操作情報はパーティションＡのパーティション毎ＲｏｗＩＤファイル３３に格納される。パーティションＢに含まれるレコードの追加命令の操作情報はパーティションＢのパーティション毎ＲｏｗＩＤファイル３３に格納される。

また、実施例に係るデータベース管理システムは、共通ＲｏｗＩＤファイル３４を有し、更新命令及び削除命令については共通ＲｏｗＩＤファイル３４に操作情報を格納する。また、実施例に係るデータベース管理システムは、更新命令については、更新後のパーティションの情報を所属パーティションとして操作情報に含める。なお、所属パーティションを用いてＲｏｗＩＤヒドラ３６の更新を制御する処理については後述する。

再起動時は、実施例に係るデータベース管理システムは、パーティション毎ＲｏｗＩＤファイル３３に基づいて並列にＲｏｗＩＤヒドラ３６を復元した後、共通ＲｏｗＩＤファイル３４に基づいてＲｏｗＩＤヒドラ３６を更新する。

図２は、実施例に係るデータベース管理システムによるＲｏｗＩＤヒドラ３６の復元を説明するための図である。図２に示すように、実施例に係るデータベース管理システムは、パーティション毎ＲｏｗＩＤファイル３３を並列に読み込み（ｔ１）、追加命令をもとに、ＲｏｗＩＤヒドラ３６を並列に復元する（ｔ２）。例えば、パーティション毎ＲｏｗＩＤファイル３３を読み込んでＲｏｗＩＤヒドラ３６を復元する処理を行うスレッドをパーティション毎に生成してマルチコアのＣＰＵにおいて実行することにより、並列にＲｏｗＩＤヒドラ３６を復元することが実現される。そして、実施例に係るデータベース管理システムは、共通ＲｏｗＩＤファイル３４を読み込んで（ｔ３）、ＲｏｗＩＤヒドラ３６に更新及び削除を反映する（ｔ４）。

このように、パーティション毎ＲｏｗＩＤファイル３３に順序性のない追加命令の操作情報のみを格納することで、実施例に係るデータベース管理システムは、複数のパーティション毎ＲｏｗＩＤファイル３３に基づくＲｏｗＩＤヒドラ３６の復元を並列に行う。このため、実施例に係るデータベース管理システムは、ＲｏｗＩＤヒドラ３６の復元時間を短縮することができる。

また、パーティション単位でレコードが削除された場合に、実施例に係るデータベース管理システムは、パーティションに対応するパーティション毎ＲｏｗＩＤファイル３３を削除することで、追加命令と削除命令の操作情報をなくすことができる。このため、実施例に係るデータベース管理システムは、操作情報の数を減らすことができ、ＲｏｗＩＤヒドラ３６の復元時間を短縮することができる。

次に、実施例に係るデータベース管理システムの構成について説明する。図３は、実施例に係るデータベース管理システムの構成を示す図である。図３に示すように、実施例に係るデータベース管理システム１は、管理装置２と３台の検索装置３とを有する。なお、データベース管理システム１は、１台以上であれば、３台以外の台数の検索装置３を有してよい。

管理装置２は、利用者から操作要求、検索要求などを受け付けて対応する処理を行い、処理結果を利用者に通知する情報処理装置である。検索装置３は、管理装置２の指示に基づいて、検索要求に含まれる検索条件を満たすＲｏｗＩＤの一覧を作成し、管理装置２に応答する。３台の検索装置３は並列に処理を行う。管理装置２は、検索装置３から受け取ったＲｏｗＩＤ一覧を用いて蓄積データ３２を検索し、利用者に応答する。

管理装置２は、制御部２１とデータ管理部２２とを有する。制御部２１は、利用者から操作要求、検索要求などを受け付け、受け付けた要求に対する処理を制御し、処理結果を利用者に通知する。

データ管理部２２は、制御部２１が受け付けた操作要求、検索要求などの処理を行う。データ管理部２２は、第１記憶部３０ａと、第２記憶部３０ｂと、操作部４３と、復元部４４とを有する。

第１記憶部３０ａは、パーティション定義３１と、蓄積データ３２と、パーティションの数のパーティション毎ＲｏｗＩＤファイル３３と、共通ＲｏｗＩＤファイル３４とを記憶する。蓄積データ３２は、パーティションに分割されて管理される。第１記憶部３０ａは、ＨＤＤ、ＳＳＤなどの不揮発性記憶装置に設けられる。

第２記憶部３０ｂは、ＲｏｗＩＤヒドラ３６とパーティション一覧３７を記憶する。パーティション一覧３７は、パーティションに関する情報である。第２記憶部３０ｂは、メモリ５１上に設けられる。

操作部４３は、操作要求を処理する。操作部４３は、追加部４３ａと、更新部４３ｂと、削除部４３ｃと、パーティション削除部４３ｄとを有する。

追加部４３ａは、追加されるレコードのパーティションを判定し、ＲｏｗＩＤを割り当て、レコードを第１記憶部３０ａに格納する。第１記憶部３０ａに格納されたレコードは、蓄積データ３２として管理される。また、追加部４３ａは、判定したパーティションのパーティション毎ＲｏｗＩＤファイル３３に操作情報を書き込む。また、追加部４３ａは、第１記憶部３０ａに格納したレコードの情報をＲｏｗＩＤヒドラ３６に追加する。

更新部４３ｂは、更新されるレコードが属するパーティションを判定し、更新レコードを第１記憶部３０ａに格納する。なお、更新前のレコードは別のタイミングで第１記憶部３０ａから削除される。また、更新部４３ｂは、共通ＲｏｗＩＤファイル３４に操作情報を書き込む。その際、更新部４３ｂは、操作情報に所属パーティションの情報を含める。また、更新部４３ｂは、第１記憶部３０ａに格納した更新レコードの情報でＲｏｗＩＤヒドラ３６を更新する。

削除部４３ｃは、共通ＲｏｗＩＤファイル３４に操作情報を書き込む。また、削除部４３ｃは、削除レコードの情報をＲｏｗＩＤヒドラ３６から削除する。なお、削除レコードは別のタイミングで第１記憶部３０ａから削除される。

パーティション削除部４３ｄは、パーティション削除要求で指定されたパーティションを蓄積データ３２から削除し、対応するパーティション毎ＲｏｗＩＤファイル３３を削除する。また、パーティション削除部４３ｄは、ＲｏｗＩＤヒドラ３６において対応する部分を削除する。

復元部４４は、データベースの再起動時にＲｏｗＩＤヒドラ３６を復元する。まず、復元部４４は、パーティション毎ＲｏｗＩＤファイル３３を読み込んでＲｏｗＩＤヒドラ３６を作成する処理をパーティション毎に並列に実行する。

そして、復元部４４は、共通ＲｏｗＩＤファイル３４を読み込み、更新命令の場合には、更新対象レコードのＲｏｗＩＤヒドラ葉の有無と更新対象レコードが所属するパーティションの有無に基づいて、ＲｏｗＩＤヒドラ３６に対する処理を行う。

具体的には、復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉があり、更新対象レコードが所属するパーティションがある場合には、ＲｏｗＩＤヒドラ葉を更新する。復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉があり、更新対象レコードが所属するパーティションがない場合には、ＲｏｗＩＤヒドラ３６からＲｏｗＩＤヒドラ葉を削除する。復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉がなく、更新対象レコードが所属するパーティションがある場合には、ＲｏｗＩＤヒドラ３６へＲｏｗＩＤヒドラ葉を追加する。復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉がなく、更新対象レコードが所属するパーティションがない場合には、ＲｏｗＩＤヒドラ３６に対する処理は行わない。

なお、復元部４４は、更新対象レコードが所属するパーティションの有無を操作情報に含まれる所属パーティションを用いて判定する。

復元部４４は、削除命令の場合には、ＲｏｗＩＤヒドラ３６から削除対象レコードのＲｏｗＩＤヒドラ葉を削除する。

次に、操作部４３による処理のフローについて説明する。図４は、操作部４３による処理のフローを示すフローチャートである。図４に示すように、操作部４３は、操作要求の命令区分を判定する（ステップＳ１）。

そして、命令区分が「追加」である場合には、操作部４３は、追加対象レコードが属するパーティションを判定し（ステップＳ２）、追加対象レコードにＲｏｗＩＤを割り当てる（ステップＳ３）。そして、操作部４３は、判定したパーティションに基づいて追加対象レコードを格納し（ステップＳ４）、操作情報を該当パーティションのパーティション毎ＲｏｗＩＤファイル３３へ書き込む（ステップＳ５）。そして、操作部４３は、追加対象レコードのＲｏｗＩＤヒドラ葉をＲｏｗＩＤヒドラ３６へ追加する（ステップＳ６）。

また、命令区分が「更新」である場合には、操作部４３は、更新対象レコードが属するパーティションを判定し（ステップＳ７）、判定したパーティションに基づいて更新対象レコードを格納する（ステップＳ８）。そして、操作部４３は、操作情報を共通ＲｏｗＩＤファイル３４へ書き込み（ステップＳ９）、更新対象レコードの情報でＲｏｗＩＤヒドラ葉を更新する（ステップＳ１０）。

また、命令区分が「削除」である場合には、操作部４３は、操作情報を共通ＲｏｗＩＤファイル３４へ書き込み（ステップＳ１１）、削除対象レコードのＲｏｗＩＤヒドラ葉をＲｏｗＩＤヒドラ３６から削除する（ステップＳ１２）。

このように、操作部４３が、命令区分が「追加」である場合に、操作情報を追加対象レコードが属するパーティションのパーティション毎ＲｏｗＩＤファイル３３へ書き込む。したがって、復元部４４は、追加命令に関するＲｏｗＩＤヒドラ３６の復元をパーティション毎に並列に行うことができる。

次に、復元部４４による処理のフローについて説明する。図５は、復元部４４による処理のフローを示すフローチャートである。図５に示すように、復元部４４は、パーティション毎ＲｏｗＩＤファイル３３を読み込み（ステップＳ２１）、ＲｏｗＩＤヒドラ３６を作成する（ステップＳ２２）。復元部４４は、ステップＳ２１とステップＳ２２の処理をパーティション毎に並列に行うことで、ＲｏｗＩＤヒドラ３６を作成する。

そして、復元部４４は、共通ＲｏｗＩＤファイル３４を読み込み（ステップＳ２３）、各操作情報について、以下のステップＳ２４～ステップＳ３１の処理を行う。復元部４４は、操作情報に含まれる命令区分を判定し（ステップＳ２４）、命令区分が「更新」である場合には、更新対象レコードのＲｏｗＩＤヒドラ葉の有無を判定する（ステップＳ２５）。

そして、更新対象レコードのＲｏｗＩＤヒドラ葉がある場合には、復元部４４は、更新対象レコードの所属パーティションの有無を判定する（ステップＳ２６）。そして、復元部４４は、更新対象レコードの所属パーティションがある場合には、ＲｏｗＩＤヒドラ葉を更新し（ステップＳ２７）、ない場合には、ＲｏｗＩＤヒドラ葉をＲｏｗＩＤヒドラ３６から削除する（ステップＳ２８）。

一方、更新対象レコードのＲｏｗＩＤヒドラ葉がない場合には、復元部４４は、更新対象レコードの所属パーティションの有無を判定する（ステップＳ２９）。そして、復元部４４は、更新対象レコードの所属パーティションがある場合には、ＲｏｗＩＤヒドラ葉をＲｏｗＩＤヒドラ３６へ追加し（ステップＳ３０）、ない場合には、ＲｏｗＩＤヒドラ３６に対する処理は行わない。

また、ステップＳ２４において、命令区分が「削除」である場合には、復元部４４は、削除対象レコードのＲｏｗＩＤヒドラ葉をＲｏｗＩＤヒドラ３６から削除する（ステップＳ３１）。

このように、復元部４４は、パーティション毎ＲｏｗＩＤファイル３３を読み込んでＲｏｗＩＤヒドラ３６を作成する処理をパーティション毎に並列に行うことで、ＲｏｗＩＤヒドラ３６の復元時間を短縮することができる。

次に、データ管理部２２による処理の例を図６～図１２Ｅを用いて説明する。なお、図６～図８、図１０Ａ～図１０Ｃ、図１２Ａ～図１２Ｅにおいて、Ｓ２、Ｓ３などは、図４及び図５に示したフローチャートのステップを示す。

図６は、レコード追加の処理例を示す図である。図６に示すように、データ管理部２２は、利用者が予め指定したパーティション定義３１と、追加しようとしているレコードをもとに、格納先のパーティションを判定する（ステップＳ２）。ここでは、追加レコードの／ｒｏｏｔ／月度タグの値は「４」であるため、格納先のパーティションは、４月パーティションに決定される。

そして、データ管理部２２は、追加レコードに対し、ＲｏｗＩＤを割り当てる（ステップＳ３）。ここでは、「４１」と「４２」が割り当てられる。そして、データ管理部２２は、追加レコードを読み込み、蓄積データ３２の４月パーティションに格納する（ステップＳ４）。

そして、データ管理部２２は、４月パーティションのパーティション毎ＲｏｗＩＤファイル３３に命令区分として「ＡＤＤ」、ＲｏｗＩＤとして「４１」、物理位置として格納先の格納位置情報を書き込む。また、データ管理部２２は、４月パーティションのパーティション毎ＲｏｗＩＤファイル３３に命令区分として「ＡＤＤ」、ＲｏｗＩＤとして「４２」、物理位置として格納先の格納位置情報を書き込む（ステップＳ５）。そして、データ管理部２２は、第２記憶部３０ｂ上のＲｏｗＩＤヒドラ３６に、ＲｏｗＩＤヒドラ葉（追加レコードの情報）を追加する（ステップＳ６）。

図７は、レコード更新の処理例を示す図である。図７に示すように、データ管理部２２は、利用者が予め指定したパーティション定義３１と、更新レコードをもとに、格納先のパーティションを判定する（ステップＳ７）。ここでは、／ｒｏｏｔ／月度タグの値は「４」であるため、格納先のパーティションは、４月パーティションに決定される。そして、データ管理部２２は、更新レコードを読み込み、蓄積データ３２の４月パーティションに格納する（ステップＳ８）。

そして、データ管理部２２は、共通ＲｏｗＩＤファイル３４に命令区分として「ＵＰＤ」、ＲｏｗＩＤとして「４１」、物理位置として格納先の格納位置情報、更新後の所属パーティションとして「４月」を書き込む（ステップＳ９）。そして、データ管理部２２は、第２記憶部３０ｂのＲｏｗＩＤヒドラ３６の更新レコードに対応するＲｏｗＩＤヒドラ葉を更新レコードの情報で更新する（ステップＳ１０）。ここでは、／ｒｏｏｔ／ＩＤタグの値が「ＡＡＡ」であるレコードのＲｏｗＩＤは「４１」であるので、ＲｏｗＩＤが「４１」であるＲｏｗＩＤヒドラ葉が更新される。

図８は、レコード削除の処理例を示す図である。図８に示すように、データ管理部２２は、共通ＲｏｗＩＤファイル３４に命令区分として「ＤＥＬ」、ＲｏｗＩＤとして「４１」を書き込む（ステップＳ１１）。そして、データ管理部２２は、第２記憶部３０ｂのＲｏｗＩＤヒドラ３６から削除レコードに対応するＲｏｗＩＤヒドラ葉を削除する（ステップＳ１２）。

図９は、パーティション削除の処理例を示す図である。図９に示すように、データ管理部２２は、１月パーティションの削除を指示されると、１月パーティションの蓄積データ３２を削除し（ｕ１）、１月パーティションのパーティション毎ＲｏｗＩＤファイル３３を削除する（ｕ２）。そして、データ管理部２２は、１月パーティションのＲｏｗＩＤヒドラ葉を削除する（ｕ３）。

図１０Ａ～図１０Ｃは、再起動時にＲｏｗＩＤヒドラ３６を復元する処理の例を示す図である。図１０Ａは、追加命令の操作情報を用いたＲｏｗＩＤヒドラ３６の復元を示す。図１０Ａに示すように、データ管理部２２は、２月、３月、４月のパーティション毎ＲｏｗＩＤファイル３３を読み込み（ステップＳ２１）、ＲｏｗＩＤヒドラ３６を作成する（ステップＳ２２）。このとき、データ管理部２２は、パーティション毎に並列にＲｏｗＩＤヒドラ３６を復元する。また、図９に示したように、１月パーティションは削除されたため、１月のパーティション毎ＲｏｗＩＤファイル３３はなく、ＲｏｗＩＤヒドラ３６において、１月のレコード情報は復元されない。

図１０Ｂは、更新命令の操作情報のＲｏｗＩＤヒドラ３６への反映を示す。図１０Ｂに示すように、データ管理部２２は、共通ＲｏｗＩＤファイル３４を読み込み（ステップＳ２３）、最初の操作情報の命令区分が「ＵＰＤ」であるので更新処理を行う。すなわち、データ管理部２２は、ＲｏｗＩＤが「４１」のレコードについては、ＲｏｗＩＤヒドラ葉があり、所属パーティションの「４月」があるので、ＲｏｗＩＤヒドラ葉を更新する（ステップＳ２７）。

図１０Ｃは、削除命令の操作情報のＲｏｗＩＤヒドラ３６への反映を示す。図１０Ｃに示すように、データ管理部２２は、共通ＲｏｗＩＤファイル３４を読み込み（ステップＳ２３）、次の操作情報の命令区分が「ＤＥＬ」であるので削除処理を行う。すなわち、データ管理部２２は、ＲｏｗＩＤが「４１」のＲｏｗＩＤヒドラ葉をＲｏｗＩＤヒドラ３６から削除する（ステップＳ３１）。

図１１Ａ～図１１Ｄは、パーティション移動をともなう更新例を示す図である。図１１Ａは、登録データの例を示す。図１１Ａに示すように、勤務地でパーティショニングされた従業員データにおいて、レコード＃１とレコード＃２が追加されると、蓄積データ３２の東京パーティションにレコード＃１とレコード＃２が格納される。また、東京パーティションのパーティション毎ＲｏｗＩＤファイル３３に、命令区分が「ＡＤＤ」でＲｏｗＩＤが「０１」と「０２」の２つの操作情報が格納される。

図１１Ｂは、レコード＃１の更新を示す。図１１Ｂに示すように、レコード＃１の勤務地が「東京」から「大阪」に変更されると、レコード＃１は、蓄積データ３２の東京パーティションから大阪パーティションに移動される。また、共通ＲｏｗＩＤファイル３４に命令区分が「ＵＰＤ」でＲｏｗＩＤが「０１」で所属パーティションが「大阪」の操作情報が格納される。

図１１Ｃは、レコード＃２の更新を示す。図１１Ｃに示すように、レコード＃２の勤務地が「東京」から「大阪」に変更され、その後、「大阪」から「東京」に変更される。すると、レコード＃２は、蓄積データ３２の東京パーティションから大阪パーティションに移動され、その後、大阪パーティションから東京パーティションに移動される。また、共通ＲｏｗＩＤファイル３４に、命令区分が「ＵＰＤ」でＲｏｗＩＤが「０２」で所属パーティションが「大阪」の操作情報と、命令区分が「ＵＰＤ」でＲｏｗＩＤが「０２」で所属パーティションが「東京」の操作情報が格納される。

図１１Ｄは、東京パーティションの削除を示す。図１１Ｄに示すように、東京パーティションが削除されると、東京パーティションの蓄積データ３２が削除され、東京パーティションのパーティション毎ＲｏｗＩＤファイル３３が削除される。

図１２Ａ～図１２Ｅは、図１１Ａ～図１１Ｄに示した更新が行われた場合のＲｏｗＩＤヒドラ３６の復元処理を示す図である。図１２Ａは、追加命令の操作情報を用いた復元処理を示す。図１２Ａに示すように、データ管理部２２は、パーティション毎ＲｏｗＩＤファイル３３を読み込む（ステップＳ２１）。ただし、東京パーティションのパーティション毎ＲｏｗＩＤファイル３３は削除されたため、データ管理部２２は、ＲｏｗＩＤが「０１」と「０２」のレコードについては、ＲｏｗＩＤヒドラ葉を復元しない。

図１２Ｂ及び図１２Ｃは、レコード＃１の更新命令の操作情報を用いた復元処理を示す。図１２Ｂに示すように、データ管理部２２は、共通ＲｏｗＩＤファイル３４を読み込み（ステップＳ２３）、最初の操作情報の命令区分が「ＵＰＤ」であるので更新処理を行う。すなわち、データ管理部２２は、ＲｏｗＩＤが「０１」のレコードについては、ＲｏｗＩＤヒドラ葉がなく、所属パーティションの「大阪」があるので、図１２Ｃに示すように、ＲｏｗＩＤヒドラ葉を追加する（ステップＳ３０）。

図１２Ｄ及び図１２Ｅは、レコード＃２の更新命令の操作情報を用いた復元処理を示す。図１２Ｄに示すように、データ管理部２２は、共通ＲｏｗＩＤファイル３４を読み込み（ステップＳ２３）、次の操作情報の命令区分が「ＵＰＤ」であるので更新処理を行う。すなわち、データ管理部２２は、ＲｏｗＩＤが「０２」のレコードについては、ＲｏｗＩＤヒドラ葉がなく、所属パーティションの「大阪」があるので、ＲｏｗＩＤヒドラ葉を追加する（ステップＳ３０）。

そして、図１２Ｅに示すように、データ管理部２２は、共通ＲｏｗＩＤファイル３４を読み込み（ステップＳ２３）、次の操作情報の命令区分が「ＵＰＤ」であるので更新処理を行う。すなわち、データ管理部２２は、ＲｏｗＩＤが「０２」のレコードについては、ＲｏｗＩＤヒドラ葉があり、所属パーティションの「東京」はないので、ＲｏｗＩＤヒドラ葉を削除する（ステップＳ３０）。

上述してきたように、実施例では、追加部４３ａが、追加命令の操作情報をパーティション毎ＲｏｗＩＤファイル３３に書き込み、更新部４３ｂ及び削除部４３ｃが、それぞれ更新命令及び削除命令の操作情報を共通ＲｏｗＩＤファイル３４に書き込む。そして、復元部４４が、ＲｏｗＩＤヒドラ３６を復元する際に、パーティション毎ＲｏｗＩＤファイル３３を読み込んでＲｏｗＩＤヒドラ３６を作成する処理をパーティション毎に並列に行う。そして、復元部４４は、共通ＲｏｗＩＤファイル３４を読み込んで、更新命令及び削除命令をＲｏｗＩＤヒドラ３６に反映する。したがって、データ管理部２２は、ＲｏｗＩＤヒドラ３６の復元時間を短縮して再起動性能を向上することができる。

また、実施例では、パーティション削除部４３ｄは、パーティション削除要求で指定されたパーティションに対応するパーティション毎ＲｏｗＩＤファイル３３を削除するので、操作情報の数を減らし、ＲｏｗＩＤヒドラ３６の復元時間を短縮することができる。

また、実施例では、更新命令の操作情報は所属パーティションを含み、復元部４４は、所属パーティションを用いてＲｏｗＩＤヒドラ３６を復元する。具体的には、復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉があり、更新対象レコードが所属するパーティションがある場合には、ＲｏｗＩＤヒドラ葉を更新する。復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉があり、更新対象レコードが所属するパーティションがない場合には、ＲｏｗＩＤヒドラ３６からＲｏｗＩＤヒドラ葉を削除する。復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉がなく、更新対象レコードが所属するパーティションがある場合には、ＲｏｗＩＤヒドラ３６へＲｏｗＩＤヒドラ葉を追加する。復元部４４は、更新対象レコードのＲｏｗＩＤヒドラ葉がなく、更新対象レコードが所属するパーティションがない場合には、ＲｏｗＩＤヒドラ３６に対する処理は行わない。したがって、復元部４４は、パーティションの移動をともなう更新やパーティションの削除が行われた場合にも、更新命令の操作情報に基づいて、当該更新や削除と整合のとれたＲｏｗＩＤヒドラ３６を復元することができる。

なお、実施例では、管理装置２について説明したが、管理装置２が有する構成をソフトウェアによって実現することで、同様の機能を有する管理プログラムを得ることができる。そこで、管理プログラムを実行するコンピュータについて説明する。

図１３は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。図１３に示すように、コンピュータ５０は、メモリ５１と、ＣＰＵ（Central Processing Unit）５２と、ＬＡＮ（Local Area Network）インタフェース５３と、ＨＤＤ（Hard Disk Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input Output）５５と、ＤＶＩ（Digital Visual Interface）５６と、ＯＤＤ（Optical Disk Drive）５７とを有する。

メモリ５１は、プログラムやプログラムの実行途中結果等を記憶するメモリである。ＣＰＵ５２は、メモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。

ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボード等の入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤの読み書きを行う装置である。

ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low Pin Count）によりＣＰＵ５２に接続される。

そして、コンピュータ５０において実行される管理プログラムは、コンピュータ５０により読み出し可能な記録媒体の一例であるＤＶＤに記憶され、ＯＤＤ５７によってＤＶＤから読み出されてコンピュータ５０にインストールされる。あるいは、管理プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベース等に記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされた管理プログラムは、ＨＤＤ５４に記憶され、メモリ５１に読み出されてＣＰＵ５２によって実行される。

また、実施例では、ＸＭＬデータを管理する場合について説明したが、管理装置２は、他のデータを管理してもよい。また、実施例では、ＲｏｗＩＤヒドラ３６を用いる場合について説明したが、管理装置２は、ＲｏｗＩＤとレコードの物理位置を対応付ける情報であれば、他のデータ構造を用いてもよい。

１ データベース管理システム
２ 管理装置
３ 検索装置
４ 検索式
９ ＲｏｗＩＤファイル
２１ 制御部
２２ データ管理部
３０ａ 第１記憶部
３０ｂ 第２記憶部
３１ パーティション定義
３２ 蓄積データ
３３ パーティション毎ＲｏｗＩＤファイル
３４ 共通ＲｏｗＩＤファイル
３６ ＲｏｗＩＤヒドラ
３７ パーティション一覧
４３ 操作部
４３ａ 追加部
４３ｂ 更新部
４３ｃ 削除部
４３ｄ パーティション削除部
４４ 復元部
５０ コンピュータ
５１ メモリ
５２ ＣＰＵ
５３ ＬＡＮインタフェース
５４ ＨＤＤ
５５ スーパーＩＯ
５６ ＤＶＩ
５７ ＯＤＤ

Claims (6)

1. データを複数のデータ領域に分割してデータベースに記憶し、
   前記データ領域の少なくとも一つに対する追加、更新、削除のいずれかの操作を受け付けた際に、前記受け付けた操作が、前記追加の操作である場合に、前記追加の操作に関する情報を前記追加の対象となるデータ領域に対応付けて記憶し、
   前記受け付けた操作が前記更新又は前記削除のいずれかの操作である場合に、前記更新又は削除の操作に関する情報を前記データに対応付けて記憶し、
   全データの格納位置を示す全格納位置情報を復元する際に、前記複数のデータ領域それぞれに対応付けられた操作に関する情報に基づいて、前記追加に関する復元処理を前記複数のデータ領域に関して並列で実行し、
   前記追加に関する復元処理の実行後に前記更新又は削除の操作に関する情報に基づいて、前記更新又は前記削除に関する復元処理を実行する、
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。
2. 前記複数のデータ領域に含まれるあるデータ領域の削除が行われた際に、前記データ領域に対応付けられた操作に関する情報を削除する処理を前記コンピュータに実行させることを特徴とする請求項１に記載の情報処理プログラム。
3. 前記更新の操作に関する情報は、更新後のデータ領域を識別するデータ領域識別情報を含み、
   前記更新に関する復元処理は、前記データ領域識別情報を用いることを特徴とする請求項１又は２に記載の情報処理プログラム。
4. 前記更新に関する復元処理は、前記全格納位置情報において、更新対象データに対応する格納位置情報が復元されている場合には、前記データ領域識別情報で識別されるデータ領域があれば前記格納位置情報を更新し、前記データ領域識別情報で識別されるデータ領域がなければ前記格納位置情報を削除し、更新対象データに対応するデータ情報が復元されていない場合には、前記データ領域識別情報で識別されるデータ領域があれば前記格納位置情報を追加することを特徴とする請求項３に記載の情報処理プログラム。
5. データを複数のデータ領域に分割してデータベースに記憶し、
   前記データ領域の少なくとも一つに対する追加、更新、削除のいずれかの操作を受け付けた際に、前記受け付けた操作が、前記追加の操作である場合に、前記追加の操作に関する情報を前記追加の対象となるデータ領域に対応付けて記憶し、
   前記受け付けた操作が前記更新又は前記削除のいずれかの操作である場合に、前記更新又は削除の操作に関する情報を前記データに対応付けて記憶し、
   全データの格納位置を示す全格納位置情報を復元する際に、前記複数のデータ領域それぞれに対応付けられた操作に関する情報に基づいて、前記追加に関する復元処理を前記複数のデータ領域に関して並列で実行し、
   前記追加に関する復元処理の実行後に前記更新又は削除の操作に関する情報に基づいて、前記更新又は前記削除に関する復元処理を実行する、
   処理をコンピュータが実行することを特徴とする情報処理方法。
6. データを複数のデータ領域に分割して記憶するデータベースと、
   前記データ領域の少なくとも一つに対する追加、更新、削除のいずれかの操作が受け付けられた際に、前記受け付けられた操作が、前記追加の操作である場合に、前記追加の操作に関する情報を前記追加の対象となるデータ領域に対応付けて格納する追加部と、
   前記受け付けられた操作が前記更新又は前記削除のいずれかの操作である場合に、前記更新又は削除の操作に関する情報を前記データに対応付けて格納する更新削除部と、
   全データの格納位置を示す全格納位置情報を復元する際に、前記複数のデータ領域それぞれに対応付けられた操作に関する情報に基づいて、前記追加に関する復元処理を前記複数のデータ領域に関して並列で実行し、前記追加に関する復元処理の実行後に前記更新又は削除の操作に関する情報に基づいて、前記更新又は前記削除に関する復元処理を実行する復元部と、
   を有することを特徴とする情報処理装置。

Images