Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
experimental-dev
-
None
-
None
-
None
Description
The 0.2-dev code currently is driven from the client. We should make the sharding strategy pluggable so that someone who needs something more than a typical modulo on the docid over the shard count can do it.
From Aaron's response[1]:
"So a couple of strategies that I have been thinking about.
-Hash based where it would hash on a pre-configured field. Field would not be allowed to be null and the number of shards would be fixed. Also the shard placement provided by the user would be ignored.
-User based where the user has total control over the placement of the document by providing it during indexing. If a shard index is provided in an update and the current table does not continue that shard, then a new one would be created and added to the table.
As for now we are now somewhere in between. The number of shards are fixed and it's up to the user to provide the shard index. I think (need to look at the code) if the user provides a -1 then it randomly chooses a shard for the document. It's could be dangerous for updates. We should create a jira issue to discuss further and provide a better implementation."