Sitecore – SolrNet vs ContentSearch

I got a very relevant question on one of my prior Blog posts:

 “I saw you mentioning using SolrNet but i thought ContentSearch was using

SolrNet underneath.what do i gain using one vs another?”

This post shares some of my experiences and thought’s on the above question.

First of all, “Yes”, Sitecore ContentSearch uses SolrNet when you choose to use Solr instead of Lucene. So if you are familiar with the Content Search API, you don’t have to worry about it really; you just continue to do what you normally do.

If you dive in a little deeper there are some differences in flexibility and potentially performance. That’s really no surprise since – I see the ContentSearch to be more abstract as it hides some of the specifics of Solr. But say you have a very high performance website, and you have to tune and configure Solr – the actual Solr queries will impact performance.

Let’s look at an example. Say that we have some “Article” items in Sitecore with Title, Body and Category fields. The Category is a Multilist. Below examples on how to do such a query using ContentSearch as well as SolrNet directly to find all Articles in a specific category.

ContentSearch API

The following Content Search query:

IQueryable<ArticleQueryModel>query = searchContext.GetQueryable<ArticleQueryModel>();
query = query.Where(x => x.TemplateName == "Article");
query = query.Where(x => x.Category.Contains(ArticleCategoryNewsId));

Results in a Solr Query like this:

select?q=(_templatename:(Article) AND category_sm:(7febb1f1bc4e4b2a9fc7710f98f084ef))&fq=_indexname:(sitecore_web_index)

SolrNet

The following SolrNet Query:

 

var solrQuery = new SolrQueryByField("_templatename", "Article");
var queryOptions = new QueryOptions();
queryOptions.FilterQueries.Add(new SolrQueryByField("category_sm", ArticleCategoryNewsIdStr));

Results in a Solr Query like this:

select?q=_templatename:(Article)&fq=category_sm:(7febb1f1bc4e4b2a9fc7710f98f084ef)

SolrNet

So the difference is around the use of Solr “FilterQueries” – the fq parameter. Sitecores ContentSearch API converts it into the use of logical AND, where the use of SolrNet directly converts it into separate filter queries.

So the question is what difference does this make?

If you have millions of items in Solr that you query – there will be a difference. The major difference is that with Filter Queries Solr can utilize a FilterCache. If you have a large index, uses a lot of facets and queries it can make a big difference in performance. Also – the filter cache can be configured with more dedicated memory if needed.

What to use?

Depends on the specific solution – as always. It’s easy to use the ContentSearch API; so stick to that unless you know that you are working with a lot of data. In some cases, we do both – e.g. if we need a specific Solr function such as “MoreLikeThis”. SolrNet implements this directly and is easy to use for such a special functionality.

An obvious question would be if one can extend the existing ContentSearch API – and force it to utilize fq instead? That could be a challenge worth for another Blog post.

 

Relevant links

https://wiki.apache.org/solr/SolrCaching#filterCache

https://kb.sitecore.net/articles/227897

Sitecore – SolrNet vs ContentSearch
Tagged on:             

2 thoughts on “Sitecore – SolrNet vs ContentSearch

  • September 13, 2017 at 8:26 am
    Permalink

    Hello – I am planning to Integrate SOLR with my sitecore 7.2 solution. I am able to integrate SOLR 4.1. But I would like to know if I can use SOLR 6.6 with my current sitecore 7.2 Installation. If yes, do you have any document or steps which can help me to integrate.

    Thanks in Advance!!

    Reply
    • September 14, 2017 at 11:43 am
      Permalink

      Hi Manvendra,
      We have tried a lot of combinations of Sitecore and Solr, but not Sitecore 7.2 and Solr 6.6. But I don’t see a reason why it shouldn’t be possible. Let us know if you need help, or have any other questions – and please comment here if you set it up 🙂

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *