5 ms·

> MongoDB, as some of you may know, has a process-wide write lock. I've never taken time to see what MogoDB db is, but thanks to this opening sentence, now I

by DenisM 15y ago

> MongoDB, as some of you may know, has a process-wide write lock. I've never taken time to see what MogoDB db is, but thanks to this opening sentence, now I know everything I ever wanted to know about this system. Having worked for 13 years on database system design I am pretty confident that a system not designed with concurrency in mind cannot be retrofitted with any decent concurrency later. Thank you Rick for saving me the time.

cperciva 15y ago
I'm not convinced. I'm not saying that MongoDB is well designed -- I don't think it is -- but it seems to me that a process-wide write lock would be perfectly fine for a data store which is designed to cluster at a one-process-per-CPU-core level.
- DenisM 15y ago
  So one core is processing one request at a time, right? If it spends any time at all being queued up on disk IO or network traffic or anything else, that core is burning up XX watts for no good reason. A more efficient system, designed for concurrency, will have higher HW utilization and lower cost. For a sign of things to come, I invite you to take a look at how relational database vendors are fighting to squeeze single-digit percentages from their engines to beat benchmarks such as TPC-C or TPC-E. NoSQL will get there too - fight for efficiency.
  - nknight 15y ago
    > queued up on disk IO And there's where your legacy understanding fails. You're really not supposed to be doing a lot of disk IO in modern datastores in the first place. Your working set should be in RAM. > beat benchmarks If my vendor is investing time in beating benchmarks instead of solving real problems, I'm finding a new vendor.
    - eternalban 15y ago
      "solving real problems" I am not at all addressing MongoDB here to be clear -- just your comment regarding worthwhile "problems" to "solve". It is not too difficult to foresee a future where energy costs will trump all other considerations, including development time, sys ops, etc. Specially for <X>aaS efforts, energy efficiency can clearly end up being a competitive edge.
  - milkshakes 15y ago
    since you refuse to actually learn about what's going on before arguing about it, i'll just leave this here, lifted directly from 10gen's official page on concurrency[1] (nevermind the fact that this is directly addressed in TFA) mongod threads yield their lock (read or write) in two classes of situations: * yield-on-page-fault – v2.0 implements a yield-on-page-fault feature which results in much more concurrency than one would achieve with a pure reader/writer lock. For common operational cases, file system page faults are detected in advanced and handled outside of any lock, then the lock is resumed. Not all fault situations yield, but many do. This results in v2.0 having much better concurrency in practice than v1.8. * yield-on-long-operation – mongod also yields periodically on common operations that are extremely long running. The goal here is to allow interleaving so that other operations which are quick-running can execute soon. http://www.mongodb.org/display/DOCS/How+does+concurrency+work http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...
  - viraptor 15y ago
    I'm sorry, but "being queued up on disk IO" and "burning up XX watts for no good reason" are not related at all. For decades we have systems which do not do busy loops on external store access. They go into low power state if they really have nothing else to do in that time. They also use crazy "new" things like interrupts, notifications and wait queues. This article actually explains how mongodb does not wait for IO, but handles other requests in the meantime. (within the current known limitations of writer/writer locks, etc. of course - i'm not saying it's all perfect) Did you really read the post before arguing this?
old-gregg 15y ago
You sound like a "database system design" is just one specific thing that has a well-defined definition which is known to and agreed on by everyone. Ughh... fine, not arguing. But in that case MongoDB is not a "database system" then. How about I call it a tool that holds your data for you and gives it back later. This tool has certain properties that make it work (or not work) for certain applications. It is just that simple. I do not work with/for 10gen but we have been using MongoDB since version 1.5 and found it incredibly useful addition to our toolbox. It always helps to own more than one hammer.
- DenisM 15y ago
  Sure it might be useful, I just don't think it has longevity in it. In other words it will be surpassed by another system, aiming to solve the same set of problems, but designed with concurrency in mind from the start. MongoDB developers will end up spending all their efforts to retrofit concurrency, and the community of users will simply move on.
  - xxqs 15y ago
    I guess some other team will eventually spin off an alternative server engine, still keeping the API compatibility, but improving or re-designing the poor parts. Let's wait another year or two. Pity is that as an application developer, I cannot rely on Mongo as a long-term backend solution.
  - milkshakes 15y ago
    In other words it will be surpassed by another system, aiming to solve the same set of problems, but designed with concurrency in mind from the start. MongoDB developers will end up spending all their efforts to retrofit concurrency, and the community of users will simply move on. Fine, I'll bite. Your assertion that MongoDB was not designed "with concurrency in mind" is simply wrong. They have in fact put a lot of thought into it, they simply made decisions that you either do not understand, or happen to disagree with. Nobody at 10gen is arguing that a global write lock is the best idea in the world. They are acutely aware of the drawbacks. They initially implemented it that way because it significantly reduces the complexity of offering concurrency in the first place. There's a reason that a NoSQL solution with more granular locking doesn't exist yet. It's much more difficult to construct. There is an ongoing, documented, transparent effort to migrate toward more granular locking, but that is hard and takes time. In the meantime, they have been working on mitigating the drawbacks of their decision by aggressively yielding whenever possible during long running operations. Did you even read the article? Did you look at the benchmarks? The entire point of it was it's not as bad as you would think, and it's getting better.
nknight 15y ago
Why is it all the "experienced" database people I encounter remind me of flat earthers? Are you really so hung up on yourselves that you'll watch the entire industry pass you by rather than admit the traditional models might not always be the best models for every situation?
- DenisM 15y ago
  If you would kindly refrain from personal attacks, we might have a productive conversation, and hacker news might continue to be a place to have such conversations.
  - nknight 15y ago
    If there were an argument to attack, I'd gladly attack it. You didn't offer one, just snide remarks and an appeal to authority. Kindly refrain from content-free posts.
milkshakes 15y ago
without explicitly defending this decision*, i'd like to point out that mongodb was never intended to be deployed as a single node living on a single machine. it was designed with concurrency in mind, the concurrency you're looking for comes in the form of sharding and replica sets though. edit: meh, got bored, decided to defend it: http://news.ycombinator.com/item?id=3412283 http://news.ycombinator.com/item?id=3412283
rogerbinns 15y ago
There was a poxy operating system a few years ago. It only ran on one 32 bit architecture, didn't have multi-processing, had limited device support and a rather bizarre set of dev tools. Then they tidied things up a bit. But when they added multi-processing these morons just used a single big kernel lock. What a bunch of idiots. Obviously anyone using that operating system was blind and stupid and there were far better solutions. That operating system is Linux. It started out very simple and was good enough for many people and then kept evolving. Nowadays the alternatives are mainly footnotes in history. MongoDB is also simple. Its locking approach does not give wrong answers. Its users are happy. Your assertion that the locking can't evolve is bollocks because you have no clue how the database works. While your statement has many elements of truth for a relational database, it is meaningless for the current generation of schemaless/NoSQL databases. Did you know that MongoDB has auto-sharding and replication, and doesn't need locks for that either?
- DenisM 15y ago
  I would argue Linux ended up with decent concurrency because both Sun and IBM poured huge heaps of dollars into making it so with their contributions, plus huge efforts from other contributors. If someone pours same amount of effort into MongoDB they might succeed with a retrofit/rewrite as well. It's relatively rare though.
- deleted 15y ago
  [deleted]
marshray 15y ago
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.
yason 15y ago
Perhaps you should read the whole article, then? As it happens, the article itself was exactly about how they actually made MongoDB work well even with the dreary global lock because global locking for in-memory data is nearly nothing. They had no reason to get rid of the global lock, it works well enough. The author said he suspects that obtaining the lock actually takes more time than generally doing the actual database update; I don't know but it sounds about right.

by DenisM 15y ago

cperciva 15y ago

I'm not convinced. I'm not saying that MongoDB is well designed -- I don't think it is -- but it seems to me that a process-wide write lock would be perfectly fine for a data store which is designed to cluster at a one-process-per-CPU-core level.

DenisM 15y ago
So one core is processing one request at a time, right? If it spends any time at all being queued up on disk IO or network traffic or anything else, that core is burning up XX watts for no good reason. A more efficient system, designed for concurrency, will have higher HW utilization and lower cost. For a sign of things to come, I invite you to take a look at how relational database vendors are fighting to squeeze single-digit percentages from their engines to beat benchmarks such as TPC-C or TPC-E. NoSQL will get there too - fight for efficiency.
- nknight 15y ago
  > queued up on disk IO And there's where your legacy understanding fails. You're really not supposed to be doing a lot of disk IO in modern datastores in the first place. Your working set should be in RAM. > beat benchmarks If my vendor is investing time in beating benchmarks instead of solving real problems, I'm finding a new vendor.
  - eternalban 15y ago
    "solving real problems" I am not at all addressing MongoDB here to be clear -- just your comment regarding worthwhile "problems" to "solve". It is not too difficult to foresee a future where energy costs will trump all other considerations, including development time, sys ops, etc. Specially for <X>aaS efforts, energy efficiency can clearly end up being a competitive edge.
- milkshakes 15y ago
  since you refuse to actually learn about what's going on before arguing about it, i'll just leave this here, lifted directly from 10gen's official page on concurrency[1] (nevermind the fact that this is directly addressed in TFA) mongod threads yield their lock (read or write) in two classes of situations: * yield-on-page-fault – v2.0 implements a yield-on-page-fault feature which results in much more concurrency than one would achieve with a pure reader/writer lock. For common operational cases, file system page faults are detected in advanced and handled outside of any lock, then the lock is resumed. Not all fault situations yield, but many do. This results in v2.0 having much better concurrency in practice than v1.8. * yield-on-long-operation – mongod also yields periodically on common operations that are extremely long running. The goal here is to allow interleaving so that other operations which are quick-running can execute soon. http://www.mongodb.org/display/DOCS/How+does+concurrency+work http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...
- viraptor 15y ago
  I'm sorry, but "being queued up on disk IO" and "burning up XX watts for no good reason" are not related at all. For decades we have systems which do not do busy loops on external store access. They go into low power state if they really have nothing else to do in that time. They also use crazy "new" things like interrupts, notifications and wait queues. This article actually explains how mongodb does not wait for IO, but handles other requests in the meantime. (within the current known limitations of writer/writer locks, etc. of course - i'm not saying it's all perfect) Did you really read the post before arguing this?

old-gregg 15y ago

You sound like a "database system design" is just one specific thing that has a well-defined definition which is known to and agreed on by everyone. Ughh... fine, not arguing. But in that case MongoDB is not a "database system" then. How about I call it a tool that holds your data for you and gives it back later. This tool has certain properties that make it work (or not work) for certain applications. It is just that simple. I do not work with/for 10gen but we have been using MongoDB since version 1.5 and found it incredibly useful addition to our toolbox. It always helps to own more than one hammer.

DenisM 15y ago
Sure it might be useful, I just don't think it has longevity in it. In other words it will be surpassed by another system, aiming to solve the same set of problems, but designed with concurrency in mind from the start. MongoDB developers will end up spending all their efforts to retrofit concurrency, and the community of users will simply move on.
- xxqs 15y ago
  I guess some other team will eventually spin off an alternative server engine, still keeping the API compatibility, but improving or re-designing the poor parts. Let's wait another year or two. Pity is that as an application developer, I cannot rely on Mongo as a long-term backend solution.
- milkshakes 15y ago
  In other words it will be surpassed by another system, aiming to solve the same set of problems, but designed with concurrency in mind from the start. MongoDB developers will end up spending all their efforts to retrofit concurrency, and the community of users will simply move on. Fine, I'll bite. Your assertion that MongoDB was not designed "with concurrency in mind" is simply wrong. They have in fact put a lot of thought into it, they simply made decisions that you either do not understand, or happen to disagree with. Nobody at 10gen is arguing that a global write lock is the best idea in the world. They are acutely aware of the drawbacks. They initially implemented it that way because it significantly reduces the complexity of offering concurrency in the first place. There's a reason that a NoSQL solution with more granular locking doesn't exist yet. It's much more difficult to construct. There is an ongoing, documented, transparent effort to migrate toward more granular locking, but that is hard and takes time. In the meantime, they have been working on mitigating the drawbacks of their decision by aggressively yielding whenever possible during long running operations. Did you even read the article? Did you look at the benchmarks? The entire point of it was it's not as bad as you would think, and it's getting better.

nknight 15y ago

Why is it all the "experienced" database people I encounter remind me of flat earthers? Are you really so hung up on yourselves that you'll watch the entire industry pass you by rather than admit the traditional models might not always be the best models for every situation?

DenisM 15y ago
If you would kindly refrain from personal attacks, we might have a productive conversation, and hacker news might continue to be a place to have such conversations.
- nknight 15y ago
  If there were an argument to attack, I'd gladly attack it. You didn't offer one, just snide remarks and an appeal to authority. Kindly refrain from content-free posts.

milkshakes 15y ago

without explicitly defending this decision*, i'd like to point out that mongodb was never intended to be deployed as a single node living on a single machine. it was designed with concurrency in mind, the concurrency you're looking for comes in the form of sharding and replica sets though. edit: meh, got bored, decided to defend it: http://news.ycombinator.com/item?id=3412283 http://news.ycombinator.com/item?id=3412283

rogerbinns 15y ago

There was a poxy operating system a few years ago. It only ran on one 32 bit architecture, didn't have multi-processing, had limited device support and a rather bizarre set of dev tools. Then they tidied things up a bit. But when they added multi-processing these morons just used a single big kernel lock. What a bunch of idiots. Obviously anyone using that operating system was blind and stupid and there were far better solutions. That operating system is Linux. It started out very simple and was good enough for many people and then kept evolving. Nowadays the alternatives are mainly footnotes in history. MongoDB is also simple. Its locking approach does not give wrong answers. Its users are happy. Your assertion that the locking can't evolve is bollocks because you have no clue how the database works. While your statement has many elements of truth for a relational database, it is meaningless for the current generation of schemaless/NoSQL databases. Did you know that MongoDB has auto-sharding and replication, and doesn't need locks for that either?

DenisM 15y ago
I would argue Linux ended up with decent concurrency because both Sun and IBM poured huge heaps of dollars into making it so with their contributions, plus huge efforts from other contributors. If someone pours same amount of effort into MongoDB they might succeed with a retrofit/rewrite as well. It's relatively rare though.
deleted 15y ago
[deleted]

marshray 15y ago

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.

yason 15y ago

Perhaps you should read the whole article, then? As it happens, the article itself was exactly about how they actually made MongoDB work well even with the dreary global lock because global locking for in-memory data is nearly nothing. They had no reason to get rid of the global lock, it works well enough. The author said he suspects that obtaining the lock actually takes more time than generally doing the actual database update; I don't know but it sounds about right.