JPH10254748A - 分散共有メモリ一貫性最適制御方法 - Google Patents

Abstract

(57)【要約】 【課題】分散データベース管理システム等における分散
共有メモリ一貫性最適制御方法に関し，読み出しにおけ
る通信コストと書き込みにおける通信コストとのバラン
スを保つことにより，メッセージ通信のオーバヘッドを
削減することを目的とする。 【解決手段】分散共有仮想メモリ3,3'について，書き込
みの少ないデータは，ライト・インバリデーション・プ
ロトコルによって，処理終了後もメモリ3,3'内にデータ
を残し，ライト時にデータ無効を通知する。書き込みの
多いデータは，イーブン・コスト・プロトコルによっ
て，処理終了後もメモリ3,3'内にデータを残すが，ライ
ト時にデータ無効のメッセージは送らないようにし，そ
のデータに対する再度の処理時にそのデータの有効性を
確認することを行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，計算機網上に実現
された分散データベース管理システム等において，各計
算機が持つ分散共有メモリのデータの一貫性を効率よく
保証することができるようにした分散共有メモリ一貫性
最適制御方法に関する。

【０００２】

【従来の技術】図１７は，一般的な従来の計算機網を示
す。例えば図１７に示すように，複数の計算機１０１〜
１０４がネットワーク１００で接続された計算機システ
ムが用いられている。各々の計算機はディスク記憶装置
１１１〜１１４を持ち，ディスク記憶装置１１１〜１１
４にはデータベースが格納される。データベースは複数
のディスク記憶装置に分散されていてもよいし，１つの
ディスク記憶装置に集められていてもよい。データベー
スの利用者は，計算機網上の任意の計算機１０１〜１０
４から，ネットワーク１００を介して，任意のディスク
記憶装置１１１〜１１４に格納されたデータベースにア
クセスする。

【０００３】分散データベース管理システムと分散共有
メモリとは密接な関係がある。分散共有メモリ（または
分散共有仮想メモリともいう）とは，計算機網を構成す
る複数の計算機によって共有されたメモリ空間のことで
ある。具体的には，計算機網上の各計算機に分散共有仮
想メモリの複製が作成され，互いの通信により各複製の
メモリイメージの同一性が維持される（このことをメモ
リコヒーレンスという）。

【０００４】このシステムでは，オペレーティングシス
テム（ＯＳ）が提供するメモリマップドファイルの機能
を利用することで，ディスク記憶装置にファイルとして
格納されたデータベース（データベースファイル）を，
分散共有仮想メモリにマップすることが可能である。

【０００５】図１８は，図１７に示すシステムでのデー
タベースへのアクセス説明図である。図１８のように，
あるアプリケーションプログラム１５２が，ネットワー
ク１００を介して遠隔のデータベース１４１にアクセス
する場合，両方の計算機１０１，１０２の仮想メモリ空
間１３１，１３２中に，分散共有仮想メモリ１２１，１
２２が作成される。そして，一方の分散共有仮想メモリ
１２１はデータベースファイルにマップされ，もう一方
の分散共有仮想メモリ１２２はアプリケーションプログ
ラム１５２から利用される。

【０００６】ここでは，データベースファイルが格納さ
れたディスク記憶装置１１１に接続された計算機１０１
をデータベースサイト，アプリケーションプログラム１
５２が実行されるサイトをアプリケーションサイトと呼
ぶことにする。

【０００７】データベースサイトおよびアプリケーショ
ンサイト上で，メモリコヒーレンスを行うための特別な
プロセスを常に実行し，このプロセスが実行されている
ことをアプリケーションプログラムから意識させないよ
うにすることが可能である。このようにすると，分散共
有仮想メモリ１２２へのアクセスは，ネットワーク１０
０を意識せずに，通常のメモリアクセスと同様に行うこ
とができる。すなわち，分散共有仮想メモリ１２２を利
用することで，データベース１４１へのアクセスを通常
のメモリアクセスと同様に行うことができる。このこと
は，計算機網上に実現された分散データベースのアプリ
ケーションプログラム１５２の開発が容易に行えること
を意味する。

【０００８】以上のようなシステムで用いられるメモリ
コヒーレンスは，計算機網上のあるアプリケーションプ
ログラムが書き込んだデータを，他の計算機に見掛け上
瞬時に配送するための技術である。メモリコヒーレンス
では，あるアプリケーションプログラムがデータを読み
込む場合には，そのデータについて，現時点に最も時間
的に近く書き込まれたデータが読み出されなければなら
ないという原則がある。

【０００９】メモリコヒーレンスには，大きく分けて，
Weak ConsistencyとStrong Consistencyの２つの手法が
ある。Weak Consistencyの研究は，“B.N.Bershad and
M.J.Zekauskas.“Midway：shared memory parallel pro
graming casual distributed shared memory”, Procee
dings of the 11th International Conference on Dist
ributed Computing Systems, pp.152-164,1991. ”など
で行われてきた。

【００１０】Weak Consistencyでは，ユーザがあるアプ
リケーションプログラムを開発するときに，ある程度メ
モリコヒーレンスを意識したプログラミングを書くこと
を義務づける（例えば，ユーザにロック命令を書かせ
る）ことで，メッセージ数を減らそうというものであ
る。従って，この方式は，ユーザに負担を強いるものだ
といえる。

【００１１】一方，Strong Consistencyは，ユーザは，
アプリケーション開発において，メモリコヒーレンスを
意識する必要はなく，その意味でアプリケーションの開
発は容易である。しかし，Weak Consistencyよりも性能
は劣る。

【００１２】

【発明が解決しようとする課題】本発明は，前述したSt
rong Consistencyをベースとして，性能面での改善，お
よびデータベースシステムの実現に必要となるトランザ
クション機能の導入を図ることにより，アプリケーショ
ンの開発が容易で，かつ性能のよいメモリコヒーレンス
を実現することを目的とする。特に，読み出しにおける
通信コストと書き込みにおける通信コストとのバランス
を保つことにより，メッセージ通信のオーバヘッドを削
減することを目的とする。

【００１３】

【課題を解決するための手段】図１は本発明の概要説明
図である。図１（Ａ）において，１，１’はプロセッサ
とメモリを持つ計算機，２，２’は各計算機で動作する
アプリケーションプログラム（単に，アプリケーション
ともいう）に対して共有メモリへのアクセス機能を提供
する分散共有仮想メモリ管理部，３，３’は計算機１，
１’が共有する分散共有仮想メモリを表す。

【００１４】図１（Ｂ）は，分散共有仮想メモリ３，
３’内のページの状態遷移を示しており，５はページデ
ータが無効（空）であることを示すインバリッド(Inval
id) 状態，６はページデータが有効であることを示すバ
リッド(Valid) 状態，７は所定の時間内にライトされた
ことを示す更新ホットスポット状態を表す。

【００１５】本発明では，各計算機１，１’の分散共有
仮想メモリ３，３’のメモリコヒーレンスを実現するた
めに，ライト・インバリデーション・プロトコル(Write
Invalidation Protocol) によってデータの一貫性を保
証する手段と，イーブン・コスト・プロトコル(Even Co
st Protocol)によってデータの一貫性を保証する手段と
を持ち，ライト・インバリデーション・プロトコルとイ
ーブン・コスト・プロトコルとを，データへのアクセス
状況によって動的に切り換えることを主要な特徴とす
る。

【００１６】ライト・インバリデーション・プロトコル
は，各計算機１，１’が保持する分散共有仮想メモリ
３，３’のデータを，そのデータを利用したアプリケー
ションまたは一連のアクセス処理の終了後も残し，その
データの更新時に他の同じデータを持つ計算機に対して
そのデータの無効を通知する（このメッセージをインバ
リデート・メッセージという）ことによって，データの
矛盾が生じないようにする計算機間のプロトコルであ
る。ここでいうアプリケーションまたは一連のアクセス
処理の終了時点とは，アプリケーションプログラムの実
行終了，オンラインシステムにおけるトランザクション
の終了，またはリードロックやライトロックなどのロッ
ク解放等の時点をいう。

【００１７】イーブン・コスト・プロトコルは，本発明
によって新たに導入されたプロトコルであり，各計算機
１，１’が保持する分散共有仮想メモリ３，３’のデー
タを，そのデータを利用したアプリケーションまたは一
連のアクセス処理の終了後も残すが，インバリデート・
メッセージの通知はせず，その代わりに再度のリードま
たはライト時にそれが矛盾のないものであるかどうかの
確認を行うことで，その後に他の計算機でデータがライ
トされても，ライト前のデータを読むことなく，新たな
ライト後のデータを読むようにした計算機間のプロトコ
ルである。

【００１８】ライト・インバリデーション・プロトコル
とイーブン・コスト・プロトコルとの切り替えは，分散
共有仮想メモリ３，３’の全体に対して行っても，分散
共有仮想メモリ３，３’の例えばページごとに行っても
いずれでもよい。特に，ページ単位で行った場合には，
効果が大きい。

【００１９】ページなどのある大きさのデータ単位で切
り替える場合には，例えば以下のようにプロトコルを選
択する。分散共有仮想メモリ３，３’内のデータに対し
て，イーブン・コスト・プロトコルを用いるか，ライト
・インバリデーション・プロトコルを用いるかを，アク
セス要求のあったデータが最後にライトされてから所定
の時間が経過したかどうかによって決める。最後にライ
トされてから所定の時間が経過するまではイーブン・コ
スト・プロトコルを選択し，所定の時間が経過した場合
には，ライト・インバリデーション・プロトコルを選択
する。

【００２０】また，分散共有仮想メモリ３，３’の各デ
ータについて，ページごとにライトされた回数をカウン
トしておき，所定の期間内においてライトのアクセス頻
度の多いデータについてイーブン・コスト・プロトコル
を選択し，ライトのアクセス頻度の少ないデータについ
てライト・インバリデーション・プロトコルを選択する
ようにしてもよい。ライトのアクセス頻度が多いか少な
いかは，与えられた閾値との比較によって判断する。ま
たは，リードのアクセス回数との相対的な比較によって
判断するようにしてもよい。

【００２１】イーブン・コスト・プロトコルは，データ
の更新時に他の同じデータを持つ計算機に対してそのデ
ータの無効を通知するインバリデート・メッセージを送
る必要がないので，ライトが多い場合には，ライト・イ
ンバリデーション・プロトコルよりもメッセージ通信の
回数が少なくて済み，有利である。

【００２２】一方，イーブン・コスト・プロトコルで
は，アプリケーションまたは一連のアクセス処理の終了
後，次のアプリケーションが同じデータを利用する場合
であっても，最新のデータを持つ計算機への問い合わせ
と，必要に応じて再度のデータ転送を行う。したがっ
て，ライトが少なくリードが多いデータに対しては，ラ
イト・インバリデーション・プロトコルのほうが有利で
ある。

【００２３】分散共有仮想メモリ３，３’の各ページに
ついて，ライト・インバリデーション・プロトコルを用
いるか，イーブン・コスト・プロトコルを用いるかの決
定のために，図１（Ｂ）に示すようなページの状態遷移
を管理する手法を用いることができる。この管理によれ
ば，比較的簡単なロジックによって決定できるので，プ
ロトコル決定のためのオーバヘッドが少ない。

【００２４】従来の分散共有仮想メモリのページの状態
には，ページデータが無効である（空である）インバリ
ッド状態５と，ページデータが有効である（データの複
製が作成されている）バリッド状態６の二つの状態があ
った。本発明では，さらに現在から一定時間Ｔの過去の
間にライトされたという更新ホットスポット状態７を設
ける。

【００２５】インバリッド状態５およびバリッド状態６
において，そのページにライトがあった場合には，その
ページの状態を更新ホットスポット状態７に遷移させ
る。インバリッド状態５におけるデータのリードにより
元のデータの複製を持つとき，および更新ホットスポッ
ト状態７において所定の時間Ｔが経過したときに，その
ページの状態をバリッド状態６に遷移させる。

【００２６】バリッド状態６においてそのページデータ
が無効であることを通知するインバリデート・メッセー
ジが到着したとき，そのページの状態をインバリッド状
態５に遷移させる。

【００２７】これにより，バリッド状態６のデータに対
しては，ページデータへのライト時に他の同じページデ
ータを持つ計算機に対してそのデータの無効を通知する
インバリデート・メッセージを送信することによってデ
ータの一貫性を保証し，更新ホットスポット状態７のデ
ータに対しては，ページデータのリードまたはライト時
に，そのページデータの有効性の確認を行うことによっ
て，分散共有仮想メモリ内のページデータの一貫性を保
証する。

【００２８】本発明の作用は以下のとおりである。分散
共有仮想メモリを利用する分散データベース管理システ
ム等において，メモリコヒーレンスの実現には，データ
ベースサイトおよびアプリケーションサイト間でのメッ
セージ通信が必要である。ＣＰＵ（プロセッサ）やディ
スク記憶装置の速さに比べて，ネットワークの速さは遅
いので，メモリコヒーレンスのためのメッセージ通信の
オーバヘッドが，性能面での大きなボトルネックとな
る。すなわち，ネットワークを介したデータ転送は遅い
ために，計算機網を構成する計算機の台数をある程度以
上に増やすと，もはや台数の追加による性能の向上を達
成できない。

【００２９】そこで，本発明は，従来のメモリコヒーレ
ンス方式に，新しいメモリコヒーレンス方式であるイー
ブン・コスト(Even Cost) プロトコルを統合し，結果と
して，より高い性能を得ることを達成する。イーブン・
コスト・プロトコルは，ライト操作がある程度以上多い
アプリケーションに対して，より少ないメッセージ数で
メモリコヒーレンスを実現可能な方式である。

【００３０】本発明は，例えば分散共有仮想メモリをペ
ージ単位に分割し，各ページごとのアクセス状況を監視
することで，各ページごとに最適なメモリコヒーレンス
を判断し，動的に切り替えるものである。

【００３１】本発明は，Strong Consistencyをベースと
して，（１）性能面での改善，および（２）データベー
スシステムの実現に必要となるトランザクション機能の
導入を行ったものである。

【００３２】

【発明の実施の形態】以下，本発明を分散データベース
管理システムに適用した場合の実施の形態を説明する。

【００３３】本方式では，従来のメモリコヒーレンスに
おける一般的な手法であるライト・インバリデーション
（Write Invalidation）プロトコルをベースにしてい
る。ライト・インバリデーション・プロトコルとは，
「必要になったら通信を行う」という方針である。すな
わち，最初，アプリケーションサイトの分散共有仮想メ
モリの中身は空であり，必要に応じて必要な分だけのデ
ータ転送が，アプリケーションサイトに行われるという
方針である。

【００３４】図２は，ライト・インバリデーション・プ
ロトコルにおけるリード時の処理を説明する図である。
例えば，図２のように計算機１Ｂ上のアプリケーション
プログラムが，分散共有仮想メモリ３Ｂ内のデータをリ
ードする時には，リードするデータを含むページのみが
データベースサイトである計算機１Ａから計算機１Ｂに
送られる。このとき，アプリケーションサイトである計
算機１Ｂは，リードの前にデータ要求を発し，その返事
としてデータが，データベースサイトからアプリケーシ
ョンサイトに供給される。

【００３５】ライト・インバリデーション・プロトコル
では，計算機網上の各計算機１Ａ〜１Ｃに分散共有仮想
メモリの複製が作成され，データを利用したアプリケー
ションプログラム等が終了しても，一度作成された複製
は可能な限り残り続ける。

【００３６】このライト・インバリデーション・プロト
コルでは，データ書き込みの場合に，複製が置かれてい
るすべての計算機に対して「当該データは更新されたの
で，今の複製は無効である」ことを知らせるメッセージ
（これをインバリデート・メッセージという）が通知さ
れることが特徴である。

【００３７】図３は，ライト・インバリデーション・プ
ロトコルにおけるライト時の処理を説明する図である。
例えば，図３のように計算機１Ｂ上のアプリケーション
プログラムがリードした後で，同じデータを計算機１Ｃ
上のアプリケーションプログラムがライトする場合，デ
ータベースサイトである計算機１Ａから計算機１Ｃへデ
ータが送られると同時に，計算機１Ｂ上の複製を無効化
するためのインバリデート・メッセージが計算機１Ｂへ
送られる。計算機１Ｂでは，これにより該当データを消
去するので，計算機１Ｃがライトを行っても，それより
古いデータを読むことはない。

【００３８】一方，イーブン・コスト(Even Cost) プロ
トコルでは，計算機網上の各計算機に作成される分散共
有仮想メモリの複製への再度のリードまたはライト時
に，その有効性の確認を行う。

【００３９】図４は，イーブン・コスト・プロトコルに
おけるライト時の処理を説明する図である。イーブン・
コスト・プロトコルにおいて，計算機１Ｂ上のアプリケ
ーションプログラムがデータベース８のデータをリード
する時には，リードするデータを含むページのみが，デ
ータベースサイトである計算機１Ａの分散共有仮想メモ
リ３Ａから計算機１Ｂの分散共有仮想メモリ３Ｂに送ら
れる。このことは，ライト・インバリデーション・プロ
トコルと同じである。

【００４０】しかし，イーブン・コスト・プロトコルで
は，インバリデート・メッセージの通知を行わない。す
なわち，例えば図４のように計算機１Ｂ上のアプリケー
ションプログラムがリードした後で，同じデータを計算
機１Ｃ上のアプリケーションプログラムがライトする場
合，データベースサイトである計算機１Ａから計算機１
Ｃへデータが送られるが，インバリデート・メッセージ
を送らない。その代わり，計算機１Ｂの他のアプリケー
ションが，分散共有仮想メモリ３Ｂに残っているページ
データをリードまたはライトするとき，計算機１Ａとの
間で確認を行う。

【００４１】以上を比較すると，イーブン・コスト・プ
ロトコルは，リード時のメッセージ数は多くなり，ライ
ト時のメッセージ数は少なくなる。ライト・インバリデ
ーション・プロトコルでは，計算機網を構成する計算機
の台数の増加につれてインバリデート・メッセージの数
が増加することが問題であったが，イーブン・コスト・
プロトコルではそのような問題はない。

【００４２】一方，ライト・インバリデーション・プロ
トコルでは，一度アプリケーションサイトに作成された
複製は可能な限り残り続け，しかも，そのアプリケーシ
ョンサイトで他のアプリケーションプログラムがリード
を行う場合，直ちに利用可能で，データベースサイトか
らのデータ転送を行う必要がないので，その点が有利で
ある。

【００４３】以上をまとめると，ライトが多い場合に
は，イーブン・コスト・プロトコルが有利であり，ライ
トが少なくリードが多い場合には，ライト・インバリデ
ーション・プロトコルが有利である。

【００４４】本方式の特徴は，分散共有仮想メモリをペ
ージ単位に分割し，各ページごとのアクセス状況を監視
して，各ページごとに最適なプロトコル方式を刻々と判
断することにある。

【００４５】各ページについてライトが多いか少ないか
を判断する一方法として，ライトされた回数をページご
とにカウントし，所定の閾値と比較する方法が考えられ
る。本実施の形態では，さらに効果的に判断できるよう
にするため，ページの状態として「更新ホットスポッ
ト」という新しい属性を導入し，次のようにページの状
態管理を行う。

【００４６】従来の分散共有仮想メモリのページの状態
には，（１）複製が作成されている（Valid)，（２）空
である(Invalid）の２つの状態があった。本方式では，
現在からある一定時間Ｔの過去の間にライトされたペー
ジは，「更新ホットスポット」であるものとする。すな
わち，ライトされたページは，「バリッド」状態または
「インバリッド」状態から「更新ホットスポット」状態
に変わり，一定時間Ｔの経過後に「バリッド」状態に変
わるものとする（図１（Ｂ）参照）。

【００４７】本方式は，ページ状態がバリッド状態の場
合にはライト・インバリデーション・プロトコルを用
い，更新ホットスポット状態の場合には，イーブン・コ
スト・プロトコルを用いるものである。

【００４８】更新ホットスポット状態のページにリード
またはライトを行う場合には，これらデータ操作の前
に，データの有効性の確認を行うという操作が必要であ
る。ライトを行ったアプリケーションプログラムについ
ては，その時刻を覚えておいて，更新ホットスポットで
あるべき時間を定める必要がある。

【００４９】以上のことから，各ページごとに，アクセ
スしたアプリケーションプログラムのプロセスＩＤおよ
びその時刻を覚えることが必要である。以下，リードア
クセスした時刻をＲＲＴ，ライトアクセスした時刻をＲ
ＵＴと呼ぶことにする。

【００５０】以上の方式を実現するため，アプリケーシ
ョンサイトは，リード時には図５に示した処理を，ライ
ト時には図６に示した処理を行う。また，データベース
サイトでは，リード時には図７に示した処理を行う。

【００５１】図５は，リード時におけるアプリケーショ
ンサイトでの処理を説明する図である。リード要求に対
して，ステップＳ１０では，ページ状態が更新ホットス
ポット状態，すなわち現在からさかのぼって一定時間Ｔ
内にライトされたページであるかどうかを調べる。更新
ホットスポットの場合，ステップＳ１２へ進む。

【００５２】更新ホットスポットでない場合，次にステ
ップＳ１１により，ページ状態はインバリッド状態であ
るかどうかを調べる。インバリッド状態の場合，ステッ
プＳ１２へ進む。

【００５３】ページ状態が更新ホットスポットでもイン
バリッドでもない場合，ページ状態はバリッド状態でリ
ードが可能であるので，そのままリード処理へ移る。ペ
ージ状態が更新ホットスポットまたはインバリッドの場
合，その状態でデータをリードすることはできないの
で，データベースサイトにリード要求を行い，データベ
ースサイトからの許可を待つ。

【００５４】図６は，ライト時におけるアプリケーショ
ンサイトでの処理を説明する図である。ライト時の処理
もリード時の処理とほぼ同様である。ステップＳ２０で
は，ページ状態が更新ホットスポット状態かどうかを調
べ，ステップＳ２１では，インバリッド状態かどうかを
調べる。

【００５５】どちらでもない場合，バリッド状態である
ので，実際のライト処理へ移る。ページ状態が更新ホッ
トスポットまたはインバリッドの場合，ステップＳ２２
によってデータベースサイトにライト要求を行い，デー
タベースサイトからの許可を待つ。

【００５６】図７は，リード時におけるデータベースサ
イトでの処理を説明する図である。リード要求に対して
以下の処理を行う。まず，ステップＳ３０では，ホット
・リード・ユーザが存在するかどうかを判定する。すな
わち，現在リードしているユーザがいて，そのデータの
複製が作成されているかどうかを判定する。ホット・リ
ード・ユーザが存在する場合，ステップＳ３１へ進み，
存在しない場合，ステップＳ３２へ進む。

【００５７】ステップＳ３１では，そのページが最後に
リードアクセスされた時刻ＲＲＴと最後にライトアクセ
スされた時刻ＲＵＴとを比較し，リードアクセスのほう
が新しければ，ステップＳ３３へ進み，リード後にライ
トされていれば，ステップＳ３２へ進む。

【００５８】ステップ３２では，要求元のページは空で
あるか，または古いデータであるので，新しいページデ
ータを転送する。ステップＳ３３では，現在の時刻から
最後にライトした時刻ＲＵＴを引いた時間が一定値より
小さいかどうか，すなわち最後にライトしてからまだ一
定時間が経過していないかどうかを判定する。一定値よ
り小さい場合，そのページは更新ホットスポット状態で
あり，ステップＳ３４へ進む。一定値以上の場合，その
ページはバリッド状態であり，ステップＳ３５へ進む。

【００５９】ステップＳ３４では，ライト・インバリデ
ーション・プロトコルを採用し，データ要求元のアプリ
ケーションが終了（リードロックを解放）したときは，
ページ状態をバリッドに変更するものとする。一方，ス
テップＳ３５では，イーブン・コスト・プロトコルを採
用し，そのアプリケーションが終了したとき，ページ状
態は更新ホットスポットのままとする。

【００６０】

【実施例】図８は，本発明の実施例に係るシステム構成
の例を示す。図中，１Ａ〜１Ｄは各々プロセッサとメモ
リとを有する計算機，２０Ａ〜２０Ｄはアプリケーショ
ンプログラム，１１Ａ〜１１Ｄはアプリケーションプロ
グラム２０Ａ〜２０Ｄに対してデータベースへのアクセ
ス機能を提供するデータベースサーバ，４は各計算機１
Ａ〜１Ｄを接続するネットワーク，８Ａ〜８Ｄはデータ
ベース，９Ａ〜９Ｄはデータベース８Ａ〜８Ｄを格納す
るディスク記憶装置を表す。

【００６１】計算機網を構成する各計算機１Ａ〜１Ｄに
は，データベースサーバ１１Ａ〜１１Ｄが一つずつ配置
される。各データベースサーバ１１Ａ〜１１Ｄは，互い
に通信を行い，本発明の機能を実現する。アプリケーシ
ョンプログラム２０Ａ〜２０Ｄは，同一計算機内のデー
タベースサーバ１１Ａ〜１１Ｄとのみ通信を行う。すな
わち，アプリケーションプログラム２０Ａ〜２０Ｄは，
同一計算機内のデータベースサーバ１１Ａ〜１１Ｄによ
って供給されるデータベース８Ａ〜８Ｄにアクセスを行
うが，データベースサーバ間で通信や各種処理が行われ
ていることは意識しない。

【００６２】図９は，計算機の詳細ブロック図であり，
図８に示す計算機１Ａ〜１Ｄのうちの２台を計算機１
Ａ，計算機１Ｂとして示している。データベースサーバ
１１Ａ（データベースサーバ１１Ｂも同様）は，アプリ
ケーションプログラム２０Ａとデータベースサーバ１１
Ａ間の通信のためのアプリケーションインタフェース１
２Ａ，データベースへのアクセスを制御し，データベー
ス領域１６Ａを管理するデータベース制御部１３Ａ，ロ
ック制御を行うロック制御部１４Ａ，他のデータベース
サーバとの通信を行う通信制御部１５Ａ，データベース
のデータを展開するための分散共有仮想メモリによるデ
ータベース領域１６Ａ，ページ単位のロック情報を管理
するページロックテーブル１７Ａを持つ。

【００６３】図１０ないし図１６は，図８に示すシステ
ムの動作説明図である。以下，図１０ないし図１６に従
って，以下の場合について順に説明する。 １．計算機１Ａ上のデータベース８Ａに，計算機１Ｂか
ら書き込みを行う。

【００６４】２．その後，計算機１Ｃからそのデータベ
ース８Ａの読み込みを行う。 ３．その後，計算機１Ｂから書き込みを行う。 ４．その後，計算機１Ｃから再度読み込みを行う。

【００６５】ページの書き込みが行われた後，一定時間
（Ｔとする）の間は，ページの状態は「ホット」であ
る。以下の説明では，ページ状態が「ホット」である場
合の動作を示すために，上記一連の操作を行う間，ペー
ジの状態は「ホット」のままであるものとする（すなわ
ちＴの長さは十分に長いものとする）。

【００６６】ただし，この例では，簡単のためデータベ
ースのページ数は４ページであり，操作するページはペ
ージ１のみとする。実際では，これらの数はもっと多
い。図１０は，計算機１Ａ上のデータベースに対し，計
算機１Ｂから書き込みを行うときの状態を示している。

【００６７】本システムでは，データベースアクセス時
に，アプリケーションによるロック獲得を義務づけてい
る。計算機１Ａ上のデータベースを，計算機１Ｂから書
き込む場合においては，ロック管理のために，データベ
ースサイトである計算機１Ａのページロックテーブル１
７Ａと，アプリケーションサイトである計算機１Ｂのペ
ージロックテーブル１７Ｂが使用される。各ページロッ
クテーブル１７Ａ，１７Ｂの欄の数は，データベースの
ページ数と同じ４である。

【００６８】ここでは，計算機１Ｂ上のあるアプリケー
ションプログラム（プロセス番号＝１００とする）が，
ページ１に書き込みを行ったものとする（このときの時
刻をＴ１とする）。

【００６９】アプリケーションプログラムがページ１に
書き込みを行うと，計算機１Ａのページロックテーブル
１７Ａ中のページ１の欄に，「アプリケーションサイト
Ｂのプロセス１００が時刻Ｔ１に書き込みを行った」こ
とが記録される。計算機１Ｂのページロックテーブル１
７Ｂでは，時刻Ｔ１が記録されるのみである。

【００７０】図１１は，計算機１Ｂからの書き込みが終
了した状態を示している。本システムでは，アプリケー
ションプログラムは，トランザクションの終了時（いわ
ゆるコミット時）にデータベースサイト（計算機１Ａ）
へ「終了したこと」を通知することになっている。この
場合，「計算機１Ｂから書き込み」を行っていたアプリ
ケーションのトランザクションが終了すると，その通知
は計算機１Ａと１Ｂのそれぞれのロック制御部１４Ａ，
１４Ｂ（図９）へ送られる。

【００７１】その結果，計算機１Ａと１Ｂのページロッ
クテーブル１７Ａ，１７Ｂにおけるページ１の欄には，
ページの状態が「ホット（Ｈｏｔ）」であること，およ
び書き込み時刻が「Ｔ１」であることが記録され，他の
情報（サイト名＝Ｂ，プロセス番号＝１００など）は消
える。同時にデータベース領域１６Ｂのページ１の内容
がデータベース領域１６Ａに送られる。

【００７２】図１２は，計算機１Ｃから読み込みがあっ
たときの状態を示している。次に，計算機１Ｃ上のある
アプリケーションプログラム（プロセス番号＝２００）
が，ページ１から読み出しを行ったものとする（このと
きの時刻をＴ２とする）。そうすると，計算機１Ａのペ
ージロックテーブル１７Ａのページ１の欄に，「アプリ
ケーションサイトＣのプロセス２００が時刻Ｔ２に読み
出しを行った」ことが記録される。計算機１Ｃのページ
ロックテーブル１７Ｃには，時刻Ｔ２が記録される。

【００７３】図１３は，計算機１Ｃからの読み込みが終
了した状態を示している。「計算機１Ｃから読み込み」
を行っていたアプリケーションのトランザクションが終
了すると，その通知は計算機１Ａと計算機１Ｃのそれぞ
れのロック制御部１４Ａ，１４Ｃに送られる。その結
果，計算機１Ａのページロックテーブル１７Ａのページ
１の欄には，以前の情報，すなわちページの状態が「ホ
ット」であること，および書き込み時刻「Ｔ１」の情報
が残り続ける。

【００７４】計算機１Ｃのページロックテーブル１７Ｃ
では，計算機１Ｃにおける最後の操作時刻，すなわちＴ
２が記録される。図１４は，計算機１Ｂから再度書き込
みを行ったときの状態を示している。

【００７５】次に，計算機１Ｂ上のあるアプリケーショ
ンプログラム（プロセス番号＝３００）が，ページ１に
対して書き込みを行ったものとする（このときの時刻を
Ｔ３とする）。このときにも，最初の書き込みと同様の
処理が行われる。すなわち，計算機１Ａのページロック
テーブル１７Ａのページ１の欄に，「アプリケーション
サイトＢのプロセス３００が時刻Ｔ３に書き込みを行っ
た」ことが記録される。計算機１Ｂのページロックテー
ブル１７Ｂでは，時刻Ｔ３が記録される。

【００７６】ページ状態が「ホット」である（すなわち
最後の書き込み時刻Ｔ１から，まだ制限時間Ｔが経って
いない）から，インバリデート・メッセージは通知され
ない。すなわち，この時点では計算機１Ａ，１Ｂ，１Ｃ
上にページ１の複製が作成されているため，従来のライ
ト・インバリデーション・プロトコルによれば，インバ
リデート・メッセージの通知によるページ１の無効化が
必要となるが，本方式では，このインバリデート・メッ
セージを省き，メッセージ数を削減することができる。
このことが，本発明の特徴となる点である。

【００７７】図１５は，計算機１Ｂからの書き込みが終
了した状態を示している。「計算機Ｂから書き込み」を
行っていたアプリケーションのトランザクションが終了
すると，その通知は計算機１Ａと１Ｂのそれぞれのロッ
ク制御部１４Ａ，１４Ｂに送られる。その結果，計算機
１Ａ，１Ｂのページロックテーブル１７Ａ，１７Ｂのペ
ージ１の欄には，ページの状態が「ホット」のままであ
ること，および書き込み時刻「Ｔ３」が記録される。同
時にデータベース領域１６Ｂのページ１の内容がデータ
ベース領域１６Ａに送られる。

【００７８】以上の処理は，最初の書き込みと同様の処
理である。図１６は，図１５の状態に続いて，計算機１
Ｃから読み込みがあったときの状態を示している。

【００７９】最後に，計算機１Ｃ上のあるアプリケーシ
ョンプログラム（プロセス番号＝４００）が，ページ１
から読み出しを行ったものとする（このときの時刻をＴ
４とする）。そうすると，計算機１Ａのページロックテ
ーブル１７Ａのページ１の欄に，「アプリケーションサ
イトＣのプロセス４００が時刻Ｔ４に読み出しを行っ
た」ことが記録される。計算機１Ｃのページロックテー
ブル１７Ｃには，時刻Ｔ４が記録される。このとき，ペ
ージロックテーブル１７Ｃの以前の内容「Ｔ２」とペー
ジロックテーブル１７Ａの「Ｔ３」の比較が行われ，こ
の場合，Ｔ２＜Ｔ３であるから，データベース領域１６
Ｃのページ１に残っているページ１の複製は有効ではな
いことが分かる。そこで，データベース領域１６Ａのペ
ージ１の内容が新たにデータベース領域１６Ｃに送られ
る。

【００８０】以上の処理は，最初の読み出しの場合と同
様である。以上，ページの状態が「ホット」のままであ
る例について説明したが，書き込みが行われてから一定
時間Ｔが経過すると，そのページ状態は通常のバリッド
状態となり，次の書き込みでは，ライト・インバリデー
ション・プロトコルにより，インバリデート・メッセー
ジの通知が行われる。

【００８１】

【発明の効果】以上説明したように，本発明によれば，
計算機網をあたかも一つの並列計算機であるかのように
見立てて分散データベース管理システムを構築するよう
な場合に，Strong Consistencyの利点であるユーザにと
ってのアプリケーション開発のしやすさをそのままに，
より高い性能を発揮することができるようになる。

【００８２】本発明の方式は，読み出しにおけるメッセ
ージ通信コストと，書き込みにおけるメッセージ通信コ
ストのバランスを保つことで，書き込みの多いアプリケ
ーションが多く存在する場合にも，効率よく動作する。

【図面の簡単な説明】

【図１】本発明の概要説明図である。

【図２】ライト・インバリデーション・プロトコルにお
けるリード時の処理を説明する図である。

【図３】ライト・インバリデーション・プロトコルにお
けるライト時の処理を説明する図である。

【図４】イーブン・コスト・プロトコルにおけるライト
時の処理を説明する図である。

【図５】リード時におけるアプリケーションサイトでの
処理を説明する図である。

【図６】ライト時におけるアプリケーションサイトでの
処理を説明する図である。

【図７】リード時におけるデータベースサイトでの処理
を説明する図である。

【図８】本発明の実施例に係るシステム構成の例を示す
図である。

【図９】本発明の実施例に係る計算機の詳細ブロック図
である。

【図１０】図８に示すシステムの動作説明図である。

【図１１】図８に示すシステムの動作説明図である。

【図１２】図８に示すシステムの動作説明図である。

【図１３】図８に示すシステムの動作説明図である。

【図１４】図８に示すシステムの動作説明図である。

【図１５】図８に示すシステムの動作説明図である。

【図１６】図８に示すシステムの動作説明図である。

【図１７】一般的な従来の計算機網を示す図である。

【図１８】図１７に示すシステムでのデータベースへの
アクセス説明図である。

【符号の説明】

１，１’ 計算機 ２，２’ 分散共有仮想メモリ管理部 ３，３’ 分散共有仮想メモリ ４ ネットワーク ５ インバリッド状態 ６ バリッド状態 ７ 更新ホットスポット状態

Claims (4)

【特許請求の範囲】
1. 【請求項１】 複数の計算機がネットワークを介して仮
   想的にメモリを共有するシステムにおける分散共有メモ
   リ一貫性最適制御方法であって，各計算機が保持する分
   散共有メモリのデータを，そのデータを利用したアプリ
   ケーションまたは一連のアクセス処理の終了後も残し，
   そのデータに対するライト時に他の同じデータを持つ計
   算機に対してそのデータの無効を通知するライト・イン
   バリデーション・プロトコルによって，データの一貫性
   を保証する過程と，各計算機が保持する分散共有メモリ
   のデータを，そのデータを利用したアプリケーションま
   たは一連のアクセス処理の終了後も残し，そのデータに
   対する再度の処理時にそのデータの有効性を確認するイ
   ーブン・コスト・プロトコルによって，データの一貫性
   を保証する過程と，前記ライト・インバリデーション・
   プロトコルおよび前記イーブン・コスト・プロトコル
   を，データへのアクセス状況によって動的に切り換える
   過程とを有することを特徴とする分散共有メモリ一貫性
   最適制御方法。
2. 【請求項２】 請求項１記載の分散共有メモリ一貫性最
   適制御方法において，前記プロトコルを切り換える過程
   では，アクセス要求のあったデータが最後にライトされ
   てから所定の時間が経過するまでのアクセスに対しては
   前記イーブン・コスト・プロトコルを選択し，所定の時
   間が経過した後のアクセスに対しては前記ライト・イン
   バリデーション・プロトコルを選択することを特徴とす
   る分散共有メモリ一貫性最適制御方法。
3. 【請求項３】 請求項１記載の分散共有メモリ一貫性最
   適制御方法において，前記プロトコルを切り換える過程
   では，所定の期間内においてライトのアクセス頻度の多
   いデータについて前記イーブン・コスト・プロトコルを
   選択し，ライトのアクセス頻度の少ないデータについて
   前記ライト・インバリデーション・プロトコルを選択す
   ることを特徴とする分散共有メモリ一貫性最適制御方
   法。
4. 【請求項４】 複数の計算機がネットワークを介して仮
   想的にメモリを共有するシステムにおける分散共有メモ
   リ一貫性最適制御方法であって，分散共有メモリのデー
   タが無効であることを示すインバリッド状態と，有効で
   あることを示すバリッド状態と，所定の時間内にライト
   されたことを示す更新ホットスポット状態間の状態遷移
   を管理する手段を持ち，前記インバリッド状態および前
   記バリッド状態において，データにライトがあったとき
   に，そのデータを前記更新ホットスポット状態に遷移さ
   せ，前記インバリッド状態におけるデータのリードによ
   り元のデータの複製を持つとき，および前記更新ホット
   スポット状態において所定の時間が経過したときに，そ
   のデータをバリッド状態に遷移させ，前記バリッド状態
   においてそのデータが無効であることを通知するインバ
   リデート・メッセージが到着したとき，および前記更新
   ホットスポット状態においてアプリケーションまたは一
   連のアクセス処理が終了したときに，そのデータをイン
   バリッド状態に遷移させ，前記バリッド状態のデータに
   対しては，データへのライト時に他の同じデータを持つ
   計算機に対してそのデータの無効を通知するライト・イ
   ンバリデーション・プロトコルによってデータの一貫性
   を保証し，前記更新ホットスポット状態のデータに対し
   ては，データへのリードまたはライト時に，そのデータ
   を管理する計算機に対して，データの複製の有効性を確
   認するイーブン・コスト・プロトコルによってデータの
   一貫性を保証することを特徴とする分散共有メモリ一貫
   性最適制御方法。