MongoDB Documentation, Release 3.0.4 This setting prevents the mongos from causing connection spikes on the individual shards . Spikes like these may disrupt the operation and memory allocation of the sharded cluster . If the query does not include the shard key , the mongos must send the query to all shards as a “scatter/gather” operation. Each shard will, in turn, use either the shard key index or another more efficient index to fulfill the query. If the query includes multiple sub-expressions that reference the fields indexed by the shard key and the secondary index, the mongos can route the queries to a specific shard and the shard will use the index that will allow it to fulfill most efficiently. See this presentation 22 for more information. Shard keys can be random. Random keys ensure optimal distribution of data across the cluster. Sharded clusters , attempt to route queries to specific shards when queries include the shard key as a parameter, because these directed queries are more efficient. In many cases, random keys can make it difficult to direct queries to specific shards. Yes. There is no requirement that documents be evenly distributed by the shard key. However, documents that have the same shard key must reside in the same chunk and therefore on the same server. If your sharded data set has too many documents with the exact same shard key you will not be able to distribute those documents across your sharded cluster. You can use any field for the shard key. The _id field is a common shard key. Be aware that ObjectId() values, which are the default value of the _id field, increment as a timestamp. As a result, when used as a shard key, all new documents inserted into the collection will initially belong to the same chunk on a single shard. Although the system will eventually divide this chunk and migrate its contents to distribute data more evenly, at any moment the cluster can only direct insert operations at a single shard. This can limit the throughput of inserts. If most of your write operations are updates, this limitation should not impact your performance. However, if you have a high insert volume, this may be a limitation. To address this issue, MongoDB 2.4 provides hashed shard keys (page 674). At the end of a chunk migration (page 685), the shard must connect to the config database to update the chunk’s record in the cluster metadata. If the shard fails to connect to the config database , MongoDB reports the following error: ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING" 11.5.26 What do moveChunk commit failed errors mean? 11.5.25 Can you shard on the _id field? 11.5.24 Can shard keys have a non-uniform distribution of values? 11.5.23 Can shard keys be randomly generated? 11.5.22 How do indexes impact queries in sharded systems? $^{22}$http://www.slideshare.net/mongodb/how-queries-work-with-sharding 767 11.5. FAQ: Sharding with MongoDB