【読書メモ】達人に学ぶDB設計徹底指南書-第２章

こんにちは，ふわせぐです．
第２章を読んだので，メモ書きをまとめていきます．
前回は結構解説チックに書いてしまったのですが，もうちょっとアウトプットのコストを減らしたいので，殴り書きに近くなるかもしれません．
僕は本を読みながらスマホにメモしているので，それをまとめます．

2-1 概念スキーマと論理設計

概念スキーマを定義する設計＝論理設計
→物理層の制約（CPUやストレージなど）に囚われない設計．

【システム開発におけるDB設計の手順】（❌ 皿を用意してから料理を作る　⭕️ 料理に合わせて皿を決める）
１．概念スキーマ（論理設計）
２．内部スキーマ（物理設計）

【論理設計のステップ】
１．エンティティの抽出
　　エンティティ＝実体（物理的実体で無くてもOK）
　　システムにどんなエンティティが必要になるかを洗い出す．
２．エンティティの定義
　　各エンティティにどのようなデータを保持するかを決定．属性を決めてあげる．キーが重要．
３．正規化
　　データの更新が整合的に行えるように，データのフォーマットを整理する．
４．ER図の作成
　　エンティティ（テーブル）同士の関係を可視化する．これは，開発者が理解しやすいためのもの．

2-2 内部スキーマと物理設計

テーブル定義＝論理モデルを２次元表に起こすこと．
インデックス定義＝索引をつけてあげること

ハードウェアのサイジングは，キャパとパフォーマンスの２つの観点に分かれる．見積もったデータ量に見合ったストレージサイズ，そしてストレージのディスクI/Oを含むマシンの適切なスペックを考える．
データの整合性とパフォーマンスは二律背反でトレードオフの関係．限られた予算の中での平衡点を見つける．

【キャパシティのサイジング】
サービス終了時のデータ量を見積もらないと，データは増えていくのでいつかストレージがパンクする．設計時点で見積もりが難しい場合は，
・余裕を持ったサイジング
・記憶装置の増築を簡単にできる構成にする（＝高いスケーラビリティ）

【パフォーマンスのサイジング】
処理時間とスループットを指標にする．どれだけ速いか，そしてどれだけ（仕事量）が多いか．

ハードウェアリソースの見積もりが難しい場合は，
・類似システムのデータを使ってみる
・プロトタイプで検証する

ストレージの冗長構成について
「RAID」という技術＝ディスクを重ねて冗長化・同じデータを複数箇所に配置
RAIDは，複数のディスクにデータを分散して持つので，ディスクI/Oが分散されてパフォーマンスが上がる．
RAIDにはレベルがいろいろある．
【RAID0】・・・データを複数ディスクに分散させるだけ
→どれか１つでもディスクが壊れたらオワリ
【RAID1】・・・複数のディスクそれぞれに同じデータを保持
→１つでもディスクが生きてたら耐え
【RAID5】・・・パリティという誤り訂正符号を分散して保持
→ディスクが壊れてもパリティから復元可能
【RAID10】・・・RAID1とRAID0の組み合わせ.いいとこ取り．
→高信頼性と高速性の代わりにコストが高い
結論として，少なくともRAID5で構成したい．できればRAID10がよくて，RAID0は論外．

ファイルの物理配置
DBに操作されるファイルは５種類．
データファイル，インデックスファイル，システムファイル，一時ファイル，ログファイル．
最もファイルI/Oが多いのはデータファイル．つまり，データファイルとそれ以外を別のRAIDグループに配置すべき．
次にファイルI/Oが多いのはインデックスファイルと一時ファイル．できれbこれも独立したRAIDグループに置いておきたい．

2-3 バックアップ設計

バックアップは，フルバックアップ・差分バックアップ・増分バックアップ３種類を組み合わせる．

フルバックアップは復元が簡単だが，欠点として，「バックアップするのに時間がかかる」「ハードウェアへの負担が高い」「サービスの停止が必要」などがあげられる．

差分バックアップはある時点からの変更分だけをコピーする．基準点でフルバクアップをとり，そこから差分を記録していく．差分は，ログファイルをバックアップすれば良い．ログファイルには変更操作の履歴が残っているので，十分ログファイルだけで復元できる．
バックアップ時間が短縮できるし，必要とするストレージ容量も少ないという利点がある一方で，リカバリの手順は増えるので時間はかかる．

増分バックアップは差分バックアップを効率的にしたもの．必要なログファイルだけバックアップをとる．
差分バックアップは，一つ前のバックアップ内容を含むが，増分バックアップは前回から増えたものだか絵を記録する．したがって，データ容量が最小になる．つまりバックアップ時間も最速．ただし，リカバリが最も複雑になるし時間もかかる．また，必要なファイルが増えるので復旧できる可能性も低くなる．

まぁつまりこれも容量・時間・確実性のトレードオフ．

【バックアップ設計で考慮すべきポイント４選】
・いつ時点の状態に復旧させる必要があるか，復旧の必要はあるか
・バックアップに使用できる時間
・リカバリに使用できる時間
・何世代のデータを残す必要があるか

【バックアップの選択肢４選】
・バックアップしない
・フルバックアップのみ
・フルバックアップ＋差分バックアップ
・フルバックアップ＋増分バックアップ

2-4 リカバリ設計

バックアップ設計とリカバリ設計はセットで考える．

バックアップだけでは，障害の直前には戻れない．バックアップしたタイミングから，障害がおきたタイミングまでの間に時間があると，その間にデータの更新が行われているかもしれないから．

バックアップファイルで復元→リストア
トランザクションを適用して変更差分を反映→リカバリ

実はトランザクションのバックアップだけでは無く，DBMS内部にもトランザクションログが残っている．バックアップがされていないだけでDBサーバーに残っているので，復旧するのに使える．

リストア＆リカバリの手順
１．フルバックアップのファイルをデータベースに戻る→リストア
２．差分or増分バックアップしてたトランザクションログを適用→リカバリ
３．DBサーバーに残ってるトランザクションログを適用→ロールフォワード

あとがき

以上，かなり書き殴りました！！！

第３章も引き続き頑張って少しずつ読んでいきます

達人に学ぶDB設計 徹底指南書