ストーリー

「新しいプロジェクトのデータベースはMongoDBでいきましょう！」

チームメンバーの提案に、高橋アーキテクトが落ち着いて問いかける。

「なぜMongoDBなんだ？ 技術選定は『使いたいから』ではなく『要件に合っているから』で判断する。RDBとNoSQL、それぞれの強みと限界を正しく理解した上で選ぶんだ」

判断フレームワーク

Step 1: データの特性を分析する

Step 2: アクセスパターンを分析する

比較表

ユースケース別の推奨

RDBが適しているケース

1. 金融・決済システム
   → ACID トランザクションが必須
   → 複雑なリレーションと整合性制約

2. ERPシステム
   → 構造化された定型データ
   → 複雑なレポート・集計クエリ

3. ユーザー管理・認証
   → 一意性制約（email, username）
   → 外部キーによる参照整合性

// RDB向き: 送金処理（ACID必須）
async function transferFunds(
  fromAccountId: number,
  toAccountId: number,
  amount: number
): Promise<void> {
  await prisma.$transaction(async (tx) => {
    // 送金元の残高を減らす
    const from = await tx.account.update({
      where: { id: fromAccountId },
      data: { balance: { decrement: amount } },
    });

    if (from.balance < 0) {
      throw new Error('Insufficient funds');
    }

    // 送金先の残高を増やす
    await tx.account.update({
      where: { id: toAccountId },
      data: { balance: { increment: amount } },
    });
  });
}

NoSQLが適しているケース

1. SNSのタイムライン
   → 大量の書き込みと読み込み
   → 柔軟なコンテンツ構造（テキスト、画像、動画）

2. IoTデータ
   → 大量の時系列データの書き込み
   → 水平スケールが必須

3. リアルタイムゲーム
   → サブミリ秒のレスポンス要件
   → セッション状態の高速管理

4. コンテンツ管理（CMS）
   → 各記事が異なる構造を持つ
   → スキーマの柔軟性が必要

// NoSQL向き: CMSのコンテンツ管理（MongoDB）
// 記事の種類によって構造が異なる
const blogPost = {
  _id: new ObjectId(),
  type: 'blog',
  title: 'MongoDBの使い方',
  body: '...',
  tags: ['mongodb', 'database'],
  author: { name: '田中', avatar: '/img/tanaka.jpg' },
};

const photoGallery = {
  _id: new ObjectId(),
  type: 'gallery',
  title: '春の写真集',
  photos: [
    { url: '/img/1.jpg', caption: '桜', exif: { camera: 'Sony A7', iso: 400 } },
    { url: '/img/2.jpg', caption: '梅', exif: { camera: 'Canon R5', iso: 200 } },
  ],
};

CAP定理

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

    Consistency（一貫性）
        /\
       /  \
      /    \
     / CAP  \
    /________\
Availability    Partition Tolerance
（可用性）        （分断耐性）

よくある間違い

判断フローチャート

データに強い整合性が必要？
├── Yes → RDB（PostgreSQL, MySQL）
└── No
    ├── アクセスパターンは Key-Value 型？
    │   ├── Yes → Redis / DynamoDB
    │   └── No
    │       ├── データ構造が柔軟？
    │       │   ├── Yes → MongoDB
    │       │   └── No
    │       │       ├── 時系列データの大量書き込み？
    │       │       │   ├── Yes → Cassandra / TimescaleDB
    │       │       │   └── No
    │       │       │       └── 関係性の深い探索？
    │       │       │           ├── Yes → Neo4j
    │       │       │           └── No → RDB

まとめ

理解度チェックリスト

• RDBとNoSQLの特性の違いを5つ以上挙げられる
• ユースケースに応じた適切なデータストアを選択できる
• CAP定理を説明できる
• 「NoSQLを選ぶべきではない」ケースを判断できる

次のステップ

次は演習：NoSQLで設計しよう。実際のシナリオに対して最適なNoSQLデータストアを選び、データモデルを設計する。

推定読了時間: 25分