Mongodbのマルチドキュメントまたは埋め込みドキュメント？

Question

私はTwitterのようなソーシャルネットワークシステムを設計しており、ユーザーは通知を受け取ります。私はmongodbに通知を保存します。たいていの場合、100ユーザーごとに100の通知を行い、唯一のフィールドはreadです（ユーザーは通知を読んでいます）。だから私はブロー

{"userId":1, "content":"some msg", "read":true..} 
{"userId":1, "content":"another msg", "read":true..} 

またはこのような埋め込まれた文書を使用してマルチドキュメントを使用して天気を疑問に思って：

{"userId":1, "noficications":[{"content":"some msg", "read": true},{"content":"another msg", "read":true}]} 

Answer 1

私のアプリを作成したとき、私は、しばらく前に同じ疑問を持っていました。しかし私の場合、アプリケーションに焦点を当てるのはサブ文書に記録された値です。それでは、コードが不明確になることがありました。私は質問を書くためにいくつかの問題がありました。

フォーカスが「ユーザー」の場合、2番目のアプローチでは問題は発生しませんが、フォーカスが「通知」の場合は、通知を保存するドキュメントを作成することをおすすめします。

Answer 2

これは、あなたの使用状況によって決まります。特定のユーザーの通知のほとんどまたはすべてを常にロードする場合は、通知の配列を持つ1つのドキュメントに保持します。これにより、ドキュメント全体がメモリにマップされ、物事がうまく保たれます。また、余分なインデックスを作成する必要もありません。

{"_id":1 /* User Id */, "noficications":[{"content":"some msg", "read": true},{"content":"another msg", "read":true}]} 

は、しかし、あなたがアドホック個別通知を引き戻すしようとしている場合は、メモリ内に熱い文書全体を維持したくないので、私は、別々の文書にして、それを下に分割したいです。このapporachでは、 "userId"に別のインデックスを作成することになり、すべての通知を一度に取り戻すことができます。

{"_id": 1 /* Notification Id */, "userId":1, "content":"some msg", "read":true..} 
{"_id": 2 /* Notification Id */, "userId":1, "content":"another msg", "read":true..} 

両者の長所と短所は、データの使用状況によって異なります。