bech分散データベースシステムにおける”透過性”分散データベースシステムにおける”透過性”について、頭に入れておいた方が良い。ポイントは、データベースは分散していても、利用者(アプリケーション)から見ると、1つのデータベースのように見えることです。データベースを分散する目的は、負荷を分散させてパフォーマンスを上げること、又は、地理的に2箇所に分散させて災害に備えることです。それでは早速、言葉の問題。分散データベースシステムの透過性についての言葉です。同一のデータが複数のサイトに格納されていても、ユーザーはそれを意職せずに利用できること分割に対する透過性1つの表が複数のサイトに分割されて格納されていても、ユーザーはそれを意識せずに利用できること位置に対する透過性ユーザーがデータベースの位置を意識せずに利用できることアクセスに対する透過性データベースの物理的な位置に関係なく同じ操作方法でアクセスできること障害に対する透過性あるサイトで障害が発生しても代わりのサイトがカバーしてシステムが停止しないようにすることデータモデルに対する透過性データモデルがリレーショナルモデルや階層モデル、ネットワークモデルなど、サイトごとに異なる場合でも利用者は意識せずに利用できること規模に対する透過性OSやアプリケーションに影響を与えることなく、規模を拡張できること言葉だけでなく、ここに書いてあることが、分散データベースでは実現できることがわかりますね。分散データベースのコミットには問題があります。ややこしい話になりそうなので、それだけでも問題です(><)分散データベースでは、分散したすべてのサイトに対してコミットを行い、すべてのサイトのコミットが終わって、コミット完了になります。1つのサイトでコミットできない場合、すべてのサイトでロールバックを行わなければなりません。いっても、利用者はこんなことをまったく意識をする必要はありません。分散データベースの分散透過性ですね!サイト同士をつなげるのは、ネットワークです。トランザクション内でネットワーク障害があったらどうなるでしょう。いやな予感しまくりですね。データベースとしても障害が起こります。どんな障害でしょう?まずは分散データベースシステムにおけるトランザクションを図化してみましょう。Aをローカルサイト、B,Cをリモートサイトとしましょう。コミットorロールバック実行結果応答ってな感じです。(4)ですべてのサイトにコミットできるか聞き、できるならばすべてのサイトにコミットを要求します。このとき、何らかの障害により、コミット可否の返答がこない場合、コミットしていいのかロールバックすべきなのか、判断がつかなくなります。(4)~(6)の間に何らかの問題があると、非常にまずいということです。このような、コミットすべきか、ロールバックすべきか判断つかない状態を、ブロック状態といいます。分散データベースで、表のレコードを分散させるとき、どうやって分散させるか。その方法について、以下の3つがよく出題されます。キーレンジ分割ある特定のキーの値の範囲ごとに格納先を決めます。年齢が30歳まではA、31~60歳はB、61歳以上はCって感じです。メリット:どこに格納されているか1発でわかるので管理しやすい。特定のキーに対してハッシュ関数を用いて格納先を決める。メリット:格納先がわかるので管理しやすい上に、ある程度データ数が均等になる。デメリット:データが偏る可能性もある。ハッシュ関数がパフォーマンスダウンにつながる。ラウンドロビン分割レコード発生ごとに、格納先を変える。メリット:レコード数が均等になる。デメリット:格納先がわからないので、検索時は全ての格納先から検索を行う。コメントをキャンセルメールアドレスが公開されることはありません。