データベース
第 12 回 RDB の実際 (1)
鈴木幸市
今日の内容
DB の設計からアプリケーション作成まで
業務分析
何年運転するのか
その間にデータはどう変化していくのか
構造上の変化はありそうか
DBサイズと性能要件
トランザクションの性質と量
オンラインとバッチ
テーブル論理設計
正規化を原則とした設計
性能要件が厳しいところでは正規化しないことも
テーブル物理設計
データベースの配置
テーブル、インデックス、ログの配置
インデックスの設計
パーティショニング
アプリケーションの作成
種々の API
ESQL, CLI, JDBC, PHO, Perl,,,
クライアントプログラミングとサーバプログラミング
データベースのチューニング
RDB の実際
データベース「だけ」を作ることはできない
データベースはシステムの一部
たくさんの人のチームワークでシステムは作
られる
データベースを作るために理解すべきこと
システムの目的
システムで行う業務
システムの寿命
予算
開発
運用
まず「要件定義書」 ( あるいは「要求仕様 書」を作ること
このような外部条件を
「システム要件」とい う
要件定義書に書くべき内容 (例 )
使う側からみたシステムの具備すべき機能
システムが具備すべき性能
同時に何人使うのか
どれだけの量のデータを扱うのか
システムの寿命
何年くらい運転するのか
あまり長くするとハードウェアやソフトウェアの保守切れの影響がでる
次の更改はいつか
信頼性及び可用性の条件
故障したときの影響範囲はどの程度にするか
許されるダウン時間
欲張るほどコストが膨らむ
運転の条件
定期的に止められるか、どれくらい止められるか
システムの設置場所の条件
自社のオフィスか、専用のデータセンタか
セキュリティの要件
しっかり守るにはやはりコストがかかる
コスト条件
開発コスト
運転コスト
実現手段は書かないのが原則
信頼性やセキュリティの要件から決まる場合も ある
要求仕様からデータベースの要件を抽出
(1)
格納すべきデータの 種類 → どんなカラムが必要か
構造 → どんなテーブルにするか
その主キーと外部キーはどうするか
量 → 何行あるか
どの程度の容量のストレージが必要か
データだけではだめ。インデックスや、それ以外の作業用のデータも 格納しなければならない。
トランザクションの
種類 → どんなトランザクションがあるか
量 → 毎秒トランザクションをどのくらい処理するか
どの程度の性能のサーバとストレージが必要か
データベースの
サイズ → 運転開始時から増えるのか、どの程度増えるのか
ストレージの導入計画
最適設計をする決まった方法はない。経験と実績が大きい。
要求仕様からデータベースの要件を抽出
(2)
運転条件 バックアップのスケジュール
定期的なバッチジョブ（月締めなどのまとまった処理）のスケ ジュール
バックアップの戦略
コールドバックアップ → データベースの運転を止めてバックアップ
ホットバックアップ → データベースの運転中にバックアップ
ストレージの機能を使ったバックアップを行うか
信頼性及び可用性
データベースクラスタを組むか
サーバが故障したら別のサーバが同じストレージを使ってサービス継続
レプリケーションを行うか
データベースの最新のコピーを常に作っておいて故障したら切り替える
ハードウェアのコストに大きく影響す
る要因が多いので注意
テーブルの論理設計
正規化、及び ER の手法を用いて設計する
第 4 回、第 10 回講義の内容を実践すれば
いい
データベースの物理設計 (1)
データベースの配置
一つのサーバにすべて格納するのか（単一デー
タベース）
サブシステムに分けて複数のデータベースでシ
ステムを作るのか
単一データベースの中の
テーブルやインデックス、ログなどをどのディ
スク（あるいはファイル）に格納するのか
できるだけ分散させたほうが性能は上がる
すべてまとめて大きな RAID0 で構成しても性能
は上がる
RAID0 の復習
データベースの物理設計 (2)
インデックスの設計
どのテーブルにどのようなインデックスを作
ると性能が上がるか
主キーには通常インデックスを作る
外部キーはよく考えて
外部キーのあるテーブルの行を探索しなければ、外部 キーにはインデックスは不要
たくさんインデックスを作ると
データベースの容量が増える
データの追加、更新、削除の性能が下がる
行データだけでなく、インデックスも同時に追加修正 が必要になる
インデックスは作ればいいというものではない
データベースの物理設計 (3)
パーティショニング
テーブルを小さな多くのサブテーブルに分け
る
一つ一つのテーブルが小さくなるので効率が
あがることがある
きちんと評価環境で試験してから実施すべき
逆に大規模な処理（集計など）では、無駄が
出て性能が悪くなることもある
データベースの物理設計 (4)
メモリ設計
データベースにどの程度のメモリを割り当てるか
共通バッファ用のメモリ
個別の作業用のメモリ
行の並べ替えなどに使うメモリ
OS で使う I/O キャッシュにもメモリが必要
物理設計は性能を出すには非常に重要
詳細な方法は DBMS によって異なる
アプリケーションの作成
どの言語を使うか
埋め込み SQL （ ESQL) → C, C++, COBOL
なども
API :JDBC, ODBC, Perl, PHP, Ruby 等々
どこで動くアプリケーションか
クライアント
上記の ESQL や API はクライアントで動く
サーバ
SQL の一部として DBMS の中で動く
ストアドプロセジャ (Stored Procedure)
PL/SQL など、 DBMS 毎に手段を提供している
