Apache Solr vs. Constructor.io Search

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.

Incentivized

Constructor.io Search takes all of the guesswork out of maintaining a search engine. As merchandisers or product teams, we have educated guesses at how search relevance should work but the customer is always king. We can't always predict the ways in which consumers will search or what their intent is. That's why the behavioral-driven approach that Constructor.io employs works so well. It means that merchandisers can focus on their sales and promotional responsibilities, instead of wasting time and bandwidth on base-level relevance questions.

Incentivized

• 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.

Incentivized

• Optimizes for business KPIs, not string matches, so merchandisers can focus on strategy instead of maintaining a dictionary.
• Gives merchandisers control to curate the right customer experience per their expert understanding.
• Customer/technical support during and after implementation.

Incentivized

• 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.

• Visibility of the personalization algorithm.
• Exposing detailed analytics within the customer-facing dashboard.
• "Top searches" available via API.

Incentivized

Apache Solr is a ready-to-use product addressing specific use cases such as keyword searches from a huge set of data documents.

Incentivized

• Improved response time in e-commerce websites.
• Developer's job is easier with Apache Solr in use.
• Customization in filtering and sorting is possible.

Incentivized