DEPARTMENT OF

ARTIFICIAL INTELLIGENCE & MACHINE LEARNING

22AML64A
Next-Gen Database Technology using MongoDB
 MODULE 3

MongoDB ─ A Database for the Modern Web: What is MongoDB?, JSON, JSON Structure, MongoDB
Structure, Document Store Example, MongoDB as a Document Database, Transaction Management in
MongoDB, Scaling Up vs. Scaling Out, Features of MongoDB, Secondary Indexes, Replication,
Memory Management, Auto Sharding, Aggregation and MapReduce, Collection and Database, Schema
Design and Modeling, Reference Data Model, Embedded Data Model, Data Types, Installing
MongoDB on Linux, Windows, Starting MongoDB On Windows, Use Cases: Explore MongoDB
database
Reference : https://learn.mongodb.com/courses/start-here-introduction-to-mongodb
OVERVIEW OF NON-RELATIONAL
DATABASES
WHERE IT BEGAN: RELATIONAL
KEY FEATURES OF RELATIONAL
DATABASES

Related data is stored in A table uses columns to define

SQL (Structured Query
rows and columns in one the information being stored
Language)
table. and rows for the actual data.
 Filling in the Gap

1970s 1990s 2000s

Relational Databases World Wide Web NoSQL

SQL was developed by IBM as Need for data storage Unstructured data storage
a way to interact with the new explodes to mitigate costs and
relational databases increase efficiency
NON-RELATIONAL DATABASE
TYPES
NON-RELATIONAL DATABASE TYPES

Key/Value Graph Column Document

Structure

● A unique key is paired with a

collection of values, where
the values can be anything
from a string to a large
binary object

Strength
Key/Value Database

● Simple data model

Key/Value: Example

Key Value

Name Sherlock Holmes

Age 40

Address 221B Baker

Street
Structure

● Captures connected data

● Each element is stored as a
node
● Connections between nodes
are called links or
relationships

Strength
Graph Database
● Traverses the connections
between data rapidly
 Graph: Example
221B
Baker :addr
ess
St.

: li
ke
Sherlock

d
ress
s Holmes
Post
i e nd :fr
r
:f h wi iend
1
:add
:p t
os wi th s
te
d

John :friends with

Irene
Watson Adler
:p
d

os
te

:p
os

te

os
d
d
:like
d
:p

te
Post Post
2 Post
3 1
Structure

● Data is stored using key

rows that can be
associated with one or
more dynamic columns

Strengths

● Highly performant queries

● Designed for analytics Column Oriented
or Wide Column
 Column Oriented Example

Name ID Age ID Height ID

Sherlock 001 40 001 6’2 001

John 002 45 002 5’9 002

Irene 003 43 003 5’7 003

Structure

● Polymorphic data models

● Each document contains

markup that identifies fields
and values

Strengths

● Obvious relationships using

embedded arrays and Document Database
documents

● No complex mapping
 Document Model Example

{
"_id": {
ObjectId("5ef2d4b45b7f11b6d7a"), "_id":
"user_id": "Sherlock Holmes", ObjectId("6ef8d4b32c9f12b6d4a"),
"age": 40, "user_id": "John Watson",
"address": "age": 45,
{ "address":
“Country: “England” {
“City”: “London”, “Country: “England”
“Street”: “221B Baker St.” “City”: “London”,
}, “Street”: “221B Baker St.”
“Hobbies”:[ violin, crime-solving ] },
} “Medical license”: “Active”
}
THE DOCUMENT MODEL
FOR GENERAL PURPOSE USE, THE
DOCUMENT MODEL PREVAILS AS
THE PREFERRED MODEL BY
DEVELOPERS AND DATABASE
ADMINISTRATORS.
WHAT IS MONGODB ?
MONGODB

● MongoDB is a scalable, flexible NoSQL document database platform

designed to overcome the relational databases approach and the
limitations of other NoSQL solutions.
● MongoDB is well known for its horizontal scaling and load balancing
capabilities, which has given application developers an unprecedented
level of flexibility and scalability.
● MongoDB Atlas is the leading global cloud database service for modern
applications.
● Using Atlas, developers can deploy fully managed cloud databases
across AWS, Azure, and Google Cloud.
MONGODB AS A DOCUMENT
DATABASE
{
The Document Model:
"_id": ObjectId(
Structure and Syntax
"5f4f7fef2d4b45b7f11b6d7a"),
"user_id": "Sean", To the left is an example of a
document representing a
"age": 29,
user details including
"Status": "A" user_id, age, and a status
} category.
{
The Document Model:
"_id": ObjectId(
Structure and Syntax
"5f4f7fef2d4b45b7f11b6d7a"),
"user_id": "Sean", A document in MongoDB
"age": 29, uses the JavaScript Object
Notation (JSON) format.
"Status": "A"
} This format uses curly brackets
to mark the start and the end of
the document.
{ The Document Model:
"_id": ObjectId( Structure and Syntax
"5f4f7fef2d4b45b7f11b6d7a"),
"user_id": "Sean", MongoDB refers to keys
as fields.
"age": 29,
"Status": "A" The field-values within a
pair in a document are
}
separated by colons (:).
{ The Document Model:
"_id": ObjectId( Structure and Syntax
"5f4f7fef2d4b45b7f11b6d7a"),
Each field must be
"user_id": "Sean", enclosed within quotation
"age": 29, marks. String values are
"Status": "A" often quoted as good
practice.
}
{ The Document Model:
"_id": ObjectId( Structure and Syntax
"5f4f7fef2d4b45b7f11b6d7a"), Each field-value pair is
"user_id": "Sean", separated within the
"age": 29, document by commas.

"Status": "A"
}
TRANSACTIONS IN
MONGODB

https://www.mongodb.com/docs/manual/core/transactions/
WHAT IS A TRANSACTION?
A single unit of logic composed of multiple different database
operations, which exhibits the following properties:

Atomic: either completes in its entirety or has no effect whatsoever

(rolls back and is not left only partially complete)

Consistent: each transaction observes the latest current database

state in the correct write ordering

Isolated: the state of an inflight transaction is not visible to other

concurrent inflight transactions (and vice versa)

Durable: changes are persisted and cannot be lost if there is a

system failure
LOCAL AND GLOBAL TRANSACTIONS
LOCAL TRANSACTIONS IS WHEN THE SINGLE TRANSACTION AND ITS OPERATIONS
ARE PERFORMED AGAINST THE SAME DATABASE INSTANCE.

GLOBAL TRANSACTION IS WHEN THE SINGLE TRANSACTION AND ITS OPERATIONS

ARE PERFORMED AGAINST TWO OR MORE DIFFERENT INSTANCES.
APPROACHES TO
TRANSACTIONS IN MONGODB
TWO APPROACHES TO TRANSACTIONS

MongoDB Document MongoDB Transactions

>= 1.0 MongoDB
>= 4.2 MongoDB
 TRANSACTIONS WITH A DOCUMENT
Patient records from a doctor’s visit. Update the document in one operation

patients collection
{
date of visit "_id": 2395652,
"name": "AJ",
"current_weight": 70,

doctor's notes "next_physical": "2021-06-13",

"visits": [
{ "date": "2018-12-24",
"notes": "Torn right calf" },
{ "date": "2020-02-01",
drugs prescribed "notes": "Strained left hamstring" }
],
"drugs": [
{ "date": "2018-12-24",
current weight "drug": "Ibuprofen" },
{ "date": "2020-02-01",
"drug": "Paracetamol" }
]
}
 TRANSACTIONS WITH A DOCUMENT
patients collection
{
Atomic: All writes to one "_id": 2395652,
document are done at once "name": "AJ",
"current_weight": 210,
Consistency: No dependency "next_physical": "2021-06-13",
"visits": [
on other documents { "date": "2018-12-24",
"notes": "Torn right calf" },
Isolation: Document being { "date": "2020-02-01",
modified not seen by other "notes": "Strained left hamstring" }
],
reads "drugs": [
{ "date": "2018-12-24",
Durability: Guaranteed by "drug": "Ibuprofen" },
{ "date": "2020-02-01",
doing a write with a "majority"
"drug": "Paracetamol" }
concern ]
}
ACID WITH A MONGODB DOCUMENT

SINCE MONGODB VERSION 1.0

Preferred way to achieve ACID

Design your model to have documents,

embedding the different relational tables
updated together
 TRANSACTIONS WITH A DOCUMENT
Patient records and payments patients collection
{
from a doctor’s visit. "_id": 2395652,
"name": "AJ",
"current_weight": 210,
"next_physical": "2021-06-13",
date of visit "visits": [
{ "date": "2018-12-24",
"notes": "Torn right calf" },

doctor's notes { "date": "2020-02-01",

"notes": "Strained left
hamstring" } ],
"drugs": [
drugs prescribed { "date": "2018-12-24",
"drug": "Ibuprofen" },
{ "date": "2020-02-01",
"drug": "Paracetamol" } ]
current weight }
payments collection
{

payment information "date": "2020-02-01",

"patient_id": 2395652,
"amount": 250.00,
}
 TRANSACTIONS WITH A MONGODB
TRANSACTION patients collection
{
Atomic: All writes to all "_id": 2395652,
"name": "AJ",
documents are committed "current_weight": 70,
at once "next_physical": "2021-06-13",
"visits": [
{ "date": "2018-12-24",
Consistency: All checks are "notes": "Torn right calf" },
{ "date": "2020-02-01",
done within the transaction "notes": "Strained left
hamstring" } ],
Isolation: Guaranteed "drugs": [
{ "date": "2018-12-24",
through a "snapshot" "drug": "Ibuprofen" },
{ "date": "2020-02-01",
isolation level "drug": "Paracetamol" } ]
}
Durability: Guaranteed by payments collection
{
default, the write has a "date": "2020-02-01",
"patient_id": 2395652,
"majority" concern "amount": 250.00,
}
SCALING UP VS. SCALING OUT
DATABASE SCALING

● Database scalability is the ability to expand or contract the capacity of

system resources in order to support the changing usage of your
application
● This can refer both to increasing and decreasing usage of the application.
● Increased usage of your application brings three main challenges to your
database server:
○ The CPU and/or memory becomes overloaded, and the database server either
cannot respond to all the request throughput or do so in a reasonable amount
of time.
○ Your database server runs out of storage, and thus cannot store all the data.
○ Your network interface is overloaded, so it cannot support all the network
traffic received.
https://www.mongodb.com/resources/basics/scaling
https://www.mongodb.com/resources/basics/horizontal-vs-vertical-scaling
TWO APPROACHES

● There are two approaches to database scaling:

○ Vertical scaling also known as scaling up
○ Horizontal scaling also known as scaling out
SCALING UP (VERTICAL APPROACH)
● The vertical scaling approach, also referred to as "scaling up," focuses on adding more
resources or more processing power to a single machine.
● These additions may include CPU and RAM resources upgrades which will increase the
processing speed of a single server or increase the storage capacity of a single machine
to address increasing data requirements.
● Advantage:
○ it is easier than the alternative horizontal scaling approach, since hardware resources and/or
computing resources are only being added to one machine, there is less complexity
involved.
○ since only one machine is being upgraded, vertical scaling is often a more economical
choice in the short-term than the horizontal scaling approach.
● Disadvantage:
○ With one machine, there is a limit to the amount of upgrades or expansion that can occur.
○ This means that an organization's scalability needs may not be met if their single machine
doesn't have the necessary expansion capacity.
SCALING UP
PROS
CONS
● The main benefit of vertical scaling • The downside of scaling up is that servers
is that nothing changes about your with more storage and processing power
database infrastructure other than can be a lot more expensive.
the hardware specifications of the • There is also a physical limit on the
machine running the database. amount of CPUs, memory, network
● As such, it's transparent to the interfaces, and hard-drives that can be
application. The only difference is used on a single machine.
that you have more CPUs, memory, • If scaling vertically requires a migration
and/or storage space. between hardwares, it could result in
● downtime or service disruption.
Vertical scaling is a good option to
try first if massive storage and
processing are not required.
https://www.mongodb.com/resources/basics/horizontal-vs-vertical-scaling
SCALING OUT (HORIZONTAL APPROACH)

● The horizontal scaling approach also known as "scaling out," refers to

adding more machines to further distribute the load of the database
and increase overall storage and/or processing power.
● There are two common ways to perform horizontal scaling —
○ Sharding , which increases the overall capacity of the system,
○ Replication, which increases the availability and reliability of the system
● This approach improves the system's fault tolerance and availability, as
a single point of failure in one machine does not affect the remaining
machines

● MongoDB implements horizontal scaling with a method called sharding

SCALING OUT
PROS
CONS

● Horizontal scaling is "infinitely scalable" • Horizontal scaling may require application

as you can always add another architecture and code changes due to the
machine, if you are already using the distributed nature of the data.
• Database systems that are scaled
largest machine available.
horizontally can be more complicated to
● There is more predictable increases in
manage and maintain, leading to more work
pricing
for you and your team.
● Horizontal scaling can also deliver better • This approach also adds additional
performance and customer experience. complexity as it's important to make sure
● An example of this is distributing with data is evenly distributed across the shards
global clusters to deliver better and there is no duplicated or lost data.
performance in each region.

https://www.mongodb.com/resources/basics/horizontal-vs-vertical-scaling
 FEATURES OF MONGODB

https://www.mongodb.com/resources/products/capabilities/features
 Document Model
● MongoDB has been designed with developer
productivity and flexibility in mind.
● It is a document-oriented database, which
means that data is stored as documents, and
documents are grouped in collections.
● The document model is a lot more natural for
developers to work with because documents
are self-contained and can be treated as
objects.
● This means that developers can focus on the
data they need to store and process, rather
than worrying about how to split the data
across different rigid tables.
● Documents are grouped together
in collections. However, the documents in a
single collection don't necessarily need to
have exactly the same set of fields. This is
what we call a “flexible schema.”
DOCUMENT MODEL

● Documents in MongoDB are stored in the BSON format, which is a binary-encoded

JSON format. This means that the data is stored in a binary format, which is much
faster than JSON.
● This also allows for the storage of binary data, which is useful for storing images,
videos, and other binary data. Even though BSON is a binary-encoded format, it's
easy to work with it using the MongoDB driver for your programming language.
 SHARDING

● Sharding is the process of splitting larger datasets across multiple

distributed instances, or “shards.”
● When applied to particularly large datasets, sharding helps the database
distribute and better execute what might otherwise be problematic and
cumbersome queries.
● Sharding in MongoDB allows for much greater horizontal scalability.
● Horizontal scaling means that each shard in every cluster houses a portion
of the dataset in question, essentially functioning as a separate database.
● Combining the data of the distributed shards forms a single, comprehensive
database much better suited to handling the needs of a popular, growing
application with zero downtime.
 SHARDING IN MONGODB
• All client operations in a sharding
environment are handled through
a lightweight process
called mongos.
• The mongos can direct queries to
the correct shard based on the
shard key. Proper sharding also
contributes significantly to better
load balancing.
REPLICATION

● When your data only resides in a single server, it is exposed to multiple potential
points of failure, such as a server crash, service interruptions, or even good old
hardware failure. Any of these events would make accessing your data nearly
impossible.
● Replication allows you to sidestep these vulnerabilities by deploying multiple
servers for disaster recovery and backup.
● Horizontal scaling across multiple servers greatly increases data availability,
reliability, and fault tolerance.
● Potentially, replication can help spread the read load to the secondary members
of the replica set with the use of read preference.
REPLICATION IN MONGODB

● In MongoDB, replica sets are employed

for this purpose.
● A primary server or node accepts all
write operations and applies those
same operations across secondary
servers, replicating the data.
● If the primary server should ever
experience a critical failure, any one of
the secondary servers can be elected
to become the new primary node.
● If that server comes back online, it
becomes a secondary once it fully
recovers, aiding the new primary node.
AUTHENTICATION

● Authentication is a critical security feature in MongoDB. Authentication ensures

that only authorized users can access the database.
● MongoDB provides a number of authentication mechanisms for users to access
the database.
● The most common is the Salted Challenge Response Authentication Mechanism
(SCRAM), which is the default.
● When used, SCRAM requires the user to provide an authentication database,
username, and password.
INDEXING

● The number one issue that many technical support teams fail to address with
their users is indexing.
● Indexes are intended to improve search speed and performance.
● A failure to properly define appropriate indexes can and usually will lead to
accessibility issues, such as problems with query execution and load balancing.
● Without the right indexes, a database is forced to scan documents one by one to
identify the ones that match the query statement.
● But if an appropriate index exists for each query, user requests can be optimally
executed by the server.
INDEXING

● MongoDB offers a broad range of indexes and features with language-specific sort
orders that support complex access patterns to datasets.
● Notably, MongoDB indexes can be created on demand to accommodate real-time,
ever-changing query patterns and application requirements.
● They can also be declared on any field within any of your documents, including
those nested within arrays.
DATABASE TRIGGERS

● Database triggers in MongoDB Atlas are a powerful feature that allow you to
execute code when certain events occur in your database.
● For example, you can use triggers to execute a script when a document is
inserted, updated, or deleted. Triggers can also be scheduled to execute at
specific times.
● MongoDB Atlas allows you to create and manage triggers in a simple, intuitive
way.
● Database triggers are a great way to perform audits, ensure data consistency and
data integrity, and to perform complex event processing.
TIME SERIES DATA

● Time series data is most commonly generated by a device, such as a sensor, that
records data over time. The data is stored in a collection of documents, each of
which contains a timestamp and a value.
● MongoDB provides a number of features to help you manage time series data.
● The native time series collections in MongoDB are designed to be storage-
efficient and perform well with sequences of measurements.
● You have a number of parameters to control the storage of time series data,
including the granularity (the time span between measurements) and the
expiration threshold of old data.
AD-HOC QUERIES

● When designing the schema of a database, it is impossible to know in advance all

the queries that will be performed by end users.
● An ad-hoc query is a short-lived command whose value depends on a variable.
Each time an ad-hoc query is executed, the result may be different, depending on
the variables in question.
● With ad-hoc query support that allows developers to update ad-hoc queries in real
time, the improvement in performance can be game-changing.
● MongoDB supports field queries, geo queries, and regular expression searches.
Queries can return specific fields and also account for user-defined functions.
● This is made possible with MongoDB indexes, BSON documents, and the
MongoDB Query Language (MQL). MongoDB also supports aggregations via the
Aggregation Framework.
LOAD BALANCING

● At the end of the day, optimal load balancing remains one of the holy grails of large-
scale database management for growing enterprise applications.
● Properly distributing millions of client requests to hundreds or thousands of servers
can lead to a noticeable (and much appreciated) difference in performance.
● Fortunately, via horizontal scaling features like replication and sharding, MongoDB
supports large-scale load balancing.
● The platform can handle multiple concurrent read and write requests for the same
data with best-in-class concurrency control and locking protocols that ensure data
consistency.
● There’s no need to add an external load balancer—MongoDB ensures that each and
every user has a consistent view and quality experience with the data they need to
access.
COLLECTIONS IN THE DOCUMENT
MODEL
 Document Collection

A way to organize and store An organized store of

data as a set of field-value documents in MongoDB,
pairs in MongoDB. usually with common fields
between documents
Example
Two documents in the same collection but with different
fields

{MongoDB does not

{
"_id": ObjectId(
enforce a single
"_id": ObjectId(
"schema on a ")collection.
5f4f7fef2d4b45b7f11b6d7a ,
"5f4f7fef2d4b45b7f11b6d7a"),
Documents
"user_id": "Daniel", can have
"user_id": "Sean",
common
"age": 25, fields, but
"age": 29, they are not required
"Status": "A",
"Status": "A" to by default.
"Country": "USA"
}
}
COLLECTIONS AND SCHEMA
VALIDATION
THE DOCUMENT MODEL USED BY MONGODB CAN ENFORCE A
SCHEMA IF REQUIRED, THE RECOMMENDED APPROACH IS TO
DO SO USING JSON SCHEMA.

JSON SCHEMA

● ALLOWS A PRESCRIBED DOCUMENT STRUCTURE TO BE

CONFIGURED ON A PER COLLECTION BASIS.
● CAN TUNE SCHEMA VALIDATION ACCORDING TO USE
CASE.
● CAN BE USED BY ANY QUERY TO INSPECT DOCUMENT
STRUCTURE AND CONTENT.
 AGGREGATION AND MAP REDUCE

Aggregation Operations - MongoDB Manual v7.0

 AGGREGATION OPERATIONS
Aggregation operations process multiple documents and return computed results. You can
use aggregation operations to:
• Group values from multiple documents together
• Perform operations on the grouped data to return a single result
• Analyze data changes over time

To perform aggregation operations, you can use:

• Aggregation pipelines, which are the preferred method for performing aggregations.
• Single purpose aggregation methods, which are simple but lack the capabilities of an
aggregation pipeline.
AGGREGATION PIPELINES

• An aggregation pipeline consists of one or more stages that process

documents
• Each stage performs an operation on the input documents. For example, a
stage can filter documents, group documents, and calculate values.
• The documents that are output from a stage are passed to the next stage.
• An aggregation pipeline can return results for groups of documents. For
example, return the total, average, maximum, and minimum values.
AGGREGATION PIPELINE EXAMPLE

• The following aggregation pipeline example contains two stages and

returns the total order quantity of medium size pizzas grouped by pizza
name:
SINGLE PURPOSE AGGREGATION METHODS

• The single purpose aggregation methods aggregate documents from a

single collection. The methods are simple but lack the capabilities of
an aggregation pipeline.
MAP REDUCE

• Map-reduce is a data processing paradigm for condensing large

volumes of data into useful aggregated results.
• To perform map-reduce operations, MongoDB provides the mapReduce
database command.
 DATA
MODELING

https://www.mongodb.com/docs/manual/data-modeling/
DATA MODELING

• Data modeling refers to the organization of data within a database and the links between
related entities.
• Data in MongoDB has a flexible schema model, which means:
• Documents within a single collection are not required to have the same set of fields.
• A field's data type can differ between documents within a collection.

• The flexible data model lets you organize your data to match your application's needs.
• Use case : Your company tracks which department each employee works in. You can embed
department information inside of the employee collection to return relevant information in a single
query

• Generally, documents in a collection share a similar structure.

• To ensure consistency in your data model, you can create schema validation rules.
SCHEMA DESIGN: DIFFERENCES BETWEEN RELATIONAL AND DOCUMENT DATABASES
WHEN YOU DESIGN A SCHEMA FOR A DOCUMENT DATABASE LIKE MONGODB, THERE ARE A COUPLE OF IMPORTANT DIFFERENCES FROM RELATIONAL DATABASES TO
CONSIDER.

Relational Database Behavior Document Database Behavior

You must determine a table's schema Your schema can change over time as the
before you insert data. needs of your application change.
You often need to join data from several The flexible data model lets you store data
different tables to return the data needed to match the way your application returns
by your application. data, and avoid joins. Avoiding joins across
multiple collections improves performance
and reduces your deployment's workload.
EMBEDDED DATA MODELS

• You can embed related data in a single document.

• In the following example, the contact and access fields are embedded
documents
EMBEDDED DATA MODELS

• Embedded data models are often denormalized, because frequently-

accessed data is duplicated in multiple collections.
• Embedded data models let applications query related pieces of
information in the same database record.
• As a result, applications require fewer queries and updates to complete
common operations.
 USE CASES – EMBEDDED DATA MODELS

• Use embedded data models in the following scenarios:

• You have "contains" relationships between entities. This is one-to-one

relationship
• For example, a contacts document that contains an address.

• You have one-to-many relationships between entities.

• In these relationships, the "many" or child documents are viewed in the
context of the "one" or parent documents.

Model One-to-One Relationships with Embedded Documents - MongoDB Manual v7.0

Model One-to-Many Relationships with Embedded Documents - MongoDB Manual v7.0
ONE-TO-ONE RELATIONSHIPS WITH
EMBEDDED DOCUMENTS
ONE-TO-MANY RELATIONSHIPS WITH EMBEDDED DOCUMENTS
 REFERENCE DATA MODEL
• References store relationships between data by including links, called references,
from one document to another
• References result in normalized data models because data is divided into multiple
collections and not duplicated.
REFERENCE DATA MODEL – USE CASES

Use references to link related data in the following scenarios:

• Embedding would result in duplication of data but would not provide sufficient read performance advantages
to outweigh the implications of the duplication.
• For example, when the embedded data frequently changes.

• You need to represent complex many-to-many relationships or large hierarchical data sets.

• The related entity is frequently queried on its own. For example, if you have employee and department data,
you may consider embedding department information in the employee documents. However, if you often
query for a list of departments, your application will perform best with a separate department collection that
is linked to the employee collection with a reference.
 SCHEMA DESIGN

Schema Design Process - MongoDB Manual v7.0

SCHEMA DESIGN PROCESS

• The schema design process helps you prepare an effective schema for
your application.
• The schema design process consists of the following steps:
• Identify your workload - Identify the operations that your application
runs most frequently.
• Map relationships - Identify the relationships in your application's data
and decide whether to link or embed related data.
• Apply design patterns - Apply schema design patterns to optimize reads
and writes.
REFERENCE

• For complete content refer below link –

https://www.mongodb.com/docs/manual/