Производительность при использовании Filter.Where с помощью драйвера

Question

MongoDB C# Допустим, есть следующие строки кода:

var filter = Builders<BsonDocument>.Filter.Where(t => t.id == myId); 
var result = collection.Find(filter).ToList(); 

ли перевести фильтр строитель лямбда буквального $, где положение или это оптимизировать его для использования предложение $ eq? $ где медленная производительность, поэтому я не хочу ее использовать, если нет перевода.

Это простой пример, но у нас есть другие запросы в нашем коде, которые являются более длинными, но легко перевести на non $ где запросы.

Answer 1

Я понятия не имею. Я посмотрю на это сегодня вечером и вернусь к вам.

Answer 2

Благодаря комментариям Давида Осборна выше, я смог сделать немного больше исследований и придумать ответ. Оказывается, простые запросы LINQ на самом деле переводятся непосредственно на собственные запросы Mongo, а не на $ where query.

var filter = Builders<BsonDocument>.Filter.Where(x => x["status"] != "ready"); 
var findFluent = collection.Find(filter); 

Console.WriteLine(findFluent); 

filter = Builders<BsonDocument>.Filter.Ne("status", "ready"); 
var findFluent = collection.Find(filter); 

Console.WriteLine(findFluent); 

Оба печатают идентичные запросы. Это справедливо для простых комбинаций равенства и логических операторов.

Однако некоторые операторы оказываются недоступными через LINQ. Я попытался написать $ в запросе

var success = new List<string> { "imported", "processed" }; 
var filter = Builders<BsonDocument>.Filter.Where(x => success.Contains(x["status"].ToString())); 

и получил ошибку времени выполнения. Аналогичным образом с регулярным выражением

var regex = new Regex("^*0000"); 
var filter = Builders<BsonDocument>.Filter.Where(x => regex.IsMatch(x["orderId"].ToString())); 

Не удивительно, но приятно знать.