RDB と NoSQL の違い

RDB の世界観：表・スキーマ・関係

RDB は、現実を正規化された複数の表に分解して持ちます。たとえば「ユーザー」と「注文」を別の表に分け、注文側はユーザーの ID（外部キー）だけを持つ。重複を排し、矛盾が起きにくい構造です。

-- ユーザーと注文を別テーブルで持ち、JOIN で結合する
SELECT u.name, o.total
FROM   users u
JOIN   orders o ON o.user_id = u.id
WHERE  u.id = 42;

RDB の3本柱を押さえておきましょう。

• スキーマが厳格: 列名・型・制約（NOT NULL、UNIQUE など）を先に定義する。形を破るデータは弾かれるので、品質が保たれる。
• JOIN: 分けて持った表を、その場で結合して「ユーザー名＋注文額」のような横断ビューを作れる。
• ACID: 複数の更新をまとめて全部成功か全部失敗かにできる（→ 詳しくは トランザクション）。送金で「引いたのに足されない」を防ぐ要。

代表例は PostgreSQL や MySQL、組込みの SQLite です。

NoSQL の世界観：形の自由と横へのスケール

NoSQL は「表に当てはめにくいデータ」「とにかく量とアクセスをさばきたいデータ」のために生まれました。共通する性格は次のとおりです。

• スキーマ柔軟: レコードごとに項目が違っても OK。仕様変更で列追加…の手間が要らない（ただし"無秩序"とは別物）。
• 水平スケール（スケールアウト）: データを複数サーバーに分割（シャーディング）して、台数を足すほど容量・性能が伸びる設計が前提。
• 結果整合（Eventual Consistency）: 書いた直後に全サーバーへ反映されるとは限らず、「しばらくすれば全員同じになる」を許容することで、可用性と速度を稼ぐ。

NoSQL の4つの種類

ひとくちに NoSQL と言っても、データモデルで大きく4つに分かれます。

• ドキュメント型（例: MongoDB）: 関連データを1つの入れ子ドキュメントにまとめて持つので、JOIN せずに一発で取れる。
• KV型（例: Redis）: 「キーで引いて値を返す」だけに特化。キャッシュやセッション置き場の定番。
• ワイドカラム型（例: Cassandra）: 行ごとに列構成が違ってよい分散表。書き込みスループットと水平スケールに強い。
• グラフ型: データ同士のつながりを主役にする。SNS の交友関係や経路探索で、RDB の多段 JOIN より自然・高速に扱える。

全文検索に特化した Elasticsearch のような製品も、広い意味では NoSQL の仲間として語られることがあります。

どこが本質的に違う？

設計思想の対比として、RDB の ACID に対し、NoSQL でよく語られるのが BASE（Basically Available, Soft state, Eventual consistency）という考え方です。「常に最新で一貫」より「止まらず使えて、いずれ揃う」を優先する、という方向性の違いと捉えると分かりやすいです。

つまずきポイント

使い分けの指針

最後に、選ぶときの目安をまとめます。

• RDB が向く: 会計・在庫・予約など整合性が命／複数テーブルをまたぐ複雑な集計／データの形が安定している。
• NoSQL が向く: ログ・イベント・IoT など書き込み量が膨大／キャッシュやセッションの超高速な単純アクセス／JSON のような入れ子で形が一定でないデータ／SNS の交友関係のようなつながりの探索。
• 両方使う（ポリグロット・パーシステンス）: 本体データは RDB、キャッシュは KV、検索は全文検索エンジン…と適材適所で併用するのが今や普通。「どちらか一方」と決めつける必要はありません。

迷ったら、**「このデータをどう読むか」**から逆算するのが王道です。読み方が決まれば、必要な構造・整合性・スケール特性がはっきりし、RDB か NoSQL か、NoSQL ならどの型か、が自ずと絞れます。