達人に学ぶDB設計徹底指南書第2版・読んだまとめpart2
はじめに
本記事では、第2章を読んで得られた学びや感想をまとめました。
※前回記事はこちら
第２章の目次
論理設計と物理設計
２ー１ 概念スキーマと論理設計
２ー２ 内部スキーマと物理設計
２ー３ データベース単位の冗長構成・レプリケーション
２ー４ クラウドにおけるデータベースの冗長構成
２ー５ クラウドはいつどんな時利用すべきなのか
２ー６ バックアップ設計
２ー７ リカバリ設計
習得したこと
⚫︎概念スキーマを定義する設計を「論理設計」と呼ぶ。論理設計は物理設計に先立つ。
料理で例えるなら、器を用意してから何の料理を作るか決めるのではなく、料理に合わせて器を決める、ということ。
⚫︎論理設計のステップ
１、エンティティの抽出
まずはシステムのためにどんなエンティティ（＝データ）が必要になるかを抽出することが論理設計の第1ステップ。（＝要件定義と同じこと）
２、エンティティの定義
エンティティは、データを「属性（attribute）」という形で保持する。特に重要なのが「キー（key）」という列を定義すること。
３、正規化
エンティティ（テーブル）について、システムでの利用がスムーズに行えるよう整理する作業。特に更新（データの登録・変更・削除）が整合的に行えるように、エンティティのフォーマットを整理すること。
４、ER図の作成
Entity-Relationship Diagramの略。正規化を行うとエンティティは増える。そうすると、そのままではエンティティ同士の関係が把握しづらくなるという問題が起こり、開発効率が落ちてしまう。その問題を解決するために考案された。
⚫︎物理設計のステップ
１、テーブル定義
論理設計で定義された概念スキーマをもとに、それをDBMS内部に格納するための「テーブル」の単位に変換していく作業。このフェーズで作られるモデルを「物理モデル」という。
２、インデックス定義
なくても機能的にはなんの問題もないが、インデックスが重要な役割を果たすのは、パフォーマンス部分。
３、ハードウェアのサイジング
サイジングには以下の2つの意味がある。
・データの規模を問題にする場合で、「システムで利用するデータサイズを見積り、それに十分な容量の記憶装置（ストレージ）を選定する
・システムが十分な性能を発揮できるだけのスペックのCPUやメモリをもったサーバーを選定する
▶︎データベースの性能問題の8割はストレージI/Oによって起きる
４、ストレージの冗長構成決定
データベースに保管されるデータは、業務の基幹データのため、これを失うことは絶対に許されない。様々なレベルで可能な限り高い耐障害性を持つようにシステムを構築する必要がある。
RAID（Redundant Array of Independent Disk）＝独立したディスクの冗長配列
５、ファイルの物理配置決定
データベースのストレージの冗長構成が決まったら、物理設計の最終ステップは、データベースのファイルをどのディスクに配置するかを考える。
実はこのファイル配置は、最近のDBMSでは、エンジニアが意識しなくても、ある程度はDBMSが自動的に配置してくれることもある。
・データファイル
・インデックスファイル
・システムファイル
・一時ファイル
・ログファイル
開発者がその存在を意識するのはデータファイルとインデックスファイルだけ。残り三つはDBMSの内部処理で使用されるファイルのため、DBAと呼ばれるデータベース管理者以外は意識しない。
※
・システムファイル：DBMSの内部管理用に使われるデータを格納する
・一時ファイル：DBMS内部での一時的なデータを格納するために使用されている
・ログファイル：テーブルのデータに対する変更を受け付けた場合にログファイルに溜め込んだ後、非同期でデータファイルに変更を反映している
⚫︎レプリケーションとは
現用系と待機系からなる複数のデータベースを用意し、現用系から待機系へ更新データの情報を送信してデータベースのレベルでデータが同じになるようにする技術。
これによって、現用系データベースに障害があった場合も待機系で処理を継続できるようにしたり（可用性向上）、
リードレプリカを増やすことで読み込みスループットを向上させたりする。（性能向上）
レプリケーションによってデータが反映される先の待機系のデータベースを特にレプリカ（複製）と呼ぶことがある。
災害対策はもちろん、待機系では読み込み処理のみを受け付けるなどして負荷分散を行うという使われ方もするそう。
※ただし、リードレプリカは読み取り負荷を分散できる優れたソリューションだが、増やしていくほどコストも増える。。
※バックアップとは異なるので、データを任意のある時点に戻すということはできない。
⚫︎バックアップの３つの方法
①フルバックアップ（完全バックアップ）
ユーザーデータだけでなく、設定ファイルやアーカイブされたトランザクションログファイルなどもバックアップ対象に含まれる
欠点1：バックアップにかかる時間が長い
欠点2：ハードウェアリソースへの負荷が高い
欠点3：ストレージ容量の消費が大きい
最近のシステムは24時間365日稼働が当たり前・・システムに負荷をかける時間は極力短くすることが求められる。
②差分バックアップ
フルバックアップを毎日実行するのではなく、例えば月曜日だけフルバックアップを行い、それ以降は差分バックアップを取ることによって火〜土までのバックアップは月曜日からの変更分のログファイルだけで済む。
バックアップ時間も短くなるほか、バックアップファイルを保管しておく媒体の容量も小さくして節約できる。
欠点1：リカバリの手間も時間も増える（フルバックアップの分と差分バックアップの分それぞれ実行しないといけない）
欠点2：両方のファイルが正常に使用できる必要がある。仮にどちらか一方でも壊れていたら、復旧はできない！
③増分バックアップ
差分バックアップと同じ考え方だがより「効率的」にしたもの。
実は差分バックアップには無駄がある。それは最新のログファイルが古いログファイルの内容も包含するという関係にある。リカバリには最新のログだけでいいから。
火〜土はその日の変更分のみバックアップでOK。
→バックアップデータ量・バックアップに必要な時間も最小で最短。保管するメディアの容量も最小で済む。コスト的にも優れている。
欠点1：リカバリ手順が複雑になる。時間もかかる。（サービス復旧を待ち望むユーザからのプレッシャーと闘いながらリカバリを実施しないといけない）
欠点2：復旧に必要なファイルも増えるため、完全にデータ復旧できる可能性が最も低くなる。
⚫︎リカバリ設計
バックアップ設計とリカバリ設計はセットで実施することが一般的。
障害直前の状態にデータを復旧させるためには、単にバックアップファイルをデータベースに戻しただけではダメ。そこからさらに、ユーザーの変更分を再反映させなければ、リカバリは完結しない。。
障害復旧の手順を厳密にふたつに分ける必要がある。
「バックアップファイルを戻す」作業をリストア、
そのファイルに対して、トランザクションログを適用して変更分を反映する作業を「リカバリ」と呼ぶ。
💫リストア及びリカバリの手順は以下
１、フルバックアップのファイルをデータベースに戻す→リストア
２、差分（または増分）バックアップしていたトランザクションログを適用する→リカバリ
３、データベースサーバーに残っているトランザクションログを適用する→ロールフォワード
リカバリ計画を立てるときは、RTO（Recovery Time Objective：目標復旧時間）を満たすことが可能かどうか、しっかり情報を集めて設計をする必要がある。
感想
正直なところ、第二章でもう設計の話か・・と感じました。
設計することはまだないですが、論理設計→物理設計の流れで、料理の例え（料理に合わせて器を決める）はわかりやすいですが、
実際にいざ設計を任された時、どんなデータをどう抽出するかめちゃくちゃ迷いそうだと思いました。
ちなみに、たくさん出てくる「ストレージI/O」というワードは初めて聞きました。
「I/O」とは入出力(Input/Output)の意味。 頻繁にデータを出し入れすることにより、ハードウェアやネットワークに負荷がかかること。
バックエンドの勉強歴は浅いため、最近「サーバーに負荷」という概念について
聞き慣れてきたくらいです。😣
本を読んでいて恐ろしいことなんだと改めて感じた部分は、
バックアップ・リカバリ計画で出てきた
障害発生時、できるだけ稼働をストップせずに短い処理で復旧作業をおこなわないといけないこと・・
ユーザーが利用を待っているプレッシャーとかを感じながら、いかにストレスが少ない方法で復旧作業をするか、
考えたら怖いですね。
いろんなリスクも考えて計画的にバックアップ・リカバリできるようにしないといけないんだと改めて感じました。
あと、フルバックアップって名前だけ聞いたら完璧そうなのに、
欠点も多く、毎日フルバックアップって行わなかったり・・んー難しい。
引き続き3章を読んでみます👀
3章は「論理設計と正規化〜なぜテーブルは分割する必要があるのか？」
タイトル聞いただけで難しそう・・w
頑張って読んでみます👍
Discussion