Azure Search is not as mature as Apache Solr at this point. So the range of query flexibility is less than Solr. Also, when indexing content goes beyond 1 TB, it might become costly for Azure Search.
As I've mentioned, the biggest competitor to Azure Search is actually Azure SQL Database. It doesn't have as many features, but it's more economical and most .Net applications will have one already. As long as you can arrive at a schema and ranking strategy, it's a "good …
Solr spins up nicely and works effectively for small enterprise environments providing helpful mechanisms for fuzzy searches and facetted searching. For larger enterprises with complex business solutions you'll find the need to hire an expert Solr engineer to optimize the powerful platform to your needs. Internationalization is tricky with Solr and many hosting solutions may limit you to a latin character set.
It's very useful when used with large file systems, once the models index the files good enough, the suggestions are very impressive and produce grounded answers. Since it can natively work with blob storage the requirement for pre-processing the data is eliminated i.e. the data can be searched in its raw form, this makes Azure AI Search a very powerful tool when used with Azure Stack.
Easy to get started with Apache Solr. Whether it is tackling a setup issue or trying to learn some of the more advanced features, there are plenty of resources to help you out and get you going.
Performance. Apache Solr allows for a lot of custom tuning (if needed) and provides great out of the box performance for searching on large data sets.
Maintenance. After setting up Solr in a production environment there are plenty of tools provided to help you maintain and update your application. Apache Solr comes with great fault tolerance built in and has proven to be very reliable.
These examples are due to the way we use Apache Solr. I think we have had the same problems with other NoSQL databases (but perhaps not the same solution). High data volumes of data and a lot of users were the causes.
We have lot of classifications and lot of data for each classification. This gave us several problems:
First: We couldn't keep all our data in Solr. Then we have all data in our MySQL DB and searching data in Solr. So we need to be sure to update and match the 2 databases in the same time.
Second: We needed several load balanced Solr databases.
Third: We needed to update all the databases and keep old data status.
If I don't speak about problems due to our lack of experience, the main Solr problem came from frequency of updates vs validation of several database. We encountered several locks due to this (our ops team didn't want to use real clustering, so all DB weren't updated). Problem messages were not always clear and we several days to understand the problems.
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.
I give 10 rating because by using this endpoint and api key only we able to build that chatbot product in a timeline given by our client and also creating the endpoint and keys from the portal is also very easy for Azure AI Search and it doesn't take much time and also scalability is good.
We tried to use both Elasticsearch and Swiftype with Drupal 8 but there are currently no good modules that integrate Drupal with those solutions. So Solr was really the only option for a Drupal 8 web site. It's not as easy to learn or use as Swiftype, but in the end I think it will be a little less expensive and offer more customization and flexibility.
It is good for me, and I want to rate this product 9/10. I hope they continue to improve and also offer a free plan with more benefits to learn Azure AI Search.
When integrated with our existing file system the Azure AI Search helped users tremendously by reducing search times and improve efficacy of intended result.
Since Azure AI Search is a PaaS solution, we had very short ideation to go-live timespan, which ended up reflecting in our product performance.
A rare but not negligible occurrence was correctness of search being questionable when new data was added to the system. The search returns false positive results.
