I must be wrong about this. I'm considering using mongodb in my project, but I read this:
http://docs.mongodb.org/manual/faq/concurrency/#what-type-of-locking-does-mongodb-use
It says that mongodb uses a database level reader-writer lock.
MySQL InnoDB uses row-level locking. Well, doesn't it means, theoretically, mongodb is 2 levels slower than MySQL for concurrent access?
There are four different levels of locking in MongoDB.
lock file when the server starts and drops it before mongodb is stopped. Removing mongodb. lock does not affect any data it just means that MongoDB was not stopped correctly.
No, it really does not, and depending on your exact workload could be a lot faster or a little faster or slower - it all depends on the types of operations you are doing, your available physical resources, the structure of your data, as well as the needs of your application.
The following MongoDB operations lock multiple databases: db. copyDatabase() must lock the entire mongod instance at once. Journaling, which is an internal operation, locks all databases for short intervals.
If you look up readers-writer lock you will find that it is a completely different type of animal than database lock that MySQL is referring to when you use the phrase "row level locking".
Readers-writer lock protects shared memory access, and therefore is extremely short lived (on the order of microseconds). Since in MongoDB operations are only atomic on the document level, these locks (in traditional databases they are sometimes referred to as latches and are used to guard index access) are only held as long as a single document takes to update in memory.
Regular "database lock" will usually exists until the transaction that's in progress has either been committed or rolled back. Because RDBMS transactions can span multiple operations across many tables, these locks are normally much longer lived and therefore must be much more granular to allow other work to happen concurrency.
doesn't it means, theoretically, mongodb is 2 levels slower than MySQL for concurrent access?
No, it really does not, and depending on your exact workload could be a lot faster or a little faster or slower - it all depends on the types of operations you are doing, your available physical resources, the structure of your data, as well as the needs of your application.
Applications that write a lot of data to the database in MongoDB tend to be limited primarily by the available disk IO throughput rate. Only when available disk bandwidth exceeds the amount of writes done by the application to the database would you see concurrency become a factor with MongoDB. With relational databases, because of longer lifetimes of locks, concurrency can become a factor much earlier even with relatively small amount of total data being written.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With