WO2020241727A1

WO2020241727A1 - 情報処理システム

Info

Publication number: WO2020241727A1
Application number: PCT/JP2020/021032
Authority: WO
Inventors: 近藤　健一
Original assignee: 株式会社Ｍｕｒａｋｕｍｏ
Priority date: 2019-05-28
Filing date: 2020-05-28
Publication date: 2020-12-03
Also published as: JP2020194335A; JP7398066B2

Abstract

所定の過去の時刻のデータを取得する際の処理コストを低減し、且つ、複数の情報処理システムを活用してデータベースに対する処理能力を向上させることを課題とし、データを所定単位毎に管理する情報処理システムにおいて、論理時刻情報取得部１１２は、管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な第１情報を取得する。行番号情報取得部１１３は、前記管理対象のデータが属する前記所定単位を特定可能な第２情報を取得する。対象データ管理部１１４は、前記第１情報と、前記第２情報と、前記管理対象のデータとを対応付けて管理する。

Description

情報処理システム

　本発明は、情報処理システムに関する。

　従来、情報処理装置において、大量のデータの蓄積、検索、又は更新等を行う場合、データベース（以下、「ＤＢ」と呼ぶことある）が用いられる。
　ここで、データベースに対して同時に複数の処理を行うため、複数データベース間のデータの整合性がとれている状態で、過去のデータを取得可能とする技術が提案されている（例えば、特許文献１参照）。

　特許文献１に記載の技術を含む従来技術では、データベースに付随するジャーナルと呼ばれる履歴に更新の情報を記録し、管理することが行われていた。

特開２０１２－２３４４６２号公報

　しかしながら、特許文献１に記載の技術を含む従来技術では、利用者が所定の過去の時刻のデータベースを取得する場合、所定の過去の時刻より更に前の時刻のデータベースに対し、ジャーナルに記録された過去の更新の情報を適用することが必要であった。このような方法は、利用者が所定の過去の時刻のデータベースを取得する度に、多くの処理が必要となることがあった。

　また、複数の情報処理システムからなるデータベース管理システムを構築して処理能力を向上させる場合、所定の過去の時刻のデータベースを取得することがある。しかしながら、上述のように、特許文献１に記載の技術を含む従来技術では、所定の過去の時刻のデータベースを取得する際に多くの処理が必要となる。このため、複数の情報処理システムを活用してデータベースに対する処理能力を向上させることが十分に達成されないことがあった。

　本発明は、所定の過去の時刻のデータを取得する際の処理コストを低減し、且つ、複数の情報処理システムを活用してデータベースに対する処理能力を向上させることを目的とする。

　上記目的を達成するため、本発明の一態様の情報処理システムは、
　データを所定単位毎に管理する情報処理システムであって、
　管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な第１情報を取得する第１取得手段と、
　前記管理対象のデータが属する前記所定単位を特定可能な第２情報を取得する第２取得手段と、
　前記第１情報と、前記第２情報と、前記管理対象のデータとを対応付けて管理する管理手段と、
　を備える。

　本発明によれば、所定の過去の時刻のデータを取得する際の処理コストを低減し、且つ、複数の情報処理システムを活用してデータベースに対する処理能力を向上させることができる。

本発明の情報処理システムの第１実施形態に係るデータベース管理システムの構成を示すブロック図である。図１のデータベース管理システムにおける情報処理の流れの例を示す図である。図１のデータベース管理システムのうちストレージ管理系ノードのハードウェア構成の一例を示すブロック図である。図１のデータベース管理システムのうちストレージ管理系ノード、トランザクション管理系ノード、及びクライアント系ノードの機能的構成例の一例を示す機能ブロック図である。図１のストレージ管理系ノードで管理されるデータベースに含まれる、論理時刻の夫々における検索対象の候補のデータの夫々の例を示す図である。第１実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。第１実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象のデータの管理の流れの一例を説明するフローチャートである。第２実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。第２実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象のデータの管理の流れの例を説明するフローチャートである。第３実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、検索対象の候補のデータの例を示す図である。第３実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。第３実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象のデータの管理の流れの例を説明するフローチャートである。第４実施形態における図１のストレージ管理系ノードで管理されるファイルにおける、ファイル名と内容の例を示す図である。第４実施形態における図１のストレージ管理系ノードで管理されるデータベースのファイルのファイル名を、論理時刻と対応づけたファイル名として管理する例を示す図である。第４実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象データの管理の流れの一例を説明するフローチャートである。

　以下、図面を参照して、本発明の実施形態として、第１実施形態乃至第４実施形態の夫々についてその順番に説明する。

［第１実施形態］
　まず、本発明が適用される情報処理システムの第１実施形態として、大量のデータの蓄積、検索、及び更新等を行うことができる、データベース管理システムについて説明する。

　ここで、「データベース」とは、蓄積、検索、更新等に便利なように整理された情報（データ）の集まりをいう。

　説明の簡単のため、第１実施形態（及び後述の第２実施形態）では、データベースとして、例えば、ＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ　ＤａｔａＢａｓｅ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）により管理されるリレーショナル形式のデータベースが採用されているものとする。
　ここで、ＲＤＢＭＳは、リレーショナル形式のデータベースを管理するデータベース管理システムである。また、リレーショナル形式のデータベースは、簡単に言うならば、列と行からなる２次元の表の形式としてとらえることが可能なデータベースである。
　即ち、第１実施形態（及び後述の第２実施形態）のデータベースは、例えば、人物の情報をデータとして管理するデータベースにおいて、列の夫々が「名前」、「性別」、「年齢」等の項目に対応し、複数の行の夫々は、複数の人物の夫々に対応する。即ち、この例のデータベースは、管理対象のデータとして人物の各属性を示す各データ（各項目）を含むデータ群を採用しており、その管理対象のデータを行の単位（人物単位）毎に管理する。なお、データベースの列の夫々が示す「名前」、「性別」、「年齢」といった項目（データの属性）のことを「スキーマ」と呼ぶ。

　また、第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベースにおける「蓄積」とは、利用者の希望に応じて検索や更新等を行える状態にするため、又は単に保管するため、管理対象のデータをデータベースの少なくとも一部として記憶することを言う。
　また、第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベースにおける「検索」とは、データベースから、所定のデータを抽出することを言う。ここで、所定のデータには、データベースの一部の生データの他、１以上の生データを加工等したデータも含まれる。なお、以下、データベースの検索に係る処理を、「検索処理」と呼ぶ。
　また、第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベースにおける「更新」とは、データベースの少なくとも一部として、新たなデータを追加すること、既にデータベースの少なくとも一部として記憶されているデータを書き換えること、既にデータベースの少なくとも一部として記憶されているデータを削除することをいう。即ち、データベースに蓄積されたデータを変更することを更新という。なお、データベースの更新に係る処理を、以下、「トランザクション処理」又は「更新処理」と呼ぶ。

　例えば、人物に関するデータベースであって、スキーマとして「名前」、「性別」、「年齢」を持つデータベースにおける、蓄積と検索と更新との例について説明する。
　この例のデータベースは、複数の人物の夫々に対応する行（所定の単位）毎に、各スキーマのデータの組が蓄積されて、構成される。
　また、データベースの利用者は、以下のようなデータを検索することができる。具体的には例えば、特定の人物の「名前」、「性別」、「年齢」の夫々のデータの組を検索（抽出）することができる。また例えば、データベースの利用者は、複数の人物のうち、性別が男性である人物のリストを検索（抽出）することができる。また例えば、データベースの利用者は、複数の人物のデータのうち、性別が男性である人物の年齢の平均値を検索（抽出）することができる。
　また、データベースの利用者は、新たな人物のデータを追加する更新を行ったり、人物のデータのうち年齢を変更する更新を行ったり、人物のデータを削除する更新を行ったりすることができる。

　第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベース管理システムは、複数種類の機能（例えば、蓄積、検索、更新等）毎に、複数のノードにより構成される。データベース管理システムを構成する複数のノードが連携することにより、データベースの処理の能力を向上することができる。更に言えば、複数のノードの数に対して、効率的に処理の能力を向上することができる。

　ここで、「ノード」とは、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）や、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）といったハードウェアと、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）といったソフトウェアが協働する１組の情報処理システムである。即ち例えば、ノードは、１つの情報処理装置である。上述したように、複数のノードは、連携することができる。換言すれば、複数の情報処理装置が連携する場合に、当該複数の情報処理装置の夫々を、「ノード」の夫々と呼ぶ。ノードの夫々の具体的な構成の例は、後述する。

　また、「スケーラビリティ」とは、ハードウェア資源を所定倍にしたときに、ソフトウェアも含めてシステムの全体の性能が何倍になるかという概念である。即ち、ハードウェア資源を５倍にした際に、性能が５倍になった場合スケーラビリティが高く、性能が２倍になった場合スケーラビリティが低いと言える。
　なお、ハードウェア資源を所定倍にする方法は、スケールアップとスケールアウトの２つが存在する。

　「スケールアップ」とは、データベース管理システムを構成する複数のノードの夫々を、より高性能なノードの夫々で置き換えることをいう。具体的には例えば、ノードのＣＰＵとして、より性能の高いＣＰＵを採用することが、スケールアップの一例である。通常、スケールアップがなされた場合、スケーラビリティは高い。しかしながら、ＣＰＵの開発技術によって、ＣＰＵの性能の向上は、頭打ちとなる。更に言えば、高性能なＣＰＵは、性能に対するコストが高い。即ち、スケールアップは、全体的な性能の向上に対するコストパフォーマンスを悪化させることがある。

　「スケールアウト」とは、データベース管理システムを構成するノードの数を増やすことをいう。具体的には例えば、データベース管理システムを構成するノードの数を所定倍の数とすることがスケールアウトの一例である。スケールアウトがなされた場合、スケーラビリティは低下することがある。具体的には例えば、スケールアウトにより数が増加したノードの連携に係る処理により、増加したノードの数に対して、性能が向上しないことがある。

　第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベース管理システムは、当該データベース管理システムを構成する複数のノードの夫々の連携に係る処理を効率的に行うことで、整合性を保ったまま、スケーラビリティを向上させることができる。即ち、第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベース管理システムは、スケールアウトにおいてもスケーラビリティの高い、分散されたデータベース管理システムである。

　ここで、「分散されたデータベース管理システム」とは、複数のノードの夫々にデータが蓄積されたり、複数のノードにより同時に検索処理がされたり、複数のノードにより同時に更新処理がされる、データベース管理システムである。
　即ち例えば、分割されたデータベースの夫々が複数のノードの夫々に記憶された場合、当該データベースは、分散されたデータベースといえる。なお、データベースが複数のノードに記憶される場合、複数のノードの夫々は、分割されたデータベースのみならず、全部、又は一部が共通なデータベースを記憶してもよい。

　なお、「分散されたデータベース管理システム」は、データの蓄積のみならず、検索処理や更新処理を管理するノードも複数存在し、検索処理の要望や更新処理の要望が分散されていてもよい。即ち、後述するように、複数のノードに分散されたデータベースに対し、複数のノードの要望に基づき、更新処理や検索処理を実行することができる。なお、データベース管理システムを構成する他のノードに対して、検索処理を要求することを「検索要求」、更新処理を要求することを「更新要求」と呼ぶ。

　上述のように、分散されたデータベース管理システムにおいてスケールアウトされた場合、更新処理における複数のノードの連携に係る処理により、スケーラビリティが低下することがある。また、分散されたデータベース管理システムにおいて検索処理が行われる場合、複数回の検索処理が行われたとき、複数回の検索処理の間で同一のデータベースに基づかず、例え同一の検索内容で検索された場合であっても同じ結果とならないといった不都合が生じることがある。

　詳細は後述するが、第１実施形態（及び後述の第２実施形態乃至第４実施形態）のデータベース管理システムは、論理時刻を管理することにより、スケールアウトした場合における、トランザクション処理や検索処理に係る、整合性の実現や、処理コストの削減、利便性の向上ができる。

　図１は、本発明の情報処理システムの第１実施形態に係るデータベース管理システムの構成を示すブロック図である。

　図１に示すデータベース管理システムは、ストレージ管理系ノード群Ｇ１と、クライアント系ノード群Ｇ２と、トランザクション管理系ノード群Ｇ３とが、インターネット等の所定のネットワークＮＷを介して相互に接続されることで構成されている。
　ストレージ管理系ノード群Ｇ１は、Ｎ台（Ｎは１以上の任意の整数値）のストレージ管理系ノード１－１乃至１－Ｎにより構成される。同様に、クライアント系ノード群Ｇ２は、Ｍ台（Ｍは１以上の任意の整数値）のクライアント系ノード２－１乃至２－Ｍにより構成される。また、トランザクション管理系ノード群Ｇ３は、Ｌ台（Ｌは１以上の任意の整数値）のトランザクション管理系ノード３－１乃至３－Ｌにより構成される。

　なお、ストレージ管理系ノード１－１乃至１－Ｎの夫々を個々に区別する必要が無い場合、これらをまとめて「ストレージ管理系ノード１」と呼ぶ。また、クライアント系ノード２－１乃至２－Ｍの夫々を個々に区別する必要が無い場合、これらをまとめて「クライアント系ノード２」と呼ぶ。また、トランザクション管理系ノード３－１乃至３－Ｌの夫々を個々に区別する必要が無い場合、これらをまとめて「トランザクション管理系ノード３」と呼ぶ。

　図２は、図１のデータベース管理システムにおける情報処理の流れの例を示す図である。

　ストレージ管理系ノード１は、データベースを記憶し、外部からの要求に基づいて検索処理や更新処理を行う。

　ストレージ管理系ノード１は、クライアント系ノード２から検索要求を受信すると、その検索要求から検索の条件を認識し、その条件を満たすデータを検索して、返信する。例えば、検索要求の中身は、一致検索のような単純な場合や、ＳＱＬで表現されるような複雑な場合がある。
　なお、「ＳＱＬ」とは、データベース管理システムにおいて、データの操作や定義を行うための言語である。

　また、ストレージ管理系ノード１は、トランザクション管理系ノード３から更新要求を受信すると、その更新要求の内容に従って保持しているデータの更新を行う。

　クライアント系ノード２は、検索要求や更新要求の発行元となるノードである。即ち、「クライアント系」とは、検索要求や更新要求の発行元を抽象的に指し示す言葉である。具体的には例えば、クライアント系とは、アプリケーションプログラムや、ＳＱＬ解釈系があげられる。
　ここで、「ＳＱＬ解釈系」とは、更に別の系（アプリケーションプログラムや人間）からＳＱＬを受け付け、それを解釈し、ストレージ管理系ノード群Ｇ１やトランザクション管理系ノード群Ｇ３を構成するノードの夫々が理解できる形に変換するプログラム等をいう。

　即ち、クライアント系ノード２は、例えば、図２の「検索要求」の矢印に示すように、ストレージ管理系ノード１に検索要求を送信する。また、クライアント系ノード２は、例えば、図２の「更新要求」の矢印に示すように、トランザクション管理系ノード３に更新要求を送信する。

　トランザクション管理系ノード３は、クライアント系ノード２から、更新要求を受信すると、以下のように処理を行う。即ち、トランザクション管理系ノード３は、仮にその更新要求に従ってデータベースの更新を行ったとして、整合性が崩れるかどうかを判定する。整合性が崩れる場合、又はその可能性が十分に高い場合、トランザクション管理系ノード３は、その更新要求を破棄する。整合性が崩れないことが確実である場合、トランザクション管理系ノード３は、ストレージ管理系ノード１に更新要求を送信する。

　ここでいう「整合性」とは、トランザクション処理の信頼性を保つために満たすべき性質の１つである。更に言えば、「整合性」は、データベースが満たすべきＡＣＩＤ特性（Ａｔｏｍｉｃｉｔｙ（原子性）、Ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）、Ｉｓｏｌａｔｉｏｎ（独立性）、Ｄｕｒａｂｉｌｉｔｙ（永続性））を含む広義の概念であってよい。
　具体的には例えば、整合性として、以下のことが求められる。ＡＣＩＤ特性のＡである、「『一部の操作は実行され、残りの操作は実行されない』ということが起こらない」ことが求められる。また例えば、強い整合性として、「完了したトランザクションの内容はすぐに検索できる」こと等が求められる。即ち、トランザクションが完了した場合、トランザクションの内容が反映されたデータベースから検索できること等が求められる。また例えば、ＡＣＩＤ特性のＩとして、「トランザクション中に行われる操作の過程が他の操作から隠蔽される」こと等が求められる。即ち、トランザクション中において、整合性がない時点（過程）は、検索が不可能であることが求められる。

　即ち、トランザクション管理系ノード３は、例えば、図２の「更新要求」の矢印に示すように、クライアント系ノード２から送信されてきた更新要求を受信する。上述のように、整合性が崩れないと判定された場合、トランザクション管理系ノード３は、例えば、図２の「更新要求（整合性を崩さないもののみ）」の矢印に示すように、ストレージ管理系ノード１に更新要求を送信する。なお、詳細は後述するが、トランザクション管理系ノード３は、整合性が崩れるか否かを判定する場合や、ＳＩ（Ｓｎａｐｓｈｏｔ　Ｉｓｏｌａｔｉｏｎ）の方式による更新要求の管理をする場合、検索要求を送信することができる。

　図３は、図１のデータベース管理システムのうちストレージ管理系ノードのハードウェア構成の一例を示すブロック図である。

　ストレージ管理系ノード１は、ＣＰＵ１１と、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）１２と、ＲＡＭ１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０と、を備えている。

　ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
　ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

　ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

　出力部１６は、ディスプレイやスピーカ等で構成され、各種情報を画像や音声として出力する。
　入力部１７は、キーボードやマウス等で構成され、各種情報を入力する。

　記憶部１８は、ハードディスクやＤＲＡＭ（Ｄｙｎａｍｉｃ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
　通信部１９は、インターネットを含むネットワークＮＷを介して他の装置（図１の例ではクライアント系ノード２やトランザクション管理系ノード３）との間で通信を行う。

　ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３１が適宜装着される。ドライブ２０によってリムーバブルメディア３１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。
　また、リムーバブルメディア３１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

　なお、図示はしないが、図１のデータベース管理システムのクライアント系ノード２、及びトランザクション管理系ノード３は、図３に示すハードウェア構成と基本的に同様の構成を有している。

　図４は、図１のデータベース管理システムのうちストレージ管理系ノード、トランザクション管理系ノード、及びクライアント系ノードの機能的構成例の一例を示す機能ブロック図である。

　図４以降の説明において、説明を簡単にするため、ストレージ管理系ノード１、クライアント系ノード２、及びトランザクション管理系ノード３の夫々は、１台ずつであるものとして説明する。

　なお、第１実施形態（及び後述の第２実施形態乃至第４実施形態）において、ストレージ管理系ノード１がデータベースを「蓄積」や「検索」や「更新」等に便利なように整理して記憶することを、まとめて、ストレージ管理系ノード１がデータベースを「管理」すると呼ぶ。即ち、ストレージ管理系ノード１は、管理対象のデータをデータベースとして管理する。
　また、データベースは、上述のように、リレーション（表）の形式で管理されるものとして説明する。即ち、管理対象のデータは、リレーションにおける行毎に、管理される。

　まず、図４を用いて、ストレージ管理系ノード１、クライアント系ノード２、及びトランザクション管理系ノード３により、更新処理が行われる場合機能する機能ブロックについて説明する。

　なお、図４の説明において、ストレージ管理系ノード１は、人物に関するデータベースを管理しており、当該データベースは、スキーマとして「名前」、「性別」、「年齢」を持つものとする。また、更新処理を行う要求、即ち更新要求として、データベースの２行目に蓄積されている、名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５歳」といった人物のデータを、名前と性別とは変更がなく、年齢が「２６歳」であるといった人物のデータに更新させるという内容（以下、「更新内容」と呼ぶ）の要求が採用されたものとして説明する。また、更新処理は、後述する「論理時刻＝５」の時刻に行われたものとして説明する。

　更新処理が実行される場合には、ストレージ管理系ノード１のＣＰＵ１１において、更新要求情報取得部１１１と、論理時刻情報取得部１１２と、行番号情報取得部１１３と、対象データ管理部１１４と、が機能する。また、クライアント系ノード２のＣＰＵ２１２において、更新要求管理部２２１が機能する。また、トランザクション管理系ノード３のＣＰＵ３１２において、更新要求情報取得部３２１と、更新要求整合性管理部３２２と、が機能する。

　まず、クライアント系ノード２の更新要求管理部２２１は、データベースの更新を要求する情報であって、その更新の内容を含む情報（以下、「更新要求情報」と呼ぶ）をトランザクション管理系ノード３に送信することで、更新要求を管理する。ここで、「更新要求」とは、上述したように、データベース管理システムを構成するストレージ管理系ノード１により管理されるデータベースに対する、更新処理の要求である。
　具体的には例えば、更新要求管理部２２１は、図示せぬアプリケーションプログラム等の要求に基づき、更新要求情報として、データベースに要求する更新内容を含む情報を取得又は生成し、更新要求情報をトランザクション管理系ノード３に通信部２１１を介して送信する。即ち、ここでいう更新要求情報は、例えば「データベースの２行目に蓄積されている、名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５歳」といった人物のデータを、名前と性別とは変更がなく、年齢が「２６歳」であるといった人物のデータに更新する」という要求の情報である。

　トランザクション管理系ノード３の更新要求情報取得部３２１は、クライアント系ノード２から送信されてきた更新要求情報を取得する。

　更新要求整合性管理部３２２は、更新要求情報取得部３２１で取得された更新要求情報に基づき、管理対象のデータが管理されるストレージ管理系ノード１に対して更新要求情報を送信することで、当該更新要求を管理する。
　即ち、更新要求整合性管理部３２２は、更新要求情報に基づき、ストレージ管理系ノード１に対して更新要求情報を送信するか否かを管理することで、更新の要求を管理する。

　具体的には例えば、更新要求整合性管理部３２２は、当該更新要求情報をストレージ管理系ノード１に対して送信することで、管理対象のデータが含まれるデータベースの更新を行った場合に、当該データベースの整合性が崩れるか否かを判定する。
　また例えば、まず、更新要求整合性管理部３２２は、過去の更新要求情報等の全部又は一部を保持して管理する。次に、更新要求整合性管理部３２２は、新たな更新要求情報を、過去の更新要求情報等と照合する。このとき、更新要求整合性管理部３２２は、新たな更新要求情報により更新される管理対象のデータが、過去の更新要求情報等により更新されたか否かに基づいて、ストレージ管理系ノード１に格納されたデータベースの整合性が崩れるか否かを判定する。
　もし、当該更新要求情報に基づいてデータベースの更新を行った場合に、整合性が維持されない、又はその可能性が十分に高いと判定された場合、更新要求整合性管理部３２２は、その更新の要求を破棄する。整合性が維持されることが確実である場合、トランザクション管理系ノード３は、ストレージ管理系ノード１に更新要求を送信する。

　つまり、更新要求整合性管理部３２２は、データベースの整合性が崩れるか否かを判定して、整合性が維持されることが確実である場合にのみ、ストレージ管理系ノード１に更新要求情報を送信する。これにより、ストレージ管理系ノード１により管理されるデータベースは、更新処理に係る整合性が維持される。

　なお、図示はしないが、更新要求整合性管理部３２２は、データベースの整合性が崩れるか否かを判定する際に、後述する検索処理を行うことができる。
　なお、更新要求整合性管理部３２２は、更新の要求を破棄する旨やストレージ管理系ノード１に送信する旨を、クライアント系ノード２の更新要求管理部２２１に通知することができる。更新要求整合性管理部３２２により更新の要求を破棄された場合、クライアント系ノード２の更新要求管理部２２１は、更新の要求を再度発行することができる。

　ストレージ管理系ノード１の更新要求情報取得部１１１は、トランザクション管理系ノード３から送信されてきた更新要求情報を取得する。

　論理時刻情報取得部１１２は、管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な情報を、論理時刻情報として取得する。
　ここで、論理時刻とは、管理対象のデータを管理する際における、更新履歴を記録するための時刻である。論理時刻は、データベースの更新毎に一意に付与された、整数であってよい。具体的には例えば、１回目の更新は「論理時刻＝１」、２回目の更新は「論理時刻＝２」といった数の形態とすることができる。また例えば、論理時刻は、通常の時刻と同様に、「年」「月」「日」「時」「分」「秒」等の組み合わせで示される、いわゆる通常の時刻の形態とすることができる。
　即ち、論理時刻は、データベースの管理に使われ、一方向に変化する識別子である。図４の第１実施形態の説明では、論理時刻は、データベースの更新毎に付与された整数値として説明する。また、「論理時刻＝５」において、更新処理が行われるものとして説明する。

　論理時刻情報取得部１１２は、管理対象のデータが更新処理により有効になった時点を示す挿入論理時刻ｘｔ＿ｉｎｓと、管理対象のデータが無効になった時点を示す削除論理時刻ｘｔ＿ｄｅｌとを含む情報を論理時刻情報として取得する。

　具体的には例えば、更新処理として、名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５歳」といった人物のデータを、名前と性別とは変更がなく、年齢が「２６歳」であると更新する処理が採用されている場合を例として説明する。即ち、この例の更新処理において、「ＡＢＣＤ」、「男性」、「２６歳」のデータの組がデータベースに挿入される。また、「ＡＢＣＤ」、「男性」、「２５歳」のデータの組がデータベースから削除される。
　この場合、論理時刻情報取得部１１２は、この更新処理が行われる「論理時刻＝５」を、「ＡＢＣＤ」、「男性」、「２６歳」のデータの組の挿入論理時刻ｘｔ＿ｉｎｓとして、取得する。また、「ＡＢＣＤ」、「男性」、「２６歳」のデータの組の削除論理時刻ｘｔ＿ｄｅｌは、未定である。そこで、例えば、論理時刻情報取得部１１２は、削除論理時刻ｘｔ＿ｄｅｌが未定である旨を、∞という削除論理時刻ｘｔ＿ｄｅｌとして取得することができる。
　また、論理時刻情報取得部１１２は、この更新処理が行われる「論理時刻＝５」を、「ＡＢＣＤ」、「男性」、「２５歳」のデータの組の削除論理時刻ｘｔ＿ｄｅｌとして、取得する。「ＡＢＣＤ」、「男性」、「２５歳」のデータの組の挿入論理時刻ｘｔ＿ｉｎｓは、すでにデータベースに蓄積されているデータから取得することができる。

　行番号情報取得部１１３は、管理対象のデータが属する行を特定可能な行番号情報を取得する。即ち、行番号情報取得部１１３は、更新処理を行うデータの組が、データベースにおけるいずれの行のデータであるのかを特定可能な行番号情報を取得する。具体的には例えば、行番号情報取得部１１３は、更新要求情報から、「ＡＢＣＤ」、「男性」、「２６歳」のデータの組が、２行目である旨を行番号情報として取得する。

　対象データ管理部１１４は、論理時刻情報と、行番号情報と、管理対象のデータとを対応付けてデータベース１５０に蓄積して管理する。

　ここで、図４を見ると、データベース１５０の一領域には、論理時刻ｔ１乃至ｔｎの夫々に対応するデータベース１５０－１乃至１５０－ｎの夫々が設定されている。このデータベース１５０－１乃至１５０－ｎの夫々には、１乃至ｎの論理時刻の夫々に対応するデータの内容が格納されている。

　即ち、データベース１５０は、論理時刻情報と、行番号情報と、管理対象のデータとを対応付けてデータベース１５０に格納するため、データベース１５０－１乃至１５０－ｎに対応する管理対象のデータを全て含んでいる。論理時刻情報を含む情報を格納されているデータベース１５０は、所定の処理を施されることで、論理時刻ｔ１におけるデータベース１５０－１に含まれる情報が抽出されることが可能なデータベースである。
　なお、挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌが、具体的にどのようにデータベース１５０に蓄積されるのかの詳細は図５及び図６を用いて後述する。

　以上、ストレージ管理系ノード１、クライアント系ノード２、及びトランザクション管理系ノード３により、更新処理が行われる場合に機能する機能ブロックについて説明した。
　次に、ストレージ管理系ノード１、及びクライアント系ノード２により、検索処理が行われる場合に機能する機能ブロックについて説明する。

　ここで、以下の説明を容易なものとすべく、検索処理は、その前提として上述の更新処理がなされた後のデータベース１５０に対して行われる例を用いるものとする。この例では、検索対象とする論理時刻は、上述の更新処理が行われる以前の論理時刻である「論理時刻＝４」であるものとする。つまり、これから説明する検索処理の例は、図示せぬユーザからの「論理時刻＝４」におけるデータベース１５０－４の内容に対して検索処理が実行されるものとする。
　まとめると、検索処理を行う要求、即ち検索要求として、「「論理時刻＝４」におけるデータベースの２行目に蓄積されている、人物のデータを抽出する」という内容（以下、「検索内容」と呼ぶ）の要求がなされる例を用いて説明する。

　検索処理が実行される場合には、ストレージ管理系ノード１のＣＰＵ１１において、検索対象論理時刻情報取得部１２１と、検索内容情報取得部１２２と、検索管理部１２３と、検索結果提示部１２４と、が機能する。また、クライアント系ノード２のＣＰＵ２１２において、検索要求管理部２２２が機能する。

　クライアント系ノード２の検索要求管理部２２２は、データベースからデータの検索を要求する情報であって、その検索の内容を含む情報（以下、「検索要求情報」と呼ぶ）をストレージ管理系ノード１に送信することで、検索要求を管理する。
　具体的には例えば、検索要求管理部２２２は、図示せぬアプリケーションプログラム等の要求に基づき、検索要求情報として、データベースに要求する検索内容を含む情報を取得又は生成し、検索要求情報をストレージ管理系ノード１に送信する。即ち、ここでいう検索要求情報は、例えば「「論理時刻＝４」におけるデータベースの２行目に蓄積されている、人物のデータを抽出する」という要求の情報である。

　ストレージ管理系ノード１の検索対象論理時刻情報取得部１２１は、クライアント系ノード２から送信されてきた検索要求情報に含まれる論理時刻を、検索対象論理時刻ｓｔ（ｓｔは１乃至ｎのうちの任意の整数値であり、本例では「４」）として取得する。

　検索内容情報取得部１２２は、検索要求情報から、どのような内容の検索を行うかを示す情報（以下、「検索内容情報」と呼ぶ）を取得する。
　本例では、検索内容情報取得部１２２は、検索要求情報のうち、「データベースの２行目に蓄積されている、人物のデータを抽出する」という情報を、検索内容情報として取得する。

　検索管理部１２３は、検索対象特定部１３１と、検索部１３２とを有する。

　検索対象特定部１３１は、検索対象論理時刻情報取得部１２１により取得された検索対象論理時刻ｓｔ（本例では「４」）に基づいて、データベースの中から検索対象の候補のデータを特定する。

　具体的には例えば、データベースには、上述の更新処理が行われた結果として、次の第１データと第２データとが蓄積されているものとする。即ち、行番号が「２行目」、挿入論理時刻ｘｔ＿ｉｎｓが「１」、削除論理時刻ｘｔ＿ｄｅｌが「５」、名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５」のデータが第１データであるものとする。また、行番号が「２行目」、挿入論理時刻ｘｔ＿ｉｎｓが「５」、削除論理時刻ｘｔ＿ｄｅｌが「∞」、名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２６」のデータが第２データであるものとする。
　この場合、検索対象特定部１３１は、データベースのうち、検索対象の候補のデータを特定するための条件を、次のようにして決定する。即ち、本例では、上述のように、検索対象論理時刻ｓｔは「４」である。従って、検索対象の候補のデータは、「挿入論理時刻ｘｔ＿ｉｎｓが４より小さく、且つ、削除論理時刻ｘｔ＿ｄｅｌが４以上」という条件を満たす必要がある。そこで、検索対象特定部１３１は、かかる条件を、検索対象の候補のデータを特定するための条件として決定する。
　即ち、この場合、上述の例では、検索対象特定部１３１は、第１データを、検索対象の候補のデータとして特定する。

　検索部１３２は、検索内容情報取得部１２２により取得された検索内容情報から検索内容を認識し、検索対象特定部１３１により特定された検索対象の候補のデータから当該検索内容に合致するデータを検索する。
　具体的には例えば、上述の例では、検索部１３２は、第１データから、「データベースの２行目に蓄積されている、人物のデータを抽出する」という検索内容に合致するデータを検索する。
　このように、複数のデータを含む検索対象の候補のデータから、検索結果として、「名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５」」のデータが抽出される。

　検索結果提示部１２４は、検索部１３２の検索結果を、クライアント系ノード２に提示する。
　具体的には例えば、検索結果提示部１２４は、検索部１３２で抽出された、検索結果である「名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５」」のデータを、クライアント系ノード２に送信する。

　クライアント系ノード２の検索要求管理部２２２は、ストレージ管理系ノード１から送信されてきた検索結果を取得して管理する。具体的には例えば、検索要求管理部２２２は、ストレージ管理系ノード１から送信されてきた「名前が「ＡＢＣＤ」、性別が「男性」、年齢が「２５」」という人物のデータを取得して管理する。このように、検索要求管理部２２２は、発行した検索要求に対する結果を取得することができる。

　以上、図４を用いて、ストレージ管理系ノード１、及びクライアント系ノード２により、検索処理が行われる場合に機能する機能ブロックについて説明した。

　以上をまとめると、第１実施形態のストレージ管理系ノード１は、論理時刻に基づいた更新処理及び検索処理を実行することができる。

　具体的には、対象データ管理部１１４は、論理時刻情報（挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌの情報）と、行番号情報と、管理対象のデータとを対応付けてデータベース１５０に蓄積して管理する。これにより、ストレージ管理系ノード１が有するデータベース１５０は、論理時刻の夫々に対応するデータベース１５０－１乃至１５０－ｎの夫々のデータを含んだデータベースとなる。
　また、検索対象特定部１３１は、対象データ管理部１１４により管理される論理時刻情報、及び検索対象論理時刻情報に基づき、検索対象論理時刻情報により特定される時刻に有効であった管理対象のデータを、検索対象の候補のデータとして特定する。即ち、検索対象特定部１３１は、データベース１５０から、検索対象論理時刻ｓｔに対応するデータベース１５０－ｓｔを検索対象の候補のデータとして特定する。
　これにより、検索部１３２は、検索対象論理時刻ｓｔにおけるデータベース１５０から、検索することができる。

　特許文献１に記載の技術を含む従来技術では、スナップショットとジャーナルにより、データベースとその更新処理の内容を管理していた。この場合、データベースのスナップショットに対して、ジャーナルから取得した検索対象の時刻までの更新の情報を適用することで、検索対象の候補のデータとすることができる。しかしながら、この方法は、データ処理に係る時間等のコストが大きく、安易に利用することができなかった。

　一方、第１実施形態は、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓや削除論理時刻ｘｔ＿ｄｅｌを、データベースに蓄積して管理することができる。これにより、論理時刻に対する検索を、データベースに対する検索と同様に行うことができる。具体的には例えば、データベースに蓄積されている挿入論理時刻ｘｔ＿ｉｎｓや削除論理時刻ｘｔ＿ｄｅｌと検索対象論理時刻ｓｔとの大小関係を比較する形式で与えることで、検索対象の候補のデータを特定することができる。
　これにより、第１実施形態は、分散されたデータベース管理システムでありながら、スケーラビリティを向上させることができる。

　次に、図５、及び図６を用いて、第１実施形態に係る対象データ管理部１１４により、挿入論理時刻ｘｔ＿ｉｎｓ、削除論理時刻ｘｔ＿ｄｅｌ、及び管理対象のデータが、対応付けられてデータベース１５０Ａに蓄積される例を説明する。

　図５は、図１のストレージ管理系ノードで管理されるデータベースに含まれる、論理時刻の夫々における検索対象の候補のデータの夫々の例を示す図である。
　図６は、第１実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。

　図５（Ａ）乃至図５（Ｄ）の夫々に示すデータベースの夫々の検索対象論理時刻ｓｔは、相互に異なっている。図６に示すデータベース１５０Ａは、図５（Ａ）乃至図５（Ｄ）の夫々に示すデータベースの夫々を包含するデータベースである。

　図５（Ａ）乃至図５（Ｄ）に示すデータベースの夫々は、スキーマとして、「ｔｉｄ」、「Ａ」、「Ｂ」、「Ｃ」を有する。「ｔｉｄ」は、図４の説明における、行番号に対応する。「Ａ」、「Ｂ」、及び「Ｃ」の夫々は、図４の説明における、「名前」、「性別」、「年齢」の夫々に対応する。ただし、図５以降の説明におけるデータベースに蓄積された管理対象のデータは、図４の説明で用いた人物のデータではなく、一般的な管理対象のデータであり数値や文字列であるものとして説明する。
　また、詳細は後述するが、図６のデータベース１５０Ａは、以下の第１の更新処理乃至第４の更新処理が行われたデータである。

　なお、データベース１５０Ａの符号が含む「Ａ」の文字は、図５（Ａ）乃至図５（Ｄ）に示すデータベース１５０－８、１５０－１１、１５０－１３、１５０－１６等を含むデータベースのうち、ある１つの実施形態であることを示している。
　図５（Ａ）乃至図５（Ｄ）に示すデータベース１５０－８、１５０－１１、１５０－１３、１５０－１６を含むデータベースのうち、他の実施形態は、図８以降を用いて、データベース１５０Ｂ等を用いて後述する。

　第１の更新処理は、論理時刻が「７」において、「ｔｉｄ」について「１００１」のデータが追加される更新処理である。
　第２の更新処理は、論理時刻が「１０」において、「ｔｉｄ」について「１００２」、「１００３」のデータが追加される更新処理である。
　第３の更新処理は、論理時刻が「１２」において、「ｔｉｄ」について「１００２」のデータが変更される更新処理である。
　第４の更新処理は、論理時刻が「１５」において、「ｔｉｄ」について「１００３」のデータが削除される更新処理である。

　図５（Ａ）には、データベース１５０－８、即ち、検索対象論理時刻ｓｔが「８」におけるデータベースが図示されている。即ち、データベース１５０－８は、第１の更新処理の結果として得られるデータベースである。データベース１５０－８は、スキーマの夫々に対応するデータとして、「１００１」、「ａ１」、「ｂ１」、「ｃ１」のデータの組を含む。即ち、データベース１５０－８は、「ｔｉｄ」が「１００１」のデータのみを含む。
　検索処理において、検索対象論理時刻ｓｔとして「８」が指定された場合、検索対象特定部１３１は、図６のデータベース１５０Ａから、図５（Ａ）に示すデータベース１５０－８のデータを、検索対象の候補のデータとして特定する。

　図５（Ｂ）には、データベース１５０－１１、即ち、検索対象論理時刻ｓｔが「１１」である場合におけるデータベースが図示されている。即ち、データベース１５０－１１は、第１の更新処理及び第２の更新処理の結果として得られるデータベースである。データベース１５０－１１は、「ｔｉｄ」が「１００１」、「１００２」、「１００３」のデータを含む。
　検索処理において、検索対象論理時刻ｓｔとして「１１」が指定された場合、検索対象特定部１３１は、データベース１５０Ａから、図５（Ｂ）に示すデータベース１５０－１１のデータを、検索対象の候補のデータとして特定する。

　図５（Ｃ）には、データベース１５０－１３、即ち、検索対象論理時刻ｓｔが「１３」である場合におけるデータベースが図示されている。即ち、データベース１５０－１３は、第１の更新処理乃至第３の更新処理の結果として得られるデータベースである。データベース１５０－１３は、「ｔｉｄ」が「１００１」、「１００２」、「１００３」のデータを含む。また、図５（Ｃ）のデータベース１５０－１３における「ｔｉｄ」が「１００２」のデータは、図５（Ｂ）のデータベース１５０－１１における「ｔｉｄ」が「１００２」のデータと異なる。即ち、図５（Ｃ）のデータベース１５０－１３における「ｔｉｄ」が「１００２」のデータは、第３の更新処理により変更されている。
　検索処理において、検索対象論理時刻ｓｔとして「１３」が指定された場合、検索対象特定部１３１は、図６のデータベース１５０Ａから、図５（Ｃ）に示すデータベース１５０－１３のデータを、検索対象の候補のデータとして特定する。

　図５（Ｄ）には、データベース１５０－１６、即ち、検索対象論理時刻ｓｔが「１６」である場合におけるデータベースが図示されている。即ち、データベース１５０－１６は、第１の更新処理乃至第４の更新処理の結果として得られるデータベースである。データベース１５０－１６は、「ｔｉｄ」が「１００１」、「１００２」のデータを含む。
　検索処理において、検索対象論理時刻ｓｔとして「１６」が指定された場合、検索対象特定部１３１は、図６のデータベース１５０Ａから、図５（Ｄ）に示すデータベース１５０－１６のデータを、検索対象の候補のデータとして特定する。

　図６のデータベース１５０Ａは、スキーマとして、「ｔｉｄ」、「ｘｔ＿ｉｎｓ」、「ｘｔ＿ｄｅｌ」、「Ａ」、「Ｂ」、「Ｃ」を有する。「ｔｉｄ」は、図４の説明における、行番号に対応する。「ｘｔ＿ｉｎｓ」は、図４の説明における、「挿入論理時刻ｘｔ＿ｉｎｓ」に対応する。「ｘｔ＿ｄｅｌ」は、図４の説明における、「削除論理時刻ｘｔ＿ｄｅｌ」に対応する。即ち、データベース１５０Ａは、挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌを、データベースのスキーマとして蓄積している。

　図６を用いて、検索対象論理時刻ｓｔとして「１３」が指定された検索処理において、検索対象特定部１３１が、データベース１５０Ａから、図５（Ｃ）に示すデータベース１５０－１３を、検索対象の候補のデータとして特定するまでの一連の流れを説明する。
　検索対象特定部１３１は、データベース１５０Ａの４つの行の夫々が、検索対象論理時刻ｓｔが「１３」の時刻において有効であったかを特定する。具体的には、検索対象特定部１３１は、データベース１５０Ａの行の夫々について、以下の式（１）及び式（２）を満たすか否かを確認することで、その行の管理対象のデータが有効であったか否かを判定することができる。

　ｓｔ　＞　ｘｔ＿ｉｎｓ　・・・　（１）
　ｓｔ　≦　ｘｔ＿ｄｅｌ　・・・　（２）

　即ち、式（１）を満たす場合、その行の管理対象のデータは、検索対象論理時刻ｓｔより前に有効となったデータである。換言すれば、式（１）が満たされない場合、その行の管理対象のデータは、未だ有効でなかったデータである。

　また、式（２）を満たす場合、その行の管理対象のデータは、検索対象論理時刻ｓｔの時点では無効となっていないデータである。換言すれば、式（２）が満たされない場合、その行の管理対象のデータは、既に無効になったデータである。

　検索対象論理時刻ｓｔとして「１３」が指定された場合、検索対象特定部１３１は、図６のデータベース１５０Ａの行の夫々の有効又は無効の判定を、以下の通り行う。

　図６のデータベース１５０Ａの１行目の行（「ｔｉｄ」が「１００１」の行）は、式（１）及び式（２）を満たすので有効である。
　図６のデータベース１５０Ａの２行目の行（「ｔｉｄ」が「１００１」の行のうち上の行）は、式（２）を満たさないので無効である。
　図６のデータベース１５０Ａの３行目の行（「ｔｉｄ」が「１００１」の行のうち下の行）は、式（１）及び式（２）を満たすので有効である。
　図６のデータベース１５０Ａの４行目の行（「ｔｉｄ」が「１００１」の行）は、式（１）及び式（２）を満たすので有効である。

　これにより、上述のように図６のデータベース１５０Ａのうち、有効である１行目、３行目、４行目が、図５（Ｃ）のデータベース１５０－１３として検索対象の候補のデータとして特定される。

　図７は、第１実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象データの管理の流れの一例を説明するフローチャートである。
　ここで、第１実施形態（及び後述の第２実施形態乃至第４実施形態）の「格納処理」とは、更新処理によりデータベースに蓄積されたデータが変更される際、変更されたデータが図４のストレージ管理系ノード１の記憶部１８に格納される処理である。
　更新処理が行われることにより、データベース１５０Ａに蓄積して管理すべきデータ（管理対象のデータ）が発生すると、格納処理が開始されて、次のようなステップＳ１１乃至Ｓ１５の処理が実行される。

　即ち、ステップＳ１１において、論理時刻情報取得部１１２は、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。

　ステップＳ１２において、行番号情報取得部１１３は、管理対象のデータがデータベースにおけるいずれの行であるかを特定可能な情報を、行番号情報として取得する。

　ステップＳ１３において、対象データ管理部１１４は、ステップＳ１２の処理で取得された行番号情報に基づき、データベース１５０Ａの中に、無効になった管理対象のデータがあるか否かを判定する。
　無効になった管理対象のデータがある場合、ステップＳ１３の処理においてＹＥＳであると判定されて、処理はステップＳ１４に進む。

　ステップＳ１４において、対象データ管理部１１４は、ステップＳ１１の処理で取得された、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌと、無効になった管理対象のデータとを対応づけてデータベース１５０Ａに蓄積して管理する。

　ステップＳ１５において、対象データ管理部１１４は、ステップＳ１１の処理で取得された有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータとを対応づけてデータベース１５０Ａに蓄積して管理する。
　これにより、格納処理は終了する。

　以上、管理対象のデータの中に無効になったデータがある場合のステップＳ１３以降の処理について説明した。

　これに対して、管理対象のデータの中に無効になったデータが存在する場合のステップＳ１３以降の処理は次のようになる。
　即ち、無効になったデータがない場合、ステップＳ１３の処理においてＮＯであると判定されて、処理はステップＳ１５に進む。即ち、無効になったデータがある場合に実行されたステップＳ１４の処理は、無効になった管理対象のデータがない場合には実行されない。

　ステップＳ１５において、対象データ管理部１１４は、ステップＳ１１の処理で取得された論理時刻情報を、有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓとして、有効になった管理対象のデータとを対応づけてデータベース１５０Ａに蓄積して管理する。
　これにより、格納処理は終了する。

　ここで、格納処理の理解を容易なものとすべく、データベース１５０Ａの中に無効になった管理対象のデータがある場合の第１の例と、データベース１５０Ａの中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明する。

　第１の例は、管理対象のデータとして、「Ａ」、「Ｂ」、及び「Ｃ」のスキーマを持つデータ群のうち、「ｔｉｄ」が「１００２」の管理対象のデータに対する更新処理が実行された場合の例である。
　なお、以下の説明において、「Ａ」というスキーマが「ａ１」、「Ｂ」というスキーマが「ｂ１」、「Ｃ」というスキーマが「ｃ１」であることを、「（Ａ，Ｂ，Ｃ）＝（ａ１，ｂ１，ｃ１）」と記載する。
　第１の例では、更新処理前には、論理時刻１０乃至１２において、管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）であったものが、論理時刻１２における更新処理により、管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）に更新されたものとする。

　ステップＳ１１において、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。具体的には、ステップＳ１１の処理は、無効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」及び削除論理時刻ｘｔ＿ｄｅｌ＝「１２」の情報を論理時刻情報として取得する。また、具体的には、ステップＳ１１の処理は、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）の挿入論理時刻ｘｔ＿ｉｎｓ＝「１２」を論理時刻情報として取得する。

　ステップＳ１２において、行番号情報として「１００２」が取得される。
　第１の例では無効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）があるため、ステップＳ１３の処理においてＹＥＳであると判定されて、処理はステップＳ１４に進む。

　ステップＳ１４において、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌは、無効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）と対応づけられてデータベース１５０Ａに蓄積されて管理される。

　ステップＳ１５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓは、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）と対応づけられて、データベース１５０Ａに蓄積されて管理される。
　これにより格納処理は終了となる。

　以上、データベース１５０Ａの中に無効になった管理対象のデータがある場合の第１の例を用いて格納処理の説明をした。
　次に、データベース１５０Ａの中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をする。

　第２の例は、管理対象のデータとして、「Ａ」、「Ｂ」、及び「Ｃ」のスキーマを持つデータ群のうち、「ｔｉｄ」が「１００３」の管理対象のデータに対する更新処理が実行された場合の例である。
　第２の例では、更新処理前には、論理時刻１０までにおいて、「ｔｉｄ」が「１００３」の管理対象のデータは存在しなかったが、論理時刻１０における更新処理により、管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）が更新（追加）されたものとする。

　ステップＳ１１において、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。具体的には、ステップＳ１１の処理は、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」を論理時刻情報として取得する。また、ステップＳ１１の処理は、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）の削除論理時刻ｘｔ＿ｄｅｌ＝「∞」を論理時刻情報として取得する。なお、上述で説明した通り、削除論理時刻ｘｔ＿ｄｅｌ＝「∞」という論理時刻情報は、削除論理時刻ｘｔ＿ｄｅｌが未定である旨を示す論理時刻情報である。

　ステップＳ１２において、行番号情報として「１００２」が取得される。
　第２の例では無効になったデータがないため、ステップＳ１３の処理においてＮＯであると判定されて、処理はステップＳ１５に進む。

　ステップＳ１５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）とが対応づけて、データベース１５０Ａに蓄積されて管理される。
　これにより格納処理は終了となる。
　以上、データベース１５０Ａの中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をした。

　以上をまとめると、第１の例のように、管理対象のデータを書き換える様な更新処理の場合、更新処理により無効となる管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）が、ステップＳ１４の処理によりデータベース１５０Ａに蓄積されて管理される。また、更新処理により、有効となる管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）が、ステップＳ１５の処理によりデータベース１５０Ａに蓄積されて管理される。
　また、第２の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップＳ１４の処理は実行されない。また、更新処理により、有効となる管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）が、ステップＳ１５の処理によりデータベース１５０Ａに蓄積されて管理される。

　以上、格納処理の理解を容易なものとすべく、データベース１５０Ａの中に無効になった管理対象のデータがある場合の第１の例と、データベース１５０Ａの中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明した。

　以上、本発明の第１実施形態に係るデータベース管理システムについて説明した。
　次に、本発明の第２実施形態に係るデータベース管理システムについて説明する。

［第２実施形態］
　第２実施形態に係るデータベース管理システムの構成は、第１実施形態と同様である。即ち、図１はそのまま、本発明の第２実施形態に係るデータベース管理システムの構成を示している。よって、本発明の第２実施形態に係るデータベース管理システムの構成の説明は省略する。

　また、第２実施形態に係るストレージ管理系ノード１のハードウェア構成は、第１実施形態と同様である。即ち、図３はそのまま、本発明の第２実施形態に係るストレージ管理系ノード１のハードウェア構成を示している。
　また、図示はしないが、第２実施形態に係るデータベース管理システムのクライアント系ノード２及びトランザクション管理系ノード３の夫々は、図３に示すハードウェア構成と基本的に同様の構成を有している。
　よって、本発明の第２実施形態に係る、ストレージ管理系ノード１、クライアント系ノード２、及びトランザクション管理系ノード３の夫々のハードウェア構成の説明は省略する。

　また、第２実施形態に係るデータベース管理システムの機能的構成は、第１実施形態と同様である。即ち、図４はそのまま、本発明の第２実施形態に係るデータベース管理システムの機能的構成を示している。よって、本発明の第２実施形態に係るデータベース管理システムの機能的構成の説明は省略する。

　第２実施形態と第１実施形態の差異点は、対象データ管理部１１４が、論理時刻情報と、行番号情報と、管理対象のデータとを対応付けてデータベース１５０に蓄積して管理する対応付けの仕組みである。
　即ち、第１実施形態で採用された仕組みは、管理対象のデータ、当該管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌが、データベース１５０Ａのスキーマとして蓄積される仕組みであった。
　ここで、「最新の論理時刻」とは、現時点（例えば検索処理の開始時点）からみて直前の更新処理が行われた論理時刻に１を加えたものである。また、最新の論理時刻におけるデータベース、即ち最新の論理時刻より小さい論理時刻における更新処理が完了したデータベースを、「最新のデータベース」と呼ぶ。
　このような第１実施形態で採用される仕組みに対して、第２実施形態で採用される仕組みは、最新の論理時刻において有効な管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓが、第１のデータベース（例えば後述する図８のデータベース１５０Ｂ－１）のスキーマとして蓄積される仕組みである。また、第２実施形態で採用される仕組みは、最新の論理時刻において無効な管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌが、第２のデータベース（例えば後述するデータベース１５０Ｂ－２）のスキーマとして蓄積される仕組みである。

　さらに、以下、第２実施形態で採用される仕組みの詳細について、図８及び図９を用いて説明する。

　図８は、第２実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。

　図８（Ａ）には、最新のデータベースにおいて有効であるデータを蓄積するデータベース１５０Ｂ－１の例が示されている。
　図８（Ｂ）には、最新のデータベースにおいて無効であるデータを蓄積するデータベース１５０Ｂ－２の例が示されている。
　第２実施形態に係る対象データ管理部１１４は、挿入論理時刻ｘｔ＿ｉｎｓ、削除論理時刻ｘｔ＿ｄｅｌ、及び管理対象のデータ（有効と無効とを夫々区別したデータ）を対応付けて、データベース１５０Ｂ－１及びデータベース１５０Ｂ－２に蓄積する。

　具体的には例えば、図８（Ａ）のデータベース１５０Ｂ－１には、図５（Ｄ）に示すデータベース１５０－１６に含まれる管理対象のデータと、挿入論理時刻ｘｔ＿ｉｎｓとが対応づけられて蓄積されている。
　図８（Ｂ）のデータベース１５０Ｂ－２には、図６に示すデータベース１５０Ａのうち図８に示すデータベース１５０Ｂ－１に含まれない管理対象のデータと、挿入論理時刻ｘｔ＿ｉｎｓと、削除論理時刻ｘｔ＿ｄｅｌとが対応づけられて蓄積されている。換言すれば、データベース１５０Ｂ－２は、最新の論理時刻において無効である管理対象のデータの更新の履歴である。
　即ち、図８（Ａ）に示すデータベース１５０Ｂ－１及び図８（Ｂ）に示すデータベース１５０Ｂ－２には、最新の論理時刻において有効である管理対象のデータと無効である管理対象のデータとが、別のデータベースとして蓄積されている。

　即ち、対象データ管理部１１４は、最新の論理時刻において、有効である管理対象のデータを、データベース１５０Ｂ－１に蓄積する。また、対象データ管理部１１４は、最新の論理時刻において無効である管理対象のデータを、データベース１５０Ｂ－２に蓄積する。

　第２実施形態において、検索対象特定部１３１は、検索処理を行うとき、第１実施形態と同様に、検索対象論理時刻ｓｔにおいて有効であった管理対象のデータを、検索対象の候補のデータとして特定する。ここで、検索対象論理時刻ｓｔとは、上述したように、クライアント系ノード２から送信されてきた検索要求情報に含まれる論理時刻である。
　しかしながら、第２実施形態に係る検索対象特定部１３１は、以下のように検索する点で第１実施形態と異なる。

　まず、検索対象特定部１３１は、検索処理において指定された検索対象論理時刻ｓｔのデータを用いて、図８（Ａ）に示すデータベース１５０Ｂ－１から検索対象の候補のデータを特定する。
　具体的には例えば、検索対象特定部１３１は、データベース１５０Ｂ－１の行のデータの夫々のうち、第１実施形態で示した式（１）の条件を満たすデータを、検索対象の候補のデータとして特定する。これにより、検索対象特定部１３１は、最新の論理時刻において、有効なデータのうち、検索対象論理時刻ｓｔにおいて有効である管理対象のデータを、検索対象の候補のデータとして特定することができる。

　次に、検索対象特定部１３１は、図８（Ｂ）に示すデータベース１５０Ｂ－２から、検索対象の候補を特定する。即ち、検索対象特定部１３１は、検索処理において指定された検索対象論理時刻ｓｔのデータを用いて、図８（Ｂ）に示すデータベース１５０Ｂ－２から検索対象の候補のデータを特定する。
　具体的には例えば、検索対象特定部１３１は、データベース１５０Ｂ－２の行のデータの夫々のうち、第１実施形態で示した式（１）及び式（２）の条件を満たすデータを、検索対象の候補のデータとして特定する。例えば、管理対象のデータが削除される様な更新処理がされた後において、削除された管理対象のデータは、最新の論理時刻において無効な管理対象のデータである。検索対象特定部１３１は、第１実施形態で上述したのと同様に、検索対象論理時刻ｓｔにおいて有効であった管理対象のデータを、データベース１５０Ｂ－２から、検索対象の候補のデータとして特定する。

　更に、検索対象特定部１３１は、データベース１５０Ｂ－１から特定した検索対象の候補のデータと、データベース１５０Ｂ－２から特定した検索対象の候補のデータとの和集合を、総合的な検索対象の候補のデータとして特定する。
　ここで、総合的な検索対象の候補のデータが、検索部１３２おける検索対象特定部１３１により特定された検索対象の候補のデータとして採用され、検索に用いられる。

　なお、検索対象の候補として、最新の論理時刻において有効でない行のデータ（例えば、「ｔｉｄ」が「１００３」のデータ）は検索対象の候補とする必要がない場合、データベース１５０Ｂ－２から検索対象の候補を特定する必要はない。

　第２実施形態に係るデータベース管理システムは、上述のような一連の処理を行うことにより、以下のような効果を奏することができる。

　例えば、検索処理において、検索対象特定部１３１は、まず、最新の論理時刻において有効なデータが蓄積されたデータベース１５０Ｂ－１から、検索対象の候補のデータを特定する。検索処理において、多くの場合、検索対象論理時刻ｓｔとして最新の論理時刻が指定されて検索される。

　検索対象論理時刻ｓｔが最新の論理時刻である場合、検索対象特定部１３１は、データベース１５０Ｂ－２から検索対象の候補のデータを特定する必要はない。つまり、検索対象特定部１３１は、データベース１５０Ｂ－２の夫々の行のデータが、第１実施形態で示した式（１）及び式（２）の条件を満たすか否かを判定する処理を行わないようにすることができる。
　即ち、第２実施形態において、検索処理に係る処理のうち、第１実施形態で示した式（１）及び式（２）の条件を満たすか否かを判定する処理を削減できるため、検索処理に係る計算資源を節約することができる。

　図９は、第２実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、格納処理の一例を説明するフローチャートである。
　更新処理が行われることにより、データベース１５０Ｂ－１又はデータベース１５０Ｂ－２に蓄積して管理すべきデータ（管理対象のデータ）が発生すると、格納処理が開始されて、次のようなステップＳ２１乃至Ｓ２５の処理が実行される。

　即ち、ステップＳ２１において、論理時刻情報取得部１１２は、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。

　ステップＳ２２において、行番号情報取得部１１３は、管理対象のデータがデータベースにおけるいずれの行であるかを特定可能な情報を、行番号情報として取得する。

　ステップＳ２３において、対象データ管理部１１４は、ステップＳ２２の処理で取得された行番号情報に基づき、最新の論理時刻において有効なデータが蓄積されたデータベース１５０Ｂ－１の中に、無効になった管理対象のデータがあるか否かを判定する。
　無効になった管理対象のデータがある場合、ステップＳ２３の処理においてＹＥＳであると判定されて、処理はステップＳ２４に進む。

　ステップＳ２４において、対象データ管理部１１４は、ステップＳ２１の処理で取得された、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌと、無効になった管理対象のデータとを対応づけてデータベース１５０Ｂ－２に蓄積して管理する。

　ステップＳ２５において、対象データ管理部１１４は、ステップＳ２１の処理で取得された有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータとを対応づけてデータベース１５０Ｂ－１に蓄積して管理する。
　これにより、格納処理は終了する。

　以上、管理対象のデータの中に無効になったデータがある場合のステップＳ２３以降の処理について説明した。

　これに対して、管理対象のデータの中に無効になったデータが存在しない場合のステップＳ２３以降の処理は次のようになる。
　即ち、無効になったデータがない場合、ステップＳ２３の処理においてＮＯであると判定されて、処理はステップＳ２５に進む。即ち、無効になったデータがある場合に実行されたステップＳ２４の処理は、無効になった管理対象のデータがない場合には実行されない。

　ステップＳ２５において、対象データ管理部１１４は、ステップＳ２１の処理で取得された論理時刻情報を、有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓとして、有効になった管理対象のデータとを対応づけてデータベース１５０Ｂ－１に蓄積して管理する。
　これにより、格納処理は終了する。

　ここで、格納処理の理解を容易なものとすべく、データベース１５０Ｂ－１の中に無効になった管理対象のデータがある場合の第１の例と、データベース１５０Ｂ－１の中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明する。

　第１の例は、管理対象のデータとして、「Ａ」、「Ｂ」、及び「Ｃ」のスキーマを持つデータ群のうち、「ｔｉｄ」が「１００２」の管理対象のデータに対する更新処理が実行された場合の例である。
　なお、以下の説明において、上述の第１実施形態の説明と同様に、「Ａ」というスキーマが「ａ１」、「Ｂ」というスキーマが「ｂ１」、「Ｃ」というスキーマが「ｃ１」であることを、「（Ａ，Ｂ，Ｃ）＝（ａ１，ｂ１，ｃ１）」と記載する。
　第１の例では、更新処理前には、論理時刻１０乃至１２において、管理対象のデータが（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）であったものが、論理時刻＝「１２」における更新処理により、管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）に更新されたものとする。

　ステップＳ２１において、格納処理が実行される論理時刻を、論理時刻情報として取得する。具体的には、ステップＳ２１の処理は、無効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」及び削除論理時刻ｘｔ＿ｄｅｌ＝「１２」を論理時刻情報として取得する。また、具体的には、ステップＳ２１の処理は、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）の挿入論理時刻ｘｔ＿ｉｎｓ＝「１２」を論理時刻情報として取得する。

　ステップＳ２２において、行番号情報として「１００２」が取得される。
　第１の例では無効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）があるため、ステップＳ２３の処理においてＹＥＳであると判定されて、処理はステップＳ２４に進む。

　ステップＳ２４において、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌは、無効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）と対応づけられ、データベース１５０Ｂ－２に蓄積されて管理される。

　ステップＳ２５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓは、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）と対応づけられて、データベース１５０Ｂ－１に蓄積されて管理される。
　これにより格納処理は終了となる。

　以上、データベース１５０Ｂ－１の中に無効になった管理対象のデータがある場合の第１の例を用いて格納処理の説明をした。
　次に、データベース１５０Ｂ－１の中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をする。

　ステップＳ２１において、格納処理が実行される論理時刻を、論理時刻情報として取得する。具体的には、ステップＳ２１の処理は、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」を論理時刻情報として取得する。

　ステップＳ２２において、行番号情報として「１００３」が取得される。
　第２の例では無効になったデータがないため、ステップＳ２３の処理においてＮＯであると判定されて、処理はステップＳ２５に進む。

　ステップＳ２５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）とを対応づけて、データベース１５０Ｂ－１に蓄積されて管理される。
　これにより格納処理は終了となる。
　以上、データベース１５０Ｂ－１の中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をした。

　以上をまとめると、第１の例のように、管理対象のデータを書き換える様な更新処理の場合、更新処理により無効となる管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２，ｃ２）が、ステップＳ２４の処理によりデータベース１５０Ｂ－２に蓄積されて管理される。また、更新処理により、有効となる管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ２，ｂ２’，ｃ２’）が、ステップＳ２５の処理によりデータベース１５０Ｂ－１に蓄積されて管理される。
　また、第２の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップＳ２４の処理は実行されない。また、更新処理により、有効となる管理対象のデータ（Ａ，Ｂ，Ｃ）＝（ａ３，ｂ３，ｃ３）が、ステップＳ２５の処理によりデータベース１５０Ｂ－１に蓄積されて管理される。

　以上、格納処理の理解を容易なものとすべく、データベース１５０Ｂ－１の中に無効になった管理対象のデータがある場合の第１の例と、データベース１５０Ｂ－１の中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明した。

　以上、本発明の第２実施形態に係るデータベース管理システムについて説明した。
　次に、本発明の第３実施形態に係るデータベース管理システムについて説明する。

［第３実施形態］
　第３実施形態に係るデータベース管理システムの構成は、第１実施形態と同様である。即ち、図１はそのまま、本発明の第３実施形態に係るデータベース管理システムの構成を示している。よって、本発明の第３実施形態に係るデータベース管理システムの構成の説明は省略する。

　また、第３実施形態に係るストレージ管理系ノード１のハードウェア構成は、第１実施形態と同様である。即ち、図３はそのまま、本発明の第３実施形態に係るストレージ管理系ノード１のハードウェア構成を示している。
　また、図示はしないが、第３実施形態に係るデータベース管理システムのクライアント系ノード２及びトランザクション管理系ノード３の夫々は、図３に示すハードウェア構成と基本的に同様の構成を有している。
　よって、本発明の第３実施形態に係る、ストレージ管理系ノード１、クライアント系ノード２、及びトランザクション管理系ノード３の夫々のハードウェア構成の説明は省略する。

　また、第３実施形態に係るデータベース管理システムの機能的構成は、第１実施形態と同様である。即ち、図４はそのまま、本発明の第３実施形態に係るデータベース管理システムの機能的構成を示している。よって、本発明の第２実施形態に係るデータベース管理システムの機能的構成の説明は省略する。

　第３実施形態と第１実施形態の差異点は、対象データ管理部１１４が、論理時刻情報と、行番号情報と、管理対象のデータとを対応付けてデータベース１５０に蓄積して管理する対応付けの仕組みである。
　即ち、第１実施形態で採用された仕組みは、ＲＤＢＭＳにより管理されるリレーショナル形式のデータベースが採用されている仕組みであった。これにより、管理対象のデータ、当該管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌが、データベース１５０Ａのスキーマとして蓄積された。
　このような第１実施形態で採用される仕組みに対して、第３実施形態で採用される仕組みは、後述するＫＶＳにより管理されるデータベースが採用される仕組みである。詳細は後述するが、これにより、最新の論理時刻における有効な管理対象のデータ、無効な管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌが、データベース１５０ＣのＶａｌｕｅとして蓄積される。また、管理対象のデータの行番号情報が、データベース１５０ＣのＫｅｙとして蓄積される。即ち、第３実施形態で採用される仕組みは、ＫＶＳにより管理されるデータベース１５０Ｃを利用した仕組みである。

　そこで、以下、第３実施形態で採用される仕組みの詳細について、図１０乃至図１２を用いて説明する。

　第３実施形態において、データベースとして、ＫＶＳ（Ｋｅｙ－Ｖａｌｕｅ　Ｓｔｏｒｅ）により管理されるデータベースが採用されているものとする。
　ＫＶＳとは、キーと値（Ｖａｌｕｅ）の組を大量に蓄積し、キーを指定して検索を高速に実行可能なデータベース管理システムのことである。ＫＶＳにより管理されるデータベースは、ＲＤＢＭＳにより管理されるリレーショナル形式のデータベースと比較して、機能が極めて限定されている代わりに、性能が高いという特徴がある。

　図１０は、第３実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、検索対象の候補のデータの例を示す図である。
　具体的には、図１０は、第３実施形態におけるストレージ管理系ノード１で管理されるデータベース１５０に含まれる、検索対象論理時刻ｓｔが「１１」の場合の検索対象の候補のデータのリレーションＲＣを示す図である。

　第３実施形態に係る対象データ管理部１１４は、挿入論理時刻ｘｔ＿ｉｎｓ、削除論理時刻ｘｔ＿ｄｅｌ、及び管理対象のデータを対応付けて、データベース１５０Ｃに蓄積する。

　具体的には例えば、図１０に示すリレーションＲＣは、ＫＶＳにより管理されており、スキーマとしてＫｅｙとＶａｌｕｅとを持つ。ここで、図１０に示すリレーションＲＣに示すように、第１実施形態や第２実施形態における行番号「ｔｉｄ」に対応する行番号が、「Ｋｅｙ」として管理される。また、第１実施形態や第２実施形態における管理対象のデータは、「Ｖａｌｕｅ」として管理される。

　図１１は、第３実施形態における図１のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。

　図１１には、ＫＶＳにより管理されるデータベース１５０Ｃの例が示されている。

　図１１のデータベース１５０Ｃには、図６に示すデータベース１５０Ａに含まれる管理対象のデータと、挿入論理時刻ｘｔ＿ｉｎｓと、削除論理時刻ｘｔ＿ｄｅｌとが対応づけられたデータが、ＫＶＳにより管理されるデータベースとして蓄積されている。
　具体的には、図１１に示すデータベース１５０Ｃは、図１０に示すリレーションＲＣと同様に、ＫＶＳにより管理されており、スキーマとしてＫｅｙとＶａｌｕｅとを持つ。ここで、図１１に示すデータベース１５０Ｃに示すように、第１実施形態や第２実施形態における行番号「ｔｉｄ」は、「Ｋｅｙ」として管理される。また、第１実施形態や第２実施形態における管理対象のデータは、「Ｖａｌｕｅ」として管理される。

　第３実施形態において、検索対象特定部１３１は、検索処理を行うとき、第１実施形態と同様に、検索対象論理時刻ｓｔに有効であった管理対象のデータを、検索対象の候補のデータとして特定する。ここで、検索対象論理時刻ｓｔとは、上述したように、クライアント系ノード２から送信されてきた検索要求情報に含まれる論理時刻である。
　しかしながら、第３実施形態に係る検索対象特定部１３１は、以下のように検索する点で第１実施形態と異なる。

　まず、検索対象特定部１３１は、検索処理において指定された行番号情報を用いて、図１１に示すデータベース１５０Ｃから、検索対象の候補のデータを特定する。
　具体的には例えば、検索対象特定部１３１は、データベース１５０Ｃの行のデータの夫々のうち、検索内容に関する行番号の情報を、行番号情報として指定する。即ち、検索対象特定部１３１は、行番号情報に基づき、ＫＶＳで管理されるデータベース１５０Ｃにおける「Ｋｅｙ」と一致する行を、検索対象の候補のデータとして特定する。これにより、検索対象特定部１３１は、行番号情報により特定された検索対象の候補のデータの夫々のＶａｌｕｅの夫々が取得できる。

　次に、検索対象特定部１３１は、検索対象の候補のデータのＶａｌｕｅのデータの夫々のうち、第１実施形態で示した式（１）及び式（２）の条件を満たすデータを検索対象の候補のデータとして特定する。これにより、検索対象の候補のデータのうち、検索対象論理時刻ｓｔにおける管理対象のデータを、総合的な検索対象の候補のデータとして特定することができる。

　上述のような第３実施形態の処理を行うことにより、以下のような効果を奏することができる。

　例えば、第１実施形態において、説明の簡単のため、データベースとして、ＲＤＢＭＳにより管理されるリレーショナル形式のデータベースが採用されているものとした。しかし、第３実施形態に示したように、ＫＶＳにより管理されるデータベース１５０Ｃにおいても、論理時刻情報と、行番号情報と、管理対象のデータとを対応付けて蓄積することができる。

　また、ＫＶＳにより管理されるデータベース１５０Ｃは、ＲＤＢＭＳにより管理されるリレーショナル形式のデータベースと比較して、機能が極めて限定されている代わりに、性能が高い。即ち、データの様式や更新の有無によっては、ＫＶＳにより管理されるデータベース１５０Ｃを採用したデータベース管理システムは、ＲＤＢＭＳにより管理されるリレーショナル形式のデータベースと比較して性能が高いシステムとなる可能性がある。

　図１２は、第３実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象のデータの管理の流れの例を説明するフローチャートである。
　更新処理が行われることにより、データベース１５０Ｃに蓄積して管理すべきデータ（管理対象のデータ）が発生すると、格納処理が開始されて、次のようなステップＳ３１乃至Ｓ３５の処理が実行される。

　即ち、ステップＳ３１において、論理時刻情報取得部１１２は、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。

　ステップＳ３２において、行番号情報取得部１１３は、管理対象のデータがデータベースにおけるいずれの行であるかを特定可能な情報を、行番号情報として取得する。

　ステップＳ３３において、対象データ管理部１１４は、ステップＳ３２の処理で取得された行番号情報に基づき、最新の論理時刻において有効なデータが蓄積されたデータベース１５０Ｃの中に、無効になった管理対象のデータがあるか否かを判定する。
　無効になった管理対象のデータがある場合、ステップＳ３３の処理においてＹＥＳであると判定されて、処理はステップＳ３４に進む。

　ステップＳ３４において、対象データ管理部１１４は、ステップＳ３１の処理で取得された、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌと、無効になった管理対象のデータとを対応づけてデータベース１５０Ｃに蓄積して管理する。

　ステップＳ３５において、対象データ管理部１１４は、ステップＳ３１の処理で取得された有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータとを対応づけてデータベース１５０Ｃに蓄積して管理する。
　これにより、格納処理は終了する。

　以上、管理対象のデータの中に無効になったデータがある場合のステップＳ３３以降の処理について説明した。

　これに対して、管理対象のデータの中に無効になったデータが存在しない場合のステップＳ３３以降の処理は次のようになる。
　即ち、無効になったデータがない場合、ステップＳ３３の処理においてＮＯであると判定されて、処理はステップＳ３５に進む。即ち、無効になったデータがある場合に実行されたステップＳ３４の処理は、無効になった管理対象のデータがない場合には実行されない。

　ステップＳ３５において、対象データ管理部１１４は、ステップＳ３１の処理で取得された論理時刻情報を、有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓとして、有効になった管理対象のデータとを対応づけてデータベース１５０Ｃに蓄積して管理する。
　これにより、格納処理は終了する。

　ここで、格納処理の理解を容易なものとすべく、データベース１５０Ｃの中に無効になった管理対象のデータがある場合の第１の例と、データベース１５０Ｃの中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明する。

　第１の例は、管理対象のデータとして、ＫＶＳにより管理されるデータベースに含まれるデータ群のうち、「Ｋｅｙ」が「１００２」の管理対象のデータに対する更新処理が実行された場合の例である。
　なお、以下の説明において、「挿入論理時刻ｘｔ＿ｉｎｓ」が「７」であることを、「ｘｔ＿ｉｎｓ＝７」と記載する。同様に、「削除論理時刻ｘｔ＿ｄｅｌ」が「∞」であることを「ｘｔ＿ｄｅｌ＝∞」、「Ｖａｌｕｅ」が「ＡＢＣＤＥＦＧ」であることを「ｖａｌｕｅ＝ＡＢＣＤＥＦＧ」と夫々記載する。また、この様な挿入論理時刻ｘｔ＿ｉｎｓと、削除論理時刻ｘｔ＿ｄｅｌと、Ｖａｌｕｅとが対応付けられたものを、「｛ｘｔ＿ｉｎｓ＝７，ｘｔ＿ｄｅｌ＝∞，ｖａｌｕｅ＝ＡＢＣＤＥＦＧ｝」と記載する。
　第１の例では、更新処理前には、論理時刻１０乃至１２において、管理対象のデータが「ｖａｌｕｅ＝ｈｉｊｋｌｍｎｏｐ」であったものが、論理時刻１２における更新処理により、管理対象のデータが「ｖａｌｕｅ＝ＨＩＪＫＬＭＮＯＰ」に更新されたものとする。

　ステップＳ３１において、格納処理が実行される論理時刻を、論理時刻情報として取得する。具体的には、ステップＳ３１の処理は、無効になった管理対象のデータ「ｖａｌｕｅ＝ｈｉｊｋｌｍｎｏｐ」の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」及び削除論理時刻ｘｔ＿ｄｅｌ＝「１２」を論理時刻情報として取得する。また、具体的には、ステップＳ３１の処理は、有効になった管理対象のデータ「ｖａｌｕｅ＝ＨＩＪＫＬＭＮＯＰ」の挿入論理時刻ｘｔ＿ｉｎｓ＝「１２」を論理時刻情報として取得する。

　ステップＳ３２において、行番号情報として「１００２」が取得される。
　第１の例では無効になった管理対象のデータ「ｖａｌｕｅ＝ｈｉｊｋｌｍｎｏｐ」があるため、ステップＳ３３の処理においてＹＥＳであると判定されて、処理はステップＳ３４に進む。

　ステップＳ３４において、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌは、無効になった管理対象のデータ「ｖａｌｕｅ＝ｈｉｊｋｌｍｎｏｐ」と対応づけられ、データベース１５０Ｃに蓄積されて管理される。

　ステップＳ３５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓは、有効になった管理対象のデータ「ｖａｌｕｅ＝ＨＩＪＫＬＭＮＯＰ」と対応づけられて、データベース１５０Ｃに蓄積されて管理される。
　これにより格納処理は終了となる。

　以上、データベース１５０Ｃの中に無効になった管理対象のデータがある場合の第１の例を用いて格納処理の説明をした。
　次に、データベース１５０Ｃの中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をする。

　第２の例は、管理対象のデータとして、ＫＶＳにより管理されるデータベースに含まれるデータ群のうち、「Ｋｅｙ」が「１００３」の管理対象のデータに対する更新処理が実行された場合の例である。
　第２の例では、更新処理前には、論理時刻１０までにおいて、「Ｋｅｙ」が「１００３」の管理対象のデータは存在しなかったが、論理時刻１０における更新処理により、管理対象のデータ「ｖａｌｕｅ＝１２３４５６７８９０」が更新（追加）されたものとする。

　ステップＳ３１において、格納処理が実行される論理時刻を、論理時刻情報として取得する。具体的には、ステップＳ３１の処理は、有効になった管理対象のデータ「ｖａｌｕｅ＝１２３４５６７８９０」の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」を論理時刻情報として取得する。

　ステップＳ３２において、行番号情報として「１００３」が取得される。
　第２の例では無効になったデータがないため、ステップＳ２３の処理においてＮＯであると判定されて、処理はステップＳ３５に進む。

　ステップＳ３５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータ「ｖａｌｕｅ＝１２３４５６７８９０」とを対応づけて、データベース１５０Ｃに蓄積されて管理される。
　これにより格納処理は終了となる。
　以上、データベース１５０Ｃの中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をした。

　以上をまとめると、第１の例のように、管理対象のデータを書き換える様な更新処理の場合、更新処理により無効となる管理対象のデータ「ｖａｌｕｅ＝ｈｉｊｋｌｍｎｏｐ」が、ステップＳ３４の処理によりデータベース１５０Ｃに蓄積されて管理される。また、更新処理により、有効となる管理対象のデータ「ｖａｌｕｅ＝ＨＩＪＫＬＭＮＯＰ」が、ステップＳ３５の処理によりデータベース１５０Ｃに蓄積されて管理される。
　また、第２の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップＳ３４の処理は実行されない。また、更新処理により、有効となる管理対象のデータ「ｖａｌｕｅ＝１２３４５６７８９０」が、ステップＳ３５の処理によりデータベース１５０Ｃに蓄積されて管理される。

　以上、格納処理の理解を容易なものとすべく、データベース１５０Ｃの中に無効になった管理対象のデータがある場合の第１の例と、データベース１５０Ｃの中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明した。

　以上、本発明の第３実施形態に係るデータベース管理システムについて説明した。
　次に、本発明の第４実施形態に係るデータベース管理システムについて説明する。

［第４実施形態］
　第４実施形態に係るデータベース管理システムの構成は、第１実施形態と同様である。即ち、図１はそのまま、本発明の第４実施形態に係るデータベース管理システムの構成を示している。よって、本発明の第４実施形態に係るデータベース管理システムの構成の説明は省略する。

　また、第４実施形態に係るストレージ管理系ノード１のハードウェア構成は、第１実施形態と同様である。即ち、図３はそのまま、本発明の第４実施形態に係るストレージ管理系ノード１のハードウェア構成を示している。
　また、図示はしないが、第４実施形態に係るデータベース管理システムのクライアント系ノード２及びトランザクション管理系ノード３の夫々は、図３に示すハードウェア構成と基本的に同様の構成を有している。
　よって、本発明の第４実施形態に係る、ストレージ管理系ノード１、クライアント系ノード２、及びトランザクション管理系ノード３の夫々のハードウェア構成の説明は省略する。

　また、第４実施形態に係るデータベース管理システムの機能的構成は、第１実施形態と同様である。即ち、図４はそのまま、本発明の第４実施形態に係るデータベース管理システムの機能的構成を示している。よって、本発明の第４実施形態に係るデータベース管理システムの機能的構成の説明は省略する。

　第４実施形態と第１実施形態の差異点は、対象データ管理部１１４が、論理時刻情報と、行番号情報と、管理対象のデータとを対応付けてデータベース１５０を蓄積して管理する対応付けの仕組みである。
　即ち、第１実施形態で採用された仕組みは、データベースにより、挿入論理時刻ｘｔ＿ｉｎｓ等が対応づけられて管理される仕組みであった。具体的には、管理対象のデータ、当該管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌの夫々が、データベース１５０Ａのスキーマの夫々として蓄積された。
　このような第１実施形態で採用される仕組みに対して、第４実施形態で採用される仕組みは、後述するファイル名として、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ等が対応づけられて管理される仕組みである。詳細は後述するが、これにより、管理対象のデータが、ファイルの内容として管理される。また、管理対象のデータの行番号情報、挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌが、ファイル名として管理される。即ち、第４実施形態で採用される仕組みは、ファイル名により管理対象のデータが管理される仕組みである。

　そこで、以下、第４実施形態で採用される仕組みの詳細について、図１３乃至図１５を用いて説明する。
　第４実施形態に係る対象データ管理部１１４は、挿入論理時刻ｘｔ＿ｉｎｓ、削除論理時刻ｘｔ＿ｄｅｌ、及び行番号情報をファイル名として、管理対象のデータをファイルの内容として、ファイルとそのファイルのファイル名とを対応付けて、記憶部１８に格納する。つまり、第４実施形態におけるデータベースは、記憶部１８に、複数のファイルとして格納されたファイル群である。

　ここで、説明を簡単にするため、第４実施形態における管理対象のデータは１行のテキストデータであり、当該テキストデータはテキストファイルとして管理されるものとする。即ち、１つのテキストファイルは第１実施形態乃至第３実施形態における１行の管理対象のデータに対応する。

　図１３は、第４実施形態における図１のストレージ管理系ノード１で管理されるファイルにおける、ファイル名と内容の例を示す図である。以下、ファイル名と内容の対応を示す表を、「ファイル名内容対応表」と呼ぶ。

　具体的には、図１３は、第４実施形態におけるストレージ管理系ノード１で管理されるファイルにおける、検索対象論理時刻ｓｔが「１１」の場合のファイル名内容対応表ＲＤを示す図である。換言すれば、図１３に示すファイル名内容対応表ＲＤは、検索対象論理時刻ｓｔが「１１」の場合の検索対象の候補のデータである。
　また、第４実施形態におけるストレージ管理系ノードで管理されるファイルのファイル名は、図１３に示すファイル名内容対応表ＲＤに示すように付与されている。即ち、図１３に示すファイル名内容対応表ＲＤは、第１実施形態乃至第３実施形態の行番号情報「ｔｉｄ」の代わりに、行を特定する情報として図１３に示すファイル名内容対応表ＲＤの「ファイル名」を採用している。

　図１４は、第４実施形態における図１のストレージ管理系ノードで管理されるデータベースのファイルのファイル名を、論理時刻と対応づけたファイル名として管理する例を示す図である。

　図１４には、ストレージ管理系ノード１の記憶部１８に格納されるファイルのファイル名と、ファイルの内容の例が示されている。

　図１４の記憶部１８には、ファイル名が「ｂａｒ（１０，１２）」のファイルの内容として、「ｈｉｊｋｌｍｎｏｐ」が、格納されている。「ｂａｒ（１０，１２）」というファイル名は、行を特定する情報が「ｂａｒ」、挿入論理時刻ｘｔ＿ｉｎｓが「１０」、削除論理時刻ｘｔ＿ｄｅｌが「１２」、であることを示している。

　即ち、第４実施形態の対象データ管理部１１４は、行を特定する情報と、挿入論理時刻ｘｔ＿ｉｎｓと、削除論理時刻ｘｔ＿ｄｅｌとをファイル名として記憶部１８に記憶する。

　第４実施形態において、検索処理を行うとき、検索対象特定部１３１は、第１実施形態と同様に、検索対象論理時刻ｓｔに有効であった管理対象のデータを、検索対象の候補のデータとして特定する。しかしながら、第４実施形態に係る検索対象特定部１３１は、以下のように検索する点で第１実施形態と異なる。

　まず、検索対象特定部１３１は、検索処理において指定された行番号情報、挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌを用いて、図１４に示す記憶部１８に格納されたファイルから、検索対象の候補のデータが含まれるファイルを特定する。

　具体的には例えば、検索対象特定部１３１は、図１４に示す記憶部１８に格納されたファイルのファイル名、行を特定する情報、挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌに基づき、条件に一致するファイル名のファイルを特定する。つまり、検索対象特定部１３１は、ファイル名から特定された行を特定する情報、挿入論理時刻ｘｔ＿ｉｎｓ、及び、削除論理時刻ｘｔ＿ｄｅｌの夫々に基づき、条件に一致するファイル名のファイルを検索対象の候補のデータとして特定する。

　「ｂａｒ（１０，１２）」というファイル名のファイルがある場合、行を特定する情報が「ｂａｒ」、挿入論理時刻ｘｔ＿ｉｎｓが「１０」、削除論理時刻ｘｔ＿ｄｅｌが「１２」であると識別する。検索対象特定部１３１は、検索対象論理時刻ｓｔに基づき、ファイル名から識別した挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌに対して、第１実施形態で示した式（１）及び式（２）の条件を満たすか否かを判定する。これにより、「ｂａｒ（１０，１２）」というファイル名のファイルが、検索対象論理時刻ｓｔにおいて有効であったかを判定することができる。
　検索対象特定部１３１は、上述の判定を、複数のファイルの夫々に対して行うことで、総合的な検索対象論理時刻とする。
　ここで、総合的な検索対象の候補のデータが、検索部１３２おける検索対象特定部１３１により特定された検索対象の候補のデータとして採用され、検索に用いられる。

　即ち、検索対象特定部１３１は、ファイル名から識別された挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌの夫々が、第１実施形態で示した式（１）及び式（２）の条件を満たすファイル名であるかを判定する。これにより、検索対象の候補のデータのうち、検索対象論理時刻ｓｔにおける管理対象のデータを、検索対象の候補のデータとして特定することができる。

　第４実施形態に係るデータベース管理システムは、上述のような一連の処理を行うことにより、以下のような効果を奏することができる。

　例えば、第４実施形態において、記憶部１８に格納されるファイルは、データベースに限らず、例えば、テキストファイル等、任意のファイル形式のファイルで良い。この場合、第４実施形態における検索対象特定部１３１は、特定された検索対象の候補のデータとして、ファイルをクライアントに提供することができる。即ち、第４実施形態に係るデータベース管理システムは、管理対象のファイル（データ）を、挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌと対応づけて格納することができる。
　これにより、挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、データベース管理システムにおけるスキーマとして管理せず、ファイル名とすることで管理することができる。即ち、通常データベースにおいて処理するＳＱＬ等による処理が不要となり、検索処理における計算資源の消費が削減される。

　図１５は、第４実施形態における図４の機能的構成を有するストレージ管理系ノードにより実行される、管理対象データの管理の流れの一例を説明するフローチャートである。即ち、第４実施形態におけるストレージ管理系ノードにより実行される、格納処理の一例を説明するフローチャートである。
　更新処理が行われることにより、記憶部１８に格納して管理すべきデータ（管理対象のデータ）が発生すると、格納処理が開始されて、次のようなステップＳ４１乃至Ｓ４５の処理が実行される。

　即ち、ステップＳ４１において、論理時刻情報取得部１１２は、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。

　ステップＳ４２において、行番号情報取得部１１３は、管理対象のデータがデータベースにおけるいずれの行であるかを特定可能な情報を、行番号情報として取得する。

　ステップＳ４３において、対象データ管理部１１４は、ステップＳ４２の処理で取得された行番号情報に基づき、記憶部１８の中に、無効になった管理対象のデータがあるか否かを判定する。
　無効になった管理対象のデータがある場合、ステップＳ４３の処理においてＹＥＳであると判定されて、処理はステップＳ４４に進む。

　ステップＳ４４において、対象データ管理部１１４は、ステップＳ４１の処理で取得された、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌと、無効になった管理対象のデータ（ファイル）とを対応づけて記憶部１８に格納して管理する。

　ステップＳ４５において、対象データ管理部１１４は、ステップＳ４１の処理で取得された有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータ（ファイル）とを対応づけて記憶部１８に格納して管理する。
　これにより、格納処理は終了する。

　以上、管理対象のデータの中に無効になったデータがある場合のステップＳ４３以降の処理について説明した。

　これに対して、管理対象のデータの中に無効になったデータが存在しない場合のステップＳ４３以降の処理は次のようになる。
　即ち、無効になったデータがない場合、ステップＳ４３の処理においてＮＯであると判定されて、処理はステップＳ４５に進む。即ち、無効になったデータがある場合に実行されたステップＳ４４の処理は、無効になった管理対象のデータがない場合には実行されない。

　ステップＳ４５において、対象データ管理部１１４は、ステップＳ４１の処理で取得された論理時刻情報を、有効になったデータの挿入論理時刻ｘｔ＿ｉｎｓとして、有効になった管理対象のデータとを対応づけて記憶部１８に格納して管理する。
　これにより、格納処理は終了する。

　ここで、格納処理の理解を容易なものとすべく、記憶部１８の中に無効になった管理対象のデータがある場合の第１の例と、記憶部１８の中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明する。

　第１の例は、管理対象のデータとして、ファイルが管理されるファイル群のうち、行を特定する情報が「ｂａｒ」の管理対象のデータに対する更新処理が実行された場合の例である。
　第１の例では、更新処理前には、論理時刻１０乃至１２において、管理対象のデータが「ｈｉｊｋｌｍｎｏｐ」であったものが、論理時刻１２における更新処理により、管理対象のデータ「ＨＩＪＫＬＭＮＯＰ」に更新されたものとする。

　ステップＳ４１において、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。具体的には、ステップＳ４１の処理は、無効になった管理対象のデータ「ｈｉｊｋｌｍｎｏｐ」の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」及び削除論理時刻ｘｔ＿ｄｅｌ＝「１２」を論理時刻情報として取得する。また、具体的には、ステップＳ４１の処理は、有効になった管理対象のデータ「ＨＩＪＫＬＭＮＯＰ」の挿入論理時刻ｘｔ＿ｉｎｓ＝「１２」を論理時刻情報として取得する。

　ステップＳ４２において、行を特定するとして「ｂａｒ」が取得される。
　第１の例では無効になった管理対象のデータ「ｈｉｊｋｌｍｎｏｐ」があるため、ステップＳ４３の処理においてＹＥＳであると判定されて、処理はステップＳ４４に進む。

　ステップＳ４４において、無効になった管理対象のデータの削除論理時刻ｘｔ＿ｄｅｌは、無効になった管理対象のデータ「ｈｉｊｋｌｍｎｏｐ」と対応づけられて記憶部１８に格納されて管理される。

　ステップＳ４５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓは、有効になった管理対象のデータ「ＨＩＪＫＬＭＮＯＰ」と対応づけられて、記憶部１８に格納されて管理される。
　これにより格納処理は終了となる。

　以上、記憶部１８の中に無効になった管理対象のデータがある場合の第１の例を用いて格納処理の説明をした。
　次に、記憶部１８の中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をする。

　第２の例は、管理対象のデータとして、ファイルが管理されるファイル群のうち、行を特定する情報が「ｂａｚ」の管理対象のデータに対する更新処理が実行された場合の例である。
　第２の例では、更新処理前には、論理時刻が「１０」である時刻までにおいて、行を特定する情報が「ｂａｚ」の管理対象のデータは存在しなかったが、論理時刻１０における更新処理により、管理対象のデータ「１２３４５６７８９０」が更新（追加）されたものとする。

　ステップＳ４１において、管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓ及び削除論理時刻ｘｔ＿ｄｅｌを、論理時刻情報として取得する。具体的には、ステップＳ４１の処理は、有効になった管理対象のデータ「１２３４５６７８９０」の挿入論理時刻ｘｔ＿ｉｎｓ＝「１０」を論理時刻情報として取得する。また、ステップＳ４１の処理は、有効になった管理対象のデータ「１２３４５６７８９０」の削除論理時刻ｘｔ＿ｄｅｌ＝「∞」を論理時刻情報として取得する。なお、上述で説明した通り、削除論理時刻ｘｔ＿ｄｅｌ＝「∞」という論理時刻情報は、削除論理時刻ｘｔ＿ｄｅｌが未定である旨を示す論理時刻情報である。なお、図１４に示す記憶部１８のファイル名は、論理時刻が「１５」において、行を特定する情報が「ｂａｚ」の管理対象のデータが削除される更新処理が行われた場合におけるファイル名である。

　ステップＳ４２において、行を特定する情報として「ｂａｚ」が取得される。
　第２の例では無効になったデータがないため、ステップＳ４３の処理においてＮＯであると判定されて、処理はステップＳ４５に進む。

　ステップＳ４５において、有効になった管理対象のデータの挿入論理時刻ｘｔ＿ｉｎｓと、有効になった管理対象のデータ「１２３４５６７８９０」とを対応づけて、記憶部１８に格納されて管理される。
　これにより格納処理は終了となる。
　以上、記憶部１８の中に無効になった管理対象のデータがない場合の第２の例を用いて格納処理の説明をした。

　以上をまとめると、第１の例のように、管理対象のデータを書き換える様な更新処理の場合、更新処理により無効となる管理対象のデータ「ｈｉｊｋｌｍｎｏｐ」が、ステップＳ４４の処理により記憶部１８に格納されて管理される。また、更新処理により、有効となる管理対象のデータ「ＨＩＪＫＬＭＮＯＰ」が、ステップＳ４５の処理により記憶部１８に格納されて管理される。
　また、第２の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップＳ４４の処理は実行されない。また、更新処理により、有効となる管理対象のデータ「１２３４５６７８９０」が、ステップＳ４５の処理により記憶部１８に格納されて管理される。

　以上、格納処理の理解を容易なものとすべく、記憶部１８の中に無効になった管理対象のデータがある場合の第１の例と、記憶部１８の中に無効になった管理対象のデータがない場合の第２の例との夫々における格納処理について説明した。

　以上、本発明の実施形態の夫々について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

　例えば、第１実施形態の説明において、更新要求整合性管理部３２２は、データベースの整合性が崩れるか否かを判定して、整合性が維持されることが確実である場合にのみ、ストレージ管理系ノード１に更新要求情報を送信するとした。更新要求整合性管理部３２２は、具体的に以下のような処理を行うことで、整合性の管理を行ってもよい。

　具体的には例えば、まず、トランザクション管理系ノード３は、更新要求整合性管理部３２２は、ストレージ管理系ノード１に更新要求情報を送信する。次に、トランザクション管理系ノード３は、更新の内容を処理した場合にデータベースの整合性が崩れるか否かを、ストレージ管理系ノード１に判定させることができる。ここで、整合性が維持されることが確実である場合にのみ、トランザクション管理系ノード３は、ストレージ管理系ノード１に更新の内容を確定（トランザクションをコミット）させることができる。また、整合性が維持されることが確実でない場合に、トランザクション管理系ノード３は、ストレージ管理系ノード１に更新の内容を破棄させることができる。

　更に言えば、更新要求整合性管理部３２２は、整合性の管理にＳＩの方式を採用して管理してよい。以下、整合性の管理にＳＩの方式を採用した場合について説明する。ここで、トランザクション管理系ノード３は、トランザクション管理系ノード３－１，３－２の２台が存在し、同時に更新処理を行っているものとして説明する。また、トランザクション管理系ノード３－１，３－２は、１つのストレージ管理系ノード１に更新要求を送信するものとする。また、トランザクション管理系ノード３－１，３－２は、更新の内容を処理した場合にデータベースの整合性が崩れるか否かを、ストレージ管理系ノード１に判定させる。なお、トランザクション管理系ノード３－１が更新要求整合性管理部３２２－１を有し、トランザクション管理系ノード３－２が更新要求整合性管理部３２２－２を有するものとして説明する。

　まず、トランザクション管理系ノード３－１の更新要求整合性管理部３２２－１は、対象データ管理部１１４により管理される、論理時刻情報と、行番号情報と、管理対象のデータとが対応付けられたデータベース１５０を、ストレージ管理系ノード１に複製させる。例えば、更新要求整合性管理部３２２－１は、最新のデータベースの複製であるスナップショットのデータベース１５０－１Ｓを、ストレージ管理系ノード１に生成させる。即ち、スナップショットのデータベース１５０－１Ｓは、最新のデータベースが複製されたデータベースの１つである。ここで、スナップショットのデータベース１５０－１Ｓは、ストレージ管理系ノード１のＲＡＭ１３や記憶部１８の一領域に記憶されていてよい。即ち、スナップショットのデータベース１５０－１Ｓは、記憶部１８に記憶されたデータベース１５０と異なる領域に記憶されてよい。

　次に、更新要求整合性管理部３２２－１は、スナップショットのデータベース１５０－１Ｓに対して更新処理を行い、更新されたスナップショットのデータベース１５０－１Ｍを生成する。このとき、更新されたスナップショットのデータベース１５０－１Ｍは、スナップショットのデータベース１５０－１に含まれる管理対象のデータのうち、一部（いくつかの行のデータ）が更新（変更）されたデータベースとなっている。ここで、更新されたスナップショットのデータベース１５０－１Ｍは、ストレージ管理系ノード１のＲＡＭ１３や記憶部１８の一領域に記憶されていてよい。即ち、更新されたスナップショットのデータベース１５０－１Ｍは、記憶部１８に記憶されたデータベース１５０と異なる領域に記憶されてよい。

　ここで、上述した更新要求整合性管理部３２２－１が管理する更新処理がなされている間に、トランザクション管理系ノード３－２の更新要求整合性管理部３２２－２は、他の更新処理を管理（処理）している。即ち、更新要求整合性管理部３２２－２は、ストレージ管理系ノード１に、スナップショットのデータベース１５０－２Ｓや更新されたスナップショットのデータベース１５０－２Ｍを生成や管理させている。

　更に言えば、トランザクション管理系ノード３－１の更新要求整合性管理部３２２－１が上述の更新処理を行っている間に、トランザクション管理系ノード３－２の更新要求整合性管理部３２２－２が、更新処理を行い、完了している可能性がある。そこで、トランザクション管理系ノード３－１の更新要求整合性管理部３２２－１は、データベース１５０のうち、更新処理により書き換えるべき管理対象のデータが、他の更新処理により更新されていないかを、ストレージ管理系ノード１に管理させることができる。

　この時、データベース１５０に含まれるデータのうち、上述の更新処理により更新された一部のデータが、既に更新されていない場合、当該一部のデータのみを、データベース１５０に書き戻す。これにより、更新要求整合性管理部３２２－１は、スナップショットのデータベース１５０－１Ｓと更新されたスナップショットのデータベース１５０－１Ｍとの間で差異のある管理対象のデータを、ストレージ管理系ノード１のデータベース１５０に反映させる。

　また、データベース１５０に含まれるデータのうち、上述の更新処理により更新された一部のデータが、既に更新されている場合、更新処理の結果やスナップショットのデータベース１５０－１Ｍ等は破棄される。これにより、更新処理の内容は、データベース１５０に反映されない。この場合、更新要求整合性管理部３２２－１は、更新処理をスナップショットの生成からやり直してもよいし、クライアント系ノード２に更新処理が失敗した旨を通知してもよい。

　これにより、更新要求整合性管理部３２２は、ストレージ管理系ノード１に格納されたデータベース１５０の整合性が維持されるか否かを検証し、整合性が維持される場合のみ、実際にデータベース１５０に更新処理を反映することができる。即ち、データベース１５０の整合性が維持される。
　このように同時並行的に更新処理が管理される場合、先に反映（コミット）された更新処理の内容は、後に反映（コミット）されようとする更新処理の内容に優先する。更には、先に反映された更新処理の内容により変更されていない場合にのみ、後に反映されようとする更新処理の内容が反映される。このように、「先に反映（コミット）された更新処理の内容は、後に反映（コミット）されようとする更新処理の内容に優先する」といったルールを、「Ｆｉｒｓｔ－Ｃｏｍｍｉｔｔｅｒ－Ｗｉｎｓ　Ｒｕｌｅ」と呼ぶ。

　なお、ストレージ管理系ノード１やトランザクション管理系ノード３は、上述の「Ｆｉｒｓｔ－Ｃｏｍｍｉｔｔｅｒ－Ｗｉｎｓ　Ｒｕｌｅ」に則って、更新処理を管理すれば足りる。即ち、ストレージ管理系ノード１は、必ずしも、上述のようにスナップショットのデータベース１５０－１Ｓや、更新されたスナップショットのデータベース１５０－１Ｍを生成や管理をする必要はない。つまり、ストレージ管理系ノード１は、スナップショットのデータベース１５０－１Ｓや、更新されたスナップショットのデータベース１５０－１Ｍを生成しなくてもよい。
　例えば、ストレージ管理系ノード１は、スナップショットのデータベース１５０－１Ｓと更新されたスナップショットのデータベース１５０－１Ｍを生成しない。この場合、ストレージ管理系ノード１は、更新処理によって差異が生じる管理対象のデータについて、当該差異等を管理する。

　更に言えば、上述の差異等は、ストレージ管理系ノード１ではなく、トランザクション管理系ノード３－１，３－２により管理されてよい。この場合、トランザクション管理系ノード３－１，３－２は、協働して、更新処理による差異を管理する。また、上述の例における、更新要求整合性管理部３２２－１により管理される更新処理と、更新要求整合性管理部３２２－２により管理される更新処理とが存在する場合、当該差異について先に処理された更新処理を優先する。
　即ち、トランザクション管理系ノード群Ｇ３は、複数の更新処理を、更新処理に係る差異として管理したうえで、「Ｆｉｒｓｔ－Ｃｏｍｍｉｔｔｅｒ－Ｗｉｎｓ　Ｒｕｌｅ」に則って、ストレージ管理系ノード１のデータベース１５０に反映（コミット）する。

　上述のように、整合性の管理にＳＩの方式を採用する場合、更新要求情報は、以下の情報を含んでいてよい。具体的には、更新要求情報は、「トランザクション開始時刻」、「行毎の更新情報」を含んでいてよい。

　ここで、「トランザクション開始時刻」は、例えば、クライアント系ノード２から更新要求が送信されてきた時刻であってよい。また例えば、クライアント系ノード２が更新要求の管理に係る検索処理をストレージ管理系ノード１に実行させた場合、「トランザクション管理時刻」は、当該検索処理における検索対象論理時刻であってよい。更新要求整合性管理部３２２は、先に送信されてきた更新要求を優先する「Ｆｉｒｓｔ－Ｃｏｍｍｉｔｔｅｒ－Ｗｉｎｓ　Ｒｕｌｅ」を適用して、更新処理を管理する。

　また、「行毎の更新情報」は、例えば、以下の内容を含んでよい。更新の内容として、新規行（管理対象のデータ）の挿入の場合、「行毎の更新情報」は、「行番号情報と、具体的な管理対象のデータの内容（例えば図５や図６におけるＡ，Ｂ，Ｃの具体的な値）」を含む。また、既存行（既にデータベース１５０に蓄積された管理対象のデータ）を削除する場合、「削除を行う管理対象のデータの行番号情報」を含む。

　例えば、第１実施形態の説明において、管理対象のデータは、「行」毎に管理されるものとしたが、特にこれに限定されない。即ち、管理対象のデータは、所定単位毎に管理されれば足りる。
　具体的には例えば、管理対象のデータは、「複数行」毎に管理されてもよく、第４実施形態の説明のように「ファイル」毎に管理されてもよい。

　また例えば、第１実施形態の説明において、データベース管理システムは、管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な情報を、論理時刻情報として取得するものとしたが、特にこれに限定されない。即ち、例えば、論理時刻は、データベースの管理に使われ、一方向に変化する識別子であれば足りる。
　具体的には例えば、データベースの更新毎に付与された整数値でもよく、「年」「月」「日」「時」「分」「秒」等の組み合わせで示される、日時の形態の情報でもよい。

　また例えば、第１実施形態の説明において、論理時刻情報取得部１１２は、管理対象のデータが有効になった論理時刻を挿入論理時刻ｘｔ＿ｉｎｓ、管理対象のデータが無効になった論理時刻を削除論理時刻ｘｔ＿ｄｅｌとして取得したが、特にこれに限定されない。即ち、管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な情報であれば足りる。
　具体的には例えば、挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌに挟まれた論理時刻の時間帯を示しうる情報を取得すれば足りる。

　また例えば、第１実施形態乃至第４実施形態の説明において、管理対象のデータが有効であったか否かを判定する式は、式（１）及び式（２）であるとしたが、特にこれに限定されない。
　具体的には例えば、式（１）及び式（２）に代えて、以下の式（３）及び式（４）を満たすか否かを確認することで、その行の管理対象のデータが有効であったか否かを判定することができる。

　ｓｔ　≧　ｘｔ＿ｉｎｓ　・・・　（３）
　ｓｔ　＜　ｘｔ＿ｄｅｌ　・・・　（４）

　なお、式（２）を採用し、式（１）に代えて式（３）を採用してもよい。また、式（１）を採用し、式（２）に代えて式（４）を採用してもよい。即ち、式（１）及び式（３）のうちいずれか一方を採用し、式（２）及び式（４）のいずれか一方を採用すれば足りる。

　また例えば、論理時刻として「年」「月」「日」「時」「分」「秒」等の組み合わせで示される日時の形態を採用する場合、ノード間の時刻計測の誤差を考慮した管理対象のデータが有効であったか否かを判定する式を採用することができる。具体的には例えば、所定の正の時間幅を表す定数εを用いて、以下の式（５）及び式（６）を満たすか否かを確認することで、その行の管理対象のデータが有効であったか否かを判定することができる。

　ｓｔ　＞　ｘｔ＿ｉｎｓ＋ε　・・・　（５）
　ｓｔ　≦　ｘｔ＿ｄｅｌ＋ε　・・・　（６）

　ただし、上述の式（５）及び式（６）は、あくまで例示である。即ち、式（５）及び式（６）に限定されない。検索対象特定部１３１は、ノード間の時刻計測の誤差を考慮して、管理対象のデータが有効であったか否かを判定することができれば足りる。

　また例えば、第１実施形態の説明において、行番号情報取得部１１３は、管理対象のデータが属する行番号を取得するものとしたが、特にこれに限定されない。即ち、管理対象のデータが属する前記所定単位を特定可能な情報であれば足りる。
　具体的には例えば、管理対象のデータが複数行毎に管理されている場合、複数行の何番目であるかの情報であればよく、管理対象のデータがファイル毎に管理されている場合、ファイル名であってよい。

　また例えば、第１実施形態の説明において、対象データ管理部１１４は、データベース１５０Ａのスキーマとして、挿入論理時刻ｘｔ＿ｉｎｓ、及び削除論理時刻ｘｔ＿ｄｅｌを管理するものとしたが、特にこれに限定されない。即ち、管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な情報と、管理対象のデータが属する前記所定単位を特定可能な情報と、管理対象のデータとを対応づけて管理できれば足る。
　具体的には例えば、第２実施形態乃至第４実施形態に示したように、対応づけて管理してよい。

　また例えば、第１実施形態の説明において、対象データ管理部１１４は、管理対象のデータが未だ無効になっていない旨を示す情報として、削除論理時刻ｘｔ＿ｄｅｌが「∞」の値を採用したが、特にこれに限定されない。
　具体的には例えば、対象データ管理部１１４は、任意に設定した整数値を未だ無効になっていない旨を示す情報として採用してよい。更に言えば、未だ無効になっていない旨を示す情報を示す値を数値として管理する場合、未だ無効になっていない旨を示す情報は、大きな値が望ましい。これにより、検索対象論理時刻ｓｔと削除論理時刻ｘｔ＿ｄｅｌとの大小関係を用いて、検索対象の候補のデータを特定することができる。

　また例えば、第２実施形態の説明において、対象データ管理部１４４は、管理対象のデータが最新の論理時刻において有効か否かに基づいて、管理対象のデータを第１のデータベースに蓄積するか、第２のデータベースに蓄積するかを異ならせるものとしたが、特にこれに限定されない。
　具体的には例えば、対象データ管理部１１４は、任意の数のデータベースに管理対象のデータを蓄積して管理してよい。例えば、対象データ管理部１１４は、最新の論理時刻において無効な管理対象のデータを、論理時刻の区分毎に複数のデータベースに蓄積してもよい。即ち例えば、所定の論理時刻よりも前の論理時刻において無効となった管理対象のデータは、第３のデータベースに蓄積して管理されてもよい。この場合、検索処理において、検索対象の候補のデータが第１のデータベース及び第２のデータベースにも含まれない場合に、第３のデータベースから検索対象の候補のデータが特定されてよい。これにより、検索処理の対象となりづらい管理対象のデータを別のデータベースとして管理し、検索処理等の処理に係るコストを削減することができる。

　第１実施形態及び第２実施形態の説明における対象データ管理部１１４を採用することで、以下のようなデータを管理する効率が向上する可能性がある。
　具体的には例えば、オンラインバンキングシステムや、航空券の予約システム等、大量の検索と更新が入り混じっており、整合性が必要とされる（絶対に間違いが許されない）システムを管理する効率が向上する可能性がある。

　第３実施形態の説明における対象データ管理部１１４を採用することで、以下のようなデータを管理する効率が向上する可能性がある。
　具体的には例えば、更新の大部分はデータの新規追加がほとんどであるが、稀に変更や削除が行われるようなシステムを管理する効率が向上する可能性がある。即ち例えば、ＩｏＴシステムにおける大量のセンサーから送られてくるデータの蓄積を行うシステムや、ＳＮＳ（Ｓｏｃｉａｌ　Ｎｅｔｗｏｒｋｉｎｇ　Ｓｙｓｔｅｍ）のデータの蓄積を行うシステムにおいて、効率が向上する可能性がある。即ち例えば、大量のセンサーから送られてくるデータやＳＮＳのデータは、大量の文字情報、画像、動画等であって、稀に変更や削除が行われる。

　第４実施形態の説明における対象データ管理部１１４を採用することで、以下のようなデータを管理する効率が向上する可能性がある。
　例えば、データベース管理システムを介さずより高速に処理を行いたい場合や、各種リソースの量の制限によりデータベース管理システムを動かしにくいシステム（例えば、組込みシステム）をストレージ管理系に利用したい場合等に、データを管理する効率が向上する可能性がある。

　また、上述したように、データベース管理システムは、ストレージ管理系ノード群Ｇ１と、クライアント系ノード群Ｇ２と、トランザクション管理系ノード群Ｇ３から構成され、論理時刻を用いてデータベースを管理することで、以下のような効果を奏する。
　具体的には例えば、トランザクション管理（更新処理の管理）や、当該管理にＳＩの方式を採用することで、整合性を保ったままデータの複製を複数持つことできるため、可用性を高めることができる。即ち、複数のノードのうち何れかのノードの一部が壊れた場合において、データが失われない。換言すれば、データベース管理システムは、複数のノードのうち何れかのノードの一部が壊れた場合においても、正常に稼働を続けることができる。即ち、データベース管理システムは、論理時刻を用いてデータベースを管理することでトランザクション管理を行う。これにより、複数のストレージ管理系ノード１の間でのデータベースの整合性を保つことができる。

　また例えば、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
　換言すると、図４の機能的構成は例示に過ぎず、特に限定されない。
　即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図４の例に限定されない。また、機能ブロックの存在場所も、図４に特に限定されず、任意でよい。例えば、ストレージ管理系ノード１の機能ブロックをクライアント系ノード２等に移譲させてもよい。逆にクライアント系ノード２の機能ブロックをストレージ管理系ノード１等に移譲させてもよい。
　また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

　一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
　コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。
　また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

　このようなプログラムを含む記録媒体は、ユーザ等にプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザ等に提供される記録媒体等で構成される。

　なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
　また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

　以上まとめると、本発明が適用される情報処理システムは、次のような構成を取れば足り、各種各様な実施形態を取ることができる。
　即ち、本発明が適用される情報処理システム（例えば、図４のストレージ管理系ノード１）は、
　データを所定単位（例えば、図５（Ｂ）の「行」）毎に管理する情報処理システムであって、
　管理対象のデータ（例えば、図５（Ｂ）の「ａ３」、「ｂ３」、「ｃ３」）が有効になった時間帯の少なくとも一部を特定可能な第１情報（例えば、「論理時刻ｘｔ」や「その幅」であって、図６の「ｘｔ＿ｉｎｓ」や「ｘｔ＿ｄｅｌ」であり、管理対象のデータが図６の「ａ３」、「ｂ３」、「ｃ３」ならば「１０」や「１５」）を取得する第１取得手段（例えば、図４の論理時刻情報取得部１１２）と、
　前記管理対象のデータが属する前記所定単位を特定可能な第２情報（例えば、図５や図６の「ｔｉｄ」）を取得する第２取得手段（例えば、図４の行番号情報取得部１１３）と、
　前記第１情報と、前記第２情報と、前記管理対象のデータとを対応付けて管理する（例えば図６のデータベース１５０Ａのように管理する）管理手段（例えば、図４の対象データ管理部１１４）と、
　を備える。

　これにより、情報処理システムは、第１情報や第２情報に基づいて、管理対象のデータを検索することが可能となる。また、情報処理システムは、第１情報に基づいて管理対象のデータを検索ができることで、分散されたデータベース管理システムにおけるスケーラビリティを向上させることができる。即ち、このような情報処理システムは、所定の過去の時刻のデータを取得する際の処理コストを低減し、且つ、整合性を保ったまま、複数の情報処理システムを活用してデータベースに対する処理能力を向上させることができる。

　また、前記管理手段は、
　　前記管理対象のデータが有効になった時点を特定可能な第１の１情報（例えば、図６の「ｘｔ＿ｉｎｓ」の値）と、
　　前記管理対象のデータが無効になった時点を特定可能な第１の２情報（例えば、図６の「ｘｔ＿ｄｅｌ」の値）と、
　を含む情報を前記第１情報として、
　前記第２情報と、前記管理対象のデータとに対応付けて管理することができる。

　これにより、このような情報処理システムは、第１情報により示される範囲が、管理対象のデータが有効になった時点と無効になった時点とに対応付けられて管理されることができる。

　また、前記第１の２情報は、前記管理対象のデータが未だ無効になっていない旨を示す情報（例えば、管理対象のデータが図６の「ａ１」ならば「ｘｔ＿ｄｅｌ＝∞」の値）を含む。

　これにより、第１の２情報に基づき、管理対象のデータが未だ無効になっていないことを特定することができる。

　また、前記管理手段は、
　　管理対象の１以上の前記データのうち、有効な１以上のデータを第１データ群（例えば図８（Ａ）のデータベース１５０Ｂ―１で管理されるデータ群）として、無効な１以上のデータを第２データ群（例えば図８（Ｂ）のデータベース１５０Ｂ―２で管理されるデータ群）として夫々管理し、
　　前記第１データ群に含まれる管理対象のデータついては、
　　　前記管理対象のデータが有効になった時点を特定可能な第１の１情報（例えば、図８（Ａ）の「ｘｔ＿ｉｎｓ」の値）を前記第１情報として、
　　前記第２情報と、前記管理対象のデータとを対応付けて管理し、
　　前記第２データ群に含まれる管理対象のデータついては、
　　　前記第１の１情報（例えば、図８（Ｂ）の「ｘｔ＿ｉｎｓ」の値）と、
　　　前記管理対象のデータが無効になった時点を特定可能な第１の２情報（例えば、図８（Ｂ）の「ｘｔ＿ｄｅｌ」の値）と、
　　を含む情報を前記第１情報として、
　　前記第２情報と、前記管理対象のデータとを対応付けて管理することができる。

　これにより、情報処理システムは、検索処理において、まず、第１データ群から検索対象の候補のデータを特定することができる。次に、情報処理システムは、必要に応じて、第２データ群から更に検索対象の候補のデータを特定することができる。そして、第１データ群から特定した検索対象の候補のデータと、第２データ群から特定した検索対象の候補のデータとの和集合を、総合的な検索対象の候補のデータとして特定する。第２データ群から検索対象の候補を特定する必要がない場合、情報処理システムは、第２データ群から検索対象の候補のデータを特定する処理を行う必要がない。即ち、このような情報処理システムは、検索処理に係る計算資源を節約することができる。

　また、前記管理手段は、
　　前記第２情報（例えば、図１１の「ｔｉｄ＝１００１」のような「Ｋｅｙ」）と、前記管理対象のデータ（例えば、図１１の「ｖａｌｕｅ＝ＡＢＣＤＥＦＧ」）及び前記第１情報（例えば、図１１の「ｘｔ＿ｉｎｓ＝７」や「ｘｔ＿ｄｅｌ＝∞」）を含む情報（例えば、管理対象のデータと論理時刻のデータを含む「Ｖａｌｕｅ」）とを対応付けて（例えば、図１１のＫＶＳ形式のデータベース１５０Ｃのように）管理することができる。

　これにより、情報処理システムは、１つの情報（例えば、第２情報）と対応付けられた他の情報（例えば、管理対象のデータ及び前記第１情報を含む情報）を管理するデータベース管理システムを用いて、第１情報、第２情報、及び管理対象のデータを管理することができる。
　ここで、１つの情報（例えば、第２情報）と対応付けられた他の情報を管理するデータベース管理システムは、通常、他のデータベース管理システム（例えば、ＲＤＢＭＳにより管理されるリレーショナル形式のデータベース）と比較して性能が高い。即ち、情報処理システムは、検索処理の性能を向上させることができる。

　また、前記管理対象のデータは、前記第１情報（例えば、図６の「ｘｔ＿ｉｎｓ」や「ｘｔ＿ｄｅｌ」に相当するものであって、管理対象のデータが図１４の「１２３４５６７８９０」ならば「１０」や「１５」）及び前記第２情報（例えば、図６の「ｔｉｄ」に相当するものであって、管理対象のデータが図１４の「１２３４５６７８９０」ならば「ｂａｚ」）を含むファイル名（例えば、管理対象のデータが図１４の「１２３４５６７８９０」ならば「ｂａｚ（１０，１５）」）のファイルとして所定の媒体（例えば、図４の記憶部１８）に記憶されており、
　前記管理手段は、前記ファイル名を管理することで、前記第１情報と、前記第２情報と、前記管理対象のデータとを対応付けて管理（例えば、記憶部１８に記憶された、図１４に示すファイルの一覧のように管理）することができる。

　これにより、情報処理システムは、任意のファイル形式のファイルを、管理対象のデータとして、第１情報、及び第２情報と対応付けて管理することができる。これにより例えば、情報処理システムは、特定された検索対象の候補のデータとして、ファイルをクライアントに提供することができる。
　また例えば、第１情報を、データベース管理システムにおけるスキーマとして管理せず、単にファイルのファイル名として管理することができる。即ち、通常データベースにおいて処理するＳＱＬ等による処理が不要となり、検索処理における計算資源の消費を削減することができる。

　また、前記管理対象のデータが有効であった前記時間帯のうち、所定の時刻を特定可能な第３情報（例えば、明細書で言う「検索対象論理時刻ｓｔ」）を取得する第３取得手段と、
　前記管理手段により管理される前記第１情報（図６のデータベース１５０Ａの「ｘｔ＿ｉｎｓ」、「ｘｔ＿ｄｅｌ」）、及び前記第３情報に基づき、前記第３情報により特定される時刻に有効であった前記管理対象のデータ（例えば、「検索対象論理時刻ｓｔ」が「１３」であった場合、図６のデータベース１５０Ａの「ｔｉｄ」が「１００１」の行、「１００２」であって上の行、及び「１００３」の行のデータ）を、検索対象の候補のデータとして特定する特定手段と、
　前記特定手段により特定された前記検索対象の候補のデータ（例えば、図６のデータベース１５０Ａの「ｔｉｄ」が「１００１」の行、「１００２」であって上の行、及び「１００３」の行のデータを抽出した図５（Ｃ）のデータベース１５０－１３）から検索する検索手段と、を備える。

　これにより、管理対象のデータを、単に第１情報、及び第２情報と対応付けて管理するのみならず、任意の時点における管理対象のデータから検索対象の候補のデータを特定して、検索することができる。

　また、第１情報処理システム（例えば、図４のストレージ管理系ノード１）により管理対象のデータが所定単位毎に管理されている場合における、当該管理対象のデータの更新を管理する第２情報処理システム（例えば、図４のトランザクション管理系ノード３）として機能する情報処理システムであって、
　　前記管理対象のデータの更新の内容（例えば、図５（Ｂ）の「ｔｉｄ＝１００２」のＢ列を「ｂ２’」とする更新の内容）を特定可能な情報を、更新要求情報として取得する取得手段（例えば、図４の更新要求情報取得部３２１）と、
　　前記更新要求情報に基づき、前記管理対象のデータが管理される前記第１情報処理システムに対して当該更新要求情報を送信することで、当該更新の要求（送信すべきか、送信した結果が処理されたか）を管理する管理手段（例えば、図４の更新要求整合性管理部３２２）と、
　を備え、
　前記第１情報処理システムは、
　　前記第２情報処理システムから送信されてくる前記更新要求情報に基づき、更新をされた前記管理対象のデータを更新後管理対象のデータとして生成し、当該更新後管理対象のデータを有効化し、
　　前記更新後管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な有効時間帯情報を取得し、
　　前記更新後管理対象のデータが属する前記所定単位を特定可能な所定単位特定情報を取得し、
　　前記有効時間帯情報と、前記所定単位特定情報と、前記更新後管理対象のデータとを対応付けて管理することができる。

　これにより、第２情報処理システムは、データベースの整合性が崩れるか否かを判定して、整合性が維持されることが確実である場合にのみ、第１情報処理装置に更新の要求を送信する。これにより、第１情報処理装置により管理されるデータベースは、更新処理に係る整合性が維持される。

　また、前記第２情報処理システムの前記管理手段は、
　　先の時点に取得された更新要求情報により更新される管理対象のデータ（例えば、「更新要求整合性管理部３２２－２により管理される更新処理により更新される管理対象のデータ」）が後の時点に取得された他の更新要求情報により更新されるか否か（例えば、「更新要求整合性管理部３２２－１により管理される更新処理により更新されるか否か」）に基づき、前記管理対象のデータが管理される前記第１情報処理システムに対して当該他の更新要求情報（例えば、「更新要求整合性管理部３２２－１により管理される更新処理」）を送信するか否かを管理することができる。

　これにより、複数の第２情報処理システムの夫々により、同時に複数の更新の要求の夫々を処理した場合であっても、整合性が維持されることが確実である場合にのみ、第１情報処理装置に書き戻すことができる。即ち、第１情報処理装置により管理されるデータベースは、更新処理に係る整合性が維持される。
　また、第１情報処理装置により管理されるデータベースの整合性が維持されるからこそ、複数の第２情報処理システムの夫々により、同時に複数の更新の夫々の要求を処理することができる。
　即ち、第１情報処理システムと、複数の第２情報処理システムを含む様に、情報処理システムを構成すると、スケールアウトがされた環境において、第１情報処理装置により管理されるデータベースは、更新処理に係る整合性が維持される。即ち例えば、第１情報処理システム及び第２情報処理システムを含む情報処理システムは、複数の情報処理システムを活用することで、整合性を維持したまま、データベースに対する処理能力を向上させることができる。

　１・・・ストレージ管理系ノード、２・・・クライアント系ノード、３・・・トランザクション管理系ノード、１１・・・ＣＰＵ、１８・・・記憶部、１９・・・通信部、１１１・・・更新要求情報取得部、１１２・・・論理時刻情報取得部、１１３・・・行番号情報取得部、１１４・・・対象データ管理部、１２１・・・索対象論理情報取得部、１２２・・・検索内容情報取得部、１２３・・・検索管理部、１２４・・・検索結果提示部、１３１・・・検索対象特定部、１３２・・・検索部、１５０・・・データベース、２１２・・・ＣＰＵ、２２１・・・更新要求管理部、２２２・・・検索要求管理部、３１２・・・ＣＰＵ、３２１・・・更新要求情報取得部、３２２・・・更新要求整合性管理部

Claims

　データを所定単位毎に管理する情報処理システムであって、
　管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な第１情報を取得する第１取得手段と、
　前記管理対象のデータが属する前記所定単位を特定可能な第２情報を取得する第２取得手段と、
　前記第１情報と、前記第２情報と、前記管理対象のデータとを対応付けて管理する管理手段と、
　を備える情報処理システム。
　前記管理手段は、
　　前記管理対象のデータが有効になった時点を特定可能な第１の１情報と、
　　前記管理対象のデータが無効になった時点を特定可能な第１の２情報と、
　を含む情報を前記第１情報として、
　前記第２情報と、前記管理対象のデータとに対応付けて管理する、
　請求項１に記載の情報処理システム。
　前記第１の２情報は、前記管理対象のデータが未だ無効になっていない旨を示す情報を含む、
　請求項２に記載の情報処理システム。
　前記管理手段は、
　　管理対象の１以上の前記データのうち、有効な１以上のデータを第１データ群として、無効な１以上のデータを第２データ群として夫々管理し、
　　前記第１データ群に含まれる管理対象のデータついては、
　　　前記管理対象のデータが有効になった時点を特定可能な第１の１情報を前記第１情報として、
　　前記第２情報と、前記管理対象のデータとを対応付けて管理し、
　　前記第２データ群に含まれる管理対象のデータついては、
　　　前記第１の１情報と、
　　　前記管理対象のデータが無効になった時点を特定可能な第１の２情報と、
　　を含む情報を前記第１情報として、
　　前記第２情報と、前記管理対象のデータとを対応付けて管理する、
　請求項１に記載の情報処理システム。
　前記管理手段は、
　　前記第２情報と、前記管理対象のデータ及び前記第１情報を含む情報とを対応付けて管理する、
　請求項１に記載の情報処理システム。
　前記管理対象のデータは、前記第１情報及び前記第２情報を含むファイル名のファイルとして所定の媒体に記憶されており、
　前記管理手段は、前記ファイル名を管理することで、前記第１情報と、前記第２情報と、前記管理対象のデータとを対応付けて管理する、
　請求項１に記載の情報処理システム。
　前記管理対象のデータが有効であった前記時間帯のうち、所定の時刻を特定可能な第３情報を取得する第３取得手段と、
　前記管理手段により管理される前記第１情報、及び前記第３情報に基づき、前記第３情報により特定される時刻に有効であった前記管理対象のデータを、検索対象の候補のデータとして特定する特定手段と、
　前記特定手段により特定された前記検索対象の候補のデータから検索する検索手段と、
　をさらに備える、
　請求項１乃至６のうちいずれか１項に記載の情報処理システム。
　第１情報処理システムにより管理対象のデータが所定単位毎に管理されている場合における、当該管理対象のデータの更新を管理する第２情報処理システムとして機能する情報処理システムであって、
　　前記管理対象のデータの更新の内容を特定可能な情報を、更新要求情報として取得する取得手段と、
　　前記更新要求情報に基づき、前記管理対象のデータが管理される前記第１情報処理システムに対して当該更新要求情報を送信することで、当該更新の要求を管理する管理手段と、
　を備え、
　前記第１情報処理システムは、
　　前記第２情報処理システムから送信されてくる前記更新要求情報に基づき、更新をされた前記管理対象のデータを更新後管理対象のデータとして生成し、当該更新後管理対象のデータを有効化し、
　　前記更新後管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な有効時間帯情報を取得し、
　　前記更新後管理対象のデータが属する前記所定単位を特定可能な所定単位特定情報を取得し、
　　前記有効時間帯情報と、前記所定単位特定情報と、前記更新後管理対象のデータとを対応付けて管理する、
　情報処理システム。
　前記第２情報処理システムの前記管理手段は、
　　先の時点に取得された更新要求情報により更新される管理対象のデータが後の時点に取得された他の更新要求情報により更新されるか否かに基づき、前記管理対象のデータが管理される前記第１情報処理システムに対して当該他の更新要求情報を送信するか否かを管理する、
　請求項８に記載の情報処理システム。