頻出中
⏱ 7分★★★☆☆
性能設計
インデックス・パーティション・接続プール・反正規化を完全習得
性能設計の全体像
DB性能設計は「どれだけ速く・どれだけ多くの処理を捌けるか」を設計段階から作り込む活動。インデックス・パーティション・接続プール・クエリ最適化の4本柱で構成される。
| 施策 | 効果 | トレードオフ |
|---|
| インデックス | 検索高速化 | INSERT/UPDATE/DELETEのオーバーヘッド増 |
| パーティショニング | 大テーブルの分割・並列処理 | 跨ぎ検索はパフォーマンス低下の可能性 |
| 接続プール | 接続確立コスト削減 | プール数の上限設計が必要 |
| クエリ最適化 | 実行計画の改善 | アプリ修正コスト |
パーティショニングの種類
| 種類 | 分割基準 | 適した用途 | 例 |
|---|
| レンジパーティション | 値の範囲 | 時系列データ（年月で分割） | 2023年分・2024年分 |
| リストパーティション | 値のリスト | 地域・カテゴリで分割 | 東日本・西日本 |
| ハッシュパーティション | ハッシュ値 | 均等分散・ホットスポット回避 | 顧客IDのハッシュ |
| 複合パーティション | 上記の組み合わせ | 多次元の分割 | 年月 x 地域 |
パーティションプルーニング：WHERE 条件がパーティションキーに一致すると関係しないパーティションをスキップできる。
接続プールと性能
DB接続の確立はコストが高い（TCP ハンドシェイク・認証など）。接続プールで事前に接続を確立しておき再利用する。
- プールサイズ：CPU コア数 × 2〜4 が目安（DBMSの最大接続数も考慮）
- 接続タイムアウト：長時間使われない接続は切断してリソース解放
- コネクションリーク：返却し忘れでプールが枯渇 → アプリのバグ原因
クエリチューニングの基本手順
スロークエリログで遅いクエリを特定
↓
EXPLAIN / EXPLAIN ANALYZE で実行計画を確認
↓
Seq Scan を Index Scan / Index Only Scan に変える施策を検討
↓
インデックス追加・クエリ書き換え・統計情報更新を実施
↓
実測で改善を確認（ベンチマーク比較）
反正規化（非正規化）による性能改善
正規化によって増えた JOIN が性能ボトルネックになる場合、意図的に冗長化することで JOIN を削減する。
| 手法 | 内容 | リスク |
|---|
| 列の複製 | よく参照する列を別テーブルにコピー | 更新時に両方の同期が必要 |
| 集計列の追加 | 合計・件数などを事前計算して列に保存 | 更新タイミングのずれ |
| テーブルの結合 | JOINが多い2テーブルを1テーブルにまとめる | NULL列増、更新異常の可能性 |
反正規化は性能改善の手段として有効だが、データ整合性リスクを伴う。適用前にトレードオフを十分検討する。
試験頻出ポイント
- レンジパーティション：時系列データの分割に適し、パーティションプルーニングが有効
- 接続プール：接続確立コスト削減。プールサイズはCPUコア数を基準に設計
- スロークエリ→EXPLAINでSeq Scanを発見→インデックス追加の流れを理解
- 反正規化：整合性を犠牲にして性能を向上させる意図的な設計判断
📝 理解度チェック
時系列ログデータを月単位で分割管理するのに最適なパーティション種別はどれか？
接続プールを利用する主な目的はどれか？
反正規化（非正規化）のリスクとして最も適切なのはどれか？
読了ボタンを누すとトップページの進捉に反柼されます