私は50万人のユーザーを持つWebサイトを持っています（SQL Server 2008で実行しています）。ここで、ユーザーとその友達のアクティビティ ストリームを含めたいと思います。SQL Server でいくつかのことをテストした後、RDMS はこの種の機能には適していないことが明らかになりました。遅いです（データを大幅に非正規化した場合でも）。そのため、他の NoSQL ソリューションを検討した結果、これには MongoDB を使用できることがわかりました。アクティビティ ストリームのactivitystrea.ms json 仕様に基づくデータ構造に従います。 したがって、私の質問は次のとおりです。MongoDB のアクティビティ ストリームに最適なスキーマ設計は何でしょうか (このように多くのユーザーを使用すると、書き込みが非常に重くなることがほぼ予測できます。したがって、MongoDB を選択しました。「書き込み」パフォーマンスが優れています。私は 3 種類の構造について考えました。これが理にかなっているのか、それとも他のスキーマ パターンを使用する必要があるのか教えてください。
1 - このパターンですべての友達/フォロワーと一緒に各アクティビティを保存します。
{
_id:'activ123',
俳優：{
id:person1
}、
動詞:「従う」,
物体：{
objecttype:'人',
id:'person2'
}、
updateon:Date(),
消費者:[
person3、person4、person5、person6、...など
]
}
2 - 2 番目のデザイン: コレクション名 - activity_stream_fanout
{
_id:'activ_fanout_123',
personId:person3,
活動：[
{
_id:'activ123',
俳優：{
id:person1
}、
動詞:「従う」,
物体：{
objecttype:'人',
id:'person2'
}、
updateon:Date(),
}
]、[
//アクティビティ フィード 2
]
}
3 - このアプローチでは、アクティビティ アイテムを 1 つのコレクションに格納し、コンシューマーを別のコレクションに格納します。アクティビティでは、次のようなドキュメントがある場合があります。
{ _id: "123",
俳優: { 人物: "UserABC" },
動詞：「従う」、
オブジェクト: { 人物: "someone_else" },
updatedOn: 日付(...)
}
そして、フォロワーのために、次の「通知」ドキュメントを用意します。
{ activityId: "123", 消費者: "someguy", updatedOn: Date(...) }
{ activityId: "123", 消費者: "otherguy", updatedOn: Date(...) }
{ activityId: "123", 消費者: "secondguy", updatedOn: 日付(...) }
あなたの答えは大歓迎です。