mongodb、パフォーマンスに収集データ構造の影響

Question

コレクションデータ構造を定義する上で、どの構造が良い設計または決定であるかを判断するには？これは、その後のデータベースパフォーマンスへのアクセスに影響します。例えば

：

場合、このような一つのデータ：

{ 
    _id:'a' 
    index:1, //index 1~n 
    name:'john' 
} 

nが大きい場合、データが大きいと堆積頻繁になることを意味します。

収集データ構造はone dimensional objectになります。

{ 
    _id:'a' 
    index:1, 
    name:'john' 
} 
. 
. 
. 
{ 
    _id:'a' 
    index:99, 
    name:'jule' 
} 

またはcomposite two-dimensional object：

{ 
    _id:'a' 
    info:[ 
     {index:1,name:'john'},...,{index:99,name:'jule'} 
    ] 
} 

composite two-dimensional object効果的にデータの数を減らすことができ、しかし、検索方法は、書き込み用に便利ではありませんデータベースの検索や預金の有効性を実際に低下させるかどうかを決定します。

または、データの数がデータベースの有効性に影響する鍵です。

Answer 1

「より良い」とは、ユースケースごとに異なることを意味します。あなたのケースで動作するものは、他のユースケースでは必ずしも機能しないかもしれません。

1. のMongoDBのドキュメントサイズ制限（16メガバイト）：

   一般的には起因して、大きな配列を避けることをお勧めします。

2. 大きな配列を索引付けすることは、通常、あまり効果がありません。

しかし、これは概観であり、特定の経験則ではありません。データが配列ベースの表現に適していて、16MBの文書サイズに決してぶつかることがないと確信しているなら、その設計は（あなたのユースケースに合わせて）行く方法かもしれません。

あなたはスキーマ設計を始めるためにこれらのリンクが役立つことがあります。

• 6 Rules of Thumb for MongoDB Schema Design: Part 1
• Part 2
• Part 3
• Data Models
• Use Cases
• Query Optimization
• Explain Results