---
note: 全13回の先。公式ドキュメント通読・ミニDB実装・理論・意図的な破壊・他DB比較まで、実務外で積めるステップの地図
created: 2026-08-15T18:00:00+09:00
---

# 講座修了後のロードマップ（DBの専門性をどう積むか）

> [DB講座（全13回）](00-index.md)の続き。講座が育てるのは「設計・性能・運用・安全の四方向から根拠を語れる実務者」までである。ここから先、実務経験以外で積めるステップを整理する。

## 前提: 「DBの専門家」は一つではない

方向によって必要なステップが変わるため、先に整理しておく。

| 方向 | 何ができる人か | 主戦場 |
|---|---|---|
| 性能屋 | 遅い原因を内部構造から特定し、根拠を持って直す | チューニング、キャパシティ設計 |
| 設計屋 | 要求からスキーマを起こし、長期に耐える判断ができる | モデリング、データ基盤設計 |
| 運用屋 | 壊れる前に気づき、壊れても戻せる | SRE、DBA |
| 内部実装屋 | DBそのものを作る・直せる | エンジン開発、OSS貢献 |

講座が育てるのは性能屋・設計屋の土台。複数プロダクトの技術判断を担う立場であれば、**性能屋と設計屋を深めて運用屋を実用レベルまで**が現実的な目標になる。内部実装屋の領域は職業としてではなく学習手段として通ると、他の3つの解像度が大きく上がる。

## 全体の順序

```text
講座13回
  ↓
公式ドキュメント通読 ＋ ミニDB実装(ヒープ+B-tree)   ← ここで理解の質が一段変わる
  ↓
体系的な講義・書籍で理論を埋める
  ↓
意図的に壊す ＋ 他DBとの比較
  ↓
論文 ＋ コミュニティ
```

**「公式ドキュメント通読 + B-tree実装」までが最も費用対効果の高い区間**であり、半年〜1年で到達できる。その先は年単位。専門家を名乗る水準までは3〜5年を見る。

---

## Step 1. 公式ドキュメントを検索でなく通読する

最も地味で、最も効く。PostgreSQLの公式ドキュメントは教科書として書かれており、通読に耐える数少ないプロダクトドキュメントである。

**優先して読む章**

- **Internals** — Overview of PostgreSQL Internals / System Catalogs / Index Access Method Interface
- **Server Administration** — WAL Configuration / VACUUM / Resource Consumption
- **Concurrency Control** — 分離レベルの正確な定義。二次情報の解説は不正確なものが多く、ここが一次情報になる

**なぜ検索では駄目か**

断片的に読むと「そういう設定がある」で終わる。通読すると設定同士の関係が見える。例として、`shared_buffers` と `effective_cache_size` とOSのページキャッシュが三重構造になっている関係は、個別に引いても見えてこない。

**あわせて習慣化する**

- リリースノートを毎バージョン読む。何が問題だったから直されたのかが分かり、設計の意図を逆算できる

## Step 2. ミニDBを実装する

理解の質が最も変わるステップ。読むだけでは「B-treeは平衡木」で止まるが、実装すると**なぜページ単位なのか、なぜノード分割が高コストなのか、なぜ削除が難しいのか**が具体的に分かる。

**段階**

1. **ヒープファイル + 全件走査** — ページ管理、タプルの配置
2. **B-tree索引** — 挿入・分割・検索。講座第7回の内容がここで腑に落ちる
3. **簡易パーサ + エグゼキュータ** — SELECT文を構文木にして実行する
4. **プランナ（コスト計算）** — 候補の列挙とコスト比較。`EXPLAIN` の出力が「自分が書いたのと同じもの」に見えるようになる
5. **WAL + クラッシュリカバリ** — 学びが最も大きい。fsyncのタイミングを誤るとデータが失われることを自分で体験する
6. **MVCC** — 可視性判定、スナップショット、xmin/xmax

**1と2だけでも投資対効果は非常に高い。** 全段階をやる必要はない。

**言語選択**

メモリ管理が見える言語（Rust / C / Go）のほうが学びが多い。抽象度の高い言語だと、学ぶべき部分がランタイムに隠れる。

**参考にできる教材**

- "Let's Build a Simple Database"（SQLiteクローンを段階的に作るチュートリアル）
- CMU 15-445 の課題（BusTub）

## Step 3. 体系的な講義・書籍で理論を埋める

**講義**

- **CMU 15-445 / 15-721（Andy Pavlo）** — ほぼ唯一の正解に近い。全講義がYouTubeで公開されている。15-445が基礎、15-721が先端（インメモリ、列指向、最適化）。大学院レベルでありながら実装寄り

**書籍**

| 書籍 | 位置づけ |
|---|---|
| 『Database Internals』(Alex Petrov) | ストレージエンジンと分散の内部。講座第7回を深掘りした内容 |
| 『Designing Data-Intensive Applications』 | DB単体ではなくシステム全体の中でのDB。講座第13回の拡張 |
| 『トランザクション処理』(Gray & Reuter) | 古典。分厚いが、トランザクション理論の源流 |
| 『内部構造から学ぶPostgreSQL』(鈴木啓修) | 日本語でPostgreSQL固有の内部に踏み込める数少ない一冊 |

## Step 4. 論文を数本読む

網羅する必要はない。**設計判断の源流にある10本程度**を押さえると、以降の技術記事が「あの系譜か」で読めるようになる。

| 論文 | 何が分かるか |
|---|---|
| Codd 1970 | 関係モデルの原論文。短い |
| ARIES | クラッシュリカバリの事実上の標準。WALの理解が変わる |
| Serializable Snapshot Isolation | PostgreSQLのSERIALIZABLE実装の根拠 |
| Volcano / Cascades | プランナの最適化フレームワーク |
| The Log-Structured Merge-Tree | LSM。B-treeとの対比で両方が分かる |
| Stonebraker "What Goes Around Comes Around" | DBの歴史と、なぜ関係モデルが勝ったか |

## Step 5. 意図的に壊す

実務では実行できないため、実務外でしか積めない経験になる。**壊れ方を知っていることが専門性の実体**と言ってよい。

**再現する対象**

- 分離レベルごとの異常（Lost Update / Write Skew / Phantom）を、セッション2本で実際に再現する
- ディスクフル状態でのPostgreSQLの挙動
- OOM Killerに停止させられた場合のリカバリ手順
- レプリケーション遅延中にフェイルオーバーした場合のデータの状態
- ロングトランザクションの滞留でVACUUMが機能しなくなり、XID周回に近づいた場合の挙動

**あわせて読むもの**

- **Jepsen** のレポート。分散システムの整合性検証プロジェクトで、「このDBはこう主張しているが実際はこう壊れる」の実例集。ベンダーの主張を検証する目が育つ

## Step 6. 他DBとの比較で設計空間を把握する

PostgreSQLだけを深く知ると、**その選択が唯一の解に見える**。対比によって初めて「なぜそう作ったか」が分かる。

| 対象 | 学べる対比 |
|---|---|
| MySQL / InnoDB | クラスタ化索引。PostgreSQLのヒープ+索引と正反対の設計 |
| SQLite | 単一ファイル・単一ライター。削ぎ落とした設計として教材価値が高く、ソースが読みやすい |
| RocksDB / LSM系 | 書き込み最適化。B-treeとの対比 |
| ClickHouse / DuckDB | 列指向。OLAPの発想 |

**既に使っているDBで練習する**

MongoDB・Elasticsearchを使っているなら、次を設計上の必然として説明できるかを自問する。

- なぜMongoDBは統計による見積もりではなく、候補計画を実際に走らせて選ぶのか
- なぜElasticsearchのQuery DSL側にはコストベースのプランナが存在しないのか

答えられれば比較の観点が身についている。詳細は[実行計画のメモ](../learning-log/query-planner-and-explain.md)を参照。

## Step 7. 計測の作法を身につける

抜けやすい領域。ベンチマークは**正しく行うほうが難しい**。

- pgbench、TPC-C / TPC-H が何を測っているかを知る
- ウォームアップ、キャッシュ効果、分散、外れ値の扱い
- 「1回測って速くなった」がなぜ信用できないか

計測が信用できなければ、性能改善の主張はすべて根拠を失う。[DB性能検証の初期セットアップ](../checklists/db-performance-setup.md)で扱った「msを判定条件にすると誤魔化される」という話は、この領域の入り口にあたる。

## Step 8. コミュニティを覗く

- **pgsql-hackers メーリングリスト** — 機能がどう議論されて採用されるかが公開されている。「なぜこの仕様なのか」の一次情報
- **CommitFest** — レビュー中のパッチ一覧。何が課題として認識されているかが分かる
- パッチの投稿、あるいはドキュメントの誤りの報告

ここまで来ると「使う人」から「作る側を理解している人」に位置が変わる。

---

## 注意点

**装備は判断の代わりにならない。** 専門性が実際に立ち上がるのは、実務で難しい判断をした回数で決まる。上記のステップは判断の質を上げる装備であって、判断そのものではない。

ただし逆も成立する。装備がない状態での実務経験は、**経験年数だけが増えて判断が変わらない**状態になりやすい。

```text
装備 → 実務での判断 → 装備の見直し
```

このループを回すことが、遠回りに見えて最短になる。

## 関連

- [DB講座 全13回](00-index.md)
- [第7回 ストレージとインデックス](07-storage-indexes-collation.md) — Step 2 のB-tree実装と対応
- [第8回 実行計画を読む](08-explain.md) — Step 2 のプランナ実装と対応
- [第9回 トランザクションと並行制御](09-transactions.md) — Step 5 の異常再現と対応
- [第13回 スケールと外の世界](13-scaling.md) — Step 6 の他DB比較と対応
- [DB性能検証の初期セットアップ](../checklists/db-performance-setup.md) — Step 7 の実務側の適用