Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why everyone hates MongoDB

gustavoveloso.posterous.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Why everyone hates MongoDB

#31

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

Re: Why everyone hates MongoDB

#32

Post by TylerE »

corresation wrote: post #5
lucian1900 wrote: post #2

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…

for both single-machine (Postgres, MySQL) and distributed (Cassandra, HBase) usage. I'm surprised that MySQL Cluster Edition doesn't get more attention in the scale-out space. It is a simply brilliant product.

Because MySQL is owned by Oracle.

Re: Why everyone hates MongoDB

#33

Post by jasonmccay »

mediocregopher wrote: post #23

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

Re: Why everyone hates MongoDB

#34

Post by ddrmaxgt37 »

jcastro wrote: post #8

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

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.

Re: Why everyone hates MongoDB

#35

Post by ericcholis »

mediocregopher wrote: post #23

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…

All very constructive points, thanks for this.

On the point of slow queries, nailing a slow query is a bit of a mixed bag at the moment. I've found that Dex (http://blog.mongolab.com/2012/06/introducing-dex-the-index-b...) and NewRelic help diagnose trouble queries pretty well.

Re: Why everyone hates MongoDB

#36

Post by lucian1900 »

jasonmccay wrote: post #29
lucian1900 wrote: post #28

Earlier quoted context omitted.

I blame both the technology for being poor and the creators for claiming things it cannot really do. While all tools can be used both well and poorly, some tools are just poor themselves.

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 recommendations, it's pretty easy to get inconsistencies. Also, many useful commands don't work (or work differently) with sharding. This is the sort of thing Cassandra and HBase get right.

They used to claim you can have control over whether reads/writes happen on the master or slaves, but not all commands supported this differentiation. There's was safe and masterOnly, but they don't always apply (and amazingly enough, don't always work). This is the sort of thing Cassandra gets right, and at least newer Mongo (and clients) support more granularity, and more consistently.

They claim certain benchmark numbers, but neglect to mention they're done without durability or any router/replica/shard setup.

It's nothing overly enthusiastic creators of a new database wouldn't be expected to do, but still annoying.

Re: Why everyone hates MongoDB

#37

Post by jasonmccay »

ericcholis wrote: post #35
mediocregopher wrote: post #23

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…

All very constructive points, thanks for this. On the point of slow queries, nailing a slow query is a bit of a mixed bag at the moment. I've found that Dex ( http://blog.mongolab.com/2012/06/introducing-dex-the-index-b... ) and NewRelic help diagnose trouble queries pretty well.

You can also use the MongoDB Profiler to get a historical view of the performance of your queries and can easily separate out results based on scanned documents and query time.

http://docs.mongodb.org/manual/tutorial/manage-the-database-...

Re: Why everyone hates MongoDB

#38

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

Re: Why everyone hates MongoDB

#40

Post by cpleppert »

jasonmccay wrote: post #27
lucian1900 wrote: post #2

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

Post reply on HN