Live data from Hacker News

Why everyone hates MongoDB

gustavoveloso.posterous.com

41–50 of 53 posts

Re: Why everyone hates MongoDB

#41

I'll give the reasons why I hate it, and they have nothing to do with it not being a "good fit" for our model or abstraction problems or anything of that nature. The problem we have with it is that it's an absolute pain to maintain in a large production. The setup alone is just bizarre, for each replica set you have to have 3 (and only 3!) config server instances associated with your set, along with possibly an "arbi…

Interesting feedback ... I agree on the log messages that look terrifying yet, when googled, are like "oh, that's normal, don't worry about that." I also agree that the 2.x versions of MongoDB have been a great step forward for stability and performance. On the logging, not sure what you mean by the old logs get clobbered. Is this, perhaps, some house-cleaning job that you have on your server? When we stop/start proc…

>On the logging, not sure what you mean by the old logs get clobbered.

For us the logs are not opened in append-mode, just write. We don't do any house cleaning except for logrotate, but that only runs nightly and isn't the cause of what we're seeing. Like I said, it may not be for the normal mongod instance, but it's definitely true for mongos. I'll double-check on the version number of what we're running

> do you host your databases on Amazon?

Nope, all owned servers, over a local network on a switch we own as well. The switching happens on some clusters more then others, so it's possibly a usage related thing.

Re: Why everyone hates MongoDB

#42
The thing that pissed me off about MongoDB was finding it in an environment where it had no business being because it had been heavily marketed as 'cool!' 'saves time!', 'web scale!', and so on.

Besides antirez being a friend, I think something like redis more credible due to the fact that it seems fairly clear about what it is, and what it is not.

Re: Why everyone hates MongoDB

#43
post #12

I've made a transcription of the famous 'MongoDB is web scale' video, a humorous conversation between a NoSQL fanboy and a more cautious, conventional database developer: "'And in conclusion, we have found MySQL to be an excellent database for our website. Any questions?' Yes, I have a question. Why didn't you use MongoDB? MongoDB is a web scale database, and doesn't use SQL or JOINs, so it's high-performance. ...."…

That turned narcissistic and annoyingly stupid halfway through. And I'm not talking about the obvious stupidity in it.

Re: Why everyone hates MongoDB

#44

Because it's not a particularly good database, but it's being marketed strongly. There are better (more mature, easier to maintain, faster, etc.) alternatives for both single-machine (Postgres, MySQL) and distributed (Cassandra, HBase) usage. It's a pain to take care of, it does table scans all the time (partly because it has no schema, partly because of design issues), it has pretty poor profiling tools. It's almost…

You have clearly never attempted to use Cassandra in a production (or likely any) capacity. Just sayin'.

What's wrong with it?

Re: Why everyone hates MongoDB

#45

It's cool to hate MongoDB, it used to be really cool to like MongoDB. Same thing happend with MySQL probably 10 years ago. I have built some apps with Mongo and it's fine as long as you don't expect it to be a SQL database. A lot of times I wish it had features x,y,z from sql land, and other times I wish MySQL was schemaless. Nowadays, I have begun to defer my database choice until I absolutely have to put an app int…

Where do you work? Sounds pretty chill.

I work at Firespring (http://www.firespring.com) in Lincoln, NE. It's an awesome place to work. The project I work on is LAMP for the site with some ruby api backend mixed in.

My side projects are where I have the most freedom and I just recently built and open sourced Obvious - http://obvious.retromocha.com. It makes it easy to build apps with good structure, good testing, and with pluggable front and back ends. So, if I want to switch out Mongo for MySQL or Postgres, it's basically painless.

Re: Why everyone hates MongoDB

#46

Earlier quoted context omitted.

You are making sweeping (but vague) negative characterizations of a technology while, at the same time, accusing the company that created the technology of marketing it strongly. When DHH created Rails, was it his job to tell you all the reasons why you should not use it over Java/.NET/PHP or, instead, to tell you all the reasons that he created it and the problems that he was trying to solve by developing apps with…

There is something to be said for well architected software independent of any features that one may find attractive in it. For databases this is a big problem as you often don't find out about technical problems until you are already committed to the technology and are trying to scale it. The same thing happened with MySQL and now it looks like it is happening with MongoDB as well. Mongo has so many corner cases and…

RethinkDB looks to be a better Mongo. It even does MVCC, the lack of which I certainly felt with Mongo (can't do analytics queries on your data or build indexes without DoS-ing your db).

Re: Why everyone hates MongoDB

#47

Earlier quoted context omitted.

There is something to be said for well architected software independent of any features that one may find attractive in it. For databases this is a big problem as you often don't find out about technical problems until you are already committed to the technology and are trying to scale it. The same thing happened with MySQL and now it looks like it is happening with MongoDB as well. Mongo has so many corner cases and…

RethinkDB looks to be a better Mongo. It even does MVCC, the lack of which I certainly felt with Mongo (can't do analytics queries on your data or build indexes without DoS-ing your db).

We also don't mmap the data files, though it's much more relevant to the internal architecture than user facing features :)

Re: Why everyone hates MongoDB

#48

I'll give the reasons why I hate it, and they have nothing to do with it not being a "good fit" for our model or abstraction problems or anything of that nature. The problem we have with it is that it's an absolute pain to maintain in a large production. The setup alone is just bizarre, for each replica set you have to have 3 (and only 3!) config server instances associated with your set, along with possibly an "arbi…

@mediocregopher

Re: replica sets. You don't need config servers to run replica sets. You need config servers to run a sharded cluster. Your understanding of when to run an arbiter is also flawed. I think you might find the documentation enlightening: http://docs.mongodb.org/manual/. The unfortunate situation you describe where the master was left in a read-only state is a flawed setup -- not an error in mongo.

In your second paragraph referring to "random occurrences" you're again conflating sharding and replica sets... I'm not sure what exactly you're describing, sorry :(!

IN general you should not ignore errors in logs... the mongo processes all have log rotation via signals or server commands.

I think a lot of what you're describing is hard to take at face value because of a lack of a common vocabulary -- or some misunderstanding. In my experience mongo has worked fairly well in some large scale systems. It's not the solution to everything -- I'll agree with that... but if you read the documentation it does what you would expect.

Re: Why everyone hates MongoDB

#49

Earlier quoted context omitted.

Can you offer an example of the creators claiming that it does something that it really cannot do? Also, while MongoDB does have its faults and some sharp edges, it is far from poor. For the most part, 2.x MongoDB is solid, performs well and generally without issue.

They claim the oplog ensures durability, but it actually gets written and fsynced quite late in the process. This becomes quite obvious when the master of your replicaset changes: clients will receive errors and you will get inconsistent data you have to clean up later. This is the sort of thing Postgres and even Redis get right. They claim sharding works up to a high number of nodes, but even when following their re…

AFAIK 10gen vehemently refrains from releasing benchmarks.

Re: Why everyone hates MongoDB

#50

I'm considering using MongoDB for some limited cases in our app: 1. A capped collection of responses from a 3rd party endpoint (XML) that we often want to go back up to 2 weeks and have a look at. 2. Data that is all reads after initial write: Historical data, lots of it (100-150M rows and growing fast), that we want to take advantage of the scaleout nature of MongoDB to handle. 3. "Built out data": Data that is the…

As an alternative for 1) you might consider using the TTL collections feature in mongo, which expires data after a given time threshold: http://docs.mongodb.org/manual/tutorial/expire-data/
Post reply on HN