ent: Monday, August 4, 2014 3:33 AM
> To: solr-user@lucene.apache.org
>
> Subject: Re: Solr vs ElasticSearch
>
> On Mon, 2014-08-04 at 08:31 +0200, Harald Kirsch wrote:
>
>> As for performance, I would expect that it is very hard to find one of
>> the two technologie
Krupansky
-Original Message-
From: Toke Eskildsen
Sent: Monday, August 4, 2014 3:33 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr vs ElasticSearch
On Mon, 2014-08-04 at 08:31 +0200, Harald Kirsch wrote:
As for performance, I would expect that it is very hard to find one
On Mon, Aug 4, 2014 at 2:43 AM, Alexandre Rafalovitch
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.
On Mon, 2014-08-04 at 08:31 +0200, Harald Kirsch wrote:
> As for performance, I would expect that it is very hard to find one of
> the two technologies to be generally ahead. Except for plain blunders
> that may be lurking in the code, I would think the inner loops, the
> stuff that really burns
That resource is rather superficial. I wouldn't make big decision based on it.
As to performance, ElasticSearch stores the full submitted content as
_source field. That allows it some extra tricks (like fake-nested
documents), but also has a storage price. You can disable the _source
field, but th
Except if I missed it, nobody yet pointed to
http://solr-vs-elasticsearch.com/
which seems to be fairly up-to-date.
As for performance, I would expect that it is very hard to find one of
the two technologies to be generally ahead. Except for plain blunders
that may be lurking in the code, I w
ple say "You've got to check out Elasticsearch!" rather than
for some clear and obvious benefit in terms of features, performance, and
scalability.
-- Jack Krupansky
-Original Message-
From: Salman Akram
Sent: Friday, August 1, 2014 1:35 AM
To: Solr Group
Subject: Re: So
On 01/08/2014 09:53, Alexandre Rafalovitch wrote:
Thank you Charlie, very informative even if non-scientific.
About the aggregations, are they very different from:
http://heliosearch.org/solr-facet-functions/ (obviously not yet
production ready)?
They're the same sort of thing. The ES signific
Thank you Charlie, very informative even if non-scientific.
About the aggregations, are they very different from:
http://heliosearch.org/solr-facet-functions/ (obviously not yet
production ready)?
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newslette
On 01/08/2014 06:43, Alexandre Rafalovitch wrote:
Maybe Charlie Hull can answer that:
https://twitter.com/FlaxSearch/status/494859596117602304 . He seems to
think that - at least in some cases - Solr is faster.
I'll try to expand on the tweet.
Firstly, this is a totally unscientific comparison
If performance is the main reason, you can stick with Solr. Both Solr and
ES have many knobs to turn for performance, it is impossible to give a
direct and correct answer to the question which is faster.
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Suppor
Maybe Charlie Hull can answer that:
https://twitter.com/FlaxSearch/status/494859596117602304 . He seems to
think that - at least in some cases - Solr is faster.
I am also doing a talk and a book on Solr vs. ElasticSearch, but I am
not really planning to address those issues either, only the featur
I did see that earlier. My main concern is search
performance/scalability/throughput which unfortunately that article didn't
address. Any benchmarks or comments about that?
We are already using SOLR but there has been a push to check elasticsearch.
All the benchmarks I have seen are at least few y
Not super fresh, but more recent than the 2 links you sent:
http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Thu, Jul 31, 2014 at 10:33 PM, Salman Ak
This is quite an old discussion. Wanted to check any new comparisons after
SOLR 4 especially with regards to performance/scalability/throughput?
On Tue, Jul 26, 2011 at 7:33 PM, Peter wrote:
> Have a look:
>
>
> http://stackoverflow.com/questions/2271600/elasticsearch-sphinx-lucene-solr-xapian-
On Wed, Jul 27, 2011 at 7:17 AM, Tarjei Huse wrote:
> On 06/01/2011 08:22 AM, Jason Rutherglen wrote:
>> Thanks Shashi, this is oddly coincidental with another issue being put
>> into Solr (SOLR-2193) to help solve some of the NRT issues, the timing
>> is impeccable.
> Hmm, does anyone have an ide
You might also check out Solandra:
https://github.com/tjake/Solandra
With Solr's configuration and indexes in Cassandra, you can benefit from
replication, distribution etc., and still have Cassandra available for non-Solr
specific purposes.
Cheers,
Jeff
On Jul 27, 2011, at 5:17 AM, T
On 06/01/2011 08:22 AM, Jason Rutherglen wrote:
> Thanks Shashi, this is oddly coincidental with another issue being put
> into Solr (SOLR-2193) to help solve some of the NRT issues, the timing
> is impeccable.
Hmm, does anyone have an idea on when this will be finished?
I'm considering if I shoul
Have a look:
http://stackoverflow.com/questions/2271600/elasticsearch-sphinx-lucene-solr-xapian-which-fits-for-which-usage
http://karussell.wordpress.com/2011/05/12/elasticsearch-vs-solr-lucene/
Regards,
Peter.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-vs-Elastic
You _could_ configure it as a slave, if you plan to sometimes use it as
a slave. It can be configured as both a master and a slave. You can
configure it as a slave, but turn off automatic polling. And then issue
one-off replicate commands whenever you want.
But yeah, it gets messy, your use
On Wed, 01 Jun 2011 11:47 -0400, "Jonathan Rochkind"
wrote:
> On 6/1/2011 11:26 AM, Upayavira wrote:
> >
> > Probably the ReplicationHandler would need a 'one-off' replication
> > command...
>
> It's got one already, if you mean a command you can issue to a slave to
> tell it to pull replication
Jonathan,
This is all true, however it ends up being hacky (this is from
experience) and the core on the source needs to be deleted. Feel free
to post to the issue.
Jason
On Wed, Jun 1, 2011 at 8:44 AM, Jonathan Rochkind wrote:
> On 6/1/2011 10:52 AM, Jason Rutherglen wrote:
>>
>> nightmarish
On 6/1/2011 11:26 AM, Upayavira wrote:
Probably the ReplicationHandler would need a 'one-off' replication
command...
It's got one already, if you mean a command you can issue to a slave to
tell it to pull replication right now. The thing is, you can only issue
this command if the core is co
On 6/1/2011 10:52 AM, Jason Rutherglen wrote:
nightmarish to setup. The problem is, it freezes each core into a
respective role, so if I wanted to then 'move' the slave, I can't
because it's still setup as a slave.
Don't know if this helps or not, but you CAN set up a core as both a
master and
> And some way to delete the core when it has been transferred.
Right, I manually added that to CoreAdminHandler. I opened an issue
to try to solve this problem: SOLR-2569
On Wed, Jun 1, 2011 at 8:26 AM, Upayavira wrote:
>
>
> On Wed, 01 Jun 2011 07:52 -0700, "Jason Rutherglen"
> wrote:
>> > I
On Wed, 01 Jun 2011 07:52 -0700, "Jason Rutherglen"
wrote:
> > I'm likely to try playing with moving cores between hosts soon. In
> > theory it shouldn't be hard. We'll see what the practice is like!
>
> Right, in theory it's quite simple, in practice I've setup a master,
> then a slave, then h
> I'm likely to try playing with moving cores between hosts soon. In
> theory it shouldn't be hard. We'll see what the practice is like!
Right, in theory it's quite simple, in practice I've setup a master,
then a slave, then had to add replication to both, then call create
core, then replicate, th
On Tue, 31 May 2011 19:38 -0700, "Jason Rutherglen"
wrote:
> Mark,
>
> Nice email address. I personally have no idea, maybe ask Shay Banon
> to post an answer? I think it's possible to make Solr more elastic,
> eg, it's currently difficult to make it move cores between servers
> without a lot
Well, I recently chose it for a personal project and the deciding
thing for me was that it had nice integration to couchdb.
Thanks,
Bryan Rasmussen
On Wed, Jun 1, 2011 at 4:33 AM, Mark wrote
> I've been hearing more and more about ElasticSearch. Can anyone give me a
> rough overview on how these
Thanks Shashi, this is oddly coincidental with another issue being put
into Solr (SOLR-2193) to help solve some of the NRT issues, the timing
is impeccable.
At a base however Solr uses Lucene, as does ES. I think the main
advantage of ES is the auto-sharding etc. I think it uses a gossip
protoco
Sender: shashi@gmail.com
Date: Wed, 1 Jun 2011 01:01:51
To:
Reply-To: solr-user@lucene.apache.org
Subject: Re: Solr vs ElasticSearch
Here is a very interesting comparison
http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
> -Original Message-
>
Here is a very interesting comparison
http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
> -Original Message-
> From: Mark
> Sent: May-31-11 10:33 PM
> To: solr-user@lucene.apache.org
> Subject: Solr vs ElasticSearch
>
> I've been hearing more and more about
Interesting wordings:
"we want real-time search, we want simple multi-tenancy, and we want a
solution that is built for the cloud"
And later,
" built on top of Lucene."
Is that possible? :)
(what does that mean "real time search" anyway... and what is "cloud"?)
community is growing!
P.S.
I neve
Mark,
Nice email address. I personally have no idea, maybe ask Shay Banon
to post an answer? I think it's possible to make Solr more elastic,
eg, it's currently difficult to make it move cores between servers
without a lot of manual labor.
Jason
On Tue, May 31, 2011 at 7:33 PM, Mark wrote:
>
34 matches
Mail list logo