lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Kan <>
Subject Re: Profiling Solr Lucene for query
Date Wed, 02 Oct 2013 07:55:59 GMT
What Shawn has described is exactly what we do: classical distributed
no-SolrCloud setup. This is why it was possible to implement a custom
frontend solr instance.

On Wed, Oct 2, 2013 at 12:42 AM, Shawn Heisey <> wrote:

> On 10/1/2013 2:35 PM, Isaac Hebsh wrote:
>> Hi Dmitry,
>> I'm trying to examine your suggestion to create a frontend node. It sounds
>> pretty usefull.
>> I saw that every node in solr cluster can serve request for any
>> collection,
>> even if it does not hold a core of that collection. because of that, I
>> thought that adding a new node to the cluster (aka, the frontend/gateway
>> server), and creating a dummy collection (with 1 dummy core), will solve
>> the problem.
>> But, I see that a request which sent to the gateway node, is not then sent
>> to the shards. Instead, the request is proxyed to a (random) core of the
>> requested collection, and from there it is sent to the shards. (It is
>> reasonable, because the SolrCore on the gateway might run with different
>> configuration, etc). This means that my new node isn't functioning as a
>> frontend (which responsible for sorting, etc.), but as a poor load
>> balancer. No performance improvement will come from this implementation.
>> So, how do you suggest to implement a frontend? On the one hand, it has to
>> run a core of the target collection, but on the other hand, we don't want
>> it to hold any shard contents.
> With SolrCloud, every node is a frontend node.  If you're running
> SolrCloud, then it doesn't make sense to try and use that concept.
> It only makes sense to create a frontend node (or core) if you are using
> traditional distributed search, where you need to include a shards
> parameter.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message