
Why everyone hates MongoDB - gjmveloso
http://gustavoveloso.posterous.com/why-everyone-hates-mongodb
======
lucian1900
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 impossible to use without a model/schema in the
app. Migrations are a pain.

The one thing it's particularly well suited at is indexing and searching JSON-
like data.

~~~
jasonmccay
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 it?

To say that there are better alternatives implies that you understand
everyone's use case. It is faulty logic. One of the reasons for the revolt
that was "NoSQL" was an attempt to get people to stop shoe-horning data into
MySQL ... so the concept of developers using database engines poorly isn't
new. Same with MongoDB and developers that use it based on their experiences
with MySQL or other relational (or non-relational) models.

I have seen people use MongoDB to great (even amazing) success and have seen
others use it very poorly. In both cases, it was the developer (and not the
technology) that was responsible for the way they used the technology.

~~~
cpleppert
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 although I have never
scaled it up in production the amount of moving pieces and the clear lack of
attention paid to distributed programming literature in the design doesn't
inspire a lot of confidence.

Technical problems with MongoDB are being explained away as features in the
same way MySQL did. Why does Mongo MMAP its datafiles?? So the cache stays
warm!!! Why doesn't MySQL have transactions? No one needs transactions, just
lock the table !!

If you didn't consider these cases you might think that Mongo sounded pretty
good. I don't fault 10gen for pushing this hard and taking advantage of the
perception that NoSQL is a more modern technology. I just can't believe there
isn't something better that does what Mongo does.

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

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

------
Luyt
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. ...."_

Read the entire conversation at <http://www.mongodb-is-web-scale.com/>

~~~
ninetax
That was pretty funny. Thanks.

------
ianstallings
The plain answer is it's painful using newer technologies. If you use node.js
and mongoDB be prepared for working without a net and stumbling across errors
that no one has encountered before as it comes to fruition. Be prepared for
putting a question out to the community and hearing nothing back. But honestly
I've seen the same thing with almost every technology at the beginning of it's
life span. If you are a pioneer recognize it and plan accordingly.

And if you just chose it willy-nilly because it's a hot tech, well.. You made
a mistake.

PS - linking to a couple paragraph blog with come conjecture and a link to a
google search? That deserves a bitch slap. Try harder.

------
jcastro
There's no content in that article other than a link to a google search for
"why mongodb is bad".

~~~
ddrmaxgt37
I'm not sure what the intent of the article is.

However, we can see that it has again sparked the age old flame war. It
reminds me of the online flamewars that start once someone voices their
opinion on some hot topic like mac vs pc, ios vs android, etc.

------
programminggeek
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 into production if possible. That way I can write an app and have
it working without worrying too much about queries, caching, and so on until I
need to actually put it out on a real server.

MySQL, Mongo, HBase, Cassandra, Postgres, Riak, Redis, Memcache, Couchbase,
Filesystem? It doesn't matter.

They're all going to break at different times for different reasons depending
on how you use them and what scale you are at. Everything breaks at scale
eventually.

Build something awesome enough that it breaks under the user load. That's a
good problem to have.

~~~
corresation
_It's cool to hate MongoDB_

When a product is pushed as essentially a silver-bullet -- often by people who
have never and will never actually build anything with it -- it is naturally
going to get a lot of backlash by people who see through the problems, and
moreso by those who _buy_ the hype and then smash into the reality halfway
through their projects.

I speak from personal experience on the first point, while the second has come
from countless real-world case studies. A couple of years back I had several
widely distributed pieces declared "trolls" because I essentially called for a
sobering reset on the NoSQL hype train. Every single thing I said has been
well proven out since, so there's that.

~~~
drivebyacct2
Then that's obviously a problem with the people touting MongoDB. It's not an
inherent fault in the actual software itself...

~~~
corresation
Absolutely and unequivocally true! And the truth is that the actual makers
have always been quite reasonable in their claims. But from an industry
perspective it is hard to separate the two, much like Visual Basic got most of
its bad rap from the _people who used Visual Basic_ than from the platform
itself.

------
freework
The reason why I dislike MongoDB is because it exist in between that key+value
store and ful blown database. They market is as the best of both worlds, but
it ends up being the wost of each world. Its like all those car+bike,
car+boat, car+plane, boat+plane, boat+bike combinations that have been
marketed over the years.

If I had a bunch of keys and values, I'd put it in memcache. If I had
relational data, I'd put it in postgres. I don't see where mongo fits into
play. Every time I've seen it used in production, it always seems like its
being used as an improperly implemented RDBMS or an improperly implemented
key+value store.

------
mediocregopher
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 "arbiter" instance depending on what circumstances you're operating under.
I could do a whole rant (and have, in the past, to anyone who would listen) on
the arbiter/voting system mongo uses. We've been left in a situation in the
past where one of our secondaries randomly died (more on these lovely "random
occurences" later), leaving the cluster with a master and an arbiter left
over. Mongo decided that since there was an even number of votes (and why is
my production-critical database voting on things?!) it couldn't promote a
master (even though the master never actually died), dropped the master down
to being read-only, leaving us completely boned. They have since fixed this
issue (I think), but it definitely garnered a lot of ill-will from me, and
should never EVER have even been a problem.

"Random occurrences" have always plagued us with mongo. Whether it's been
random segfaults (less common with more recent versions, but oh dear god were
they frequent pre-2.0), secondaries being promoted to master with no clear
reason as to what sparked this (which has left us flailing twice now, when a
master decided to step down while one secondary was in RECOVERING mode and the
other was AWOL), config servers getting out of sync (one time one of the
config server sets decided it was going to start hosting the config for an
entirely different replica set, luckily no production mongos instances had to
reload the config before we noticed), mongos instances getting out of
sync/crashing (less common now than before, thankfully), and I'm sure much
more that I'm not thinking of now.

To make all of the above about 10x worse the mongo logs are terrible. There is
no distinction between INFO messages and ERROR messages in the logs, so
everything has to be treated as an error of some kind. And there are many
"errors" that we should "just ignore". This makes debugging pretty much
impossible. Another nice feature is when you restart a mongos instance (and
possibly a mongod instance too, although I could be wrong on that) all the
logs from the old process get clobbered by the new one (so backup those logs
folks!). It's extremely difficult to track down why slow queries are happening
unless you can catch them in the act, and even then it's not trivial.

Mongo has many great qualities. It's one of the few (if the only, that I know
of) that can do many of the things that it does, and for that it's very
useful. But for it to have been marketed as a production-ready database was a
bit disingenuous I think. It scales OK. Not well, just OK. You can make it
scale if you try real hard and tiptoe around it so you don't wake it up and
make it cry. I think someday in the future all of these issues will be fixed,
but at the moment I don't recommend anyone use mongo for anything they plan on
a significant number (200k+ users at any given moment) of users being
dependent on.

~~~
jasonmccay
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 processes, the logs are appended and keep going.

On the issues with primary/secondary and state changes, do you host your
databases on Amazon? We have often found that when we have this issue, it was
pinpointed back to some temporary intra-zone networking glitch with AWS ...
either with their name resolution or a blip in one zone being unable to see
another zone in the window of time that MongoDB has set for the response.

These often (if not all the time) go unreported by AWS until you get them to
dig a bit and report back. We effectively utilize priority to keep the member
we want as primary and if a state change does occur, it moves back once the
full set is healthy again.

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

------
overgard
I wonder if the ease of use of MongoDB might be part of why this "hating on
mongo" trend exists -- it's very easy to setup and use without having to think
through exactly what the best way to use it is. Which means it's very easy to
do something dumb without realizing you're doing something dumb. The problem
is, most of these database anti-patterns aren't visible at a small-scale, they
only become obvious once the datasets get large and then it's really hard to
change things.

Pretty much any database is going to leak abstractions at some point, there's
absolutely no way of getting around understanding how your DB works. I think
the problem with Mongo is that it's so developer friendly initially, that it
makes it easy to avoid a lot of hard decisions that will eventually have to be
made, and when those decisions do come to the forefront, it's often at a much
less convenient juncture in the application's lifecycle to change things.

~~~
lincolnbryant
I heard its going to be bundled with the next Flash IDE and support
Actionscript for querying.

------
outside1234
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 summarized output of the ground truth
in our MySQL DB that is expensive to compute, has a varying JSON schema, and
we want have ready at our fingertips for the frontend.

It seems like MongoDB is well suited for these use cases, leaving our
transactional and user data in MySQL.

Am I crazy? Should I be considering one of the alternatives instead?

~~~
mpobrien
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/>

------
ahallock
I'm not going to argue about the technology itself, but 10gen does provide
excellent documentation, screencasts, and tutorials. Other DB vendors could
learn a thing or two about writing better documentation and educational
materials. Look at <https://education.10gen.com/> and
<http://www.10gen.com/presentations> for example.

~~~
gjmveloso
Great point! 10gen is growing really really fast (and receiving a lot of
funding to sustain that). The newly-released Education channel is great.

And I really didn't understand other people complaining about 10gen marketing
capabilities ;)

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

------
kylemaxwell
"Everyone" may be a bit of hyperbole. I have some particular use cases where
it works really well, and others where I wouldn't dream of deploying it. Using
any technology "because it's cool" without understanding the implications only
works for experimental stuff where that's the whole point.

------
foobar1988
It's clear that the easiest way to get to the top of hacker news is to discuss
why you hate MongoDB <http://blog.serverdensity.com/does-everyone-hate-
mongodb/>

------
Millennium
There's an old saying, "If all you have is a hammer, everything else looks
like a nail." People hate MongoDB because its makers (and, to a lesser extent,
userbase) actively market it as the hammer.

~~~
byoung2
The problem is not that MongoDB is marketed as a hammer, the problem is that
the use case most users have is a screw. I think it is a perception problem
among developers who have run into problems scaling apps based on relational
databases (read: the screwdriver) that they can just drop in MongoDB and scale
away. The problem is that MongoDB isn't a better screwdriver, it is a hammer.
If you can rework your app to take advantage of a different database structure
(read: nails), then MongoDB could be the right tool to use.

