[SERVER-4271] Shard key (512 bytes) maximum is less than Index key (1024 bytes) maximum Created: 14/Nov/11  Updated: 06/Dec/22  Resolved: 30/Jul/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: daniel.roberts@10gen.com Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Done Votes: 4
Labels: sharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-5290 fail to insert docs with fields too l... Closed
Assigned Teams:
Sharding
Participants:

 Description   

Currently the shard key maximum (512 bytes) is less than the index key maximum (1024 bytes) hence an error is thrown when you attempt to shard on an index key that is greater than 512 bytes. Consequently it may become impossible to shard on the most appropriate index key for your application if the size is above the 512 byte maximum of the shard key.

Error returned is "Shard Key must be less than 512 bytes".

Increasing the shard key maximum to 1024 bytes would solve this problem.



 Comments   
Comment by Christian Csar [ 31/Jan/13 ]

It'd be really great if this could be mentioned in any the documentation such as http://docs.mongodb.org/manual/reference/limits/ http://docs.mongodb.org/manual/faq/sharding http://docs.mongodb.org/manual/core/sharded-cluster-internals/ , or really anywhere sensible. It's quite a useful consideration to be aware of given when designing things particularly given that _id is the only option for a shard key for a collection that is being used for the output of map reduce.

Comment by Mathias Stearn [ 27/Jan/12 ]

There are some good reasons to limit the shard key size. One is that the _id of chunks is currently a stringified form of ns and shard key value. Also since the shard keys are kept in memory on every mongos (many times in some cases) it is a very good idea to pick a small key. If the natural shard key is too large, such as urls, it might make sense to use an md5/sha1 of the key rather than the key itself.

Generated at Thu Feb 08 03:05:30 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.