To answer Otis' question of whether or not this would be useful, the
trouble is, I don't know! :) It very well could be useful for my use case.

Is there any way to determine the impact of result merging (time spent?
Etc?) aside from just 'trying it'?

Cheers,

Tim


On 10 June 2013 14:48, Otis Gospodnetic <otis.gospodne...@gmail.com> wrote:

> I think it would be useful.  I know people using ElasticSearch use it
> relatively often.
>
> >  Is aggregation expensive enough to warrant a separate box?
>
> I think it can get expensive if X in rows=X is highish.  We've seen
> this reported here on the Solr ML before....
> So to make sorting/merging of N result set from N "data nodes" on this
> "aggregator node" you may want to get all the CPU you can get and not
> have the CPU simultaneously also try to handle incoming queries.
>
> Otis
> --
> Solr & ElasticSearch Support
> http://sematext.com/
>
>
>
>
>
> On Mon, Jun 10, 2013 at 5:32 AM, Shalin Shekhar Mangar
> <shalinman...@gmail.com> wrote:
> > No, there's no such notion in SolrCloud. Each node that is part of a
> > collection/shard is a replica and will handle indexing/querying. Even
> > though you can send a request to a node containing a different
> collection,
> > the request would just be forwarded to the right node and will be
> executed
> > there.
> >
> > That being said, do people find such a feature useful? Is aggregation
> > expensive enough to warrant a separate box? In a distributed search, the
> > local index is used. One'd would just be adding a couple of extra network
> > requests if you don't have a local index.
> >
> >
> > On Sun, Jun 9, 2013 at 11:18 AM, Otis Gospodnetic <
> > otis.gospodne...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> Is there a notion of a data-node vs. non-data node in SolrCloud?
> >> Something a la
> http://www.elasticsearch.org/guide/reference/modules/node/
> >>
> >>
> >> Thanks,
> >> Otis
> >> Solr & ElasticSearch Support
> >> http://sematext.com/
> >>
> >
> >
> >
> > --
> > Regards,
> > Shalin Shekhar Mangar.
>

Reply via email to