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

121–130 of 188 posts

Re: Why you should never use MongoDB (2013)

#121

Post by marcosdumay »

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

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

No idea about what MongoDB would be good for, but:

> In what case is it every acceptable for a data store to lose data?

This is usually acceptable on analytics data, session data, on most of the "big data" applications... In fact, data that you can not lose whatever happens is the exception, not the rule.

Anyway, when in doubt, it's certainly better to err to the side of security, not risk. Even more because all that security is already written into some middleware that you can simply install and use.

Re: Why you should never use MongoDB (2013)

#122

Post by kolme »

hobs wrote: post #115
kolme wrote: post #110

Earlier quoted context omitted.

Indexes are basically a copy of the original data, only sorted in the right order. They are denormalized data, sort of.

Indexes are often only a pointer to that data, and they are not denormalized, they are better described as projections of your data (this way saving the work of ordering/filtering on that same projection in the future.)

Yes, they are pointers. But the indexed fields have to be duplicated for efficient reading. From Wikipedia:

"An index is a copy of select columns of data from a table that can be searched very efficiently that also includes a low-level disk block address or direct link to the complete row of data it was copied from." [1]

When you reference a field in an index, you're effectively duplicating this column on disk.

We can discuss semantics, but at the end of the day, indexes are glorified copies of your columns in a specific order.

[1] https://en.wikipedia.org/wiki/Database_index

Re: Why you should never use MongoDB (2013)

#123

Post by franciscop »

KirinDave wrote: post #81
franciscop wrote: post #9

Is it a joke? > Error establishing a database connection Or is it truly an error? In a page that from the title is bashing another DB

Unfair comparisons aside, no one is "bashing" MongoDB. These criticisms have been levied for years (as the article demonstrates by its byline). These complaints have been levied not just because we should expect more reliability from corporate-backed database products, but because _they run counter to the advertising and technical literature_ that 10gen produced. It is not "bashing" to say, "I do not like this and by…

Sorry didn't read the article due to the error and I truly wasn't sure if it was an error or a joke; so from my limited knowledge I wrongly assumed it was an article bashing MongoDB

Re: Why you should never use MongoDB (2013)

#124

Post by kolme »

tremon wrote: post #119
kolme wrote: post #110

Earlier quoted context omitted.

Indexes are basically a copy of the original data, only sorted in the right order. They are denormalized data, sort of.

Are you suggesting that RAID-1 and RAID-5 are also examples of denormalized data, sort of?

Not really, for two reasons:

- It's done at the hard disk level, so no database or data schema is involved.

- It's not done for performance reasons, but for security reasons (not to lose any data).

"In computing, denormalization is the process of trying to improve the read performance of a database, at the expense of losing some write performance, by adding redundant copies of data or by grouping data."

It's a technique that involves copying data for some very particular reason, an abstraction to hide the nasty duplication because the desirable thing is to have only one source of truth.

So while there's some remote similarity (the copying of data), the goals are completely different.

Re: Why you should never use MongoDB (2013)

#125

Post by icc97 »

chaostheory wrote: post #120
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…

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

Re: Why you should never use MongoDB (2013)

#126

Post by hitchhiker999 »

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…

Finally, great comment - had to scroll too far to get to this!

1) The developers clearly weren't experienced enough to know what document storage is and when/where it shines/fails. 2) Author jumped on the ever-boring 'i hate mongo' easy train. 3) I am so sick of technology becoming a religious war.

Re: Why you should never use MongoDB (2013)

#127

Post by icc97 »

20years wrote: post #111

My company got hired for 2 very large MongoDB to MySQL migration projects this year alone totaling over $170k. These apps should have never been on MongoDB in the first place. Total mess that cost them lots of $$. I am okay if others continue to use MongoDB. It will keep my team gainfully employed ;)

Wow, that is truly impressive. I'd be surprised if there's any examples of people prepared to spend the same amount of money to go the opposite way.

Re: Why you should never use MongoDB (2013)

#128

Post by codyb »

gwbas1c wrote: post #103
codyb wrote: post #64

Earlier quoted context omitted.

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?

I'm looking for a more quantitative answer. For example, if I write a message board in MDB: - An entire discussion (think hacker news story and all corresponding discussion) is a single document - Each post, reply, ect, has a user ID - I load the post object and then do a "where uid in (all uids in document)" query Obviously, that has scalability limits, but what are they? In practice, when do you hit them?

Sounds like a great article. Take some of the open sourced reddit comments, or just create a small script to generate lorem ipsum posts for "users". Deploy mongo somewhere. Scale the data and scale the number of requests per second and see when things fall off. I've got so many projects I'd like to do but that does sound neat. I'd like to compare it to couchbase and postgres as well, two databases I'm much more interested in, and also Neo4j which I'm sure I've heard of but rediscovered when looking up graph databases after reading this article.

Could be a couple of solid weekends maybe with a few friends. A lot of good experience gained from my end that I could see.

Re: Why you should never use MongoDB (2013)

#129

Post by spikej »

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…

What you're really after is materialized/indexed views, or having the NoSQL DB be a layer after your primary DB...

Re: Why you should never use MongoDB (2013)

#130

Post by jdmichal »

kolme wrote: post #124
tremon wrote: post #119

Earlier quoted context omitted.

Are you suggesting that RAID-1 and RAID-5 are also examples of denormalized data, sort of?

Not really, for two reasons: - It's done at the hard disk level, so no database or data schema is involved. - It's not done for performance reasons, but for security reasons (not to lose any data). "In computing, denormalization is the process of trying to improve the read performance of a database, at the expense of losing some write performance, by adding redundant copies of data or by grouping data." It's a techni…

A good RAID controller exactly fits your included quote. It will speed up reads by distributing to all disks, but writes will be slower because they have to be written to all disks before the controller will signal the write as completed.
Post reply on HN