Video Transcript (English)

Now that you have a better understanding of what MongoDB is and how it came to be, let’s dive deeper into its architecture.

In this video, we'll discuss MongoDB architecture. Next, we'll briefly review the CAP theorem which will prime us to examine how MongoDB manages the related tradeoffs. Then we'll dive into replication, which is MongoDB's solution for high availability. After that, we'll discuss read and write concerns which help MongoDB manage consistency. And finally we'll cover sharding, which is how MongoDB allows you to partition data so you can scale.

Keep in mind, what we cover here is to help you get started with MongoDB and become familiar with its terminology. These topics are covered comprehensively in other University units and in our documentation if you are curious to learn more.

Let’s start with an overview of MongoDB’s hierarchy for organizing data. We’ll start from the bottom up with Documents.

Documents are the smallest unit of data in MongoDB. They typically store information about an object and any of its related metadata. Documents store data in field-value pairs. The values can be a variety of data types, including strings, numbers, dates, arrays, objects, and more. We’ll discuss the document model and data types in MongoDB in an upcoming unit.

MongoDB stores multiple documents in collections.

A collection is a group of documents that typically correspond to an entity in our data model. But MongoDB’s flexible data model allows you to model collections based on your application’s needs, supporting multiple entities and documents of different shapes.

Next, a group of collections is housed by a database.

Something to note, typically when we talk about a database we're referring to a database management system (or DBMS) like MongoDB or PostgreSQL. But in the context of the MongoDB architecture a database is simply a group of collections.

The next two levels of our architecture hierarchy are key components to MongoDB’s distributed system.

First, we have nodes. A node refers to an individual MongoDB instance. This instance can be running on a physical machine, a virtual machine, or within a container.

The next level up is a cluster. A cluster is a group of MongoDB nodes.There are two main types of clusters in MongoDB, replica sets and sharded clusters.

Replica sets help MongoDB achieve high availability through a process called replication. Sharded clusters support scaling through a partitioning process called sharding.

Before we learn more about replication and sharding let's zoom out for a moment and discuss the CAP Theorem.

The CAP theorem states that in a distributed system, it's impossible to simultaneously guarantee consistency, availability, and partition tolerance.

Consistency means that every read should have updated data from the most recent write or give an error, ensuring that all nodes in the system return all the same data at the same time.

Availability is met when every request, read or write, receives a response, even if it may not be the most recent or correct data.

Finally, Partition Tolerance is where the system continues to function despite communication breakdowns between nodes or partitions.

A distributed system can only achieve two of these three at any given time.

MongoDB, which is a distributed database, supports Partition Tolerance via replication and sharding. This means that users can manage the balance between consistency and availability.

So, let’s talk more about how MongoDB manages availability through replication first.

Replication is the process of storing multiple copies of data and keeping them synchronized across multiple nodes to provide redundancy. Because the same data is stored on multiple nodes, the database will continue to run as expected even if one of the nodes experiences a failure and goes offline. This process makes data highly available.

MongoDB uses replica sets to perform the process of replication. We dive deep into replica sets in our unit on replication. But for now, all you need to know is that a replica set is a group of mongod instances that maintain the same data set.

Notice I said mongod, not mongodb. A mongod is the primary daemon process for the MongoDB database system. It handles data requests, manages data access, and performs background management operations.

Since replica sets maintain multiple nodes with redundant data, you may be wondering how data stays consistent.

When writing data on a distributed system, it can be a challenge to keep data consistent across the nodes. MongoDB manages data consistency through Read and Write Concerns.

Read Concern controls the consistency and isolation of the data read from replica sets or sharded clusters.

By default, the read concern is set to local in MongoDB. This means that MongoDB will return data from the node on which the request is run, without waiting for data to be acknowledged by other replica set members. This default behavior ensures high availability and low latency, but cannot guarantee consistency. However, there are other Read Concern settings that prioritize consistency, such as the “majority” setting.

The Write Concern dictates the number of replica set members that must confirm a write operation for it to be considered successful.

By default, the write concern is set to majority. This means that the majority of the replica set will confirm that the write is successful, which allows for faster write operations.

Together, read and write concerns allow you to balance performance, availability, and consistency according to your application's needs.

Now that we've discussed how replication solves the need for high availability and read and write concerns address consistency, let's talk about partition tolerance and scaling. As mentioned earlier, sharding is the mechanism MongoDB uses to scale. Let’s look at what it entails.

With sharding, you partition, or shard, your data in MongoDB across multiple nodes. Each shard contains a subset of the sharded data. Together, the shards make up a single logical database, or sharded cluster.

In MongoDB, sharding provides horizontal scalability. As your dataset grows, you can add more shards to distribute the data and the load, ensuring that the database continues to perform well.

However, it's essential to keep in mind that sharding in MongoDB requires careful planning because it adds complexity to your deployments and is not always required.Poorly balanced clusters can lead to inefficient use of resources and can degrade query performance.

Congratulations! You have completed this lesson on MongoDB’s architecture as a distributed database system. Let’s review what you learned.

In this lesson, you learned what documents, collections, databases, nodes, and clusters are in MongoDB and how they fit into a hierarchy.

We quickly reviewed the CAP Theorem. Then you learned how MongoDB ensures high availability using replication, manages consistency through read and write concerns, and ensures scalability through sharding.

Now that you have a deeper understanding of the makeup of MongoDB, jump into the next lesson to discover MongoDB’s fully managed cloud database, Atlas.