1 / 74

Chapter 21 Distributed Database

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

spence
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 21Distributed Database 2004/5/13 junko

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

  3. １．Introduction • 厳密には分散データベースが何であるのか • なぜ分散データベースが重要なのか • 分散データベースの技術的問題 • クライアント／サーバシステムについて

  4. ２. SOME PRELIMINARIES • 分散データベースとは・・・　（実用的な定義） • 各サイトはそれ自身がデータベースシステムサイト • 他のサイトにいるユーザが、まるで全てのデータがユーザ自身のサイトに蓄えているかのように得ネットワーク中のどのデータもアクセスできるように動作しあう 相互結合されたサイトの集まりから構成される （通信ネットワークのようなもの）

  5. 通信ネットワーク

  6. 分散データベースの目的 ローカルな 「実」データベース ユーザ DBMS トランザクション管理ソフトウェア データ通信管理 分散システムに 参加していないかのように データ操作を実行できる

  7. 分散データベース・システム • 分散データベース・システムは、個々のローカルサイトにある個々のローカルDBMS間の協力と考えられる • 構成されるサイトは「論理的」だけでなく、「物理的（地理的）」にも分散配置されていると仮定されている • 地理的とは言っても・・・ 「サイト」を同じ建物に置いてLAN程度で結合 →地理的には一緒 データベースの視点から見れば違いはない ローカルな分散も分散配置とみなす

  8. Strict homogeneity assumption（強い均質性の仮定） 　　システムが各サイトで同じDBMSの複製を使っているという意味で均一であると仮定 少々強すぎる 本当に必要なのは異なるサイトにある DBMSインスタンスが 同じインターフェースをサポートすること （同じDBMSソフトウェアの複写である必要はない）

  9. Advantages (& disadvantages) • 分散システムの利点 データベースの構造に企業の構造を映すことができる • 企業は、　論理的－（部門、部署、室）　　　　　　に分かれている 　　 　　　　　 　物理的－（工場、研究所、事業部） →ローカルのデータはローカルに保持され、 リモートのデータは必要に応じてアクセスされればよい • 欠点 技術的な視点から見て複雑（実装者の問題） • 複雑性はユーザには見えないようにすることが重要 ※付加的利点は後半で・・・

  10. Sample Systemｓ • Prototypes • SDD-1 (1970後-1980後、Computer Corporation of America研究所) • R* （1980前、IBM研究所、システムRプロトタイプ分散バージョン） • Distributed Ingres （1980前、カリフォルニア大学バークレー校、Ingresプロトタイプ分散バージョン） • SQL products • Ingres/Star • Oracleの分散データベースオプション • DB2の分散データ機能

  11. A Fundamental Principle 　　ユーザにとって、分散システムは完全に 非分散であるかのように見えるべき！！ 　　分散システムのユーザが分散ではないかのように振舞うべき！！ ※ユーザ： エンド・ユーザ 　　　　　　　アプリケーション・プログラマ １２の目標

  12. Distributed database & remote data access • Remote data access system • ユーザはリモート・サイトのデータを操作することができるかもしれない • 複数のリモートサイトのデータを同様に操作できるかもしれない • 継ぎ目が見える • Distributed database • 継ぎ目は隠されている

  13. ３．THE TWELVEOBJECTIVES • ローカル自律性 • 中央のサイトに頼らない • 継続的な動作 • 位置独立性 • 断片化独立性 • 複製独立性 • 分散問い合わせ処理 • 分散トランザクション管理 • ハードウェア独立性 • オペレーティングシステム独立性 • ネットワーク独立性 • DBMS独立性

  14. ①Local Autonomy 分散システムのサイトは、自律的であるべきである • ローカル自律性：あるサイトでのすべての操作がそのサイトで制御される • ローカルの責任においてローカルデータがローカルに保存管理される • 安全性、完全性、ローカルデータの保存表現などは、ローカルサイトの管轄であり制御下のまま

  15. しかし・・・ • ローカル自律性という目標は完全には達成しえない • サイトXが他のサイトYへある程度の制御を委ねなければならない状況が数多く存在する • Reference[21.13] サイトは可能な限り最大限に自律的であるべきである 目標を正確に言うと・・・

  16. Reference[21.13] • Local Autonomyを妥協する必要がある状況 • 断片化された関係の個々の断片は、それらが記憶されているサイトからのみ直接アクセス可 • 複製された関係の個々の複写は、それらが記憶されているサイトからのみアクセス可 • 更新アクセスは、それが記憶されているLocalなサイトにおいては不可 • ２相コミットの処理の参加者として動作しているサイトは、対応する調停サイトの決定に従わなければならない

  17. ②No Reliance on a Central Site • ローカル自律性 　すべてのシステムが中央のサイトに依存しないように中央の「マスタ」サイトに頼ってはならない • ローカル自律性が達成されなくても本来望ましいこと • 中央のサイトに頼らない理由 • 中央のサイトがボトルネックになる可能性 • システムが弱点を持つ可能性 （中央サイトのダウンによってすべてのシステムがダウンしてしまう） すべてのサイトが等しく扱われなければならない ※１の目標から導き出され、追従する

  18. ③Continuous Operation 　　分散システムの利点は、より多くの信頼性と可用性を提供できることである • 信頼性（reliability）：システムがある瞬間に稼動している確率 • 個々のサイトの要素が失敗していても機能し続けることができるため信頼性が向上する • 可用性（availability）：システムがある期間継続的に稼動している 確率 • データの複製の可能性から（２１．６参照）可用性が向上する • システムは決して停止されるよう要求されるべきではない • 計画されていない停止（失敗）は明らかに望まざること • 計画されている停止（EX.新規サイト追加、DBMSレベルアップ）も決して必要とされるべきではない

  19. ④Location Independence（位置独立性） 　　ユーザはデータが物理的にどこへ記憶されているかを知る必要はない 　　データがユーザのローカルサイトに記憶されているかのように振舞えるべき • ユーザのプログラムや端末の活動をなんら無効にすることなく、データをサイトからサイトへ移動可能 ※「～独立性」：データ独立性の概念を分散の場合に適合するように拡張したもの

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

  21. 断片化の例 ユーザへの 見え方 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

  22. データの断片化をサポートするシステムは、断片化の独立性もサポートするべきであるデータの断片化をサポートするシステムは、断片化の独立性もサポートするべきである • ユーザはデータが全く断片化されていないかのように振る舞うことができるべきである • 断片化の独立性はユーザのプログラムや端末の活動を無効にすることなく性能要求の変化に応じてデータをいつでも再断片化することが許される

  23. 断片化の独立性は、断片が適切な結合と和によって論理的に組み合わされたデータのビューがユーザに提供されることを意味する断片化の独立性は、断片が適切な結合と和によって論理的に組み合わされたデータのビューがユーザに提供されることを意味する • ユーザの要求を満足するためにどの断片を物理的にアクセスする必要があるのかを決定するのはシステムオプティマイザの責任

  24. オプティマイザによる要求の変換 [EMP WHERE SALARY > 40K AND DEPT# = ‘D1’] ＥＭＰ =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’

  25. オプティマイザの決定 ユーザへの 見え方 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

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

  27. 複製の例 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 E３ D２ ３0K E４ D1 ３５K EMP#DEPT# SALARY E1 D1 40K E2 D1 42K E5 D3 48K EMP#DEPT# SALARY E３ D２ ３0K E４ D1 ３５K NL_EMP（L_EMPの複製） LN_EMP（N＿EMPの複製）

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

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

  30. ⑦Distributed Query Processing 「ロンドンにいる赤い部品の納入業者を得よ」 Ans. N社の納入業者 レコード単位型 関係型 ・ニューヨークからロンドンへ要求を送信 ・ニューヨークからロンドンへ「次の」納入業者を要求 ×ｎ ・ロンドンからニューヨークへｎ組の結果を返信 ロンドンからニューヨークへ「次の」納入業者を返信 ２個のメッセージ ２ｎ個のメッセージ 関係型システムが非関係型よりも優れている

  31. Distributed Query Processing • 最適化は集中システム内に比べて分散システム内の方がより重要である • 複数のサイトを巻き込むような問い合わせでは、効果的な戦略を見つけることが極めて重要 • 次節の例で詳しく説明

  32. ⑧Distributed Transaction Management • トランザクションは複数のエージェントから構成される • 「エージェント」･･･サイトで与えられたトランザクションのために処理を実行するもの • Recovery:システムはそのトランザクションのためのエージェントの組が全て一斉にコミットするか、ロールバックすることを保証しなければならない →2相コミット・プロトコル • Concurrency:非分散システムと同じロックに基づいている

  33. ⑨Hardware Independence • 実世界のコンピュータ実装は多数の異なるマシン 　　同じDBMSが異なるハードウェア・プラットフォーム上で実行可能 　　それらの異なるマシンが全て等しい仲間として分散システムに参加できることが望ましい IBMの機械、DECの機械、HPの機械、多機種のPCやワークステーション システム全てのデータが統合 ユーザに「単一システム」のイメージで提供

  34. ⑩Operating System Independence • 異なるハードウェアプラットフォーム上で同じDBMSが実行できるならば・・・ 　　異なるオペレーティング・システム上でも実行可能であることは必然的 • MVS版とUNIX版とPC/DOS版の全てが同じ分散システムに参加できることが明らかに望ましい

  35. ⑪NetworkIndependence • システムが異なるハードウェアと異なるオペレーティングシステムを持つ多くの異種サイトをサポートできるのであれば・・・ 　　様々な異なる通信ネットワークもサポートできることが望ましい

  36. ⑫DBMSIndependence • 異なるサイトにあるDBMSインスタンスが同じインターフェースをサポートするだけのこと • （例）INGRESとORACLEが正式のSQL標準をサポート　 →　INGRESのサイトとORACLEのサイトが分散システム • 分散システムはある程度は非均質でもかまわない • 詳しくは２１．５節で・・・

  37. 主要な問題点 主要な目標 ２１．４　分散システムの問題点 通信ネットワークが遅い ネットワークの使用率を減少 メッセージの数と大きさを減らす • 問い合わせ処理 • カタログ管理 • 更新伝播 • リカバリ制御 • 並行制御 従属領域に問題発生

  38. 問い合わせ処理 ネットワークの使用率を減少させる 問い合わせ実行処理、問い合わせの最適化処理も分散させる必要 サイトX 問い合わせQ 「サイトYの関係Ry とサイトZの関係Rzとの和を算出」 Xのオプティマイザ 　　→　“RｙをZへ移動” 全体の最適化段階 サイトY 100組の関係Ry サイトZ 100万組の関係Rz Zのオプティマイザが Z特有の戦略を決定 局所最適化段階

  39. 問い合わせ処理の例 • データベース（納入業者と部品） • S{S#, CITY} ー1000組がサイトAに記憶 • P{P#, COLOR} ー100,000組がサイトAに記憶 • SP{S#, P#}　 ー1,000,000組がサイトBに記憶 • 記憶されている全ての組は25ｂｙｔe（200ｂit） • 問い合わせ－「ロンドンにいる赤い部品の納入者の納入者番号」 • 中間結果の見積もり基数 • 赤い部品の数 ＝10 • ロンドンの納入業者の出荷量 ＝100,000 • 通信の仮定 • データ速度 ＝50,000ビット/秒 • アクセス遅延 ＝0.1秒

  40. 問い合わせ処理の手法 • 六つの手法について総通信時間T［i］を計算 T[i]　＝　総アクセス遅延＋（総データ量/データ速度） ＝（メッセージ数/10）＋（ビット数/50000） １．PをサイトAに移動してAで問い合わせを処理する T[i]=0.1＋（100000＊200）/50000 =　約400秒（6.67分） • 以降も同様に計算

  41. 分散問い合わせ処理の戦略 • 手法　　　　　　　　　　　　技術内容　　　　　　　　　通信時間　 • PをAへ移動 　　6.67分 • SとSPをBへ移動 　　1.12時間 • 　　 各ロンドンの出荷について 5.56時間 • 　　　　　部品が赤いか検査 　　　　　　　　　　　 • ４．　　 各赤い部品について 2.00秒 • 　　　　　ロンドンに納入業者がいるか検査 • ５．　　　ロンドンの出荷をBへ移動　　　　　　　　6.67分 • 赤い部品をAへ移動　　　　　　　　　 　　0.1秒(最速)

  42. カタログ管理 • システムカタログは望ましい場所や断片化、複製の独立性をシステムに提供するために必要な制御情報も含んでいる • 関係やビュー、索引、ユーザなどに関するカタログデータも含む • では、カタログ自身はどこにどのように記憶されるべきか・・・？ １．集中化：全体のカタログを単一中央サイトに記憶 ２．完全複製：全体のカタログを全てのサイトに記憶 ３．区分化：各サイトが自分のカタログを保守 ４．1と3の組み合わせ：

  43. 各アプローチの問題点 • １．集中化:明らかに「中央のサイトに頼らない」という目標を侵害 • ２．完全複製:自律性を侵害 • ３．区分化:局所的でない操作のコスト大 • ４．１と３の組み合わせ:３よりも効果的だが、１と同じ問題発生 システムはどのアプローチも採用していない

  44. R*のアプローチ • R*のオブジェクト名 • ユーザに知られている名前とそれらに対応するシステムが知っている名前との対応付けを意味するもの • オブジェクトの印字名 • ユーザによって通常参照される名前 • システムの広域名 • 一意なオブジェクトの内部識別子 （例）MARILYN @ NEWYORK . STATS @ LONDON • 印字名はシステム広域名「局所名」の部分かシノニムで構成される 作成者ID 作成サイID 局所名 誕生サイトID

  45. CREATME SYNONM • R*独自のSQL文 • ユーザは以下のどちらも使用可 • 局所名を利用 SELECT ... FROM STATS ... ; • シノニムを利用 SELECT ... FROM MSTATS ... ; CREATE SYNONYM MSTATS FOR MARILYN @ NEWYORK . STATS @ LONDON

  46. 局所名を利用したアプローチ • システムは全ての明らかなデフォルトを仮定してシステム広域名を推論する • システムＲのアプリケーションが何の変更もなくＲ*で走る

  47. シノニムを利用した場合 • システムは適切なシノニムテーブルに問い合わせることによってシステム広域名を決定 • シノニムテーブルはカタログの最初の要素 • 各サイトはシノニムテーブルを保守 • 各サイトは以下も保守 • そのサイトで誕生した全てのオブジェクトのカタログエントリ • そのサイトで現在記憶されている全てのオブジェクトのカタログエントリ

  48. シノニムＭＳＴATSへの参照を要求 シノニムテーブル中から対応するシステム広域名を調べる MARILYN @ NEWYORK . STATS @ LONＤON 誕生サイト ロンドン オブジェクトが ロンドンにあった！ カタログエントリ 「オブジェクトはロサンゼルスへ移動しました」 ロサンジェルス サンフランシスコ 「サンフランシスコへ･･･」

  49. 更新伝搬 • データの複製に伴う基本的な問題 　　　オブジェクトの更新を全ての記憶複写に　　　　　　 　　　伝搬させなければならない 　　全ての複写を直ちに更新する 共通の機能が 導かれる →主複写機能 複写の一つが使用不可能の場合の更新は 失敗する

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

More Related