在接受的答案中取消一个例子：
对于博客系统，“帖子应该是一个集合。帖子作者可能是一个单独的集合，或者只是一个帖子中的字段，如果只是一个电子邮件地址。评论应该是帖子中的嵌入对象以提高性能。”
如果是这种情况，这是否意味着每次我的应用程序显示博客文章时，我都会加载该帖子上发表的每条评论？如果有3,729条评论怎么说？这不会破坏数据库连接，SQL或NoSQL吗？还有一个明显的场景，当我加载一篇博文时，我想最初只显示前10条评论。
答案 0 :(得分：4)
文档数据库不是关系数据库。您不能先构建数据库模型，然后再决定查询它的各种有趣方法。相反，您应首先确定要支持的访问模式，然后相应地设计文档模式。
因此，为了回答您的问题，我们真正需要知道的是您打算如何使用这些数据。显示与帖子关联的评论与显示特定作者的所有评论完全不同。这些要求中的每一个都将规定不同的设计，并支持它们。
这本身对你来说可能是有用的信息（？），但我怀疑你想要更具体的答案:)所以请在你的预期用途上添加一些额外的细节。
添加更多信息： 在决定策略时，有一些“做”和“不做”：
DO：针对常见用例进行优化。通常有20/80的故障，其中20％的UX驱动80％的负载 - 主页/登陆页面是一个典型的例子。首要任务是确保这些尽可能高效。确保您的数据模型允许A）在单个IO请求中加载或B）缓存友好
不要：不要陷入可怕的“N + 1”陷阱。当您的数据模型强制您进行N次调用以加载N个实体时，通常会先执行额外调用以获取N个ID列表，从而出现此模式。这是一个杀手，特别是与＃3 ...
DO：始终限制（通过UX）您愿意获取的数据量。如果用户有3729条评论，您显然不会立即获取所有评论。即使从数据库的角度看它是可行的，用户体验也会很糟糕。这就是搜索引擎使用“未来20个结果”范例的原因。因此，您可以（例如）将数据库结构与UX对齐，并将注释保存为20个块。然后每个页面刷新涉及一个DB get。
DO：平衡读写要求。某些类型的系统读取很重，您可以假设每次写入都会有很多读取（StackOverflow就是一个很好的例子）。因此，为了获得读取性能的好处，使写入更加昂贵是有意义的。例如，数据非规范化和复制。其他系统均衡均衡，甚至写得很重，需要其他方法
DO：使用TIME的维度。 Twitter是一个典型的例子：99.99％的推文在第一小时/每天/每周/之后永远不会被访问。这将在您的数据模式中打开各种有趣的优化可能性。
这只是冰山一角。我建议稍微阅读基于列的NoSQL系统（如Cassandra）
答案 1 :(得分：1)
不确定这是否能回答您的问题，但无论如何您可以通过两种方式限制博客评论的数量：
$slice运算符 db.blogs.find( {_id : someValue}, { comments: { $slice: -10 } } )
将返回最后10条评论
db.blogs.find( {_id : someValue}, { comments: { $slice: [-10, 10] } } )
将返回下一个10条评论