On 3/22/2018 7:13 AM, Steven White wrote:
There are some good write ups on the internet comparing the two and the one
thing that keeps coming up about Elasticsearch being superior to Solr is
it's analytic capability. However, I cannot find what those analytic
capabilities are and why they cannot be done using Solr. Can someone help
me with this question?
The first thing I have to say is that getting an unbiased opinion on a
Solr mailing list is probably never going to happen.
Personally, I'm a Solr user and the thing that concerns me about
Elasticsearch is the fact that it is owned by a company that can any day
decide to stop making Elasticsearch avaialble under Apache license and even
completely close free access to it.
So, this is a 2 part question:
1) What are the analytic capability of Elasticsearch that cannot be done
using Solr? I want to see a complete list if possible.
There's very little that you can do with one that you can't do with the
other. I haven't actually installed or tried ES, but I do try to at
least be semi-aware of what's going on in this little world of search.
ES seems to handle a novice user a lot better than Solr does.
Solr has a very steep learning curve ... and can even be challenging for
a seasoned system administrator when they first start working with it.
The documentation is excellent for someone who already knows their way
around, but for a beginner, is very overwhelming. Once the basics
becomes familiar, working with it is relatively easy.
My general impression is that Solr has far more capability built in than
ES does. This is reflected in download size. The ES download is less
than 30 MB, while Solr weighs in at nearly 150MB. Most users are never
going to need all that additional stuff that Solr includes. The
majority of an ES download is Lucene, while Solr includes a LOT of
additional libraries in the main application, and a TON of contrib
material. The configurations tend to have a "kitchen sink" mentality,
while the sample configs for ES are pretty lightweight.
It's my understanding that in performance tests, if you actually
configure both systems similar to each other (NOT using out-of-the-box
configurations), that performance is about the same, and Solr might be
slightly faster.
ES has the ELK stack, which from what I understand, makes log management
a lot easier. Solr can be coaxed into doing everything ES does for log
management, but there's nothing *included* with Solr to do the heavy
lifting for you. LucidWorks has the SiLK stack, which I once tried to
get working, without success.
There is a software package called Jepsen that has been used to test
both ES and Solr, to learn how they deal with network environment
issues. Solr did quite well. The testing revealed some bugs, which
have been fixed. For ES, the testing revealed some fundamental design
problems. I do not know whether those problems have been fixed in newer
versions or not.
2) Should an Elasticsearch user be worried that Elasticsearch may close
it's open-source policy at anytime or that outsiders have no say about it's
road map?
I doubt they'll ever completely close things up. Like Solr, most of its
functionality comes from Lucene. Because Lucene is under the Apache
umbrella, it's not likely to disappear, and without Lucene, both Solr
and ES are nothing.
I don't have any sense as to how much the Elastic dev team listens to
its community. Solr has a great community, and many of its members
contribute a lot to Solr development.
Elastic might decide that they can make more money by switching to an
"open core" model ... but I think that is becoming less common in recent
years, because enough users are familiar with it and aren't fooled. It
doesn't seem likely to me that they would try it.
Solr is a subproject of Lucene, and is found in the same source code
repository as Lucene. Its releases are in lock-step with Lucene, and
the integration is very tight. The team of committers for Lucene has
people from both projects on it.
Thanks,
Shawn
