6 ms·

There are also people using MongoDB and finding it meets their needs well, and don't feel the need to keep writing about how everything sucks or is wonderful.

There are also people using MongoDB and finding it meets their needs well, and don't feel the need to keep writing about how everything sucks or is wonderful. (I'm one of them.) None of how MongoDB works is a secret. And just like everything else it has sweet spots and problem areas. And like many others, development continues and it gets better. The database does not get the job done - it is a tool to help get the job done.

orthecreedence 13y ago
> 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
calinet6 13y ago
It's important to make the inner workings of our tools visible and understandable, so that we can make the right decisions about them. In this case, this article does nothing but elucidate the truth, quite plainly and clearly, in fact. That's important, in and of itself. How you use it is up to you, but we must not vilify truth.
invisible 13y ago
Mongos (the routing for MongoDB when clustering) has a bunch of drawbacks that make MongoDB worse. One of which is dropping all connections when a master switches. Have you dealt with those problems yet? MongoDB is generally perfect at small scale is what I have perceived. The new database level lock in 2.2 is also annoying (and arbitrary) but it is better than the global lock.
- ak217 13y ago
  I'm curious, how do other DBMSs handle a master switch/other cluster updates? I'm familiar enough with mongos to know how it works but not what e.g. redis or postgres or mysql does.
  - gaius 13y ago
    Oracle restarts your query, where it was interrupted, on another node. The feature is called TAF, transparent application failover. A client might notice a brief pause, but probably not even that.
  - rsynnott 13y ago
    Most master-slave databases don't do auto-promotion themselves; it's a bit of a minefield. (In particular, in cases of network partition, where some applications servers may have a different view to others on whether the master is dead or not).
    - ak217 13y ago
      OK, but that's a different concern. If a database admin manually switches a master (called a primary in Mongo), then someone is responsible for deciding what to do with queries that are in flight. In Mongo, the driver drops them, which is less than optimal. It certainly is a hard problem for writes, but not so for reads. To your point, I think deployments on modern architectures generally want the ability to scale out and tolerate network partitions, which makes the ability to drop and re-elect masters, reconcile a node that rejoins after a partition, manage shards, avoid hosing remaining nodes, etc. critical. Inability to do so really hurts on a platform like AWS (or in any multi-datacenter deployment, really).
weddpros 13y ago
Most people here seem to complain that their champion lost a benchmark, or that Mongodb does not follow their ideology. I've used Mongodb for the last 18 months, never lost any data, and it made it obvious that "enough durability" is sometimes... enough. When I switched to MongoDB from MySQL, performance rose 10+ times and I switched from "don't hit the db too much" to "give it more work, 'cause it's idle". I know it's an ideology problem: otherwise, I can't see why people would complain about a tool they don't use.

orthecreedence 13y ago

> 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

calinet6 13y ago

It's important to make the inner workings of our tools visible and understandable, so that we can make the right decisions about them. In this case, this article does nothing but elucidate the truth, quite plainly and clearly, in fact. That's important, in and of itself. How you use it is up to you, but we must not vilify truth.

invisible 13y ago

Mongos (the routing for MongoDB when clustering) has a bunch of drawbacks that make MongoDB worse. One of which is dropping all connections when a master switches. Have you dealt with those problems yet? MongoDB is generally perfect at small scale is what I have perceived. The new database level lock in 2.2 is also annoying (and arbitrary) but it is better than the global lock.

ak217 13y ago
I'm curious, how do other DBMSs handle a master switch/other cluster updates? I'm familiar enough with mongos to know how it works but not what e.g. redis or postgres or mysql does.
- gaius 13y ago
  Oracle restarts your query, where it was interrupted, on another node. The feature is called TAF, transparent application failover. A client might notice a brief pause, but probably not even that.
- rsynnott 13y ago
  Most master-slave databases don't do auto-promotion themselves; it's a bit of a minefield. (In particular, in cases of network partition, where some applications servers may have a different view to others on whether the master is dead or not).
  - ak217 13y ago
    OK, but that's a different concern. If a database admin manually switches a master (called a primary in Mongo), then someone is responsible for deciding what to do with queries that are in flight. In Mongo, the driver drops them, which is less than optimal. It certainly is a hard problem for writes, but not so for reads. To your point, I think deployments on modern architectures generally want the ability to scale out and tolerate network partitions, which makes the ability to drop and re-elect masters, reconcile a node that rejoins after a partition, manage shards, avoid hosing remaining nodes, etc. critical. Inability to do so really hurts on a platform like AWS (or in any multi-datacenter deployment, really).

weddpros 13y ago

Most people here seem to complain that their champion lost a benchmark, or that Mongodb does not follow their ideology. I've used Mongodb for the last 18 months, never lost any data, and it made it obvious that "enough durability" is sometimes... enough. When I switched to MongoDB from MySQL, performance rose 10+ times and I switched from "don't hit the db too much" to "give it more work, 'cause it's idle". I know it's an ideology problem: otherwise, I can't see why people would complain about a tool they don't use.