6 ms·

> None of how MongoDB works is a secret. Maybe not now, but this hasn't always been the case. The fact that they had (have?) a global write lock was completely

> None of how MongoDB works is a secret. Maybe not now, but this hasn't always been the case. The fact that they had (have?) a global write lock was completely buried on the doc site for ages. Benchmarks were waved in front of developer's faces to distract them from the "drivers don't actually write data, they just blast it out in every direction and hope it lands somewhere good" BS. I don't use Mongo anymore, and I think a lot of it has not to do with the database itself, but with the way 10gen used their marketing machine in a dishonest way. They incurred a lot of trust-debt, and now have a serious amount of work to do to pay it back.

jbooth 13y ago
That's all true, but they were giving 90% of their users exactly what they wanted: "We value feature-set and expressiveness much more than scalability at our data size, but we want to feel like we're big data too so say some of that stuff" And that's their brilliance, they listened to what people said they wanted and then gave them what they really wanted.
- arohner 13y ago
  Then where did the "Mongo is web scale", and sharding and performance come from? The fact remains that Mongo just doesn't scale, and 10gen was never honest about that.
  - lttlrck 13y ago
    Define "just doesn't scale"
    - arohner 13y ago
      Global write lock. Abysmal performance when your data set doesn't fit in ram. Clustering with durability. Clustering in a way that isn't horribly complex and fragile.
- gaius 13y ago
  No, what they thought they wanted. They promised a world without DBAs, but the "DBA" is really, whoever gets called at 3am in the morning with the site goes down. If you don't know who the DBA is, it's you. They promised a world without schemas, but you always have a schema, the only question is whether you know what it is and the tools help you validate it or not. They promised massive scalability, but really just pushed scalability problems out into other layers of the stack. I could go on and on...
rogerb 13y ago
Sorry, but the global write lock has been public knowledge since the very early days. Mongo's done nothing to hide that. Also (i worked for 10gen at the time) the "marketing department" that you refer to, was a single person organizing events to give developers what they wanted: knowledge and a community around mongodb.
- rsynnott 13y ago
  I think it's really less that 10gen itself was trying to mislead people, and more that the community itself was building up a strange mythos with little relation to reality. This, unfortunately, tends to happen rather often (node.js is magic! Java is really slow! etc.)
  - digitailor 13y ago
    That's what made me drop research into NoSQL a couple of years ago- the overly optimistic and magical thinking seemed to be really pervasive. I don't want to get burned from joining in a group delusion. (I'm not trying to say that's what's going on specifically in Mongo or anything else, just acknowledging that the mythos phenomenon mentioned above can repel me.) Since you've coined the term, are there any NoSQL projects you've seen that don't suffer from the mythos issue?
    - rsynnott 13y ago
      It varies, a fair bit. MongoDB is perhaps the worst, possibly because it's easy to get up and running with, and behaves a little magically (you don't need to know how it works to use it, or at least so you might think initially). It also has a company pushing it, of course. I'd say that this is less of a problem for the Dynamo paper databases (Riak, Voldemort, Cassandra), because really to use them at all you have to have some idea of what's going on. I'm a bit biased here, though, while I've found Voldemort, Redis and Cassandra useful and can see Riak and a couple of others being useful, I could never really figure out a good reason that anyone would use MongoDB besides naiveté. That said, I've never really tried, as I don't have a problem that fits it (part of my issue is that I don't know what a problem that fits it would look like).
rit 13y ago
I worked for 10gen (now MongoDB) for over 2 years (I left in December). Never once while I was there did they publish a benchmark: There was a [publicly] stated company policy to not publish or comment on benchmarks. If you have evidence otherwise (i.e. benchmarks published by the folks working on MongoDB) fine, but I take this as a deliberately inflammatory (and false) statement. EDIT: The global write lock was removed ~last August; there is now a database level lock. Future releases will likely make that more fine grained. Additionally, the drivers no longer do "unsafe" writes, but check w/ server.. as of the same release.
- mdellabitta 13y ago
  > database level lock But that's not anywhere close to good enough.
  - lowboy 13y ago
    > But that's not anywhere close to good enough for me FTFY
    - mdellabitta 13y ago
      > But that's not anywhere close to good enough for concurrent, multiuser systems with reasonable traffic. FTFY
      - lowboy 13y ago
        Mmhmm. Like I said, that's not good enough for you and for your needs. For other people it's fine. That's important to note.
        lucian1900 13y ago
        At that point you might as well use a JSON file per database and lock the entire file, parse, change then serialise again. That might even be faster.
- 13y ago

jbooth 13y ago

That's all true, but they were giving 90% of their users exactly what they wanted: "We value feature-set and expressiveness much more than scalability at our data size, but we want to feel like we're big data too so say some of that stuff" And that's their brilliance, they listened to what people said they wanted and then gave them what they really wanted.

arohner 13y ago
Then where did the "Mongo is web scale", and sharding and performance come from? The fact remains that Mongo just doesn't scale, and 10gen was never honest about that.
- lttlrck 13y ago
  Define "just doesn't scale"
  - arohner 13y ago
    Global write lock. Abysmal performance when your data set doesn't fit in ram. Clustering with durability. Clustering in a way that isn't horribly complex and fragile.
gaius 13y ago
No, what they thought they wanted. They promised a world without DBAs, but the "DBA" is really, whoever gets called at 3am in the morning with the site goes down. If you don't know who the DBA is, it's you. They promised a world without schemas, but you always have a schema, the only question is whether you know what it is and the tools help you validate it or not. They promised massive scalability, but really just pushed scalability problems out into other layers of the stack. I could go on and on...

rogerb 13y ago

Sorry, but the global write lock has been public knowledge since the very early days. Mongo's done nothing to hide that. Also (i worked for 10gen at the time) the "marketing department" that you refer to, was a single person organizing events to give developers what they wanted: knowledge and a community around mongodb.

rsynnott 13y ago
I think it's really less that 10gen itself was trying to mislead people, and more that the community itself was building up a strange mythos with little relation to reality. This, unfortunately, tends to happen rather often (node.js is magic! Java is really slow! etc.)
- digitailor 13y ago
  That's what made me drop research into NoSQL a couple of years ago- the overly optimistic and magical thinking seemed to be really pervasive. I don't want to get burned from joining in a group delusion. (I'm not trying to say that's what's going on specifically in Mongo or anything else, just acknowledging that the mythos phenomenon mentioned above can repel me.) Since you've coined the term, are there any NoSQL projects you've seen that don't suffer from the mythos issue?
  - rsynnott 13y ago
    It varies, a fair bit. MongoDB is perhaps the worst, possibly because it's easy to get up and running with, and behaves a little magically (you don't need to know how it works to use it, or at least so you might think initially). It also has a company pushing it, of course. I'd say that this is less of a problem for the Dynamo paper databases (Riak, Voldemort, Cassandra), because really to use them at all you have to have some idea of what's going on. I'm a bit biased here, though, while I've found Voldemort, Redis and Cassandra useful and can see Riak and a couple of others being useful, I could never really figure out a good reason that anyone would use MongoDB besides naiveté. That said, I've never really tried, as I don't have a problem that fits it (part of my issue is that I don't know what a problem that fits it would look like).

rit 13y ago

I worked for 10gen (now MongoDB) for over 2 years (I left in December). Never once while I was there did they publish a benchmark: There was a [publicly] stated company policy to not publish or comment on benchmarks. If you have evidence otherwise (i.e. benchmarks published by the folks working on MongoDB) fine, but I take this as a deliberately inflammatory (and false) statement. EDIT: The global write lock was removed ~last August; there is now a database level lock. Future releases will likely make that more fine grained. Additionally, the drivers no longer do "unsafe" writes, but check w/ server.. as of the same release.

mdellabitta 13y ago
> database level lock But that's not anywhere close to good enough.
- lowboy 13y ago
  > But that's not anywhere close to good enough for me FTFY
  - mdellabitta 13y ago
    > But that's not anywhere close to good enough for concurrent, multiuser systems with reasonable traffic. FTFY
    - lowboy 13y ago
      Mmhmm. Like I said, that's not good enough for you and for your needs. For other people it's fine. That's important to note.
      - lucian1900 13y ago
        At that point you might as well use a JSON file per database and lock the entire file, parse, change then serialise again. That might even be faster.
13y ago