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

71–80 of 188 posts

Re: Why you should never use MongoDB (2013)

#71

Post by fadzlan »

manishsharan wrote: post #49

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 enterpris…

The article is from 2013, so its very much likely that some of the issues has been handled by MongoDB itself or some agreed practices.

Re: Why you should never use MongoDB (2013)

#72

Post by devishard »

vidarh wrote: post #55
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!

Here's one: I have an aggregation engine where 99.99something% of the data is cycled out within 3 days, and where the system can be functional again within about ~5 minutes of ingesting new data after a total data loss. There are a lot of applications where your database is not the or even a source of truth, but effectively a big cache that you can either fully rebuild or where rebuilding isn't necessary (the data is…

> There are a lot of applications where your database is not the or even a source of truth, but effectively a big cache that you can either fully rebuild or where rebuilding isn't necessary (the data is too "fast moving" for there to be much point).

This use case doesn't mean it's okay to lose data randomly. Cache invalidation should happen intentionally via an intelligent algorithm, and other data stores (such as Redis) provide this.

> Here is another: A search engine for classifieds where the source of truth of 99%+ of listings were external feeds that'd get re-crawled at least once a day. If we lost a few million updates, who cared? If it was few enough, we'd just let the normal updates take care of it. If we had a major problem, or needed to do a major update that'd have compatibility implications, we could just do a re-crawl of all the feeds.

Just because some data loss is acceptable doesn't mean it's desirable, and while I agree that most of the time some data loss doesn't matter, I don't think you can actually say it never will. What if the 1% listing happens to include an client's feed when the client is doing a major product launch?

> You're scaling reads by replication, and so the vast majority of your data exists in multiple data stores. You may choose one you consider reliable for the source of truth, and the rest are basically caches, but you may want/need something more capable than a straight up key/value store for various reasons.

Again, cache invalidation should happen intelligently via a well-thought-out algorithm, not by randomly dropping data, and there are solutions which supply that.

> I believe the vast majority of data stores I've worked with have been ok to suffer a total loss of because most of them are not the source of truth, and the source of truth can be re-queries fast enough for it to not be a big deal to deal with losses in secondary copies.

Okay, I don't buy this, but let's say it's true. What about the memory leaks?

And what if your needs change, and you're no longer okay with data loss? Are you willing to take the risk that you're going to have to rewrite your storage layer because you chose a data store that drops data randomly, and your needs changed?

Re: Why you should never use MongoDB (2013)

#73

Post by phamilton »

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…

Lack of isolation and multi document atomic updates is one of the biggest difficulties. If you are updating multiple associated documents under a semantic transaction, it's possible there will be a window in which the partial update is visible. Sometimes this is harmless, other times quite harmful (changing constraints and budget on a bidding platform can result in overpaying for undesired inventory for example).

This can be worked around somewhat. If you only ever update the parent documents, then you can create new associated documents and atomically update the parent document to point to all the new ones. It's a bit of a song and dance, and definitely has limitations and gets complicated fast.

Re: Why you should never use MongoDB (2013)

#74

Post by toast0 »

weddpros wrote: post #53
toast0 wrote: post #35

Earlier quoted context omitted.

Without any knowledge of mongodb; if using it means you have to handle sharding right away, and using MySQL means you have to handle sharding when you outgrow a single instance, isn't that a big deal? MySQL scales pretty well these days, I think, so you can get a huge box -- a lot of stuff will fit in 2TB of ram.

MySQL can't scale horizontally if you're using it like it's a relational database. No joins between shards means Sarah Mei could throw away her data model if she needs sharding. She would then need to denormalize her data to avoid joins, which is the main argument in the article. The project they were working on was a social network, a free alternative to Facebook. So I guess it's safe to say a single box, even the b…

I meant scale on a single box, sorry for confusion. It used to not be a great idea to get a really big SMP box to run MySQL because locking would kill performance; I think the locks are fine grained enough these days.

Re: Why you should never use MongoDB (2013)

#75

Post by brazzledazzle »

cpplinuxdude wrote: post #45
brazzledazzle wrote: post #31

Earlier quoted context omitted.

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.

And yet many blog dbs fall over under what is ostensibly read-only loads. It could be inefficient connection reuse, shitty disks or it could be something as stupid as writing visitor data on each visit. But it's irrelevant to the main point which is that it's a blog.

This comes up every time a blog falls over that discusses or criticizes a database on HN and it's just as shallow as it ever was. Do we really expect anyone to spend significant time optimizing their blogs for load that may not ever come? We talk about "pre-optimization" and "core competency" routinely on here and then shoot the messenger when a wordpress blog using MySQL falls over that's criticizing something like MongoDB. It's irrelevant to the point of silliness.

Re: Why you should never use MongoDB (2013)

#77

Post by rch »

enraged_camel wrote: post #61
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.

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.

Re: Why you should never use MongoDB (2013)

#78

Post by nurettin »

phamilton wrote: post #58
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…

While not a fan of mongoDB for many reasons, any sufficiently large scale application will have denormalization. Caching layers cause all sorts of cache invalidation bugs because of this exact problem. Indexes, while often managed by the DB, are essentially denormalization. One could even argue that syncing data between a client and server is a class of the same problem. My point is that we deal with these problems o…

If you excuse the buzzword, data warehouses are built for this very reason. So you are right in the sense that cache invalidation and denormalization are problems in sql based large scale systems, but they are largely solved problems whereas in mongodb you would need to do this work manually.

Re: Why you should never use MongoDB (2013)

#79

Post by feld »

coding123 wrote: post #76

ArangoDB would have been a good fit, it's basically mongo db with graph features. By the way 99.99999% of the time a WordPress blog can't establish a database connection is because they used mysql.

The database backend of a Wordpress blog has nothing to do with this conversation. Any software can be poorly tuned/configured. NoSQL wouldn't magically solve this problem.

Re: Why you should never use MongoDB (2013)

#80

Post by tensor »

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.

And for those few where you think MongoDB might be a good fit, you should probably use something like RethinkDB instead.
Post reply on HN