MongoDB电商多语言产品及子产品集合嵌套/拆分方案选型问询

问题1：单集合嵌套是否无需顾虑集合大小，是更优的实现方案？ #

首先明确结论：单集合嵌套绝对不能忽略大小限制，也不是所有场景下的最优方案。
MongoDB有16MB的单文档硬上限，电商场景下如果产品SKU数量多（比如服装类单产品可能有几十上百个颜色、尺码组合的SKU），再加上多语言内容、后续迭代新增的产品参数、图片资源字段，很容易触碰上限引发写入失败。
两种方案的适用场景差异很明确：

• 若单产品SKU稳定在20个以内、支持的语种不超过10种，且绝大多数查询是单产品维度（比如产品详情页查询），嵌套方案确实更优，无需关联查询，单次请求就能拿全所有数据，开发成本也更低。
• 若站点规模较大、SKU数量多，或者存在大量跨产品的SKU筛选、库存统计、SKU维度的运营分析需求，拆分集合的方案灵活度更高，后续迭代踩坑的概率远低于嵌套方案。

另外也可以选折中方案：把语种数量少、更新频率低的多语言content嵌套进products集合，SKU单独存sub集合，兼顾开发效率和扩展性。

问题2：嵌套结构如何筛选符合规格的子产品？查询性能会不会大幅下降？ #

筛选写法 #

嵌套后匹配符合规格的主产品非常简单，查询条件只需改为{"sub.features.color": { $in: ['red'] }}即可命中包含对应规格SKU的主产品。如果需要只返回匹配的SKU、过滤掉不符合的其他SKU，可以在聚合中用$filter操作符实现，示例如下：

db.products.aggregate([
  // 第一步匹配包含红色SKU的主产品
  { $match: { "sub.features.color": { $in: ["red"] } } },
  // 第二步过滤出仅符合条件的SKU
  { $project: {
    item: 1,
    price: 1,
    content: 1,
    matchedSub: {
      $filter: {
        input: "$sub",
        as: "s",
        cond: { $in: ["red", "$$s.features.color"] }
      }
    }
  }}
])

性能问题 #

只要给sub.features.color这类嵌套查询字段建立合适的索引，基础匹配查询的性能和平铺的独立sub集合没有明显差距，不会出现大幅下降。
但如果需要对SKU做排序、分页、全局库存统计这类操作，嵌套方案的性能会明显弱于独立集合：嵌套数组的聚合运算开销远高于独立集合的聚合，数据量达到十万级以上时差距会非常明显，实现复杂度也更高。

内容的提问来源于stack exchange，提问作者אלנ נורמן