JP5772458B2 - データ管理プログラム、ノード、および分散データベースシステム - Google Patents

データ管理プログラム、ノード、および分散データベースシステム Download PDF

Info

Publication number
JP5772458B2
JP5772458B2 JP2011215290A JP2011215290A JP5772458B2 JP 5772458 B2 JP5772458 B2 JP 5772458B2 JP 2011215290 A JP2011215290 A JP 2011215290A JP 2011215290 A JP2011215290 A JP 2011215290A JP 5772458 B2 JP5772458 B2 JP 5772458B2
Authority
JP
Japan
Prior art keywords
data
time
transaction
node
storage unit
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
Application number
JP2011215290A
Other languages
English (en)
Other versions
JP2013077063A (ja
Inventor
知彦 平口
知彦 平口
信幸 武部
信幸 武部
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2011215290A priority Critical patent/JP5772458B2/ja
Priority to US13/614,632 priority patent/US20130085988A1/en
Publication of JP2013077063A publication Critical patent/JP2013077063A/ja
Application granted granted Critical
Publication of JP5772458B2 publication Critical patent/JP5772458B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2365Ensuring data consistency and integrity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, 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)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、データ管理プログラム、ノード、および分散データベースシステムに関する。
データベースにおいて、データの参照が発生した場合に、整合性のあるデータを参照する必要がある。
整合性のあるデータ(または、Atomicなデータと呼ぶ)とは、あるトランザクションが更新を行なう前のデータ集合か、もしくはコミットした後のデータ集合のどちらかである。
ここで、整合性のあるデータの例を説明する。
図1Aは、トランザクションの実行時間を示す図である。
図1Bは、参照されるデータを示す図である。
図1Aにおいて横軸は時間を示しており、各トランザクションT1〜T5の実行時間を示している。
また、トランザクションT1〜T4は、それぞれレコードR1〜R4を更新する。尚、レコードはコミットされることで更新が確定する。
トランザクションT1は、時刻t_T1_aでレコードR1をコミットする。
トランザクションT2は、時刻t_T2_bでトランザクションを開始し、時刻t_T2_aでレコードR2をコミットする。
トランザクションT3は、時刻t_T3_aでレコードR3をコミットする。
トランザクションT4は、時刻t_T4_bでトランザクションを開始し、時刻t_T4_aでレコードR4をコミットする。
尚、時刻t_T1_a、t_T2_b、t_T3_a、およびt_T4_bは時刻tより前であり、時刻t_T2_aおよびt_T4_aは時刻tより後である。
図1Aにおいて、トランザクションT5が時刻tで参照する整合性のあるデータ(すなわちレコードR1〜R4)は以下の(1)または(2)どちらかである。
(1)トランザクションT1、T3で更新された後のデータ(t_T1_a、t_T3_a時点のデータ)、且つトランザクションT2、T4で更新される前のデータ(t_T2_b、t_T4_b時点のデータ)。
(2)トランザクションT1、T3で更新された後のデータ(t_T1_a、t_T3_a時点のデータ)、且つトランザクションT2、T4で更新された後のデータ(t_T2_a、t_T4_a時点のデータ)。尚、データ集合(2)を参照する場合は、トランザクションT2、T4がコミットするまで待ちが発生し、トランザクションT2、T4のコミット後にデータを参照する。
図1Bは、データ集合(1)を示している。すなわち、時刻tでトランザクションT5が参照するレコードR1〜R4は、それぞれ時刻t_T1_a、t_T2_b、t_T3_a、t_T4_aにおける値である。すなわち、時刻tでトランザクションT5が参照するレコードR1〜R4は、時刻tでコミット済みのデータである。
また、データ集合(2)の場合は、レコードR1、R3はデータ集合(1)と同じであるが、レコードR2、R4は、コミット後のレコードR2’、R4’となる。すなわち、時刻t_T2_a、t_T4_aにおける値となる。
現在、データベース技術において、スケーラビリティやアベイラビリティの向上のために、分散データベースが用いられている。
分散データベースは、ネットワークに接続した複数のノードにデータを分散して配置し、複数のノードが持っている複数のデータベースをあたかも単一のデータベースであるかのように見せる技術である。
分散データベースでは、複数のノードにデータが分散されて配置されている。各ノードは、キャッシュを有し、該キャッシュに自身が担当するデータを格納している。また、各ノードは他のノードが担当するデータを自身のキャッシュに格納する場合もある。
尚、キャッシュに格納されているデータはキャッシュデータと呼ぶ。
また、分散データベースに関する技術で、複数のノードで参照・更新を受け付ける方式がある。
図2Aは、複数ノードにおけるデータの更新を示す図である。
図2Bは、複数ノードにおいてトランザクションBが参照するデータを示す図である。
尚、以下の説明および図において、トランザクションをトランと表記する場合がある。
ノード1005は、キャッシュ1006を有し、キャッシュ1006は、レコードR1およびR2を格納している。
ノード1015は、キャッシュ1016を有し、キャッシュ1016は、レコードR1およびR2を格納している。
トランザクションAの開始時におけるレコードR1、R2の値は、それぞれR1_a、R2_aである。
図2Aでは、2つのトランザクションAおよびBを実行する。トランザクションAはデータの更新を行い、トランザクションBはデータの参照を行う。
トランザクションAの処理内容は、
(1)トランザクション開始
(2)レコードR1をR1_bに更新(UPDATE R1→R1_b)
(3)レコードR2をR2_bに更新(UPDATE R2→R2_b)
(4)コミット
である。尚、上記処理(1)〜(4)の処理は、それぞれ10時、10時10分、10時20分、10時30分に実行される。
また、トランザクションAにおいて、レコードR1およびR2の更新はノード1005で行われる。
トランザクションAが開始されると、ノード1005は、レコードR1をR1_aからR1_bに更新する。ノード1005は、更新したレコードR1の値R1_bをノード1015に送信する(ログシッピング)。また、ノード1005は、レコードR2をR2_aからR2_bに更新する。ノード1005は、更新したレコードR2の値R2_bをノード1015に送信する(ログシッピング)。
そして、ノード1005はトランザクションAをコミットする。
その後、ノード1005は、コミット指示をノード1015に送信し、コミット指示を受信したノード1015は、レコードR1、R2をコミットする。それにより、ノード1015のレコードR1はR1_aからR1_b、レコードR2はR2_aからR2_bに更新される
ノード1015のデータは、ノード1005の更新処理と非同期で更新される。
トランザクションBの処理内容は、
(1)トランザクション開始
(2)レコードR1を参照(SELECT R1)
(3)レコードR2を参照(SELECT R2)
(4)コミット
である。尚、トランザクションBは、ノード1015で実行される。
トランザクションBにおいて、レコードR1、R2を参照する場合、参照時刻によって参照されるデータは、図2Bに示すようになる。
トランザクションAの開始前、例えば9時50分に、レコードR1、R2を参照すると、レコードR1、R2の値は、それぞれR1_a、R2_aとなる。
トランザクションAの実行中、例えば10時15分に、レコードR1、R2を参照すると、レコードR1、R2の値は、コミット前なので、それぞれR1_a、R2_aとなる。尚、ノードには、MultiVersion Concurrency Control(MVCC:多版型同時実行制御)が実装されているものとする。
トランザクションAのコミット後、例えば10時40分に、レコードR1、R2を参照すると、レコードR1、R2の値は、ノード1015でコミットが行われていなければ、それぞれR1_a、R2_aとなる。また、レコードR1、R2の値は、ノード1015でコミットが行われていれば、それぞれR1_b、R2_bとなる。
特許第4362839号明細書 特開2006−235736号公報 特開平07−262065号公報
MySQL:MySQLのレプリケーションの特徴、[平成23年4月21日検索]、 インターネット、< URL:http://www.irori.org/doc/mysql-rep.html> Symfoware Active DB Guard:独自のログシッピング技術、[平成23年4月21日検索]、 インターネット、< URL:http://software.fujitsu.com/jp/symfoware/catalog/pdf/cz3108.pdf> Linkexpress Transactional Replication option:逐次差分連携方式、[平成23年4月21日検索]、 インターネット、< URL: http://software.fujitsu.com/jp/manual/manualfiles/M080000/J2X16100/02Z200/lxtro01/lxtro004.html>
図3Aは、従来の複数ノードの更新(マルチサイト更新)を行った場合のデータの更新を示す図である。
図3Bは、従来の方式においてマルチサイト更新を行った場合のトランザクションBが参照するデータを示す図である。
ノード1007は、キャッシュ1008を有し、キャッシュ1008は、レコードR1およびR2を格納している。
ノード1017は、キャッシュ1018を有し、キャッシュ1018は、レコードR1およびR2を格納している。
トランザクションAの開始時におけるレコードR1、R2の値は、それぞれR1_a、R2_aである。
図3Aでは、2つのトランザクションAおよびBを実行する。トランザクションAはデータの更新を行い、トランザクションBはデータの参照を行う。
トランザクションAの処理内容は、
(1)トランザクション開始
(2)レコードR1をR1_bに更新(UPDATE R1→R1_b)
(3)レコードR2をR2_bに更新(UPDATE R2→R2_b)
(4)コミット
である。尚、上記処理(1)〜(4)の処理は、それぞれ10時、10時10分、10時20分、10時30分に実行される。 また、トランザクションAにおいて、レコードR1の更新はノード1007で行われ、レコードR2の更新はノード1017で行われる。
トランザクションAが開始されると、ノード1007は、レコードR1をR1_aからR1_bに更新する。ノード1007は、更新したレコードR1の値R1_bをノード1017に送信する(ログシッピング)。
ノード1017は、レコードR2をR2_aからR2_bに更新する。ノード1017は、更新したレコードR2の値R2_bをノード1007に送信する(ログシッピング)。
そして、ノード1007、1017はトランザクションAをコミットする。
その後、ノード1007は、コミット指示をノード1017に送信し、コミット指示を受信したノード1017は、レコードR1をコミットする。それにより、ノード1017のレコードR1はR1_bに更新される。また、ノード1017は、コミット指示をノード1007に送信し、コミット指示を受信したノード1007は、レコードR2をコミットする。それにより、ノード1007のレコードR2はR2_bに更新される。
トランザクションBの処理内容は、
(1)トランザクション開始
(2)レコードR1を参照(SELECT R1)
(3)レコードR2を参照(SELECT R2)
(4)コミット
である。尚、トランザクションBは、ノード1017で実行される。
トランザクションBにおいて、レコードR1、R2を参照する場合、参照時刻によって参照されるデータは、図3Bに示すようになる。
トランザクションAの開始前、例えば9時50分に、レコードR1、R2を参照すると、レコードR1、R2の値は、それぞれR1_a、R2_aとなる。
トランザクションAの実行中、例えば10時15分に、レコードR1、R2を参照すると、レコードR1、R2の値は、コミット前なので、それぞれR1_a、R2_aとなる。尚、ノードには、MultiVersion Concurrency Control(MVCC:多版型同時実行制御)が実装されているものとする。
トランザクションAのコミット後、例えば10時40分に、レコードR1、R2を参照すると、レコードR1、R2の値は、ノード1017でレコードR1のコミットが行われていなければ、それぞれR1_a、R2_bとなる。また、レコードR1、R2の値は、ノード1017でレコードR1のコミットが行われていれば、それぞれR1_b、R2_bとなる。
すなわち、ノード1017でレコードR1のコミットが行われていなければ、レコードR1、R2の値は、それぞれR1_a、R2_bとなってしまい、整合性のあるデータが参照できないことになる。
このように、キャッシュデータ更新を非同期に行う方式でマルチサイト更新を行うと、整合性のあるデータを参照することが出来ない場合があった。
1つの側面では、本発明は、マルチサイト更新でキャッシュデータの更新を非同期に行う方式において、整合性のあるデータの参照を可能とすることを目的とする。
実施の形態に係るノードは、キャッシュと処理部とを備える。
キャッシュは、他ノードに格納されているデータの少なくとも一部であるキャッシュデータと、分散データベースシステムにおいて、実行されているトランザクションの一覧を示す第1のトランザクション一覧と、前記第1のトランザクション一覧の要求をトランザクション管理装置が受信した時刻を示す第1の時刻と、を格納する。
処理部は、前記キャッシュデータに含まれる複数世代を有するレコードの参照要求を受信したときに、第2のトランザクション一覧と前記第2のトランザクション一覧の要求を前記トランザクション管理装置が受信した時刻を示す第2の時刻を受信して前記キャッシュに格納する。そして、処理部は、前記第1の時刻と前記第2の時刻とを比較し、比較結果に基づいて、前記第1のトランザクション一覧または前記第2のトランザクション一覧のいずれかを第3のトランザクション一覧として選択し、前記第3のトランザクション一覧を用いて、前記複数世代を有するレコードのうち参照する世代のレコードを特定する。
実施の形態のノードによれば、マルチサイト更新でキャッシュデータの更新を非同期に行う方式において、整合性のあるデータの参照を可能とすることができる。
トランザクションの実行時間を示す図である。 参照されるデータを示す図である。 複数ノードにおけるデータの更新を示す図である。 複数ノードにおいてトランザクションBが参照するデータを示す図である。 従来の複数ノードの更新(マルチサイト更新)を行った場合のデータの更新を示す図である。 従来の方式においてマルチサイト更新を行った場合のトランザクションBが参照するデータを示す図である。 実施の形態に係る分散データベースシステムの構成図である。 実施の形態に係るノードの構成図である。 キャッシュの構成図を示す図である。 ページの詳細な構成を示す図である。 レコードの構成を示す図である。 実施の形態に係るトランザクション管理装置の構成図である。 実施の形態に係るキャッシュデータの最新化を示す図である。 実施の形態に係るキャッシュデータ最新化処理のフローチャートである。 実施の形態に係るデータの整合性を説明する図である。 実施の形態に係るスナップショット選択処理のフローチャートである。 実施の形態に係る参照レコードの特定処理のフローチャートである。 Satisfy処理の例を示す図である。 情報処理装置(コンピュータ)の構成図である。
以下、図面を参照しながら実施の形態を説明する。
図4は、実施の形態に係る分散データベースシステムの構成図である。
分散データベースシステム101は、ロードバランサ201、複数のノード301−i(i=1〜3)、およびトランザクション管理装置401を備える。尚、ノード301−1〜301−3は、それぞれノード1〜3と表記する場合もある。
ロードバランサ201は、クライアント端末501と接続し、クライアント端末501からの要求を均等になるようにノード301のいずれかに振り分ける。尚、ロードバランサ201は、例えば、シリアルバスでノード301と接続している。
ノード301−iは、キャッシュ302−iと記憶部303−iを備える。
キャッシュ302−iは、キャッシュデータ304−iを有する。
キャッシュデータ304−iは、ノード301−iが有するデータベース305−iと同じ内容のデータを保持している。また、キャッシュデータは、他のノードが有するデータベース305と同じ内容のデータの一部または全てを有している。
例えば、キャッシュデータ304−1は、データベース305−1と同じ内容を有している。さらに、キャッシュデータ304−1は、データベース305−2、305−3の一部または全ての内容を有している。
キャッシュデータ304の内、自ノードが担当しているデータは、自ノードのデータベースの更新と同期して更新される。すなわち、キャッシュデータ304の内、自ノードが担当しているデータは最新のデータとなる。
キャッシュデータ304の内、他ノードが担当しているデータは、他ノードのデータベースの更新と非同期に更新される。すなわち、キャッシュデータ304の内、他ノードが担当しているデータは、最新のデータとならない場合がある。
記憶部303−iは、データベース305−iを有する。
ノード301は、クライアント端末501から要求されたデータが自身のキャッシュデータ304に無い場合は、該データを保持するノード301へ要求を送信し、該データを取得し、キャッシュデータ304として格納する。
トランザクション管理装置401は、分散データベースシステム101で実行されるトランザクションを制御する。尚、トランザクション管理装置401は、例えば、シリアルバスでノード301と接続している。
分散データベースシステム101において、データベース305の更新は複数のノードで行われる。すなわち、分散データベースシステム101は、マルチサイト更新を行う。
図5は、実施の形態に係るノードの詳細な構成図である。
図5では、ノード301−1の詳細な構成図を記載している。尚、ノード301−2、301−3については、保持するデータが違うだけで構成は同じため、説明は省略する。
ノード301−1は、受付部311、データ操作部312、レコード操作部313、キャッシュ管理部314、トランザクション管理部315、キャッシュ最新化部316、ログ管理部317、通信部318、キャッシュ319、および記憶部320を備える。
尚、キャッシュ319および記憶部320は、図4のキャッシュ302−1および記憶部303−1に対応している。
受付部311は、データベース操作、例えば、参照や更新、トランザクションの開始/終了などを受け付ける。
データ操作部312は、データベース作成時に定義した情報を参照して、受付部311が受け付けたデータ操作命令を解釈して実行する。
データ操作部312は、トランザクションの開始および終了指示をトランザクション管理部315に指示する。
データ操作部312は、受付部311が受け付けたデータ操作命令と定義情報を参照して、どのようにデータベースにアクセスするかを決定する。
データ操作部312は、アクセス手順に従い、レコード操作部313を呼び出してデータの検索や更新を実行する。データベースのレコードは、更新の度に新たな世代レコードを生成する方式になっているので、データの検索時はレコード操作部313に、どの時刻(例えばトランザクション開始時刻や、データ操作命令の実行時刻)のコミット済データを検索するかを通知する。また、データ更新時には、各データの担当ノードの情報を管理しているロケータ322を参照し、自ノードが更新データの担当ノードならば、自ノードのレコード操作部313に更新依頼を行う。自ノードが担当ノードでなければ、通信部318を介して担当ノードへ更新データを転送し、更新依頼を行う。
レコード操作部313は、データベースの検索や更新、トランザクションの終了、ログの採取を行なう。データベース323およびキャッシュデータ321のレコードはMVCCにより、更新の度に新たな世代レコードを作成する方式になっていて、レコード参照時には資源を占有(排他)せず、たとえ更新処理と競合しても、参照処理は排他待ちすることなく処理できるようになっている。
キャッシュ管理部314は、データ参照時にレコード操作部313より要求されたデータをキャッシュデータ321から返却する。データがない場合には、ロケータ322を参照して担当ノードを特定した後、担当ノードから最新データを取得して返す。
キャッシュ管理部314は、キャッシュデータ321の肥大化を抑えるために、参照されなくなった古い世代レコードを定期的に削除して再利用可能にする。また、キャッシュ管理部314は、キャッシュ319の空き容量が不足した場合は、データベース323にデータを書き込み、キャッシュ319に空きを作る。
トランザクション管理部315は、トランザクションをマネジメントする。トランザクション管理部315は、トランザクションがコミットする時には、ログ管理部317にコミットログを書き出すように依頼する。トランザクション管理部315は、トランザクションがロールバックする時には、トランザクションで更新した結果を無効化させる。
トランザクション管理部315は、トランザクション開始時、またはデータ参照時に、トランザクション管理装置401に時刻(トランザクションID)とスナップショットの取得依頼を行う。
また、トランザクション管理部315は、トランザクション開始時に、トランザクション管理装置401が管理しているスナップショットへ、トランザクションIDを追加するようにトランザクション管理装置401に依頼する。
また、トランザクション管理部315は、トランザクション終了時に、スナップショットからトランザクションIDを削除するようにトランザクション管理装置401に依頼する。
キャッシュ最新化部316は、キャッシュデータ321の最新化を行う
キャッシュ最新化部316は、他ノードの担当するデータが更新されたかどうかを確認するために、他ノードを定期巡回する。
ログ管理部317は、トランザクションの更新情報をログ324に記録する。更新情報は、トランザクションのロールバック時に更新データを無効化する場合や、分散データベースシステム101がダウンした場合にデータベース323を最新状態にリカバリするために使用される。
通信部318は、他ノードとの通信インタフェースである。他ノードが担当するデータを更新する場合や、キャッシュ最新化部316によるキャッシュ定期巡回で、他ノードのデータが更新されたかを確認するために、通信部318を介してやりとりする。
キャッシュ319は、ノード301−1で用いるデータを格納する記憶手段である。キャッシュ319は、記憶部320より読み書きの速度が速いことが望ましい。キャッシュ319は、例えば、Random Access Memory(RAM)である。
キャッシュ319は、キャッシュデータ321およびロケータ322を格納している。尚、キャッシュデータは、図4のキャッシュデータ304−1に対応している。また、キャッシュ319は、後述するスナップショットや採番した時刻を格納する。
キャッシュデータ321は、データベース323の内容を含むデータである。キャッシュデータ321は、さらに他ノードが格納するデータベースの内容の少なくとも一部を含む。
ロケータ322は、各データをどのノードが担当しているかを示す情報である。すなわちデータと該データを有するデータベースを持つノードが対応付けられた情報である。
記憶部320は、ノード301−1で用いるデータを格納する記憶手段である。記憶部320は、例えば、磁気ディスク装置である。
記憶部320は、データベース323およびログ324を格納している。
図6は、キャッシュの構成図を示す図である。
ここでは、ノード301−1のキャッシュデータについて説明する。
キャッシュデータ321は、自ノード担当データ331と他ノード担当データ332からなる。
自ノード担当データ331は、自身が記憶部320に格納するデータ、すなわちノード301−1にとってはデータベース323と同じ内容のデータである。
データベース323は、複数のページから構成されるので、同様に自ノード担当データ331も複数のページから構成される。
自ノード担当データ331は、データベース323の更新と同期して更新されるため、常に最新のデータとなる。
他ノード担当データ332は、他のノードがそれぞれの記憶部に格納するデータベースの一部又は全てと同じ内容のデータである。
ただし、他ノード担当データ332は、他ノードのデータベースの更新とは非同期に更新される。そのため、他ノード担当データ332は、最新のデータではない場合がある。すなわち、ある時点において、他ノード担当データ332と他のノードに格納されているデータベースの内容が異なる場合がある。他ノード担当データ332も自ノード担当データ331と同様に複数のページから構成される。
例えば、ノード301−1の他ノード担当データ332は、データベース305−2
、305−3の一部または全てと同じ内容のデータである。
次にページの構成について説明する。
図7は、ページの詳細な構成を示す図である。
ページ333は、ページ制御部とレコード領域とを有する。
ページ制御部は、ページ番号、ページカウンタ、およびその他の制御情報を有する。
ページ番号は、ページを特定するための一意な値である。
ページカウンタは、ページが更新された回数を示し、ページが更新されるたびにインクリメントされる。
その他の制御情報は、レコード位置やサイズ、ページのサイズなどの情報である。
レコード領域は、レコードおよび未使用領域を備える。
レコードは、1件分のデータである。
未使用領域は、レコードが記述されていない領域である。
次にレコードの構成について説明する。
ノード301には、MVCCが実装されており、一つのレコードは複数の世代のレコードで構成されている。
図8は、レコードの構成を示す図である。
図8は、一つのレコードの構成を示している。
レコードは、項目として、世代インデックス、作成者TRANID、削除者TRANID、およびデータを有する。
世代インデックスは、レコードの世代を示す値である。
作成者TRANIDは、その世代のレコードを作成したトランザクションを示す値である。
削除者TRANIDは、その世代のレコードを削除したトランザクションを示す値である。
データは、レコードのデータである。
図8においては、3世代のレコードを示しており、世代1が一番古いレコードであり、世代3は最新のレコードである。
次にトランザクション管理装置401について説明する。
図9は、実施の形態に係るトランザクション管理装置の構成図である。
トランザクション管理装置401は、トランザクションID採番部402、スナップショット管理部403、および時刻採番部404を備える。
トランザクションID採番部402は、トランザクションが開始された順番でトランザクションIDを採番する。実施の形態においては、トランザクションIDを”TRANID_時刻”としている。時刻はトランザクションID採番部402が採番の要求を受信した時刻である。トランザクションIDを”TRANID_時刻”とすることにより、トランザクションIDを比較すれば、どちらが先に開始されたトランザクションであるか分かる。
スナップショット管理部403は、スナップショット405を管理する。
スナップショット405は、実行中のトランザクションの一覧を示す情報である。スナップショット405は、スナップショット管理部403またはトランザクション管理装置401が有する記憶部(不図示)に格納される。
実施の形態において、スナップショット405は分散データベースシステム101で実行中のトランザクションのトランザクションIDの一覧である。スナップショット管理部403は、トランザクションの開始時に開始するトランザクションのトランザクションIDをスナップショット405に追加、またトランザクションの終了時に終了したトランザクションのトランザクションIDをスナップショット405から削除する。
時刻採番部404は、ノード301からの要求に応じて時刻を採番し、採番した時刻をノード301に送信する。ノード301からの要求に応じて時刻を採番するので、採番した時刻は要求を受信した時刻となる。
実施の形態において、時刻採番部404は、採番した時刻をトランザクションID採番部402が割り当てるトランザクションIDと同じ形式のデータとする。すなわち、採番した時刻を”TRANID_時刻”としてノードに送信する。
採番した時刻とトランザクションIDを同じ形式とすることにより、これらを比較することにより、採番した時刻とトランザクションの開始のどちらが先か分かる。
次にキャッシュデータの最新化について説明する。
図10は、実施の形態に係るキャッシュデータの最新化を示す図である。
実施の形態のノードは、他ノードのデータベースの更新を定期的にチェックすることで、キャッシュデータが最新の状態であるかをチェックする。
図10では、ノード0のキャッシュの最新化を表している。
図10の白丸はページを示し、黒丸は担当ノードで更新されたページを示し、×はキャッシュ上で削除したページを示す。
ここでは、ノード0は、他ノード、すなわちノード1〜ノード3のデータベースの更新をチェックしている。
時刻t1におけるノード0の他ノード担当データ501は、ノード1〜ノード3が担当するページを4つずつ有している。
ノード0は、ノード1にページ番号を送付する。ノード1は、受信したページ番号に対応するページのページカウンタをノード0に送信する。
ノード0は、受信したページカウンタと他ノード担当データ501のページのページカウンタと比較し、異なっていれば、ページは更新されていると判断する。そして、ページカウンタが異なっていたページを削除する。図10においては、他ノード担当データ501のうちノード1の左から3番目のページが削除される。
ノード2およびノード3に対しても同様の処理を行い、他ノード担当データ501のうちノード2の左から1番目のページとノード3の左から2番目のページが削除される。時刻t2で、全ての他ノードのチェックが終了する。
それにより、時刻t2において、他ノード担当データは、他ノード担当データ502の様になる。
図11は、実施の形態に係るキャッシュデータ最新化処理のフローチャートである。
ここではノード301−1の処理について説明する。
ステップS901において、キャッシュ最新化部316は、トランザクション管理装置401に時刻の採番とスナップショット405を要求する。そして、キャッシュ最新化部316は、トランザクション管理装置401から採番した時刻とスナップショットを受信し、キャッシュ319の領域Cに格納する。上述したように、実施の形態において、採番した時刻の形式はトランザクションIDの形式と同一である。
ステップS902において、キャッシュ最新化部316は、複数の他ノードのうち未選択の他ノードを一つ選択し、選択した他ノードが担当する他ノード担当データのページ番号を送付する。
ステップS903において、キャッシュ最新化部316は、ページカウンタをページ番号を送付した他ノードから受信する。受信したページカウンタは最新のページカウンタである。
ステップS904において、キャッシュ最新化部316は、ページカウンタが更新されていたページを削除する。すなわち、キャッシュ最新化部316は、他ノード担当データの各ページのページカウンタと受信したページカウンタを比較して、異なっていた場合、ページカウンタが異っていたページを削除する。
ステップS905において、キャッシュ最新化部316は、全他ノードを処理したか。すなわち、全他ノードに対してページ番号を送付したか判定する。全他ノードを処理した場合、制御はステップS906へ進み、全他ノードを処理していない場合、制御はステップS902へ戻る。
ステップS906において、キャッシュ最新化部316は、キャッシュ319の領域Cの内容、すなわち採番した時刻およびスナップショット405をキャッシュ319の領域Bへコピーする。
図12は、実施の形態に係るデータの整合性を説明する図である。
図12において横軸は時間を示しており、各トランザクションT1〜T5の実行時間を示している。
ここで、時刻t1<t2≦t3<t4である。
また、トランザクションT1、T3は、時刻t1より前にコミットされている。トランザクションT2、T4は、時刻t1より前に開始している。
ノードは、他ノードの巡回を行い、データが更新されているかチェックしている。図12では、時刻t1からt2間と時刻t2からt4間で1回分の巡回を行っている。
時刻t1では、トランザクションT1、T3でコミットされたデータ、およびトランザクションT2、T4開始時のデータがキャッシュデータに反映されている(すなわち、キャッシュデータと同じ)であるかは、確認できない。
時刻t2では、他ノードのキャッシュを1巡回したため、時刻t3で参照するデータにトランザクションT1、T3でコミットされたデータ、およびトランザクションT2、T4開始時のデータがキャッシュデータに反映されているか判断可能となる。上述のように、キャッシュの最新化処理で、他ノードで更新されたページは、キャッシュデータから削除される。
キャッシュデータに反映されていないデータ、すなわちキャッシュデータから削除されているデータを参照する場合は、ノードは時刻t3で担当ノードからデータを取得してキャッシュデータに格納する。取得するデータは、参照するデータが含まれるページである。ノードはページの取得後、時刻t1以降にコミットされた世代のデータは削除し、時刻t1までに更新された各世代のデータをキャッシュデータに反映する。
時刻t3でデータを参照する場合は、時刻t1のスナップショット、またはレコードの参照要求の受信時に取得したスナップショットを使用する。スナップショットには、トランザクションT2、T4のトランザクションIDが含まれている。
次に、参照レコードの特定に用いるスナップショットの選択処理について説明する。
図13は、実施の形態に係るスナップショット選択処理のフローチャートである。
ここではノード301−1の処理について説明する。
先ず、ノード301−1は、レコードの参照要求を受信すると、該レコードが自ノード担当データ331にあるか判定し、ある場合は、該レコードを読み出して応答する。自ノード担当データ331にあるか否かはロケータ322を用いて判断する。また、参照要求されたレコードが自ノード担当データ331にない、すなわち他ノードが担当するデータである場合、該レコードが他ノード担当データ332にあるか判定し、他ノード担当データ332にない場合は、該レコードを担当する他ノードから該レコードを含むページを取得し、図12で説明したようにキャッシュデータ321に反映する。
ステップS911において、トランザクション管理部315は、トランザクション管理装置401に時刻の採番とスナップショット405を要求する。そして、トランザクション管理部315は、トランザクション管理装置401から採番した時刻とスナップショットを受信し、キャッシュ319の領域Aに格納する。
ステップS912において、レコード操作部313は、領域Aの採番した時刻と領域Bの採番した時刻を比較する。
ステップS913において、領域Aの採番した時刻の方が新しい場合、制御はステップS914に進み、領域Aの採番した時刻の方が新しくない場合、制御はステップS915へ進む。
ステップS914において、レコード操作部313は、領域Bのスナップショットを選択する。
ステップS915において、レコード操作部313は、領域Aのスナップショットを選択する。
ステップS916において、レコード操作部313は、選択したスナップショットを使用して、複数の世代を有するレコードのうち参照する世代のレコード(有効レコード)を特定する。そして、特定したレコードを参照し、該レコードの値を要求元に送信する。
次に参照レコードの特定処理について説明する。
上述のように、実施の形態のノードはMVCCを実装しており、レコードはレコード毎にそのレコードを作成したトランザクション、削除したトランザクションを識別する値を格納している。そして、ノードは、ある世代のレコードがあるトランザクションにとって有効な世代か無効な世代かを判定する。このような判定をSatisfy処理と呼ぶ。
Satisfy処理では、下記のルールに合致するレコードが有効な世代のレコードであると判定する。
レコードの作成者TRANIDが、
自トランIDを除くスナップショット中のトランザクションID(TRANID)でない、且つ、
スナップショット取得時以降に開始されたTRANIDでない、
且つ
レコードの削除者TRANIDが、
未設定、または、
自トランIDを除くスナップショット中に含まれるTRANIDである、または、
スナップショット取得時以降に開始されたTRANIDである。
ここで、自トランIDは、レコードを参照しようとするトランザクションのトランザクションIDである。
図14は、実施の形態に係る参照レコードの特定処理のフローチャートである。
図14は、ステップS916の参照する世代のレコードの特定する処理の詳細を示す。
ステップS921において、レコード操作部313は、全世代のレコードを判定したか判定する。全世代のレコードを判定した場合、処理を終了し、全世代のレコードを判定していない場合、未判定の世代のレコードの内、最古の世代のレコードを選択し、制御はステップS922へ進む。以下、選択した世代のレコードに対して有効な世代であるか無効な世代であるか判定する。
ステップS922において、レコード操作部313は、レコードの作成者TRANIDが自トランID、またはスナップショット中のTRANIDでないか判定する。レコードの作成者TRANIDが自トランID、またはスナップショット中のTRANIDでない場合、制御はステップS922へ進み、自トランID、またはスナップショット中のTRANIDである場合、制御はステップS921へ戻る。
ステップS923において、レコード操作部313は、レコードの作成者TRANIDがスナップショット取得時以降に開始されたTRANIDでないか判定する。レコードの作成者TRANIDがスナップショット取得時以降に開始されたTRANIDでない場合、制御はステップS924へ進み、スナップショット取得時以降に開始されたTRANIDである場合、制御はステップS921へ戻る。実施の形態において、スナップショット取得時以降に開始されたTRANIDでないかの判定は、該スナップショット取得時に採番した時刻を用いて判定する。
ステップS924において、レコード操作部313は、レコードの削除者TRANIDが未設定であるか判定する。レコードの削除者TRANIDが未設定である場合、制御はステップS927へ進み、未設定で無い場合、制御はステップS925へ進む。
ステップS925において、レコード操作部313は、レコードの削除者TRANIDが自トランIDでない、かつスナップショット中に含まれるTRANIDであるであるか判定する。レコードの削除者TRANIDが自トランIDでない、かつスナップショット中に含まれるTRANIDである場合、制御はステップS927へ進み、自トランIDである、またはスナップショット中に含まれるTRANIDでない場合、制御はステップS926へ進む。
ステップS926において、レコード操作部313は、レコードの削除者TRANIDがスナップショット取得時以降に開始されたTRANIDであるか判定する。レコードの削除者TRANIDがスナップショット取得時以降に開始されたTRANIDである場合、制御はステップS927へ進み、スナップショット取得時以降に開始されたTRANIDで無い場合、制御はステップS921へ戻る。実施の形態において、スナップショット取得時以降に開始されたTRANIDであるかの判定は、該スナップショット取得時に採番した時刻を用いて判定する。
ステップS927において、レコード操作部313は、選択した世代のレコードを有効レコードとして設定する。尚、以前に設定された有効レコードは、新たに有効レコードが設定されると無効となる。
図15は、Satisfy処理の例を示す図である。
図15は、レコード801に対してSatisfy処理を行った場合を示している。
ここでは、スナップショットは“25,50,75”であり、自TRANIDは50であり、スナップショット取得時において次に開始するトランザクションに割り当てられるTRANIDは100である。
上述のルールに基づいて、レコード801の各世代について有効な世代か無効な世代かすると、世代インデックスが1、3、5、6、8、10のレコードは有効(Visible)と判定され、世代インデックスが2、4、7、9、11のレコードは無効(Invisible)と判定される。
ここで、有効なレコードの内で世代インデックが一番大きいレコード、すなわち有効なレコードの内で一番新しいレコードが最終的に有効なレコードとなる。すなわち、図15では、世代インデックスが10のレコードが有効なレコード、すなわちノードが参照するレコードとなる。
実施の形態の分散データベースシステムによれば、マルチサイト更新が行われ、キャッシュデータの最新化を非同期に行われる分散データベースシステムにおいて、整合性のあるデータの参照が可能となる。
図16は、情報処理装置(コンピュータ)の構成図である。
実施の形態のノード301は、例えば、図16に示すような情報処理装置1によって実現される。
情報処理装置1は、CPU2、メモリ3、入力部4、出力部5、記憶部6、記録媒体駆動部7、およびネットワーク接続部8を備え、それらはバス9により互いに接続されている。
CPU2は、情報処理装置1全体を制御する中央処理装置である。CPU2は、受付部311、データ操作部312、レコード操作部313、キャッシュ管理部314、トランザクション管理部315、キャッシュ最新化部316、ログ管理部317に対応する。
メモリ3は、プログラム実行の際に、記憶部6(あるいは可搬記録媒体10)に記憶されているプログラムあるいはデータを一時的に格納するRead Only Memory(ROM)やRandom Access Memory(RAM)等のメモリである。メモリ3は、キャッシュ319に対応する。CPU2は、メモリ3を利用してプログラムを実行することにより、上述した各種処理を実行する。
この場合、可搬記録媒体10等から読み出されたプログラムコード自体が実施の形態の機能を実現する。
入力部4は、例えば、キーボード、マウス、タッチパネル等である。
出力部5は、例えば、ディスプレイ、プリンタ等である。
記憶部6は、例えば、磁気ディスク装置、光ディスク装置、テープ装置等である。情報処理装置1は、記憶部6に、上述のプログラムとデータを保存しておき、必要に応じて、それらをメモリ3に読み出して使用する。
記憶部6は、記憶部320に対応する。
記録媒体駆動部7は、可搬記録媒体10を駆動し、その記録内容にアクセスする。可搬記録媒体としては、メモリカード、フレキシブルディスク、Compact Disk Read Only Memory(CD-ROM)、光ディスク、光磁気ディスク等、任意のコンピュータ読み取り可能な記録媒体が用いられる。ユーザは、この可搬記録媒体10に上述のプログラムとデータを格納しておき、必要に応じて、それらをメモリ3に読み出して使用する。
ネットワーク接続部8は、LAN等の任意の通信ネットワークに接続され、通信に伴うデータ変換を行う。ネットワーク接続部は、通信部318に対応する。
101 分散データベースシステム
201 ロードバランサ
301 ノード
311 受付部
312 データ操作部
313 レコード操作部
314 キャッシュ管理
315 トランザクション管理部
316 キャッシュ最新化部
317 ログ管理部
318 通信部
319 キャッシ
320 記憶部
321 キャッシュデータ
322 ロケータ
323 データベース
324 ログ
331 自ノード担当データ
332 他ノード担当データ
333 ページ
401 トランザクション管理装置
402 トランザクションID採番部
403 スナップショット管理部
404 時刻採番部
405 スナップショット
501 クライアント端末
1005 ノード
1006 キャッシュ
1007 ノード
1008 キャッシュ
1015 ノード
1016 キャッシュ
1017 ノード
1018 キャッシュ

Claims (7)

  1. コンピュータに、
    他のコンピュータに格納されたデータについて更新がなされてから所定時間内に、更新後のデータを格納することにより、更新前後のデータが格納部に格納された状態とし、
    第1の時刻から前記所定時間経過した第2の時刻からさらに前記所定時間経過するまでに前記データについての参照要求を受け付け、且つ前記第1の時刻に前記他のコンピュータに前記更新を行なうトランザクションが存在していた場合に、前記格納部に格納された更新前のデータを前記参照要求の要求元に送信する、
    処理を実行させることを特徴とするデータ管理プログラム。
  2. 前記コンピュータに、
    前記参照要求を受け付け、且つ前記第1の時刻に前記更新を行なうトランザクションがない場合に、前記格納部に格納された更新後のデータを前記参照要求の要求元に送信する、
    処理を実行させることを特徴とする請求項1記載のデータ管理プログラム。
  3. 他ノードに格納されているデータの少なくとも一部を含むデータと、分散データベースシステムにおいて、実行されている1または複数のトランザクションを特定する第1のトランザクション情報と、前記第1のトランザクション情報に示されるトランザクションに対応する要求をトランザクションを管理する管理装置が受信した時刻を示す第1の時刻と、を格納する記憶部と、
    前記記憶部に記憶されたデータのうちの複数世代を有するデータの参照要求を受信したときに、第2のトランザクション情報と前記第2のトランザクション情報に示されるトランザクションに対応する要求を前記管理装置が受信した時刻を示す第2の時刻を受信して前記記憶部に格納し、前記第1の時刻と前記第2の時刻と比較結果に基づいて、前記第1のトランザクション情報または前記第2のトランザクション情報のいずれかを用いて、前記複数世代を有するデータのうち参照する世代のデータを特定する処理部と、
    を備え、
    前記記憶部に記憶されたデータに対応する前記他ノードで格納されているデータが更新されているか否か判定する処理を行い、更新されている場合、前記記憶部に記憶されたデータを削除し、
    のトランザクション情報および前記第のトランザクション情報に示されるトランザクションに対応する要求を前記管理装置が受信した時刻を示す第の時刻を、前記判定する処理の前に受信し、前記判定する処理の終了後に前記第のトランザクション情報および第の時刻を前記第1のトランザクション情報および前記第1の時刻として前記記憶部に格納することを特徴とするノード。
  4. 前記ノードは、前記第1のトランザクション情報および前記第1の時刻を定期的に前記管理装置から受信することを特徴とする請求項3記載のノード。
  5. 分散データベースシステムにおいて、実行されている1または複数のトランザクションを特定するトランザクション情報を管理するトランザクション情報管理部と、
    ノードからの要求に応じて、該要求を受信した時刻を前記ノードに送信する時刻採番部と、
    を備える管理装置と、
    複数のノードと、
    を備える分散データベースシステムにおいて、
    前記複数のノードの各ノードは、
    他ノードに格納されているデータの少なくとも一部を含むデータと、前記分散データベースシステムにおいて、実行されている1または複数のトランザクションを特定する第1のトランザクション情報と、前記第1のトランザクション情報に示されるトランザクションに対応する要求をトランザクションを管理する前記管理装置が受信した時刻を示す第1の時刻と、を格納する記憶部と、
    前記記憶部に記憶されたデータのうちの複数世代を有するデータの参照要求を受信したときに、第2のトランザクション情報と前記第2のトランザクション情報に示されるトランザクションに対応する要求を前記管理装置が受信した時刻を示す第2の時刻を受信して前記記憶部に格納し、前記第1の時刻と前記第2の時刻と比較結果に基づいて、前記第1のトランザクション情報または前記第2のトランザクション情報のいずれかを用いて、前記複数世代を有するデータのうち参照する世代のデータを特定する処理部と、を備え
    前記記憶部に記憶されたデータに対応する前記他ノードで格納されているデータが更新されているか否か判定する処理を行い、更新されている場合、前記記憶部に記憶されたデータを削除し、
    第3のトランザクション情報および前記第3のトランザクション情報に示されるトランザクションに対応する要求を前記管理装置が受信した時刻を示す第3の時刻を、前記判定する処理の前に受信し、前記判定する処理の終了後に前記第3のトランザクション情報および第3の時刻を前記第1のトランザクション情報および前記第1の時刻として前記記憶部に格納することを特徴とする分散データベースシステム。
  6. 他のコンピュータに格納されたデータについて更新がなされてから所定時間内に、更新後のデータを格納することにより、更新前後のデータが格納部に格納された状態とし、
    第1の時刻から前記所定時間経過した第2の時刻からさらに前記所定時間経過するまでに前記データについての参照要求を受け付け、且つ前記第1の時刻に前記他のコンピュータに前記更新を行なうトランザクションが存在していた場合に、前記格納部に格納された更新前のデータを前記参照要求の要求元に送信する、
    処理を含むコンピュータが実行するデータ管理方法。
  7. 格納部と、
    他のコンピュータに格納されたデータについて更新がなされてから所定時間内に、更新後のデータを格納することにより、更新前後のデータが前記格納部に格納された状態とし、第1の時刻から前記所定時間経過した第2の時刻からさらに前記所定時間経過するまでに前記データについての参照要求を受け付け、且つ前記第1の時刻に前記他のコンピュータに前記更新を行なうトランザクションが存在していた場合に、前記格納部に格納された更新前のデータを前記参照要求の要求元に送信する処理部と、
    を備えるコンピュータ。
JP2011215290A 2011-09-29 2011-09-29 データ管理プログラム、ノード、および分散データベースシステム Active JP5772458B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2011215290A JP5772458B2 (ja) 2011-09-29 2011-09-29 データ管理プログラム、ノード、および分散データベースシステム
US13/614,632 US20130085988A1 (en) 2011-09-29 2012-09-13 Recording medium, node, and distributed database system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011215290A JP5772458B2 (ja) 2011-09-29 2011-09-29 データ管理プログラム、ノード、および分散データベースシステム

Publications (2)

Publication Number Publication Date
JP2013077063A JP2013077063A (ja) 2013-04-25
JP5772458B2 true JP5772458B2 (ja) 2015-09-02

Family

ID=47993568

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011215290A Active JP5772458B2 (ja) 2011-09-29 2011-09-29 データ管理プログラム、ノード、および分散データベースシステム

Country Status (2)

Country Link
US (1) US20130085988A1 (ja)
JP (1) JP5772458B2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9519902B2 (en) * 2013-06-25 2016-12-13 Quisk, Inc. Fraud monitoring system with distributed cache
US9760596B2 (en) * 2013-05-13 2017-09-12 Amazon Technologies, Inc. Transaction ordering
US9690671B2 (en) 2013-11-01 2017-06-27 Cloudera, Inc. Manifest-based snapshots in distributed computing environments
AU2016292783B2 (en) * 2015-07-10 2019-05-30 Ab Initio Technology Llc Method and architecture for providing database access control in a network with a distributed database system
KR102590347B1 (ko) * 2016-12-15 2023-10-18 삼성전자주식회사 서버, 전자 장치 및 데이터 관리 방법
US10896165B2 (en) * 2017-05-03 2021-01-19 International Business Machines Corporation Management of snapshot in blockchain
US11210272B2 (en) * 2019-03-29 2021-12-28 Electronic Arts Inc. Low latency cache synchronization in distributed databases
CN115311092B (zh) * 2022-08-22 2023-06-27 中国国际金融股份有限公司 用于资源处理系统的方法、装置,资源处理系统以及计算机可读存储介质

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5495601A (en) * 1992-12-11 1996-02-27 International Business Machines Corporation Method to off-load host-based DBMS predicate evaluation to a disk controller
US6237001B1 (en) * 1997-04-23 2001-05-22 Oracle Corporation Managing access to data in a distributed database environment
US5956731A (en) * 1997-04-23 1999-09-21 Oracle Corporation Sharing snapshots for consistent reads
JP3367385B2 (ja) * 1997-06-27 2003-01-14 日本電気株式会社 分散トランザクション整合方法及びプログラムを記録した機械読み取り可能な記録媒体
US6012059A (en) * 1997-08-21 2000-01-04 Dataxel Corporation Method and apparatus for replicated transaction consistency
US6353836B1 (en) * 1998-02-13 2002-03-05 Oracle Corporation Method and apparatus for transferring data from the cache of one node to the cache of another node
JP3785004B2 (ja) * 1999-09-30 2006-06-14 株式会社東芝 トランザクション管理方法及びトランザクション管理装置
US6625602B1 (en) * 2000-04-28 2003-09-23 Microsoft Corporation Method and system for hierarchical transactions and compensation
US8650169B1 (en) * 2000-09-29 2014-02-11 Oracle International Corporation Method and mechanism for identifying transaction on a row of data
US6671686B2 (en) * 2000-11-02 2003-12-30 Guy Pardon Decentralized, distributed internet data management
US6996674B2 (en) * 2001-05-07 2006-02-07 International Business Machines Corporation Method and apparatus for a global cache directory in a storage cluster
US7392321B1 (en) * 2001-05-30 2008-06-24 Keynote Systems, Inc. Method and system for evaluating quality of service for transactions over a network
US7334004B2 (en) * 2001-06-01 2008-02-19 Oracle International Corporation Consistent read in a distributed database environment
US7020684B2 (en) * 2002-01-18 2006-03-28 Bea Systems, Inc. System and method for optimistic caching
US6957236B1 (en) * 2002-05-10 2005-10-18 Oracle International Corporation Providing a useable version of a data item
US20030220935A1 (en) * 2002-05-21 2003-11-27 Vivian Stephen J. Method of logical database snapshot for log-based replication
US7072912B1 (en) * 2002-11-12 2006-07-04 Microsoft Corporation Identifying a common point in time across multiple logs
US7020746B2 (en) * 2003-01-28 2006-03-28 Microsoft Corporation Method and system for an atomically updated, central cache memory
US7233947B2 (en) * 2003-05-22 2007-06-19 Microsoft Corporation Timestamping in databases
US7243088B2 (en) * 2003-08-06 2007-07-10 Oracle International Corporation Database management system with efficient version control
US8762331B2 (en) * 2004-06-29 2014-06-24 Microsoft Corporation Concurrent transactions and page synchronization
US7454581B2 (en) * 2004-10-27 2008-11-18 International Business Machines Corporation Read-copy update grace period detection without atomic instructions that gracefully handles large numbers of processors
JP2006235736A (ja) * 2005-02-22 2006-09-07 Ricoh Co Ltd クラスタシステムのキャッシュ同期制御方法
US7177994B2 (en) * 2005-03-04 2007-02-13 Emc Corporation Checkpoint and consistency markers
US9141930B2 (en) * 2005-06-16 2015-09-22 Sap Se Method and apparatus for making changes to a quantity for a time interval within a time series
CA2657657A1 (en) * 2005-12-02 2007-06-07 International Business Machines Corporation System for improving access efficiency in database and method thereof
US7421542B2 (en) * 2006-01-31 2008-09-02 Cisco Technology, Inc. Technique for data cache synchronization
US7502792B2 (en) * 2006-04-26 2009-03-10 Microsoft Corporation Managing database snapshot storage
WO2007134250A2 (en) * 2006-05-12 2007-11-22 Goldengate Software, Inc. Method for forming homogeneous from heterogeneous data
US9483525B2 (en) * 2007-04-30 2016-11-01 Microsoft Technology Licensing, Llc Reducing update conflicts when maintaining views
US7644238B2 (en) * 2007-06-01 2010-01-05 Microsoft Corporation Timestamp based transactional memory
US7930274B2 (en) * 2007-09-12 2011-04-19 Sap Ag Dual access to concurrent data in a database management system
US7761434B2 (en) * 2007-11-19 2010-07-20 Red Hat, Inc. Multiversion concurrency control in in-memory tree-based data structures
US8229945B2 (en) * 2008-03-20 2012-07-24 Schooner Information Technology, Inc. Scalable database management software on a cluster of nodes using a shared-distributed flash memory
US8732386B2 (en) * 2008-03-20 2014-05-20 Sandisk Enterprise IP LLC. Sharing data fabric for coherent-distributed caching of multi-node shared-distributed flash memory
US8700574B2 (en) * 2008-03-21 2014-04-15 Omnitracs, Llc Pourover journaling
US8131698B2 (en) * 2008-05-28 2012-03-06 International Business Machines Corporation Method for coordinating updates to database and in-memory cache
US8190820B2 (en) * 2008-06-13 2012-05-29 Intel Corporation Optimizing concurrent accesses in a directory-based coherency protocol
US7996360B2 (en) * 2008-06-27 2011-08-09 International Business Machines Corporation Coordinating updates to replicated data
US8275815B2 (en) * 2008-08-25 2012-09-25 International Business Machines Corporation Transactional processing for clustered file systems
US8195893B2 (en) * 2008-11-03 2012-06-05 International Business Machines Corporation Eliminating synchronous grace period detection for non-preemptible read-copy update on uniprocessor systems
US8868510B2 (en) * 2009-12-03 2014-10-21 Sybase, Inc. Managing data storage as an in-memory database in a database management system
US8396831B2 (en) * 2009-12-18 2013-03-12 Microsoft Corporation Optimistic serializable snapshot isolation
US8356007B2 (en) * 2010-10-20 2013-01-15 Microsoft Corporation Distributed transaction management for database systems with multiversioning
US8335771B1 (en) * 2010-09-29 2012-12-18 Emc Corporation Storage array snapshots for logged access replication in a continuous data protection system
US20120136839A1 (en) * 2010-11-30 2012-05-31 Peter Eberlein User-Driven Conflict Resolution Of Concurrent Updates In Snapshot Isolation
US9075858B2 (en) * 2010-12-16 2015-07-07 Sybase, Inc. Non-disruptive data movement and node rebalancing in extreme OLTP environments
US9063969B2 (en) * 2010-12-28 2015-06-23 Sap Se Distributed transaction management using optimization of local transactions
US8442962B2 (en) * 2010-12-28 2013-05-14 Sap Ag Distributed transaction management using two-phase commit optimization

Also Published As

Publication number Publication date
JP2013077063A (ja) 2013-04-25
US20130085988A1 (en) 2013-04-04

Similar Documents

Publication Publication Date Title
JP5772458B2 (ja) データ管理プログラム、ノード、および分散データベースシステム
US11003689B2 (en) Distributed database transaction protocol
US20180203888A1 (en) Multi-Version Concurrency Control Method in Database and Database System
CN107077495B (zh) 数据库管理系统中的高性能事务
US8375007B2 (en) Status tool to expose metadata read and write queues
CN105630863B (zh) 用于多版本并发提交状态的事务控制块
US8473950B2 (en) Parallel nested transactions
JP5652228B2 (ja) データベースサーバ装置、データベース更新方法及びデータベース更新プログラム
US9037557B2 (en) Optimistic, version number based concurrency control for index structures with atomic, non-versioned pointer updates
JP5343399B2 (ja) 管理プログラム、管理方法、及び管理装置
US20120203745A1 (en) System and method for range search over distributive storage systems
EP3493071B1 (en) Multi-version concurrency control (mvcc) in non-volatile memory
CN106575297A (zh) 使用盲更新操作的高吞吐量数据修改
US9652492B2 (en) Out-of-order execution of strictly-ordered transactional workloads
CN102955792A (zh) 一种实时全文搜索引擎事务处理的实现方法
CN106354732B (zh) 一种支持并发协同的离线数据版本冲突解决方法
CN105574026B (zh) 非关系型数据库支持事务的方法及装置
US9390131B1 (en) Executing queries subject to different consistency requirements
US9043371B1 (en) Storing information in a trusted environment for use in processing data triggers in an untrusted environment
JP4126843B2 (ja) データ管理方法および装置並びにデータ管理プログラムを格納した記録媒体
WO2013132628A1 (ja) データベースの管理方法
US9424261B2 (en) Techniques to take clean database file snapshot in an online database
JP6239697B2 (ja) データベースの管理方法
CN114791913B (zh) 数据库的共享内存缓冲池处理方法、存储介质与设备
CN118606009A (zh) 一种事务的并发控制方法、装置、设备及介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20140603

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150123

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150406

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: 20150602

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150615

R150 Certificate of patent or registration of utility model

Ref document number: 5772458

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150