Hacker News Reader

Comment by rogerbinns | Hacker News Reader

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.

View on HN

> 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.

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.

It is not a sin of commission Mongo is accused of, but a sin of omission. MongoDB out of the box is configured to be fast-but-unsafe. Postgres and other databases out of the box are configured to be safe-even-if-slower. A benchmark which doesn't spend the time to configure both systems equivalently (i.e. most community benchmarks) will therefore show MongoDB as the faster system. The policy of not publishing/commenting on benchmarks simply allows misleading benchmarks to be created and to stand. It's a self-serving policy.

Mongo has repeatedly chosen defaults for their database which make naive benchmarks look better, at the expense of production safety. You seem to be willing to attribute that to Mongo's incompetence. Proverbs are on your side, but it sure ties in nicely with the "leave the benchmarks to the community" policy.

> database level lock

But that's not anywhere close to good enough.

> But that's not anywhere close to good enough for me

FTFY

> But that's not anywhere close to good enough for concurrent, multiuser systems with reasonable traffic.

FTFY

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.

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.

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.

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.)

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?

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).

If you are looking for a sober and no bullshit NOSQL database, consider RethinkDB. The DB is quite young but it doesn't have some obvious flaws out of the gate.

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.

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...

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.

Define "just doesn't scale"

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.

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.

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.

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.

The best is not to ever need it by using an architecture with no SPOF (even temporary). Master switch is a huge pain - there are simply too many nasty ways it can fail miserably. I'd stay away from databases needing it, if high availability is the primary concern.

OK, but that's a serious performance and functionality tradeoff.

Most modern architectures make the choice between having nodes serve as master for a subset of the data, and the increased cross-link bandwidth needs and reduced flexibility of a master-less system.

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).

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).

I think dropping reads is just as unsettling as dropping writes in production.

Also, MongoDB does let you elect a primary via setting a priority. Really, it should be a requirement because sometimes mongo nodes will switch due to a dropped packet (or this is all I can assume at least) and the arbiter just randomly picks a node when there aren't priorities.

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.

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.

Reply on news.ycombinator.com