MongoDB Lock problem

I. Database-level locks

MongoDB's lock mechanism and general relational database such as MySQL (InnoDB), Oracle is very different, InnoDB and Oracle can provide row-level granularity lock, and MongoDB 2.x can only provide library-level granularity lock , which means when MongoD B when a write lock is in use, other read and write operations are done.

MongoDB uses the "Readers-writer" lock, which can support concurrency but has great limitations, when a read lock exists, many read operations can use this lock, however, when a write lock exists, a single write operation will exclusively hold the lock, while the other reads, The write operation cannot be used to share this lock; for example, if there are 10 documents in a collection, multiple update operations cannot be concurrent on this set, even if the different documents are updated.

At first glance, library-level locks have serious problems in large concurrency, but MongoDB can still maintain large concurrency and high performance, because MongoDB's lock granularity is very extensive, but the lock processing mechanism and relational database lock are very different, mainly manifested in:

MongoDB does not have full transaction support, Operation Atomicity only to a single document level, so the operation is usually small granularity;
The actual elapsed time of MongoDB lock is memory data calculation and change time, usually quickly;
MongoDB Lock has a temporary waiver mechanism, when the need to wait for slow IO read and write data, can be temporarily discarded, and so on after the completion of IO and then regain the lock

in MongoDB 3.0, the granularity of the lock becomes finer, except for global locks, database locks, and lock mechanisms for the Wiredtiger storage engine and MMAPV1 storage engine.
Wiredtiger: For most read and write operations, Wiredtiger uses optimistic locking. Wiredtiger only use intent locks for global, database, and collection levels. When the storage engine detects a conflict between two operations, a write conflict causes MongoDB to transparently retry the write operation. Some global operations, like version 2.2, still require a global lock, for example, if you delete a collection, you still need a mutually exclusive database lock.

How to view the status of a lock

Db.serverstatus ()
Db.currentop ()
Mongotop
Mongostat

Operations that generate database locks

Operation Lock Type
Issue a query Read lock
Get more data from a cursor Read lock
Insert Data Write Lock
Remove Data Write Lock
Update Data Write Lock
Map-reduce Read Lock and write lock, unless operations is specified as non-atomic. Portions of Map-reduce jobs can run concurrently.
Create an index Building a index in the foreground, which are the default, locks the database for extended periods of time .

Db.eval () Write lock.

Two. Atomic operations but does not support transactions

The so-called atomic operation is either all successful for this document operation, or all failed, no query to the document is not saved in full condition
MongoDB does not support transactions, so be aware of this when applying to your project. No matter what the design, don't ask MongoDB to guarantee the integrity of the data. However, MongoDB provides a number of atomic operations for the operation of a single document, such as saving a document, modifying (including modifying multiple fields on a single document), deleting, and so on, all atomic operations.

MongoDB Lock problem