MongoDB查询性能对比：更多文档与更多嵌套对象哪个查询速度更快？

核心结论 #

第一种模型综合表现远优于第二种，全量拉取event的速度并不会比第二种慢很多，差异可以忽略不计，更推荐你使用第一种方案。

各维度性能对比 #

1. 全量拉取性能 #

你担心的500份文档和30份文档的拉取速度差异实际非常小：总数据量由10万个event对象决定，两种方案的总数据量差异仅来自元数据和公共字段的重复存储，实际测试下来两者全量拉取的速度差通常不会超过10%，用户侧完全感知不到。
反而第二种模型存在明确的风险：MongoDB单文档硬上限为16MB，单文档存储3000~4000个event非常容易触碰到大小红线，后续新增event字段或者event数量上涨时，会直接出现写入失败的问题，第一种模型单文档仅存200个左右event，完全不存在该风险。

2. 条件过滤查询性能 #

你的判断完全正确，第二种模型的过滤查询效率远低于第一种：

• 第一种模型的bookmaker、sport、market、exchange、league均为顶层或上层数组字段，可以直接建立索引，查询时可以直接跳过不匹配的整份文档，甚至仅返回匹配的嵌套节点，不需要遍历所有event，查询效率比第二种高2~3个量级。
• 第二种模型所有过滤维度都存储在event子对象内，即使给data.events.xxx这类嵌套字段建索引，查询时也需要遍历所有嵌套的event对象才能筛选出符合条件的条目，数据量上涨后延迟会非常明显，后续如果要增加分页、排序等操作，第二种模型几乎无法实现。

3. 写入更新性能 #

第一种模型的写入优势更加突出：如果需要更新某个联赛、某个交易所的event数据，仅需要定位到对应的小文档修改对应节点即可，写入开销极低。第二种模型修改少量event也需要操作几十MB的大文档，写入放大问题非常严重，并发量稍高就会出现写入排队、超时的问题。
另外第一种模型不需要重复存储公共字段，存储空间占用更低，同时小文档的缓存命中率更高，长期运行的性能表现会更稳定。

优化建议 #

如果你对全量拉取速度有极致要求，可以针对全量拉取的场景增加一层只读缓存，完全可以抹平两种方案之间的微小性能差异。

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