JP7398066B2 - 情報処理システム - Google Patents
情報処理システム Download PDFInfo
- Publication number
- JP7398066B2 JP7398066B2 JP2019099392A JP2019099392A JP7398066B2 JP 7398066 B2 JP7398066 B2 JP 7398066B2 JP 2019099392 A JP2019099392 A JP 2019099392A JP 2019099392 A JP2019099392 A JP 2019099392A JP 7398066 B2 JP7398066 B2 JP 7398066B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- managed
- information
- database
- search
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000010365 information processing Effects 0.000 title claims description 79
- 238000007726 management method Methods 0.000 claims description 348
- 238000003780 insertion Methods 0.000 claims description 79
- 230000037431 insertion Effects 0.000 claims description 79
- 238000012217 deletion Methods 0.000 claims description 69
- 230000037430 deletion Effects 0.000 claims description 69
- 238000013523 data management Methods 0.000 claims description 48
- 230000003213 activating effect Effects 0.000 claims description 2
- 238000000034 method Methods 0.000 description 277
- 230000008569 process Effects 0.000 description 269
- 238000012545 processing Methods 0.000 description 103
- 238000010586 diagram Methods 0.000 description 23
- 230000007246 mechanism Effects 0.000 description 23
- PCTMTFRHKVHKIS-BMFZQQSSSA-N (1s,3r,4e,6e,8e,10e,12e,14e,16e,18s,19r,20r,21s,25r,27r,30r,31r,33s,35r,37s,38r)-3-[(2r,3s,4s,5s,6r)-4-amino-3,5-dihydroxy-6-methyloxan-2-yl]oxy-19,25,27,30,31,33,35,37-octahydroxy-18,20,21-trimethyl-23-oxo-22,39-dioxabicyclo[33.3.1]nonatriaconta-4,6,8,10 Chemical compound C1C=C2C[C@@H](OS(O)(=O)=O)CC[C@]2(C)[C@@H]2[C@@H]1[C@@H]1CC[C@H]([C@H](C)CCCC(C)C)[C@@]1(C)CC2.O[C@H]1[C@@H](N)[C@H](O)[C@@H](C)O[C@H]1O[C@H]1/C=C/C=C/C=C/C=C/C=C/C=C/C=C/[C@H](C)[C@@H](O)[C@@H](C)[C@H](C)OC(=O)C[C@H](O)C[C@H](O)CC[C@@H](O)[C@H](O)C[C@H](O)C[C@](O)(C[C@H](O)[C@H]2C(O)=O)O[C@H]2C1 PCTMTFRHKVHKIS-BMFZQQSSSA-N 0.000 description 14
- 230000006870 function Effects 0.000 description 14
- 238000005516 engineering process Methods 0.000 description 10
- 238000004891 communication Methods 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 239000002253 acid Substances 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 238000009825 accumulation Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000013341 scale-up Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
ここで、データベースに対して同時に複数の処理を行うため、複数データベース間のデータの整合性がとれている状態で、過去のデータを取得可能とする技術が提案されている(例えば、特許文献1参照)。
データを所定単位毎に管理する情報処理システムであって、
管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な第1情報を取得する第1取得手段と、
前記管理対象のデータが属する前記所定単位を特定可能な第2情報を取得する第2取得手段と、
前記第1情報と、前記第2情報と、前記管理対象のデータとを対応付けて管理する管理手段と、
を備える。
まず、本発明が適用される情報処理システムの第1実施形態として、大量のデータの蓄積、検索、及び更新等を行うことができる、データベース管理システムについて説明する。
ここで、RDBMSは、リレーショナル形式のデータベースを管理するデータベース管理システムである。また、リレーショナル形式のデータベースは、簡単に言うならば、列と行からなる2次元の表の形式としてとらえることが可能なデータベースである。
即ち、第1実施形態(及び後述の第2実施形態)のデータベースは、例えば、人物の情報をデータとして管理するデータベースにおいて、列の夫々が「名前」、「性別」、「年齢」等の項目に対応し、複数の行の夫々は、複数の人物の夫々に対応する。即ち、この例のデータベースは、管理対象のデータとして人物の各属性を示す各データ(各項目)を含むデータ群を採用しており、その管理対象のデータを行の単位(人物単位)毎に管理する。なお、データベースの列の夫々が示す「名前」、「性別」、「年齢」といった項目(データの属性)のことを「スキーマ」と呼ぶ。
また、第1実施形態(及び後述の第2実施形態乃至第4実施形態)のデータベースにおける「検索」とは、データベースから、所定のデータを抽出することを言う。ここで、所定のデータには、データベースの一部の生データの他、1以上の生データを加工等したデータも含まれる。なお、以下、データベースの検索に係る処理を、「検索処理」と呼ぶ。
また、第1実施形態(及び後述の第2実施形態乃至第4実施形態)のデータベースにおける「更新」とは、データベースの少なくとも一部として、新たなデータを追加すること、既にデータベースの少なくとも一部として記憶されているデータを書き換えること、既にデータベースの少なくとも一部として記憶されているデータを削除することをいう。即ち、データベースに蓄積されたデータを変更することを更新という。なお、データベースの更新に係る処理を、以下、「トランザクション処理」又は「更新処理」と呼ぶ。
この例のデータベースは、複数の人物の夫々に対応する行(所定の単位)毎に、各スキーマのデータの組が蓄積されて、構成される。
また、データベースの利用者は、以下のようなデータを検索することができる。具体的には例えば、特定の人物の「名前」、「性別」、「年齢」の夫々のデータの組を検索(抽出)することができる。また例えば、データベースの利用者は、複数の人物のうち、性別が男性である人物のリストを検索(抽出)することができる。また例えば、データベースの利用者は、複数の人物のデータのうち、性別が男性である人物の年齢の平均値を検索(抽出)することができる。
また、データベースの利用者は、新たな人物のデータを追加する更新を行ったり、人物のデータのうち年齢を変更する更新を行ったり、人物のデータを削除する更新を行ったりすることができる。
なお、ハードウェア資源を所定倍にする方法は、スケールアップとスケールアウトの2つが存在する。
即ち例えば、分割されたデータベースの夫々が複数のノードの夫々に記憶された場合、当該データベースは、分散されたデータベースといえる。なお、データベースが複数のノードに記憶される場合、複数のノードの夫々は、分割されたデータベースのみならず、全部、又は一部が共通なデータベースを記憶してもよい。
ストレージ管理系ノード群G1は、N台(Nは1以上の任意の整数値)のストレージ管理系ノード1-1乃至1-Nにより構成される。同様に、クライアント系ノード群G2は、M台(Mは1以上の任意の整数値)のクライアント系ノード2-1乃至2-Mにより構成される。また、トランザクション管理系ノード群G3は、L台(Lは1以上の任意の整数値)のトランザクション管理系ノード3-1乃至3-Lにより構成される。
なお、「SQL」とは、データベース管理システムにおいて、データの操作や定義を行うための言語である。
ここで、「SQL解釈系」とは、更に別の系(アプリケーションプログラムや人間)からSQLを受け付け、それを解釈し、ストレージ管理系ノード群G1やトランザクション管理系ノード群G3を構成するノードの夫々が理解できる形に変換するプログラム等をいう。
具体的には例えば、整合性として、以下のことが求められる。ACID特性のAである、「『一部の操作は実行され、残りの操作は実行されない』ということが起こらない」ことが求められる。また例えば、強い整合性として、「完了したトランザクションの内容はすぐに検索できる」こと等が求められる。即ち、トランザクションが完了した場合、トランザクションの内容が反映されたデータベースから検索できること等が求められる。また例えば、ACID特性のIとして、「トランザクション中に行われる操作の過程が他の操作から隠蔽される」こと等が求められる。即ち、トランザクション中において、整合性がない時点(過程)は、検索が不可能であることが求められる。
RAM13には、CPU11が各種の処理を実行する上において必要なデータ等も適宜記憶される。
入力部17は、キーボードやマウス等で構成され、各種情報を入力する。
通信部19は、インターネットを含むネットワークNWを介して他の装置(図1の例ではクライアント系ノード2やトランザクション管理系ノード3)との間で通信を行う。
また、リムーバブルメディア31は、記憶部18に記憶されている各種データも、記憶部18と同様に記憶することができる。
また、データベースは、上述のように、リレーション(表)の形式で管理されるものとして説明する。即ち、管理対象のデータは、リレーションにおける行毎に、管理される。
具体的には例えば、更新要求管理部221は、図示せぬアプリケーションプログラム等の要求に基づき、更新要求情報として、データベースに要求する更新内容を含む情報を取得又は生成し、更新要求情報をトランザクション管理系ノード3に通信部211を介して送信する。即ち、ここでいう更新要求情報は、例えば「データベースの2行目に蓄積されている、名前が「ABCD」、性別が「男性」、年齢が「25歳」といった人物のデータを、名前と性別とは変更がなく、年齢が「26歳」であるといった人物のデータに更新する」という要求の情報である。
即ち、更新要求整合性管理部322は、更新要求情報に基づき、ストレージ管理系ノード1に対して更新要求情報を送信するか否かを管理することで、更新の要求を管理する。
また例えば、まず、更新要求整合性管理部322は、過去の更新要求情報等の全部又は一部を保持して管理する。次に、更新要求整合性管理部322は、新たな更新要求情報を、過去の更新要求情報等と照合する。このとき、更新要求整合性管理部322は、新たな更新要求情報により更新される管理対象のデータが、過去の更新要求情報等により更新されたか否かに基づいて、ストレージ管理系ノード1に格納されたデータベースの整合性が崩れるか否かを判定する。
もし、当該更新要求情報に基づいてデータベースの更新を行った場合に、整合性が維持されない、又はその可能性が十分に高いと判定された場合、更新要求整合性管理部322は、その更新の要求を破棄する。整合性が維持されることが確実である場合、トランザクション管理系ノード3は、ストレージ管理系ノード1に更新要求を送信する。
なお、更新要求整合性管理部322は、更新の要求を破棄する旨やストレージ管理系ノード1に送信する旨を、クライアント系ノード2の更新要求管理部221に通知することができる。更新要求整合性管理部322により更新の要求を破棄された場合、クライアント系ノード2の更新要求管理部221は、更新の要求を再度発行することができる。
ここで、論理時刻とは、管理対象のデータを管理する際における、更新履歴を記録するための時刻である。論理時刻は、データベースの更新毎に一意に付与された、整数であってよい。具体的には例えば、1回目の更新は「論理時刻=1」、2回目の更新は「論理時刻=2」といった数の形態とすることができる。また例えば、論理時刻は、通常の時刻と同様に、「年」「月」「日」「時」「分」「秒」等の組み合わせで示される、いわゆる通常の時刻の形態とすることができる。
即ち、論理時刻は、データベースの管理に使われ、一方向に変化する識別子である。図4の第1実施形態の説明では、論理時刻は、データベースの更新毎に付与された整数値として説明する。また、「論理時刻=5」において、更新処理が行われるものとして説明する。
この場合、論理時刻情報取得部112は、この更新処理が行われる「論理時刻=5」を、「ABCD」、「男性」、「26歳」のデータの組の挿入論理時刻xt_insとして、取得する。また、「ABCD」、「男性」、「26歳」のデータの組の削除論理時刻xt_delは、未定である。そこで、例えば、論理時刻情報取得部112は、削除論理時刻xt_delが未定である旨を、∞という削除論理時刻xt_delとして取得することができる。
また、論理時刻情報取得部112は、この更新処理が行われる「論理時刻=5」を、「ABCD」、「男性」、「25歳」のデータの組の削除論理時刻xt_delとして、取得する。「ABCD」、「男性」、「25歳」のデータの組の挿入論理時刻xt_insは、すでにデータベースに蓄積されているデータから取得することができる。
なお、挿入論理時刻xt_ins及び削除論理時刻xt_delが、具体的にどのようにデータベース150に蓄積されるのかの詳細は図5及び図6を用いて後述する。
次に、ストレージ管理系ノード1、及びクライアント系ノード2により、検索処理が行われる場合に機能する機能ブロックについて説明する。
まとめると、検索処理を行う要求、即ち検索要求として、「「論理時刻=4」におけるデータベースの2行目に蓄積されている、人物のデータを抽出する」という内容(以下、「検索内容」と呼ぶ)の要求がなされる例を用いて説明する。
具体的には例えば、検索要求管理部222は、図示せぬアプリケーションプログラム等の要求に基づき、検索要求情報として、データベースに要求する検索内容を含む情報を取得又は生成し、検索要求情報をストレージ管理系ノード1に送信する。即ち、ここでいう検索要求情報は、例えば「「論理時刻=4」におけるデータベースの2行目に蓄積されている、人物のデータを抽出する」という要求の情報である。
本例では、検索内容情報取得部122は、検索要求情報のうち、「データベースの2行目に蓄積されている、人物のデータを抽出する」という情報を、検索内容情報として取得する。
この場合、検索対象特定部131は、データベースのうち、検索対象の候補のデータを特定するための条件を、次のようにして決定する。即ち、本例では、上述のように、検索対象論理時刻stは「4」である。従って、検索対象の候補のデータは、「挿入論理時刻xt_insが4より小さく、且つ、削除論理時刻xt_delが4以上」という条件を満たす必要がある。そこで、検索対象特定部131は、かかる条件を、検索対象の候補のデータを特定するための条件として決定する。
即ち、この場合、上述の例では、検索対象特定部131は、第1データを、検索対象の候補のデータとして特定する。
具体的には例えば、上述の例では、検索部132は、第1データから、「データベースの2行目に蓄積されている、人物のデータを抽出する」という検索内容に合致するデータを検索する。
このように、複数のデータを含む検索対象の候補のデータから、検索結果として、「名前が「ABCD」、性別が「男性」、年齢が「25」」のデータが抽出される。
具体的には例えば、検索結果提示部124は、検索部132で抽出された、検索結果である「名前が「ABCD」、性別が「男性」、年齢が「25」」のデータを、クライアント系ノード2に送信する。
また、検索対象特定部131は、対象データ管理部114により管理される論理時刻情報、及び検索対象論理時刻情報に基づき、検索対象論理時刻情報により特定される時刻に有効であった管理対象のデータを、検索対象の候補のデータとして特定する。即ち、検索対象特定部131は、データベース150から、検索対象論理時刻stに対応するデータベース150-stを検索対象の候補のデータとして特定する。
これにより、検索部132は、検索対象論理時刻stにおけるデータベース150から、検索することができる。
これにより、第1実施形態は、分散されたデータベース管理システムでありながら、スケーラビリティを向上させることができる。
図6は、第1実施形態における図1のストレージ管理系ノードで管理されるデータベースに含まれる、管理対象のデータの例を示す図である。
また、詳細は後述するが、図6のデータベース150Aは、以下の第1の更新処理乃至第4の更新処理が行われたデータである。
図5(A)乃至図5(D)に示すデータベース150-8、150-11、150-13、150-16を含むデータベースのうち、他の実施形態は、図8以降を用いて、データベース150B等を用いて後述する。
第2の更新処理は、論理時刻が「10」において、「tid」について「1002」、「1003」のデータが追加される更新処理である。
第3の更新処理は、論理時刻が「12」において、「tid」について「1002」のデータが変更される更新処理である。
第4の更新処理は、論理時刻が「15」において、「tid」について「1003」のデータが削除される更新処理である。
検索処理において、検索対象論理時刻stとして「8」が指定された場合、検索対象特定部131は、図6のデータベース150Aから、図5(A)に示すデータベース150-8のデータを、検索対象の候補のデータとして特定する。
検索処理において、検索対象論理時刻stとして「11」が指定された場合、検索対象特定部131は、データベース150Aから、図5(B)に示すデータベース150-11のデータを、検索対象の候補のデータとして特定する。
検索処理において、検索対象論理時刻stとして「13」が指定された場合、検索対象特定部131は、図6のデータベース150Aから、図5(C)に示すデータベース150-13のデータを、検索対象の候補のデータとして特定する。
検索処理において、検索対象論理時刻stとして「16」が指定された場合、検索対象特定部131は、図6のデータベース150Aから、図5(D)に示すデータベース150-16のデータを、検索対象の候補のデータとして特定する。
検索対象特定部131は、データベース150Aの4つの行の夫々が、検索対象論理時刻stが「13」の時刻において有効であったかを特定する。具体的には、検索対象特定部131は、データベース150Aの行の夫々について、以下の式(1)及び式(2)を満たすか否かを確認することで、その行の管理対象のデータが有効であったか否かを判定することができる。
st ≦ xt_del ・・・ (2)
図6のデータベース150Aの2行目の行(「tid」が「1001」の行のうち上の行)は、式(2)を満たさないので無効である。
図6のデータベース150Aの3行目の行(「tid」が「1001」の行のうち下の行)は、式(1)及び式(2)を満たすので有効である。
図6のデータベース150Aの4行目の行(「tid」が「1001」の行)は、式(1)及び式(2)を満たすので有効である。
ここで、第1実施形態(及び後述の第2実施形態乃至第4実施形態)の「格納処理」とは、更新処理によりデータベースに蓄積されたデータが変更される際、変更されたデータが図4のストレージ管理系ノード1の記憶部18に格納される処理である。
更新処理が行われることにより、データベース150Aに蓄積して管理すべきデータ(管理対象のデータ)が発生すると、格納処理が開始されて、次のようなステップS11乃至S15の処理が実行される。
無効になった管理対象のデータがある場合、ステップS13の処理においてYESであると判定されて、処理はステップS14に進む。
これにより、格納処理は終了する。
即ち、無効になったデータがない場合、ステップS13の処理においてNOであると判定されて、処理はステップS15に進む。即ち、無効になったデータがある場合に実行されたステップS14の処理は、無効になった管理対象のデータがない場合には実行されない。
これにより、格納処理は終了する。
なお、以下の説明において、「A」というスキーマが「a1」、「B」というスキーマが「b1」、「C」というスキーマが「c1」であることを、「(A,B,C)=(a1,b1,c1)」と記載する。
第1の例では、更新処理前には、論理時刻10乃至12において、管理対象のデータ(A,B,C)=(a2,b2,c2)であったものが、論理時刻12における更新処理により、管理対象のデータ(A,B,C)=(a2,b2’,c2’)に更新されたものとする。
第1の例では無効になった管理対象のデータ(A,B,C)=(a2,b2,c2)があるため、ステップS13の処理においてYESであると判定されて、処理はステップS14に進む。
これにより格納処理は終了となる。
次に、データベース150Aの中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をする。
第2の例では、更新処理前には、論理時刻10までにおいて、「tid」が「1003」の管理対象のデータは存在しなかったが、論理時刻10における更新処理により、管理対象のデータ(A,B,C)=(a3,b3,c3)が更新(追加)されたものとする。
第2の例では無効になったデータがないため、ステップS13の処理においてNOであると判定されて、処理はステップS15に進む。
これにより格納処理は終了となる。
以上、データベース150Aの中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をした。
また、第2の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップS14の処理は実行されない。また、更新処理により、有効となる管理対象のデータ(A,B,C)=(a3,b3,c3)が、ステップS15の処理によりデータベース150Aに蓄積されて管理される。
次に、本発明の第2実施形態に係るデータベース管理システムについて説明する。
第2実施形態に係るデータベース管理システムの構成は、第1実施形態と同様である。即ち、図1はそのまま、本発明の第2実施形態に係るデータベース管理システムの構成を示している。よって、本発明の第2実施形態に係るデータベース管理システムの構成の説明は省略する。
また、図示はしないが、第2実施形態に係るデータベース管理システムのクライアント系ノード2及びトランザクション管理系ノード3の夫々は、図3に示すハードウェア構成と基本的に同様の構成を有している。
よって、本発明の第2実施形態に係る、ストレージ管理系ノード1、クライアント系ノード2、及びトランザクション管理系ノード3の夫々のハードウェア構成の説明は省略する。
即ち、第1実施形態で採用された仕組みは、管理対象のデータ、当該管理対象のデータの挿入論理時刻xt_ins及び削除論理時刻xt_delが、データベース150Aのスキーマとして蓄積される仕組みであった。
ここで、「最新の論理時刻」とは、現時点(例えば検索処理の開始時点)からみて直前の更新処理が行われた論理時刻に1を加えたものである。また、最新の論理時刻におけるデータベース、即ち最新の論理時刻より小さい論理時刻における更新処理が完了したデータベースを、「最新のデータベース」と呼ぶ。
このような第1実施形態で採用される仕組みに対して、第2実施形態で採用される仕組みは、最新の論理時刻において有効な管理対象のデータの挿入論理時刻xt_insが、第1のデータベース(例えば後述する図8のデータベース150B-1)のスキーマとして蓄積される仕組みである。また、第2実施形態で採用される仕組みは、最新の論理時刻において無効な管理対象のデータの挿入論理時刻xt_ins及び削除論理時刻xt_delが、第2のデータベース(例えば後述するデータベース150B-2)のスキーマとして蓄積される仕組みである。
図8(B)には、最新のデータベースにおいて無効であるデータを蓄積するデータベース150B-2の例が示されている。
第2実施形態に係る対象データ管理部114は、挿入論理時刻xt_ins、削除論理時刻xt_del、及び管理対象のデータ(有効と無効とを夫々区別したデータ)を対応付けて、データベース150B-1及びデータベース150B-2に蓄積する。
図8(B)のデータベース150B-2には、図6に示すデータベース150Aのうち図8に示すデータベース150B-1に含まれない管理対象のデータと、挿入論理時刻xt_insと、削除論理時刻xt_delとが対応づけられて蓄積されている。換言すれば、データベース150B-2は、最新の論理時刻において無効である管理対象のデータの更新の履歴である。
即ち、図8(A)に示すデータベース150B-1及び図8(B)に示すデータベース150B-2には、最新の論理時刻において有効である管理対象のデータと無効である管理対象のデータとが、別のデータベースとして蓄積されている。
しかしながら、第2実施形態に係る検索対象特定部131は、以下のように検索する点で第1実施形態と異なる。
具体的には例えば、検索対象特定部131は、データベース150B-1の行のデータの夫々のうち、第1実施形態で示した式(1)の条件を満たすデータを、検索対象の候補のデータとして特定する。これにより、検索対象特定部131は、最新の論理時刻において、有効なデータのうち、検索対象論理時刻stにおいて有効である管理対象のデータを、検索対象の候補のデータとして特定することができる。
具体的には例えば、検索対象特定部131は、データベース150B-2の行のデータの夫々のうち、第1実施形態で示した式(1)及び式(2)の条件を満たすデータを、検索対象の候補のデータとして特定する。例えば、管理対象のデータが削除される様な更新処理がされた後において、削除された管理対象のデータは、最新の論理時刻において無効な管理対象のデータである。検索対象特定部131は、第1実施形態で上述したのと同様に、検索対象論理時刻stにおいて有効であった管理対象のデータを、データベース150B-2から、検索対象の候補のデータとして特定する。
ここで、総合的な検索対象の候補のデータが、検索部132おける検索対象特定部131により特定された検索対象の候補のデータとして採用され、検索に用いられる。
即ち、第2実施形態において、検索処理に係る処理のうち、第1実施形態で示した式(1)及び式(2)の条件を満たすか否かを判定する処理を削減できるため、検索処理に係る計算資源を節約することができる。
更新処理が行われることにより、データベース150B-1又はデータベース150B-2に蓄積して管理すべきデータ(管理対象のデータ)が発生すると、格納処理が開始されて、次のようなステップS21乃至S25の処理が実行される。
無効になった管理対象のデータがある場合、ステップS23の処理においてYESであると判定されて、処理はステップS24に進む。
これにより、格納処理は終了する。
即ち、無効になったデータがない場合、ステップS23の処理においてNOであると判定されて、処理はステップS25に進む。即ち、無効になったデータがある場合に実行されたステップS24の処理は、無効になった管理対象のデータがない場合には実行されない。
これにより、格納処理は終了する。
なお、以下の説明において、上述の第1実施形態の説明と同様に、「A」というスキーマが「a1」、「B」というスキーマが「b1」、「C」というスキーマが「c1」であることを、「(A,B,C)=(a1,b1,c1)」と記載する。
第1の例では、更新処理前には、論理時刻10乃至12において、管理対象のデータが(A,B,C)=(a2,b2,c2)であったものが、論理時刻=「12」における更新処理により、管理対象のデータ(A,B,C)=(a2,b2’,c2’)に更新されたものとする。
第1の例では無効になった管理対象のデータ(A,B,C)=(a2,b2,c2)があるため、ステップS23の処理においてYESであると判定されて、処理はステップS24に進む。
これにより格納処理は終了となる。
次に、データベース150B-1の中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をする。
第2の例では、更新処理前には、論理時刻10までにおいて、「tid」が「1003」の管理対象のデータは存在しなかったが、論理時刻10における更新処理により、管理対象のデータ(A,B,C)=(a3,b3,c3)が更新(追加)されたものとする。
第2の例では無効になったデータがないため、ステップS23の処理においてNOであると判定されて、処理はステップS25に進む。
これにより格納処理は終了となる。
以上、データベース150B-1の中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をした。
また、第2の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップS24の処理は実行されない。また、更新処理により、有効となる管理対象のデータ(A,B,C)=(a3,b3,c3)が、ステップS25の処理によりデータベース150B-1に蓄積されて管理される。
次に、本発明の第3実施形態に係るデータベース管理システムについて説明する。
第3実施形態に係るデータベース管理システムの構成は、第1実施形態と同様である。即ち、図1はそのまま、本発明の第3実施形態に係るデータベース管理システムの構成を示している。よって、本発明の第3実施形態に係るデータベース管理システムの構成の説明は省略する。
また、図示はしないが、第3実施形態に係るデータベース管理システムのクライアント系ノード2及びトランザクション管理系ノード3の夫々は、図3に示すハードウェア構成と基本的に同様の構成を有している。
よって、本発明の第3実施形態に係る、ストレージ管理系ノード1、クライアント系ノード2、及びトランザクション管理系ノード3の夫々のハードウェア構成の説明は省略する。
即ち、第1実施形態で採用された仕組みは、RDBMSにより管理されるリレーショナル形式のデータベースが採用されている仕組みであった。これにより、管理対象のデータ、当該管理対象のデータの挿入論理時刻xt_ins及び削除論理時刻xt_delが、データベース150Aのスキーマとして蓄積された。
このような第1実施形態で採用される仕組みに対して、第3実施形態で採用される仕組みは、後述するKVSにより管理されるデータベースが採用される仕組みである。詳細は後述するが、これにより、最新の論理時刻における有効な管理対象のデータ、無効な管理対象のデータの挿入論理時刻xt_ins、及び削除論理時刻xt_delが、データベース150CのValueとして蓄積される。また、管理対象のデータの行番号情報が、データベース150CのKeyとして蓄積される。即ち、第3実施形態で採用される仕組みは、KVSにより管理されるデータベース150Cを利用した仕組みである。
KVSとは、キーと値(Value)の組を大量に蓄積し、キーを指定して検索を高速に実行可能なデータベース管理システムのことである。KVSにより管理されるデータベースは、RDBMSにより管理されるリレーショナル形式のデータベースと比較して、機能が極めて限定されている代わりに、性能が高いという特徴がある。
具体的には、図10は、第3実施形態におけるストレージ管理系ノード1で管理されるデータベース150に含まれる、検索対象論理時刻stが「11」の場合の検索対象の候補のデータのリレーションRCを示す図である。
具体的には、図11に示すデータベース150Cは、図10に示すリレーションRCと同様に、KVSにより管理されており、スキーマとしてKeyとValueとを持つ。ここで、図11に示すデータベース150Cに示すように、第1実施形態や第2実施形態における行番号「tid」は、「Key」として管理される。また、第1実施形態や第2実施形態における管理対象のデータは、「Value」として管理される。
しかしながら、第3実施形態に係る検索対象特定部131は、以下のように検索する点で第1実施形態と異なる。
具体的には例えば、検索対象特定部131は、データベース150Cの行のデータの夫々のうち、検索内容に関する行番号の情報を、行番号情報として指定する。即ち、検索対象特定部131は、行番号情報に基づき、KVSで管理されるデータベース150Cにおける「Key」と一致する行を、検索対象の候補のデータとして特定する。これにより、検索対象特定部131は、行番号情報により特定された検索対象の候補のデータの夫々のValueの夫々が取得できる。
更新処理が行われることにより、データベース150Cに蓄積して管理すべきデータ(管理対象のデータ)が発生すると、格納処理が開始されて、次のようなステップS31乃至S35の処理が実行される。
無効になった管理対象のデータがある場合、ステップS33の処理においてYESであると判定されて、処理はステップS34に進む。
これにより、格納処理は終了する。
即ち、無効になったデータがない場合、ステップS33の処理においてNOであると判定されて、処理はステップS35に進む。即ち、無効になったデータがある場合に実行されたステップS34の処理は、無効になった管理対象のデータがない場合には実行されない。
これにより、格納処理は終了する。
なお、以下の説明において、「挿入論理時刻xt_ins」が「7」であることを、「xt_ins=7」と記載する。同様に、「削除論理時刻xt_del」が「∞」であることを「xt_del=∞」、「Value」が「ABCDEFG」であることを「value=ABCDEFG」と夫々記載する。また、この様な挿入論理時刻xt_insと、削除論理時刻xt_delと、Valueとが対応付けられたものを、「{xt_ins=7,xt_del=∞,value=ABCDEFG}」と記載する。
第1の例では、更新処理前には、論理時刻10乃至12において、管理対象のデータが「value=hijklmnop」であったものが、論理時刻12における更新処理により、管理対象のデータが「value=HIJKLMNOP」に更新されたものとする。
第1の例では無効になった管理対象のデータ「value=hijklmnop」があるため、ステップS33の処理においてYESであると判定されて、処理はステップS34に進む。
これにより格納処理は終了となる。
次に、データベース150Cの中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をする。
第2の例では、更新処理前には、論理時刻10までにおいて、「Key」が「1003」の管理対象のデータは存在しなかったが、論理時刻10における更新処理により、管理対象のデータ「value=1234567890」が更新(追加)されたものとする。
第2の例では無効になったデータがないため、ステップS23の処理においてNOであると判定されて、処理はステップS35に進む。
これにより格納処理は終了となる。
以上、データベース150Cの中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をした。
また、第2の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップS34の処理は実行されない。また、更新処理により、有効となる管理対象のデータ「value=1234567890」が、ステップS35の処理によりデータベース150Cに蓄積されて管理される。
次に、本発明の第4実施形態に係るデータベース管理システムについて説明する。
第4実施形態に係るデータベース管理システムの構成は、第1実施形態と同様である。即ち、図1はそのまま、本発明の第4実施形態に係るデータベース管理システムの構成を示している。よって、本発明の第4実施形態に係るデータベース管理システムの構成の説明は省略する。
また、図示はしないが、第4実施形態に係るデータベース管理システムのクライアント系ノード2及びトランザクション管理系ノード3の夫々は、図3に示すハードウェア構成と基本的に同様の構成を有している。
よって、本発明の第4実施形態に係る、ストレージ管理系ノード1、クライアント系ノード2、及びトランザクション管理系ノード3の夫々のハードウェア構成の説明は省略する。
即ち、第1実施形態で採用された仕組みは、データベースにより、挿入論理時刻xt_ins等が対応づけられて管理される仕組みであった。具体的には、管理対象のデータ、当該管理対象のデータの挿入論理時刻xt_ins及び削除論理時刻xt_delの夫々が、データベース150Aのスキーマの夫々として蓄積された。
このような第1実施形態で採用される仕組みに対して、第4実施形態で採用される仕組みは、後述するファイル名として、管理対象のデータの挿入論理時刻xt_ins等が対応づけられて管理される仕組みである。詳細は後述するが、これにより、管理対象のデータが、ファイルの内容として管理される。また、管理対象のデータの行番号情報、挿入論理時刻xt_ins、及び削除論理時刻xt_delが、ファイル名として管理される。即ち、第4実施形態で採用される仕組みは、ファイル名により管理対象のデータが管理される仕組みである。
第4実施形態に係る対象データ管理部114は、挿入論理時刻xt_ins、削除論理時刻xt_del、及び行番号情報をファイル名として、管理対象のデータをファイルの内容として、ファイルとそのファイルのファイル名とを対応付けて、記憶部18に格納する。つまり、第4実施形態におけるデータベースは、記憶部18に、複数のファイルとして格納されたファイル群である。
また、第4実施形態におけるストレージ管理系ノードで管理されるファイルのファイル名は、図13に示すファイル名内容対応表RDに示すように付与されている。即ち、図13に示すファイル名内容対応表RDは、第1実施形態乃至第3実施形態の行番号情報「tid」の代わりに、行を特定する情報として図13に示すファイル名内容対応表RDの「ファイル名」を採用している。
検索対象特定部131は、上述の判定を、複数のファイルの夫々に対して行うことで、総合的な検索対象論理時刻とする。
ここで、総合的な検索対象の候補のデータが、検索部132おける検索対象特定部131により特定された検索対象の候補のデータとして採用され、検索に用いられる。
これにより、挿入論理時刻xt_ins及び削除論理時刻xt_delを、データベース管理システムにおけるスキーマとして管理せず、ファイル名とすることで管理することができる。即ち、通常データベースにおいて処理するSQL等による処理が不要となり、検索処理における計算資源の消費が削減される。
更新処理が行われることにより、記憶部18に格納して管理すべきデータ(管理対象のデータ)が発生すると、格納処理が開始されて、次のようなステップS41乃至S45の処理が実行される。
無効になった管理対象のデータがある場合、ステップS43の処理においてYESであると判定されて、処理はステップS44に進む。
これにより、格納処理は終了する。
即ち、無効になったデータがない場合、ステップS43の処理においてNOであると判定されて、処理はステップS45に進む。即ち、無効になったデータがある場合に実行されたステップS44の処理は、無効になった管理対象のデータがない場合には実行されない。
これにより、格納処理は終了する。
第1の例では、更新処理前には、論理時刻10乃至12において、管理対象のデータが「hijklmnop」であったものが、論理時刻12における更新処理により、管理対象のデータ「HIJKLMNOP」に更新されたものとする。
第1の例では無効になった管理対象のデータ「hijklmnop」があるため、ステップS43の処理においてYESであると判定されて、処理はステップS44に進む。
これにより格納処理は終了となる。
次に、記憶部18の中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をする。
第2の例では、更新処理前には、論理時刻が「10」である時刻までにおいて、行を特定する情報が「baz」の管理対象のデータは存在しなかったが、論理時刻10における更新処理により、管理対象のデータ「1234567890」が更新(追加)されたものとする。
第2の例では無効になったデータがないため、ステップS43の処理においてNOであると判定されて、処理はステップS45に進む。
これにより格納処理は終了となる。
以上、記憶部18の中に無効になった管理対象のデータがない場合の第2の例を用いて格納処理の説明をした。
また、第2の例のように、管理対象のデータを追加する様な更新処理の場合、更新処理により無効となる管理対象のデータは存在せず、ステップS44の処理は実行されない。また、更新処理により、有効となる管理対象のデータ「1234567890」が、ステップS45の処理により記憶部18に格納されて管理される。
このように同時並行的に更新処理が管理される場合、先に反映(コミット)された更新処理の内容は、後に反映(コミット)されようとする更新処理の内容に優先する。更には、先に反映された更新処理の内容により変更されていない場合にのみ、後に反映されようとする更新処理の内容が反映される。このように、「先に反映(コミット)された更新処理の内容は、後に反映(コミット)されようとする更新処理の内容に優先する」といったルールを、「First-Committer-Wins Rule」と呼ぶ。
例えば、ストレージ管理系ノード1は、スナップショットのデータベース150-1Sと更新されたスナップショットのデータベース150-1Mを生成しない。この場合、ストレージ管理系ノード1は、更新処理によって差異が生じる管理対象のデータについて、当該差異等を管理する。
即ち、トランザクション管理系ノード群G3は、複数の更新処理を、更新処理に係る差異として管理したうえで、「First-Committer-Wins Rule」に則って、ストレージ管理系ノード1のデータベース150に反映(コミット)する。
具体的には例えば、管理対象のデータは、「複数行」毎に管理されてもよく、第4実施形態の説明のように「ファイル」毎に管理されてもよい。
具体的には例えば、データベースの更新毎に付与された整数値でもよく、「年」「月」「日」「時」「分」「秒」等の組み合わせで示される、日時の形態の情報でもよい。
具体的には例えば、挿入論理時刻xt_ins、及び削除論理時刻xt_delに挟まれた論理時刻の時間帯を示しうる情報を取得すれば足りる。
具体的には例えば、式(1)及び式(2)に代えて、以下の式(3)及び式(4)を満たすか否かを確認することで、その行の管理対象のデータが有効であったか否かを判定することができる。
st < xt_del ・・・ (4)
st ≦ xt_del+ε ・・・ (6)
具体的には例えば、管理対象のデータが複数行毎に管理されている場合、複数行の何番目であるかの情報であればよく、管理対象のデータがファイル毎に管理されている場合、ファイル名であってよい。
具体的には例えば、第2実施形態乃至第4実施形態に示したように、対応づけて管理してよい。
具体的には例えば、対象データ管理部114は、任意に設定した整数値を未だ無効になっていない旨を示す情報として採用してよい。更に言えば、未だ無効になっていない旨を示す情報を示す値を数値として管理する場合、未だ無効になっていない旨を示す情報は、大きな値が望ましい。これにより、検索対象論理時刻stと削除論理時刻xt_delとの大小関係を用いて、検索対象の候補のデータを特定することができる。
具体的には例えば、対象データ管理部114は、任意の数のデータベースに管理対象のデータを蓄積して管理してよい。例えば、対象データ管理部114は、最新の論理時刻において無効な管理対象のデータを、論理時刻の区分毎に複数のデータベースに蓄積してもよい。即ち例えば、所定の論理時刻よりも前の論理時刻において無効となった管理対象のデータは、第3のデータベースに蓄積して管理されてもよい。この場合、検索処理において、検索対象の候補のデータが第1のデータベース及び第2のデータベースにも含まれない場合に、第3のデータベースから検索対象の候補のデータが特定されてよい。これにより、検索処理の対象となりづらい管理対象のデータを別のデータベースとして管理し、検索処理等の処理に係るコストを削減することができる。
具体的には例えば、オンラインバンキングシステムや、航空券の予約システム等、大量の検索と更新が入り混じっており、整合性が必要とされる(絶対に間違いが許されない)システムを管理する効率が向上する可能性がある。
具体的には例えば、更新の大部分はデータの新規追加がほとんどであるが、稀に変更や削除が行われるようなシステムを管理する効率が向上する可能性がある。即ち例えば、IoTシステムにおける大量のセンサーから送られてくるデータの蓄積を行うシステムや、SNS(Social Networking System)のデータの蓄積を行うシステムにおいて、効率が向上する可能性がある。即ち例えば、大量のセンサーから送られてくるデータやSNSのデータは、大量の文字情報、画像、動画等であって、稀に変更や削除が行われる。
例えば、データベース管理システムを介さずより高速に処理を行いたい場合や、各種リソースの量の制限によりデータベース管理システムを動かしにくいシステム(例えば、組込みシステム)をストレージ管理系に利用したい場合等に、データを管理する効率が向上する可能性がある。
具体的には例えば、トランザクション管理(更新処理の管理)や、当該管理にSIの方式を採用することで、整合性を保ったままデータの複製を複数持つことできるため、可用性を高めることができる。即ち、複数のノードのうち何れかのノードの一部が壊れた場合において、データが失われない。換言すれば、データベース管理システムは、複数のノードのうち何れかのノードの一部が壊れた場合においても、正常に稼働を続けることができる。即ち、データベース管理システムは、論理時刻を用いてデータベースを管理することでトランザクション管理を行う。これにより、複数のストレージ管理系ノード1の間でのデータベースの整合性を保つことができる。
換言すると、図4の機能的構成は例示に過ぎず、特に限定されない。
即ち、上述した一連の処理を全体として実行できる機能が情報処理システムに備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図4の例に限定されない。また、機能ブロックの存在場所も、図4に特に限定されず、任意でよい。例えば、ストレージ管理系ノード1の機能ブロックをクライアント系ノード2等に移譲させてもよい。逆にクライアント系ノード2の機能ブロックをストレージ管理系ノード1等に移譲させてもよい。
また、1つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。
また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。
即ち、本発明が適用される情報処理システム(例えば、図4のストレージ管理系ノード1)は、
データを所定単位(例えば、図5(B)の「行」)毎に管理する情報処理システムであって、
管理対象のデータ(例えば、図5(B)の「a3」、「b3」、「c3」)が有効になった時間帯の少なくとも一部を特定可能な第1情報(例えば、「論理時刻xt」や「その幅」であって、図6の「xt_ins」や「xt_del」であり、管理対象のデータが図6の「a3」、「b3」、「c3」ならば「10」や「15」)を取得する第1取得手段(例えば、図4の論理時刻情報取得部112)と、
前記管理対象のデータが属する前記所定単位を特定可能な第2情報(例えば、図5や図6の「tid」)を取得する第2取得手段(例えば、図4の行番号情報取得部113)と、
前記第1情報と、前記第2情報と、前記管理対象のデータとを対応付けて管理する(例えば図6のデータベース150Aのように管理する)管理手段(例えば、図4の対象データ管理部114)と、
を備える。
前記管理対象のデータが有効になった時点を特定可能な第1の1情報(例えば、図6の「xt_ins」の値)と、
前記管理対象のデータが無効になった時点を特定可能な第1の2情報(例えば、図6の「xt_del」の値)と、
を含む情報を前記第1情報として、
前記第2情報と、前記管理対象のデータとに対応付けて管理することができる。
管理対象の1以上の前記データのうち、有効な1以上のデータを第1データ群(例えば図8(A)のデータベース150B―1で管理されるデータ群)として、無効な1以上のデータを第2データ群(例えば図8(B)のデータベース150B―2で管理されるデータ群)として夫々管理し、
前記第1データ群に含まれる管理対象のデータついては、
前記管理対象のデータが有効になった時点を特定可能な第1の1情報(例えば、図8(A)の「xt_ins」の値)を前記第1情報として、
前記第2情報と、前記管理対象のデータとを対応付けて管理し、
前記第2データ群に含まれる管理対象のデータついては、
前記第1の1情報(例えば、図8(B)の「xt_ins」の値)と、
前記管理対象のデータが無効になった時点を特定可能な第1の2情報(例えば、図8(B)の「xt_del」の値)と、
を含む情報を前記第1情報として、
前記第2情報と、前記管理対象のデータとを対応付けて管理することができる。
前記第2情報(例えば、図11の「tid=1001」のような「Key」)と、前記管理対象のデータ(例えば、図11の「value=ABCDEFG」)及び前記第1情報(例えば、図11の「xt_ins=7」や「xt_del=∞」)を含む情報(例えば、管理対象のデータと論理時刻のデータを含む「Value」)とを対応付けて(例えば、図11のKVS形式のデータベース150Cのように)管理することができる。
ここで、1つの情報(例えば、第2情報)と対応付けられた他の情報を管理するデータベース管理システムは、通常、他のデータベース管理システム(例えば、RDBMSにより管理されるリレーショナル形式のデータベース)と比較して性能が高い。即ち、情報処理システムは、検索処理の性能を向上させることができる。
前記管理手段は、前記ファイル名を管理することで、前記第1情報と、前記第2情報と、前記管理対象のデータとを対応付けて管理(例えば、記憶部18に記憶された、図14に示すファイルの一覧のように管理)することができる。
また例えば、第1情報を、データベース管理システムにおけるスキーマとして管理せず、単にファイルのファイル名として管理することができる。即ち、通常データベースにおいて処理するSQL等による処理が不要となり、検索処理における計算資源の消費を削減することができる。
前記管理手段により管理される前記第1情報(図6のデータベース150Aの「xt_ins」、「xt_del」)、及び前記第3情報に基づき、前記第3情報により特定される時刻に有効であった前記管理対象のデータ(例えば、「検索対象論理時刻st」が「13」であった場合、図6のデータベース150Aの「tid」が「1001」の行、「1002」であって上の行、及び「1003」の行のデータ)を、検索対象の候補のデータとして特定する特定手段と、
前記特定手段により特定された前記検索対象の候補のデータ(例えば、図6のデータベース150Aの「tid」が「1001」の行、「1002」であって上の行、及び「1003」の行のデータを抽出した図5(C)のデータベース150-13)から検索する検索手段と、を備える。
前記管理対象のデータの更新の内容(例えば、図5(B)の「tid=1002」のB列を「b2’」とする更新の内容)を特定可能な情報を、更新要求情報として取得する取得手段(例えば、図4の更新要求情報取得部321)と、
前記更新要求情報に基づき、前記管理対象のデータが管理される前記第1情報処理システムに対して当該更新要求情報を送信することで、当該更新の要求(送信すべきか、送信した結果が処理されたか)を管理する管理手段(例えば、図4の更新要求整合性管理部322)と、
を備え、
前記第1情報処理システムは、
前記第2情報処理システムから送信されてくる前記更新要求情報に基づき、更新をされた前記管理対象のデータを更新後管理対象のデータとして生成し、当該更新後管理対象のデータを有効化し、
前記更新後管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な有効時間帯情報を取得し、
前記更新後管理対象のデータが属する前記所定単位を特定可能な所定単位特定情報を取得し、
前記有効時間帯情報と、前記所定単位特定情報と、前記更新後管理対象のデータとを対応付けて管理することができる。
先の時点に取得された更新要求情報により更新される管理対象のデータ(例えば、「更新要求整合性管理部322-2により管理される更新処理により更新される管理対象のデータ」)が後の時点に取得された他の更新要求情報により更新されるか否か(例えば、「更新要求整合性管理部322-1により管理される更新処理により更新されるか否か」)に基づき、前記管理対象のデータが管理される前記第1情報処理システムに対して当該他の更新要求情報(例えば、「更新要求整合性管理部322-1により管理される更新処理」)を送信するか否かを管理することができる。
また、第1情報処理装置により管理されるデータベースの整合性が維持されるからこそ、複数の第2情報処理システムの夫々により、同時に複数の更新の夫々の要求を処理することができる。
即ち、第1情報処理システムと、複数の第2情報処理システムを含む様に、情報処理システムを構成すると、スケールアウトがされた環境において、第1情報処理装置により管理されるデータベースは、更新処理に係る整合性が維持される。即ち例えば、第1情報処理システム及び第2情報処理システムを含む情報処理システムは、複数の情報処理システムを活用することで、整合性を維持したまま、データベースに対する処理能力を向上させることができる。
Claims (8)
- 管理対象のデータを所定単位毎に管理し、管理対象のデータを、該データが削除されていない場合は挿入論理時刻以降、該データが削除されている場合は挿入論理時刻から削除論理時刻までの間、有効なものとして取り扱う第1情報処理システムであって、2以上のストレージ管理系ノードからなる第1情報処理システムと、
前記第1情報処理システムにより前記管理対象のデータが所定単位毎に管理されている場合における、当該管理対象のデータの更新を管理する、トランザクション管理のための第2情報処理システムと、
を備え、検索要求又は更新要求の発行元となるクライアント系ノードと相互に接続された情報処理システムであって、
前記第2情報処理システムは、
前記管理対象のデータの更新の内容を特定可能な情報を、更新要求情報として取得する取得手段と、
前記更新要求情報に基づき、前記管理対象のデータが管理される前記第1情報処理システムに対して当該更新要求情報を送信する更新要求管理手段と、
を備え、
前記第1情報処理システムは、
前記第2情報処理システムから送信されてくる前記更新要求情報に基づき、更新をされた前記管理対象のデータを更新後管理対象のデータとして生成し、当該更新後管理対象のデータを有効化し、
前記更新後管理対象のデータが有効になった時間帯の少なくとも一部を特定可能な有効時間帯情報を取得する第1取得手段と、
前記更新後管理対象のデータが属する前記所定単位を特定可能な所定単位特定情報を取得する第2取得手段と、
前記有効時間帯情報と、前記所定単位特定情報と、前記更新後管理対象のデータとを対応付けて管理するデータ管理手段と、
前記クライアント系ノードから送信された検索要求情報を、トランザクション管理のための前記第2情報処理システムを介することなく受信し、当該検索要求情報から、どのような内容の検索を行うかを示す検索内容情報を取得する検索内容情報取得手段と、
前記管理対象のデータが有効であった前記時間帯のうち、所定の時刻を特定可能な時刻特定情報を取得する第3取得手段と、
前記データ管理手段により管理される前記有効時間帯情報、及び前記時刻特定情報に基づき、前記時刻特定情報により特定される時刻に有効であった前記管理対象のデータを、前記検索内容情報に係る検索対象の候補のデータとして特定する特定手段と、
前記検索内容情報から認識された検索の条件を満たすデータを、前記特定手段により特定された前記検索対象の候補のデータから検索する検索手段と、
前記検索手段による検索結果を、前記クライアント系ノードに対して提示する検索結果提示手段と、
を備える、
情報処理システム。 - 前記第1情報処理システムは、2以上に分割された前記管理対象のデータの、分割された夫々の部分を記憶する前記2以上のストレージ管理系ノードからなる、
請求項1に記載の情報処理システム。 - 前記第2情報処理システムの前記更新要求管理手段は、
後の時点に取得された他の更新要求情報が、先の時点に取得された更新要求情報により更新されることとなる管理対象のデータを更新しようとするものであるか否かを判定し、後の時点に取得された他の更新要求情報が、先の時点に取得された更新要求情報により更新されることとなる管理対象のデータを更新しようとするものであると判定された場合、前記管理対象のデータが管理される前記第1情報処理システムに対して当該他の更新要求情報を送信しない、
請求項1又は2に記載の情報処理システム。 - 前記データ管理手段は、
前記管理対象のデータが有効になった時点を特定可能な第1の1情報と、
前記管理対象のデータが無効になった時点を特定可能な第1の2情報と、
を含む情報を前記有効時間帯情報として、
前記所定単位特定情報と、前記管理対象のデータとに対応付けて管理する、
請求項1から3のいずれか一項に記載の情報処理システム。 - 前記第1の2情報は、前記管理対象のデータが未だ無効になっていない旨を示す情報を含む、
請求項4に記載の情報処理システム。 - 前記データ管理手段は、
管理対象の1以上の前記データのうち、有効な1以上のデータを第1データ群として、無効な1以上のデータを第2データ群として夫々管理し、
前記第1データ群に含まれる管理対象のデータついては、
前記管理対象のデータが有効になった時点を特定可能な第1の1情報を前記有効時間帯情報として、
前記所定単位特定情報と、前記管理対象のデータとを対応付けて管理し、
前記第2データ群に含まれる管理対象のデータついては、
前記第1の1情報と、
前記管理対象のデータが無効になった時点を特定可能な第1の2情報と、
を含む情報を前記有効時間帯情報として、
前記所定単位特定情報と、前記管理対象のデータとを対応付けて管理する、
請求項1から3のいずれか一項に記載の情報処理システム。 - 前記データ管理手段は、
前記所定単位特定情報と、前記管理対象のデータ及び前記有効時間帯情報を含む情報とを対応付けて管理する、
請求項1から3のいずれか一項に記載の情報処理システム。 - 前記管理対象のデータは、前記有効時間帯情報及び前記所定単位特定情報を含むファイル名のファイルとして所定の媒体に記憶されており、
前記データ管理手段は、前記ファイル名を管理することで、前記有効時間帯情報と、前記所定単位特定情報と、前記管理対象のデータとを対応付けて管理する、
請求項1から3のいずれか一項に記載の情報処理システム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019099392A JP7398066B2 (ja) | 2019-05-28 | 2019-05-28 | 情報処理システム |
PCT/JP2020/021032 WO2020241727A1 (ja) | 2019-05-28 | 2020-05-28 | 情報処理システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019099392A JP7398066B2 (ja) | 2019-05-28 | 2019-05-28 | 情報処理システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2020194335A JP2020194335A (ja) | 2020-12-03 |
JP7398066B2 true JP7398066B2 (ja) | 2023-12-14 |
Family
ID=73545970
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019099392A Active JP7398066B2 (ja) | 2019-05-28 | 2019-05-28 | 情報処理システム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP7398066B2 (ja) |
WO (1) | WO2020241727A1 (ja) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001101053A (ja) | 1999-09-30 | 2001-04-13 | Toshiba Corp | トランザクション管理方法及びトランザクション管理装置 |
JP2011086241A (ja) | 2009-10-19 | 2011-04-28 | Internatl Business Mach Corp <Ibm> | データベースの複製を生成する装置及び方法 |
JP2016103115A (ja) | 2014-11-27 | 2016-06-02 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | データベースを管理するシステム及び方法 |
-
2019
- 2019-05-28 JP JP2019099392A patent/JP7398066B2/ja active Active
-
2020
- 2020-05-28 WO PCT/JP2020/021032 patent/WO2020241727A1/ja active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001101053A (ja) | 1999-09-30 | 2001-04-13 | Toshiba Corp | トランザクション管理方法及びトランザクション管理装置 |
JP2011086241A (ja) | 2009-10-19 | 2011-04-28 | Internatl Business Mach Corp <Ibm> | データベースの複製を生成する装置及び方法 |
JP2016103115A (ja) | 2014-11-27 | 2016-06-02 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | データベースを管理するシステム及び方法 |
Also Published As
Publication number | Publication date |
---|---|
WO2020241727A1 (ja) | 2020-12-03 |
JP2020194335A (ja) | 2020-12-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10120895B2 (en) | Mirroring, in memory, data from disk to improve query performance | |
US10268746B2 (en) | Mechanism to run OLTP workload on in-memory database under memory pressure | |
EP3047400B1 (en) | Multi-version concurrency control on in-memory snapshot store of oracle in-memory database | |
CN105630863B (zh) | 用于多版本并发提交状态的事务控制块 | |
US10303682B2 (en) | Automatic verification and triage of query results | |
US10417265B2 (en) | High performance parallel indexing for forensics and electronic discovery | |
US20180203888A1 (en) | Multi-Version Concurrency Control Method in Database and Database System | |
US9639542B2 (en) | Dynamic mapping of extensible datasets to relational database schemas | |
US8051045B2 (en) | Archive indexing engine | |
US9026518B2 (en) | System and method for clustering content according to similarity | |
US10754854B2 (en) | Consistent query of local indexes | |
US9020916B2 (en) | Database server apparatus, method for updating database, and recording medium for database update program | |
US20090228473A1 (en) | Data storage for file updates | |
US11487714B2 (en) | Data replication in a data analysis system | |
EP2874077A2 (en) | Stateless database cache | |
CN107958023A (zh) | 数据同步方法、数据同步装置和计算机可读存储介质 | |
Hu et al. | Extracting deltas from column oriented NoSQL databases for different incremental applications and diverse data targets | |
JP7398066B2 (ja) | 情報処理システム | |
KR20190129474A (ko) | 데이터 검색 장치 및 방법 | |
US10394761B1 (en) | Systems and methods for analyzing and storing network relationships | |
CN111444179B (zh) | 数据处理方法、装置、存储介质及服务器 | |
CN116975053A (zh) | 一种数据处理方法、装置、设备、介质及程序产品 | |
CN117425886A (zh) | 具有仅添加数据结构的基于列表的数据搜索 | |
Maalouf | Performance Optimizations of NoSQL Databases in Distributed Systems | |
JP2023546818A (ja) | データベースシステムのトランザクション処理方法、装置、電子機器、及びコンピュータプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20200525 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20200528 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20200528 |
|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20200528 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20220414 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20230627 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20230824 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20231018 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20231115 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20231122 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7398066 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |