MongoDB, The Complete Guide [Part 2]
Now that you’ve learned about various types of NoSQL databases in part 1, we will discuss the concept of Polyglot Persistence and the reasons why NoSQL is chosen by engineers.
Why Choose NoSQL?
There are two main reasons why engineers choose NoSQL databases for their problems:
Minimizing the Impedance Mismatch
- Since a lot of effort is spent on mapping in-memory to in-database, saving that effort improves developer productivity.
- Sometimes, a NoSQL database has a data model that better suits the needs of our application, and thus simplifies the interaction of the application code with the database. This way, we have less code to develop and maintain.
- For example, in MEAN stack (M is for Mongo DB) the whole stack uses JSON objects, and the interaction of application code and database is minimal.
Embracing large scale data
Today it is very time-consuming to store a large amount of data in the relational databases. Businesses have a need to capture and process a lot of data more quickly because many NoSQL databases are designed to run on clusters, which are a better fit for this kind of problem.
Large scale clusters give us the ability to store larger data sets and process large amounts of analytic data. Also, NoSQL databases have different data models that may be better for processing huge amounts of data.
Does this mean that relational databases are dead?
No, not at all. The relational data model is still the best choice for a large number of problems out there. Additionally, relational databases have been here for decades, which means that there are many tools for them and people are familiar with them, unlike the fairly new concept of NoSQL database.
The only difference is the way that we should perceive relational databases — they are no longer the only option for data storage.
This way of looking at data storage will lead us to solutions with multiple databases, each of which will be used for a different purpose. For example, we can use:
- SQL for a financial part of the application
- MongoDB for products catalogue
- Cassandra for large-scale analytics
Polyglot Persistence has opened a new door in application development, never before have we had so many options and possibilities.
It has also raised a lot of questions. One of them being which database should be used in what situations.
This approach creates a lot of complexity, too, since there is no simple mechanism for maintaining data consistency. Maybe multi-model databases will fill this gap. Either way, it has not been this exciting in the database world since the mid-80s — what a time to be alive!
You’ve learned about NoSQL and all of its types so far. Now we will jump to MongoDB yay! The wait is over…
Core MongoDB Concepts
In this part, we will touch upon the structure of MongoDB and goes over the MongoDB documents.
Document databases are probably the closest thing to relational databases of all the databases in the NoSQL ecosystem.
Documents databases store documents in collections, a lot like relational databases store rows in tables; but, we’ll get more into that later.
One of the most popular representatives of Document databases and one of the leading NoSQL databases is MongoDB.
A Basic Introduction
Before we see all the different ways that MongoDB can be used, let’s go through some of the basic concepts of this database.
Guys from MongoDB are very proud of what they call Nexus Architecture. This architecture gives the ability to combine proven concepts and abilities of relational databases with NoSQL innovations.
MongoDB is a document-oriented database and, as previously mentioned, it has certain similarities to relational databases.
Instead of rows, MongoDB has documents. Unlike relational databases, where information for a given record is spread across many tables, all of the data for a given record is stored within a single document.
Under the hood, documents are BSON files, which are the binary-encoded serialization of JSON files. Nevertheless, from a programmer’s point of view, MongoDB manipulates pure JSON files.
For example, we can represent
user like this:
As you can see:
- there is an
_idthe field at the beginning of this JSON document.
This field is unique and is generated by MongoDB for every document in the database.
This way MongoDB keeps one of the important properties of relational databases — strong consistency.
Collections in MongoDB
In this lesson, we will delves further into the concept of documents and collections and also go over the differences between MongoDB and Relational Databases.
What are Collections?
Documents are stored inside of collections.
Collections are groups of somehow related documents, but these documents don’t need to have the same structure.
Here lies one of the biggest benefits of MongoDB: developers don’t need to know the schema of the database beforehand but can modify the schema, dynamically, during development. This is especially great in systems where we can’t get the schema quite right in the beginning, or there are plenty of edge cases to cover.
Also, this way, the entire problem with impedance mismatch is avoided (i.e., elimination of the object-relational mapping layer).
What does this look like?
Well, let’s say that the previous document is stored in the collection called
users; we could add another document into that collection which would contain fields that the previous document didn’t have, or we could add a document that may not have the fields that the previous document had.
As an example, we could add the next document into the collection:
As you can see these documents are similar, but not the same. The new document doesn’t contain the
numberOfArticles field, but it does contain an additional
location field which the previously added document didn’t have.
Collection groups then, give you the ability to add indexes to these documents. Indexes are one of the concepts that MongoDB inherited from relational databases.
Differences Between MongoDB & Relational Databases
It’s important to emphasize some of the differences between MongoDB and Relational databases.
Firstly, MongoDB doesn’t have foreign keys; but, it has a feature that looks quite like that — References.
Any object can have a reference to some other object, using its
id, but this is not automatically updated, and it’s up to the application to keep track of these connections.
This is done in this way because once a foreign key is introduced in a relational database, it can be hard to unwind the database from it.
Thanks to the document data model, and due to the fact that all the necessary information for one “record” is stored inside one document, joins are not provided in MongoDB. However, a similar mechanism called Lookup is available.
Among other differences, it should be mentioned that there is no equivalent of multiple-table transactions in MongoDB.
That is quite a lot of theory — so let’s see how it looks in practice in Part 3. If you have any query till now feel free to send hi at email@example.com. I am open to every suggestions.