3 ms·

>"For retail/catalog search SOLR dominates." Interesting, could you elaborate on why SOLR is dominant in that space over say Elasticsearch?

crawdog 7y ago
Definitely. Product catalog information as a whole doesn't change often. Price and availability does. With retail catalogs you often do a full reindex of the data in your master catalog and then run partials to account for price/availability if you don't do that in realtime using filters. Since the system of record is not the search index, Elastic is often not a good solution here. Also, relevancy in retail is often influenced by other factors that cannot easily be implemented in Elastic. TFIDF/BM25 search is available in both platforms, but you may also weigh in other factors such as relationships with the vendor, stock on hand, or other ML techniques that are more easily implemented in SOLR.
- crawdog 7y ago
  One more point - if you can run the entire index on one machine it makes deploying and managing SOLR much easier to manage than Elastic. The complexity only grows when you have a distributed system. You can fit a lot on a big box.
  - gvurrdon 7y ago
    Yes, it's certainly easy to manage on one system. As the production system I work on is an academic one with few concurrent users it's possible to get away with that.
- bogomipz 7y ago
  Thanks for the explanation and insight. I hadn't ever considered how different the catalog use case is from my own use cases. Makes good sense. Cheers.
jillesvangurp 7y ago
I think a big reason is simply that Solr has been around a few years longer and most older sites would have been using that by the time Elasticsearch came along and never saw a good reason to go through a painful process of replacing one with the other. These days, I would say there's very little that either product does that the other product can't do though obviously there are lots of strengths and weaknesses on both sides.

crawdog 7y ago

Definitely. Product catalog information as a whole doesn't change often. Price and availability does. With retail catalogs you often do a full reindex of the data in your master catalog and then run partials to account for price/availability if you don't do that in realtime using filters. Since the system of record is not the search index, Elastic is often not a good solution here. Also, relevancy in retail is often influenced by other factors that cannot easily be implemented in Elastic. TFIDF/BM25 search is available in both platforms, but you may also weigh in other factors such as relationships with the vendor, stock on hand, or other ML techniques that are more easily implemented in SOLR.

crawdog 7y ago
One more point - if you can run the entire index on one machine it makes deploying and managing SOLR much easier to manage than Elastic. The complexity only grows when you have a distributed system. You can fit a lot on a big box.
- gvurrdon 7y ago
  Yes, it's certainly easy to manage on one system. As the production system I work on is an academic one with few concurrent users it's possible to get away with that.
bogomipz 7y ago
Thanks for the explanation and insight. I hadn't ever considered how different the catalog use case is from my own use cases. Makes good sense. Cheers.

jillesvangurp 7y ago

I think a big reason is simply that Solr has been around a few years longer and most older sites would have been using that by the time Elasticsearch came along and never saw a good reason to go through a painful process of replacing one with the other. These days, I would say there's very little that either product does that the other product can't do though obviously there are lots of strengths and weaknesses on both sides.