MongoDB中集合结构的优化设计

我收集了很多文章。我需要一个新的收集意见。一篇文章可以有一条或多条评论。评论可以有答案

构建它的更好方法是什么，平面还是嵌入式

1） 平坦的

2） 嵌入式1

Articles [{
    _id: 'abc123'
    content: ...
}]

Comments [{
    articleId: 'abc123',
    comments: [{
        _id: 'comm1'
        parentCommentId: null
        comment: ...
    },{
        _id: 'comm2'
        parentCommentId: null
        comment: ...
    }, {
        _id: 'comm3'
        parentCommentId: 'comm2'
        comment: ...
    }]
}]

3） 嵌入式2

Articles [{
    _id: 'abc123'
    content: ...
}]

Comments [{
    articleId: 'abc123',
    comments: [{
        _id: 'comm1'
        parentCommentId: null
        comment: ...
    },{
        _id: 'comm2'
        parentCommentId: null
        comment: ...
        answers: [{
            _id: 'comm3'
            comment: ...
        }]
    }
}]

---

提前谢谢你

模式设计可以归结为许多不同的因素。MongoDB支持每个文档最多16MB。您没有提到这些嵌入文档的大小。此外，查询访问模式和写入模式在选择适当的模式设计方面起着重要作用。向子文档添加、从子文档中删除或更改子文档的频率如何？您多久查询一次整个文档，还是只需要查询一个子集，如果需要，是什么？谢谢您的提问。文件很小。这只是文字注释，最多200个字符。当我展示这篇文章时，评论就会显示出来。用户发表评论。多久？我希望尽快。：）这是一个启动项目。现在不多了，但我的目标是每篇文章都有很多评论。鉴于评论数量较少，我将通过将评论嵌入子文档来扩展

文章

集合。这意味着我将有一个收藏，而不是两个。这还假设一次只显示一篇文章。MongoDB（或任何非sql变体）的基本原则之一是避免查找和引用。这有时会导致重复数据，但性能提高可能是巨大的，因为数据已经为主要用例预先分组在一起。与规范化是规则的RDBMS解决方案相比，这个概念有很大的不同。顺便说一句，100000篇文章看起来可能很大。根据我的计算，如果一篇文章有10000个字符，并且有20条评论，每个评论200个字符，那么每个文档大约有14kb。大约1.4GB的数据库。容易适应所有的记忆！只要构建了适当的索引，集合大小就无关紧要。我对包含数百万文档的集合运行过查询，从未遇到过任何性能问题。您主要关心的是对您的评论的操作。MongoDB的位置运算符

$

仅在最外层的数组上工作，因此在树状嵌入式文档结构中，不可能对任何不在最顶层的注释执行

$push

或

$pull

。你会想考虑这个限制。

Articles [{
    _id: 'abc123'
    content: ...
}]

Comments [{
    articleId: 'abc123',
    comments: [{
        _id: 'comm1'
        parentCommentId: null
        comment: ...
    },{
        _id: 'comm2'
        parentCommentId: null
        comment: ...
        answers: [{
            _id: 'comm3'
            comment: ...
        }]
    }
}]