基于时间复杂度的MongoDB商品Schema设计查询效率选型咨询

两种方案说明 #

• 方案1：每个商品单独创建集合，每个集合仅存储1条对应商品的详情文档
• 方案2：所有商品统一存入products集合，每个商品对应集合内的1条独立文档

效率对比结论 #

方案2的查询、获取商品信息的效率远高于方案1，原因如下：

1. 查询请求开销更低
   如果需要查询多个商品信息，方案1需要分别向不同集合发起多次独立查询，IO次数随查询商品数量线性增长；方案2仅需调用一次$in查询，语法示例：

db.products.find({_id: {$in: [商品1ID, 商品2ID, 商品3ID]}})

一次请求就能拿到所有目标数据，IO开销极低。
2. 元数据与索引成本更低
MongoDB每个集合都有独立的元数据、索引配置，方案1每新增一个商品就要新建集合、单独维护索引，集合数量多了之后元数据查询、索引维护的开销会大幅上涨，且各集合的索引缓存独立，缓存利用率极低。方案2所有商品共用一套索引，缓存命中率高，索引维护成本也更低。
3. 业务场景适配性更强
结合你维护用户购买历史的场景，后续需要通过用户购买记录关联查询商品详情时，方案2直接用购买记录中存储的商品ID批量查询即可；方案1还需要额外做商品ID到对应集合名的映射，逻辑复杂度更高，执行效率也更差。 #

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