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.
Why everyone hates MongoDB
21–30 of 53 posts
Re: Why everyone hates MongoDB
#22There'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.
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.
Re: Why everyone hates MongoDB
#23I'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.
Re: Why everyone hates MongoDB
#24I'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?
Re: Why everyone hates MongoDB
#25I'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 was pretty funny. Thanks.
Re: Why everyone hates MongoDB
#26Because 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'.
Re: Why everyone hates MongoDB
#27Because 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 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.
Re: Why everyone hates MongoDB
#28Because 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…
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.
Re: Why everyone hates MongoDB
#29Earlier 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…
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.
Re: Why everyone hates MongoDB
#30Because 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'.
Admittedly I haven't used older versions of Cassandra, or under as much load as I have Postgres or Mongo.
My point was that it is designed for being distributed and it doesn't hide that fact. Mongo's replica sets and sharding are much less transparent and much less predictable.