时间戳

首页 > 解决方案 > MongoDb驱动c#查询优化

c# - MongoDb驱动c#查询优化

问题描述

我在 mongo db doc 中读到了我也可以使用 LINQ，但我对此一无所知。

例如，如果我写：

var result = collection.Find(filter);

和

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

什么是更好的？

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

标签： c#mongodbperformancelinq

解决方案

两者的作用几乎相同。

LINQ API 是 Collection API 的包装器。

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

什么是更好的？

这取决于。

  • 如果您在 C# 代码中具有表示数据库中文档结构的类型，那么您可能会从 LINQ API 中受益。您将受益于强类型、更好的可读性，并且您不会错过名称作为字符串传递的重命名标识符。
  • 如果你有动态的数据结构，在代码中没有具体的表示（你有某种关于文档的元数据，但没有class明确包含文档属性）。在这种情况下，使用 LINQ 会很困难，而原始的 Collection API 会是更好的选择。

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

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

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

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

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

  • 构建表达式树以将它们传递给查询提供程序
  • 访问表达式树以将它们转换为本地查询

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

推荐阅读