理Kotowary

DBサーバ — データを整理して保管する係

大人こども
初級中級上級

概要 — まず全体をつかむ

中級ではインデックス・ACID・実行計画を見ました。上級では、同時実行・耐久性・分散の内部へ。

詳細 — 1段階ずつ追う

同時実行制御の実装

多数のトランザクションが同時に走る中で、正しさ（分離性）をどう保つか。

  • MVCC — 行の複数版を保持し、読み手はスナップショットを読む。読み書きが互いをブロックしにくい
  • ロックとラッチ — 論理的な整合のためのロックと、内部データ構造を守る短命のラッチは別物
  • 分離レベルの実体 — READ COMMITTED / REPEATABLE READ / SERIALIZABLE を、MVCCやロックでどう実現するか
やさしく言うと（中級）

多くのWebサービスの中心にあるのはリレーショナルDB（RDB）。データを表（テーブル）に持ち、表どうしをキーで関連づけます。

  • 主キー — 各行を一意に識別する項目（例：ユーザーID）
  • 外部キー — 別の表の主キーを指して関連づける（例：注文の「ユーザーID」）
  • 正規化 — 同じデータの重複を減らし、矛盾が起きにくい形に整理する

登場人物メモ:

  • ※1 インデックス（B-tree） — 木構造で範囲・一致を素早く探す索引。書き込みは少し重くなる
  • ※2 トランザクション（ACID） — 原子性・一貫性・独立性・永続性を満たす処理のまとまり

1クエリが実行されるまで

  1. パース — SQLを構文木に
  2. オプティマイザ — 統計情報をもとにコストベースで複数の実行計画を比較し、最良を選ぶ
  3. 実行計画 — インデックス走査／シーケンシャルスキャン／各種JOIN（ネステッドループ・ハッシュ・マージ）を組む
  4. 実行 — バッファプール（メモリ上のページキャッシュ）を介してストレージにアクセス
  5. コミット — WAL に先行して記録し、耐久性を確保
やさしく言うと（中級）
  1. バックから SQL を受ける（SELECT／INSERT など）
  2. 実行計画を立て、インデックスが使えるかを判断する
  3. 使えれば索引で該当行へ、使えなければフルスキャン（遅い）
アニメーション『インデックスと全表走査』を開く
インデックスなし＝全表走査（フルスキャン）1行ずつ全部見る行 1確認…行 2確認…行 3確認…行 4確認…行 5確認…行 6確認…行 7← 目的の行（7件目でやっと）行 8確認…行 9確認…9行すべて走査（遅い）インデックスあり＝B木で当たりをつける根（索引）まず範囲で判断枝6〜9枝1〜5目的の行7 に到達行 8–9行 1–3行 4–5①②③根 → 枝 → 目的の行 の 3ステップ で到達見る行はごくわずか（速い）索引で「当たりをつけて」一気に絞る ― 9行を見るか、3ステップで着くかの差
  1. 更新系はトランザクションでまとめ、確定（コミット）で永続化する

トランザクションの核が原子性（Atomicity）。「全部成功か、全部なかったことに」で、送金のように「引く」だけ成功して「足す」が失敗、という中途半端を防ぎます。

アニメーション『トランザクション（全部か、なしか）』を開く
原子性（Atomicity）＝「全部成功か、全部なかったことに」例：送金（Aから引く → Bへ足す）の2ステップ① 両方できた① Aから 200円 引くA: 1000 → 800✓② Bへ 200円 足すB: 500 → 700✓コミット（確定）2つとも反映して確定A: 800円B: 700円両方反映ずみ② 途中で失敗① Aから 200円 引くA: 1000 → 800✓② Bへ 200円 足す…失敗して中断✗ロールバック全部取り消し・Aの引き落としも戻すA: 1000円B: 500円元通り（無かったことに）「Aから引いただけ／Bへ足しただけ」という中途半端は起きない

内部構造とアクセス

  • B+木 — 葉に実データ（またはポインタ）を並べ、範囲検索と順次走査に強い
  • インデックス種類 — B+木のほか、ハッシュ、GiST、全文、カバリングインデックス
  • 分離の異常 — ダーティリード／ノンリピータブルリード／ファントム。どれを許すかが分離レベル
  • 統計とプラン — 統計が古いと最適でない計画を選ぶ（プラン劣化）
  • バッファ管理 — ページの置き換え、チェックポイント、ダーティページのフラッシュ
やさしく言うと（中級）
  • インデックス設計 — よく使う検索条件に合わせて張る。多すぎると書き込みが重い
  • ロック／独立性 — 同時更新の衝突を防ぐが、待ち合わせがデッドロックを生むことも
  • レプリケーション — 同じDBの複製を用意し、読み取りを分散／障害に備える
  • シャーディング — データを複数に分割して1台の限界を超える（運用は複雑）
  • NoSQLとの使い分け — 表に馴染まないデータ（大量ログ・柔軟な構造）には別種のDBも

分散という次の壁

  • レプリケーション — 同期／非同期。非同期は遅延（レプリカラグ）で古い読みが起きる
  • シャーディング — キーで分割。クロスシャードのJOINやトランザクションが難所
  • 合意 — 分散で1つの真実を決めるための Raft／Paxos
  • CAP／PACELC — 分断時に一貫性か可用性か。平常時も遅延と一貫性のトレードオフがある
  • ホットスポット — 特定キーへの集中で、分割しても偏る
やさしく言うと（中級）
  • フルスキャンで遅い — インデックス不足／条件の書き方でインデックスが効かない
  • デッドロック — 複数トランザクションが互いのロックを待って止まる
  • N+1問題 — アプリ側が行ごとにクエリを乱発（JOINやまとめ取得で回避）
  • 整合性の乱れ — キャッシュやレプリカとの時間差（stale）を考慮していない

理解度チェック

そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

問1. コミットを「まず先行ログに追記して耐久性を確保し、本体は後で反映」する仕組みは？

問2. 「読み手はロックを待たず、書き込みの前の版（スナップショット）を読む」同時実行制御は？

問3. コストベースのオプティマイザが実行計画を選ぶ基準として正しいのは？

問4. B+木インデックスが特に強いのはどれ？

問5. 1トランザクション内で同じ行を2度読むと、間に他が更新して値が変わってしまう分離異常はどれ？

問6. 分散環境で複数ノードが「1つの真実」を一致して決めるための合意アルゴリズムはどれ？

問7. ネットワーク分断が起きたとき、一貫性(C)と可用性(A)のどちらかしか選べないことを示す定理を英字3文字で答えてください。

問8. 非同期レプリケーションで、複製先（レプリカ）が本体より遅れて古い状態になる、その遅延を何と呼ぶか（カタカナで）。