分散データベースシステムにおける”透過性”

分散データベースシステムにおける”透過性”について、頭に入れておいた方が良い。ポイントは、データベースは分散していても、利用者(アプリケーション)から見ると、1つのデータベースのように見えることです。データベースを分散する目的は、負荷を分散させてパフォーマンスを上げること、又は、地理的に2箇所に分散させて災害に備えることです。

それでは早速、言葉の問題。まずは、分散データベースシステムの透過性についての言葉です。

移動に対する透過性
データの格納サイトが変更されても、ユーザーのアプリケーションや操作法に影響がないこと

複製に対する透過性
同一のデータが複数のサイトに格納されていても、ユーザーはそれを意職せずに利用できること

分割に対する透過性
1つの表が複数のサイトに分割されて格納されていても、ユーザーはそれを意識せずに利用できること

位置に対する透過性
ユーザーがデータベースの位置を意識せずに利用できること

アクセスに対する透過性
データベースの物理的な位置に関係なく同じ操作方法でアクセスできること

障害に対する透過性
あるサイトで障害が発生しても代わりのサイトがカバーしてシステムが停止しないようにすること

データモデルに対する透過性
データモデルがリレーショナルモデルや階層モデル、ネットワークモデルなど、サイトごとに異なる場合でも利用者は意識せずに利用できること

規模に対する透過性
OSやアプリケーションに影響を与えることなく、規模を拡張できること

言葉だけでなく、ここに書いてあることが、分散データベースでは実現できることがわかりますね。分散データベースのコミットには問題があります。まあ、ややこしい話になりそうなので、それだけでも問題です(><)

分散データベースでは、分散したすべてのサイトに対してコミットを行い、すべてのサイトのコミットが終わって、コミット完了になります。1つのサイトでコミットできない場合、すべてのサイトでロールバックを行わなければなりません。

とはいっても、利用者はこんなことをまったく意識をする必要はありません。分散データベースの分散透過性ですね!サイト同士をつなげるのは、ネットワークです。もしトランザクション内でネットワーク障害があったらどうなるでしょう。いやな予感しまくりですね。当然、データベースとしても障害が起こります。

どんな障害でしょう?

まずは分散データベースシステムにおけるトランザクションを図化してみましょう。Aをローカルサイト、B,Cをリモートサイトとしましょう。

(1) A→B,C トランザクション開始要求
(2) A→B,C クエリ
(3) A←B,C クエリ結果
(4) A→B,C コミット準備要求
(5) A←B,C コミット可否応答
(6) A→B,C コミットorロールバック指示
(7) A←B,C コミットorロールバック実行結果応答

ってな感じです。

(4)ですべてのサイトにコミットできるか聞き、できるならばすべてのサイトにコミットを要求します。このとき、何らかの障害により、コミット可否の返答がこない場合、コミットしていいのかロールバックすべきなのか、判断がつかなくなります。つまり、(4)~(6)の間に何らかの問題があると、非常にまずいということです。

このような、コミットすべきか、ロールバックすべきか判断つかない状態を、ブロック状態といいます。分散データベースで、表のレコードを分散させるとき、どうやって分散させるか。その方法について、以下の3つがよく出題されます。

キーレンジ分割
ある特定のキーの値の範囲ごとに格納先を決めます。例えば年齢が30歳まではA、31~60歳はB、61歳以上はCって感じです。
メリット:どこに格納されているか1発でわかるので管理しやすい。
デメリット:格納先ごとにデータ数を均等になるように設計するのが難しい

ハッシュ分割
特定のキーに対してハッシュ関数を用いて格納先を決める。
メリット:格納先がわかるので管理しやすい上に、ある程度データ数が均等になる。
デメリット:データが偏る可能性もある。またハッシュ関数がパフォーマンスダウンにつながる。

ラウンドロビン分割
レコード発生ごとに、格納先を変える。
メリット:レコード数が均等になる。
デメリット:格納先がわからないので、検索時は全ての格納先から検索を行う。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です