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

131–140 of 188 posts

Re: Why you should never use MongoDB (2013)

#131

Post by gaius »

lmm wrote: post #95
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…

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

Indices are updated synchronously on every insert, slowing your writes, for the sake of transactional guarantees that most applications aren't written to take advantage of. Queries have to be passed over the wire as strings

Those are implementation details, not inherent properties of the relational model.

Re: Why you should never use MongoDB (2013)

#132

Post by jdmichal »

lmm wrote: post #95
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…

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

> You're assuming that you need to change things. Almost all big-data approaches work better when you abandon that and go for a log-structured model where you only ever append.

That depends on your loads. If you're write heavy, then yes. If you're read heavy, then you're adding extra work to find the current row out of all the appends. If you're read and write heavy, then get used to buying really expensive beefy machines and maybe sharding...

Re: Why you should never use MongoDB (2013)

#133

Post by 20years »

icc97 wrote: post #127
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.

To be fair, the projects pretty much required a full code re-write too. MongoDB in both cases was one of many bad decisions. Choosing all hipster stuff is what got them into trouble.

Re: Why you should never use MongoDB (2013)

#134

Post by clifanatic »

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…

> "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 recorded, but some whose age was recorded instead. Some TV shows would list the actors by role, some would just list the actors and the roles in two different lists. Sometimes the TV show start and end dates would be milliseconds since the epoch, some would be dates in YYYY/MM/DD formatted strings. Some would be dates in DD-MM-YY formatted strings. All scattered randomly throughout the data store. Elastic schema means random schema.

Re: Why you should never use MongoDB (2013)

#135

Post by herdrick »

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.

dozzie, could you remove the "Uhm, no." from that? It only adds snark to an otherwise good comment.

Re: Why you should never use MongoDB (2013)

#136

Post by drivingmenuts »

clifanatic wrote: post #134
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…

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

Re: Why you should never use MongoDB (2013)

#137

Post by phamilton »

throwanem wrote: post #116
hobs wrote: post #115

Earlier quoted context omitted.

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

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.

Re: Why you should never use MongoDB (2013)

#138

Post by breischl »

lmm wrote: post #95
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…

> 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 definition languages Huh... I always thought SQL was pretty straightforward for most cases. It only gets really arcane when you get into advanced cases (eg, recursive queries) and/or vendor extensions. It does take a bit of a mental shift, but no more so than imperative-style to functional-style, IMO.

There are certainly tradeoffs to using an RDBMS. But I think a lot of people jump to the conclusion that they have a big-data situation when they really don't. I also think a lot of people underestimate the value of very easy ad-hoc querying and already-solved backup/restore.

Re: Why you should never use MongoDB (2013)

#139

Post by geophile »

enraged_camel wrote: post #69
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." T…

Yes, I agree, it is easy to see how Agile could lead to this particular, disastrous, dead end.

Re: Why you should never use MongoDB (2013)

#140

Post by dragonwriter »

lmm wrote: post #95
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…

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

> And I don't know why there aren't RDBMSes without better query languages and schema definition languages, but there aren't

Well, better is subjective, but there are RDBMSs with languages other than SQL (e.g., Dataphor with its D4 language.)

Post reply on HN