What Is Database Sharding?

Database sharding involves breaking down records typically stored in a single table or collection and dispersing them across numerous machines, referred to as shards. Sharding is particularly advantageous when dealing with substantial data volumes since it facilitates horizontal scalability by incorporating additional devices to serve as new shards.



Understanding MongoDB’s Sharding Topology

You'll find many collections in a MongoDB database comprising numerous documents structured as key-value pairs. You can partition these extensive collections into smaller, more manageable ones by employing MongoDB sharding. This partitioning empowers MongoDB to execute queries without imposing an excessive load on the server.

When dealing with a standalone MongoDB database server, you directly connect to that instance to manage your data. In an unsharded replica set, you connect to the primary member of the cluster, and any modifications you make to the data are automatically replicated to the secondary members of the set. However, MongoDB clusters configured with sharding introduce a bit more complexity.

Sharding is designed to aid in horizontal scaling, commonly called "scaling out," as it divides records from a single dataset across multiple machines. If the workload overwhelms the shards within your cluster, you can expand your database by adding independent shards to share some of the processing load. This stands in contrast to vertical scaling, also known as "scaling up," which involves migrating resources to larger or more powerful hardware.

To mitigate these potential issues, MongoDB sharded clusters are composed of three distinct components:

1. Shard Servers: These are individual MongoDB instances that store a portion of a larger data collection. Each shard server must continuously operate as a replica set. While a minimum of one shard is required in a sharded cluster, you should have at least two to fully leverage sharding benefits.

2. Config Server: This MongoDB instance stores the sharded cluster's crucial metadata and configuration settings. The cluster relies on this metadata for its setup and management functions. Like shard servers, the config server must be deployed as a replica set to ensure the high availability of this essential metadata.

3. Mongos: This is a specialized MongoDB instance serving as a query router. Mongos is an intermediary between client applications and the sharded cluster, deciding how to route specific queries. In a sharded cluster, every application connection is directed through a query router, effectively abstracting the configuration complexity from the application layer.


Benefits of MongoDB Sharding

Storage Capacity: Sharding spreads data across the shards within the cluster. This distribution ensures that each shard holds a portion of the overall cluster data. Adding extra shards enhances the cluster's storage capacity as your dataset expands.

Read/Write: In a sharded cluster, MongoDB distributes the read and write workload across shards, enabling each shard to handle a portion of the cluster's operations. By introducing additional shards, you can scale both the read and write workloads across the cluster horizontally.

High Availability: Deploying shards and config servers as replica sets enhances availability. With this setup, even in cases where one or more shard replica sets experience complete unavailability, the sharded cluster can still perform partial read and write operations.

Geo-Distribution and Performance: Replicated shards have the flexibility to be located in various regions. Consequently, customers can enjoy low-latency access to their data by directing consumer requests to the shard that is geographically closer to them. Depending on the data governance policy within a region, it's possible to configure specific shards in a particular geographic area.


How To Set Up MongoDB Sharding

Step 1: Setting Up a MongoDB Config Server

To establish a directory for the config server data, execute the subsequent command on the first server:

• mkdir /data/configdb

Step 2: Start MongoDB in Config Mode

Initiate MongoDB in configuration mode on the initial server by executing the provided command.

• MongoDB --configsvr --dbpath /data/configdb --port 27019

Step - 3: Start Mongos Instance

To route queries to the appropriate shards based on the sharding key, you can commence the Mongos instance by employing the subsequent command:

• mongos --configdb <config server>:27019

Step 4: Connect To Mongos Instance

After the Mongo instance is operational, we can connect it using the MongoDB shell.

• mongo --host <mongos-server> --port 27017

Replace "<mongos-server>" with the hostname or IP address of the server where the Mongos instance is operating. This action will initiate the MongoDB shell, enabling us to engage with the Mongo instance and incorporate servers into the cluster.

Step 5: Add Servers To Clusters

• sh.addShard("<shard-server>:27017")

Replace "<shard-server>" with the hostname or IP address of the server hosting the shard. This command will integrate the shard into the cluster and render it accessible for utilization.

Step 6: Enable Sharding for Database

sh.enableSharding("<database>")

Substitute "<database>" with the name you intend to shard. This action will activate sharding for the designated database, enabling you to distribute its data across multiple shards.