概念スキーマと論理設計

• 論理設計

  • 概念スキーマと論理設計定義する設計工程

• 「論理」

  • 物理層の制約にとらわれない、くらいの意

• 物理層の制約

  • データベースサーバーのCPUパワー
  • ストレージのデータ格納場所
  • DBMSで利用可能なデータ型やSQLの構文

• 原則として、論理が物理に先立つ

  • 予算等の理由につき、そうもいかないこともある
• 机上で行える

論理設計のステップ

1. エンティティの抽出
2. エンティティの定義
3. 正規化
4. ER図の作成

エンティティの抽出

「エンティティ（実体）」と言っても、物理的実体を伴う必要はない

• entity: 実体

  • 物理的な実体のあるもの

    • 顧客
    • 社員

  • 物理的な実体のないもの

    • 税
    • 会社
    • 注文履歴
    • 関連エンティティ
• 要件定義と重なる
• ので、顧客やシステム利用者と要件を詰めていく中で実施する

エンティティの定義

• 各エンティティの属性を定義

• 属性(attribute)

  • 列と同義
• 特にキー列の定義が重要

正規化(normalization)

• システムでのエンティティの利用がスムーズに行えるようにする

  • 更新を整合的に行えるよう

    • 登録
    • 変更
    • 削除
• 逆に、正規化していない状態ではシステムでの利用にたえない

ER図の作成

• 正規化によりエンティティが分割されて増える

  • 中小規模システムでも数十
  • 大規模システムでは何百も
• 何の助けもないと手に負えなくなる

• ERD: Entity Relation Diagram

  • エンティティの見取り図

• 流派

  • ER記法
  • IDEF1X

内部スキーマと物理設計

• H/WやDBMS個々の製品についての知識が必要になってくる
• 本節では極力一般的な内容に絞る

物理設計のステップ

1. テーブル定義
2. インデックス定義
3. ハードウェアのサイジング
4. ストレージの冗長構成決定
5. ファイルの物理配置決定

テーブル定義

• 「物理モデル」の作成

  • cf. 論理設計で作成するERモデルは「論理モデル」
• 概念スキーマをテーブル単位に変換していく

インデックス定義

• 非機能部分

ハードウェアのサイジング

サイジングはキャパシティとパフォーマンスの2つの観点から行う

データベースの性能問題の8割はディスクI/Oによって起きる

性能要件の指標は二つ。「どれだけ速いか」と「どれだけ多いか」

精度の高いサイジングは難しい。それゆえ、

• 必ず実施時には安全率を設けること
• スケーラビリティの高い構成を組むこと

• 「サイジング」には2つ

  • キャパシティ

    • システムで利用するデータサイズを見積もり、それに十分な容量の記憶容量(ストレージ)を選定する

  • パフォーマンス

    • サーバー

      • CPU
      • メモリ

    • ストレージ

      • I/O

• データの整合性とパフォーマンスとのトレードオフ

  • データベース設計とは、限られた予算制約の中で、両端の間の平衡点を見つけ出そうとする努力

• 難易度の高い仕事。こなせればDBエンジニアとしてはエース級

  • 過剰だと嫌味を言われる

  • 不足すると悲惨

    • FinTechなどではシステムダウンが新聞に載ることも

キャパシティのサイジング

• システムで利用するデータ量

  • 物理的なテーブル定義、インデックス定義をもとに算出

  • DB内に格納するファイル以外も

    • テキスト
    • HTML
    • 画像

• サービス終了時のデータ増加率

  • だいたい増える
  • サービス運用途中で足りなくなるとまずい

  • 正確な見積もりが難しい場合もある

    • 例: まったく新規のサービス

  • どうする

    • 安全率を大きくとる
    • 記憶装置を簡単に追加できる構成にする(scalability)

パフォーマンスのサイジング

• 性能要件

  • 処理時間

    • 「何秒以内に処理完了する」

  • スループット

    • 「単位時間あたりどれだけたくさん処理できる」

      • TPS: Transaction Per Second

• リソース使用量の基礎数値

  • リソース使用量は、机上では見えにくいので他の情報から類推する

  • 類推の根拠となる基礎数値が要る

    • 類似の稼働中システム
    • プロトタイプ

• スケジュールが短期化している近年ではプロトタイプ検証を行う余裕が無い場合も

コラム: クラウドとスケーラビリティ

• IaaSにより構成変更が柔軟に行える
• とはいえスケーラビリティの問題から完全に自由になれるわけではない

ストレージの冗長構成

RAIDはシステムの信頼性と性能を共に改善できる技術

データベースのRAIDは少なくともRAID5で構成する。お金に余裕があればRAID10。RAID0は論外。

• RAID: Redundant Array of Independent Disks

• 効能

  • 信頼性向上
  • 性能向上

• 種類いろいろ

  • RAID0

    • striping

  • RAID1

    • mirroring

  • RAID5

    • パリティ分散

  • RAID6

    • 垂直パリティも

  • RAID10

    • ミラーリングしたクラスタに対してストライピング

• 信頼性・性能両面を考慮して、RAID5、お金に余裕があればRAID10がよい

• RAID0は信頼性が低いので使ってはならない

  • ただのディスク1本よりも信頼性低い

ファイルの物理配置

• DBに格納されるファイルは大別して5種類

  • データファイル

    • テーブルのデータ

  • インデックスファイル

    • テーブルに作成されたインデックス

  • システムファイル

    • アプリケーションやユーザがアクセスすることは基本的にない

  • 一時ファイル

    • 処理が終了すれば削除されるやつ

      • サブクエリ
      • ファイルソート
    • 容量が継続的に増え続けるものではない

  • ログファイル

    • トランザクションログとかバイナリログとか呼ばれるやつ

    • 容量が継続的に増え続けるものではない

      • バックアップとして残す場合は一定期間増加する
      • リカバリ時に削除するので単純増加はしない
• 全部別ディスク(RAIDグループ)に配置するのが望ましい

• 予算制約の中で妥協するなら…

  1. システムファイルとログファイルをまとめる

     • 性能的に分散優先度が低い

  2. 他のもまとめる

     • 性能への影響が大きくなる

• LOBを扱う場合はこれも分けたほうがよい

  • LargeなのでディスクI/Oコストが高い

バックアップ設計

• 新聞に載らないために

  • 極力データを失わない(前述)
  • データが失われた場合に復旧できるようにする

バックアップの基本分類

完全/差分/増分

• どれか1つだけ、ということはなく、組み合わせる

フルバックアップ

• シンプル
• バックアップ時間長い

• データ量多い

  • ディスクI/O増える
  • CPU・メモリ使用量増える

• サービス停止必要

  • データの整合性を保った状態でバックアップを取得する必要があるため
  • サービスの可用性の制約上「1年に1回しかとれない」なんてことも

差分バックアップ

• フルバックアップからの差分

  1. フル
  2. フルからの差分1
  3. フルからの差分2
  4. …
• バックアップ時間短い
• データ量少ない
• フルか最新の差分かどちらかのバックアップファイルが破損したら復旧不能
• リカバリ時間長い

増分バックアップ

• フルバックアップからの積分

  1. フル
  2. フルからの増分1
  3. フル+増分1からの増分2
  4. …
• バックアップ時間最短
• データ量最小
• フル〜最新の増分までいずれか1つでもバックアップファイルが破損したら復旧不能
• リカバリ時間最長

バックアップ方式にもトレードオフがある

• バックアップコスト <—> リカバリコスト

どんなバックアップ方式を採用すべきか？

バックアップ方式は、「フルバックアップ+差分バックアップ」または「フルバックアップ+増分バックアップ」が一般的

• 検討事項

  • いつの時点に復旧する必要があるか

    • そもそも復旧の必要があるか
  • バックアップウィンドウ(使用できる時間)
  • リカバリウィンドウ(使用できる時間)
  • 何世代前までのデータを残す必要があるか

• 選択肢

  • バックアップしない

    • バックアップファイル以外(入力ファイル等)からデータを復旧できる場合等
  • フルバックアップのみ
  • フル+差分
  • フル+増分

• フルバックアップのみだとデメリットが大きい

  • バックアップウィンドウが大きい
  • バックアップ頻度が低い場合、最新の状態に戻せないことを覚悟しなければならない
• フル+差分or増分が選択されることが多い

リカバリ設計

• バックアップファイルで復旧できるのはバックアップ時点まで
• 障害発生直前までは戻せない

リカバリとリストア

• リストア

  • バックアップファイルを戻す

• リカバリ

  • トランザクションログを適用して変更分を反映

リストアとロールフォワード

• 未バックアップのトランザクションログがDBMS内部に残っている

  • 最後のバックアップから障害発生直前までの変更分

• 復旧の流れ

  1. リストア

     • フルバックアップを戻す

  2. リカバリ

     • 差分or増分バックアップしていたトランザクションログを適用

  3. ロールフォワード

     • データベースサーバーに残っているトランザクションログを適用