Question

我们正在使用MongoDB 3.0.5，我们有Blog的集合

Blogs{
title:"",
dateCreated:"",
userId:"",
body:"",
likes:[{userId:"",dateCreated:""}] //Array List of those person who likes the blog
comments:[{userId:"",dateCreated:"",comment:""}] //Array list of comments
shares :[{userID:"",dateCreated:""}]
}

现在我们有大约1000个喜欢和大约50条评论，我们的文档大小日益增加，我认为一段时间后它可能超过16 MB

所以现在我们想把我们的文件分成 - ： 1）博客 2）喜欢 3）评论 4）股票

Blogs { 
    title:"",
    dateCreated:"",
    userId:"",
    body:""
}
Comments {
    userId:"",
    dateCreated:"",
    comment:""
    blogid:""
} 
Shares {
        userId:"",
        dateCreated:"",
        blogid:""
    } 
Likes {
        userId:"",
        dateCreated:"",
        blogid:""
    }

我们正在考虑创建这个模式，但它看起来存在性能问题，因为1博客显示我们需要计算总喜欢，总份额和总评论。

有没有比这更好的选择？

Answer 1

如果每次编写时都更新字段，则可以在视图上保留计算。假设更频繁地进行观看，那么写这个应该不是一个大问题。因此，您可以使用以下架构：

Blog {
  title:"",
  dateCreated:"",
  userId:"",
  body:""
  shares: Int
  likes: Int
}

现在，每当用户点击“赞”按钮时，您都可以更新计算喜欢的字段，并为每个用户保存他喜欢的博客的ID。

User {
   name:
   registration_date:
   likes: [ blogid1, blogid2, blogid3 ... ]
   shares: [ blogid7, blogid18, blogid39 ... ]
}

所以点击事件，写入两个文档，但现在查看要简单得多。

更新

好的，所以我就是这样做的，但实际上并没有“正确的方法”，这很大程度上取决于你试图通过博客实现的目标。

我认为大多数博客文章都不会有几十条评论，因此我会为博客选择以下模型：

Blog {
  title:"",
  dateCreated:"",
  userId:"",
  body:""
  shares: Int
  likes: Int
  comments: [ { user: "foo", date: 2015-07-09, body: "great post"},  { user: "bar", date: 2015-07-10, body: "awesome post"}]
   commentrecords: []
}

对于那些您有博客文章记录超过100条评论的极端情况，您可以这样做：

PostComments {
_id : ObjectID(abce)
comments: [ { user: "foo", date: 2015-07-09, body: "great post"},  { user: "bar", date: 2015-07-10, body: "awesome post"}]

}

PostComments {
_id : ObjectID(1234)
comments: [ { user: "Baz", date: 2015-07-09, body: "great post"},  { user: "tom", date: 2015-07-10, body: "awesome post"}]
}

Blog {
  title:"Very popular post",
  dateCreated:"",
  userId:"",
  body:""
  shares: Int
  likes: Int
  comments: []
  comment_records: [ObjectID(1234), ObjectID(abce)]
}

遵循此路径，您的应用程序代码必须检查哪些字段comments或comment_records存在并采取相应措施。这意味着在大多数情况下，您只需要1次抓取即可加载博客帖子，而在极少数情况下，您将需要两次或更多轮次（取决于评论的数量）。如果您需要两轮以上，您可能不希望将它们全部加载到一起，因为可能大多数用户仍然会阅读最新的评论，因此您以用户点击previous comments的方式构建应用程序（事实上）它有一个名称：pagination）来加载更多的评论。

关于Likes和Shares

您创建了一组喜欢和分享，这样，如果您想了解所有用户的喜欢和分享，您必须遍历该集合并找到所有这些。如果您跟踪用户活动，则将此信息保持在用户附近是有意义的。因此，我会将此信息放在用户记录中：

User:
  {name : "foo"
   password: '******',
   email: 'foo@example.org', 
   likes: [{_id: objectid(1), date: 2013-01-01} , {_id: objectid(2), date: 2013-01-02},  {_id: objectid(3), date: 2013-01-01}]
   shares: [{_id: objectid(1), date: 2013-01-01} , {_id: objectid(2), date: 2013-01-02},  {_id: objectid(3), date: 2013-01-01}]
    }

如果您的用户记录有太多喜欢和分享，您可以采用与评论相同的方法，并将其收出并与ID形成“关系”。

User:
  {name : "foo"
   password: '******',
   email: 'foo@example.org', 
   like_records: [objectid(abfe21h), objected(eeebg001) ]
   share_records: [objectid(ffe11h), ]
    }

like_record {
       _id : objectid(abfe21h)
       likes: [{_id: objectid(1), date: 2013-01-01} , {_id: objectid(2), date: 2013-01-02},  {_id: objectid(3), date: 2013-01-01}]
       }   

share_record {
       _id : objectid(ffe11h) 
       shares: [{_id: objectid(1), date: 2013-01-01} , {_id: objectid(2),    date: 2013-01-02},  {_id: objectid(3), date: 2013-01-01}]
       }

Answer 2

您可以在mongodb中使用GridFS API来存储大小超过16 MB的文档。另请阅读when should i use GridFS

在保存mongoDB文档大小超过16 MB时发出问题

2 个答案:

更新