MongoDB Documentation, Release 3.0.4 Performance Distinctions between Range and Hash Based Partitioning Range based partitioning supports more efficient range queries. Given a range query on the shard key, the query router can easily determine which chunks overlap that range and route the query to only those shards that contain these chunks. However, range based partitioning can result in an uneven distribution of data, which may negate some of the benefits of sharding. For example, if the shard key is a linearly increasing field, such as time, then all requests for a given time range will map to the same chunk, and thus the same shard. In this situation, a small set of shards may receive the majority of requests and the system would not scale very well. Hash based partitioning, by contrast, ensures an even distribution of data at the expense of efficient range queries. Hashed key values results in random distribution of data across chunks and therefore shards. But random distribution makes it more likely that a range query on the shard key will not be able to target a few shards but would more likely query every shard in order to return a result. Customized Data Distribution with Tag Aware Sharding MongoDB allows administrators to direct the balancing policy using tag aware sharding . Administrators create and associate tags with ranges of the shard key, and then assign those tags to the shards. Then, the balancer migrates tagged data to the appropriate shards and ensures that the cluster always enforces the distribution of data that the tags describe. Tags are the primary mechanism to control the behavior of the balancer and the distribution of chunks in a cluster. Most commonly, tag aware sharding serves to improve the locality of data for sharded clusters that span multiple data centers. See Tag Aware Sharding (page 682) for more information. 10.1.4 Maintaining a Balanced Data Distribution The addition of new data or the addition of new servers can result in data distribution imbalances within the cluster, such as a particular shard contains significantly more chunks than another shard or a size of a chunk is significantly greater than other chunk sizes. MongoDB ensures a balanced cluster using two background process: splitting and the balancer. Splitting Splitting is a background process that keeps chunks from growing too large. When a chunk grows beyond a specified chunk size (page 688), MongoDB splits the chunk in half. Inserts and updates triggers splits. Splits are an efficient meta-data change. To create splits, MongoDB does not migrate any data or affect the shards. Balancing The balancer (page 684) is a background process that manages chunk migrations. The balancer can run from any of the query routers in a cluster. When the distribution of a sharded collection in a cluster is uneven, the balancer process migrates chunks from the shard that has the largest number of chunks to the shard with the least number of chunks until the collection balances. For example: if collection users has 100 chunks on shard 1 and 50 chunks on shard 2 , the balancer will migrate chunks from shard 1 to shard 2 until the collection achieves balance. The shards manage chunk migrations as a background operation between an origin shard and a destination shard . During a chunk migration, the destination shard is sent all the current documents in the chunk from the origin shard . 10.1. Sharding Introduction 665