lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Garski (JIRA)" <>
Subject [jira] [Commented] (SOLR-2592) Pluggable shard lookup mechanism for SolrCloud
Date Thu, 13 Sep 2012 18:08:11 GMT


Michael Garski commented on SOLR-2592:

Thanks for the additional patch James.

It looks like the difference in approach between your patch and the one I've submitted is
that rather than hashing on a value to determine the destination shard for an update, the
shard name is added as a field on a document to explicitly name the destination shard. Is
that accurate?

It is possible to combine our two approaches, however for explicitly naming the destination
shard for an update perhaps adding optional properties to the AddUpdateCommand would be a
better approach than to use a field in a document. The same could be done for a DeleteUpdateCommand
to direct deletes to a specific shard(s) if desired. This would make index modification requests
similar to a query where the names of the shards to be queried are present in the shards parameter
as described on the wiki. The realtime get component would have to honor the shards parameter
if present on a request as well, as without a way to determine shard membership from the unique
id all requests to the realtime get component will have to be forwarded to all of the shards
in the collection.

Thoughts, anyone?
> Pluggable shard lookup mechanism for SolrCloud
> ----------------------------------------------
>                 Key: SOLR-2592
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: SolrCloud
>    Affects Versions: 4.0-ALPHA
>            Reporter: Noble Paul
>            Assignee: Mark Miller
>         Attachments: dbq_fix.patch, pluggable_sharding.patch, pluggable_sharding_V2.patch,
SOLR-2592.patch, SOLR-2592_r1373086.patch, SOLR-2592_rev_2.patch, SOLR_2592_solr_4_0_0_BETA_ShardPartitioner.patch
> If the data in a cloud can be partitioned on some criteria (say range, hash, attribute
value etc) It will be easy to narrow down the search to a smaller subset of shards and in
effect can achieve more efficient search.  

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message