これらすべての質問と同様に、主な決定要因の 1 つはデータのサイズと増加です。
ショップあたりのデータは 16 メガを超えますか? ショップが持つことができるアイテムの数と、単一のアイテムに起因するデータの量から判断すると、私はすぐにそう思います.
つまり、製品にいくつのフィールドがあるか想像してみてください。
- 製品番号
- 説明
- 価格
- オプション
- 通貨
- 宣伝文句
- SKU
- バーコード(または何でも)
これらのフィールドの一部は非常に大きくなります。たとえば、製品の説明は膨大になる可能性があります。
ただし、万が一、これが非常に単純なアプリケーションで、単一のデータ行に完全に含まれる製品と、5 ~ 8,000 アイテムを超えることのないショップを検討している場合は、並べ替え:
{
_id: ObjectId(),
shop_name: 'toys r us',
items: [
{ p_id: ObjectId(), price: '1000000', currency: 'GBP', description: 'fkf' }
]
}
ただし、サブドキュメントには代償が伴います。サブドキュメントが 1 つしかないドキュメントがあり、10 日で 100、20 日で 1000 になるとします。
増え続けるドキュメントによって引き起こされる断片化は、非常に大きなものになる可能性があります。これにより、パフォーマンスが1つ低下します。パフォーマンスが問題になるだけでなく、断片化を修正するのは良い仕事ではなく、後でアプリケーション ロジックで解決するのはさらに困難です。
内部で MongoDB が実際にどのように機能するかについて詳しく理解するには、次のプレゼンテーションをご覧ください: http://www.10gen.com/presentations/storage-engine-internals
サブドキュメントのクエリに関しては、MongoDB 側で少し余分な作業が必要ですが、適切に設定すれば、それでも非常に安価です (複数回の往復よりも安価です)。
個人的には、上記の情報に基づいて 2 つのコレクションに行きますが、あなたのシナリオの真の範囲はわかりません...
編集
UPD 1: 今のところ、製品自体が非常に小さく (ID、価格、名前、数)、その量が限られていると仮定しましょう。(だから、1店舗あたり1000商品を超えないことは確かです)
ドキュメントは小さく、おそらくそれぞれ数バイトです。この場合、ここでサブドキュメントを 2 の累乗のサイズ割り当てで使用して、その断片化の一部を修正できる場合があります: http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes
これにより、パフォーマンスの高い操作が作成される可能性があります。1 ~ 1000 のサブドキュメントでも断片化が発生する可能性がありますが、これらの断片は、存在するときに小さな「新しい」ショップ ドキュメントで満たされる必要があります。
UPD2 また、統計のためだけに、ビューの目的でそのデータベースを読み取りたくないと仮定できます。(どれだけ売れたか、どれが一番面白いか、どのグループかなど)
したがって、ショップごとに、サブドキュメントを使用して、次のようにショップごとの売上合計を簡単に取得できます。
db.shops.aggregate([
// Match shop id 1
{$match: {_id: 1}},
// unwind the products for that shop
{$unwind: '$products'},
// Group back up by shop id and total amount sold
{$group: {_id: '$_id', total_sold: {$sum: '$products.sold'}}}
])
新しい集約フレームワークの使用 (バージョン 2.1 以降): http://docs.mongodb.org/manual/applications/aggregation/
そのため、サブドキュメントは、2 つの個別のコレクションに対してクエリを実行するのと同じくらい簡単です。