2012-02-07 17 views
3

MongoDBに類似の構造を格納するためのより良い方法はありますか?すべてのコレクションを選択するか、各構造に1つのコレクションを選択しますか? 1つまたは複数の利点はありますか?類似のデータ構造に対するMongoDBコレクション構造の選択

たとえば、詳細な分析のためにいくつかのログを保存する必要があります。各構造など、いくつかのstatタイプのための特定のいくつかのデータの共通部分があります:item1item2のため、いくつかの異なるフィールドで

{ 
    timestamp: ..., 
    client: { ... }, 
    type: 'stats_for_item1', 
    data: { 
    id: ObjectId('xxx'), 
    field1: 1, 
    field2: 2 
    } 
}, 
{ 
    timestamp: ..., 
    client: { ... }, 
    type: 'stats_for_item2', 
    data: { 
    id: ObjectId('zzz'), 
    field3: 3, 
    field4: { 
     field5: [5, 1] 
    } 
    } 
} 
あなたは私たちが共通部分を持って見るように

、およびdataフィールド、。

timestampフィールドとtypeフィールドだけがインデックスされているようです(もちろん_id)。そして、このようなアイテムの数は限られています.3つのアイテムタイプがあります。書き込みがたくさんあり、読み込み量は少なくなります

私の質問はどのようにこのような構造を整理するのですか? 1つの大きなコレクションstatsを使用し、そこにすべてを保管しますか?いくつかのコレクションを作成しないでくださいstats_item1stats_item2およびstats_item3最適なのは何ですか?どんな利点? mongoの観点から、シャーディング/インデックス/クエリ/ロック/ etc?

答えて

3

私はおそらく1つのコレクションを保持します。後で別のstat-typeを取得した場合は、追加する必要がある新しいコレクションの周りにコードを再構築する必要はありません。 「タイプ」にインデックスを作成することで、特定のタイプのアイテムを特定して検索することができます。すべてのアイテムは、コレクションに「タイムスタンプ」のインデックスがあるため検索できます。 (MongoDBはすべてのドキュメントに_idフィールドを追加し、それにインデックスも追加することに注意してください)。

シャーディングの場合は、コレクションごとにキーを選択する必要があります。私はあなたの書き込み/読み取りの比率がどのようなものか、データの読み方を知らないのですが、後で何らかの分析をして何らかのログをとっていると思われます。その場合、おそらく "クライアント"のシャードキーが最も理にかなっています。タイムスタンプはおそらく1つのシャードにすべての書き込みを強制するので、貧しい選択になるでしょう。

1つまたは3つのコレクションのコレクションの違いはあまり違いはありません。現在、mongoDBはコレクションごとにロックを行いません(2.0の場合はロックで、これからの2.2で収穫する)。

歓声、

Derick