C# MongoDbDriver 迁移过时计数替换方法

Question

For some time we've been getting warnings in our code:

Warning CS0618 'IMongoCollection.Count(FilterDefinition, CountOptions, CancellationToken)' is obsolete: 'Use CountDocuments or EstimatedDocumentCount instead.'

So we want to "update". However, we're running into performance problems. Which seem to have already reported in 2018 on Jira (mongoDb driver issue tracker) .

I did some tests myself and found the following for a small collection,which already shows the differences:

• Count returns 6600 and took 12 ms.
• CountDocuments returns 6600 and took 25 ms.
• EstimatedDocumentCount returns 6600 and took 2 ms.

But then for a big collection:

• Count returns 2721199 and took 12 ms.
• CountDocuments returns 2721199 and took 196406 ms.
• EstimatedDocumentCount returns 2721199 and took 4 ms.

That's 196 seconds! 16367x slower! Totally unacceptable...

One could argue "Then just use EstimatedDocumentCount ". However, EstimatedDocumentCount doesn't offer the same interface: ie you cannot filter/there's no filter parameter or option.

And if you would try the something like collection.Find(...).EstimatedDocumentCount() that doesn't work, as IFindFluent doesn't offer an EstimatedDocumentCount method. And we do want to filter often.

What's up with this? How can they deprecate a functionality and not replace it with something good?

Does anybody know how to fix this?

edit: Like @Joe suggested, I added a filter (didn't do that before). Now I get different results:

• Count returns 2060277 and took ~434 ms.
• CountDocuments returns 2060277 and took ~575 ms.
• EstimateDocumentCount is not an option when filtering

Weird. But anyhow, CountDocuments is still 25% slower, which is significant. Can this be fixed? (The query is already using an index)

Answer 1

Previously, calling Count implicitly (and silently) used the EstimatedDocumentCount behavior when no filter was provided, and the CountDocuments behavior when one was provided.

It is called "Estimated" because all it does is retrieve the document count from the collection metadata. That value is usually correct, but there are a number of things that can cause that metadata value to drift from the actual count.

This was a source of confusion in the past, and MongoDB apparently got tired of responding "works as designed" and recommending the use of a filter that would match all documents to get the accurate count, so they split Count into two separate functions that explicitly use only one of those behaviors.

This means that you now have a choice. If you want to get the count of all documents in the collection, you can call CountDocuments to get the up to the minute completely accurate answer, or you can call EstimatedDocumentCount to really quickly pull the hopefully correct metadata.

Since getting the count from metadata is literally just retrieving a single integer, it cannot support filtering.