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

171–180 of 188 posts

Re: Why you should never use MongoDB (2013)

#171

Post by chaostheory »

icc97 wrote: post #125
chaostheory wrote: post #120

Earlier quoted context omitted.

> "if you have a hammer, everything looks like a nail." I don't like MongoDB either, but normalization is not the answer for every project. For some projects, reading efficiency is so important that people are willing to pay for of it in disk space, an increase in writing costs, and even app complexity.

Normalisation is a good starting point though. If you hit the limits of normalisation then you can always denormalise.

It depends on the problem and current circumstances. Just because MongoDB doesn't work, it doesn't mean alternatives to relational DBs should be ignored.

Re: Why you should never use MongoDB (2013)

#172

Post by lmm »

breischl wrote: post #157
lmm wrote: post #155

Earlier quoted context omitted.

> And how would any of those problems be solved by using raw SQL strings or a document DB? That just moves the problems back into the schema or the data, where it's even harder to deal with. I'm arguing for using a non-SQL interface. Either a structured binary query protocol (which leaves you shipping a lot of data around sure, but at least removes the constructing-and-parsing SQL overhead), or a map-reduce style set…

It seems to me that you're advocating changing implementation details (binary query protocol instead of SQL, map-reduce queries instead of sprocs) and claiming that it is somehow fundamentally different. But I don't see how that would be the case. How is a binary query protocol fundamentally different than calling a sproc? How is a map-reduce job in Javascript any different on the attributes you mentioned than ad-hoc…

Binary query protocol is just a tweak, but it's a tweak that most RDBMSes are missing, and it matters for some workloads.

Switching to a model where you supply your own map-reduce or pipeline is a real shift, I think, from the DB as a framework that manages querying for you to more of a library/toolkit you can use to write your own computations. The indexed tables model is an incredibly effective compromise, but it's still a compromise - if you know specifically what you need to do, you can do it better.

Running a first-class programming language with full support for usual programming language tools is a major difference for developability, testability, libraries and so on. Deployment model depends on the datastore - plenty of non-SQL ones have room for improvement here - but I think the traditional RDBMS still has the worst of it.

Re: Why you should never use MongoDB (2013)

#175

Post by mack73 »

brandur wrote: post #113
mack73 wrote: post #65

Earlier quoted context omitted.

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

I'm talking about "durability" here in the context of the "D" in "ACID". Previously, Mongo had very serious problems in that are because its client would assume that any message sent to the outgoing socket buffer was persisted "well enough", which was an obvious untruth [1]. This was also one of the somewhat underhanded techniques they used to achieve their early benchmarks. As of version 3, they have defaulted their…

MongoDB was initially designed to beat other nosql systems in benchmarks, is what I take away from reading about it. Someone took issue with that and wrote an article. "MongoDB lies" and "is slow" were some of the claims made from your link #1.

Now that these issues are gone, by having reasonable default settings for write concern and journaling, how well does MongoDB do in the benchmarks today?

Rewgarding default settings, how is "w=1" considered a safe write? The data exists in a single node and has not been propagated. If you only have one node then I guess it's as safe as can be. Is MongoDB suitable as a single node installation though? I would have thought "w=2" or "w=majority" would be the "safe" setting.

Re: Why you should never use MongoDB (2013)

#176

Post by gwbas1c »

phamilton wrote: post #73
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). Thi…

I'm painfully aware of the "Lack of isolation and multi document atomic updates is one of the biggest difficulties" problem, as I encountered it when I tried working with MongoDB. (I chose MongoDB because I was working with very fluid requirements and needed a very flexible schema.)

But that's not really what the article complains about!

The context is that I met some of the Diaspora leads in the summer of 2010. At the time, they were ambitious, but very inexperienced. (They did teach me some valuable lessons about encryption!) The reason why I say this, is without some kind of data, it's hard to know if "don't emulate joins in MongoDB" is a conclusion of inexperience; and something that a more experienced developer would understand how to do correctly.

For example, in a message board application, if a join is emulated between a discussion and user objects that just have username and avatar; the penalty of seeing an incomplete update is inconsequential. Either the user sees the old name / avatar, or the user sees the new name / avatar. So the incomplete update problem (in theory) can be handled by restricting "joins" to only when it's okay to see old data.

So, assuming that the incomplete update problem is solvable, at what point do emulated joins stop scaling?

Re: Why you should never use MongoDB (2013)

#177

Post by nurettin »

dozzie wrote: post #102
nurettin wrote: post #78

Earlier quoted context omitted.

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.

> [...] data warehouses are built for this very reason. [...] [cache invalidation and denormalization] are largely solved problems [...] Uhm, no. Data warehouse is not a database with operational (i.e. current) data, it's a database with historical data. If it is out of sync with production for a day or a week, it's totally OK, depending on its design. So no, cache invalidation is not a solved problem there.

I've worked with data warehouses which were replicated like a multimaster, YMMV.

Re: Why you should never use MongoDB (2013)

#178

Post by nailer »

vidarh wrote: post #62
nailer wrote: post #47

Earlier quoted context omitted.

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.

I'd agree with that - DBs only record things that have actually happened elsewhere in most cases - but if a DB isn't considered reliable as a source of truth (in particular, if it's backed by another piece of software that is considered the source of truth) it's not a database and is a cache.

Re: Why you should never use MongoDB (2013)

#179

Post by phamilton »

gwbas1c wrote: post #176
phamilton wrote: post #73

Earlier quoted context omitted.

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). Thi…

I'm painfully aware of the "Lack of isolation and multi document atomic updates is one of the biggest difficulties" problem, as I encountered it when I tried working with MongoDB. (I chose MongoDB because I was working with very fluid requirements and needed a very flexible schema.) But that's not really what the article complains about! The context is that I met some of the Diaspora leads in the summer of 2010. At t…

> by restricting "joins" to only when it's okay to see old data.

So what do you do when it's not OK to see old data? That's when it breaks down.

There are definitely ways around the issues, but you have to make compromises in how you build the application. If you don't make those design decisions early, you find yourself doing it wrong.

In describing large scale systems, a friend of mine said "Imagine a scenario that has a one in a billion chance of happening. On a 10k qps system, it happens almost daily."

That's how this breaks down at scale. Awkward corner cases that don't really seem likely suddenly become daily events.

Re: Why you should never use MongoDB (2013)

#180

Post by devishard »

vidarh wrote: post #152
devishard wrote: post #72

Earlier quoted context omitted.

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

First of all, let me make it clear that none of these points are specific to MongoDB. I have used (and do use) it for some projects, and I have used many other storage setups where we accepted risks of data loss. The specific technology doesn't matter. > This use case doesn't mean it's okay to lose data randomly. It often does, as long as the frequency is low enough. I've worked on many systems where the decision was…

> It's a completely reasonable tradeoff as long as you can quantify the risk and quantify the cost (here's a tip for something that scarily few engineering organizations does: track not just time spent on projects, but calculate the cost per feature and report on it; it very quickly changes organisational priorities when managers see that what they thought was a minor change ended up costing $10k engineering time)

Except it's not a tradeoff: you don't get anything for it that you couldn't get from another data store option. Maybe MongoDB was the only option for some things 5 years ago, but it's not now. There are other options that don't leak memory and lose data.

> Do you think we just randomly say "oh, lets just lose data for fun?"

Basically, yes. You're claiming you weighed the benefits agains the tradeoffs, but I'm saying that you can get all those benefits without making a tradeoff.

>As above: Serves crash. So if your system needs to be available, you need according redundancy. The typical additional scaling cost (accounting for a slightly increased risk of simultaneous restarts, requiring a small amount of extra capacity) of dealing with restarts on resource constraints are often perfectly ok. I tend to design all systems I work on to allow as many components at possible to be restarted at will, because you need to be able to accommodate upgrades etc. anyway. If you first do that, then allowing automatic restarts in the case of failure-types where that is acceptable tends to be trivial.

Of course you should build redundancy into the system, but that's to handle unforseen problems, not to handle problems which you know are there from the start.

Post reply on HN