無制限の配列を避ける
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
Overview
MongoDB の豊富なスキーマモデルの利点の 1 つは、配列をドキュメントフィールド値として保存できることです。配列をフィールド値として保存すると、リレーショナルデータベースのように別々のコレクションをまたがるのではなく、1 つのドキュメントで 1 対多または多対多の関係データベースをモデル化できます。
ただし、ドキュメント内の配列に要素を継続的に追加する場合は注意が必要です。配列の要素数を制限しないと、ドキュメントが予想外の大きさになる可能性があります。配列が大きくなるにつれて、その配列のインデックスの読み取りと構築のパフォーマンスは徐々に低下します。配列が大きくなると、アプリケーションのリソースに負担がかかり、ドキュメントが BSON ドキュメント サイズの制限を超えるリスクがあります。
あるいは、パフォーマンスを向上させ、ドキュメントを管理しやすいサイズに保つために、配列に境界を設定することも検討できます。
例
次の publishers
コレクションのスキーマを考えてみましょう。
// publishers collection { "_id": "orielly" "name": "O'Reilly Media", "founded": 1980, "location": "CA", "books": [ { "_id": 123456789, "title": "MongoDB: The Definitive Guide", "author": [ "Kristina Chodorow", "Mike Dirolf" ], "published_date": ISODate("2010-09-24"), "pages": 216, "language": "English" }, { "_id": 234567890, "title": "50 Tips and Tricks for MongoDB Developer", "author": "Kristina Chodorow", "published_date": ISODate("2011-05-06"), "pages": 68, "language": "English" } ] }
このシナリオでは、 books
配列は無制限です。この出版会社から新しい書籍がリリースされるたびに、 books
配列に新しいサブドキュメントが追加されます。出版会社が書籍をリリースし続ければ、ドキュメントはやがて非常に大きくなり、アプリケーションに不釣り合いな量のメモリ負荷をかけることになります。
可変で境界のない配列を避けるためには、 publishers
コレクションを 2 つのコレクションに分割します。1 つはpublishers
で、もう 1 つはbooks
用です。 book
ドキュメント全体をpublishers
ドキュメントに埋め込む代わりに、書籍ドキュメントの中に出版社への 参照 を含めます。
// publishers collection { "_id": "oreilly" "name": "O'Reilly Media", "founded": 1980, "location": "CA" }
// books collection { "_id": 123456789, "title": "MongoDB: The Definitive Guide", "author": [ "Kristina Chodorow", "Mike Dirolf" ], "published_date": ISODate("2010-09-24"), "pages": 216, "language": "English", "publisher_id": "oreilly" } { "_id": 234567890, "title": "50 Tips and Tricks for MongoDB Developer", "author": "Kristina Chodorow", "published_date": ISODate("2011-05-06"), "pages": 68, "language": "English", "publisher_id": "oreilly" }
この更新されたスキーマでは、publishers
コレクション内の境界のない配列が削除され、publisher_id
フィールドを使用して各書籍ドキュメントに出版者への参照が配置されます。これにより、各ドキュメントのサイズが管理可能になり、ドキュメントフィールドが異常に大きくなるリスクがなくなります。
ドキュメントの参照が必要な場合があります。 $lookups
この方法は、アプリケーションが書籍と出版会社の情報を個別に読み込む場合に特に適しています。アプリケーションで書籍と情報を一緒に必要とする場合は、 $lookup
操作を実行して、 publishers
と books
のコレクションのデータを結合する必要があります。$lookup
操作はあまりパフォーマンスが良くありませんが、このシナリオでは無制限の配列を回避するためにトレードオフの価値があるかもしれません。
詳細
MongoDB のデータ モデリングと柔軟なスキーマ モデルの詳細については、「データ モデリングの概要」を参照してください。
ドキュメント参照との関係のモデル化方法については、「 ドキュメント参照を使用した 1 対多の関係のモデル化 」を参照してください
MongoDB で配列をクエリする方法については、「 配列のクエリ 」を参照してください。
MongoDB では、データ モデリングに関する無料の MongoDB University コース「 MongoDB のデータ モデリング 」も提供しています。
MongoDB.Live 2020 のプレゼンテーション
柔軟なデータモデルをスキーマに組み込む方法については、MongoDB.live 2020 の以下のプレゼンテーションを参照してください。
MongoDB のエンティティ関係と、MongoDB を使用したデータ モデリングによるその実装例について学びます。
スキーマに組み込むことができる高度なデータモデリング設計パターンについて学ぶには、「高度なスキーマ デザイン パターン」をご覧ください。