データベース
第 13 回 (1) データベースクラスタ
鈴木幸市
今日の内容
なぜ分散型データベースか
情報が必要なところにデータベースを置く
通信速度が遅い時代の話
作ってしまったデータベースをうまく使いこなす
危険分散
バックアップ /ACT-SBY/ レプリケーション
分散型データベースの技術要件
アプリケーションからの透過性
どこにデータベースがあるのか見せない
トランザクション対応
単独 DB のトランザクションでは不十分
二相コミット
二相コミット
データベースレプリケーション
用途によっていろいろ
同期 /非同期
マルチマスタ /シングルマスタ
SQL 転送型 /ログ転送型
なぜ分散データベースか (1)
データベースを小分けにしたい
小さいほうが管理が楽
小さなデータベースを並べて高い性能を出したい
データがある場所にデータベースも置きたい
通信コストが安い時の動機
今は通信コストが安くなったのでこれは動機にはならな
い
運用中のデータベースはそのままにしたい
データベースの変更にはリスクが伴う
新しい業務を入れたら性能が低下するかもしれない
新業務は新しくデータベースを作ってそこで実行させる
構築のリスクはぐっと少ない
今の業務には影響なしに新しい業務の試験ができる
古いデータベースとの「つなぎ」は必須
危険分散をしたい
故障への備えをしたい
データベースのコピーを常に用意しておいて
、一方が壊れたらもう一方で業務を続ける
災害等への備えをしたい
遠隔地にデータベースをコピーしておいて、
何かあったらすぐ復旧できるようにする
データベースを分散させる目的は種々雑多ある。
目的によって使う技術は異なってくる。
小分けにしたデータベース (1)
複数のサーバでデータを分ける
それぞれのサーバで処理が分担できる
うまくデータを分けられれば、サーバを増やすことで
全体の性能が上げられる
小分けにしたデータベース (2) データ
の分割法 水平分割 ( 水平パーティショニング )
サーバにテーブルの「行」を分ける
学部 ID 学籍番号 氏名
001 001 ….
001 002 ….
002 003 ….
002 004 ….
003 005 ….
003 006 ….
学部 ID 学籍番号 氏名
001 001 ….
001 002 ….
学部 ID 学籍番号 氏名
002 003 ….
002 004 ….
学部 ID 学籍番号 氏名
003 005 ….
003 006 ….
小分けにしたデータベース (3) データ
の分割法
垂直分割 (垂直パーティショニン グ ) ひとつの行を別なデータベースに 分けて格納する
データの更新がアプリケーション ごとに偏っている場合などに有効
学部 ID 学籍番号 氏名 住所 成績
001 001 …. …. ….
001 002 …. …. ….
002 003 …. …. ….
002 004 …. …. ….
003 005 …. …. ….
003 006 …. …. ….
学部 ID 学籍番号 氏名 住所
001 001 …. ….
001 002 …. ….
002 003 …. ….
002 004 …. ….
003 005 …. ….
003 006 …. ….
学籍番号 成績 001 …. 002 …. 003 …. 004 …. 005 …. 006 ….
小分けしたデータベース (４ )
データを分けても問題は残る
アプリケーションにデータの所在を指定させるのか？
データの格納方法が変わるごとにアプリケーションを
修正するのは大変 ( コストがかかる )
サーバをまたぐ処理はどうする？
違うサーバにあるテーブルを結合するなど
データベースに面倒見てほしい
分散データベースでのデータの読み書き
分散データベースでは
アプリケーションからいろいろなものを意識させないようにするこ とが重要
これを「透過性」 (transparency) という
位置に対する透過性 (location transparency)
データの物理的な格納位置を意識させない
移動に対する透過性 (migration transparency)
データが移動したことを意識させない
分割に対する透過性 (fragmentation transparency)
データがどのように分割され、どこに格納されているかを意識させ ない
重複に対する透過性 (replication transparency)
あるデータが重複して格納されていても、それを意識させない
データベース設計では重複は避けるが、故障対応などの理由でデータ ベース全体をコピーすることがある
故障に対する透過性 (failure transparency)
データベースが故障しても、ほかのサーバが交代したりすることで 故障を意識させない
トランザクション保障にも特殊な技術が
コミット／ロールバックだけでは不足！！
複数のデータベースを同時にコミットしたつもりでも
成功するものと失敗するものが混在する可能性
どれかが失敗したら、までコミットしたものも取り消
さなければならない ( 可能性は低いが )
二相コミットという技術が必要
二相コミット
コミットを２回に分けて実行する：各サーバでの調整を行う
まず各サーバに「コミットする準備ができたか」と聞く (Prepare)
各サーバではログの出力などを完了させ、コミット直前まで処理を進め ておく
この時点でどこかが失敗したら、すべてのサーバでこのトランザク ションを失敗させる (Abort)
Prepare が全サーバで成功したら、本当のコミットを行うように指 示する
普通はこれで成功するが、、、万が一失敗するかもしれない
そのときには、失敗したサーバを再起動するなどして、再度直前のトラ ンザクションを救済させる
ログが残っているので実行可能
二相コミットを実装している DBMS は多い
上位の制御は、 DBMS 以外のミドルウェアで実行する
ことが多い
データベースのコピー ( レプリケーショ
ン ) レプリケーションの必要性←データは重複しないほう
がいいといったではないか、、、、
アプリケーションには重複は意識させない
故障などの場合に備えて、データベース丸ごとコピーしてお
く方法がとられる場合がある
読み出し専用に使うこともできる→ネットワークサービス
バックアップとの違い
バックアップを使ってデータベースを復旧させるには、バッ
クアップ以降のログを重畳しないといけない (アーカイブ
リカバリ )
アーカイブリカバリは時間がかかる (数時間から丸一日とか
、一般に使うログの量による )
レプリケーションは、常にデータベースのコピーをとってお
くので、短時間で運転を再開できる
レプリケーションの概要
データベースレプリケーションの種類
( １ )
同期型と非同期型
同期型
トランザクション毎にレプリケーションの情報が確実
に SBY 系に届いたことを確認する
非同期型
トランザクション毎にはレプリケーションの情報が
SBY 系に届いたかどうかは確認しない
性能：同期型＜非同期型
信頼性：同期型＞非同期型
実装の複雑さ：同期型＞非同期型
データベースレプリケーションの種類
( ２ )
シングルマスタとマルチマスタ
シングルマスタ
マルチマスタ
並列型データベース
多くのデータベースを並べて高性能を狙う
レプリケーションのデータベースを読み取り専
用にも使う (Hot Standby など )
Web サービスなど
高度な (時間のかかる ) SQL 文を分担実行して
短時間に結果を得る (Analytic)
マーケティング情報解析など (Data Warehouse)
たくさんのデータベースに分担させて多くのユ
ーザからの要求を処理する (Transactional)
大規模なオンライン処理
更新が必要な Web サービス
読み取り専用データベース
Postgres-XC
Postgres-XC の性能特性
1 2 3 4 5 6 7 8 9
0 1 2 3 4 5 6 7 8 9
Scale Factor
Idea l
Obser ved
