Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of yseeley@gmail.com designates
 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: yseeley@gmail.com
In-Reply-To: 
 <CAEFAe-FmhGq6rxjWX5Sw3r1=Gkh0HXyJeg5hDX-vvOWDm0W3vA@mail.gmail.com>
References: <4DE5A4E6.8030302@gmail.com>
	<1311690781414-3200492.post@n3.nabble.com>
	<CAKQOKRpG8C9CEKqQpUra=HcVqvnZGfV_hePnD_htw-2Hkj8=xA@mail.gmail.com>
	<CANNBgP+ehgEuTAf6McumMbyuoYU99xBenEwVJOi_CqevsUn7Ow@mail.gmail.com>
	<CAKQOKRpJ0qp6OY8wRcSumLgpZ+esCgd-wcQPyp506jRaQK4i_Q@mail.gmail.com>
	<CANNBgP+dfTyjRV1BqX5ZPcZjVt2QzAadcBzZRWx_kWCGFfJ_8g@mail.gmail.com>
	<53DF28D9.7050401@raytion.com>
	<CAEFAe-FmhGq6rxjWX5Sw3r1=Gkh0HXyJeg5hDX-vvOWDm0W3vA@mail.gmail.com>
Date: Mon, 4 Aug 2014 08:52:21 -0400
Message-ID: 
 <CAB_8Yd-i3n2byzTj02ZdgZ6=pK+vM4A4cGSU81fd+ZcQKSM1Zw@mail.gmail.com>
Subject: Re: Solr vs ElasticSearch
From: Yonik Seeley <yonik@heliosearch.com>
To: "solr-user@lucene.apache.org" <solr-user@lucene.apache.org>
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 4, 2014 at 2:43 AM, Alexandre Rafalovitch
<arafalov@gmail.com> wrote:
> That resource is rather superficial. I wouldn't make big decision based on it.

Agree.  It's also somewhat biased given the environment in which it
grew.  ES advocates were all over stuff like that, but Solr advocates
were less vocal.

Qualitatively:
Solr facets and function queries were faster for ages (no idea if they
still are or not...).
Solr's faceting took up far less memory (that's probably changed
too)... but no mention.
Solr had efficient deep paging first, but most assume it was the other
way around: https://github.com/elasticsearch/elasticsearch/issues/4940
Solr's "function queries" were far faster - I evaluated the mvel
scripting language used by ES for this stuff... it was dog slow.

Some something more concrete:
Solr's faceting gives exact counts for the constraints returned, while
ES still does not (it still does a naive "sum top N from each shard".)

Some things in the table are just wrong:
- Under "joins" for Solr, it says "It's not supported in distributed
search.", yet ES has the exact same limitations... joined docs must be
on the same shard (and provided that is true, joins are both supported
in Solr and ES).
- The comment for "Negative Boosting" is just wrong.  It is supported.
- "Online schema changes" is incorrect for Solr - it is supported.
- "Structured Query DSL"... yes, we've had it forever.  No it's not JSON.
- "Advanced Faceting" is simply a "no" under solr and a "yes" under
ES... this is incorrect.  The tooltip says "metrics and bucketing",
which solr has had forever (facet stats) that tons of people have used
to build BI tools.  Heliosearch adds even more of course.

There are probably things wrong on the ES side too of course.

But then at the bottom some of the things in "Thoughts..." are unfair
and biasing...
"""As Matt Weber points out below, ElasticSearch was built to be
distributed from the ground up, not tacked on as an 'afterthought'
like it was with Solr. This is totally evident when examining the
design and architecture of the 2 products, and also when browsing the
source code."""

That's from a well known ES advocate of course.  But software, just
like arguments, should be evaluated in it's merits.


-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data