Code Library

First and foremost, MongoDB does not always respect atomicity and does not defi ne transactional integrity or isolation levels during concurrent operations. So it’s possible for processes to step on each other’s toes while updating a collection. Only a certain class of operations, called modifier operations, offers atomic consistency.

The lack of isolation levels also sometimes leads to phantom reads. Cursors don’t automatically get refreshed if the underlying data is modifi ed.

By default, MongoDB fl ushes to disk once every minute. That’s when the data inserts and updates are recorded on disk. Any failure between two synchronizations can lead to inconsistency. You can increase the sync frequency or force a fl ush to disk but all of that comes at the expense of some performance.

MongoDB defi nes a few modifi er operations for atomic updates:
» inc — Increments the value of a given field
» set — Sets the value for a field
» unset — Deletes the field
» push — Appends value to a field
» pushAll — Appends each value in an array to a field
» addToSet — Adds value to an array if it isn’t there already
» pop — Removes the last element in an array
» pull — Removes all occurrences of values from a field
» pullAll — Removes all occurrences of each value in an array from a field
» rename — Renames a field

To avoid complete loss during a system failure, it’s advisable to set up replication. Two MongoDB instances can be set up in a master-slave arrangement to replicate and keep the data in synch. Replication is an asynchronous process so changes aren’t propagated as soon as they occur. However, it’s better to have data replicated than not have any alternative at all. In the current versions of MongoDB, replica pairs of master and slave have been replaced with replica sets, where three replicas are in a set. One of the three assumes the role of master and the other two act as slaves. Replica sets allow automatic recovery and automatic failover.

Whereas replication is viewed more as a failover and disaster recovery plan, sharding could be leveraged for horizontal scaling.

Source of Information : NoSQL