Monday, February 17, 2014

MongoDB DB level locking

MongoDB database-level locking probably is the most cited drawback in MongoDB.  Before version 2.2, there is only one “global” lock per mongod instance. For example, you have 5 databases on one mongod instance and one takes a write lock, the other 4 are not available for read or write. Anyone coming from RDBMS background is going to be shocked by such an awful design, when all RDBMS provide row level lock granularity.

Beginning with version 2.2, MongoDB implements locks on a per-database basis for most read and write operations. Of course it is still a step in the right direction. However, it is still desired to implement write lock in a more granular level such as collection level or document level. There is a a good explanation on stackoverflow about why db level locking is NOT a big a performance concern. There are many valid points in the post and I recommend people to read it. But the author did put some spin on the issue --- it is understandable since he works for MongoDB. You can see sentence like "with a properly designed schema and a typical workload, ...". Also the author stressed that MongoDB locking works better than RDBMS because it uses lightweight latch. As a matter of fact, RDBMS like Oracle has used latch long time ago. The author did admit that "This does mean that the writes to all documents within a single database get serialized.".

Take a look at the issue at https://jira.mongodb.org/browse/SERVER-1240. There are 346 people to vote for this feature right now. It was created back in 2010 and it is still a problem today. It was originally said that the issue would be taken care in version 2.4, but it was not even planned for 2.6. Now the words are that the more granular locking will be definitely added to 2.8 release. We have to wait and see.

One hacking solution you can do at the meantime is to move your collections into a separate databases to simulate collection level locking. Still, the solution sounds clumsy. Or you can add more shards to make the write operation more scalable.


No comments: