chapter 21 distributed database l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 21 Distributed Database PowerPoint Presentation
Download Presentation
Chapter 21 Distributed Database

Loading in 2 Seconds...

play fullscreen
1 / 74

Chapter 21 Distributed Database - PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on

Chapter 21 Distributed Database. 2004/5/13 junko. 1.Introduction . 「分散データベースを完全にサポートする」 アプリケーションが透過的に実行可能であるべき 透過性・・・すべてのデータが単一マシン上の単一 DBMS により管理されているかのようにアプリケーションが動作する. データが データベースにわたろうが DBMS により管理されようが 様々に異なる マシン上で実行されていようが オペレーションシステムにより支援されていようが 通信ネットワークにより相互結合されていようが.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Chapter 21 Distributed Database


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
1 introduction
1.Introduction
  • 「分散データベースを完全にサポートする」
  • アプリケーションが透過的に実行可能であるべき
    • 透過性・・・すべてのデータが単一マシン上の単一DBMSにより管理されているかのようにアプリケーションが動作する

データが

データベースにわたろうが

DBMSにより管理されようが

様々に異なる マシン上で実行されていようが

オペレーションシステムにより支援されていようが

通信ネットワークにより相互結合されていようが

introduction
1.Introduction
  • 厳密には分散データベースが何であるのか
  • なぜ分散データベースが重要なのか
  • 分散データベースの技術的問題
  • クライアント/サーバシステムについて
some preliminaries
2. SOME PRELIMINARIES
  • 分散データベースとは・・・ (実用的な定義)
    • 各サイトはそれ自身がデータベースシステムサイト
    • 他のサイトにいるユーザが、まるで全てのデータがユーザ自身のサイトに蓄えているかのように得ネットワーク中のどのデータもアクセスできるように動作しあう

相互結合されたサイトの集まりから構成される

(通信ネットワークのようなもの)

slide6
分散データベースの目的

ローカルな

「実」データベース

ユーザ

DBMS

トランザクション管理ソフトウェア

データ通信管理

分散システムに

参加していないかのように

データ操作を実行できる

slide7
分散データベース・システム
  • 分散データベース・システムは、個々のローカルサイトにある個々のローカルDBMS間の協力と考えられる
  • 構成されるサイトは「論理的」だけでなく、「物理的(地理的)」にも分散配置されていると仮定されている
    • 地理的とは言っても・・・

「サイト」を同じ建物に置いてLAN程度で結合

→地理的には一緒

データベースの視点から見れば違いはない

ローカルな分散も分散配置とみなす

strict homogeneity assumption
Strict homogeneity assumption(強い均質性の仮定)

  システムが各サイトで同じDBMSの複製を使っているという意味で均一であると仮定

少々強すぎる

本当に必要なのは異なるサイトにある

DBMSインスタンスが

同じインターフェースをサポートすること

(同じDBMSソフトウェアの複写である必要はない)

advantages disadvantages
Advantages (& disadvantages)
  • 分散システムの利点

データベースの構造に企業の構造を映すことができる

    • 企業は、 論理的-(部門、部署、室)      に分かれている

          物理的-(工場、研究所、事業部)

→ローカルのデータはローカルに保持され、

リモートのデータは必要に応じてアクセスされればよい

  • 欠点

技術的な視点から見て複雑(実装者の問題)

    • 複雑性はユーザには見えないようにすることが重要

※付加的利点は後半で・・・

sample system
Sample Systems
  • Prototypes
    • SDD-1

(1970後-1980後、Computer Corporation of America研究所)

    • R*

(1980前、IBM研究所、システムRプロトタイプ分散バージョン)

    • Distributed Ingres

(1980前、カリフォルニア大学バークレー校、Ingresプロトタイプ分散バージョン)

  • SQL products
    • Ingres/Star
    • Oracleの分散データベースオプション
    • DB2の分散データ機能
a fundamental principle
A Fundamental Principle

  ユーザにとって、分散システムは完全に

非分散であるかのように見えるべき!!

  分散システムのユーザが分散ではないかのように振舞うべき!!

※ユーザ: エンド・ユーザ

       アプリケーション・プログラマ

12の目標

distributed database remote data access
Distributed database & remote data access
  • Remote data access system
    • ユーザはリモート・サイトのデータを操作することができるかもしれない
    • 複数のリモートサイトのデータを同様に操作できるかもしれない
    • 継ぎ目が見える
  • Distributed database
    • 継ぎ目は隠されている
the twelve objectives
3.THE TWELVEOBJECTIVES
  • ローカル自律性
  • 中央のサイトに頼らない
  • 継続的な動作
  • 位置独立性
  • 断片化独立性
  • 複製独立性
  • 分散問い合わせ処理
  • 分散トランザクション管理
  • ハードウェア独立性
  • オペレーティングシステム独立性
  • ネットワーク独立性
  • DBMS独立性
local autonomy
①Local Autonomy

分散システムのサイトは、自律的であるべきである

  • ローカル自律性:あるサイトでのすべての操作がそのサイトで制御される
  • ローカルの責任においてローカルデータがローカルに保存管理される
  • 安全性、完全性、ローカルデータの保存表現などは、ローカルサイトの管轄であり制御下のまま
slide15
しかし・・・
  • ローカル自律性という目標は完全には達成しえない
  • サイトXが他のサイトYへある程度の制御を委ねなければならない状況が数多く存在する
    • Reference[21.13]

サイトは可能な限り最大限に自律的であるべきである

目標を正確に言うと・・・

reference 21 13
Reference[21.13]
  • Local Autonomyを妥協する必要がある状況
    • 断片化された関係の個々の断片は、それらが記憶されているサイトからのみ直接アクセス可
    • 複製された関係の個々の複写は、それらが記憶されているサイトからのみアクセス可
    • 更新アクセスは、それが記憶されているLocalなサイトにおいては不可
    • 2相コミットの処理の参加者として動作しているサイトは、対応する調停サイトの決定に従わなければならない
no reliance on a central site
②No Reliance on a Central Site
  • ローカル自律性

 すべてのシステムが中央のサイトに依存しないように中央の「マスタ」サイトに頼ってはならない

  • ローカル自律性が達成されなくても本来望ましいこと
  • 中央のサイトに頼らない理由
    • 中央のサイトがボトルネックになる可能性
    • システムが弱点を持つ可能性

(中央サイトのダウンによってすべてのシステムがダウンしてしまう)

すべてのサイトが等しく扱われなければならない

※1の目標から導き出され、追従する

c ontinuous operation
③Continuous Operation

  分散システムの利点は、より多くの信頼性と可用性を提供できることである

  • 信頼性(reliability):システムがある瞬間に稼動している確率
    • 個々のサイトの要素が失敗していても機能し続けることができるため信頼性が向上する
  • 可用性(availability):システムがある期間継続的に稼動している 確率
    • データの複製の可能性から(21.6参照)可用性が向上する
  • システムは決して停止されるよう要求されるべきではない
    • 計画されていない停止(失敗)は明らかに望まざること
    • 計画されている停止(EX.新規サイト追加、DBMSレベルアップ)も決して必要とされるべきではない
location independence
④Location Independence(位置独立性)

  ユーザはデータが物理的にどこへ記憶されているかを知る必要はない

  データがユーザのローカルサイトに記憶されているかのように振舞えるべき

  • ユーザのプログラムや端末の活動をなんら無効にすることなく、データをサイトからサイトへ移動可能

※「~独立性」:データ独立性の概念を分散の場合に適合するように拡張したもの

fragmentation independence
⑤Fragmentation Independence(断片化独立性)
  • 記憶関係が物理的な記憶領域のために細分化または「断片化」できるなら、システムはデータの断片化をサポートしている
  • 水平断片化:restrictionによって断片化
  • 垂直断片化:projectionによって断片化
  • 断片・・・restrictionやprojectionによって導出される任意の部分関係
    • Orthogonal(chapter13)
    • Nonloss(chapter12-13
slide21
断片化の例

ユーザへの

見え方

EMP# DEPT# SALARY

E1 D1 40K

E2 D1 42K

E3 D2 30K

E4 D2 35K

E5 D3 48K

水平断片化

New York

London

N_EMP

L_EMP

EMP# DEPT# SALARY

E1 D1 40K

E2 D1 42K

E5 D3 48K

EMP# DEPT# SALARY

E3 D2 30K

E4 D2 45K

DEPT# = D1, D3

DEPT# = D2

slide22
データの断片化をサポートするシステムは、断片化の独立性もサポートするべきであるデータの断片化をサポートするシステムは、断片化の独立性もサポートするべきである
  • ユーザはデータが全く断片化されていないかのように振る舞うことができるべきである
  • 断片化の独立性はユーザのプログラムや端末の活動を無効にすることなく性能要求の変化に応じてデータをいつでも再断片化することが許される
slide23
断片化の独立性は、断片が適切な結合と和によって論理的に組み合わされたデータのビューがユーザに提供されることを意味する断片化の独立性は、断片が適切な結合と和によって論理的に組み合わされたデータのビューがユーザに提供されることを意味する
  • ユーザの要求を満足するためにどの断片を物理的にアクセスする必要があるのかを決定するのはシステムオプティマイザの責任
slide24
オプティマイザによる要求の変換

[EMP WHERE SALARY > 40K AND DEPT# = ‘D1’]

EMP =N_EMP UNION L_EMP

(N_EMP UNION L_EMP) WHERE SALARY > 40K AND DEPT# = ‘D1’

(N_EMP ) WHERE SALARY > 40K AND DEPT# = ‘D1’

UNION

(L_EMP) WHERE SALARY > 40K AND DEPT# = ‘D1’

N_EMP WHERE SALARY > 40K AND DEPT# = ‘D1’

slide25
オプティマイザの決定

ユーザへの

見え方

EMP# DEPT# SALARY

E1 D1 40K

E2 D1 42K

E3 D2 30K

E4 D2 35K

E5 D3 48K

オプティマイザが

「ニューヨークのサイトだけを

アクセスする必要がある」

と決定!

New York

London

N_EMP

L_EMP

EMP# DEPT# SALARY

E1 D1 40K

E2 D1 42K

E5 D3 48K

EMP# DEPT# SALARY

E3 D2 30K

E4 D2 45K

replication independence
⑥Replication Independence(複製独立性)
  • 断片が多くの個別サイトに記憶されている多くの個別の複写または複製によって表現できるとき、システムは複製をサポートしている
  • データの複製をサポートするシステムは、複製独立をもサポートするべきである
  • ユーザはデータが実際には全く複製されていないかのように振舞えることができるべきである
  • ユーザのプログラムの端末操作を無効にすることなく、いつでも複製を作ったり消したりすることができる
slide27
複製の例

REPLICATE N_EMP

LN_EMP AT SITE ‘London’ ;

REPLICATE L_EMP

NL_EMP AT SITE ‘New York’ ;

New York

London

N_EMP

L_EMP

EMP#DEPT# SALARY

E1 D1 40K

E2 D1 42K

E5 D3 48K

EMP#DEPT# SALARY

E3 D2 30K

E4 D1 35K

EMP#DEPT# SALARY

E1 D1 40K

E2 D1 42K

E5 D3 48K

EMP#DEPT# SALARY

E3 D2 30K

E4 D1 35K

NL_EMP(L_EMPの複製)

LN_EMP(N_EMPの複製)

slide28
複製の利点と欠点
  • 利点
    • よい性能を生み出すことができる
      • 遠隔のサイトと通信することなくローカルの複写で動作できる
    • 可用性も向上することができる
      • ひとつの複写が使用可能であればずっと処理が可能であり続ける
  • 欠点
    • 複製されたオブジェクトが更新されたとき、すべての複写が更新されなければならない

更新伝搬問題(update propagation)

slide29
複製独立性
  • 与えられたユーザの要求を満足するためにどの複製を物理的にアクセスする必要があるのかを決めるのは、システムオプティマイザの責任である(断片化独立性と同様)
  • 多くの商用製品が完全な複製独立性を含んではいない複製のサポート形態を提供している
distributed query processing
⑦Distributed Query Processing

「ロンドンにいる赤い部品の納入業者を得よ」

Ans. N社の納入業者

レコード単位型

関係型

・ニューヨークからロンドンへ要求を送信

・ニューヨークからロンドンへ「次の」納入業者を要求

×n

・ロンドンからニューヨークへn組の結果を返信

ロンドンからニューヨークへ「次の」納入業者を返信

2個のメッセージ

2n個のメッセージ

関係型システムが非関係型よりも優れている

distributed query processing31
Distributed Query Processing
  • 最適化は集中システム内に比べて分散システム内の方がより重要である
    • 複数のサイトを巻き込むような問い合わせでは、効果的な戦略を見つけることが極めて重要
  • 次節の例で詳しく説明
distributed transaction management
⑧Distributed Transaction Management
  • トランザクションは複数のエージェントから構成される
    • 「エージェント」・・・サイトで与えられたトランザクションのために処理を実行するもの
  • Recovery:システムはそのトランザクションのためのエージェントの組が全て一斉にコミットするか、ロールバックすることを保証しなければならない

→2相コミット・プロトコル

  • Concurrency:非分散システムと同じロックに基づいている
hardware independence
⑨Hardware Independence
  • 実世界のコンピュータ実装は多数の異なるマシン

  同じDBMSが異なるハードウェア・プラットフォーム上で実行可能

  それらの異なるマシンが全て等しい仲間として分散システムに参加できることが望ましい

IBMの機械、DECの機械、HPの機械、多機種のPCやワークステーション

システム全てのデータが統合

ユーザに「単一システム」のイメージで提供

operating system independence
⑩Operating System Independence
  • 異なるハードウェアプラットフォーム上で同じDBMSが実行できるならば・・・

  異なるオペレーティング・システム上でも実行可能であることは必然的

  • MVS版とUNIX版とPC/DOS版の全てが同じ分散システムに参加できることが明らかに望ましい
network independence
⑪NetworkIndependence
  • システムが異なるハードウェアと異なるオペレーティングシステムを持つ多くの異種サイトをサポートできるのであれば・・・

  様々な異なる通信ネットワークもサポートできることが望ましい

dbms independence
⑫DBMSIndependence
  • 異なるサイトにあるDBMSインスタンスが同じインターフェースをサポートするだけのこと
    • (例)INGRESとORACLEが正式のSQL標準をサポート 

→ INGRESのサイトとORACLEのサイトが分散システム

  • 分散システムはある程度は非均質でもかまわない
  • 詳しくは21.5節で・・・
slide37
主要な問題点

主要な目標

21.4 分散システムの問題点

通信ネットワークが遅い

ネットワークの使用率を減少

メッセージの数と大きさを減らす

  • 問い合わせ処理
  • カタログ管理
  • 更新伝播
  • リカバリ制御
  • 並行制御

従属領域に問題発生

slide38
問い合わせ処理

ネットワークの使用率を減少させる

問い合わせ実行処理、問い合わせの最適化処理も分散させる必要

サイトX

問い合わせQ

「サイトYの関係Ry とサイトZの関係Rzとの和を算出」

Xのオプティマイザ   → “RyをZへ移動”

全体の最適化段階

サイトY

100組の関係Ry

サイトZ

100万組の関係Rz

Zのオプティマイザが

Z特有の戦略を決定

局所最適化段階

slide39
問い合わせ処理の例
  • データベース(納入業者と部品)
    • S{S#, CITY} ー1000組がサイトAに記憶
    • P{P#, COLOR} ー100,000組がサイトAに記憶
    • SP{S#, P#}  ー1,000,000組がサイトBに記憶
  • 記憶されている全ての組は25byte(200bit)
  • 問い合わせ-「ロンドンにいる赤い部品の納入者の納入者番号」
  • 中間結果の見積もり基数
    • 赤い部品の数 =10
    • ロンドンの納入業者の出荷量 =100,000
  • 通信の仮定
    • データ速度 =50,000ビット/秒
    • アクセス遅延 =0.1秒
slide40
問い合わせ処理の手法
  • 六つの手法について総通信時間T[i]を計算

T[i] = 総アクセス遅延+(総データ量/データ速度)

=(メッセージ数/10)+(ビット数/50000)

1.PをサイトAに移動してAで問い合わせを処理する

T[i]=0.1+(100000*200)/50000

= 約400秒(6.67分)

  • 以降も同様に計算
slide41
分散問い合わせ処理の戦略
  • 手法            技術内容         通信時間 
  • PをAへ移動   6.67分
  • SとSPをBへ移動   1.12時間
  •    各ロンドンの出荷について 5.56時間
  •      部品が赤いか検査            
  • 4.   各赤い部品について 2.00秒
  •      ロンドンに納入業者がいるか検査
  • 5.   ロンドンの出荷をBへ移動        6.67分
  • 赤い部品をAへ移動            0.1秒(最速)
slide42
カタログ管理
  • システムカタログは望ましい場所や断片化、複製の独立性をシステムに提供するために必要な制御情報も含んでいる
    • 関係やビュー、索引、ユーザなどに関するカタログデータも含む
  • では、カタログ自身はどこにどのように記憶されるべきか・・・?

1.集中化:全体のカタログを単一中央サイトに記憶

2.完全複製:全体のカタログを全てのサイトに記憶

3.区分化:各サイトが自分のカタログを保守

4.1と3の組み合わせ:

slide43
各アプローチの問題点
  • 1.集中化:明らかに「中央のサイトに頼らない」という目標を侵害
  • 2.完全複製:自律性を侵害
  • 3.区分化:局所的でない操作のコスト大
  • 4.1と3の組み合わせ:3よりも効果的だが、1と同じ問題発生

システムはどのアプローチも採用していない

slide44
R*のアプローチ
  • R*のオブジェクト名
    • ユーザに知られている名前とそれらに対応するシステムが知っている名前との対応付けを意味するもの
    • オブジェクトの印字名
      • ユーザによって通常参照される名前
    • システムの広域名
      • 一意なオブジェクトの内部識別子

(例)MARILYN @ NEWYORK . STATS @ LONDON

  • 印字名はシステム広域名「局所名」の部分かシノニムで構成される

作成者ID

作成サイID

局所名

誕生サイトID

creatme synonm
CREATME SYNONM
  • R*独自のSQL文
  • ユーザは以下のどちらも使用可
    • 局所名を利用

SELECT ... FROM STATS ... ;

    • シノニムを利用

SELECT ... FROM MSTATS ... ;

CREATE SYNONYM MSTATS FOR MARILYN @ NEWYORK . STATS @ LONDON

slide46
局所名を利用したアプローチ
  • システムは全ての明らかなデフォルトを仮定してシステム広域名を推論する
  • システムRのアプリケーションが何の変更もなくR*で走る
slide47
シノニムを利用した場合
  • システムは適切なシノニムテーブルに問い合わせることによってシステム広域名を決定
  • シノニムテーブルはカタログの最初の要素
  • 各サイトはシノニムテーブルを保守
  • 各サイトは以下も保守
    • そのサイトで誕生した全てのオブジェクトのカタログエントリ
    • そのサイトで現在記憶されている全てのオブジェクトのカタログエントリ
slide48

シノニムMSTATSへの参照を要求

シノニムテーブル中から対応するシステム広域名を調べる

MARILYN @ NEWYORK . STATS @ LONDON

誕生サイト

ロンドン

オブジェクトが

ロンドンにあった!

カタログエントリ

「オブジェクトはロサンゼルスへ移動しました」

ロサンジェルス

サンフランシスコ

「サンフランシスコへ・・・」

slide49
更新伝搬
  • データの複製に伴う基本的な問題

   オブジェクトの更新を全ての記憶複写に      

   伝搬させなければならない

  全ての複写を直ちに更新する

共通の機能が

導かれる

→主複写機能

複写の一つが使用不可能の場合の更新は

失敗する

slide50
主複写機能
  • 複製されたオブジェクトの一つは主複写と指定され、残りは第2複写
  • 異なるオブジェクトの主複写は異なるサイトにある
  • 更新操作は主複写が更新されると論理的には完了したと判断し、その複写を保持するサイトは更新を第2複写に伝搬する責任がある(COMMIT以前に)
observations on the delayed propagation approach
Observations on the delayed propagation approach

1.遅延更新伝搬によるシステムの複製の概念はスナップショット(Chapter10)の考え方の限定されたアプリケーション

2.遅延伝搬は悪い考えではない

3.「複製vs2相コミット」のような不可解を推し進める(完全に異なるものの二つの利点を比較)

→COMMIT以前に複製を更新

→サイトがCOMMIT時に稼動している必要

  →性能的に重くなる

recovery
Recovery
  • 分散システムにおけるRecoveryは2相コミットプロトコルに基づくのが一般的
  • 各サイトがトランザクションに対する調整サイトとして、他のトランザクションへの参加サイトとして振舞うことができなければならない
  • 2相コミットプロセスは全ての参加サイトと通信するための調整者を必要とする
  • サイトYがサイトXにより調整されている2相コミットプロセスへの参加者として動作するとき、サイトYはサイトXの指示(COMMITやROLLBACK)に従う
recovery53
Recovery
  • 予想しうるどんな種類の失敗もリカバリ処理が可能であることが望ましい
    • 完了したトランザクションを調和してコミットしたり、失敗したものを調和してロールバックしたり、任意の失敗に対応できるような有限プロトコルは存在しない
    • そのようなプロトコルが存在したとすると・・・
      • N:プロトコルに必要な最低限のメッセージの数
      • 最後のNメッセージが失敗により失われる

それらのメッセージが必要ではなかったか

プロトコルが動かなくなる

解決不可能

そのようなプロトコルは存在しない

recovery54
Recovery
  • 2相プロトコル(13章)は基本的なプロトコル
  • しかし、実際に採用するには改良が必要
  • presumed commit
    • トランザクションが失敗→付加的なメッセージ発生

     トランザクションが正常に終了した場合の

     メッセージ数を削減

  • presumed rollback
concurrency
Concurrency
  • 分散システムの並行制御はロックを基礎とする
  • ロックのテスト、セット、リリース要求はメッセージ

トランザクションT

n個の遠隔サイトに複製が存在するオブジェクトの更新を要求

5nのメッセージ

・ロック要求

・ロック許可

・更新メッセージ

・承認

・ロック解放

更新のための合計時間は

集中システムでのよりも

数倍大きい

×n

slide56
問題に対するアプローチ
  • 「更新伝搬」の主複写手法を採用
  • オブジェクトRに対し、Rの主複写を持つサイトがRに関わる全てのロック操作を取り扱う

メッセージ総数

5n

2n+3

・ロック要求     

・ロック許可

・更新メッセージ   

・承認          

・ロック解放      

オブジェクトの全ての複写が

ロックの目的では一つのオブジェクトと考えることができる

×n

concurrency57
Concurrency
  • ロックにおけるもう一つの問題点

大域的なデッドロックを導く可能性

二つ以上のサイトを巻き込むデッドロック

SITEX

  • サイト内だけの情報を用いても検出不可能
  • ローカル待機グラフには循環は存在しない
  • →二つのローカルグラフを大域的な
  • 待機グラフに結合
  • 個々のローカルグラフを一緒にする必要
  • 更なる通信オーバーヘッドを招く

T1x

T2x

T1xがLxを解放するのを待機

T2xが完了するのを

待機

T2xが完了するのを

待機

T1y

T2y

T2yがLyを解放するのを待機

SITEY

5 client server systems
5.CLIENT/SERVER SYSTEMS
  • クライアント/サーバシステムは
    • 複数のサイトがクライアントで残りがサーバサイト
    • 全てのデータが全てのサーバサイトに格納
    • 全てのアプリケーションはクライアントサイトで動作
    • 「継ぎ目が見える」(位置独立性は達成されない)
  • 多大なる商用的な興味は示されているが、真の汎用分散システムには興味は示されていない
client server
「CLIENT/SERVER」
  • アーキテクチャや論理的な責任の分担
  • クライアント:アプリケーション(フロントエンド)
  • サーバ:DBMS(バックエンド)
  • システム全体がほぼ二つの部分に分割可能

二つが異なるマシン上で実行される可能性

「クライアント/サーバ」という言葉は

クライアントとサーバが実際に異なるマシン上に存在する

場合に用いる

slide60
例(2章と同様)
  • 複数のクライアントが同じサーバを共用をできるかもしれない
  • 単一のクライアントが複数のサーバをアクセスできるかもしれない
    • クライアントが一度に一つのサーバだけをアクセスするように制限される
    • クライアントは同時に複数のサーバをアクセスできる
      • 真の分散データベースシステム(継ぎ目が隠れている)
      • しかし、「クライアント/サーバ」という言葉が意味するものではない

この先はこの場合は無視する

client server standards
Client/server Standards
  • クライアント/サーバ処理の世界に適用できるいくつかの標準
    • SQL standard
      • クライアントサーバ機能は最近のSQL標準の中に組み込まれている(詳細は21.7節)
    • RDA (Remote Data Access)
    • DRDA (Distributed Relational Database Architecture)
rda remote data access
RDA (Remote Data Access)
  • RDAの趣旨:クライアント/サーバ接続のための形式とプロトコルを定義すること
    • クライアントがSQLの標準形でデータベース要求を表現
    • サーバは標準カタログをサポート
  • クライアントとサーバとの間で渡されるメッセージのための表現形式を指定する
    • メッセージ:SQL要求、データと結果、診断情報
drda distributed relational database architecture
DRDA (Distributed Relational Database Architecture)
  • IBMの分散関係データベースアーキテクチャー標準
  • RDAと目的は酷似
  • フォーマットとプロトコルはRDAと極めて異なる
    • RDA-国際的でベンダによらない標準に基づく
    • DRDAーIBM固有のアーキテクチャと標準に基づく

(IBMの素姓を反映する傾向)

client server application programming
Client/Server Application Programming
  • クライアント/サーバのアプローチは、アプリケーションプログラミングと密接な関係
  • アプリケーションプログラマは
    • アクセスメソッドのようにサーバを使ったり
    • レコードレベルのコードを記述しない
  • ストアドプロシージャによってメッセージ数減少
stored procedure
Storedprocedure
  • サーバサイトに記憶されているコンパイル済みプログラム
  • 遠隔手続き呼び出しによりクライアントから起動
  • レコードレベルの処理にまつわる性能劣化はある程度相殺される
  • Storedprocedureの利点
    • 高レベルのデータ独立性の提供
    • 多くのくライアンとで共有可能
    • 実行時ではなく、作成時に最適化を行う
    • 優れた機密性を提供
dbms independence66
6.DBMSINDEPENDENCE
  • 「12の目標」の最後ーDBMS独立性
  • 異なるサイトのDBMSが同じインターフェースをサポートすること
  • 例えば・・・

※この可能性をINGRESとORACLEに的を絞って議論を進める

INGRESとORACLEが公式のSQL標準をサポート

システムにおいて等しい協力者として振舞う

gateways
Gateways
  • 二つのサイトXとYでINGRESとORACLEが派していると仮定
  • 分散データベースはINGRES
  • 必要なサポートを提供する義務
  •   →ORACLEではなくINGRES

SYTE X

「サイトXのINGRESデータベース」と「サイトYのORACLEデータベース」からとのデータを含む分散データベースが見たい

INGRES

データベース

ゲートウェイ

「ORACLEをINGRESのように見せる」

効果を持つアプリケーションプログラム

slide68
ゲートウェイの機能
  • INGRESとORACLEの間で情報を交換するためのプロトコルを実装
  • ORACLEの「関係サーバ」機能を提供
  • ORACLEとINGRESのデータ型を対応付ける
  • INGRESのSQL方言をORACLEの方言に対応付ける
  • ORACLEの応答情報をINGRES形式へ対応付ける
slide69
ゲートウェイの機能
  • ORACLEのカタログをINGRESの形式へ対応付ける
    • INGRESのサイトやユーザがORACLEのデータベースが持っているものを見つけ出せるように
  • 2相コミットプロトコルへ参加できるようにする
  • INGRESがロックする必要のあるORACLEサイトのデータが、INGRESが望んだ形でのロックを保証する
sql facilities
7.SQLFACILITIES
  • SQLは真の分散データベースシステムのためのサポートを全く提供していない
  • クライアント/サーバ機能を含む
    • CONNECTとDISCONNECT
connect
CONNECT
  • データベース要求の発行前にCONNECT操作を実行
    • 接続達成 → 必要なデータベース処理がサーバで実行
  • 一つのサーバへ接続されたSQLクライアントに対し、他のサーバへ接続することも許す
  • 二つ目の接続が達成されると、最初の接続は休止状態となり、続くSQL要求は
    • 以前のサーバへ切り替える(SETCONNECTION)
    • 別のサーバへ接続 → 二つめの休止状態まで二つ目のサーバで処理
disconnect
DISCONNECT
  • クライアントにより達成された接続は、DISCONNECT操作により切断されなければいけない

  (CONNECTもDISCONNECTも暗黙的)

summary
8.SUMMARY
  • 分散データベースに対する「12の目標」
  • 問い合わせ処理、カタログ管理、更新伝搬、リカバリ制御、並行制御においての問題点考察
  • クライアント/サーバ・システム
  • Storedprocedure
  • 分散システムのためのデータベース設計は議論せず
    • 配置問題は有名な難問
  • 断片化と複製のサポートは更なる複雑な要因を生み出す
distributed independence
Distributed independence
  • 「12の目標」がコッドの関係型DBMSのための「分散独立性」規則と等価に思える

DBMSはアプリケーションプログラムと端末の動作とを論理的に損なわないようにできるようなデータ副言語を持つ

    • データの分散が最初に導入されるとき
    • データが再分散されるとき