Consistency

In a master/slave setup, the slave always stays up to date with the master. Scaling of read operations occurs with the use of setSlaveOk, causing the client library to distribute the reads automatically to the closest replica slave (on the basis of ping latency). In production, this will depend on a number of factors, including network latency and query throughput, which means MongoDB eventually becomes consistent, although the slaves might differ occasionally from the master.

To mitigate this problem, use write concern (Table 1) as part of the driver options when issuing writes. This value defaults to 1, which means the call will not return until the write has been acknowledged by the server.

For real replication and consistency, you can require acknowledgment by n slaves. At this point, the data has been replicated and is consistent across the cluster. The write concern can be a simple integer, the keyword majority, or a self-defined tag.

Each step up the consistency ladder has an effect on performance [11] because of the additional time required to verify and replicate the write.

Be advised that an acknowledgment is not the same as a successful write – it simply acknowledges that the server accepted the write job. The next step is to require a successful write to the local journal. All writes hit the MongoDB journal before being flushed to the data files on disk, so once in the journal, the write is pretty much safe on that single node.

In this way, different levels of reliability are ensured. A high-throughput logging application would be able to tolerate losing a few write operations because of network issues, but user-defined alert configurations, for example, would need a higher level of reliability.

Tag Flexibility

To make your setup even more flexible, tags can remove replica set consistency from your code. Instead of specifying a number in the client call, you can define tags and then change them at the database level.

For example, in Listing 1, I have defined a replica set with two nodes in New York, two nodes in San Francisco, and one node in the cloud. I have also defined two different write modes: veryImportant, which ensures data is written to a node in all three data centers, and sortOfImportant, which writes to nodes in two data centers.

On the basis of this configuration, the following statements:

db.foo.insert({x:1})
db.runCommand({getLastError : 1, w : "veryImportant"})

write to one node in New York, one node in San Francisco, and one node in the cloud.

Sharding

Even with a fast network, plenty of RAM, and SSDs [11], you will eventually hit the limits of a single node within a replica set. At this point, you need to scale horizontally, which means sharding.

Sharding in MongoDB takes place without the need to modify your application. Instead of connecting directly to the database, you point your clients to a router process called mongos, which knows how the data is distributed across shards by storing metadata in three config servers.

Sharding sits on top of replica sets, so you have multiple nodes within a replica set, all containing copies of the same data. Each shard consists of one replica set, and data is distributed evenly among the shards.

MongoDB moves chunks of data around to ensure balance is maintained, but it's up to the admin to decide the basis on which those chunks are moved. This is known as your shard key and should allow you to split the data while avoiding hotspots. For example, if your shard key is a timestamp, data is split chronologically across the shards. This becomes a problem if you access data that's all in the same shard (e.g., today's date). Instead, a better key is something more random and not dictated by use patterns. The MongoDB documentation provides a more detailed look at this [12].

Sharding lets you add new shards to the cluster transparently, and data then moves to them. As your data grows, you simply add more shards. This method works if you maintain good operational practices, such as adding new shards before reaching capacity (because moving lots of documents can be quite an intensive operation). For example, if you increase the number of shards from two to three, 33% of your data will be moved to the new shard.