4 ms·

Why everyone hates MongoDB

32 points by gjmveloso 14y ago

lucian1900 14y ago
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.
- corresation 14y ago
  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.
  - TylerE 14y ago
    Because MySQL is owned by Oracle.
- lttlrck 14y ago
  'The one thing it's particularly well suited at is indexing and searching JSON-like data.' OMG! What a surprise! The fact that I read the documentation and through testing discovered its a perfect fit for our application means I am not one of the 'everybody' that hates it.
- eknkc 14y ago
  It's easy to jump in, and able to provide decent environment for developers. I believe that's similar to early MySQL, you know with only MyISAM tables, where there was no transaction support or referential integrity and your data was open to all kinds of corruption issues. It was easy to use, was installed almost everywhere and there were great tools around it. It has grown to be a pretty decent RDBMS. Mongo has the same traction behind it, so it should become a great solution in no time. (Given a decent development process it is. See PHP for a counter example)
  - lucian1900 14y ago
    But why wait, when you can use Postgres now?
    - eknkc 14y ago
      I'm not saying that I would not use Postgres now. Actually, I've been running a website on MongoDB for over a year now. I don't remember the reason behind it but it haven't caused any problems so far. The web server handles more than a million page views per day and all data is stored on MongoDB. I'm not perfectly happy with it but it does what it's supposed to. With some gimmicks here and there. If I started from scratch today, I'd probably go with PostgreSQL. Not because MongoDB is "bad" but because it's data model itself causes some problems. For example, if you query some range on an index with upper and lower bounds (like age > 18 && age < 50) it can not use both bounds on the index. That's been driving me crazy on some queries and I had to use hacky indexes. It's not a bug though, it's the query syntax and data model causing these kind of behaviour. There have been similar examples during this last year but not something that would cause "hate" agains it. On the plus side, it makes prototyping stuff so pleasantly easy that you can not have that on PostgreSQL.
      - lucian1900 14y ago
        I consider it a design flaw that queries can only use one index. In fact, many queries can never use any index (I had to write a query optimiser because mongo doesn't bother). Actually some queries do use more than one index (top-level $or), but it's actually more annoying than useful. I find especially during prototyping having a clear data model is great. SQLAlchemy + Postgres, then later on Alembic for migrations is so much more pleasant, predictable and performant.
  - deleted 14y ago
    [deleted]
- nateabele 14y ago
  You have clearly never attempted to use Cassandra in a production (or likely any) capacity. Just sayin'.
  - lucian1900 14y ago
    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.
  - StavrosK 14y ago
    What's wrong with it?
- jasonmccay 14y ago
  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.
  - lucian1900 14y ago
    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.
    - jasonmccay 14y ago
      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.
      - lucian1900 14y ago
        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.
programminggeek 14y ago
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 14y ago
  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 14y ago
    Then that's obviously a problem with the people touting MongoDB. It's not an inherent fault in the actual software itself...
    - corresation 14y ago
      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.
kylemaxwell 14y ago
"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.
jcastro 14y ago
There's no content in that article other than a link to a google search for "why mongodb is bad".
- ddrmaxgt37 14y ago
  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.
Luyt 14y ago
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/ http://www.mongodb-is-web-scale.com/
- ninetax 14y ago
  That was pretty funny. Thanks.
- drivebyacct2 14y ago
  That turned narcissistic and annoyingly stupid halfway through. And I'm not talking about the obvious stupidity in it.
Millennium 14y ago
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 14y ago
  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.
overgard 14y ago
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 14y ago
  I heard its going to be bundled with the next Flash IDE and support Actionscript for querying.
ahallock 14y ago
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/ https://education.10gen.com/ and http://www.10gen.com/presentations http://www.10gen.com/presentations for example.
- gjmveloso 14y ago
  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 ;)
mediocregopher 14y ago
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.
outside1234 14y ago
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 14y ago
  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/ http://docs.mongodb.org/manual/tutorial/expire-data/
ianstallings 14y ago
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.
freework 14y ago
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.
davidw 14y ago
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.
foobar1988 14y ago
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/ http://blog.serverdensity.com/does-everyone-hate-mongodb/

32 points by gjmveloso 14y ago

lucian1900 14y ago

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.

corresation 14y ago
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.
- TylerE 14y ago
  Because MySQL is owned by Oracle.
lttlrck 14y ago
'The one thing it's particularly well suited at is indexing and searching JSON-like data.' OMG! What a surprise! The fact that I read the documentation and through testing discovered its a perfect fit for our application means I am not one of the 'everybody' that hates it.
eknkc 14y ago
It's easy to jump in, and able to provide decent environment for developers. I believe that's similar to early MySQL, you know with only MyISAM tables, where there was no transaction support or referential integrity and your data was open to all kinds of corruption issues. It was easy to use, was installed almost everywhere and there were great tools around it. It has grown to be a pretty decent RDBMS. Mongo has the same traction behind it, so it should become a great solution in no time. (Given a decent development process it is. See PHP for a counter example)
- lucian1900 14y ago
  But why wait, when you can use Postgres now?
  - eknkc 14y ago
    I'm not saying that I would not use Postgres now. Actually, I've been running a website on MongoDB for over a year now. I don't remember the reason behind it but it haven't caused any problems so far. The web server handles more than a million page views per day and all data is stored on MongoDB. I'm not perfectly happy with it but it does what it's supposed to. With some gimmicks here and there. If I started from scratch today, I'd probably go with PostgreSQL. Not because MongoDB is "bad" but because it's data model itself causes some problems. For example, if you query some range on an index with upper and lower bounds (like age > 18 && age < 50) it can not use both bounds on the index. That's been driving me crazy on some queries and I had to use hacky indexes. It's not a bug though, it's the query syntax and data model causing these kind of behaviour. There have been similar examples during this last year but not something that would cause "hate" agains it. On the plus side, it makes prototyping stuff so pleasantly easy that you can not have that on PostgreSQL.
    - lucian1900 14y ago
      I consider it a design flaw that queries can only use one index. In fact, many queries can never use any index (I had to write a query optimiser because mongo doesn't bother). Actually some queries do use more than one index (top-level $or), but it's actually more annoying than useful. I find especially during prototyping having a clear data model is great. SQLAlchemy + Postgres, then later on Alembic for migrations is so much more pleasant, predictable and performant.
- deleted 14y ago
  [deleted]
nateabele 14y ago
You have clearly never attempted to use Cassandra in a production (or likely any) capacity. Just sayin'.
- lucian1900 14y ago
  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.
- StavrosK 14y ago
  What's wrong with it?
jasonmccay 14y ago
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.
- lucian1900 14y ago
  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.
  - jasonmccay 14y ago
    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.
    - lucian1900 14y ago
      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.

programminggeek 14y ago

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 14y ago
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 14y ago
  Then that's obviously a problem with the people touting MongoDB. It's not an inherent fault in the actual software itself...
  - corresation 14y ago
    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.

kylemaxwell 14y ago

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

jcastro 14y ago

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

ddrmaxgt37 14y ago
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.

Luyt 14y ago

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/ http://www.mongodb-is-web-scale.com/

ninetax 14y ago
That was pretty funny. Thanks.
drivebyacct2 14y ago
That turned narcissistic and annoyingly stupid halfway through. And I'm not talking about the obvious stupidity in it.

Millennium 14y ago

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 14y ago
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.

overgard 14y ago

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 14y ago
I heard its going to be bundled with the next Flash IDE and support Actionscript for querying.

ahallock 14y ago

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/ https://education.10gen.com/ and http://www.10gen.com/presentations http://www.10gen.com/presentations for example.

gjmveloso 14y ago
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 ;)

mediocregopher 14y ago

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.

outside1234 14y ago

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 14y ago
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/ http://docs.mongodb.org/manual/tutorial/expire-data/

ianstallings 14y ago

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.

freework 14y ago

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.

davidw 14y ago

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.

foobar1988 14y ago

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/ http://blog.serverdensity.com/does-everyone-hate-mongodb/