💬
達人に学ぶDB設計 徹底指南書 読書メモ
TL;DR
- 実務経験はあるものの設計指針に自信がなく、プラクティス・パフォーマンスの考え方を学ぶために読んだ
- 設計の知見を得ること、そしてパフォーマンスへの理解を深める入門書として非常に良かった
- 続けて内部構造から学ぶPostgreSQLを読む予定
- 一貫して「論理設計は物理設計に先立つ」と主張しており、納得感があった
- 個人的には5章-8章が特に学びになった
- グレーノウハウの中には過去に遭遇したものや自分がやってしまったものがあり、本書を読んでおけば良かったと思った
- インデックスについては概要レベルでも怪しい知識だったため、初歩を確認できて良かった
- 総じて、応用情報レベルは持っている人のNext stepとして非常におすすめ
- 業務で意識せず使っている部分に気づき、より細かいところを確認してみようと思った
- どんなインデックスが実装されているのか？
- 本書で紹介されているプラクティスに反する部分はないか？もしあればその背景は？どうやって改善できる？かを検討する
1章 データベースを制するものはシステムを制する
システム設計にはデータ設計が肝
（読みかけの「データ指向アプリケーションデザイン」を思い出した。また後で読む）
2章 論理設計と物理設計
- 論理設計は物理設計に先立つ
- 物理設計では冗長設計・バックアップ設計なども意識する必要がある
- クラウドサービスを使うのであれば意識すべき点は本書と全く一緒ではないが、それはあくまでクラウドが隠蔽してくれているから
- 私自身はクラウドでの開発しか経験がなく、オンプレでの設計について非常に学びになった
3章 論理設計と正規化
正規化の復習
4章 ER図
ER図の復習
5章 論理設計とパフォーマンス
正規化と検索SQLのパフォーマンスは強いトレードオフの関係にある
ミック. 達人に学ぶDB設計 徹底指南書 (p.147). Kindle 版.
- 一般的には、正規化したことでテーブルの結合が増え、SQLのパフォーマンスが劣化する
- サマリーデータや選択データをテーブルに追加し非正規化することでパフォーマンスの問題は解決できる
- しかし一貫性の担保や更新のパフォーマンスがネックになる
- トレードオフを理解し、要件に即した設計が必要
6章 データベースとパフォーマンス
正規化以外に、インデックスと統計情報もパフォーマンスに影響する重要なポイントである。
インデックス
- 最も主要なインデックスはB-treeインデックス
- 様々なケースを平均して高いパフォーマンスを出すためよく利用されている
- B-treeが平衡木であるため均一性が高い
- B-treeインデックスの性能はO(logn)であり、データ数に対して持続性が高い
- 挿入・更新・削除のコストも検索と同じくO(logn)であり、処理汎用性が高い
- 範囲検索に対しても有効であり非等値性が高い
- 否定条件に対しては効果を持たない
- キー値をソートして保存するため、親ソート性がある
B-treeインデックスの設計方針
- 指針1: 大規模なテーブルに対して作成する。
- データ数が大きい時にB-treeインデックスは効果を発揮する
- 指針2: カーディナリティの高い列に作成する。
- 値が平均的に分散している場合に特に効果が高い
- 目安: 全体のレコード数の5%程度に絞り込めるだけのカーディナリティを持つ
- 指針3: SQL文でWHERE句の選択条件、または結合条件に使用されている列に作成する。
その他のインデックス
- ビットマップインデックス
- 各値が存在するかどうかを示すビットマップを使用する
- 値のカーディナリティが低い場合に有効
- ハッシュインデックス
- データ値をハッシュする
- 等価検索に対して有効
統計情報
DBMSはSQLを受け取り、テーブルにアクセスするまで以下の経路を辿る
- ユーザーからSQL文がDBMSに発行される
- DBMS内のパーサーというモジュールが構文を確認
- SQLはオプティマイザというモジュールに送られる
- オプティマイザが実行計画を決める
- オプティマイザはカタログマネージャーというモジュールに統計情報の紹介をかける
- この統計情報が実行計画に影響する
- オプティマイザは統計情報を元に実行計画を作成し、SQLを手続きに変換する
- テーブルにアクセス
統計情報の設計指針
一般的にエンジニアが設計で考慮すべき点は、
- 統計情報収集のタイミング
- 統計情報収集の対象
である。
統計情報収集のタイミングはデータが更新されえた後、なるべく早くが望ましい。
しかし、パフォーマンスに影響を与えうるためパフォーマンスとの兼ね合いを検討する必要がある。
統計情報を収集する対象としては、「大きな更新のあったテーブル（およびインデックス）」が対象となる。
7章 論理設計のバッドノウハウ
（いくつかの例は割愛）
テーブル分割は水平分割・垂直分割があるが、どちらも分割に明確な意味がないため避けるべきである。
水平分割についてはパーティションで解決できる。
垂直分割についてはデータマートを作成することで解決できる。
（しかし作りすぎは注意）
8章 論理設計のグレーノウハウ
（いくつかの例は割愛）
代理キー
- 原則として代理キーは避けるべき
- ナチュラルキーのみで表現できるように検討する。たとえばタイムスタンプを主キーに含めることで解決できるケースがある
- Sequenceオブジェクトはパフォーマンスに影響することに注意する
多段ビュー
- ビューはデータを物理的に保持しておらず、SQLを実テーブルに発行している
- SQLの発行が増えるためパフォーマンスネックになりやすい
- ビューの使用は原則として一段にすべし
ビューの背後にあるテーブルの存在を、常に意識せよ。
ミック. 達人に学ぶDB設計 徹底指南書 (p.251). Kindle 版.
9章 SQLで木構造を扱う
DBMSで木構造を扱うためのいくつかのモデルが紹介されている。
実際の課題をDBMSで解決するためにどのようにモデリングできるのか、そしてモデル間にはどのようなトレードオフがあるのかを考える実例として学びが深かった。
書籍へのリンク
Discussion