具有共享/喜欢/评论功能的社交网站的mongodb架构?

时间:2014-01-06 04:44:58

标签: facebook node.js mongodb

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

我有一个名为“activity”的集合,它存储用户执行的所有活动,例如share / post / like / comment和“type”字段,该字段指定用户执行的活动类型。如果我执行“评论”操作,我该如何存储该信息?我希望评论帖子的用户也将该帖子分享给他/她的朋友,以便他们可以看到评论和帖子。我应该复制用户共享的相同内容并将其嵌入一个类型为“share”的新文档中,还是应该只存储对该内容的引用?

示意图,我应该这样做:

  1. 嵌入:

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

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

    使用嵌入方法,嵌入的“已注释”内容不会包含最新的注释,因为它是原始注释的副本,并且在共享之后的任何新注释都将被更新。

    使用引用方法,我在检索这些结果时遇到了很多困难而没有乱七八糟的回调(因为一些引用的对象也引用了其他对象,比如帖子会引用注释)。

    在我的情况下,最佳做法应该是什么?

1 个答案:

答案 0 :(得分:3)

杰里米,

您可能希望回答以下几个问题,以便更好地了解将来如何最终使用这些数据。通过其中一些问题也将引导您进入架构设计的特定方向:

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

  2. 这些记录(活动数组)将来会被索引/查询吗?即,此处的目的是通过导致重定位和索引更新的文档大小的变化来识别慢/重更新(添加新活动)。随着用户的活动数组大小的增加,由于需要维护的索引条目数量,性能会逐渐下降。

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

  4. 我还建议在查看用于http://docs.mongodb.org/ecosystem/use-cases/storing-comments/定义的注释的用例。

    希望能帮助您做出长期为您服务的决定。