At what level does MongoDB block writing? (or: what does it mean “for connection”,

Question

The mongodb documentation says:

Starting with version 2.2, MongoDB implements locks for each database for most read and write operations. Some global operations, usually short-term operations with multiple databases, still require global "instance" locking. Prior to 2.2, there is only one “global” lock per instance of mongod.

Does this mean that in a situation where I have, say, 3 connections to mongodb: // localhost / test from different applications running on the network - only one can write at a time? Or is it just for the connection?

IOW: Is this for the connection or is the entire / test database locked during recording?

Answer 1

This is not for connection, this is for mongod . In other words, a lock will exist in all connections to the test database on this server.

It is also a read / write lock, so if a write occurs, then the read must wait, otherwise how can MongoDB know that this is a consistent read?

However, I must mention that MongoDB locks are very different from the SQL / regular transactional locks you receive, and usually the lock will be held in about microseconds between average updates.

Answer 2

MongoDB lock is different

Locking in MongoDB does not work, like locking in a DBMS, so a little explanation is in order. In earlier versions of MongoDB, there was one global reader / writer latch. Starting with MongoDB 2.2, there is a reader / writer latch for each database.

Reader / writer latch

A latch is a device with multiple readers, a single writer, and a greedy writer. It means that:

• The database can have an unlimited number of simultaneous readers.
• Each instance can contain only one creator in any database (a little more about this)
• Writers Block Readers
• By "writer-greedy" I mean that after entering a write request, all readers are blocked until the recording is complete (more on this later)

Please note that I call this a “latch”, not a “lock”. This is due to the fact that it is lightweight, and in a correctly designed circuit, record lock is stored on the order of ten microseconds. See here for more details on read-write lock.

In MongoDB, you can run as many simultaneous requests as you want: as long as the corresponding data is in RAM, all of them will be satisfied without blocking conflicts.

Atomic Document Update

Recall that in MongoDB, the transaction level is one document. All updates for one document - Atomic. MongoDB achieves this by holding the write latch only as long as updating one document in RAM is required. If slow work is performed (in particular, if a document or index record needs to be loaded from disk), then this operation will give a write latch. When the operation gives a latch, the next operation in the queue may continue.

This means that records in all documents in one database become serialized. This can be a problem if you have a bad circuit design and your records are time consuming, but in a properly designed circuit, locking is not a problem.

Writer-Greedy

A few more words about being a greedy writer:

Only one writer can hold the latch at a time; multiple readers can hold the latch at a time. In a naive implementation, authors can starve endlessly if only one reader works in the work. To avoid this, in a MongoDB implementation, as soon as any one thread makes a write request for a specific latch

• All subsequent readers who need this latch will lock
• This writer will wait for the completion of all current readers.
• The writer will acquire the recording latch, perform its work, and then release the recording latch
• Now all the queues in the queue are reading

Actual behavior is complex because this writer's greedy behavior interacts with the assignment in ways that may not be obvious. Recall that starting from version 2.2 there is a separate latch for each database, therefore writing to any collection in database "A" will receive a separate latch than writing to any collection in database "B".

Concrete questions

Regarding specific issues:

• Locks (actually latches) are stored by the MongoDB core only as long as updating a single document is required.
• If you have multiple connections to MongoDB, and each of them performs a series of records, the latch will be stored on the basis of each database only until it is required to complete this record
• All connections made during recording (update / insert / delete) will alternate

Although it sounds like it will be a big performance issue, in practice it does not slow down. With a properly designed circuit and typical workload, MongoDB will saturate disk I / O — even for SSDs — before the block percentage on any database exceeds 50%.

The greatest potential of the MongoDB cluster that I know of is currently doing 2 million records per second.

Answer 3

Mongo 3.0 now supports collection level locking.

In addition to this, Mongo has now created an API that allows you to create a storage engine. Mongo 3.0 comes with 2 storage engines:

• MMAPv1 : The default storage engine and the one used in previous versions. Comes with a collection level lock.
• WiredTiger : A new storage engine, comes with document-level locking and compression. (Available for 64-bit only)

MongoDB 3.0 Release Notes

Wiredtiger

Answer 4

I know the question is pretty old, but still some people are confused ....

Starting with MongoDB 3.0, the WiredTiger storage engine (which uses the document level concurrency ) is available in 64-bit builds.

WiredTiger uses a document-level concurrency control for write operations. As a result, multiple clients can simultaneously modify different collection documents.

For most read and write operations, WiredTiger uses an optimistic concurrency control. WiredTiger uses only intent locks at the global, database, and collection levels. When the storage engine encounters conflicts between two operations, a write conflict occurs that causes MongoDB to transparently repeat this operation.

Some global operations, usually short-term operations with multiple databases, still require a global "whole instance" lock. Some other operations, such as deleting a collection, still require exclusive database locking.

Concurrency document level