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

141–150 of 188 posts

Re: Why you should never use MongoDB (2013)

#141

Post by mamcx »

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…

Also this weird adversion against using the power of a RDBMS.

NO VIEWS! NO STORED PROCEDURES! NO TRIGGERS! YOU SQL MUST BE AGNOSTIC!

and stuff like that. However, they pick Mongo or anything like that and yep, they must use anything it provide just by necessity.

---

People:

Using views is easy. Is probably the most simple thing you can get to leverage what a DB can give (plus indexes) and let model the data in different ways and even help in transition from a data model and another.

Re: Why you should never use MongoDB (2013)

#142

Post by clifanatic »

drivingmenuts wrote: post #136
clifanatic wrote: post #134

Earlier quoted context omitted.

> "forget about normalization! Duplication is okay." Not just duplication. I did some work on a platform that used ElasticSearch as a relatively relational "document" store (that is, a purpose to which a true RDBMS would have been better suited). Besides data duplication, we ran into the problem of data consistency: using the author's TV show example, we would end up with some actor's whose birthdates would be record…

On the surface, that sounds more like a problem of data cleanup before insertion. Were you doing any validation/normaliztion of the data beforehand?

> Were you doing any validation/normaliztion of the data

Of course we (they) were - lots of it! Just inconsistently...

Re: Why you should never use MongoDB (2013)

#143

Post by lmm »

breischl wrote: post #138
lmm wrote: post #95

Earlier quoted context omitted.

> 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? You need to propagate the change across every duplicate of the document in every collection where it exists. This means that any "de-duplication" logic needs to happen at the application level, rather than the database…

>>Queries have to be passed over the wire as strings, so your application will spend a significant chunk of its time building them... or else you get to deal with the db-specific and per-connection quirks of prepared statements... Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. >>I don't know why there aren't RDBMSes without better query languages and schema defi…

> Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like.

The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. And the lack of a library ecosystem. And poor IDE support. And...

Re: Why you should never use MongoDB (2013)

#144

Post by hobs »

phamilton wrote: post #137
throwanem wrote: post #116

Earlier quoted context omitted.

Not only that, they're projections which you don't have to spend effort on keeping up to date, and which the engine automatically uses to optimize your queries. While there's an argument to be made that the same can be accomplished in a non-relational database with suitable application code or a translation layer, all else equal it's better not to need those things in the first place.

And as we saw from a recent Uber post about Postgresql, that automatic updating is not actually free.

Was going to say the same, but I realized the OP was talking about in your code, not so much as overhead.

Re: Why you should never use MongoDB (2013)

#145

Post by breischl »

lmm wrote: post #143
breischl wrote: post #138

Earlier quoted context omitted.

>>Queries have to be passed over the wire as strings, so your application will spend a significant chunk of its time building them... or else you get to deal with the db-specific and per-connection quirks of prepared statements... Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. >>I don't know why there aren't RDBMSes without better query languages and schema defi…

> Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. And the lack of a library ecosystem. And poor IDE support. And...

>>SQL just not being a pleasant language for expressing business logic

No kidding - don't do that. Sprocs are great to present a query interface and avoid sending queries over the wire every time. They can be handy to decouple the actual storage architecture from the query interface, so you can do tricky stuff in SQL without screwing up the clients. That doesn't mean you should stick your business logic in there.

>>testability, versioning, deployment... library ecosystem...

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.

>>poor IDE support

So your code editor has a better IDE for SQL? Or are we talking about a document DB? I haven't seen any of them that were anywhere close to SSMS.

Re: Why you should never use MongoDB (2013)

#146

Post by breischl »

alexchantavy wrote: post #108
rch wrote: post #77

Earlier quoted context omitted.

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.

What's an example of an application that is a good fit for MongoDB?

If you have a fairly complex object structure that is logically a single unit, and you only need/want to query on a small number keys. Or anytime you might think "It would be better to just serialize this and shove it into a VARCHAR column."

eg, the rate structure for a vacation rental. The fancier ones (not AirBnB) can have lots of different seasons, stay durations, various upcharges/discounts, etc. It's difficult to model in SQL, and even if you could it's not usually useful. Dealing with the entire thing as a single document just makes more sense.

Another example: if you need to handle data that your app doesn't really own. eg, you're going to read it, maybe wrap it up with some other data, and pass it on. In that case being able to handle and store that data as a mostly-opaque blob is handy.

Of course that's an argument for a document DB in general, not Mongo in particular. Dynamo, Rethink, etc might be better choices.

Re: Why you should never use MongoDB (2013)

#147

Post by throwanem »

phamilton wrote: post #137
throwanem wrote: post #116

Earlier quoted context omitted.

Not only that, they're projections which you don't have to spend effort on keeping up to date, and which the engine automatically uses to optimize your queries. While there's an argument to be made that the same can be accomplished in a non-relational database with suitable application code or a translation layer, all else equal it's better not to need those things in the first place.

And as we saw from a recent Uber post about Postgresql, that automatic updating is not actually free.

Of course it's not, but if you're not Uber, that almost certainly isn't a problem for you. When you use MongoDB, you get to roll your own indexes no matter who you are.

Re: Why you should never use MongoDB (2013)

#148

Post by dragonwriter »

lmm wrote: post #143
breischl wrote: post #138

Earlier quoted context omitted.

>>Queries have to be passed over the wire as strings, so your application will spend a significant chunk of its time building them... or else you get to deal with the db-specific and per-connection quirks of prepared statements... Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. >>I don't know why there aren't RDBMSes without better query languages and schema defi…

> Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like. The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic. And the lack of a library ecosystem. And poor IDE support. And...

> > Or you could use stored procedures. Think of it as making your RDBMS into a microservice, if you like.

> The trouble is testability, versioning, deployment, and SQL just not being a pleasant language for expressing business logic.

Most of those, to the extent they are valid, are trouble with using stored procs in SQL for that purpose, but most RDBMSs support stored procs in languages other than SQL.

Re: Why you should never use MongoDB (2013)

#149

Post by mateo411 »

rogerdpack wrote: post #100
fragola wrote: post #97

Earlier quoted context omitted.

It's a trade-off. There are a lot of reasons to duplicate (faster reads, etc.), with the big drawback being consistency. The duplications are basically caches, with similar pros and cons. I think a good solution is to use something like DynamoDB and use hot/cold tables. Like, if you're storing something high read/write (i.e. today's olympic stats), keep it in the hot table with a frequent cache timeout. Later, when t…

If it's like Cassandra, then you can kind of get around consistency problems by, for instance if you have a "replication" factor of 2, by instructing it to write to "2 instances before returning" (and then you turn around and read it after that, if you want to double check). Though of course while it's writing to the first, then second replica, it'll be inconsistent, but not for too long :)

Yes, that is the difference between strongly consistent and eventually consistent.

Re: Why you should never use MongoDB (2013)

#150

Post by avitzurel »

devishard wrote: post #88
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…

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

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

Never said people didn't.

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

No, I haven't worked around the limitations, after tweaking heap sizes, machine sizes and disk speeds the setup was very stable.

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

Again, I DO NOT disagree, there are other solutions and today we are running a completely different setup to replace the same component.

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

I'm trying to ignore the snarky/attacking nature of your comment. Not sure if this is addressable.

Post reply on HN