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

概要 — まず全体をつかむ

集めたデータをきちんとしまい、必要なときにサッと出す——それがDBサーバ(データベース)です。

詳細 — 1段階ずつ追う

これは何をする係?

よく整理された台帳図書館を想像してください。棚(※1 テーブル)に、1件ずつの記録(※2 行)が並び、それぞれに項目(列)がある。DBは、この整理された状態を保ち、探す・並べる・絞り込むのが得意です。

サーバ機器
DBサーバの実体もこうしたコンピュータ

たくさんの行から目的の1件を速く見つけるために、索引(※3 インデックス) を使います。本の巻末索引と同じ発想です。

登場人物メモ:

  • ※1 テーブル — 同じ種類のデータを集めた表(例:ユーザー表、注文表)
  • ※2 行(レコード) — 表の1件分(例:ユーザー1人)
  • ※3 インデックス — 素早く探すための索引
この部分をもっと深く(中級

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

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

登場人物メモ:

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

仕事の流れ

  1. バックエンドから「この条件のデータを探して」と頼まれる(※4 SQL)
  2. インデックスを使って素早く該当行を見つける
  3. 並べ替え・絞り込みをして返す
  4. 書き込みの依頼なら、記録して保存する(消えないように)

登場人物メモ:

  • ※4 SQL — DBへのお願いを書くための言葉(「この条件で探して」「これを保存して」)
この部分をもっと深く(中級
  1. バックから SQL を受ける(SELECTINSERT など)
  2. 実行計画を立て、インデックスが使えるかを判断する
  3. 使えれば索引で該当行へ、使えなければフルスキャン(遅い)
アニメーション『インデックスと全表走査』を開く
インデックスなし=全表走査(フルスキャン)1行ずつ全部見る行 1確認…行 2確認…行 3確認…行 4確認…行 5確認…行 6確認…行 7← 目的の行(7件目でやっと)行 8確認…行 9確認…9行すべて走査(遅い)インデックスあり=B木で当たりをつける根(索引)まず範囲で判断6〜91〜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へ足しただけ」という中途半端は起きない

DBとキャッシュ・ストレージの違い

  • DB — 表の形の構造データ(ユーザー・注文など)を、探しやすく保管
  • キャッシュ — よく使う答えを一時的に手元に(速いが消えてよい)
  • ストレージ — 画像・動画などの大きな塊(表には向かない)

「何でもDBに入れる」のではなく、向き不向きで置き場所を分けます。

この部分をもっと深く(中級
  • インデックス設計 — よく使う検索条件に合わせて張る。多すぎると書き込みが重い
  • ロック/独立性 — 同時更新の衝突を防ぐが、待ち合わせがデッドロックを生むことも
  • レプリケーション — 同じDBの複製を用意し、読み取りを分散/障害に備える
  • シャーディング — データを複数に分割して1台の限界を超える(運用は複雑)
  • NoSQLとの使い分け — 表に馴染まないデータ(大量ログ・柔軟な構造)には別種のDBも

⚠️ うまくいかないとき

  • 見つからない — 条件に合う行が無い(データ未登録/条件ミス)
  • 遅い — インデックスが無く、端から全部見ている
  • 重複・矛盾 — 同じデータが二重に入る(設計や制約で防ぐ)
この部分をもっと深く(中級
  • フルスキャンで遅い — インデックス不足/条件の書き方でインデックスが効かない
  • デッドロック — 複数トランザクションが互いのロックを待って止まる
  • N+1問題 — アプリ側が行ごとにクエリを乱発(JOINやまとめ取得で回避)
  • 整合性の乱れ — キャッシュやレプリカとの時間差(stale)を考慮していない

理解度チェック

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

1. 大量の行から目的の1件を素早く見つけるための「索引」を何と呼ぶ?

2. DBサーバが特に得意なことは?

3. DBへ「この条件で探して」「これを保存して」とお願いするための言葉を、英字3文字で答えてください。

4. 同じ種類のデータを集めた「表」を、DB用語で何と呼ぶか(カタカナで)。

5. テーブル(表)の「1件分の記録」を何と呼ぶ?

6. 「よく使う答えを一時的に手元に置き、速い代わりに消えても構わない」置き場はどれ?

7. 画像や動画のような「大きな塊」の保管に向くのはどれ?

8. 目的の1件を探すのが「遅い」ときの、よくある原因はどれ?