I was wondering what was the difference (performance or something else) between using either of these methods to query a cosmo container, other than using LINQ vs SQL and assuming that I use the ToFeedIterator()
method like mentioned in the docs (also below in case it changes) for Container.GetItemLinqQueryable
.
// LINQ query generation
using (FeedIterator<Book> setIterator = container.GetItemLinqQueryable<Book>()
.Where(b => b.Title == "War and Peace")
.ToFeedIterator())
{
//Asynchronous query execution
while (setIterator.HasMoreResults)
{
foreach(var item in await setIterator.ReadNextAsync())
{
Console.WriteLine(item.Price);
}
}
}
Slight Edge: SQL.
I had the same question and I learned that the LINQ is converted to a SQL QUERY behind the scenes. Therefore - the performance is pretty much the same. You can give an edge to SQL since it didn't have to run the routine to generate the query but that's likely unnoticable.
I guess a trick one could do for critical data operations is write the query in both SQL and LINQ... then see what kind of SQL cosmos db converts the LINQ to and maybe it's better than what one wrote. That's probably where differences come into play.
Then of course there are stored procedures but that's outside the scope of this question.
From MS:
LINQ to SQL translation in Azure Cosmos DB for NoSQL
The Azure Cosmos DB query provider performs a best effort mapping from a LINQ query into an Azure Cosmos DB SQL query. If you want to get the SQL query that is translated from LINQ, use the ToString() method on the generated IQueryable object.
These tuner articles talk about SQL not LINK as well. So SQL has the edge. Tuning query performance with Azure Cosmos DB