So let’s start this by taking into an account an organization where you build a robust application it can be either web application or mobile application which in these days it’s very popular and your concurrent connection get higher each day as your application get famous which increase the users here you face challenge to scale your database and the bad part is you are using a relation database the biggest issue on scaling and performance in the relation database are locking that means when a user using certain table and rows the database lock that particular section until the user release that section either by cancelling the query or wait until it get the output.
So to tackle this issue in relation database we need to de-normalize the database in order for us to scale it to which ever size we want as the locking happens only to single table not all tables but then there is down side by doing this which is we lose all the relationship between tables by de-normalizing the database.
So the question is how NoSQL databases tackle these issues I have put together couple of points that clearly list all the key points that differentiate normal relation database vs. NoSQL database.
Yes you hear it right no Scheme in NoSQL database particular MongoDB there is no Scheme and certainly there is no relationships between tables, no columns, no rows.
Single document write scope:
What is really means is a document lives in a collection and updating document happens one at time, so if any locking needed to occur it would be simpler no needed to lock all collection it would be single at a time as there is no relationship to enforce furthermore there is no scheme to protect as in normal database when you needed to update a table you need to lock both tables in scheme which slow down the process.
In replication scenario specifically in MongoDB you have the freedom to choose your replication consistency, Mango does not let you to put lock across several server a replica set consist of single server which will accept all right and several secondary server which will be replicated too but there are no locks extended from primary to secondary, so if your application send a request to Mango your application can wait for primary to respond or it can wait for Marjory of the server to respond or it can even wait for secondary to confirm or it can even handle the document to the primary and don’t even care about it so it’s all related to your application what it really want to do .
What is really means is that in Mango each Cape collection have fixed size and you don’t need to write size of files or control size of files each time you want you can use Cape collection which in that case every file have its own fixed size.