MongoDB の一般的なデータモデリングパターンにはどのようなものがありますか?

Question

Accepted Answer

基本的な「埋め込みか参照か」の判断を超えて、MongoDB には確立された **データモデリングパターン** があります ── 大きな配列、ポリモーフィックなデータ、リレーションシップといった一般的なシナリオに対する実証済みの解決策です。これらを知っておくと、現実的な状況に対して効果的なスキーマを設計するのに役立ちます。

## Bucket パターン ── 時系列/関連データをまとめる

```js
// instead of one document per reading (millions of tiny docs), BUCKET them:
{
  sensorId: "s1",
  date: ISODate("2024-01-15"),
  readings: [                            // a day's readings in one document
    { time: "10:00", value: 23 },
    { time: "10:01", value: 24 }
  ]
}
// → fewer documents, efficient for time-series/IoT data
```

## Subset パターン ── 頻繁に使う部分集合を埋め込む

```js
// embed the most-used part, reference the rest (for large related data)
{
  _id: ObjectId("..."),
  title: "Product",
  recentReviews: [ /* 5 most recent — embedded for fast display */ ],
  // full reviews live in a separate collection (referenced)
}
// → fast common reads without loading ALL related data
```

## Computed パターン ── 事前計算して保存する

```js
// store precomputed values (avoid recomputing on every read)
{ productId: "p1", totalReviews: 1500, avgRating: 4.5 }
// → update these when reviews change; reads are fast (no aggregation needed)
```

## Extended Reference パターン ── 主要な参照フィールドを埋め込む

```js
// embed the OFTEN-NEEDED fields of a referenced document (avoid a join for common reads)
{ orderId: "o1", customer: { _id: "u1", name: "Ann", city: "NY" } }  // enough for display
// → reference customer._id for full data; embed name/city for the common read
```

## その他のパターン

```text
Polymorphic    → different document shapes in one collection (with a "type" field)
Schema Versioning → a version field to handle evolving schemas in one collection
Outlier        → handle rare documents that don't fit the common pattern specially
Approximation  → store approximate values (e.g. view counts) to reduce write load
Tree/Hierarchy → patterns for hierarchical data (parent refs, arrays of ancestors, etc.)
```

## なぜ重要なのか

MongoDB の一般的なデータモデリングパターンを理解しておくことは、**現実的なシナリオに対して効果的なスキーマを設計する** うえで価値があり、基本的な「埋め込みか参照か」の判断の上に積み上がる有用な知識です。

埋め込みと参照は中核的な選択ですが、現実のアプリケーションはこれらの実証済みパターンが対処する繰り返し現れるモデリング課題に直面します。**Bucket パターン**(時系列/IoT の測定値を少数のドキュメントにまとめる ── 何百万もの小さなドキュメントを避ける、一般的な時系列ユースケースで重要)、**Subset パターン**(頻繁に使う部分集合を埋め込みつつ完全なデータは参照する ── 大きな関連データに対して読み取り性能とドキュメントサイズのバランスを取る)、**Computed パターン**(合計や平均などの値を事前計算して保存し、読み取り時の高コストな再計算を避ける)、**Extended Reference パターン**(参照先ドキュメントの頻繁に必要なフィールドを埋め込み、一般的な読み取りで join を避ける ── 実用的なハイブリッド)、そしてその他(多様な形状のための polymorphic、進化のための schema versioning、階層のための tree パターン)です。

これらのパターンを知っておくと、設計を一から作り直すのではなく、一般的なシナリオに対する **実証済みの解決策** が得られ、時系列データ、大きな関連コレクション、高コストな計算、階層データといった状況で健全なモデリング判断を下す助けになります。

現実の MongoDB アプリケーションはこうした繰り返し現れる設計課題に直面し、確立されたパターンは検証済みで効果的な解決策(性能と保守性の向上)を提供します。したがって、一般的な MongoDB データモデリングパターン ── bucket、subset、computed、extended reference、その他のパターン ── を理解することは、スキーマ設計を基本的な埋め込み/参照の選択から実証済みの解決策の適用へと引き上げる、実用的に重要な価値ある知識です。これは成熟した MongoDB 設計スキルを反映し、アプリケーション固有のアクセスパターンとデータ特性に対して高性能に動作するスキーマの構築に役立ちます。