以下、実施の形態について図面を参照して説明する。
図1は、本実施形態に係る分散データベースの一構成例を示す図である。
図1に示すように、本分散データベースは、複数のノード(データベース)10と、これら複数のノード10から共有される共有ストレージ装置20とが、ネットワークで接続される構成を持つ。各ノード10は、データの読込み要求や、データの書込み要求を受付け、共有ストレージ装置20からのデータの読込みや、共有ストレージ装置20へのデータの書込みを実行する。なお、ここでは、各ノード10が共有ストレージ装置20にアクセスする際のデータ領域単位をレコード単位と想定し、以下、例えば、共有ストレージ装置20へのデータの書込みや共有ストレージ装置20からのデータの読込み等を、共有ストレージ装置20へのレコードの書込みや共有ストレージ装置20からのレコードの読込み等と称する。
各ノード10は、共有ストレージ装置20のレコード用のキャッシュ領域(キャッシュ111)が確保されるメモリ110を備え、このメモリ110を用いて、レコードの読込み要求およびレコードの書込み要求に対する応答時間の短縮を図っている。例えば、レコードの読込みが要求された際、読込み対象のレコードがメモリ110に格納されていた場合には、そのレコードをメモリ110から取得することで、共有ストレージ装置20に対するアクセスを不要とし、レコードの読込み要求に対する応答時間を短縮する。レコードの書込み要求に対する応答時間の短縮は、メモリ110を用いて、いわゆるライトバック方式の書込みを行うことで、共有ストレージ装置20に対するアクセスを不要とする。複数のノード10間でのレコードの整合性保持については後述する。
また、各ノード10のメモリ110には、共有ストレージ装置20のレコードの整合性を保つべくキャッシュ111を管理するためのキャッシュ管理情報用のデータ領域112も確保される。例えば、レコードの読込みが要求された際、読込み対象のレコードがメモリ110に格納されていた場合、各ノード10は、キャッシュ管理情報に基づき、このメモリ110上のレコードを読込み対象のレコードとして取得可能か否かを判断する。読込み対象のレコードとして取得できない場合とは、典型的には、レコードをメモリ110に格納した後、他のノード10により当該レコードが書換えられた場合である。
図2は、複数のノード10が共有ストレージ装置20にアクセス可能な分散データベースにおける共有ストレージ装置20のレコードの整合性を保つためのロックによるアクセス制限を説明するための図である。図2中、(A)は、従来の分散データベースのロックによるアクセス制限を示し、(B)は、本実施形態の分散データベースのロックによるアクセス制限を示している。
従来の分散データベースでは、図2(A)に示されるように、あるノード10が共有ストレージ装置20へレコードを書込む場合、そのノード10は、書込み対象のレコードについて、他のノード10によるレコードの読込みおよびレコードの書込みを禁止する排他ロックを取得する。このロックによるアクセス制限は、排他制御と称される。この排他ロックがいずれかのノード10で取得されている場合、他のノード10は、この排他ロックが解放されるまで、そのレコードの書込みを実行することはできない。
なお、レコードの読込み時においては、読込み対象のレコードについて、他のノード10によるレコードの読込みとレコードの書込みとのうちのレコードの書込みのみを禁止する共有ロックが取得される。この共有ロックがいずれかのノード10で取得されている場合であっても、他のノード10は、そのレコードの読込みを実行することができる(共有ロックを取得することができる)。
これに対して、本実施形態の分散データベースでは、図2(B)に示されるように、書込用共有ロックを新設し、レコードの書込みを行うノード10は、この書込用共有ロックを取得する。書込用共有ロックは、他のノードによるレコードの読込みとレコードの書込みとのうちのレコードの読込みのみを禁止するものである。この書込用共有ロックがいずれかのノード10で取得されている場合であっても、他のノード10は、そのレコードの書込みを実行することができる(書込用共有ロックを取得することができる)。
図3は、書込用共有ロックを新設する本分散データベースで達成される応答性能の向上について説明するための図である。
図3中、(A)は、従来の分散データベースにおいて共有ストレージ装置20内の同一レコードについて複数のノード10がほぼ同時に書込みを行おうとした場合の処理の流れを示し、(B)は、本実施形態の分散データベースにおいて共有ストレージ装置20内の同一レコードについて複数のノード10がほぼ同時に書込みを行おうとした場合の処理の流れを示している。
前述したように、従来の分散データベースでは、レコードの書込み時、そのレコードについて、他のノード10によるレコードの読込みおよびレコードの書込みを禁止する排他ロックが取得される。従って、このレコードの書込みを行おうとしている他のノード10は、この排他ロックが解放されるまで待機することが強いられる。排他ロックは、一時に1台のノード10のみが取得可能であるので、共有ストレージ装置20内の同一レコードについて複数のノード10がほぼ同時に書込みを行おうとした場合、図3(A)に示されるように、排他ロックを取得できた順に、複数のノード10が1台ずつレコードの書込みを行うこととなる。よって、当該複数のノード10の台数分の書込み時間を要することとなる。
一方、本実施形態の分散データベースでは、レコードの書込み時、そのレコードについて、他のノード10によるレコードの読込みとレコードの書込みとのうちのレコードの読込みのみを禁止する書込用共有ロックが取得される。書込用共有ロックは、一時に複数のノード10が取得可能であるので、共有ストレージ装置20内の同一レコードについて複数のノード10がほぼ同時に書込みを行おうとした場合、図3(B)に示されるように、複数のノード10がレコードの書込みを並行して実行できる。よって、ほぼ1回分の書込み時間で済むこととなる。
この点を踏まえて、以下、共有ストレージ装置20内の同一レコードについて複数のノード10が書込みを並行して実行できるようにする本実施形態の分散データベースの基本原理について詳述する。
再び、図1を参照する。
図1に示すように、複数のノード10それぞれは、レコード読込機能部11、レコード書込機能部12、レコード合併機能部13およびレコード反映機能部14を有する。これら各機能部は、例えば、記憶媒体に格納され、プロセッサによって実行されるソフトウェア(プログラム)により実現可能である。
前述したように、各ノード10は、メモリ110、より具体的には、キャッシュ111を用いて、レコードの読込み要求およびレコードの書込み要求に対する応答時間の短縮を図っている。また、各ノード10は、共有ストレージ装置20のレコードの整合性を保つべくキャッシュ111を管理するために、メモリ110上でキャッシュ管理情報を管理する。キャッシュ管理情報には、バージョン番号およびロック情報が含まれる。
本分散データベースは、共有ストレージ装置20に対して実行されるレコードの書込みの順序を示すバージョン番号を管理する。バージョン番号は、いずれかのノード10が共有ストレージ装置20へのレコードの書込みを実行する毎にインクリメントされる。図4に、このバージョン番号の一インクリメント例を示す。
図4は、(a)ノードAによるレコード1に対する書込み、(b)ノードBによるレコード1に対する書込み、(c)ノードAによるレコード2に対する書込み、の順に、共有ストレージ装置20へのレコードの書込みが実行されたことに伴い、バージョン番号がインクリメントされるケースを示している。図4に示すように、バージョン番号は、(ノード単位やレコード単位ではなく)分散データベース全体で一意の値となるようにインクリメントされる。
各ノード10は、このバージョン番号を、キャッシュ111に格納されるすべてのレコード分、メモリ110上で管理する。ロック情報は、読込用共有ロック、書込用共有ロックおよび排他ロックのレコード単位の取得状況を示す情報である。
一方、共有ストレージ装置20は、排他制御機能部21およびバージョン加算機能部22を有する。これら各機能部も、例えば、記憶媒体に格納され、プロセッサによって実行されるソフトウェア(プログラム)により実現可能である。
また、共有ストレージ装置20は、共有記憶領域210を備えている。共有ストレージ装置20は、この共有記憶領域210内において、レコード211および最新バージョン番号212を管理する。各レコード211は、バージョン番号、ノード番号、ロック情報および合併フラグを含む管理情報211Aを持つ。バージョン番号は、そのレコード211の書込み時におけるバージョン番号である。ノード番号は、そのレコード211の書込みを行ったノード10の識別番号である。ロック情報は、そのレコードに関する読込用共有ロック、書込用共有ロックおよび排他ロックの取得状況を示す情報である。合併フラグについては後述する。
まず、図5を参照しながら、本分散データベースにおけるノード10による共有ストレージ装置20へのレコード211の書込み手順について説明する。
ノード10のレコード書込機能部12は、共有ストレージ装置20へのレコード211の書込みを実行するモジュールである。レコード書込機能部12は、レコード211の書込み要求を受けると(図5の(1))、まず、そのレコード211に関する書込用共有ロックを取得する(図5の(2))。共有ストレージ装置20の排他制御機能部21は、読込用共有ロック、書込用共有ロックおよび排他ロックの設定および解除を制御するモジュールである。
次に、レコード書込機能部12は、共有ストレージ装置20側で管理される最新バージョン番号212を加算し(図5の(3))、加算された最新バージョン番号212を取得する(図5の(4))。共有ストレージ装置20のバージョン加算機能部22は、最新バージョン番号212のインクリメントを司るモジュールである。
続いて、レコード書込機能部12は、書込み対象のレコード211をキャッシュ111に格納すると共に、取得した最新バージョン番号212をキャッシュ管理情報としてメモリ110に格納する(図5の(5))。
図6に、本分散データベースで実行されるレコード211の書込みの2つのパターンを示す。
図6中、(A)は、第1パターンの書込みの一例を示している。図6(A)は、「apple」という値を持つレコードが、「banana」→「orange」と書換えられるケースを示している。このように、新しい内容に置換えるレコードの書込みを、ここでは、上書型と称する。
レコード211の書込みが上書型の場合、レコード書込機能部12は、キャッシュ111に格納したレコード211に関する管理情報211Aとして、メモリ110に格納したバージョン番号と、自ノード10のノード番号と、合併フラグ値「1」を共有ストレージ装置20に格納する(図5の(6))。
また、図6(B)は、第2パターンの書込みの一例を示している。図6(B)は、「10」という値を持つレコードの値が、「10加算」→「10加算」→「10加算」→「5乗算」と種々の処理が施されて更新されるケースを示している。このように、書込み前の内容を加工するレコードの書込みを、ここでは、合併型と称する。
レコード211の書込みが合併型の場合、レコード書込機能部12は、処理内容を示すデータ(例えば「10加算」を示すデータ)が記録されるレコード211を書込み対象のレコード211としてキャッシュ111に格納する(図5の(5))。なお、合併型の書込みの場合は、このレコード211のキャッシュ111への格納(図5の(5))は必須ではない。
また、レコード211の書込みが合併型の場合、レコード書込機能部12は、書込み対象のレコード211に関する管理情報211Aとして、メモリ110に格納したバージョン番号と、自ノード10のノード番号と、合併フラグ値「0」を共有ストレージ装置20に格納し(図5の(6))、さらに、前述の処理内容を示すデータ(例えば「10加算」を示すデータ)が記録されるレコード211を書込み対象のレコード211として共有ストレージ装置20に格納する(図5の(6)´)。
つまり、図6からも明らかなように、合併フラグは、その値が「0」の場合、そのレコードは合併型で書込まれたものであって、レコード211の最新の値を得るためには旧バージョンのレコード211との合併が必要であることを示す。また、その値が「1」の場合、そのレコードは上書型で書込まれたものであるか、または、合併型で書込まれたが合併済みであり、レコードの最新の値を得るための合併が不要であることを示す。
なお、上書型の書込みと、合併型の書込みとは、同一レコードに対して混在させることが可能である。例えば、合併型の書込みで更新が重ねられてきたレコードの値を、上書型の書込みで初期値にリセットするといったことを行うことができる。
また、図6では、判り易くするために、同一レコードのバージョン番号を連番としているが、前述したように、バージョン番号は、分散データベース全体におけるレコードの書込み順序を示す。
以上の処理を完了すると、レコード書込機能部12は、書込み対象のレコード211に関する書込用共有ロックを解放する(図5の(7))。
次に、図7を参照しながら、本分散データベースにおけるノード10による共有ストレージ装置20からのレコード211の読込み手順について説明する。
ノード10のレコード読込機能部11は、共有ストレージ装置20からのレコード211の読込みを実行するモジュールである。レコード読込機能部11は、レコード211の読込み要求を受けると(図7の(1))、まず、そのレコード211に関する読込用共有ロックを取得する(図7の(2))。
次に、レコード読込機能部11は、そのレコード211の最新のバージョン番号(分散データベース全体の最新のバージョン番号ではない)、ノード番号および合併フラグ値を共有ストレージ装置20から取得する(図7の(3))。合併フラグ値「1」が取得された場合、レコード読込機能部11は、共有ストレージ装置20から取得したバージョン番号と、メモリ110に格納される当該レコード211のバージョン番号とを比較する(図7の(4))。2つのバージョン番号が一致する場合、レコード読込機能部11は、メモリ110、より具体的には、キャッシュ111から読込み対象のレコード211を取得する。
メモリ110に格納されるバージョン番号が共有ストレージ装置20から取得したバージョン番号よりも古い場合、レコード読込機能部11は、共有ストレージ装置20から取得したノード番号で示される他のノード10、つまり、最新のレコード211を保有する他のノード10に対し、そのレコード211の共有ストレージ装置20への反映を要求する(図7の(5A))。この要求を受けた他のノード10は、キャッシュ111に格納される当該最新のレコード211の共有ストレージ装置20への書込みを実行する(図7の(5A)´)。レコード反映機能部14は、キャッシュ111に格納された(共有ストレージ装置20に未反映の)レコード211を共有ストレージ装置20に反映させる処理を実行するモジュールである。レコード読込機能部11は、反映後のレコード211(読込み対象のレコード)を共有ストレージ装置20から取得して、キャッシュ111に格納する(図7の(6))。なお、最新のレコード211を保有する他のノード10が当該最新のレコード211を共有ストレージ装置20に反映済みであった場合、他のノード10に対する最新のレコード211の反映要求(図7の(5A))は不要である。未反映か反映済みかは、最新バージョンのレコード211(実データ)が共有ストレージ装置20に存在するか否かで判断できる。
また、合併フラグ値「0」が取得された場合、レコード読込機能部11は、レコード合併機能部13に対して、最新の書込みが合併型で行われて未合併の状態にある当該レコード211の合併を指示する。レコード合併機能部13は、合併型で書込まれたレコードの合併を実行するモジュールである。レコード合併機能部13は、レコード読込機能部11から指示されたレコード211の合併を実行し(図7の(5B))、レコード読込機能部11は、合併後のレコード211(読込み対象のレコード)を共有ストレージ装置20から取得して、キャッシュ111に格納する(図7の(6))。
レコード合併機能部13によるレコード211の合併の概要を説明すると、レコード合併機能部13は、合併フラグ値「1」の中で最も新しいバージョン番号のレコード211と、それ以降の(合併フラグ値「0」の)バージョン番号のすべてのレコード211とを取得し、バージョン番号の昇順にレコード211の合併を行い、合併後のレコード211を共有ストレージ装置20に格納すると共に、当該レコード211に関する管理情報211Aとして、合併フラグ値「1」を共有ストレージ装置20に格納する。
以上の処理を完了すると、レコード読込機能部11は、読込み対象のレコード211に関する読込用共有ロックを解放する(図7の(7))。
続いて、図8および図9を参照して、書込用共有ロックを新設して複数のノード10が同一レコード211を対象とする書込みを並行して実行できるようにした本分散データベースにおけるレコード211の整合性の保持について説明する。
図8は、複数のノード10が並行して上書型の書込みを行ったレコード211の整合性が保たれる原理を示す図である。
図8には、(a)ノードAによるレコード1に対する上書型の書込み、(b)ノードBによるレコード1に対する上書型の書込み、が実行された後、(c)ノードAによるレコード1に対する読込みが実行されるケースが示されている。より具体的には、ノードAがレコード1に「banana」を書込み、ノードBがレコード1に「apple」に書き込んだ後(「banana」→「apple」の置換えが行われた後)、ノードAが自ノードにキャッシュされる「banana」ではなく、ノードBにキャッシュされる「apple」を、レコード1の読込みで取得するケースである。
図8に示されるように、ノードAがレコード1に「banana」を書込む際、バージョン番号「1」が取得されている。また、ノードBがレコード1に「apple」を書込む際には、バージョン番号「2」が取得されている。なお、ここでは、判り易くするために、レコード1について取得されるバージョン番号を便宜的に連番としている。また、上書型の書込みなので、合併フラグの値は「1」である。
ノードAは、レコード1を読込む際、最新のバージョン番号を調べる。ここでは、最新のバージョン番号が「2」であるのに対し、自ノードにキャッシュされるレコード1のバージョン番号は「1」と古い。そこで、ノードAは、最新のレコード1をキャッシュするノードBに対し、当該最新のレコード1の共有ストレージ装置20への反映を要求し、反映後のレコード1を取得する。
このように、複数のノード10が並行して上書型の書込みを行ったレコード211の整合性は何ら問題なく保たれる。
また、図9は、複数のノード10が並行して合併型の書込みを行ったレコード211の整合性が保たれる原理を示す図である。
図9には、(a)ノードAによるレコード1に対する合併型の書込み、(b)ノードBによるレコード1に対する合併型の書込み、が実行された後、(c)ノードAによるレコード1に対する読込みが実行されるケースが示されている。より具体的には、ノードAがレコード1の値(初期値「0」)に「100加算」の処理を施し、ノードBがレコード1の値に「2乗算」の処理を施した後、ノードAが自ノードにキャッシュされる「100加算」の結果である「100」ではなく、次のノードBにキャッシュされる「2乗算」の結果である「200」を、レコード1の読込みで取得するケースである。
図9に示されるように、ノードAがレコード1に「100加算」を書込む際、バージョン番号「1」が取得されている。また、ノードBがレコード1に「2乗算」を書込む際には、バージョン番号「2」が取得されている。なお、ここでも、判り易くするために、レコード1について取得されるバージョン番号を便宜的に連番としている。また、ノードAおよびノードBがレコード1をキャッシュする例を示しているが、前述したように、合併型の書込みの場合、書込み対象のレコード211のキャッシュ111への格納は必須ではない。また、合併型の書込みなので、合併フラグの値は「0」である。
ノードAは、レコード1を読込む際、合併フラグを調べる。読込み時当初の最新のバージョン番号は「2」であり、その合併フラグの値は「0」である。そこで、ノードAは、レコード1の合併を行い、合併後のレコード1を取得する。ノードAは、取得した合併後のレコード1をキャッシュ111および共有ストレージ装置20の両方に格納する。
このように、複数のノード10が並行して合併型の書込みを行ったレコード211の整合性も何ら問題なく保たれる。
図10は、本分散データベースにおけるノード10による共有ストレージ装置20への上書型でのレコード211の書込み時の動作手順を示すフローチャートである。
まず、ノード10は、共有ストレージ装置20から最新バージョン番号と書込用共有ロックを取得する(ブロックA1)。書込用共有ロックが取得できた場合(ブロックA2のYES)、ノード10は、キャッシュ111にレコード211を格納、即ち、キャッシュ111のレコード211を更新する(ブロックA3)。書込用共有ロックの取得に成功する場合とは、いずれのノード10もロックを取得していない場合または他のノード10が書込用共有ロックを取得している場合である。つまり、書込用共有ロックは、複数のノード10が同一レコード211について並行して取得可能なロックである。
キャッシュ111のレコード211を更新したら、ノード10は、共有ストレージ装置20にバージョン番号と合併フラグを書込み、書込用共有ロックを解放する(ブロックA4)。この時に書込まれる合併フラグの値は「1」である。なお、書込用共有ロックが取得できなかった場合(ブロックA2のNO)、ノード10は、書込み要求の発行元に対して、ロック取得失敗のエラーを返却する(ブロックA5)。書込み要求の発行元は、このエラーの返却を受けて、要求した処理が失敗したことを認識する。
図11は、本分散データベースにおけるノード10による共有ストレージ装置20への合併型でのレコード211の書込み時の動作手順を示すフローチャートである。
合併型の書込みの場合も、ノード10は、まず、共有ストレージ装置20から最新バージョン番号と書込用共有ロックを取得する(ブロックB1)。書込用共有ロックが取得できた場合(ブロックB2のYES)、ノード10は、共有ストレージ装置20にバージョン番号と合併フラグとレコード211を書込み、書込用共有ロックを解放する(ブロックB3)。この時に書込まれる合併フラグの値は「0」である。また、この時に書き込まれるレコード211には、処理内容を示すデータが記録されている。なお、書込用共有ロックの取得に成功する場合とは、上書型の書込みの場合と同様、いずれのノード10もロックを取得していない場合または他のノード10が書込用共有ロックを取得している場合である。このように、書込用共有ロックは、上書型、合併型を問わず、複数のノード10が同一レコード211について並行して取得可能なロックである。また、図11には、レコード211のキャッシュ111への格納を省略する場合の動作手順を示している。
なお、書込用共有ロックが取得できなかった場合(ブロックB2のNO)、ノード10は、上書型の書込みの場合と同様、書込み要求の発行元に対して、ロック取得失敗のエラーを返却する(ブロックB4)。書込み要求の発行元は、このエラーの返却を受けて、要求した処理が失敗したことを認識する。
図12は、本分散データベースにおけるノード10による共有ストレージ装置20からのレコード211の読込み時の動作手順を示すフローチャートである。
まず、ノード10は、共有ストレージ装置20から対象レコード211の直近バージョン番号と合併フラグと読込用共有ロックを取得する(ブロックC1)。読込用共有ロックが取得できた場合(ブロックC2のYES)、ノード10は、合併フラグの値が「1」か否かを調べる(ブロックC3)。
合併フラグの値が「1」である場合(ブロックC3のYES)、ノード10は、キャッシュ111にレコード211が存在するか否かを調べる(ブロックC4)。レコード211が存在する場合(ブロックC4のYES)、ノード10は、共有ストレージ装置20から取得したバージョン番号とキャッシュ111に格納されるバージョン番号との比較により、キャッシュ111に存在するレコード211が最新バージョンか否かを調べる(ブロックC5)。
最新バージョンである場合(ブロックC5のYES)、ノード10は、そのまま、キャッシュ111から読込み対象のレコード211を取得し(ブロックC6)、読込用共用ロックを解放する(ブロックC7)。
キャッシュ111にレコード211が存在しない場合(ブロックC4のNO)またはキャッシュ111に存在するレコード211が最新バージョンでない場合(ブロックC5のNO)、ノード10は、共有ストレージ装置20に最新バージョンのレコード211が反映されているか否かを調べる(ブロックC8)。反映されていれば(ブロックC8のYES)、ノード10は、共有ストレージ装置20からキャッシュ111にレコード211を転送した上で(ブロックC9)、キャッシュ111から読込み対象のレコード211を取得し(ブロックC6)、読込用共用ロックを解放する(ブロックC7)。
反映されていなければ(ブロックC8のNO)、ノード10は、図13に動作手順が示されるレコード反映処理を実行し(ブロックC10)、かつ、共有ストレージ装置20からキャッシュ111にレコード211を転送した上で(ブロックC9)、キャッシュ111から読込み対象のレコード211を取得し(ブロックC6)、読込用共用ロックを解放する(ブロックC7)。
合併フラグの値が「0」である場合(ブロックC3のNO)、ノード10は、図14に動作手順が示されるレコード合併処理を実行し(ブロックC11)、かつ、共有ストレージ装置20からキャッシュ111にレコード211を転送した上で(ブロックC9)、キャッシュ111から読込み対象のレコード211を取得し(ブロックC6)、読込用共用ロックを解放する(ブロックC7)。
なお、読込用共有ロックが取得できなかった場合(ブロックC2のNO)、ノード10は、書込みの場合と同様、読込み要求の発行元に対して、ロック取得失敗のエラーを返却する(ブロックC12)。このエラーの返却を受けて、読込み要求の発行元は、要求した処理が失敗したことを認識する。
図13は、本分散データベースにおいて実行されるレコード反映処理の動作手順を示すフローチャートである。
図13中、(A)は、最新バージョンのレコード211を共有ストレージ装置20に反映することを要求する側のノード10の動作手順を示し、(B)は、最新バージョンのレコード211を共有ストレージ装置20に反映することを要求された側のノード10の動作手順を示している。
読込み対象のレコード211がキャッシュ111に存在しない場合またはキャッシュ111に存在する読込み対象のレコード211が最新バージョンでない場合であって、共有ストレージ装置20に最新バージョンのレコード211が反映されていない場合、ノード10は、最新バージョンのレコード211をキャッシュ111に格納する(ノード番号で示される)他のノード10に対して、最新バージョンのレコード211を共有ストレージ装置20に反映することを要求する(ブロックD11)。
一方、レコード反映要求を受けたノード10は、共有ストレージ装置20に格納されるレコード211の直近バージョン番号を取得し(ブロックD21)、共有ストレージ装置20のレコード211が旧バージョンであることを確認する(ブロックD22)。旧バージョンであることを確認したら(ブロックD22のYES)、ノード10は、共有ストレージ装置20から排他ロックを取得する(ブロックD23)。排他ロックが取得できた場合(ブロックD24のYES)、ノード10は、キャッシュ111のレコード211を共有ストレージ装置20に書込み、排他ロックを解放する(ブロックD25)。
なお、レコード反映要求が生じるケースとしては、ここで説明する外部(他のノード10)から要求されるケースのほか、キャッシュ置換と称される処理を行うケースが存在する。キャッシュ置換とは、キャッシュ111のデータを共有ストレージ装置20に戻すことを保証するための処理である。このキャッシュ置換の場合、ノード10は、キャッシュ111のレコード211を共有ストレージ装置20に書込んだ後、そのレコード211をキャッシュ111から削除する(ブロックD26)。
排他ロックが取得できなかった場合(ブロックD24のNO)、ノード10は、反映要求の発行元に対して、ロック取得失敗のエラーを返却する(ブロックD27)。このエラーの返却を受けて、反映要求の発行元は、要求した処理が失敗したことを認識する。
図14は、本分散データベースにおいて実行されるレコード合併処理の動作手順を示すフローチャートである。
合併型で書込まれて未合併のレコード211を合併する場合、ノード10は、まず、共有ストレージ装置20から排他ロックを取得する(ブロックE1)。排他ロックが取得できた場合(ブロックE2のYES)、ノード10は、共有ストレージ装置20から、対象レコード211のうち、合併フラグが「1」の直近バージョンとそれ以降の合併フラグが「0」のレコード211とを取得する(ブロックE3)。
ノード10は、取得したレコード211を基に、当該レコード211を最新バージョンに合併する(ブロックE4)。ノード10は、キャッシュ111に合併後のレコード211とバージョン番号を書込むと共に(ブロックE5)、共有ストレージ装置20に合併後のレコード211を書込み(ブロックE6)、排他ロックを解放する(ブロックE7)。
このように、本分散データベースによれば、データの整合性を保証しつつ、データの書込み時における排他ロックの取得を不要とすることが実現される。
ところで、以上の説明では、各ノード10が共有ストレージ装置20にアクセスする際のデータ領域単位をレコード単位と想定し、バージョン番号や合併フラグをレコード211毎に管理する例を示したが、これに限らず、例えば、バージョン番号や合併フラグをフィールド毎に管理するようにしてもよい。
また、以上の説明では、レコード211の書込みが上書型および合併型の2つのパターンで実行され得る例を示したが、本分散データベースのデータアクセス手法は、上書型または合併型の一方のみが実行される場合においても有効である。上書型の書込みのみが実行される場合、合併フラグの管理を不要とすることができる。
各実施形態の動作手順は、ソフトウェア(プログラム)によって実現することができるので、このソフトウェアを格納したコンピュータ読み取り可能な記憶媒体を通じてこのソフトウェアを通常のコンピュータにインストールして実行することにより、各実施形態と同様の効果を容易に実現することができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると共に、特許請求の範囲に記載された発明とその均等の範囲に含まれる。