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

Why you should never use MongoDB (2013)

sarahmei.com

Post reply on HN
Print view View original

81–90 of 188 posts

Re: Why you should never use MongoDB (2013)

#81

Post by KirinDave »

franciscop wrote: post #9

Is it a joke? > Error establishing a database connection Or is it truly an error? In a page that from the title is bashing another DB

Unfair comparisons aside, no one is "bashing" MongoDB. These criticisms have been levied for years (as the article demonstrates by its byline). These complaints have been levied not just because we should expect more reliability from corporate-backed database products, but because _they run counter to the advertising and technical literature_ that 10gen produced.

It is not "bashing" to say, "I do not like this and by the way, it's unsafe." Especially when the Mongo project has been so resistant to fixing these core issues and instead are happy to sell expensive consulting and training on workarounds for the issue rather than addressing their core technology's issues.

Re: Why you should never use MongoDB (2013)

#82

Post by honkhonkpants »

rch wrote: post #77
enraged_camel wrote: post #61

Earlier quoted context omitted.

The HN consensus seems to be that MongoDB is good only for toy projects, and that you should switch to a real database as soon as things start getting more complex.

Actually, when you have a toy project that needs a RDBMS, go ahead and use SQLite. The consensus is that relatively few applications are a good fit for MongoDB, irrespective of scale.

Or leveldb for those even more trivial storage needs.

Re: Why you should never use MongoDB (2013)

#84

Post by virmundi »

tszming wrote: post #14

> Error establishing a database connection Why you should never use database

I know there is a sense of biting irony here, but it really a valid comment for relatively static sites. Look at the Git based systems out there. If you can generate your site without a tier, generate it without a tier.

Re: Why you should never use MongoDB (2013)

#85

Post by DankCorrector »

chatmasta wrote: post #27

My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…

Why does this comment feel like an ad?

Re: Why you should never use MongoDB (2013)

#86

Post by chatmasta »

DankCorrector wrote: post #85
chatmasta wrote: post #27

My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…

Why does this comment feel like an ad?

An ad for what, Parse.com? It doesn't even exist anymore, lol.

Re: Why you should never use MongoDB (2013)

#87

Post by pmelendez »

chatmasta wrote: post #27

My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…

>"Like the author, I really cannot wrap my head around this. While I understand that duplicating documents across collections may make querying faster, what about when you want to change the document? "

That's a trade-off you have to analyze to see if it is worth it. If that data is not maintained often then is OK to have duplicated data. One thing you have to realize is that there is no a silver bullet in the CAP theorem and you always would give up something.

The other thing to realize is that not everybody needs a distributed database and most problems will live happily with an old-fashioned relational database.

Re: Why you should never use MongoDB (2013)

#88

Post by devishard »

avitzurel wrote: post #32
devishard wrote: post #24

Earlier quoted context omitted.

> I would likely not use it as a main source of truth for any application but for a lot of things, it's a good database. I really don't understand this. In what case is it every acceptable for a data store to lose data? And that's not even MongoDB's only problem: it memory leaks!

I have to say that I did not experience a single data loss that was a result of the database misbehaving. Memory leaks weren't a huge issue for us as well. After stabilizing the setup I have to say it was basically a fire and forget part of the stack for us. The role of MongoDB was to act as a fast-insert and aggregation framework for other parts of the system. So, we would insert BIG amounts of data at a time and ag…

> I have to say that I did not experience a single data loss that was a result of the database misbehaving.

Okay, but numerous people have experienced data loss using MongoDB. You can spend 10 minutes on Twitter and find someone talking about it.

> Memory leaks weren't a huge issue for us as well. After stabilizing the setup I have to say it was basically a fire and forget part of the stack for us.

"After stabilizing the setup"? So basically you worked around MongoDB's stability problems instead of choosing a solution that didn't have stability problems?

> The role of MongoDB was to act as a fast-insert and aggregation framework for other parts of the system.

Sure, but there are other solutions that can do this without MongoDB's issues (i.e. Cassandra).

> After a while, the setup became to expensive to run, at this point we turned it off for a cheaper solution, but in terms of functionality, it functioned pretty well.

Sure, you can build something stable on sand, but it's going to be a lot harder than just building on a solid foundation.

Re: Why you should never use MongoDB (2013)

#89

Post by devishard »

mack73 wrote: post #46
avitzurel wrote: post #32

Earlier quoted context omitted.

I have to say that I did not experience a single data loss that was a result of the database misbehaving. Memory leaks weren't a huge issue for us as well. After stabilizing the setup I have to say it was basically a fire and forget part of the stack for us. The role of MongoDB was to act as a fast-insert and aggregation framework for other parts of the system. So, we would insert BIG amounts of data at a time and ag…

Fire-and-forget is awesome for when you do not care at all about your data. I'm sure those types of writes are super (duper) fast. What exactly is the use case for that? Serious question.

I understand that some data loss is acceptable sometimes, but you can get the super-fast writes with a store that doesn't drop your data at random (such as Cassandra) so why would you choose the store that does?
Post reply on HN