
Apache Solr 6.3.0 released - based2
http://mail-archives.apache.org/mod_mbox/www-announce/201611.mbox/%3CCAOOKt51%3D9nAzaUXJZgE5M04JyoZYeD7WdWvan3jAE%3Dz0UD49BA%40mail.gmail.com%3E
======
quickben
After spending a week evaluating if we are to pick Solr or Elastic, here are
some of the more interesting conclusions:

\- Solr comes with optional security config; Elastic charges for Shield. At
the time of the evaluation, Shield pricing wasn't online (and there were hints
online it starts at 1600/year and goes upwards from there).

\- Elastic can have a 'split brain' from time to time, and some data can be
lost.

\- Elastic is more user friendly, but that comes at a price of installing
Kibana + other software. Solr is all-in-one.

\- Both will let you shoot yourself in the foot with dynamic fields and
schema, but if you go the hardcoded schema way, solr is easier to setup.

\- Solr has DataImportHandler, which makes configuring the entire DB import
from an existing database, 2 minutes job once you know what you are doing. The
import seemed to be doing 50k records / second, and it can also do partial
syncs if things have changed.

\- Performance wise, they are both overkill if one is staying away from
managed schemas and provide decently beefed-up VMs. But
Solr+DataImportHandler, gives you one more option (aside from zookeeper) for
cheap scaling. If you have mostly read heavy instances, you can put separate
VMs behind a load balancer to ensure near 100% uptime and robustness, with the
minimal fuss of clicking a button once a month to add the deltas to the
separate VMs.

~~~
ksec
I read this as basically a Win to Solr?

~~~
quickben
They are very very close. The differences are minute at this point. Unless you
are doing some heavy relational algebra, it will be hard to distinguish real
world results for simple queries.

In the end I chose Solr because it comes with 'ecosystem' of semi-related
projects that you can pull on (spark, ambari, etc etc).

On a sidenote, I'm personally more comfortable with forkable sourcebases, than
singular companies with paid plugins. I've been too long in this industry and
have seen all kinds of dirty tricks pulled off.

~~~
emmelaich
For us the authentication options might tip it. Also the ecosystem point is
important; we're using Spark/Avro/..

------
jonbaer
Good (and fair) article on comparison ...
[https://dzone.com/articles/10-reasons-to-choose-apache-
solr-...](https://dzone.com/articles/10-reasons-to-choose-apache-solr-over-
elasticsearc)

------
coredog64
Is there anything like Kibana for Solr?

~~~
jstrassburg
Yes, a port called banana:
[https://github.com/LucidWorks/banana](https://github.com/LucidWorks/banana)

------
IndianAstronaut
Another interesting use case for Solr is to use it as a prebuilt backend with
a REST API for a data based web service/dashboard. We have had quite a bit of
luck doing this and getting our service up and running was quite a bit faster
than trying to build out our own APIs.

------
brian-armstrong
I'd be curious to see the distribution of Solr vs Elasticsearch in production.
Anyone know how you would gather that statistic?

~~~
Thaxll
Elasticsearch is more popular than Solr nowdays.

~~~
arafalov
Is that in absolute install number (see my other thread's comment), in % of
growth number (from 0-base for ES as of only a several years ago), or the
excitement for early features of ElasticSearch that have been disabled or
rolled-back over the last couple of years.

I am somewhat biased because I am a - recent - Solr committer. But I also did
try to do a very balanced comparison presentation two years ago:
[http://www.slideshare.net/arafalov/solr-vs-elasticsearch-
cas...](http://www.slideshare.net/arafalov/solr-vs-elasticsearch-case-by-case)
(kind of popular, 49k views...).

Solr - still - is more flexible than Elasticsearch by several degrees of
magnitude. But Elasticsearch has a better vertical integration story,
especially for analytics. And size (it IS small), because it does not ship
OOTB with documentation (online), full examples (any?), Admin UI (plugin),
rich-text extraction (plugin), data import mechanism (with rivers gone), etc.

If you don't need those, the choice is much more close. And many people do not
need those. The problem is that most of the people don't know what they need
and don't need when they do the evaluation, so they look at the most surface
parameters.

Solr 6 has good startup scripts, (overly) comprehensive examples, REST APIs,
well maintained 700 pages manual, etc. Some of these features are a bit harder
to discover due to legacy information also being very visible. But it is
there.

~~~
IndianAstronaut
As a commiter, are there plans to improve the SOLR SQL interface and add
features to make it more in line with standard SQL? Also, any plans on adding
search syntax to the SQL?

~~~
arafalov
Not by me, but the SQL interface is the bleeding edge of Solr. If the last
time you looked was a month ago, look again. The feature set probably doubled
since. And, for this, don't rely on documentation, it is not complete yet.
Rather, check the Lucene Solr Revolution 2016 slides/videos and search Jira
for SQL keyword. And if you have solid use cases, feel free to create a
feature-request Jira or even help to test and/or develop it.

