MongoDB Sharding: Step by Step Tutorial with Example

What is Sharding in MongoDB?

Sharding is a concept in MongoDB, which splits large data sets into small data sets across multiple MongoDB instances.

Sometimes the data within MongoDB will be so huge that queries against such big data sets can cause a lot of CPU utilization on the server. To tackle this situation, MongoDB has a concept of Sharding, which is basically the splitting of data sets across multiple MongoDB instances.

The collection, which could be large in size, is actually split across multiple collections, or Shards as they are called. Logically, all the shards work as one collection.

Advantages of Sharding in MongoDB

Before implementing a sharded cluster, it helps to understand why teams adopt sharding. The main benefits are:

• Horizontal scalability: Data is distributed across many commodity servers instead of forcing a single machine to grow ever larger.
• Higher throughput: Read and write operations run in parallel across shards, so the cluster handles more requests per second.
• Greater storage capacity: The combined disk of all shards can hold data sets far larger than one server could store.
• High availability: When each shard is deployed as a replica set, the failure of a single node does not take the cluster down.
• Balanced load: The MongoDB balancer redistributes data chunks automatically to prevent any one shard from becoming a hotspot.

Together, these advantages make sharding the standard approach for scaling MongoDB beyond the limits of a single server.

How to Implement Sharding

Shards are implemented by using clusters, which are nothing but a group of MongoDB instances.

The components of a Shard include:

1. A Shard – This is the basic thing, and this is nothing but a MongoDB instance which holds the subset of the data. In production environments, all shards need to be part of replica sets.
2. Config server – This is a MongoDB instance which holds metadata about the cluster, basically information about the various MongoDB instances which will hold the shard data.
3. A Router – This is a MongoDB instance which is basically responsible for re-directing the commands sent by the client to the right servers.

Step by Step Sharding Cluster Example

Step 1) Create a separate database for the config server.

mkdir /data/configdb

Step 2) Start the MongoDB instance in configuration mode. Suppose we have a server named Server D, which would be our configuration server. We would need to run the below command to configure the server as a configuration server.

mongod --configdb ServerD:27019

Step 3) Start the mongos instance by specifying the configuration server.

mongos --configdb ServerD:27019

Step 4) From the mongo shell, connect to the mongos instance.

mongo --host ServerD --port 27017

Step 5) If you have Server A and Server B which need to be added to the cluster, issue the below commands.

sh.addShard("ServerA:27017")
sh.addShard("ServerB:27017")

Step 6) Enable sharding for the database. So if we need to shard the Employeedb database, issue the below command.

sh.enableSharding("Employeedb")

Step 7) Enable sharding for the collection. So if we need to shard the Employee collection, issue the below command.

sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })

How to Choose a Shard Key in MongoDB

The shard key is the indexed field, or set of fields, that MongoDB uses to decide which shard stores each document. Because the key drives data distribution, choosing it well is the single most important decision in a sharded deployment. A poor key concentrates data and traffic on one shard, undoing the benefits of sharding.

A strong shard key generally has the following characteristics:

• High cardinality: The field should have many possible values so data can be split into many fine-grained chunks.
• Low frequency: No single value should dominate, otherwise the documents sharing that value pile onto one shard.
• Non-monotonic change: Keys that always increase, such as timestamps, send every new write to the same shard, creating a hotspot.

MongoDB supports two sharding strategies based on the key. Ranged sharding divides data into contiguous ranges and suits range queries, while hashed sharding applies a hash function to spread writes evenly across shards. Teams often start with hashed sharding when writes are heavy and switch to ranged sharding when range-based reads dominate. Whichever strategy you pick, test the key against realistic query patterns before committing, because the shard key cannot be changed easily once data is loaded.

Sharding vs Replication in MongoDB

Sharding and replication are complementary but distinct features. The table below highlights the differences so you can apply each one correctly, and in practice production clusters use both together.

In short, sharding answers the need for scale, while replication answers the need for availability, and a robust deployment combines both.

FAQs