RDB vs NoSQL - 違い・使い分け・代表的なデータベース比較

データベースの大きな分類として、従来のリレーショナルデータベース（RDB）と、それ以外のNoSQLがある。それぞれの特性を理解して用途に応じて使い分けることが重要。

RDB（リレーショナルデータベース）

概要

テーブル（表）形式でデータを管理し、SQL（Structured Query Language）で操作する。1970年代に考案されたモデルで、現在も最も広く使われている。

特徴

特性説明
スキーマテーブル定義（スキーマ）が必須。構造が明確で型安全
ACID特性Atomicity・Consistency・Isolation・Durability を保証
正規化データの重複を排除し、整合性を維持する
リレーションテーブル間をJOINで結合して複雑なクエリが可能
標準言語SQL が標準化されており、製品間での知識の移転が容易

ACID特性

特性日本語内容
Atomicity原子性トランザクション内の処理は全て成功するか全て失敗する
Consistency一貫性トランザクション前後でデータの整合性が保たれる
Isolation分離性並行実行されるトランザクションが互いに影響しない
Durability永続性コミットされたデータは障害後も失われない

代表的なRDB

製品特徴用途
PostgreSQL高機能・拡張性が高い・JSONサポートも充実Webアプリ全般、複雑なクエリ
MySQL / MariaDB高速・広く普及・エコシステムが豊富Webアプリ全般
SQLiteファイルベース・サーバー不要組み込み、モバイルアプリ、開発・テスト
Oracle Databaseエンタープライズ向け・高可用性大規模基幹システム
SQL ServerWindows/.NET との親和性が高いWindowsエンタープライズ環境

NoSQL

概要

“Not Only SQL” の略。RDBの制約にとらわれず、用途に特化した様々なデータモデルを持つデータベースの総称。スケールアウトや柔軟なスキーマが必要な場面で活用される。

NoSQL は大きく4種類に分類される。

1. ドキュメントDB

JSONやBSONなどのドキュメント形式でデータを格納する。ネストしたデータ構造をそのまま保存できる。

{
  "_id": "user-001",
  "name": "田中太郎",
  "email": "tanaka@example.com",
  "address": {
    "prefecture": "東京都",
    "city": "渋谷区"
  },
  "tags": ["premium", "active"]
}
製品特徴
MongoDB最も普及したドキュメントDB。柔軟なクエリ
FirestoreGoogleのサーバーレス型。リアルタイム同期
CouchDBHTTP/JSON API ネイティブ

向いているユースケース: ユーザープロフィール、商品カタログ、コンテンツ管理、スキーマが頻繁に変わるデータ

2. キーバリューストア（KVS）

キー（Key）と値（Value）のシンプルなペアでデータを格納する。最もシンプルな構造で、高速な読み書きが特徴。

SET session:abc123  "{userId: 1, role: admin}"
GET session:abc123  →  "{userId: 1, role: admin}"
製品特徴
Redisインメモリ・リスト/セット/ソート済みセットなどのデータ型が豊富
Memcachedシンプルなインメモリキャッシュ
DynamoDBAWSのフルマネージドKVS/ドキュメントDB

向いているユースケース: セッション管理、キャッシュ、レートリミット、リアルタイムランキング

3. カラム指向DB（ワイドカラム）

行ではなく列（カラム）単位でデータを格納する。大量データの集計・分析クエリに特化している。

製品特徴
Apache Cassandra分散・高可用性・書き込み特化
HBaseHadoop上のカラム指向DB
Google BigtableGCPのフルマネージド。Cassandraの原型

向いているユースケース: IoTデータ、ログ分析、時系列データ、書き込みが多い大規模システム

4. グラフDB

ノード（頂点）とエッジ（辺）でデータ間の関係を表現する。複雑な関係性のトラバーサルに特化している。

(田中) -[FRIENDS_WITH]-> (佐藤)
(田中) -[PURCHASED]-> (商品A)
(佐藤) -[PURCHASED]-> (商品A)
製品特徴
Neo4j最も普及したグラフDB。Cypher クエリ言語
Amazon NeptuneAWSのフルマネージドグラフDB

向いているユースケース: SNSの友人関係、レコメンデーション、不正検知、知識グラフ

RDB vs NoSQL 比較

項目RDBNoSQL
データモデルテーブル（行・列）ドキュメント/KV/カラム/グラフ
スキーマ固定（事前定義が必要）柔軟（後から変更しやすい）
クエリ言語SQL（標準化）製品ごとに異なる
トランザクションACID保証（複数テーブルも可）製品による（基本的に限定的）
スケーリング垂直スケールが基本（水平も可）水平スケールが得意
整合性強整合性結果整合性が多い（CAP定理）
JOINクエリ得意基本的に苦手
学習コストSQL の知識が広く流通製品ごとに学習が必要

CAP定理

分散システムでは以下の3つの特性を同時に全て満たすことはできない。

特性説明
Consistency（一貫性）全ノードが常に同じデータを返す
Availability（可用性）全てのリクエストに応答を返す
Partition Tolerance（分断耐性）ネットワーク分断が起きても動作し続ける

分散DBはネットワーク分断（P）が避けられないため、実質的には CP（一貫性優先） か AP（可用性優先） の選択になる。

分類例特性
CPHBase, Zookeeper分断時は可用性を犠牲にして一貫性を保つ
APCassandra, DynamoDB分断時も応答を返す（一時的に古いデータを返す可能性あり）
CAPostgreSQL, MySQL単一ノード（分散しない）場合は両立可能

使い分けのガイド

flowchart TD
  A[データベース選定] --> B{データの性質}

  B --> C["複雑なリレーション<br/>・トランザクションが重要"]
  B --> D["大量・高速書き込み<br/>スキーマが変わりやすい"]

  C --> R1[RDB<br/>PostgreSQL / MySQL]

  D --> E{用途}
  E --> E1[セッション・キャッシュ] --> R2[KVS: Redis]
  E --> E2["ユーザー・コンテンツ<br/>柔軟なスキーマ"] --> R3[ドキュメント: MongoDB]
  E --> E3["IoT・ログ・時系列<br/>大量書き込み"] --> R4[カラム: Cassandra]
  E --> E4[関係性のトラバーサル] --> R5[グラフ: Neo4j]

組み合わせて使う

現代のシステムでは、1つのアプリケーションに複数のDBを使い分けることが一般的（ポリグロットパーシステンス）。

メインデータ    → PostgreSQL（ユーザー・注文・商品）
セッション      → Redis（高速アクセス・TTL管理）
検索インデックス → Elasticsearch（全文検索）
キャッシュ      → Redis / Memcached

参考リンク