C# MongoDB 驱动程序 [2.7.0] CountDocumentAsync 意外的 native 查询

Question

我在使用 C# MongoDB CountDocumentAsync 函数时遇到了奇怪的事情。我在 MongoDB 上启用了查询日志记录，这就是我得到的:

{
    "op" : "command",
    "ns" : "somenamespace",
    "command" : {
        "aggregate" : "reservations",
        "pipeline" : [
            {
                "some_query_key": "query_value"
            },
            {
                "$group" : {
                    "_id" : null,
                    "n" : {
                        "$sum" : 1
                    }
                }
            }
        ],
        "cursor" : {}
    },
    "keyUpdates" : 0,
    "writeConflicts" : 0,
    "numYield" : 9,
    "locks" : {
        "Global" : {
            "acquireCount" : {
                "r" : NumberLong(24)
            }
        },
        "Database" : {
            "acquireCount" : {
                "r" : NumberLong(12)
            }
        },
        "Collection" : {
            "acquireCount" : {
                "r" : NumberLong(12)
            }
        }
    },
    "responseLength" : 138,
    "protocol" : "op_query",
    "millis" : 2,
    "execStats" : {},
    "ts" : ISODate("2018-09-27T14:08:48.099Z"),
    "client" : "172.17.0.1",
    "allUsers" : [ ],
    "user" : ""
}

简单的计数被转换成一个聚合。

更有趣的是，当我使用 CountAsync 函数时(顺便说一句，该函数被标记为过时，我应该使用 CountDocumentsAsync)它会产生:

{
    "op" : "command",
    "ns" : "somenamespace",
    "command" : {
        "count" : "reservations",
        "query" : {
            "query_key": "query_value"
        }
    },
    "keyUpdates" : 0,
    "writeConflicts" : 0,
    "numYield" : 9,
    "locks" : {
        "Global" : {
            "acquireCount" : {
                "r" : NumberLong(20)
            }
        },
        "Database" : {
            "acquireCount" : {
                "r" : NumberLong(10)
            }
        },
        "Collection" : {
            "acquireCount" : {
                "r" : NumberLong(10)
            }
        }
    },
    "responseLength" : 62,
    "protocol" : "op_query",
    "millis" : 2,
    "execStats" : {

    },
    "ts" : ISODate("2018-09-27T13:58:27.758Z"),
    "client" : "172.17.0.1",
    "allUsers" : [ ],
    "user" : ""
}

这是我所期望的。有谁知道这种行为可能是什么原因？我浏览了文档，但没有发现任何有趣的内容。

Answer 1

这是支持 4.0 功能的驱动程序的记录行为。更改的原因是为了消除混淆并明确何时使用估算值以及何时不使用估算值。

当基于查询过滤器进行计数(而不是仅对整个集合进行计数)时，这两种方法都会导致服务器迭代匹配的文档以对它们进行计数，因此具有相似的性能。

来自 MongoDb docs: db.collection.count()

NOTE:

MongoDB drivers compatible with the 4.0 features deprecate their respective cursor and collection count() APIs in favor of new APIs for countDocuments() and estimatedDocumentCount(). For the specific API names for a given driver, see the driver documentation.

来自 MongoDb docs: db.collection.countDocuments()

db.collection.countDocuments(query, options)

New in version 4.0.3.

Returns the count of documents that match the query for a collection or view. The method wraps the $group aggregation stage with a $sum expression to perform the count and is available for use in Transactions.

可以在 MongoDb JIRA site 上找到有关此 API 更改的更详细说明。 :

Drivers supporting MongoDB 4.0 must deprecate the count() helper and add two new helpers - estimatedDocumentCount() and countDocuments(). Both helpers are supported with MongoDB 2.6+.

The names of the new helpers were chosen to make it clear how they behave and exactly what they do. The estimatedDocumentCount helper returns an estimate of the count of documents in the collection using collection metadata, rather than counting the documents or consulting an index. The countDocuments helper counts the documents that match the provided query filter using an aggregation pipeline.

The count() helper is deprecated. It has always been implemented using the count command. The behavior of the count command differs depending on the options passed to it and the topology in use and may or may not provide an accurate count. When no query filter is provided the count command provides an estimate using collection metadata. Even when provided with a query filter the count command can return inaccurate results with a sharded cluster if orphaned documents exist or if a chunk migration is in progress. The countDocuments helper avoids these sharded cluster problems entirely when used with MongoDB 3.6+, and when using Primary read preference with older sharded clusters.