Re:MongoDB's Write Lock
by marshray on Sunday January 01, 2012 @12:04AM
(#3412618)
thanks to this opening sentence, now I know everything I ever wanted to know about this system
In other words, your analytical faculties have been intentionally shut down.
I am pretty confident that a system not designed with concurrency in mind cannot be retrofitted with any decent concurrency later.
I think you're probably right from a software engineering perspective. But you haven't actually shown that Mongo was "not designed with concurrency in mind".
I've implemented in-memory persistent storage systems with a global RW lock. Depending on the characteristics of the load it can be ridiculously fast. E.g., on the order of tens of microseconds for typical transactions.
Complex schemes like MVCC with multimaster replication are an amazing accomplishment and are great for general purpose SQL-driven databases. But it's not the only reasonable design choice in the world and it's certainly not the optimal one for every problem.
In other words, your analytical faculties have been intentionally shut down.
I am pretty confident that a system not designed with concurrency in mind cannot be retrofitted with any decent concurrency later.
I think you're probably right from a software engineering perspective. But you haven't actually shown that Mongo was "not designed with concurrency in mind".
I've implemented in-memory persistent storage systems with a global RW lock. Depending on the characteristics of the load it can be ridiculously fast. E.g., on the order of tens of microseconds for typical transactions.
Complex schemes like MVCC with multimaster replication are an amazing accomplishment and are great for general purpose SQL-driven databases. But it's not the only reasonable design choice in the world and it's certainly not the optimal one for every problem.