mongodb中的服务器端集合交叉点

在我正在开发的一个应用程序中，需要进行大规模的集合交集，大约10-1000000个项目。我们相交的项目只是ObjectId

例如，有一个box文档，在box文档中有一个item_id数组。每个框的此项ID数组包含10-1000000个ObjectId

这里的最终目标是，假设框A带有ObjectId 4D3C3895149810700005，框B带有ObjectId 4D3D389895149810700002，那么它们有哪些共同的项目ID

以下是我的做法：

db.boxes.distinct("item_ids", {'_id' : {$in : [ObjectId("4d3dc3898951498107000005"), ObjectId("4d3dc3898951498107000002")]}})

首先，我想知道这是否是一种明智的做法。到目前为止，在我的研究中，似乎map reduce对于大型交叉口是一个常见的建议，但对于实时查询，不建议使用它

其次，奇怪的是，在碎片化的环境中，这种行为会如何？mongos会在mongod上运行它需要的查询块并神奇地聚合我的结果吗

最后，如果上述情况是正常的，那么这样做是否也是正常的：

db.items.find({'_id' : { $in : db.eval(function() {return db.boxes.distinct("item_ids", {_id:{$in:[ObjectId("4d3dc3898951498107000005"), ObjectId("4d3dc3898951498107000002")]}}); }) }}) 

这基本上就是找到框A和框B的共同点，然后在一个服务器端查询中将它们具体化为对象。这似乎也适用于.limit和.skip，以有效地实现数据集的分页

---

无论如何，任何反馈都是有价值的，谢谢

我认为您可能需要重新考虑您的模式。如果一个数组中有1000000个objectid，每个objectid的大小为12字节，即12MB，甚至不包括BSON开销，这对于大型数组来说可能非常重要*（可能还有8MB左右）。在1.8中，我们将最大文档大小从4MB提高到16MB，但即使这样，也不足以存储您希望存储的对象

---

*出于历史原因，我们为数组中的每个元素存储了stingified索引，当您有了

distinct

如何找到共同值时，这很好？它“返回集合中给定键的不同值列表”。Distinct没有“交集”功能，它将为您提供a或B中所有ID的列表。或者您是指“联合”？哦，是的，您是对的。我显然需要更多的咖啡。我想我应该删除这个问题。如果有其他关于服务器端阵列/集合交叉点的想法，请稍等。谢谢是的，我想你是对的。有没有关于一个可能更有效的模式的想法，w/mongo的特征？我对mongo有点陌生，还没有什么大的产品。我考虑过的一种方法可能是用一个文档来描述什么东西放在什么盒子里，比如盒子里的东西。但这开始感觉像是一个rdbms，会创建大量的小文档。但是Item和Box在这个应用程序中都是一流的类，它们都充分利用了mongo的模式灵活性。因此，使用rdbms感觉像是回溯：（在不了解更多应用程序的情况下，很难给出模式建议。我建议向mongodb的mongodb邮件列表发送电子邮件-user@googlegroups.com