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

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

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

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

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

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

全体の順序

講座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は平衡木」で止まるが、実装するとなぜページ単位なのか、なぜノード分割が高コストなのか、なぜ削除が難しいのかが具体的に分かる。

段階

ヒープファイル + 全件走査 — ページ管理、タプルの配置
B-tree索引 — 挿入・分割・検索。講座第7回の内容がここで腑に落ちる
簡易パーサ + エグゼキュータ — SELECT文を構文木にして実行する
プランナ（コスト計算） — 候補の列挙とコスト比較。EXPLAIN の出力が「自分が書いたのと同じもの」に見えるようになる
WAL + クラッシュリカバリ — 学びが最も大きい。fsyncのタイミングを誤るとデータが失われることを自分で体験する
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側にはコストベースのプランナが存在しないのか

答えられれば比較の観点が身についている。詳細は実行計画のメモを参照。

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

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

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

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

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

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

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

注意点

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

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

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

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