SQLとNoSQLの違い - データベース選択の指針

データベースの種類

データベースは大きく分けて、SQL（リレーショナル）とNoSQL（非リレーショナル）の2種類があります。どちらが優れているというわけではなく、用途に応じた選択が重要です。

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

特徴

• テーブル（行と列）でデータを格納
• スキーマ（データ構造）を事前に定義
• SQLによる標準化されたクエリ言語
• ACID特性によるトランザクション保証

-- テーブル定義
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(255) UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  user_id INTEGER REFERENCES users(id),
  total DECIMAL(10, 2),
  status VARCHAR(20)
);

-- リレーションを使ったクエリ
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.status = 'completed';

ACID特性

代表的なデータベース

NoSQL

種類と特徴

1. ドキュメント型

JSONライクなドキュメントでデータを格納します。

// MongoDB の例
{
  "_id": "user_123",
  "name": "Alice",
  "email": "alice@example.com",
  "orders": [
    { "id": "ord_1", "total": 5000, "items": [...] },
    { "id": "ord_2", "total": 3000, "items": [...] }
  ],
  "preferences": {
    "theme": "dark",
    "language": "ja"
  }
}

代表例: MongoDB, CouchDB, Firestore

2. キーバリュー型

シンプルなキーと値のペアでデータを格納します。

user:123:name → "Alice"
user:123:email → "alice@example.com"
session:abc123 → { "userId": 123, "expires": "..." }

代表例: Redis, Amazon DynamoDB, etcd

3. カラム指向型

行ではなく列単位でデータを格納します。大量データの集計に適しています。

flowchart TB
    subgraph RowBased["行ベース格納"]
        R1["user_1 | Alice | alice@ex.com"]
        R2["user_2 | Bob | bob@ex.com"]
    end

    subgraph ColumnBased["列単位で格納"]
        C1["name → Alice, Bob, ..."]
        C2["email → alice@ex.com, bob@ex.com, ..."]
    end

    RowBased --> ColumnBased

代表例: Apache Cassandra, HBase, ClickHouse

4. グラフ型

ノードとエッジの関係でデータを格納します。

(Alice)--[FOLLOWS]-->(Bob)
(Alice)--[LIKES]-->(Post1)
(Bob)--[WROTE]-->(Post1)

代表例: Neo4j, Amazon Neptune, ArangoDB

CAP定理

分散システムでは、以下の3つの特性のうち2つまでしか同時に満たせないという定理です。

flowchart TB
    subgraph CAP["CAP定理"]
        C["Consistency<br/>（一貫性）"]
        A["Availability<br/>（可用性）"]
        P["Partition Tolerance<br/>（分断耐性）"]

        CP["CP: MongoDB, Redis Cluster"]
        AP["AP: Cassandra, CouchDB"]
        CA["CA: 単一ノードRDBMS"]

        C --- CP
        P --- CP
        A --- AP
        P --- AP
        C --- CA
        A --- CA
    end

分類例

• CP: MongoDB, Redis Cluster
• AP: Cassandra, CouchDB
• CA: 単一ノードのRDBMS（分散環境では実現困難）

比較表

ユースケース別の選択

SQLが適しているケース

✓ 複雑な関係を持つデータ（EC、CRM）
✓ 強いデータ整合性が必要（金融、在庫管理）
✓ 複雑なクエリ・集計が多い
✓ スキーマが安定している

NoSQLが適しているケース

✓ 大量の読み書きが必要（SNS、IoT）
✓ スキーマが頻繁に変わる
✓ 水平スケーリングが必要
✓ 地理的に分散したデータ

具体例

ポリグロット永続化

1つのアプリケーションで複数のデータベースを使い分けるアプローチです。

flowchart LR
    App["ECアプリケーション"]
    App --> PG["PostgreSQL<br/>商品、注文、顧客"]
    App --> Redis["Redis<br/>セッション、キャッシュ"]
    App --> ES["Elasticsearch<br/>商品検索"]
    App --> Mongo["MongoDB<br/>商品レビュー、コンテンツ"]

まとめ

データベースの選択は、データの特性、スケーラビリティ要件、整合性要件に基づいて行います。SQLとNoSQLはトレードオフの関係にあり、どちらが優れているということはありません。適材適所で使い分け、必要に応じて複数のデータベースを組み合わせることで、最適なアーキテクチャを実現できます。