【達人に学ぶDB設計 徹底指南書】第2章 論理設計と物理設計をざっくりまとめてみた
目次
- 目次
- 論理設計と物理設計
- 論理設計とは
- 論理設計では何を行うのか
- 論理設計のステップ
- 物理設計とは
- 物理設計の手順
- バックアップ設計
- リカバリ設計
- リカバリとリストア
- データベースの復旧手順
- 感想
- 参考記事
論理設計と物理設計
データベース設計は、論理設計(概念スキーマの設計)と物理設計(内部スキーマの設計)に分けられます。以下では、論理設計と物理設計について深ぼって行きます。
論理設計とは
論理設計とは、概念スキーマを定義する設計のことです。論理設計における「論理」とは、物理層の制約にとらわれないという意味です。物理層の制約とは、CPUパワーやストレージのデータ格納場所、データ型等、具体的な実装レベルの条件のことです。最初にDB設計するときは、物理層の制約は考えずに、論理設計を始めます。
論理設計では何を行うのか
論理設計では、現実のデータから、RDBにおいて、何をどのようなフォーマットで保存するかを決めることを行います。
論理設計のステップ
論理設計は以下のステップで実行します
- エンティティの抽出
- エンティティの定義
- 正規化
- ER図の作成
1. エンティティの抽出
エンティティとは、現実世界に存在するデータの集合体のことです。物理的実体を伴うものと、伴わないものがあります。
■エンティティの例
顧客、社員、店舗、車、税、会社、注文履歴等
RDBでは、このような現実世界のエンティティを、最終的には「テーブル」という物理的単位で格納していきます。 そのため、RDBにおけるエンティティは、テーブルで表現されます。 システムでどんなエンティティ(データの集合体)を必要になるかを抽出することが、論理設計で一番初めに行うことです。
2. エンティティの定義
エンティティを抽出した後は、各エンティティがどのようなデータを保持するかを決める必要があります。エンティティはデータを「属性」という形で保持します(属性はテーブルの列と同義)。 RDBにおいて、エンティティを定義することは、テーブルを定義することと同義です。 テーブルを定義するときに気をつけることは、キーという列を必ず定義することです。キーとは、ある特定の列の値を決定するための列のことです。キーは複数列で構成されることもあります。
3. 正規化
正規化とは、テーブル(エンティティ)を細かく分割して、テーブルのフォーマットを整理する作業のことです。テーブルを分割することで、データの冗長的な保持を解消したり、データの整合性(ズレや矛盾がない、前後が揃っている)を向上させることができます。
4. ER図の作成
ER図とは、エンティティ(テーブル)の関係性をわかりやすく図にしたものです。 正規化すると、エンティティの数が増えて、エンティティ同士の関係性が分かりづらくなる為、このプロセスは必須です。
物理設計とは
物理設計とは、論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決める工程のことです。物理設計は内部スキーマを定義する設計のことです。
物理設計の手順
- テーブル定義
- インデックス定義
- ハードウェアのサイジング
- ストレージ冗長構成決定
- ファイルの物理的配置決定
1. テーブル定義
テーブル定義とは、論理設計で定義した概念スキーマを元に、DBMS内部格納するためのテーブルを実装することです。SQLのDDL(データ定義言語)等を用いてテーブルを実装します。
2. インデックス定義
インデックスを設定しなくても機能的には問題ないが、非機能の部分、パフォーマンスが大きく変わります。
3. ハードウェアのサイジング
ハードウェアのサイジングとは、ざっくりいうとストレージやサーバの大きさを決めることです。サイジングはキャパシティとパフォーマンスの2つの観点で行います。DBにおいて、データの整合性とパフォーマンスの間に強いトレードオフが存在します。つまり、整合性を高くすると、パフォーマンスが犠牲になり、パフォーマンスを追求すると、整合性を犠牲にします。例えば、高次の正規化をすればするほど、テーブルの数が増え、データの整合性は上がるが、joinで何度も結合する必要が出て、パフォーマンスが悪化します。
キャパシティのサイジング
データ量はシステムの運用開始から基本的には増えていくので、システムの運用終了時にデータ量がどの程度増えるかを見越しておく必要があります。そうしないとストレージの容量が足りなくなってしまいます。 サービス終了時のデータ量を正確に見積もることは難しいため、以下の2つの対策をします。
- 最初から余裕を持たせたサイジングを行う。
- 後で容量が不足した場合に、簡単に記憶装置が追加できるような構成にしておく(スケーラビリティが高い構成)。
パフォーマンスのサイジング
■性能要件
システム開発おける性能要件は、2つの指標を使って定義します。
- 処理時間(特定の処理をどれだけは早く処理できるか)
- スループット(単位時間あたりにどれだけの処理をシステムがこなせるか)
スループットの単位には、「1秒あたりの仕事量」を表すTPS(Transaction Per Second)という指標を使います。 この2つの要件は、要件定義のフェーズで必ず決めます。
■リソース使用量の基礎数値
新規システムを作る場合、どのくらいハードウェアリソースを消費するかの根拠を表す数値を得る方法は2つあります。
- 類似の稼動中システムのデータを流用する。
- 開発の初期段階でプロトタイプシステムを構築して、性能検証を実施する。
しかし、方法1は類似したシステムがない、方法2は検証するのに開発コストがかかったり等、現実的ではないです。そのため、パフォーマンスのサイジングでも、安全性を高めたり、スケーラビリティの高い構成を組むようにします。
AWSなどのクラウドサービスを使うことで、スケーラビリティの面は簡単に確保できるので、近年はAWSがメインで採用されているのかと思います。
4. ストレージ冗長構成決定
この工程では、RAID(レイド)に関する決定をします。データベースに保管されるデータを失うことは、絶対に許されません。RAIDを使うことで、可能な限り高い耐障害性を持つシステムを実現できます。
RAIDを採用するにあたって、以下のことを考える必要があります。
データベースのRAIDは少なくともRAID5で構成します。お金に余裕がある場合、RAID10が良いです。 AWSではRAIDの設定をできるのか分かっていないので、実際に使う場面があったら、設定できるか調べてみます。
RAIDとは
RAIDとは、複数のディスクを束ねて仮想的に一つのストレージとする技術のことです。この単位でまとめられたディスクをRAIDグループと言います。 RAIDのもともとの目的は、十分な信頼性の得られない安価なディスクで、なんとかシステムの保持するデータの安全を図ろうとすることでした。RAIDには何段階かレベルがありますが、基本的な考え方は、複数のディスクに同じデータを書き込んで冗長化することで、そのうちの一本が壊れても残りのディスクが生きていればデータを修復できるようにする、というものです。RAIDでは冗長性が良いことだと捉えるのに対し、正規化では極力冗長性をなくすようにしています。
RAIDのメリット
RAIDを使うことで、システムの信頼性(可用性)を高めることができます。しかし、それだけではなく、システムの性能も向上させます。理由は、ほとんどのレベルのRAIDでは、複数のディスクにデータを分散して保持するため、システムにおいて最も性能的にボトルネックとなるディスクI/O(外部記憶装置に対する読み書き)を分散することができるからです。
5. ファイルの物理的配置決定
この工程では、データベースのファイルをどのディスク(またはRAIDグループ)に配置するかを考えます。このファイル配置に関しては、DBMSが自動で配置してくれます。とはいえ、どんなファイルが配置されるかは知っておいた方が良いです。データベースには以下の5つのファイルが格納されます。
- データファイル
- インデックスファイル
- システムファイル
- 一時ファイル
- ログファイル
このうち開発者が存在を意識するのは、データファイルとインデックスファイルだけです。 これらのファイルには、以下のようなデータが格納されます
| ファイル | ファイルに格納されるデータ |
|---|---|
| データファイル | 「テーブル」のデータ |
| インデックスファイル | テーブルに付与されたインクデックスのデータ |
データファイルについて
データファイルとは、ユーザーがデータベースに格納するデータを保持するためのファイルです。アプリケーション側で発行したSQLを通じて、参照及び更新を行うファイルでもあります。しかし、アプリケーションから見えるのはあくまで「テーブル」という論理的単位であって、「ファイル」が直接見えるわけではないです。
インデックスファイルについて
インデックスファイルとは、テーブルに作成したインデックスが格納されるファイルです。DBMSではテーブルとインデックスは異なるファイルで管理されます。 SQLではテーブルへのアクセスを記述することはあっても、特定のインデックスに対するアクセスを記述することはないです。インデックスを使うかどうかは、DBMSが内部で勝手に判断してくれます。
DBMSはこうしたファイル群をテーブル等の上位の論理的な概念でラップする為、ユーザーはファイルを意識しなくてもデータを扱えます。
バックアップ設計
システムにおいて、データが失われるのは絶対に許されません。そのため、極力データを失わないようなRAIDの設計をしたり、バックアップとリカバリができるようにしておきます。
バックアップとは
バックアップとは、基本的にはファイルのコピーのことです。
ログファイルとは
バックアップを理解する上で、ログファイルの知識は欠かせません。ログファイルとは、テーブルのデータに対する変更履歴を記録するファイルです。DBMSは、ユーザーから受け付けた変更を、すぐにデータファイルに反映するのではなく、ログファイルに溜め込みます。ログファイルには、DB内のデータに対するあらゆる変更操作が残っているので、このファイルをバックアップしておけば、DBに対する変更操作をもう一度再現することができます。
バックアップの3つの方式
バックアップには3つの方式があります。 これらの方式は、バックアップデータをどのような単位で分割するか、という基準に基づいています。
| 名称 | フルバックアップ | 差分バックアップ | 増分バックアップ |
|---|---|---|---|
| バックアップ対象データ | すべて | 前回のフルバックアップからの差分 | 前回の任意のバックアップからの差分 |
| バックアップのトータル処理時間 | 大 | 中 | 小 |
| リカバリのトータル処理時間 | 小 | 中 | 大 |
| メリット | バックアップリカバリ運用が簡単。リカバリ時には一つのファイルが必要 。 | 中間的。 | バックアップファイルのサイズが小さい |
| デメリット | リソースへの負荷が大きい。サービス停止が必要 | リカバリ時には2つのファイルが必要 | リカバリ時にすべてのファイルが必要 |
バックアップには、「バックアップコストが低いほど、リカバリコストが高い」というトレードオフの関係が存在します。 DBのバックアップ設計では、基本的にはこれら3つを組み合わせていきます。どれか一つだけということは普通ないです。「フルバックアップ + 差分バックアップ」 or 「フルバックアップ + 増分バックアップ」が一般的です。
リカバリ設計
バックアップ設計とリカバリ設計はセットで実施することが一般的です。リカバリ手順はバックアップ方式によって左右されるため、リカバリ設計はバッカップ方式が決まれば、自動的に決まります。
リカバリとリストア
障害復旧をする上で、リストアとリカバリという手順にを知る必要があります。リストアを実行してから、リカバリを実行します。
リストアとは
リストアとは、バックアップファイルを使ってデータベースを復旧する作業のことです
リカバリとは
リカバリとは、バックアップファイルでリストアしたデータベースに対して、ログファイルの内容を適用させて変更分を反映する作業のことです。
データベースの復旧手順
DBMS内部にはバックアップされていないログファイルが残っています。そのため、リストアとリカバリをした後に、このログファイルを適用することで、障害直前のデータベースに復旧できます。
- フルバックアップのファイルをデータベースに戻す。→ リストア
- 差分(または増分)バックアップしていたログファイルを適用する。→ リカバリ
- DBMSに残っているログファイルを適用する。→ ロールフォワード
(※)ロールフォワードとは、どこかの時点のバックアプを適用して、バックアップ以降で障害が起きる直前までの処理を再現することで、障害が起きる直前のDBを再現することです。
感想
論理設計と物理設計には強いトレードオフの関係性(論理設計をきれいに行なおうとすると物理設計が犠牲になり、物理設計を 優先すると論理設計が犠牲になる)があるそうですが、いまいちピンと来てないので、今後の経験を通して、理解できればと思います。
