mongodb-usage

MongoDB のベストプラクティス

MCP の制限事項

この MCP は読み取り専用モードで動作します。 書き込み、更新、削除の操作はできません。

スキーマ設計パターン

埋め込みと参照の使い分け

埋め込む場合：

• データが頻繁に一緒にアクセスされる
• 子ドキュメントのサイズに上限がある（際限なく増加しない）
• 1 対少数のリレーションシップ
• データが頻繁に変更されない

参照する場合：

• データに個別にアクセスする
• 多対多のリレーションシップ
• ドキュメントが 16MB の上限を超える
• 参照先のデータが頻繁に更新される

よく使われるパターン

サブセットパターン： 頻繁にアクセスするサブセットを親に保存し、すべてのデータを別のコレクションに保存します。

バケットパターン： 時系列データをバケットにグループ化します（例：1 時間ごとの測定値を 1 つのドキュメントにまとめます）。

計算済みパターン： コストの高い計算に使う値を事前に計算して保存します。

インデックス戦略

インデックスのガイドライン

• クエリ、ソート、集約の $match ステージで使用するフィールドにインデックスを設定します
• 複合インデックスは、先頭のフィールドに対するクエリをサポートします
• カバリングクエリ（すべてのフィールドがインデックスに含まれるクエリ）が最速です
• インデックスが多すぎると書き込みが遅くなります

インデックスの種類

• 単一フィールド： 1 つのフィールドに対する基本的なインデックス
• 複合： 複数のフィールドを対象とするインデックス。クエリでは順序が重要です
• マルチキー： 配列フィールドに対して自動的に作成されます
• テキスト： 文字列の内容を対象とする全文検索
• TTL： 一定時間が経過したドキュメントを自動的に期限切れにします

ESR ルール

複合インデックスでは、フィールドを次の順序に並べます。

1. Equality（完全一致するフィールド）
2. Sort（ソート順のフィールド）
3. Range（$gt、$lt などの範囲クエリのフィールド）

集約パイプライン

パフォーマンスのヒント

• ドキュメント数を減らすため、$match と $project を早い段階に配置します
• 可能な場合は $limit を早い段階で使用します
• インデックスのない大規模なコレクションに対する $lookup は避けます
• 1 つのクエリで複数の集約を行うには $facet を使用します

よく使われるステージ

// Filter documents
{ $match: { status: "active" } }

// Reshape documents
{ $project: { name: 1, total: { $sum: "$items.price" } } }

// Group and aggregate
{ $group: { _id: "$category", count: { $sum: 1 } } }

// Sort results
{ $sort: { count: -1 } }

// Join collections
{ $lookup: { from: "orders", localField: "_id", foreignField: "userId", as: "orders" } }

接続のベストプラクティス

接続文字列の形式

• Atlas： mongodb+srv://user:[email protected]/database
• ローカル： mongodb://localhost:27017/database
• レプリカセット： mongodb://host1,host2,host3/database?replicaSet=rs0

コネクションプーリング

• アプリケーションではコネクションプーリングを使用します（ドライバーではデフォルトで有効です）
• ワークロードに適したプールサイズを設定します
• リクエストごとに新しい接続を作成しないでください

避けるべきアンチパターン

• 上限のない配列： 制限なく増加する配列
• 巨大なドキュメント： 16MB に近いサイズのドキュメント
• コレクションの作りすぎ： 代わりに埋め込みを使用します
• インデックスの不足： コレクション全体をスキャンするクエリ
• $where 演算子： セキュリティのため、代わりに集約を使用します
• ドキュメント内へのファイル保存： 大きなファイルには GridFS を使用します