On Fri, Jan 28, 2011 at 7:55 AM, Upayavira <u...@odoko.co.uk> wrote: > > On Thu, 27 Jan 2011 16:01 +0000, "Alex Cowell" <alxc...@gmail.com> wrote: > > Making it easy for clients I think is key... one should be able to > update any node in the solr cluster and have solr take care of the > hard part about updating all relevant shards. This will most likely > involve an update processor. This approach allows all existing update > methods (including things like CSV file upload) to still work > correctly. > > Does that then imply that distributed indexing would become the default > method of indexing?
Should be possible I think. Seems nice to be able to use the exact same update command w/o worrying if it's a cluster or not. > What if a user, for some reason, wanted to only target > one specific node in a cluster? Yeah, that should always be possible too. We could either utilize different URLs, or use a parameter. > Surely it would be just the same as distributed search. If you provide a > 'shards' request parameter, your content is distributed amongst shards. If > you don't, it goes directly to the host you are posting to. Control remains > in the hand of the person accessing Solr. People sometimes set up a request handler like /search that sets shards to the correct value by default. Now with SolrCloud, one can also just use distrib=true and not worry about the shards param at all. Off the top of my head, the following make sense to me: - target cluster (solr decides what shards the docs belong on, via solr hash on id, or user supplied hash on id) - target single solr core (i.e. a single physical shard) - target logical shard (i.e. sort does not decide what shard these docs live on, but does handle the distrib update to all replicas) -Yonik http://lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
