Demystifying MongoDB Consistency

Continuing from the previous Post

Data consistency is a big deal, so its worth taking a look at MongoDB handles consistency. In a single database scenario, if we have 2 observers A & B, and there is a document with a value X=’123′. At some point A decides to update the document with say  ‘789’ , during that update B’s observation could either be 123 or 789 if it waited for the  lock to be released.

When you scale out things become a little more involved, assume again 2 observers A & B with a primary database and a secondary database. Mongo only accepts writes into the primary database at a time. So lets say A updates the document and sets the value to 789, replication should also occur to take that value and populate it in the secondary database. Eventually the value will be replicated in the primary as well as the secondary database. But lets take a step backward, A may have updated the document, but B may not see that change yet because replication has not happened yet to the secondary database. This is what is called as Eventual Consistency. Eventually the document will make it over to the secondary database.

Mongo provides you the option to determine the durability and consistency model you desire. Its important to distinguish between durability and consistency in the context of eventual consistency.

Durability is about weather your data was persisted to durable media before control was returned to you.

Eventual consistency in a replica set is about weather a document was written to all of the servers ( Primaries and Secondaries) before control was returned back to your application.

• Complete Consistency (Consistent & Durable): If you want complete consistency before control is returned back to your application, issue an update/write command to the primary  and control is not returned to you until the update is made to all servers involved.
• Fire & Forget: You can also choose very limited durability guarantee, in a fire and forget manner. Hand over the update command to the primary and control will be returned to you immediately if it is received it in memory, but there is no guarantee that the document made it to the disk. If things went well the change will be propagated to all servers and consistency will be achieved. But there is a possibility that if the record didn’t make it to the disk, that document will be lost forever.
• Majority : You can also choose that a document will be replicated to a majority or any other number of secondaries. In this scenario the primary will be issued the update command and it will replicate to a specified number of secondary  servers after which the control will be returned back to the application. Following that the document is replicated to the remaining secondary servers. But Control has already been returned to the application.

With all of the options above there are still those what if scenarios related to consistency. For example in  a multiple server scenario there is a chance that during the replication lag A & B might communicate by other means such as messaging or different applications trying to access the data or different connection mechanisms etc. At that point A’s knowledge of the value will be inconsistent with B’s knowledge of the value. These are concerns that should be addressed based on the needs of the application. You can certainly point B to the primary, but then it defeats the purpose of scalability and performance. The whole purpose of secondaries is to provide read operations and thus relieve the primary.

Conclusion

For decades we have been used to the idea of having relational databases forcing schema or us. Having no schema and having mongo not enforcing us to have any schema can be jarring to some and it certainly shifts the responsibility of managing the data and its relationships  to the applications concerned. On the plus side applications need not worry about the document structure when it writes documents. So you can have scenarios where you can write various documents into collections and deal with the veriety of schemas later when you process those records.

For all your application development needs, visit www.verbat.com for a fiscally conscious proposal that meets your needs ( So I can keep this blog going as well!!!!)

Alternatively click through the link   if you found this article interesting. (This will help the companies Search engine rankings)