Sharding

Sharding is a method for distributing data across multiplemachines. MongoDB uses sharding to support deployments with very large datasets and high throughput operations.

Database systems with large data sets or high throughput applications canchallenge the capacity of a single server. For example, high query rates canexhaust the CPU capacity of the server. Working set sizes larger than thesystem’s RAM stress the I/O capacity of disk drives.

There are two methods for addressing system growth: vertical and horizontalscaling.

Vertical Scaling involves increasing the capacity of a single server, suchas using a more powerful CPU, adding more RAM, or increasing the amount ofstorage space. Limitations in available technology may restrict a singlemachine from being sufficiently powerful for a given workload. Additionally,Cloud-based providers have hard ceilings based on available hardwareconfigurations. As a result, there is a practical maximum for vertical scaling.

Horizontal Scaling involves dividing the system dataset and load overmultiple servers, adding additional servers to increase capacity as required.While the overall speed or capacity of a single machine may not be high, eachmachine handles a subset of the overall workload, potentially providing betterefficiency than a single high-speed high-capacity server. Expanding thecapacity of the deployment only requires adding additional servers as needed,which can be a lower overall cost than high-end hardware for a single machine.The trade off is increased complexity in infrastructure and maintenance forthe deployment.

MongoDB supports horizontal scaling through sharding.

Sharded Cluster

A MongoDB sharded cluster consists of the following components:

  • shard: Each shard contains asubset of the sharded data. Each shard can be deployed as a replicaset.
  • mongos: The mongos acts as aquery router, providing an interface between client applications and thesharded cluster.
  • config servers: Configservers store metadata and configuration settings for the cluster. Asof MongoDB 3.4, config servers must be deployed as a replica set (CSRS).

The following graphic describes the interaction of components within asharded cluster:

Diagram of a sample sharded cluster for production purposes. Contains exactly 3 config servers, 2 or more ``mongos`` query routers, and at least 2 shards. The shards are replica sets.

MongoDB shards data at the collection level, distributing thecollection data across the shards in the cluster.

Shard Keys

MongoDB uses the shard key to distribute the collection’sdocuments across shards. The shard key consists of a field orfields that exist in every document in the target collection.

You choose the shard key when sharding a collection. The choice of shard keycannot be changed after sharding. A sharded collection can have only _one_shard key. See Shard Key Specification.

To shard a non-empty collection, the collection must have an indexthat starts with the shard key. For empty collections, MongoDB creates theindex if the collection does not already have an appropriate index for thespecified shard key. See Shard Key Indexes.

The choice of shard key affects the performance, efficiency, and scalabilityof a sharded cluster. A cluster with the best possible hardware andinfrastructure can be bottlenecked by the choice of shard key. The choice ofshard key and its backing index can also affect the sharding strategy that your cluster can use.

See the shard keydocumentation for more information.

Chunks

MongoDB partitions sharded data into chunks. Eachchunk has an inclusive lower and exclusive upper range based on theshard key.

Balancer and Even Chunk Distribution

In an attempt to achieve an even distribution of chunks across allshards in the cluster, a balancer runs in the background tomigrate chunks across the shards .

See Data Partitioning with Chunks for more information.

Advantages of Sharding

Reads / Writes

MongoDB distributes the read and write workload across theshards in the sharded cluster, allowing each shard toprocess a subset of cluster operations. Both read and write workloads can bescaled horizontally across the cluster by adding more shards.

For queries that include the shard key or the prefix of a compound shard key, mongos can target the query at aspecific shard or set of shards. These targetedoperations are generally more efficient thanbroadcasting to every shard in the cluster.

Storage Capacity

Sharding distributes data across the shards in thecluster, allowing each shard to contain a subset of the total cluster data. Asthe data set grows, additional shards increase the storage capacity of thecluster.

High Availability

A sharded cluster can continue to perform partial read / writeoperations even if one or more shards are unavailable. While the subset ofdata on the unavailable shards cannot be accessed during the downtime, readsor writes directed at the available shards can still succeed.

Starting in MongoDB 3.2, you can deploy config servers as replica sets. A sharded cluster witha Config Server Replica Set (CSRS) can continue to process reads andwrites as long as a majority of the replica set is available.

In version 3.4, MongoDB removes support for SCCC config servers.

In production environments, individual shards should be deployed asreplica sets, providing increased redundancy andavailability.

Considerations Before Sharding

Sharded cluster infrastructure requirements and complexity requirecareful planning, execution, and maintenance.

Careful consideration in choosing the shard key is necessary forensuring cluster performance and efficiency. You cannot change theshard key after sharding, nor can you unshard a sharded collection. SeeChoosing a Shard Key.

Sharding has certain operational requirements andrestrictions. SeeOperational Restrictions in Sharded Clusters for more information.

If queries do not include the shard key or the prefix of acompound shard key, mongos performsa broadcast operation, queryingall shards in the sharded cluster. These scatter/gather queries canbe long running operations.

Note

If you have an active support contract with MongoDB, consider contactingyour account representative for assistance with sharded clusterplanning and deployment.

Sharded and Non-Sharded Collections

A database can have a mixture of sharded and unsharded collections. Shardedcollections are partitioned and distributed across theshards in the cluster. Unsharded collections are stored on aprimary shard. Each database has its own primary shard.

Diagram of a primary shard. A primary shard contains non-sharded collections as well as chunks of documents from sharded collections. Shard A is the primary shard.

Connecting to a Sharded Cluster

You must connect to a mongos router to interact with any collection inthe sharded cluster. This includes sharded and unshardedcollections. Clients should never connect to a single shard in order toperform read or write operations.

Diagram of applications/drivers issuing queries to mongos for unsharded collection as well as sharded collection. Config servers not shown.

You can connect to a mongos the same way you connect to amongod, such as via the mongo shell or a MongoDBdriver.

Sharding Strategy

MongoDB supports two sharding strategies for distributing dataacross sharded clusters.

Hashed Sharding

Hashed Sharding involves computing a hash of the shard key field’svalue. Each chunk is then assigned a range based on thehashed shard key values.

Tip

MongoDB automatically computes the hashes when resolving queries usinghashed indexes. Applications do not need to compute hashes.

Diagram of the hashed based segmentation.

While a range of shard keys may be “close”, their hashed values are unlikelyto be on the same chunk. Data distribution based on hashed valuesfacilitates more even data distribution, especially in data sets where theshard key changes monotonically.

However, hashed distribution means that ranged-based queries on the shard keyare less likely to target a single shard, resulting in more cluster widebroadcast operations

See Hashed Sharding for more information.

Ranged Sharding

Ranged sharding involves dividing data into ranges based on theshard key values. Each chunk is then assigned a range based on theshard key values.

Diagram of the shard key value space segmented into smaller ranges or chunks.

A range of shard keys whose values are “close” are more likely to reside onthe same chunk. This allows for targetedoperations as a mongos can route theoperations to only the shards that contain the required data.

The efficiency of ranged sharding depends on the shard key chosen. Poorlyconsidered shard keys can result in uneven distribution of data, which cannegate some benefits of sharding or can cause performance bottlenecks. Seeshard key selection for ranged sharding.

See Ranged Sharding for more information.

Zones in Sharded Clusters

In sharded clusters, you can create zones of sharded data basedon the shard key. You can associate each zone with one or more shardsin the cluster. A shard can associate with any number of zones. In a balancedcluster, MongoDB migrates chunks covered by a zone only tothose shards associated with the zone.

Each zone covers one or more ranges of shard key values. Each range azone covers is always inclusive of its lower boundary and exclusive of itsupper boundary.

Diagram of data distribution based on zones in a sharded cluster

You must use fields contained in the shard key when defining a newrange for a zone to cover. If using a compound shardkey, the range must include the prefix of the shard key. See shard keysin zones for more information.

When choosing a shard key, carefully consider the possibility of using zonesharding in the future, as you cannot change the shard key aftersharding the collection.

Most commonly, zones serve to improve the locality of data forsharded clusters that span multiple data centers.

Tip

Starting in MongoDB 4.0.3, setting up zones and zone ranges _before_you shard an empty or a non-existing collection allows for a fastersetup of zoned sharding.

See zones for more information.

Collations in Sharding

Use the shardCollection command with the collation :{ locale : "simple" } option to shard a collection which has adefault collation. Successfulsharding requires that:

  • The collection must have an index whose prefix is the shard key
  • The index must have the collation { locale: "simple" }

When creating new collections with a collation, ensure these conditionsare met prior to sharding the collection.

Note

Queries on the sharded collection continue to use the defaultcollation configured for the collection. To use the shard keyindex’s simple collation, specify {locale : "simple"}in the query’s collation document.

See shardCollection for more information about shardingand collation.

Change Streams

Starting in MongoDB 3.6, change streams areavailable for replica sets and sharded clusters. Change streams allowapplications to access real-time data changes without the complexityand risk of tailing the oplog. Applications can use change streams tosubscribe to all data changes on a collection or collections.

Transactions

Starting in MongoDB 4.2, with the introduction of distributedtransactions, multi-document transactions areavailable on sharded clusters.

Until a transaction commits, the data changes made in thetransaction are not visible outside the transaction.

However, when a transaction writes to multiple shards, not alloutside read operations need to wait for the result of the committedtransaction to be visible across the shards. For example, if atransaction is committed and write 1 is visible on shard A but write2 is not yet visible on shard B, an outside read at read concern"local" can read the results of write 1 withoutseeing write 2.

For details, see: