Mongodb 按相关文档位置对文档进行排序

我有3个系列：

• 供应商（_id，title）
• 产品（标识、标题、供应商id）
• vendor.location（_id、coords、vendorId）

每个供应商都有多个地点（最多10000个）和多个产品（最多10000个）

我需要找到指定位置附近的所有产品，并按距离排序

到目前为止，我想说的是：

1） 查找指定位置附近的所有供应商：

db.collection('vendor.locations').aggregate([
  {
    $geoNear: {
      near: givenLocation,
      distanceField: 'distance',
      maxDistance: 1000,
      limit: 1000,
      spherical: true
    }
  },
  {
    $group: {
      _id: "$vendor",
      distance: {$min: "$distance"}
    }
  },
  {
    $sort: {distance: -1}
  }

]);

2） 使用$in运算符查找匹配供应商的所有产品，但AFAIK它不保证匹配项目的顺序

  db.collection('products').aggregate([
  {
    $match: {
      vendor: {$in: vendorIds}
    }
  },
  {
    $sort: {} //is it possible to sort items by their position in vendorIds array? 
  },
  {
    $limit: limit
  },
  {
    $skip: skip
  }

)

因此，基本上问题归结为找到一种对产品进行分类的方法

---

另一个可能的解决方案是将供应商位置非规范化为产品位置，但潜在的收集规模（和地理索引）令我担忧。产品集合最多可以有1M个，嵌入位置阵列最多可以有10K个，因此在地理索引中最多可以有10B个项目。有多糟糕？

那么，如果这对您来说真的很重要，而且您已经清楚地在

产品上存储了
供应商ID
，那么您到底为什么不至少也在产品上存储供应商“位置”数据呢？如果您使用的是围绕其他概念设计的存储引擎，请停止相关思考。所以，正如你最后总结的那样，这实际上就是你应该怎么做的。它的存储成本会更高吗？当然会的。但是它会比你现在做的更快吗？关于森林里的一只熊……相关：。当您应该只将位置数据存储在产品数据上时，使用
$lookup
是愚蠢的。底线是“连接的时间成本比索引空间的存储成本更高”。而那些花费更多时间的东西最终会花费你更多的钱。@BlakesSeven好吧，我已经尝试在产品上放置位置数据，正如我预期的那样，索引的大小非常大（超过1GB），目前它只有一个字段，而我以后肯定需要添加更多的字段。看来反规范化并不能解决我的问题。你这么说是因为这是世界末日！同样，您使用的是NoSQL数据存储，它用“空间”换取“速度”和“可伸缩性”（这并不奇怪）。如果您不了解这些要点，则不应使用该产品。如果您实际上不需要速度和可伸缩性，而是想要所有的便利，那么可以使用RDBMS。