skip 高时 Python Mongo "Sort operation used more than the maximum"

Question

我有一段代码可以进行相当简单的查询-跳过-限制-排序。我遇到了一个我很难解释的现象。

在“小”跳过值上 - 一切都很好。在“高”跳过值(> 18000)上 - 我无法在没有收到以下错误的情况下获得限制高于 20 的结果:

OperationFailure: Executor error during find command: OperationFailed: Sort operation used more than the maximum 33554432 bytes of RAM. Add an index, or specify a smaller limit.

问题是 - 为什么只在大量跳过计数时才会发生这种情况？我该如何解决这个问题？

在 mongoShell 上运行它(即使 DBQuery.shellBatchSize = 300)也能正常工作。而且它似乎正在使用索引 db.my_collection.find({'foo':false}).skip(19000).limit(100).sort({'meta_data.created_at':-1}).explain()

"queryPlanner" : {
    "plannerVersion" : 1,
    "namespace" : "bla.my_collection",
    "indexFilterSet" : false,
    "parsedQuery" : {
        "foo" : {
            "$eq" : false
        }
    },
    "winningPlan" : {
        "stage" : "LIMIT",
        "limitAmount" : 100,
        "inputStage" : {
            "stage" : "SKIP",
            "skipAmount" : 9000,
            "inputStage" : {
                "stage" : "FETCH",
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "keyPattern" : {
                        "foo" : 1,
                        "meta_data.created_at" : -1
                    },
                    "indexName" : "foo_1_meta_data.created_at_-1",
                    "isMultiKey" : false,
                    "multiKeyPaths" : {
                        "foo" : [ ],
                        "meta_data.created_at" : [ ]
                    },
                    "isUnique" : false,
                    "isSparse" : false,
                    "isPartial" : false,
                    "indexVersion" : 1,
                    "direction" : "forward",
                    "indexBounds" : {
                        "foo" : [
                            "[false, false]"
                        ],
                        "meta_data.created_at" : [
                            "[MaxKey, MinKey]"
                        ]
                    }
                }
            }
        }
    },

更多信息:似乎排序确实是在内存中完成的——它存在于被拒绝的计划中。那么可以做什么呢？

"rejectedPlans" : [
            {
                "stage" : "SKIP",
                "skipAmount" : 19000,
                "inputStage" : {
                    "stage" : "SORT",
                    "sortPattern" : {
                        "meta_data.created_at" : -1
                    },
                    "limitAmount" : 19100,
                    "inputStage" : {
                        "stage" : "SORT_KEY_GENERATOR",
                        "inputStage" : {
                            "stage" : "FETCH",
                            "inputStage" : {
                                "stage" : "IXSCAN",
                                "keyPattern" : {
                                    "foo" : 1,
                                    "_id" : 1
                                },
                                "indexName" : "foo_1__id_1",
                                "isMultiKey" : false,
                                "isUnique" : false,
                                "isSparse" : false,
                                "isPartial" : false,
                                "indexVersion" : 1,
                                "direction" : "forward",
                                "indexBounds" : {
                                    "foo" : [
                                        "[false, false]"
                                    ],
                                    "_id" : [
                                        "[MinKey, MaxKey]"
                                    ]
                                }
                            }
                        }
                    }
                }
            }

还有一个问题。为什么它只在大量跳过时发生？为什么重要？

Answer 1

The question is - why is this happening only with large skip count?

这是因为排序是在内存中进行的。当你提供 sort 和 limit 时，必须在内存中维护的文档数等于 limit。当有skip和limit时，内存中保存的数字必须是“skip+limit”。

How can I solve this?

您可以确保有一个支持排序和过滤器的索引，如果有一个但没有被选中，您可以使用 hint指定查询应使用哪个索引。

Why is it happening only at a large skip count?

“最佳”计划是在您第一次运行特定查询时选择的，然后在将来缓存(记住)。当跳过计数变得足够大时，可能适用于较小数量的最佳计划不再适用。