Azure Cognitive Search Experience in Sitecore 9.2: Pros and Cons

Hey there! In this blog post, I want to share my development experience with Search in Sitecore 9.2.

I have been working with Search in Sitecore for more than four years with different engines, including SOLR, Lucene and Azure Search (this is not to be confused with Azure ElasticSearch, because in version 9.2, Sitecore didn’t have an SDK to work with this one).

By this time, I’ve touched upon different scenarios of Search implementation:

• Supporting both Azure Search and SOLR at the same time
• Integrating third-party tools to provide data for a custom index
• Covering all CRUD functions for Custom Index crawler
• Increasing performance for the custom Index full-rebuild logic
• Implementing cloud solutions for incremental index update
• Creating a tool to manage search results on the website according to different criteria (dates, events, filters)

It was a long journey and tons of challenges, and I will be happy if some tips from this and my future blogs will save your time during planning or troubleshooting.

The Search functionality is an important feature on many websites related to content management (literally, it means almost all Sitecore-based websites). And in my experience, indexing/search logic was sometimes really complicated and required a deep understanding of what you could do with the available tools set.

What is the first step in all systems that requires Search?

The first and most important step is to collect as many search-related requirements as possible. Otherwise, it’s hard to design a schema and choose the Search engine if you don’t know how it will be used. To clarify versions, we started our project on Sitecore 9.2 because it was the latest one at that moment.

The customer wanted to use Azure Cognitive Search on production, and this was the first issue we faced, because (as we learned later) the project turned out to be complicated in terms of the search business logic. For some reasons, we couldn’t pull together all the requirements on time. So eventually, we selected Azure Cognitive Search for all shared environments (Dev, QA, Staging and Production) and SOLR for local environments.

It was a mistake for several reasons:

1. It took additional time to support several Search Engines.
2. As mentioned above, the search functionality caused performance bottlenecks (will be described later).
3. Some bugs were reproduced only on Azure Search or SOLR.
4. Different limitations from both system took time to deal with.
5. Local testing/development.
6. Sitecore SDK for both works differently when using Search.

As you can see, it was a pretty bad idea trying to mix it all. But we were brave enough to try it.

Azure Cognitive Search limitations

Here I will try to show all limitations that can affect your work during the project life.

1. An Azure Cognitive Search index can only contain up to 1000 fields. It means that all your fields + all fields that will be created (multi-language fields (1 field for every original field for one language), system fields) are limited by 1000. This is not much at all.
2. Joining queries such as .GroupJoin(), .SelfJoin(), and other operators that join queries, is not supported and results in an error. For our case, it was mandatory to have Group operations on the Search Server side. While the Azure Search was exploited on the website, the Search response could take up to 15 seconds(!!!) because group operations were performed on the Server side instead of the Search engine.
3. Some weird behavior for equaling string operations. It turned out that getting only equivalent results to the specific string is not supported on the Azure Search LINQ Query converter level. The reason is converting the .Equals() LINQ function into Azure search query.
   

Here, if the expression is string and the trimmed expression length isn’t equal to 0, this._queryBuilder.SearchQueryBuilder.Equal will be used. Let’s take a look what this method contains inside.

It contains typical Contains() function in the {fieldName}:(“{value}”) format.

You can invent something with different types (e.g., double, integer) as a workaround. This is the first signal that should make you consider the migration to the different Search Engine.

More limitations you can find here.

Azure Cognitive Search advantages

At the same time, Azure Cognitive Search has advantages too:

1. It’s powered by Azure, meaning that you can integrate search into different Azure apps.
2. It has 99.9% SLA, which is important for the production environment.
3. It’s easy to configure auto-scale.
4. It works pretty good for simple Search solutions.
5. Due to the fact that it’s a SaaS solution, it’s pretty easy to set up.

But these advantages could not outperform challenges that we faced, and finally, we switched from Azure Cognitive Search to SOLR, which made our solution easier to support and increased performance multiple times.

P.S.

In my following blog posts, I want to describe how we created the SOLR custom index, what issues we faced, and how we built the Full-Rebuild process. Stay tuned and try to avoid big challenges instead of fighting with them.