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

41–50 of 188 posts

Re: Why you should never use MongoDB (2013)

#41

Post by overcast »

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…

Have a look at RethinkDB, it's the best of MongoDB and MySQL with real time feeds. A relational document store.

Re: Why you should never use MongoDB (2013)

#42

Post by avitzurel »

dorkalorka wrote: post #26
avitzurel wrote: post #16

I think it's ironic that the page says "Error establishing a database connection". As someone who used MongoDB extensively in the past (8TB+ of data) and also managed the devops side of things, I can tell you straight out that MongoDB has a place in a lot of startup stacks. I would likely not use it as a main source of truth for any application. However for a lot of things, it's a good database. Since I can't read th…

The placement of the commas in your post is blowing my mind!

Did you signup to HN just to make a snarky comment on my comma placement?

Not sure if I'm flattered or disturbed by this

Re: Why you should never use MongoDB (2013)

#43

Post by electricEmu »

This article has little to do with the specific failings of MongoDB at all. The author takes offense with document databases and denormalization. I disagree with the blanket statement.

Denormalization. It's not always the answer, but sometimes making reads easy and writes more difficult isn't bad for the problem set. The funny thing is a social network at scale isbt going to be able to use a traditional SQL database without sharding it and killing joins. It will be a documebt DB with limited SQL features.

As for Mongo, it is sold as the answer to everything just like any other product. It actually fits some problems sets. I actually had great success with it, at scale, in an Amazon division. It ain't the answer for a lot of problem sets though.

I give this blog post two of five for bringing up a mildly interesting topic HN already beat to the ground with misguided conclusions.

Re: Why you should never use MongoDB (2013)

#44

Post by nailer »

I like document oriented databases. It seems odd I should need to change the data structure of an item in order to persist it.

After about 5 years of the many/varied cases of Mongo losing data, I switched to rethinkdb for my current project. It's an uninteresting, surprise-less database and I like it very much.

Re: Why you should never use MongoDB (2013)

#45

Post by cpplinuxdude »

brazzledazzle wrote: post #31
ourcat wrote: post #12

Earlier quoted context omitted.

Amusingly ironic, eh? ;)

Mildly, but less so when you consider that it's a blog not a product. And even less so when you consider it likely fell over due to load and didn't silently delete the blog data.

No matter the load. A blog is only reads. Any db system should be able to hold up.

It's a different kettle of fish when there's writes; but for reads, it should be a walk through the park.

Re: Why you should never use MongoDB (2013)

#46

Post by mack73 »

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…

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.

Re: Why you should never use MongoDB (2013)

#47

Post by nailer »

avitzurel wrote: post #38
spriggan3 wrote: post #25

Earlier quoted context omitted.

> I would likely not use it as a main source of truth for any application what the point then ? MongoDB isn't even good for analytics and big data. What do you store in MongoDB ?

Commented above what we used MongoDB for.

I think you use it as a cache, but not what I would define as a database.

Re: Why you should never use MongoDB (2013)

#48

Post by nollbit »

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.

How do you know? Was your data checksummed? Did you read back changes after writes to verify what was written?

Re: Why you should never use MongoDB (2013)

#49

Post by manishsharan »

Not this FUD again! It is true that MongoDB created a lot of unexpected problems for the early adopters who did not do enough due diligence and testing. I encountered them during my POC with Mongodb but I was able to get past them easily thanks to a robust user community. I have experiences no such issues with current version with Mongodb.

Today I am fighting my enterprise bureaucracy to get MOngoDB for our enterprise applications .FUD like this allows armchair architects to quote this article to spook the management and we are stuck with stuffing json as in a RDBMS tables.

Re: Why you should never use MongoDB (2013)

#50

Post by danpalmer »

avitzurel wrote: post #16

I think it's ironic that the page says "Error establishing a database connection". As someone who used MongoDB extensively in the past (8TB+ of data) and also managed the devops side of things, I can tell you straight out that MongoDB has a place in a lot of startup stacks. I would likely not use it as a main source of truth for any application. However for a lot of things, it's a good database. Since I can't read th…

Can you give me a few examples of what it's good for? I haven't used it in production, but have researched it a fair amount, and can't find many situations where it would be suitable. Maybe analytics where it's somewhat arbitrary/changing JSON blobs and you don't care about losing individual messages?
Post reply on HN