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

61–70 of 188 posts

Re: Why you should never use MongoDB (2013)

#61

Post by enraged_camel »

ThePhysicist wrote: post #19

The post should probably be titled "Why you should not pick a technology based on hype and without evaluating it first". While MongoDB has (and probably still has) some flaws and is not the perfect DB system, there are valid use cases where it can be a good choice. Building a social networking site that requires rich queries along a relationship graph is most definitely not one of them.

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.

Re: Why you should never use MongoDB (2013)

#62

Post by vidarh »

nailer wrote: post #47
avitzurel wrote: post #38

Earlier quoted context omitted.

Commented above what we used MongoDB for.

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

Over the last 20 years, the vast majority of databases I have seen have been partly or wholly used as caches in some sense or other.

Re: Why you should never use MongoDB (2013)

#63

Post by willyk »

andyana wrote: post #37
devishard wrote: post #21

Earlier quoted context omitted.

I'm usually against absolutes, but I'm really in agreement here. It's almost always better to use a relational database, and in the rare cases where you wouldn't want a relational database, MongoDB is the worst of the major options. It literally memory leaks and drops data without warning or provocation. If you're not going to go with a relational database, RethinkDB, Cassandra, Redis, or BerkeleyDB would all be bett…

Do you know which role each of those (RethinkDB, Cassandra, Redis, and BerkeleyDB) excel at?

RethinkDB is targeted at soft real time applications which have a need to update data across many clients. Additionally, although its a schemaless document DB, it offers functionality similar to joins/relational queries. This is a good presentation on RethinkDB: https://www.youtube.com/watch?v=Ee1v_SuECRk

Re: Why you should never use MongoDB (2013)

#64

Post by codyb »

gwbas1c wrote: post #29

It takes that article a long time to get to the point. What I'd like to know is, "why is emulating joins bad?" Specifically, why is it bad to load a MongoDB document, and then load downstream documents that it links to? What kind of problems does this lead to? Granted, when I worked with MongoDB, I encountered problems due to its lack of transactions. (It's surprisingly unreliable if you end up needing to update mult…

Can you do it at the database level? Since MDB doesn't have joins wouldn't emulation require a lot more transactions across the wire? And in a distributed system couldn't that add up very quickly?

Re: Why you should never use MongoDB (2013)

#65

Post by mack73 »

brandur wrote: post #54
mack73 wrote: post #33

At this point in time, making a statement about MongoDB on HN should almost be considered trolling. We already know about the short-comings of that code-base. It will work fine until it doesn't and you'll loose some of your data. Some folks are using it and enjoying it. Others aren't. "Your shouldn't use it" is like saying you shouldn't use javascript for things other than UI. Noone cares anymore.

To be fair, I think your comment shows why this sort of post _can_ still be useful. You're very unlikely to lose data on a modern Mongo system using default configuration (their troubles with durability have largely been solved), but there are many other good reasons not to use it, and it's enlightening to read about and understand what they are.

If "their troubles with durability have largely been solved" were true then I'm sure HN would be flooded with posts about "MongoDB solves durability with an entirely new architecture". I might be wrong here. How did they solve the "your data is lost when a disk fails"?

Re: Why you should never use MongoDB (2013)

#67

Post by hitr »

I ran into exactly the same problem as the author . I started working on mongo as it was already chosen as backend for a startup .i tried to avoid it but they did not listen. We understood duplication is the only way forward and you need to unlearn your RDBS skill.Then features crop in and you realize that you need joins badly.Then you would like to have some kind of transaction support and its high time you realize you are really screwed. I always used to wonder what is the real use case for mongo and that is explained nicely in the blog

The only thing it’s good at is storing arbitrary pieces of JSON. “Arbitrary,” in this context, means that you don’t care at all what’s inside that JSON. You don’t even look. There is no schema, not even an implicit schema

Re: Why you should never use MongoDB (2013)

#68

Post by mack73 »

vidarh wrote: post #57
mack73 wrote: post #46

Earlier quoted context omitted.

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.

Don't know about the guy you replied to, but e.g. consider any application that regularly crawl feeds, api's etc. where the data is rapidly changing and only a portion of the data is necessary to give good output. There are lots of applications like that where you just need "enough" data to give good results and/or where any loss will auto-heal next time you crawl the original source.

That makes sense to me. If your MongoDB cluster under preasure will only actually persist 90% of your writes and this is something you anticipate, then MongoDB seems like a good choice, if writing in this style is faster than other nosql systems (that make grander promises about persistance) that is.

Re: Why you should never use MongoDB (2013)

#69

Post by enraged_camel »

geophile wrote: post #40

More than a story about MongoDB, this is a story about hype. The unquestioning, unthinking acceptance of some technology just because someone enjoying his 15 minutes of fame has tweeted about it. The designers of Diaspora set out to build a distributed database that needed to support complex queries and transactional updates. Only they didn't realize it. And they chose MongoDB because of hype. And of course it failed…

>>Yes, it was an unreasonable choice. This is basically saying that the cool kids are using document stores, so we should too. There is no discussion of requirements...

You hit the nail on the head. I posit that this problem is caused by the Agile mindset that says "we don't need to collect or discuss requirements upfront. They change too often! Instead, we will just start hacking and change things as we go along." Two years later, the team is running into all kinds of complex, hard-to-reproduce problems, and they realize that they have made a terrible mistake picking MongoDB and they have to undertake a very painful migration and rewrite of the backend.

Re: Why you should never use MongoDB (2013)

#70

Post by manyxcxi »

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…

This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info all over the place.

If you have semi normalized data relationships, Mongo really doesn't fit the bill that well as your primary data store.

Where it shines is when you've got computed pieces of data to display (parts of a user data feed for example, data for a live graph, etc), you want to quickly store some data to be processed later (analytics, event processing), or you just use it as an object cache for expensive queries.

I have found that with a decently tuned DB, and I mean barely tuned, a decent data model, and sane fetching strategies (don't eager load everything always), a database can be good enough for quite a while, if not forever.

The answer I pretty much always get from people when I ask, "Why did you start with (whatever NoSQL they chose)?" Is, "Because (whoever) said it's faster and scales better."

I think younger devs that have options besides relational DBs find the barriers to entry on NoSQL lower (it looks mostly like how it went in and it's just JSON) so they pass over the learning SQL and basic data normalization fundamentals.

Post reply on HN