I think the takeaway of "easily" is relevant... I would say "as easily" and it really depends on your needs. Very high write scenarios don't work as well in an SQL database as say a Cassandra cluster. Let alone multi-master or automatic failover scenarios. Most NoSQL databases are easier to setup for certain types of eventual consistency scaling...
Now, better consensus varies a lot by db... I'm a pretty big fan of the approaches of RethinkDB, and would love to use it sometime over Mongo for an actual project. But Mongo isn't horrible for some use cases. Likewise, Cassandra and ElasticSearch also have their good/great use cases. It just depends on your need.
In the end though, if you need very high writes and redundancy, then SQL databases can start to hit bottlenecks very quickly. You usually have to relax part of the db constraints for growing beyond a certain point horizontally. You can shard and manually shard SQL data, but it gets weird, and anything but "easy".
> 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."
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
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 ?
> 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.
(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.
> 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.
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.
> 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, ...).
Anyone have good links or articles for DB comparisons to get a better understanding of which DB fits best for what type of projects?
So far I've gathered from here is that I want Postgres if going for a SQL DB, MariaDB as a MySQL drop-in, Redis for a simple NoSQL cache DB, RethinkDB for real-time applications (if project is still ongoing), and then there's CouchDB, CockroachDB, Cassandra, etc. which I still need to look in to.
If this was a book I would pick it up and lightly place it in the trashcan.
I don't care what sort of changes they've made under the hood since I used MongoDB at massive scale, all I know is 9 out 10 of my major outages were Mongo related and now that I run PostgreSQL, all my outages have been human error related.
What I find interesting is when I discuss MongoDB with other developers is that (so far) all of them seem to think that there should only be "one" database. When I explain to other developers that it's OK to use an SQL database as a primary database and MongoDB (or another document based storage system) for periphery data (logs, events) or data that is difficult to store in a relational system.
Somehow there seems to be this notion that you either use xyz document store OR a relational database. I don't think this is the case.
I often end up with MySQL, MongoDB and Redis to store data.
I'm guilty of this. I have a project I'd like to open source and it's currently using a blend of MySQL and Mongo. I plan on moving it over to Postgres before publishing its source.
I've been mostly happy using MySQL for relational things and Mongo where it makes sense, but there is a certain amount of overhead in setting up and configuring multiple different types of datastores. Securely deploying Mongo in particular is a minefield, and expecting other people to be willing to learn the nuances of this stuff seems like more work than just saying "use Postgres".
19 comments
[ 3.8 ms ] story [ 36.4 ms ] threadNo need to read any further than this.
Now, better consensus varies a lot by db... I'm a pretty big fan of the approaches of RethinkDB, and would love to use it sometime over Mongo for an actual project. But Mongo isn't horrible for some use cases. Likewise, Cassandra and ElasticSearch also have their good/great use cases. It just depends on your need.
In the end though, if you need very high writes and redundancy, then SQL databases can start to hit bottlenecks very quickly. You usually have to relax part of the db constraints for growing beyond a certain point horizontally. You can shard and manually shard SQL data, but it gets weird, and anything but "easy".
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
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."
That's basically the same thing as 'MongoDB is web scale'. sigh
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 ?
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.
(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.
> 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.
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.
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, ...).
Bzzzt! You ALWAYS have a schema. The only question is whether and to what extent your tools help you validate or enforce it.
So far I've gathered from here is that I want Postgres if going for a SQL DB, MariaDB as a MySQL drop-in, Redis for a simple NoSQL cache DB, RethinkDB for real-time applications (if project is still ongoing), and then there's CouchDB, CockroachDB, Cassandra, etc. which I still need to look in to.
I don't care what sort of changes they've made under the hood since I used MongoDB at massive scale, all I know is 9 out 10 of my major outages were Mongo related and now that I run PostgreSQL, all my outages have been human error related.
Somehow there seems to be this notion that you either use xyz document store OR a relational database. I don't think this is the case.
I often end up with MySQL, MongoDB and Redis to store data.
I've been mostly happy using MySQL for relational things and Mongo where it makes sense, but there is a certain amount of overhead in setting up and configuring multiple different types of datastores. Securely deploying Mongo in particular is a minefield, and expecting other people to be willing to learn the nuances of this stuff seems like more work than just saying "use Postgres".