MongoDB V3 & V2 Version lock performance Comparison test and basic overview of Locks

1.mongo Lock Overview:

Features of each version lock:

当前版本 生产版本最高是 2.6.7[Production Release (2.6.7)]  开发版本是 3.0.0-rc7[Development Releases (unstable)3.0.0] Version < 2.2 : 只支持进程级锁，一个Mongod实例一个锁。2.8 >Version >= 2.2 : 支持库级锁，一个db一把锁。目前3.0.0 支持 collection 级别的锁。

Ps:mysql's InnoDB and Oracle support row locks. The highest version of production release is 2.6.7, which supports only library-level locks, and when a MongoDB is in the write state, other operations are done. Although MONGO has a library lock, it can still maintain high performance because it compromises or is called optimization at the following levels:

（1）Mongo没有完整的事物支持，原子操作仅仅到document级别，粒度比较小。<br>（2）Mongo锁实际的占用时间是内存数据计算和变更时间，通常很快。<br>（3）Mongo锁有一种临时放弃机制，当出现需要等待慢速IO读写数据时，可以先临时放弃，等IO完成之后重新获取锁。<br>

The current version of the 2.8 has reduced the granularity of the lock to collection basic, the official website says:

MongoDB 2.8版本的最重要的特性应该就是对WiredTiger的支持，从而实现对文档级锁的支持。在过去使用MongoDB时，自己就遇到了缺少文档级锁的问题。每次进行写入操作时，必须等待写操作的一个反馈，整个数据库级别的锁给写入操作带来了很大的延迟。这次能带来稳定级别的锁特性，真是令人兴奋。

Official lock-related introduction: http://docs.mongodb.org/manual/faq/concurrency/

2. Optimization Strategy for Library Lock (usage):

(1) The construction of the index becomes a background operation:
When there is a large scale of data that needs to be indexed, it is often time-consuming to build an index if the building in the foreground creates a write lock (optimization policy: does not give up temporarily), and if the collection has a large amount of data. Optimization means that the indexed action will have the foreground switch to the background.

example:    前台索引：db.trends.ensureIndex({user_id:1})    后台索引：db.trends.ensureIndex({user_id:1},{background:1})

(2) Performance test of the Lock:
A. MONGO 2.6 and MONGO 3.0 performance comparisons for 2 different sets of concurrent writes to the same db (main test mongoV3.0 support for collection Locks):
Scenario: In order to test the performance of mongoV3.0 for collection level locks, on our daily machine, two write threads for the same DB but different collection are opened, each of which has been written for 20, the results of the QPS analysis are as follows:

Results analysis: The mongo2.6.4 version is a DB level lock, there will be a lock competition for two different sets in the same library, and mongo3.0.0 is a collection level lock, so the performance of the theory and test results is actually improved.

B. MongoV2.6.4 as the lock conflict changes, its read-Write throughput trends:
Scenario: This was tested on my own development machine, with 10 concurrent read and write threads tested, and the horizontal axis represented: The ratio of locks (time of lock wait/read/write Transaction completion)

Results: The results show that the overall throughput decreases with the increase of lock waiting ratio.

C. MongoV2.6.4 test the performance comparison of the DB in the foreground index, background index, and non-indexed conditions:
Scenario: MongoDB is divided into foreground index, background index, and non-indexed, foreground index and read-write transaction have serious conflict, the latter index is optimized, when the background index takes a long time, will give up lock to read and write transaction. Non-indexed read transactions take a long time and write transactions take less time. As follows:

Results analysis: In the case of non-indexed read transaction QPS is very low, it can be understood that the read data in the absence of index time is longer, and the write transaction has been preempted by the write lock, causing the read transaction hunger wait.

3. Effects of lock on Copy mode (replica) and sharding mode:

(1) sharding mode: In terms of Read and write locks, each Mongod instance is independent of other instances. Operations on one Mongod do not block the operation of other Mongod instances.
(2) Replica mode: In the Primary node to write operations, but also to Primary's Oplog write, at this time need to lock 2 libraries, one is the current write collection The library, and the other is the local library Oplog. That is, primary will add a write lock on both libraries. In addition, the secondary node will synchronize the oplog of the primary node, and the oplog sequence will be executed on its own node, which is a write operation, and secondary cannot provide read operation during the execution of the write operation.

MongoDB V3 & V2 Version lock performance Comparison test and basic overview of Locks