Elastic Search vs Sunspot comparison on features

Question

Couden't find any compare questions related to sunspot (Solr) to Elastic Search (Lucene) What would be the pro's and con's on both search engines?

I saw other VS questions to get a better inside in the comparisment of 2 gems so hope this is allowed to get a better insight in the both engines for newbies ( like me ). I have looked at sunspot already but have some issues with it. So I searched

• http://www.elasticsearch.org/guide/reference/api/

vs

• http://sunspot.github.com/

Oversew

Solr is a service layer on top of Lucene. It just depends on how you want to architect. – Neilson

A more apt comparison question would be Solr vs ElasticSearch, or Sunspot vs Tire. – Bulrush

Answer 1

I think you should search for a comparison between Solr and elastic search. In fact sunspot is based on Solr, and both Solr and elastic search are based on Lucene. They are two different projects with similar goals, both built on top of Lucene.

Here are two comparisons:

ElasticSearch, Sphinx, Lucene, Solr, Xapian. Which fits for which usage?

http://www.findbestopensource.com/article-detail/solr-vs-elasticsearch

Smoot

Okay I did not knew they both based on Lucene, great links with much info thanks a lot for posting. – Oversew

Answer 2

I started working on a project that needed full text search in Ruby so naturally I started with Solr + Sunspot, but I couldn't get it to work. It was a pain just the get them connected, then tried to figure out if the document indexed correctly, figure out the runtime classpath so I can add additional analyzer/tokenizer classes, editing config.xml/schema.xml, etc. Solr numDocs clearly said it received and indexed them but I couldn't get any query results. I just gave up after a couple days, it was kind of a configuration hell.

ElasticSearch + Tire was a breezy to get it up and running, I got it working in an hour.

Lucene is just a Java search library, hence Solr was developed to be a full service search app, but Solr still have all the trapping of a typical Java webapp: overly complicated XML configurations, schema-heavy, expect XML docs for indexing, requires a Java servlet container (Jetty or Tomcat), which just become too many points of failure for me.

ElasticSearch is based on Lucene too, it has a built-in servlet container so just run like a daemon, use a very straight forward JSON + REST API so it's great for testing and a more natural fit for Ruby. It's schemaless and it worked for me without even editing a config file. Everything worked beautifully.

What I really needed was Chinese search and ElasticSearch already packaged Luecene's SmartChineseAnalyzer as a plugin. Not sure how difficult it will be to customize the analyzer/tokenizer chain if you need that level of customization. Docmentation for ElasticSearch and Tire are both top-notch.

Tire (Ruby library for ElasticSearch)

https://github.com/karmi/tire

You can try out the demo, it'll install a rails searchapp, download the ElasticSearch binary and run it, then start Webrick automatically.

$ rails new searchapp -m https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb

On my system it complained about not having a Javascript engine (Rails 3.2? no longer include thereubyracer gem by default), so I had to:

$ wget https://raw.github.com/karmi/tire/master/examples/rails-application-template.rb
$ nano rails-application-template.rb

add gem 'therubyracer' in the file (look for gem 'tire' and gem 'will_paginate'), then...

$ rails new searchapp -m rails-application-template.rb

For developing my own app, I just downladed the ElasticSearch tarball and run in the foreground with the -f switch (so I can easily stop it by Ctrl-C)

$ bin/elasticsearch -f

You can install the eleasticsearch-head plugin to get a web admin interface

https://github.com/mobz/elasticsearch-head

Also something I found out: if you have one-to-many relationship models, Tire won't resolve them for you in the search results, it just returns a flat collection. Your has_many and belongs_to relationships will just be object ids in the collection rather than full objects.

Syllabize

Answer 3

Here is the most complete up-to-date post on the topic: http://solr-vs-elasticsearch.com/

My recommendations as of May 2018

Here are some simple guidelines if the crazy long grid of features above did not help.

Choose Solr if any of the following are true...

• Your team consists mainly of Java programmers
• You're already using ZooKeeper in your stack
• You're already using Java in your stack
• You are building a search application that has specific and nuanced relevancy requirements
• You are building an ecommerce, job, or product search engine
• Search is a central part of your product and user experience and there is the organizational mandate for search to be a core strength

Choose Elasticsearch if any of the following are true...

• Your team consists mainly of Ruby/PHP/Python/full stack programmers (and your application does not have specific and nuanced relevancy requirements)
• You live and breathe JSON
• You already use Kibana/ELK for managing your logs
• Your application is analytics-heavy

If in doubt...

Every serious search application I have worked on has required in-depth customization of the search workflow and relevancy tweaks, and at the time of writing, this is simply not possible in Elasticsearch without major hacking. If in doubt, go Solr.

Drugget