问题:MongoDb驱动c#查询优化

我在 mongodb doc 中读到我也可以使用 LINQ,但我对此一无所知。

例如,如果我写:

var result = collection.Find(filter);

和

var result = collection.AsQueryable()
              .Where(x => x.Foo == 114)

什么是更好的?

基于整个集合的LINQ过滤器?在我获得整个收藏然后过滤之前?或者在过滤器之前,它给了我已经过滤的集合?

解答

两者的作用几乎相同。

LINQ API 是 Collection API 的包装器。

通过简要研究mongo-csharp-driver的来源,我可以看到 LINQ 版本调用Collection.FindAs(...)或Collection.Distinct(...)。它基于 LINQ 表达式构造在query参数中传递的IMongoQuery。为此,它使用查询构建器 API(Query类),例如Query.EQ

什么更好?

这取决于。

• 如果您在 C# 代码中有表示数据库中文档结构的类型,那么您可能会从 LINQ API 中受益。您将受益于强类型、更好的可读性,并且您不会错过名称作为字符串传递的重命名标识符。

• 如果你有动态的数据结构,在代码中没有具体的表示(你有某种关于文档的元数据,但没有明确包含文档属性的class)。在这种情况下,使用 LINQ 会很困难,而原始的 Collection API 会是更好的选择。

基于整个集合的 LINQ 过滤器?在我获得整个收藏然后过滤之前?或者在过滤器之前,它给了我已经过滤的集合?

由于 LINQ API 实现了IQueryable而不仅仅是IEnumeable,所有可枚举的方法(例如Where或OrderBy)实际上并没有被调用,而是在编译期间被转换为构建表达式树的代码。在运行时,构建表达式树并将其传递给底层查询提供程序(在本例中由 MongoDB 驱动程序实现)。查询提供程序将表达式树转换为常规 MongoDB 查询,并通过常规 MongoDB API 执行它们。

有关更多详细信息,请参见如何:使用表达式树构建动态查询。

所以查询实际上是在数据库中执行的,只有经过处理(过滤、排序或投影)的结果才会返回给应用程序。

然而,使用 LINQ API 意味着一些性能开销,因为除了运行查询之外,LINQ API 还:

• 构建表达式树以将它们传递给查询提供程序

• 访问表达式树,将它们翻译成原生查询

在许多情况下,这种开销可以忽略不计,但这取决于您的要求。