
Introduction to MongoDB - praveenscience
https://www.pluralsight.com/guides/sql/introduction-to-mongodb
======
justboxing
> 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."

~~~
threeseed
> 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 ?

~~~
brandur
> _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
> 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
> _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,
...).

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

------
molsson
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.htm...](https://mo.github.io/2017/01/22/mongo-db-tips-and-tricks.html)

~~~
praveenscience
This one is awesome! Thanks for this link. Really precise and concise.

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

------
marklawrutgers
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
Start with "not MongoDB" and take it from there.

------
gaius
_whereas the traditional RDBs do not scale easily._

No need to read any further than this.

~~~
tracker1
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".

