I’m in the process of porting my application from an App Engine Datastore to a MongoDB backend and have a question regarding the consistency of “document updates.” I understand that the updates on one document are all atomic and isolated, but is there a way to guarantee that they’re “consistent” across different replica sets?
In our application, many users can (and will) be trying to update one document at the same time by inserting a few embedded documents (objects) into it during one single update. We need to ensure these updates occur in a logically consistent manner across all replicas, i.e. when one user “puts” a few embedded documents into the parent document, no other users can put their embedded documents in the parent document until we ensure they’ve read and received the first user’s updates.
So what I mean by consistency is that we need a way to ensure that if two users attempt to perform an update on one document at exactly the same time, MongoDB only allows one of those updates to go through, and discards the other one (or at least prevents both from occuring). We can’t use a standard “sharding” solution here, because a single update consists of more than just an increment or decrement.
What’s the best way of guaranteeing the consistency of one particular document?
MongoDB does not offer master-master replication or multi-version concurrency. In other words, writes always go to the same server in a replica set. By default, even reads from secondaries are disabled so the default behavior is that you communicate only with one server at a time. Therefore, you do not need to worry about inconsistent results in safe mode if you use atomic modifiers (like
$inc, $push, etc.).If you don’t want to restrict yourself to these atomic modifiers, compare and swap as recommended by dcrosta (and the mongo docs) looks like a good idea. All this is not related to replica sets or sharding, however – it would be the same in a single-server scenario.
If you need to ensure read consistency also in case of a database/node failure, you should make sure you’re writing to the majority of servers in safe mode.
The two approaches behave different if you allow unsafe reads: the atomic update operations would still work (but may give unexpected results), while the compare-and-swap approach would fail.