无法使用嵌入式文档时，MongoDB一对多关系的最佳建模方式

在MongoDB里，视频和评论的一对多关系，用嵌入式文档是最直接的方式，但评论数一旦到数千条就会变得很鸡肋——不仅会让视频文档体积暴涨，拖慢读写速度，还可能触碰到MongoDB单文档16MB的大小限制，只适合评论极少的场景。

两种可选方案分析 #

方案1：视频文档存评论ID列表 #

这种方案的核心问题是并发冲突：多个用户同时加评论时，对视频文档里的评论ID数组做更新，很容易出现数据丢失。哪怕用$push原子操作，评论量上来后视频文档还是会越来越大，同样影响性能，完全不是最优解。

方案2：评论文档存视频ID #

这个方案没有并发更新的问题，因为每条评论都是独立文档，新增评论就是插新文档，不会动视频文档。至于担心的查询性能，只要给评论文档的videoId字段建个索引，查某个视频的所有评论时，索引能快速定位目标文档，性能根本不会下降。而且这种方案扩展性极强，评论再多也不影响视频文档，还能轻松做分页、按时间排序这类操作，比如拿最新的10条评论，用索引配合sort()和limit()就能高效实现。

最佳解决方案 #

优先选方案2：评论文档存视频ID并为videoId建立索引，原因如下：

• 彻底规避并发更新冲突，新增评论是独立操作，互不干扰
• 索引加持下，查询视频对应的评论性能拉满，完全不用顾虑性能问题
• 扩展性好，支持评论的各种复杂操作，不受评论数量增长影响
• 视频文档体积稳定，读写性能不会被评论拖垮

如果需要在视频页面快速展示最新几条评论，可以在视频文档里额外存10条左右的最新评论嵌入式文档当"预览"，不用查全量评论就能快速显示，这种混合模式能兼顾性能和用户体验。

内容的提问来源于stack exchange，提问作者cooooool