Demystifying MongoDB Consistency


consistency
MongoDB Consistency Scenarios

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.

Demystifying MongoDB Consistency

Advertisements

Demystifying MongoDB


Overview

Databases are at the heart of almost all internet and enterprise applications.  The demand for scale speed and fast application development has brought on a new breed of databases broadly termed NoSQL databases. mongoDB is one of the most popular and fast growing databases. Developers want a database that is easy to use. Relational databases save data in tables and rows. A typical application hardly ever does (by that I mean a typical application object is rarely related to a single table).  This misalignment of application layer objects to tables and rows is called an Impedance Mismatch.

Demystifying MongoDB