MongoDB Sharding: 6 Easy Steps Tutorial

Do you wish to understand what MongoDB Sharding is how it works, and how you can implement it for your MongoDB Server? If yes, then you’ve come to the right place. Although a lot of businesses still use Relational Databases, the volume of data being collected by large enterprises is too high to be stored in Relational Databases due to their inability to scale horizontally.

Hence, these large enterprises have started relying more on NoSQL Databases for their data storage requirements. MongoDB is able to keep up with the demands of data growth through a process called Sharding. Let’s get started learning about MongoDB Sharding.

What is MongoDB Sharding?

The main purpose of using a NoSQL Database for most organizations is the ability to deal with the storage and computing demands of storing and querying high volumes of data. MongoDB Sharding can be seen as the way in which MongoDB deals with high volumes of data.

It can be seen as the process in which large datasets are split into smaller datasets that are stored across multiple MongoDB Instances. This is done because querying on large datasets could lead to high CPU utilization on the MongoDB Server.

The following image shows a MongoDB Sharding example in a cluster:

Each MongoDB Database consists of a large number of Collections. Each Collection is made up of a large number of Documents that store data as Key-Value pairs. MongoDB Sharding breaks up a large Collection into smaller Collections called Shards. Splitting up large Collections into Shards allows MongoDB to execute queries without putting much load on the Server.

MongoDB Sharding can be implemented by creating a Cluster of MongoDB Instances. The following image shows how MongoDB Sharding works in a Cluster.

The three main components of Sharded Cluster are as follows:

• Shard
• Config Servers
• Query Routers

1) Shard

Shard is the most basic unit of a Shared Cluster that is used to store a subset of the large dataset that has to be divided. Shards are designed in such a way that they are capable of providing high data availability and consistency.

2) Config Servers

Config Servers are supposed to store the metadata of the MongoDB Sharded Cluster. This metadata consists of information about what subset of data is stored in which Shard. This information can be used to direct user queries accordingly. Each Sharded Cluster is supposed to have exactly 3 Config Servers.

3) Query Routers

Query Routers can be seen as Mongo Instances that form an interface to the client applications. The Query Routers are responsible for forwarding user queries to the right Shard.

What are the Benefits of MongoDB Sharding?

MongoDB Sharding is important because of the following reasons:

• In a setup in which MongoDB Sharding has not been implemented, the Master nodes handle the potentially large number of write operations whereas the Slave Nodes are responsible for read operations and maintaining backups. Since MongoDB Sharding utilizes Replica Sets, queries are distributed equally among all nodes.
• The storage capacity of the Sharded Cluster can be increased without performing any complex hardware restructuring by adding additional Shards to the Cluster.
• If one or more Shards in the Cluster go down, other Shards will continue to operate, which means that the data stored in those active Shards can be accessed without any issues.

Sharding Strategies in MongoDB

Understanding the principles of how to do sharding in MongoDB is essential for optimizing performance in large-scale deployments. Implementing sharding in MongoDB involves partitioning data into smaller chunks for efficient storage and retrieval. MongoDB provides support for two sharding strategies within sharded clusters:

Hashed Sharding 

Hashed sharding is a technique used in MongoDB to distribute data evenly across multiple servers or clusters. It works by computing the shard key field’s hash value and assigning each calculated hash value to a specific chunk or range. 

This helps achieve a more balanced data distribution, especially in cases where the shard key changes monotonically. However, it also means that range-based queries on the shard key are less efficient as they are likely to broadcast across the entire cluster. 

MongoDB automatically computes these hashes when resolving queries using hashed indexes, so applications don’t have to worry about computing them. For more information on Hashed Sharding, check out the MongoDB documentation.

Ranged Sharding

One of the another type of mongodb sharding examples is ranged sharding. Ranged sharding is a technique used to divide data into smaller chunks or ranges based on their shard key values. These ranges are then assigned to different database nodes or chunks. Doing so makes locating and performing targeted operations on the required data easier. 

However, the effectiveness of ranged sharding depends on the shard key selection. If not chosen appropriately, it can lead to uneven data distribution, adversely affecting the advantages of sharding or causing performance issues. Therefore, it is essential to consider the shard key selection for range-based sharding. You can check out MongoDB Documentation for more information. 

When to enable MongoDB sharding

Sharding is a way of distributing data across multiple MongoDB instances. It can improve the performance, scalability, and availability of your database. Here are some reasons to consider sharding:

• Disaster recovery: If your database is larger than 200GB, restoring it from a backup might take too long. Sharding can reduce the restore time by splitting the data into smaller chunks.
• Hardware limitations: If your disk or memory cannot handle the workload of your application, sharding can increase the available resources by spreading the load among different machines.
• Storage engine limitations: If your storage engine has concurrency or locking issues, sharding can reduce the contention by isolating the operations on different collections or documents.
• Hot data vs. cold data: If you have data that is frequently accessed and data that is rarely used, sharding can help you optimize the storage and performance of each type of data. You can use cheaper or slower hardware for the cold data and more expensive or faster hardware for the hot data.
• Geo-distributed data: If you have data that needs to be stored in specific regions for legal or design reasons, sharding can help you comply with the requirements and improve the latency for the users.

What are the Steps to Set up MongoDB Sharding?

Let’s look into the MongoDB sharding step by step process:

• Step 1: Creating a Directory for Config Server
• Step 2: Starting MongoDB Instance in Configuration Mode
• Step 3: Starting Mongos Instance
• Step 4: Connecting to Mongos Instance
• Step 5: Adding Servers to Clusters
• Step 6: Setting up Replica sets for Shard Servers
• Step 7: Initialize mongos and add shards to cluster
• Step 8: Enabling Sharding for Database
• Step 9: Evaluate the Shard Usage

Step 1: Creating a Directory for Config Server

The first step to be performed in order to set up MongoDB Sharding would be to create a separate directory for Config Server. This can be done using the following command:

mkdir /data/configdb

Step 2: Starting MongoDB Instance in Configuration Mode

One Server has to be set up as the Configuration Server. Suppose you have a Server named “ConfServer” which would be used as the Configuration Server, the following command can be executed to perform that operation:

mongod –configdb ConfServer: 27019

Step 3: Starting Mongos Instance

Once the Configuration Server has been set up, the Mongos Instance can be started by executing the following command along with the name of your Configuration Server:

mongos –configdb ConfServer: 27019

Step 4: Connecting to Mongos Instance

A connection can be formed to the Mongos Instance by running the following command from the Mongo Shell:

mongo –host ConfServer –port 27017

Step 5: Adding Servers to Clusters

All Servers that have to be included in the Cluster can be added by the following command:

sh.addShard("SA:27017")

“SA” here has to be replaced with the name of your Server that has to be added to the Cluster. This command can be executed for all Servers that have to be added to the Cluster.

Step 6: Setting up Replica sets for Shard Servers

Convert the shard instances into replicas. To set up replica sets, run the following command.

sh.addShardToZone("shardInstance", "replicaSetName")

Step 7: Initialize mongos and add shards to cluster

Whatever shards you have created so far are running currently but not a part of the Sharded cluster. To include them into sharded cluster you will need mongos query. Follow the given command to add shards to cluster.

mongos --configdb <configdb_connection_string> 
sh.addShard("<shard1_connection_string>")
sh.addShard("<shard2_connection_string>")
# Repeat for additional shards if needed

Step 8: Enabling Sharding for Database

Once the Sharded Cluster has been set up, Sharding for the required database has to be enabled. This can be done by the following command:

sh.enableSharding(db_test)

In the above command, “db_test” has to be replaced with the name of the database that you wish to Shard. This completes the MongoDB sharding tutorial to help set up MongoDB sharding.

Step 9: Evaluate the Shard Usage

Sharding is implemented to enhance the scalability of a database system, and its effectiveness is maximized when efficiently supporting database queries. If a significant portion of your queries requires scanning every shard in the cluster for execution, the advantages of sharding may be compromised by the increased complexity of the system. This step assesses whether a query is optimized and utilizes a single shard or if it spans multiple shards to fetch results.

MongoDB uses different query strategies like- SINGLE_SHARD and SHARD_MERGE to evaluate the shard usage.This completes the MongoDB sharding tutorial.

What are the Limitations of MongoDB Sharding?

The limitations of MongoDB Sharding are as follows:

• Setting up MongoDB Sharding is a complex operation and hence, careful planning and high maintenance are required.
• There are certain MongoDB operations that cannot be executed in a Sharded Cluster. For example, geoSpace command.
• Once a Collection in MongoDB has been sharded, there is no way to un-shard it and restore the Collection in the original format.

Conclusion

This article provided you with an in-depth understanding of what MongoDB Sharding is along with the various benefits and limitations of implementing it for your dataset. It also provided you with a guide on how you can set up MongoDB Sharding for your dataset.

Most businesses today use multiple databases for their operations. To perform any useful analysis, data from all these databases first has to be integrated into a centralized location. Making an in-house solution to perform this task would require a high amount of resources. Businesses can instead use existing platforms like Hevo.

Hevo is the only real-time ELT No-code Data pipeline platform that cost-effectively automates data pipelines that are flexible to your needs.

Visit our Website to Explore Hevo

Want to take Hevo for a spin? Sign Up for a 14-day free trial and experience the feature-rich Hevo suite first hand. You can also have a look at the unbeatable Hevo pricing that will help you choose the right plan for your business needs.

Share your experience of learning about MongoDB Sharding in the comments section below!

Frequently Asked Questions