liveBook · Manning

Horizontal scaling

As explained in MongoDB 8.0 in Action, Third Edition

Horizontal scaling is the practice of increasing capacity by distributing workloads across additional machines or partitions.

Horizontal scaling increases database capacity by spreading data and workload across additional servers. It contrasts with vertical scaling, which adds CPU, RAM, or storage to one server. Scaling out can be more cost-effective as data grows, but a larger network of servers adds management complexity. section 9.3

MongoDB scales out through sharding: a sharded collection is partitioned across shards, each holding part of its data. MongoDB balances data and distributes load as machines are added. Its self-contained documents help because retrieving one document need not require joins across servers. section 1.2 section 9.3

Figure 1.1 MongoDB’s sharding architecture enables horizontal scaling by distributing data across multiple servers. (Image © MongoDB 2024 CC BY-NC-SA 3.0)
A diagram of a computer program

Description automatically generated

The cluster diagram shows the application reaching shards through mongos query routers, rather than choosing a server for each query itself. section 1.2

Keep these operational distinctions in mind:

  • Replication copies data to secondary members for availability and read distribution; writes still pass through the primary. Sharding partitions data, allowing writes to different shards to reach their respective primaries. Replication within each shard helps keep its data accessible after a server failure. section 9.0
  • Sharding is chosen per collection. Unsharded collections remain on a database’s primary shard; MongoDB 8.0+ provides moveCollection to move them to another shard. section 9.3
  • Atlas offers sharding as an option, but its cluster autoscaling does not add shards or convert a replica set into a sharded cluster. Do not mistake automatic tier or storage changes for horizontal scaling. section 9.0 section 10.2.3

When one server becomes the limit

If growing data exceeds a server’s RAM or strains disk I/O, upgrading that server may help only until its available configurations run out. Sharding offers another path: add servers and distribute the collection’s data and workload, while planning for the added operational complexity. section 9.3

How MongoDB 8.0 in Action, Third Edition covers it

How deep it goes
Explains sharding at collection and cluster level, including trade-offs, but provides no shard-creation commands in the supplied passages.
Examples
Uses RAM and disk capacity limits, a sharded-cluster diagram, and Atlas autoscaling behavior as concrete reference points.
What it assumes
Defines scaling up and out from basic server resources, while assuming familiarity with databases and collections.
What you can do after
Evaluate/understand when sharding addresses capacity or write bottlenecks, and why replication or Atlas tier autoscaling is not a substitute.
How it connects
Connects horizontal scaling to vertical scaling, sharding, replication, and autoscaling while distinguishing their roles.

Also explained in

Compare how 13 books explain horizontal scaling →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of MongoDB 8.0 in Action, Third Edition. The section links point to the parts of the book it draws on.