MongoDB のパフォーマンスを最適化するにはどうすればよいですか?

Question

Accepted Answer

MongoDB のパフォーマンス最適化は、**インデックス作成**（最大の効果）、アクセスパターンに合わせた**スキーマ設計**、効率的な**クエリ**、および **`explain()`** などのツールを使用したボトルネック発見に集中します。常に以下のとおりです：最初に測定してから、実際の問題（通常は欠落したインデックスまたは貧弱なスキーマ設計）を修正します。

## インデックス作成が最大の効果

```js
// use explain() to check if a query uses an index
db.users.find({ email: "ann@x.com" }).explain("executionStats");
// → look for: COLLSCAN (collection scan = BAD, no index) vs IXSCAN (index = GOOD)

db.users.createIndex({ email: 1 });   // add the missing index → fast
```

```text
✓ Index fields used in queries, sorts, and filters (the #1 optimization)
✓ Compound indexes for multi-field queries (mind the field order)
✓ explain() to verify queries use indexes (COLLSCAN = problem)
✓ Don't over-index (slows writes); index what's actually queried
```

## アクセスパターンに合わせたスキーマ設計

```text
✓ EMBED data accessed together → single-query reads (no joins)
✓ Reference large/unbounded/shared data appropriately
✓ Design around your QUERIES (the access-pattern principle) → most reads = one document
→ Poor schema design (e.g. needing many $lookups, huge documents) hurts performance
  more than almost anything else in MongoDB.
```

## クエリの最適化

```text
✓ Use PROJECTION — return only needed fields (less data transferred)
✓ Filter early; use covered queries (all fields from the index → no document fetch)
✓ In aggregation pipelines, put $match (and $limit) EARLY to reduce data through the pipeline
✓ Avoid querying without the shard key on sharded collections (scatter-gather)
✓ Use limit/pagination; prefer range-based over deep skip()
```

## その他の手法

```text
✓ Working set in RAM — frequently-accessed data + indexes should fit in memory
  (MongoDB caches in RAM; disk access is much slower)
✓ Connection pooling (drivers pool by default)
✓ Monitor: explain(), MongoDB profiler, Atlas Performance Advisor (suggests indexes)
✓ Avoid large/unbounded arrays; consider the bucket pattern for time-series
```

## なぜ重要なのか

MongoDB のパフォーマンス最適化は、MongoDB アプリケーションを高速に保つための価値のあるシニアレベルの知識であり、正しいアプローチ（測定駆動型で、インデックス作成とスキーマ設計が最大の手段）を理解することは、効果的な最適化に重要です。

**単一の最大の効果はインデックス作成**（リレーショナルデータベースと同じ）です：欠落したインデックスは **collection scans**（COLLSCAN — すべてのドキュメントをチェック、データが増えると極めて遅い）を引き起こし、クエリ対象/ソート対象/フィルタ対象フィールドに適切なインデックスを追加すると、これらは高速なインデックススキャンになります。**`explain()`** を使用してクエリがインデックスを使用していることを確認（COLLSCAN の問題を発見）することが主要な診断スキルです。**アクセスパターンに合わせたスキーマ設計**は、MongoDB ではおそらく SQL よりもさらに影響が大きいです：クエリの周囲に設計して（一緒にアクセスされるデータを埋め込んで単一クエリ読み取り、適切に参照）、ほとんどの読み取りが 1 つのドキュメントにアクセスするようにします。一方、不適切な設計（多くの `$lookup` が必要、巨大なドキュメント）はパフォーマンスを大きく損ないます。これにより、スキーマ設計は MongoDB の柔軟性に固有の最大の最適化手段になります。**クエリの最適化**（必要なフィールドのみを返すプロジェクション、カバード クエリ、集約パイプラインの早期に `$match`/`$limit` を配置してデータフローを削減、シャーディングされたコレクション上の scatter-gather の回避、効率的なページネーション）と**ワーキングセットが RAM に収まる**こと（頻繁にアクセスされるデータとインデックスがメモリにキャッシュされること、ディスクは大幅に遅いため）を確保することで、ツールキットが完成します。

**測定駆動型の規律**（explain()、プロファイラー、Atlas Performance Advisor を使用して実際のボトルネック（通常は欠落したインデックスまたは貧弱なスキーマ）を見つけて修正）は不可欠です。

MongoDB のパフォーマンスはアプリケーションにとって重要であり、適切な最適化（インデックス作成、スキーマ設計、クエリ効率、RAM のワーキングセット）はそれをスケール時に高速に保つものであるため、MongoDB のパフォーマンス最適化を理解すること（特にインデックス作成（explain() で確認）とアクセスパターン駆動型スキーマ設計を最大の手段として）は、パフォーマンスの高い MongoDB アプリケーションを運用するための価値のあるシニアレベルの知識であり、頻繁に関連する関心事であり、MongoDB を体系的に最適化する能力を示すトピックです。