Very effective for end-user searching applications and for generating search results. Also very well suited to those looking for high reliability and performance. If [you're doing] fuzzy searching or if you are working on a smaller end-user application or an internal application that does not require high performance and flexible/adapting searching then it may not be necessary to use Solr.
If you have a medium amount of data (2GB - 2.4TB), high-security concerns, and search is a key requirement in your single-tenant application then Azure Search likely has you covered. If you have a small amount of data per tenant (EG, about 2GB), have low-security concerns, and a multi-tenant application where search is a key requirement, then Azure Search would likely be a good choice - though you would need to implement your own concept of sharding and managing across potentially multiple Azure Search instances. If you can reflect your would-be indexes in Azure Search by depositing the data in columns in a SQL table and just index it for full-text search - and that still fits your requirements - it's probably better to start with SQL Database then scale up to Azure Search when you need the advanced features like ranking or cognitive abilities.
Faceted navigation and field collapsing/grouping : filtering and quick results were what we needed for our websites. Our customers needed to have this functionalities for good and efficient results.
We tested them with our customers' registered searches (they received all new goods matching with their registered searches by emails and/or mobile push). Results were incredible by comparison with our old system (old MySQL requests).
Note : we didn't put all our data in Solr. Just what we need for searching uses. Other data stayed in our MySQL database.
Auto-suggest : our old auto-suggest wasn't performing well. With Apache Solr, our new one was worked really well ! The suggestions came quickly and suggestions were good.
We also extended auto-suggestion with geo-spatial data and it worked well.
Hit highlighting : we used this functionality and we didn't have problem and nasty surprise.
Keep all data status during data upgrading (see next details for improvements)
Like virtually all Azure services, it has first-class treatment for .Net as the developer platform of choice, but largely ignores other options. While there is a first-party Python SDK, there are only community packages for other languages like Ruby and Node. Might be a game of roulette for those to be kept up-to-date. This might make it a non-starter for some teams that don't want to do the work to integrate with the REST API directly.
In my opinion, partitions inside of Azure Search don't count as data segregation for customers in a multi-tenant app, so any application where you have many customers with high-security concerns, Azure Search is probably a non-starter.
To elaborate on the multi-tenant issue: Azure Search's approach to pricing is pretty steep. While there is a free tier for small applications (50MB of content or less) the first paid tier is about 14x more expensive than the first SQL Database tier that supports full-text search. For many applications, it makes a lot more economic sense to just run some LIKE or CONTAINS queries on columns in a table rather than going with Azure Search.
It takes some time to deploy and currectly maintein it. And also, to learn how to use and integrate in the enviroment as well. Once you get theses steps done, it usability is very simple, and almost of the time it don't require no further attention on it. Even for maintence, if you deploy it on a cluster mode, it is very reliable and easy to take one host down.
We switched from search indexes stored in MySQL to soar and it's made a world of difference for our growing businesses. The relational databases are very poor for handling the complex data searches require and Solr delivered all the tools we need to get the performance our end users are demanding.
Azure Search is a competitor against Google's own AI autosuggest a feature. We went with Azure because our network security folks found it to be more robust from a security standpoint, which is incredibly important when you have proprietary manufacturing information. Additionally, we're a Microsoft shop so it plugged into our cloud hosting package and client facing OS.
It's enabled us to deliver fast, relevant search results on our new website. The site is still in beta and being actively developed so our complete ROI is still unknown.
It integrates very well with Drupal so it has saved us from having to develop a custom solution.
