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

101–110 of 188 posts

Re: Why you should never use MongoDB (2013)

#101

Post by jt2190 »

manyxcxi wrote: post #70
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…

This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info all over the place. If you have semi normalized data relationships, Mongo really doesn't fit the bill that well as your primary data store. Where it shines is when you've got computed pieces of data to display (parts of a user data feed for example, data for a…

I agree with you, but would like to add that by using SQL to query a relational database it is very, very easy to denormalize the data that is copied into an application, so while a relational schema is essentially "static", query results are very dynamic, and can easily strip away all of the "goodness" that results from a normalized data structure.

In other words, the application probably needs to deal with normalization and schema if it's taking copies of data, and using a relational database doesn't remove this requirement. (Of course, small applications often get away without enforcing schema, with the understanding that frequent database write failures due to malformed data are ok.)

Re: Why you should never use MongoDB (2013)

#102

Post by dozzie »

nurettin wrote: post #78
phamilton wrote: post #58

Earlier quoted context omitted.

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.

> [...] 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.

Re: Why you should never use MongoDB (2013)

#103

Post by gwbas1c »

codyb wrote: post #64
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…

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?

Re: Why you should never use MongoDB (2013)

#105

Post by lmm »

SeanDav wrote: post #92
GoldenMonkey wrote: post #91

Earlier quoted context omitted.

There are two paradigms with databases. Normalization for high volume insert/update transaction requirements (faster writes). Denormalization for (faster reads), typically used for data warehouses and reporting. NoSQL is designed to support both of these scenarios well. And with lower overhead requirements by not having to update a central store... It is used in particular for Big Data solutions. Rather than having t…

Not being optimized for a particular use case, makes it a poor choice for anything outside toy, or best case, medium sized applications.

The point is you have the level of control that lets you optimize for your use case. RDBMSes are a jack-of-all-trades solution and have the advantage of needing very little customization, but they can't be as well-optimized for specific use cases.

Re: Why you should never use MongoDB (2013)

#106

Post by rch »

3pt14159 wrote: post #94
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.

Why? Now I have to learn a crappier version of SQL (no support for real date types, no user management, etc) and heaven help me if my toy project actual gets traction. I'll have to migrate everything over to Postgres or I'll have to keep my DB on a single server because it's just a single file. Compared to just using Postgres or even MySQL I do not understand the benefit. It takes less than an hour to spin up a PG da…

SQLite provides date and time functions for working with e.g. ISO8601 strings, but I understand where you're coming from.

https://www.sqlite.org/lang_datefunc.html

https://www.sqlite.org/datatype3.html#section_2_2

Re: Why you should never use MongoDB (2013)

#107

Post by tremon »

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…

Indexes are not an example of denormalization. Normalization means that there is one canonical element that describes an object, not that there's only one copy or representation of that element.

Re: Why you should never use MongoDB (2013)

#108

Post by alexchantavy »

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.

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

Re: Why you should never use MongoDB (2013)

#109

Post by catnaroek »

manyxcxi wrote: post #70
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…

This is a problem I've had to explain to too many developers recently. It's not faster just because you throw away data modeling practices and jam bits of info all over the place. If you have semi normalized data relationships, Mongo really doesn't fit the bill that well as your primary data store. Where it shines is when you've got computed pieces of data to display (parts of a user data feed for example, data for a…

> find the barriers to entry on NoSQL lower

Not having to think rigorously about the logical structure of your data is a huge selling point for many. For programmers, because it means they don't have to think. And for employers, because it means they can make do with programmers who don't want to think.

Re: Why you should never use MongoDB (2013)

#110

Post by kolme »

tremon wrote: post #107
phamilton wrote: post #58

Earlier quoted context omitted.

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…

Indexes are not an example of denormalization. Normalization means that there is one canonical element that describes an object, not that there's only one copy or representation of that element.

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

They are denormalized data, sort of.

Post reply on HN