facebook - 具有共享/喜欢/评论功能的社交网站的 mongodb 模式？

Question

我正在开发一个社交网站，用户可以在其中发布状态、分享/喜欢/评论其他人的帖子以及其他功能。我正在使用 mongodb + nodejs，我遇到了是否嵌入或引用用于存储这些数据的文档的问题。

我有一个名为“事件”的集合，它存储用户执行的所有事件，例如分享/发布/喜欢/评论，其中包含一个“类型”字段，该字段指定用户执行的事件类型。如果我执行“评论”操作，我应该如何存储该信息？我希望评论帖子的用户也可以将该帖子分享给他/她的 friend ，以便他们可以同时看到评论和帖子。我应该复制用户共享的相同内容并将其嵌入到一个类型为“共享”的新文档中，还是应该只存储对该内容的引用？

示意性地，我应该怎么做:

1. 嵌入:

   var activity = new Schema({
         type:String // specifies the type  of activity 
         content: [{
         // the object that user share/like/comments on.
         }]
   });
   

或

2.引用:

var activity = new Schema({
    type:String // in this case would be "share",
    content_id: Schema.Types.ObjectId // the id of the thing I share.
   }); 

使用嵌入方法，嵌入的“评论”内容将不包含最新评论，因为它是原始评论的副本，并且共享后的任何新评论都会更新。

使用引用方法，如果没有乱七八糟的回调，我很难检索这些结果(因为引用的某些对象也引用其他对象，例如帖子将引用评论)。

在我的情况下，最佳做法应该是什么？

Answer 1

杰里米，

您可能需要回答以下几个问题，以便更好地了解您将来可能最终如何使用这些数据。解决其中一些问题还将引导您进入模式设计的特定方向:

1. 用户的事件类型是否有限制？即这里的主要目的是确定一个非常活跃的用户是否会达到 16MB 的文档大小限制。如果是这样，嵌入一系列事件可能无济于事。

2. 这些记录(事件数组)将来会被索引/查询吗？即这里的目的是通过导致重定位和索引更新的文档大小的变化来识别缓慢/大量更新(添加新事件)。随着用户的事件数组大小的增长，性能会逐渐受到影响，因为它需要维护索引条目的数量。

3. 从用户的角度来看，这些事件的使用情况如何，这些事件是同时查看的，还是分页的。如果分页，可能会复制主文档中最近的“N”个事件条目的事件，其他事件则单独存储。

我还建议查看在 http://docs.mongodb.org/ecosystem/use-cases/storing-comments/ 中定义的评论用例.

希望这能帮助您做出对您长期有益的决定。