リレーショナルデータベース(RDBMS)
Relational Database (RDBMS)
データを行と列のテーブルで管理し、トランザクションがACIDを満たすデータベース。整合性と複雑なクエリに強い。MySQL / PostgreSQL など。
ACIDを身近な例で
ACIDは『トランザクション(一連の処理のまとまり)が信頼できる』ための4つの保証です。銀行振込で考えると腑に落ちます。
- Atomicity(原子性): 『Aから引いてBに足す』は全部成功か、全部なかったことにするかの二択。Aから引いた直後に落ちて、Bに足されない…が起きない。
- Consistency(一貫性): 処理の前後でルールが守られた正しい状態を保つ(残高がマイナスにならない等)。
- Isolation(分離性): 複数の振込が同時に走っても、1件ずつ順番にやったのと同じ結果になる。途中の中途半端な状態を他から見せない。
- Durability(永続性): 『振込完了』と言ったら、たとえ直後に停電してもその記録は消えない。
図を描画中...
なぜRDBMSは『複雑なクエリ』に強いのか
テーブル同士を**JOIN(結合)**でつなげるから。『この注文をしたユーザーの住所一覧』のような、複数の表をまたぐ問い合わせを1つのSQLで書けます。NoSQLではこれをアプリ側のコードで頑張る必要があります。
スケールの6つの武器(概要)
大きくなったRDBMSをスケールさせる手法は6つ。それぞれ個別のコンセプトとして詳しく扱いますが、まず地図として:
図を描画中...
- レプリケーション: 同じデータのコピーを増やして読みを分散。
- Federation: 機能ごとにDBを分ける(ユーザー用、商品用…)。
- Sharding: 同じテーブルを行で分割して別DBに置く。
- Denormalization: あえて冗長にコピーを持ってJOINを減らす。
- SQLチューニング: インデックスやスキーマを最適化する。
つまずきポイント
- ACIDの中でも特に Isolation が分かりにくい。『同時にたくさん走っても、1件ずつ順にやったかのような正しい結果になる』保証だと覚える。
- スケール技法は『どれか1つ』ではなく組み合わせて使う。まずレプリケーションとチューニング、それでも足りなければFederation、最後にSharding、という順序感がある。