Why should you care?

When one replica set’s RAM/disk/CPU cannot hold the working set, horizontal scale via sharding is the path — think global chat messages or IoT events.

See it live — copy this example

Open mongosh or MongoDB Compass, select database nosqlverse, then run the example. Change one field and run again.

// On a sharded cluster mongos:
sh.status()
sh.enableSharding("NoSQLVerse")
db.adminCommand({ shardCollection: "NoSQLVerse.readings", key: { deviceId: 1, ts: 1 } })
db.readings.getShardDistribution()

Run Example »

Edit the code below and click Run to see the result in Toolliyo’s live editor.

What happened?

• enableSharding turns on sharding for the DB.
• shardCollection chooses the shard key.
• getShardDistribution shows how chunks spread.
• You must connect via mongos, not a single shard primary, for these commands.

Practice next

1. Study sh.status() output on Atlas dedicated or a local sharded lab.
2. Pick a high-cardinality shard key for a practice collection.
3. Insert sample docs and check distribution.
4. Compare hashed vs ranged shard keys in docs for your workload.
5. Inspect jumbo chunks in sh.status().

Remember

Sharding partitions data across shards. mongos routes queries. Shard key choice decides success.

Global chat message store

Messages sharded by roomId grow beyond one replica set.

Outcome: Each shard holds a slice of rooms; cluster capacity scales out.