Mongo $ in运营商表现

Question

在MongoDB中使用带有大量可能性的$ in运算符是缓慢/差的形式吗？

posts.find({
    author : {
        $in : ['friend1','friend2','friend3'....'friend40'] 
    }
})

例如,App Engine不允许您使用超过30个,因为它们直接转换为IN数组中每个项目的一个查询,因此强制您使用他们的方法来处理扇出.虽然这可能是Mongo中最有效的方法,但它的代码要复杂得多,所以我更喜欢使用这种通用方法.

Mongo会有效地为合理大小的数据集执行这些$ in查询吗？

Answer 1

对于$ in,它可以相当有效地使用小列表(很难说小,但至少是几十/几百).它不像app-engine那样工作,因为mongodb有实际的btree索引而且不像bigtable这样的列存储.

使用$ in将在索引中跳过以查找匹配的文档,或者如果没有要使用的索引,则遍历整个集合.

那么,appengine中的AFAIK索引是在列存储的顶部实现的.这意味着您只能使用范围查询,并且不能像使用btree结构那样轻松地在内存中跳过.通过使用列存储来维护索引数据,Cassandra的工作方式与GAE相同. (2认同)

Answer 2

假设您已经在author字段上创建了索引,从算法的角度来看,$in操作的时间复杂度是:$(N*log(M)),N输入数组的长度在哪里,是M集合的大小.

除非您更改数据库,否则$in操作的时间复杂度不会改变(尽管我认为任何数据库都不会中断O(N*log(M))).

但是,从工程角度来看,如果N使用大数字,最好让您的业务逻辑服务器$in通过批处理或逐个模拟操作.

这只是因为:数据库服务器中的内存比业务逻辑服务器中的内存更有价值.

Answer 3

如果在list元素上构建索引(ensureIndex),它应该非常快.