如果文档不足，MongoDB cursor.limit()将超时 [英] MongoDB cursor.limit() times out if not enough documents

问题描述

我在外壳中有这个查询，它的工作方式与我试图在Java中工作的查询完全一样:

I have this query in the shell which works exactly like the one I'm trying to get working in java:

db.documents.find({a query which works just fine}).max({archiveDate:"2015-04-14T11:24:50.004-0400",_id:ObjectId("553531139bb0d56edc9e4b9c")}).sort({archiveDate:-1,_id:-1}).skip(1).limit(12).maxTimeMS(1000)

等效的Java更加像这样:

The java equivalent would be more like this:

DBCursor dbCursor = documentCollection.find(query)
                    .max(new BasicDBObject().append("archiveDate", "2015-04-14T11:24:50.004-0400").append("_id", new ObjectId("553531139bb0d56edc9e4b9c"))
                    .sort(new BasicDBObject().append("archiveDate", -1).append("_id", -1)
                    .limit(12)
                    .skip(1)
                    .maxTime(1, TimeUnit.SECONDS);

(其中documentCollection是DBCollection，并且查询已正确定义并且可以正常工作，但是在此处插入有点麻烦).

(where documentCollection is a DBCollection and query is properly defined and works just fine, but is kind of cumbersome to plug in here).

我正在使用max()，sort()，limit()和skip()来解决常见的跳过问题并限制大型集合的性能问题.

I'm using max(), sort(), limit(), and skip() to get around the usual skip and limit performance issues for large collections.

无论如何，在max()方法中引用的文档在已排序的集合中为#12，因此它应该恰好返回11个文档.相反，当我尝试遍历游标时，它超时了，因为我定义了最长的时间为一秒.

In any case the document being referenced in the max() method is #12 in the sorted collection, so it should be returning exactly 11 documents. Instead it times out when I try to iterate over the cursor, since I've defined the maximum time it can take to be one second.

如果我取消时间限制，则大约需要10秒钟才能运行.如果我将限制设置为11，那么它将立即或多或少地运行.

If I remove the time constraint it will take about 10 seconds to run. If I set the limit to 11 then it will run more or less instantly.

因此，当此查询的限制超出可返回的文档数时，似乎就出现了问题.

So the problem appears to be happening when this query is given a limit which exceeds the number of documents available to be returned.

我不明白为什么会这样，所以我希望:

I don't understand why this happens, so I was hoping:

(a)某人知道并可以解释其发生的原因，并且

(a) someone knows and could explain why it's happening, and

(b)我该如何解决?我的Google-fu没有透露任何内容.

(b) how can I get around it? My Google-fu has revealed nothing.

查询时我不知道文档位于什么位置，所以我不知道可以返回多少文档，因此无法调整限制值以适合其位置.

I won't know when making the query what position the document is in, so I won't know how many documents could be returned, and therefore couldn't tailor the limit value to suit its position.

推荐答案

我想到的一个解决方案是使用查询获取下界:

One solution I've in my mind is get the lower bound using query:

db.documents.find({a query which works just fine}).sort({archiveDate:1,_id:1}).limit(1);

完成此绑定后，您可以将其应用于失败的查询.由于我们无法说出页面是否是最后一页，因此您可能必须在每次调用下一页之前都要查询该值，或者通过使用此值构造下一页链接或将其缓存来在请求中持久化. 如果在调用者获取页面时有可能更改下限，则您别无选择，只能选择第一个选项.也就是说，在发出下一个页面请求之前先确定下界.

Once you've this bound you can apply it for the query that's failing. Since we can't say if the page is last page or not, you might either have to query this value every time before making call for next page or persist across requests by either constructing next page link using this value or cache it. if there is a possibility of changing lower bound while caller is fetching pages, then you don't have a choice but go with first option only. i.e. get lower bound before making a next page request.

由于您在一段时间前发布了此查询，因此我确定您必须找到解决方案.我想了解您如何解决此问题，并能分享一下问题所在.

Since you've posted this query a while ago and I'm sure you must have figured out a solution. I want to understand how you got around this problem and could you share what the issue is.

这篇关于如果文档不足，MongoDB cursor.limit()将超时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！