4 ms·

Introduction to MongoDB

gaius 9y ago
whereas the traditional RDBs do not scale easily. No need to read any further than this.
- tracker1 9y ago
  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".
justboxing 9y ago
> 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.
molsson 9y ago
If you prefer a more compact intro in Q&A format: https://mo.github.io/2017/01/18/mongo-db-basics.html https://mo.github.io/2017/01/18/mongo-db-basics.html https://mo.github.io/2017/01/22/mongo-db-tips-and-tricks.html https://mo.github.io/2017/01/22/mongo-db-tips-and-tricks.htm...
- praveenscience 9y ago
  This one is awesome! Thanks for this link. Really precise and concise.
marklawrutgers 9y ago
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.
- gaius 9y ago
  Start with "not MongoDB" and take it from there.
nasalgoat 9y ago
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.
pan69 9y ago
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.
- drewrv 9y ago
  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".
- nasalgoat 9y ago
  The right tool for the right job.

whereas the traditional RDBs do not scale easily. No need to read any further than this.

tracker1 9y ago
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".

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

molsson 9y ago

If you prefer a more compact intro in Q&A format: https://mo.github.io/2017/01/18/mongo-db-basics.html https://mo.github.io/2017/01/18/mongo-db-basics.html https://mo.github.io/2017/01/22/mongo-db-tips-and-tricks.html https://mo.github.io/2017/01/22/mongo-db-tips-and-tricks.htm...

praveenscience 9y ago
This one is awesome! Thanks for this link. Really precise and concise.

marklawrutgers 9y ago

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.

gaius 9y ago
Start with "not MongoDB" and take it from there.

nasalgoat 9y ago

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.

pan69 9y ago

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.

drewrv 9y ago
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".
nasalgoat 9y ago
The right tool for the right job.