4 ms·

> NoSQL is generally much faster in most cases, so if you need to store or retrieve large quantities of data, NoSQL is the way to go. Right. Here's the other

> NoSQL is generally much faster in most cases, so if you need to store or retrieve large quantities of data, NoSQL is the way to go. Right. Here's the other side. [EDIT: In the HN discussion, not the linked article] Why you should never use MongoDB (2013) => https://news.ycombinator.com/item?id=12290739 https://news.ycombinator.com/item?id=12290739 Cherry-picked quote. > I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplication is okay."

lostcolony 9y ago
Not to mention his conclusion - "an increasingly popular NoSQL database that ca(n) enhance pretty much any application that relies on using lots of data." That's basically the same thing as 'MongoDB is web scale'. sigh
threeseed 9y ago
> Why you should never use MongoDB (2013) I wouldn't post this in the future. It's irrelevant. This is pre-Wiredtiger which means it is a completely different database. Before the Jepsen work, before the replication protocol update, before the default fsync changes etc. Almost nothing is the same except maybe the query engine ?
- justboxing 9y ago
  > I wouldn't post this in the future. It's irrelevant. I meant to draw attention to the HN user comments on that story, not the actual story itself :) Edited to make that clear. I do believe the HN comments about data inconsistency, duplicity, using a NoSQL solution where an RDBMS makes more sense, are all relevant. Here's another quote from that discussion thread. > 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.
  - threeseed 9y ago
    (1) NoSQL comprises hundreds of databases. Are all of them worse than every single RDBMS even those that support ACID ? That's just idiotic. (2) MongoDB supports date types. Don't blame them if you choose to use a string or number. And yes it is a schemaless database as it was designed to be since day one. If you can't competent enough to manage your schema in your application layer than use something else.
- brandur 9y ago
  > I wouldn't post this in the future. It's irrelevant. > This is pre-Wiredtiger which means it is a completely different database. That's not true. Mongo switched out their backend and fixed a few heinous bugs and defaults. All the important parts from the perspective of developer and operator experience including no data normalization, weak constraints, lack of anything beyond document-level atomicity, etc., are still the same. If you read the article, it's largely about how document databases that encourage denormalization don't do a good job of modeling or working with relational data, which is most of what we're all working with. In this respect, nothing's changed in Mongo.
  - threeseed 9y ago
    > In this respect, nothing's changed in Mongo I honestly don't understand this though. MongoDB is a schemaless, document database. That is exactly what it was designed to be and one of the big reasons people are using it. And many of us aren't working with relational data.
    - brandur 9y ago
      > And many of us aren't working with relational data. I think this is probably where the disconnect is. If your data has relations to other data, which is the vast majority of things that you're going to be building in the real world, it's relational. Mongo came out of the gates billing itself as a general purpose backend solution for modern "webscale" apps. It was upfront about being document-oriented, but not upfront about the ramifications of such a design, leaving a lot of people including the author of this article to find out the hard way as to the sort of architectural debt that you end up with as you shoehorn a relational schema into a non-relational store. When you're showing a simple demo with three relations like article <-> comment <-> user it's easy to be fooled that a document oriented design is relatively sane, but once you build something more complex the shortcomings become very apparent _very_ quickly. > That is exactly what it was designed to be and one of the big reasons people are using it. A lot of people are using it because of early hype, aggressive marketing (the "MEAN stack"), and misleading benchmarks when it came out (`writeConcern`, flush intervals, and no journaling) combined with the fact that moving databases is very hard once you've got a big operation going. I don't think there's been a reason to use Mongo for years now, but that goes doubly so these days with the advent of modern scalable databases that give you a lot of important features that Mongo doesn't (Aurora, Citus, Spanner, ...).

lostcolony 9y ago

Not to mention his conclusion - "an increasingly popular NoSQL database that ca(n) enhance pretty much any application that relies on using lots of data." That's basically the same thing as 'MongoDB is web scale'. sigh

threeseed 9y ago

> Why you should never use MongoDB (2013) I wouldn't post this in the future. It's irrelevant. This is pre-Wiredtiger which means it is a completely different database. Before the Jepsen work, before the replication protocol update, before the default fsync changes etc. Almost nothing is the same except maybe the query engine ?

justboxing 9y ago
> I wouldn't post this in the future. It's irrelevant. I meant to draw attention to the HN user comments on that story, not the actual story itself :) Edited to make that clear. I do believe the HN comments about data inconsistency, duplicity, using a NoSQL solution where an RDBMS makes more sense, are all relevant. Here's another quote from that discussion thread. > 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.
- threeseed 9y ago
  (1) NoSQL comprises hundreds of databases. Are all of them worse than every single RDBMS even those that support ACID ? That's just idiotic. (2) MongoDB supports date types. Don't blame them if you choose to use a string or number. And yes it is a schemaless database as it was designed to be since day one. If you can't competent enough to manage your schema in your application layer than use something else.
brandur 9y ago
> I wouldn't post this in the future. It's irrelevant. > This is pre-Wiredtiger which means it is a completely different database. That's not true. Mongo switched out their backend and fixed a few heinous bugs and defaults. All the important parts from the perspective of developer and operator experience including no data normalization, weak constraints, lack of anything beyond document-level atomicity, etc., are still the same. If you read the article, it's largely about how document databases that encourage denormalization don't do a good job of modeling or working with relational data, which is most of what we're all working with. In this respect, nothing's changed in Mongo.
- threeseed 9y ago
  > In this respect, nothing's changed in Mongo I honestly don't understand this though. MongoDB is a schemaless, document database. That is exactly what it was designed to be and one of the big reasons people are using it. And many of us aren't working with relational data.
  - brandur 9y ago
    > And many of us aren't working with relational data. I think this is probably where the disconnect is. If your data has relations to other data, which is the vast majority of things that you're going to be building in the real world, it's relational. Mongo came out of the gates billing itself as a general purpose backend solution for modern "webscale" apps. It was upfront about being document-oriented, but not upfront about the ramifications of such a design, leaving a lot of people including the author of this article to find out the hard way as to the sort of architectural debt that you end up with as you shoehorn a relational schema into a non-relational store. When you're showing a simple demo with three relations like article <-> comment <-> user it's easy to be fooled that a document oriented design is relatively sane, but once you build something more complex the shortcomings become very apparent _very_ quickly. > That is exactly what it was designed to be and one of the big reasons people are using it. A lot of people are using it because of early hype, aggressive marketing (the "MEAN stack"), and misleading benchmarks when it came out (`writeConcern`, flush intervals, and no journaling) combined with the fact that moving databases is very hard once you've got a big operation going. I don't think there's been a reason to use Mongo for years now, but that goes doubly so these days with the advent of modern scalable databases that give you a lot of important features that Mongo doesn't (Aurora, Citus, Spanner, ...).