Processing

Please wait...

Settings

Settings

Goto Application

1. WO2020194403 - INFORMATION PROCESSING PROGRAM, INFORMATION PROCESSING METHOD, AND INFORMATION PROCESSING DEVICE

Document

明 細 書

発明の名称 情報処理プログラム、情報処理方法及び情報処理装置

技術分野

0001  

背景技術

0002   0003   0004   0005   0006   0007  

先行技術文献

特許文献

0008  

発明の概要

発明が解決しようとする課題

0009   0010   0011   0012   0013  

課題を解決するための手段

0014  

発明の効果

0015  

図面の簡単な説明

0016  

発明を実施するための形態

0017  

実施例

0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080  

符号の説明

0081  

請求の範囲

1   2   3   4   5   6   7   8   9   10  

図面

1   2   3   4   5   6   7   8   9   10A   10B   10C   11A   11B   11C   11D   12A   12B   12C   12D   12E   13   14   15   16  

明 細 書

発明の名称 : 情報処理プログラム、情報処理方法及び情報処理装置

技術分野

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

背景技術

[0002]
 XML(Extensible Markup Language)データなどのデータをレコードとして記憶するデータベースは、レコードに対する操作を記録するRowIDファイルを保持する。図14は、RowIDファイルを説明するための図である。図14に示すように、レコードに対する追加、更新又は削除の操作が行われると、操作情報がRowIDファイル9に追記される。操作情報には、命令区分、RowID、レコードの物理位置などが含まれる。命令区分は、「追加(ADD)」、「更新(UPD)」又は「削除(DEL)」である。RowIDは、操作を識別する識別子である。レコードの物理位置は、レコードがHDD(Hard Disk Drive)やSSD(Solid State Drive)に格納される物理的な格納位置情報である。
[0003]
 RowIDファイル9は、データベースの再起動時に、各レコードの最新状態をメモリ51上に保持するRowIDヒドラ36を復元するために用いられる。RowIDヒドラ36は、RowIDに関する木構造のデータであり、木の葉の部分はRowIDヒドラ葉と呼ばれ、レコードの物理位置を含むレコード情報を記憶する。RowIDヒドラ36は、RowIDからレコードの物理位置を取得する際に用いられる。
[0004]
 例えば、RowIDを000~999までの数とし、RowIDヒドラ36をルート(root)を除いて3階層とすると、第1階層はRowIDの百の桁の数の0~9それぞれに対応する10個のノードで構成される。第2階層は、第1階層の各ノードに対してRowIDの十の桁の数の0~9それぞれに対応する合計100個のノードで構成される。第3階層すなわち葉の階層は、第2階層の各ノードに対してRowIDの一の桁の数の0~9それぞれに対応する合計1000個のノードで構成される。なお、RowIDヒドラ36の詳細については、特開2003-44267に記載されている。
[0005]
 図14に示すRowIDファイル9の例では、RowIDが「#1」であるレコードとRowIDが「#2」であるレコードがデータベースに追加され、RowIDが「#2」であるレコードが更新され、RowIDが「#1」であるレコードが削除される。このRowIDファイル9が再起動時に読み込まれると、RowIDが「#1」であるレコードの情報とRowIDが「#2」であるレコードの情報を記憶するRowIDヒドラ葉がRowIDヒドラ36に作成される。そして、RowIDが「#2」であるレコードの情報を記憶するRowIDヒドラ葉が更新され、RowIDが「#1」であるレコードの情報を記憶するRowIDヒドラ葉が削除される。
[0006]
 なお、過去から現在まで同一の起源を持つデータを更新する毎に更新済のデータを時系列にしたがって格納するデータベースファイルから不要な時系列データを削除する際、自動的に必要時点の時系列データを同一データベースファイルに保持する従来技術がある。この従来技術のシステムは、データベースファイルとデータベース管理システムとデータベース管理情報入出力装置を備える。データベース管理システムは、データ検索とデータ更新とデータ削除とを含めデータベースファイルに対する一連の動作を管理する。データベース管理情報入出力装置は、データベース管理システムに対し任意の最新データの更新及び時系列にしたがって格納した更新済のデータの中の任意のデータの削除を指定し命令する。
[0007]
 また、従来技術として、セーフログ域と、バッファ域と、データベース格納域と、データベースアクセス部と、コミットレコード収集部と、バッファ制御部とを備え、ヒストリカルなデータ蓄積処理に適したデータベース管理処理方式がある。セーフログ域には、追加レコードのログが格納される。バッファ域には、コミットされたレコードが格納される。データベース格納域は、二次記憶上に設けられる。データベースアクセス部は、レコードの追加時に、セーフログ域に当該レコードのログデータを採取する。コミットレコード収集部は、コミット済みのログデータをセーフログ域から取り出し、バッファ域に格納する。バッファ制御部は、バッファ域の内容をトランザクションの処理とは非同期にデータベース格納域に書き出す。そして、このデータベース管理処理方式は、追加レコードのディスクロージャをバッファ域への転送で行う。

先行技術文献

特許文献

[0008]
特許文献1 : 特開平7-73086号公報
特許文献2 : 特開平4-24750号公報
特許文献3 : 特開2003-44267号公報

発明の概要

発明が解決しようとする課題

[0009]
 記憶するデータの数が増大すると、全データを検索する手法では、検索性能が劣化し、リソース使用量が増大する。そこで、データを分類してデータベースに格納し、検索時には分類を用いて検索対象を絞り込むパーティショニング機能が求められる。
[0010]
 図15は、パーティショニング機能を説明するための図である。図15では、XMLデータをデータベースに記憶する場合を示す。利用者は、パーティション定義を用いてパーティションを定義する。図15では、/root/月度タグを用いてXMLデータが分割管理される。すなわち、XMLデータは、<月度>が「1」であるデータ、<月度>が「2」であるデータ、・・・、<月度>が「12」であるデータに分割されて管理される。
[0011]
 検索では、パーティションが指定される。図15では、<月度>が「4」であることが検索式4で指定される。データベース管理システムは、検索式4からパーティションを特定し、特定したパーティションの範囲で検索を実行することができる。
[0012]
 しかしながら、パーティショニング機能を備えても、データの数が増えると、再起動時のRowIDヒドラ36の復元に時間がかかり、再起動に時間がかかるという問題がある。図16は、RowIDヒドラ36の復元を示す図である。図16に示すように、データベース管理システムは、RowIDファイル9をシーケンシャルに読み込み、RowIDヒドラ36を復元する。このため、追加によりデータベースに大量のレコードを格納した場合には、RowIDヒドラ36の復元に時間がかかる。特に、パーティショニング機能を備えた場合、パーティション単位の削除や移動により一度に大量のレコードを操作する運用が増え、RowIDファイル9の操作情報の数が増大する。
[0013]
 本発明は、1つの側面では、RowIDヒドラ36の復元時間を短縮して再起動性能を向上することを目的とする。

課題を解決するための手段

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

発明の効果

[0015]
 本発明は、1つの側面では、RowIDヒドラ36の復元時間を短縮して再起動性能を向上することができる。

図面の簡単な説明

[0016]
[図1] 図1は、実施例に係るデータベース管理システムが管理するのRowIDファイルを説明するための図である。
[図2] 図2は、実施例に係るデータベース管理システムによるRowIDヒドラの復元を説明するための図である。
[図3] 図3は、実施例に係るデータベース管理システムの構成を示す図である。
[図4] 図4は、操作部による処理のフローを示すフローチャートである。
[図5] 図5は、復元部による処理のフローを示すフローチャートである。
[図6] 図6は、レコード追加の処理例を示す図である。
[図7] 図7は、レコード更新の処理例を示す図である。
[図8] 図8は、レコード削除の処理例を示す図である。
[図9] 図9は、パーティション削除の処理例を示す図である。
[図10A] 図10Aは、追加命令の操作情報を用いたRowIDヒドラの復元を示す図である。
[図10B] 図10Bは、更新命令の操作情報のRowIDヒドラへの反映を示す図である。
[図10C] 図10Cは、削除命令の操作情報のRowIDヒドラへの反映を示す図である。
[図11A] 図11Aは、登録データの例を示す図である。
[図11B] 図11Bは、レコード#1の更新を示す図である。
[図11C] 図11Cは、レコード#2の更新を示す図である。
[図11D] 図11Dは、東京パーティションの削除を示す図である。
[図12A] 図12Aは、追加命令の操作情報を用いた復元処理を示す図である。
[図12B] 図12Bは、レコード#1の更新命令の操作情報を用いた復元処理を示す第1の図である。
[図12C] 図12Cは、レコード#1の更新命令の操作情報を用いた復元処理を示す第2の図である。
[図12D] 図12Dは、レコード#2の更新命令の操作情報を用いた復元処理を示す第1の図である。
[図12E] 図12Eは、レコード#2の更新命令の操作情報を用いた復元処理を示す第2の図である。
[図13] 図13は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。
[図14] 図14は、RowIDファイルを説明するための図である。
[図15] 図15は、パーティショニング機能を説明するための図である。
[図16] 図16は、RowIDヒドラの復元を示す図である。

発明を実施するための形態

[0017]
 以下に、本願の開示する情報処理プログラム、情報処理方法及び情報処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
実施例
[0018]
 まず、実施例に係るデータベース管理システムが管理するRowIDファイルについて説明する。図1は、実施例に係るデータベース管理システムが管理するのRowIDファイルを説明するための図である。図1に示すように、実施例に係るデータベース管理システムは、蓄積データ32をパーティションに分割して管理し、各パーティションに対応付けてパーティション毎RowIDファイル33を有する。
[0019]
 実施例に係るデータベース管理システムは、追加命令については操作情報をパーティション毎RowIDファイル33に格納する。例えば、パーティションAに含まれるレコードの追加命令の操作情報はパーティションAのパーティション毎RowIDファイル33に格納される。パーティションBに含まれるレコードの追加命令の操作情報はパーティションBのパーティション毎RowIDファイル33に格納される。
[0020]
 また、実施例に係るデータベース管理システムは、共通RowIDファイル34を有し、更新命令及び削除命令については共通RowIDファイル34に操作情報を格納する。また、実施例に係るデータベース管理システムは、更新命令については、更新後のパーティションの情報を所属パーティションとして操作情報に含める。なお、所属パーティションを用いてRowIDヒドラ36の更新を制御する処理については後述する。
[0021]
 再起動時は、実施例に係るデータベース管理システムは、パーティション毎RowIDファイル33に基づいて並列にRowIDヒドラ36を復元した後、共通RowIDファイル34に基づいてRowIDヒドラ36を更新する。
[0022]
 図2は、実施例に係るデータベース管理システムによるRowIDヒドラ36の復元を説明するための図である。図2に示すように、実施例に係るデータベース管理システムは、パーティション毎RowIDファイル33を並列に読み込み(t1)、追加命令をもとに、RowIDヒドラ36を並列に復元する(t2)。例えば、パーティション毎RowIDファイル33を読み込んでRowIDヒドラ36を復元する処理を行うスレッドをパーティション毎に生成してマルチコアのCPUにおいて実行することにより、並列にRowIDヒドラ36を復元することが実現される。そして、実施例に係るデータベース管理システムは、共通RowIDファイル34を読み込んで(t3)、RowIDヒドラ36に更新及び削除を反映する(t4)。
[0023]
 このように、パーティション毎RowIDファイル33に順序性のない追加命令の操作情報のみを格納することで、実施例に係るデータベース管理システムは、複数のパーティション毎RowIDファイル33に基づくRowIDヒドラ36の復元を並列に行う。このため、実施例に係るデータベース管理システムは、RowIDヒドラ36の復元時間を短縮することができる。
[0024]
 また、パーティション単位でレコードが削除された場合に、実施例に係るデータベース管理システムは、パーティションに対応するパーティション毎RowIDファイル33を削除することで、追加命令と削除命令の操作情報をなくすことができる。このため、実施例に係るデータベース管理システムは、操作情報の数を減らすことができ、RowIDヒドラ36の復元時間を短縮することができる。
[0025]
 次に、実施例に係るデータベース管理システムの構成について説明する。図3は、実施例に係るデータベース管理システムの構成を示す図である。図3に示すように、実施例に係るデータベース管理システム1は、管理装置2と3台の検索装置3とを有する。なお、データベース管理システム1は、1台以上であれば、3台以外の台数の検索装置3を有してよい。
[0026]
 管理装置2は、利用者から操作要求、検索要求などを受け付けて対応する処理を行い、処理結果を利用者に通知する情報処理装置である。検索装置3は、管理装置2の指示に基づいて、検索要求に含まれる検索条件を満たすRowIDの一覧を作成し、管理装置2に応答する。3台の検索装置3は並列に処理を行う。管理装置2は、検索装置3から受け取ったRowID一覧を用いて蓄積データ32を検索し、利用者に応答する。
[0027]
 管理装置2は、制御部21とデータ管理部22とを有する。制御部21は、利用者から操作要求、検索要求などを受け付け、受け付けた要求に対する処理を制御し、処理結果を利用者に通知する。
[0028]
 データ管理部22は、制御部21が受け付けた操作要求、検索要求などの処理を行う。データ管理部22は、第1記憶部30aと、第2記憶部30bと、操作部43と、復元部44とを有する。
[0029]
 第1記憶部30aは、パーティション定義31と、蓄積データ32と、パーティションの数のパーティション毎RowIDファイル33と、共通RowIDファイル34とを記憶する。蓄積データ32は、パーティションに分割されて管理される。第1記憶部30aは、HDD、SSDなどの不揮発性記憶装置に設けられる。
[0030]
 第2記憶部30bは、RowIDヒドラ36とパーティション一覧37を記憶する。パーティション一覧37は、パーティションに関する情報である。第2記憶部30bは、メモリ51上に設けられる。
[0031]
 操作部43は、操作要求を処理する。操作部43は、追加部43aと、更新部43bと、削除部43cと、パーティション削除部43dとを有する。
[0032]
 追加部43aは、追加されるレコードのパーティションを判定し、RowIDを割り当て、レコードを第1記憶部30aに格納する。第1記憶部30aに格納されたレコードは、蓄積データ32として管理される。また、追加部43aは、判定したパーティションのパーティション毎RowIDファイル33に操作情報を書き込む。また、追加部43aは、第1記憶部30aに格納したレコードの情報をRowIDヒドラ36に追加する。
[0033]
 更新部43bは、更新されるレコードが属するパーティションを判定し、更新レコードを第1記憶部30aに格納する。なお、更新前のレコードは別のタイミングで第1記憶部30aから削除される。また、更新部43bは、共通RowIDファイル34に操作情報を書き込む。その際、更新部43bは、操作情報に所属パーティションの情報を含める。また、更新部43bは、第1記憶部30aに格納した更新レコードの情報でRowIDヒドラ36を更新する。
[0034]
 削除部43cは、共通RowIDファイル34に操作情報を書き込む。また、削除部43cは、削除レコードの情報をRowIDヒドラ36から削除する。なお、削除レコードは別のタイミングで第1記憶部30aから削除される。
[0035]
 パーティション削除部43dは、パーティション削除要求で指定されたパーティションを蓄積データ32から削除し、対応するパーティション毎RowIDファイル33を削除する。また、パーティション削除部43dは、RowIDヒドラ36において対応する部分を削除する。
[0036]
 復元部44は、データベースの再起動時にRowIDヒドラ36を復元する。まず、復元部44は、パーティション毎RowIDファイル33を読み込んでRowIDヒドラ36を作成する処理をパーティション毎に並列に実行する。
[0037]
 そして、復元部44は、共通RowIDファイル34を読み込み、更新命令の場合には、更新対象レコードのRowIDヒドラ葉の有無と更新対象レコードが所属するパーティションの有無に基づいて、RowIDヒドラ36に対する処理を行う。
[0038]
 具体的には、復元部44は、更新対象レコードのRowIDヒドラ葉があり、更新対象レコードが所属するパーティションがある場合には、RowIDヒドラ葉を更新する。復元部44は、更新対象レコードのRowIDヒドラ葉があり、更新対象レコードが所属するパーティションがない場合には、RowIDヒドラ36からRowIDヒドラ葉を削除する。復元部44は、更新対象レコードのRowIDヒドラ葉がなく、更新対象レコードが所属するパーティションがある場合には、RowIDヒドラ36へRowIDヒドラ葉を追加する。復元部44は、更新対象レコードのRowIDヒドラ葉がなく、更新対象レコードが所属するパーティションがない場合には、RowIDヒドラ36に対する処理は行わない。
[0039]
 なお、復元部44は、更新対象レコードが所属するパーティションの有無を操作情報に含まれる所属パーティションを用いて判定する。
[0040]
 復元部44は、削除命令の場合には、RowIDヒドラ36から削除対象レコードのRowIDヒドラ葉を削除する。
[0041]
 次に、操作部43による処理のフローについて説明する。図4は、操作部43による処理のフローを示すフローチャートである。図4に示すように、操作部43は、操作要求の命令区分を判定する(ステップS1)。
[0042]
 そして、命令区分が「追加」である場合には、操作部43は、追加対象レコードが属するパーティションを判定し(ステップS2)、追加対象レコードにRowIDを割り当てる(ステップS3)。そして、操作部43は、判定したパーティションに基づいて追加対象レコードを格納し(ステップS4)、操作情報を該当パーティションのパーティション毎RowIDファイル33へ書き込む(ステップS5)。そして、操作部43は、追加対象レコードのRowIDヒドラ葉をRowIDヒドラ36へ追加する(ステップS6)。
[0043]
 また、命令区分が「更新」である場合には、操作部43は、更新対象レコードが属するパーティションを判定し(ステップS7)、判定したパーティションに基づいて更新対象レコードを格納する(ステップS8)。そして、操作部43は、操作情報を共通RowIDファイル34へ書き込み(ステップS9)、更新対象レコードの情報でRowIDヒドラ葉を更新する(ステップS10)。
[0044]
 また、命令区分が「削除」である場合には、操作部43は、操作情報を共通RowIDファイル34へ書き込み(ステップS11)、削除対象レコードのRowIDヒドラ葉をRowIDヒドラ36から削除する(ステップS12)。
[0045]
 このように、操作部43が、命令区分が「追加」である場合に、操作情報を追加対象レコードが属するパーティションのパーティション毎RowIDファイル33へ書き込む。したがって、復元部44は、追加命令に関するRowIDヒドラ36の復元をパーティション毎に並列に行うことができる。
[0046]
 次に、復元部44による処理のフローについて説明する。図5は、復元部44による処理のフローを示すフローチャートである。図5に示すように、復元部44は、パーティション毎RowIDファイル33を読み込み(ステップS21)、RowIDヒドラ36を作成する(ステップS22)。復元部44は、ステップS21とステップS22の処理をパーティション毎に並列に行うことで、RowIDヒドラ36を作成する。
[0047]
 そして、復元部44は、共通RowIDファイル34を読み込み(ステップS23)、各操作情報について、以下のステップS24~ステップS31の処理を行う。復元部44は、操作情報に含まれる命令区分を判定し(ステップS24)、命令区分が「更新」である場合には、更新対象レコードのRowIDヒドラ葉の有無を判定する(ステップS25)。
[0048]
 そして、更新対象レコードのRowIDヒドラ葉がある場合には、復元部44は、更新対象レコードの所属パーティションの有無を判定する(ステップS26)。そして、復元部44は、更新対象レコードの所属パーティションがある場合には、RowIDヒドラ葉を更新し(ステップS27)、ない場合には、RowIDヒドラ葉をRowIDヒドラ36から削除する(ステップS28)。
[0049]
 一方、更新対象レコードのRowIDヒドラ葉がない場合には、復元部44は、更新対象レコードの所属パーティションの有無を判定する(ステップS29)。そして、復元部44は、更新対象レコードの所属パーティションがある場合には、RowIDヒドラ葉をRowIDヒドラ36へ追加し(ステップS30)、ない場合には、RowIDヒドラ36に対する処理は行わない。
[0050]
 また、ステップS24において、命令区分が「削除」である場合には、復元部44は、削除対象レコードのRowIDヒドラ葉をRowIDヒドラ36から削除する(ステップS31)。
[0051]
 このように、復元部44は、パーティション毎RowIDファイル33を読み込んでRowIDヒドラ36を作成する処理をパーティション毎に並列に行うことで、RowIDヒドラ36の復元時間を短縮することができる。
[0052]
 次に、データ管理部22による処理の例を図6~図12Eを用いて説明する。なお、図6~図8、図10A~図10C、図12A~図12Eにおいて、S2、S3などは、図4及び図5に示したフローチャートのステップを示す。
[0053]
 図6は、レコード追加の処理例を示す図である。図6に示すように、データ管理部22は、利用者が予め指定したパーティション定義31と、追加しようとしているレコードをもとに、格納先のパーティションを判定する(ステップS2)。ここでは、追加レコードの/root/月度タグの値は「4」であるため、格納先のパーティションは、4月パーティションに決定される。
[0054]
 そして、データ管理部22は、追加レコードに対し、RowIDを割り当てる(ステップS3)。ここでは、「41」と「42」が割り当てられる。そして、データ管理部22は、追加レコードを読み込み、蓄積データ32の4月パーティションに格納する(ステップS4)。
[0055]
 そして、データ管理部22は、4月パーティションのパーティション毎RowIDファイル33に命令区分として「ADD」、RowIDとして「41」、物理位置として格納先の格納位置情報を書き込む。また、データ管理部22は、4月パーティションのパーティション毎RowIDファイル33に命令区分として「ADD」、RowIDとして「42」、物理位置として格納先の格納位置情報を書き込む(ステップS5)。そして、データ管理部22は、第2記憶部30b上のRowIDヒドラ36に、RowIDヒドラ葉(追加レコードの情報)を追加する(ステップS6)。
[0056]
 図7は、レコード更新の処理例を示す図である。図7に示すように、データ管理部22は、利用者が予め指定したパーティション定義31と、更新レコードをもとに、格納先のパーティションを判定する(ステップS7)。ここでは、/root/月度タグの値は「4」であるため、格納先のパーティションは、4月パーティションに決定される。そして、データ管理部22は、更新レコードを読み込み、蓄積データ32の4月パーティションに格納する(ステップS8)。
[0057]
 そして、データ管理部22は、共通RowIDファイル34に命令区分として「UPD」、RowIDとして「41」、物理位置として格納先の格納位置情報、更新後の所属パーティションとして「4月」を書き込む(ステップS9)。そして、データ管理部22は、第2記憶部30bのRowIDヒドラ36の更新レコードに対応するRowIDヒドラ葉を更新レコードの情報で更新する(ステップS10)。ここでは、/root/IDタグの値が「AAA」であるレコードのRowIDは「41」であるので、RowIDが「41」であるRowIDヒドラ葉が更新される。
[0058]
 図8は、レコード削除の処理例を示す図である。図8に示すように、データ管理部22は、共通RowIDファイル34に命令区分として「DEL」、RowIDとして「41」を書き込む(ステップS11)。そして、データ管理部22は、第2記憶部30bのRowIDヒドラ36から削除レコードに対応するRowIDヒドラ葉を削除する(ステップS12)。
[0059]
 図9は、パーティション削除の処理例を示す図である。図9に示すように、データ管理部22は、1月パーティションの削除を指示されると、1月パーティションの蓄積データ32を削除し(u1)、1月パーティションのパーティション毎RowIDファイル33を削除する(u2)。そして、データ管理部22は、1月パーティションのRowIDヒドラ葉を削除する(u3)。
[0060]
 図10A~図10Cは、再起動時にRowIDヒドラ36を復元する処理の例を示す図である。図10Aは、追加命令の操作情報を用いたRowIDヒドラ36の復元を示す。図10Aに示すように、データ管理部22は、2月、3月、4月のパーティション毎RowIDファイル33を読み込み(ステップS21)、RowIDヒドラ36を作成する(ステップS22)。このとき、データ管理部22は、パーティション毎に並列にRowIDヒドラ36を復元する。また、図9に示したように、1月パーティションは削除されたため、1月のパーティション毎RowIDファイル33はなく、RowIDヒドラ36において、1月のレコード情報は復元されない。
[0061]
 図10Bは、更新命令の操作情報のRowIDヒドラ36への反映を示す。図10Bに示すように、データ管理部22は、共通RowIDファイル34を読み込み(ステップS23)、最初の操作情報の命令区分が「UPD」であるので更新処理を行う。すなわち、データ管理部22は、RowIDが「41」のレコードについては、RowIDヒドラ葉があり、所属パーティションの「4月」があるので、RowIDヒドラ葉を更新する(ステップS27)。
[0062]
 図10Cは、削除命令の操作情報のRowIDヒドラ36への反映を示す。図10Cに示すように、データ管理部22は、共通RowIDファイル34を読み込み(ステップS23)、次の操作情報の命令区分が「DEL」であるので削除処理を行う。すなわち、データ管理部22は、RowIDが「41」のRowIDヒドラ葉をRowIDヒドラ36から削除する(ステップS31)。
[0063]
 図11A~図11Dは、パーティション移動をともなう更新例を示す図である。図11Aは、登録データの例を示す。図11Aに示すように、勤務地でパーティショニングされた従業員データにおいて、レコード#1とレコード#2が追加されると、蓄積データ32の東京パーティションにレコード#1とレコード#2が格納される。また、東京パーティションのパーティション毎RowIDファイル33に、命令区分が「ADD」でRowIDが「01」と「02」の2つの操作情報が格納される。
[0064]
 図11Bは、レコード#1の更新を示す。図11Bに示すように、レコード#1の勤務地が「東京」から「大阪」に変更されると、レコード#1は、蓄積データ32の東京パーティションから大阪パーティションに移動される。また、共通RowIDファイル34に命令区分が「UPD」でRowIDが「01」で所属パーティションが「大阪」の操作情報が格納される。
[0065]
 図11Cは、レコード#2の更新を示す。図11Cに示すように、レコード#2の勤務地が「東京」から「大阪」に変更され、その後、「大阪」から「東京」に変更される。すると、レコード#2は、蓄積データ32の東京パーティションから大阪パーティションに移動され、その後、大阪パーティションから東京パーティションに移動される。また、共通RowIDファイル34に、命令区分が「UPD」でRowIDが「02」で所属パーティションが「大阪」の操作情報と、命令区分が「UPD」でRowIDが「02」で所属パーティションが「東京」の操作情報が格納される。
[0066]
 図11Dは、東京パーティションの削除を示す。図11Dに示すように、東京パーティションが削除されると、東京パーティションの蓄積データ32が削除され、東京パーティションのパーティション毎RowIDファイル33が削除される。
[0067]
 図12A~図12Eは、図11A~図11Dに示した更新が行われた場合のRowIDヒドラ36の復元処理を示す図である。図12Aは、追加命令の操作情報を用いた復元処理を示す。図12Aに示すように、データ管理部22は、パーティション毎RowIDファイル33を読み込む(ステップS21)。ただし、東京パーティションのパーティション毎RowIDファイル33は削除されたため、データ管理部22は、RowIDが「01」と「02」のレコードについては、RowIDヒドラ葉を復元しない。
[0068]
 図12B及び図12Cは、レコード#1の更新命令の操作情報を用いた復元処理を示す。図12Bに示すように、データ管理部22は、共通RowIDファイル34を読み込み(ステップS23)、最初の操作情報の命令区分が「UPD」であるので更新処理を行う。すなわち、データ管理部22は、RowIDが「01」のレコードについては、RowIDヒドラ葉がなく、所属パーティションの「大阪」があるので、図12Cに示すように、RowIDヒドラ葉を追加する(ステップS30)。
[0069]
 図12D及び図12Eは、レコード#2の更新命令の操作情報を用いた復元処理を示す。図12Dに示すように、データ管理部22は、共通RowIDファイル34を読み込み(ステップS23)、次の操作情報の命令区分が「UPD」であるので更新処理を行う。すなわち、データ管理部22は、RowIDが「02」のレコードについては、RowIDヒドラ葉がなく、所属パーティションの「大阪」があるので、RowIDヒドラ葉を追加する(ステップS30)。
[0070]
 そして、図12Eに示すように、データ管理部22は、共通RowIDファイル34を読み込み(ステップS23)、次の操作情報の命令区分が「UPD」であるので更新処理を行う。すなわち、データ管理部22は、RowIDが「02」のレコードについては、RowIDヒドラ葉があり、所属パーティションの「東京」はないので、RowIDヒドラ葉を削除する(ステップS30)。
[0071]
 上述してきたように、実施例では、追加部43aが、追加命令の操作情報をパーティション毎RowIDファイル33に書き込み、更新部43b及び削除部43cが、それぞれ更新命令及び削除命令の操作情報を共通RowIDファイル34に書き込む。そして、復元部44が、RowIDヒドラ36を復元する際に、パーティション毎RowIDファイル33を読み込んでRowIDヒドラ36を作成する処理をパーティション毎に並列に行う。そして、復元部44は、共通RowIDファイル34を読み込んで、更新命令及び削除命令をRowIDヒドラ36に反映する。したがって、データ管理部22は、RowIDヒドラ36の復元時間を短縮して再起動性能を向上することができる。
[0072]
 また、実施例では、パーティション削除部43dは、パーティション削除要求で指定されたパーティションに対応するパーティション毎RowIDファイル33を削除するので、操作情報の数を減らし、RowIDヒドラ36の復元時間を短縮することができる。
[0073]
 また、実施例では、更新命令の操作情報は所属パーティションを含み、復元部44は、所属パーティションを用いてRowIDヒドラ36を復元する。具体的には、復元部44は、更新対象レコードのRowIDヒドラ葉があり、更新対象レコードが所属するパーティションがある場合には、RowIDヒドラ葉を更新する。復元部44は、更新対象レコードのRowIDヒドラ葉があり、更新対象レコードが所属するパーティションがない場合には、RowIDヒドラ36からRowIDヒドラ葉を削除する。復元部44は、更新対象レコードのRowIDヒドラ葉がなく、更新対象レコードが所属するパーティションがある場合には、RowIDヒドラ36へRowIDヒドラ葉を追加する。復元部44は、更新対象レコードのRowIDヒドラ葉がなく、更新対象レコードが所属するパーティションがない場合には、RowIDヒドラ36に対する処理は行わない。したがって、復元部44は、パーティションの移動をともなう更新やパーティションの削除が行われた場合にも、更新命令の操作情報に基づいて、当該更新や削除と整合のとれたRowIDヒドラ36を復元することができる。
[0074]
 なお、実施例では、管理装置2について説明したが、管理装置2が有する構成をソフトウェアによって実現することで、同様の機能を有する管理プログラムを得ることができる。そこで、管理プログラムを実行するコンピュータについて説明する。
[0075]
 図13は、実施例に係る管理プログラムを実行するコンピュータのハードウェア構成を示す図である。図13に示すように、コンピュータ50は、メモリ51と、CPU(Central Processing Unit)52と、LAN(Local Area Network)インタフェース53と、HDD(Hard Disk Drive)54とを有する。また、コンピュータ50は、スーパーIO(Input Output)55と、DVI(Digital Visual Interface)56と、ODD(Optical Disk Drive)57とを有する。
[0076]
 メモリ51は、プログラムやプログラムの実行途中結果等を記憶するメモリである。CPU52は、メモリ51からプログラムを読み出して実行する中央処理装置である。CPU52は、メモリコントローラを有するチップセットを含む。
[0077]
 LANインタフェース53は、コンピュータ50をLAN経由で他のコンピュータに接続するためのインタフェースである。HDD54は、プログラムやデータを格納するディスク装置であり、スーパーIO55は、マウスやキーボード等の入力装置を接続するためのインタフェースである。DVI56は、液晶表示装置を接続するインタフェースであり、ODD57は、DVDの読み書きを行う装置である。
[0078]
 LANインタフェース53は、PCIエクスプレス(PCIe)によりCPU52に接続され、HDD54及びODD57は、SATA(Serial Advanced Technology Attachment)によりCPU52に接続される。スーパーIO55は、LPC(Low Pin Count)によりCPU52に接続される。
[0079]
 そして、コンピュータ50において実行される管理プログラムは、コンピュータ50により読み出し可能な記録媒体の一例であるDVDに記憶され、ODD57によってDVDから読み出されてコンピュータ50にインストールされる。あるいは、管理プログラムは、LANインタフェース53を介して接続された他のコンピュータシステムのデータベース等に記憶され、これらのデータベースから読み出されてコンピュータ50にインストールされる。そして、インストールされた管理プログラムは、HDD54に記憶され、メモリ51に読み出されてCPU52によって実行される。
[0080]
 また、実施例では、XMLデータを管理する場合について説明したが、管理装置2は、他のデータを管理してもよい。また、実施例では、RowIDヒドラ36を用いる場合について説明したが、管理装置2は、RowIDとレコードの物理位置を対応付ける情報であれば、他のデータ構造を用いてもよい。

符号の説明

[0081]
  1  データベース管理システム
  2  管理装置
  3  検索装置
  4  検索式
  9  RowIDファイル
 21  制御部
 22  データ管理部
 30a  第1記憶部
 30b  第2記憶部
 31  パーティション定義
 32  蓄積データ
 33  パーティション毎RowIDファイル
 34  共通RowIDファイル
 36  RowIDヒドラ
 37  パーティション一覧
 43  操作部
 43a  追加部
 43b  更新部
 43c  削除部
 43d  パーティション削除部
 44  復元部
 50  コンピュータ
 51  メモリ
 52  CPU
 53  LANインタフェース
 54  HDD
 55  スーパーIO
 56  DVI
 57  ODD

請求の範囲

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

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10A]

[ 図 10B]

[ 図 10C]

[ 図 11A]

[ 図 11B]

[ 図 11C]

[ 図 11D]

[ 図 12A]

[ 図 12B]

[ 図 12C]

[ 図 12D]

[ 図 12E]

[ 図 13]

[ 図 14]

[ 図 15]

[ 図 16]