MongoDB V3 & amp; V2 lock performance comparison test and lock basic overview, mongodbv3

MongoDB V3 & V2 lock performance comparison test and lock basic overview, mongodbv3
1. mongo lock Overview:

Features of each version lock:

The current Production Version is 2.6.7 [Production Release (2.6.7)] and the Development Version is 3.0.0-rc7 [Development Releases (unstable) 3.0.0] Version <2.2: only process-level locks are supported, one Mongod instance and one lock. 2.8> Version> = 2.2: database-level locks are supported. One database is used as a lock. Currently, 3.0.0 supports collection-level locks.

Ps: Mysql innoDB and Oracle Support row locks. The maximum version of the project Production Release is 2.6.7, which only supports database-level locks. When a MongoDB is in the write State, other operations are required. Although mongo has a database lock, it can maintain high performance because it has made concessions or optimizations in the following aspects:

(1) Mongo does not support complete transactions. Atomic operations are only at the document level, with a small granularity. <Br> (2) the actual usage time of the Mongo lock is the memory data computing and change time, usually very fast. <Br> (3) the Mongo lock has a temporary discard mechanism. When you need to wait for a slow IO to read and write data, you can temporarily discard the lock and obtain the lock again after IO is completed. <Br>

The current version 2.8 has reduced the lock granularity to the collection basics. The official website says:

The most important feature of MongoDB 2.8 should be the support for WiredTiger to support document-level locks. When I used MongoDB in the past, I encountered a lack of document-level locks. Each write operation must wait for a feedback from the write operation. The entire database-Level Lock brings a great delay to the write operation. It is exciting to bring stable lock features this time.

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

2. database lock optimization policy (usage ):

(1) Indexing becomes a background operation:
When there is a large amount of data to be indexed, if the data is built on the front end, a write lock (optimization policy: Do not temporarily discard) will be created. If the data volume of the set is large, creating an index usually takes a long time. Optimization means to switch the index creation action to the background.

Example: foreground index: db. trends. ensureIndex ({user_id: 1}) background index: db. trends. ensureIndex ({user_id: 1}, {background: 1 })

(2) Lock performance test:
A. Performance Comparison of two different sets of concurrent writes to the same DB by mongo 2.6 and mongo 3.0 (mainly testing the support of collection locks by ikev3.0 ):
Scenario: To test the performance improvement of collection-level locks in collections V3.0, two write threads for the same database but different collections are enabled on our daily machine, the qps analysis result is as follows:

Result Analysis: Version 2.6.4 is a db-Level Lock. There will be lock competition for two different sets in the same database, while version 3.0.0 is a collection-Level Lock, therefore, from the theoretical and test results, the performance has indeed improved.

B. Changing the read/write throughput of v2.6.4 with the lock conflict:
Scenario: I tested it on my own development machine and opened 10 concurrent read/write threads. The horizontal coordinates represent: lock ratio (Lock wait time/read/write Transaction completion time)

Result Analysis: The results show that the overall throughput decreases as the lock wait rate increases.

C. Conduct v2.6.4 test the performance comparison of DB front-end indexes, back-end indexes, and non-indexed indexes:
Scenario: MongoDB is divided into front-end index, back-end index, and no-index. The front-end index is in serious conflict with read/write transactions, and the back-end index is optimized, when the background index takes a long time, the lock will be applied to read/write transactions. If no index is added, the read transaction takes a long time and the write transaction takes a short time. As follows:

Result Analysis: The qps of read transactions is very low without indexing. It can be understood that reading data takes a long time without indexing, and write transactions always seize the write lock, this causes read transactions to wait.

3. Impact of the lock on the replica and sharding modes:

(1) sharding mode: In terms of read/write locks, each Mongod instance is independent of other instances. Operations on one Mongod will not block operations on other mongod instances.
(2) replica mode: When writing to the Primary node, it also writes data to the Primary's OpLog. At this time, you need to lock two databases, one is the database where the collection is currently written, and the other is the local database where OpLog is located. That is, the Primary will add a write lock to the two databases. In addition, the Secondary node synchronizes the OpLog of the Primary node and concurrently executes the Oplog on its own node in sequence. This is a write operation. during the execution of the write operation, secondary does not provide read operations.