UNIT-5

What Is MongoDB?
MongoDB is a document database with the scalability and flexibility that you want with the
querying and indexing that you need.

MongoDB’s document model is simple for developers to

learn and use, while still providing all the capabilities
needed to meet the most complex requirements at any
scale. We provide drivers for 10+ languages, and the
community has built dozens more.

 The document model maps to the objects in your application code,

making data easy to work with
 Ad hoc queries, indexing, and real time aggregation provide powerful
ways to access and analyze your data
 MongoDB is a distributed database at its core, so high availability,
horizontal scaling, and geographic distribution are built in and easy to
use
 MongoDB is free to use. Versions released prior to October 16, 2018
are published under the AGPL. All versions released after October
16, 2018, including patch fixes for prior versions, are published under
the Server Side Public License (SSPL) v1.
 MongoDB stores data in flexible, JSON-like documents, meaning
fields can vary from document to document and data structure can be
changed over time

MongoDB is a source-available cross-platform document-oriented
database program. Classified as a NoSQL database program, MongoDB
uses JSON-like documents with optional schemas. MongoDB is developed
by MongoDB Inc. and licensed under the Server Side Public License (SSPL).

Main features:
Ad-hoc queriesEdit
MongoDB supports field, range query, and regular-expression searches.[28] Queries can
return specific fields of documents and also include user-defined JavaScript functions.
Queries can also be configured to return a random sample of results of a given size.
IndexingEdit
Fields in a MongoDB document can be indexed with primary and secondary indices
or index.

ReplicationEdit
MongoDB provides high availability with replica sets.[29] A replica set consists of two
or more copies of the data. Each replica-set member may act in the role of primary or
secondary replica at any time. All writes and reads are done on the primary replica by
default. Secondary replicas maintain a copy of the data of the primary using built-in
replication. When a primary replica fails, the replica set automatically conducts an
election process to determine which secondary should become the primary.
Secondaries can optionally serve read operations, but that data is only eventually
consistent by default.
If the replicated MongoDB deployment only has a single secondary member, a
separate daemon called an arbiter must be added to the set. It has a single
responsibility, which is to resolve the election of the new primary. [30] As a
consequence, an idealized distributed MongoDB deployment requires at least three
separate servers, even in the case of just one primary and one secondary. [30]
Load balancingEdit
MongoDB scales horizontally using sharding.[31] The user chooses a shard key, which
determines how the data in a collection will be distributed. The data is split into
ranges (based on the shard key) and distributed across multiple shards. (A shard is a
master with one or more replicas.). Alternatively, the shard key can be hashed to map
to a shard – enabling an even data distribution.
MongoDB can run over multiple servers, balancing the load or duplicating data to keep
the system up and running in case of hardware failure.
File storageEdit
MongoDB can be used as a file system, called GridFS, with load balancing and data
replication features over multiple machines for storing files.
This function, called grid file system,[32] is included with MongoDB drivers. MongoDB
exposes functions for file manipulation and content to developers. GridFS can be
accessed using mongofiles utility or plugins for Nginx[33] and lighttpd.[34] GridFS
divides a file into parts, or chunks, and stores each of those chunks as a separate
document.[35]
AggregationEdit
MongoDB provides three ways to perform aggregation: the aggregation pipeline, the
map-reduce function, and single-purpose aggregation methods. [36]
Map-reduce can be used for batch processing of data and aggregation operations.
But according to MongoDB's documentation, the Aggregation Pipeline provides
better performance for most aggregation operations.[37]
The aggregation framework enables users to obtain the kind of results for which
the SQL GROUP BY clause is used. Aggregation operators can be strung together to
form a pipeline – analogous to Unix pipes. The aggregation framework includes the
$lookup operator which can join documents from multiple collections, as well as
statistical operators such as standard deviation.
Server-side JavaScript executionEdit
JavaScript can be used in queries, aggregation functions (such as MapReduce), and
sent directly to the database to be executed.
Capped collectionsEdit
MongoDB supports fixed-size collections called capped collections. This type of
collection maintains insertion order and, once the specified size has been reached,
behaves like a circular queue.
TransactionsEdit
MongoDB claims to support multi-document ACID transactions since the 4.0 release
in June 2018.[38] This claim was found to not be true as MongoDB violates snapshot
isolation.
Architecture:
Programming language accessibilityEdit
MongoDB has official drivers for major programming languages and development
environments.[43] There are also a large number of unofficial or community-
supported drivers for other programming languages and frameworks.
Serverless accessEdit
Management and graphical front-endsEdit

Record insertion in MongoDB with Robomongo 0.8.5

The primary interface to the database has been the mongo shell. Since MongoDB 3.2,
MongoDB Compass is introduced as the native GUI. There are products and third-
party projects that offer user interfaces for administration and data viewing. [44]

MongoDB is designed to meet the demands of modern apps with a

technology foundation that enables you through:
  The document data model – presenting you the best way to work with
data.
 A distributed systems design – allowing you to intelligently put data
where you want it.
 A unified experience that gives you the freedom to run anywhere –
allowing you to future-proof your work and eliminate vendor lock-in.

With these capabilities, you can build an Intelligent Operational Data

Platform, underpinned by MongoDB. Download the Architecture
Guide where we dive deeper into the technology foundations of MongoDB.

Best way to work with data

 Easy: Work with data in a natural, intuitive way

 Fast: Get great performance without a lot of work
 Flexible: Adapt and make changes quickly
 Versatile: Supports a wide variety of data and queries

Put data where you need it

 Availability: Deliver globally resilient apps through sophisticated

replication and self-healing recovery
 Scalability: Grow horizontally through native sharding
 Workload Isolation: Run operational and analytical workloads in the
same cluster
 Locality: Place data on specific devices and in specific geographies
for governance, class of service, and low-latency access

Freedom to run anywhere

 Portability: Database that runs the same everywhere

 Cloud Agnostic: Leverage the benefits of a multi-cloud strategy with
no lock-in
 Global coverage: Available as a service in 50+ regions across the
major public cloud providers
Features of MongoDB
These are some important features of MongoDB:

1. Support ad hoc queries

In MongoDB, you can search by field, range query and it also supports regular expression
searches.

2. Indexing

You can index any field in a document.

3. Replication

MongoDB supports Master Slave replication.

A master can perform Reads and Writes and a Slave copies data from the master and
can only be used for reads or back up (not writes)

4. Duplication of data

MongoDB can run over multiple servers. The data is duplicated to keep the system
up and also keep its running condition in case of hardware failure.

5. Load balancing

It has an automatic load balancing configuration because of data placed in shards.

. Supports map reduce and aggregation tools.

7. Uses JavaScript instead of Procedures.

8. It is a schema-less database written in C++.

9. Provides high performance.

10. Stores files of any size easily without complicating your stack.

11. Easy to administer in the case of failures.

12. It also supports:

o JSON data model with dynamic schemas

o Auto-sharding for horizontal scalability
 o Built in replication for high availability

Now a day many companies using MongoDB to create new types of applications,
improve performance and availability.

Create Database
Use Database method:

There is no create database command in MongoDB. Actually, MongoDB do not provide any
command to create database.

It may be look like a weird concept, if you are from traditional SQL background where you
need to create a database, table and insert values in the table manually.

Here, in MongoDB you don't need to create a database manually because MongoDB
will create it automatically when you save the value into the defined collection at first
time.

How and when to create database

If there is no existing database, the following command is used to create a new
database.

Syntax:

1. use DATABASE_NAME  

If the database already exists, it will return the existing database.

Let' take an example to demonstrate how a database is created in MongoDB. In the

following example, we are going to create a database "javatpointdb".

See this example

1. >use javatpointdb  

MongoDB – Database, Collection, and

Document
 Difficulty Level : Basic
 Last Updated : 13 Aug, 2021
Databases, collections, documents are important parts of MongoDB without them you
are not able to store data on the MongoDB server. A Database contains a collection,
and a collection contains documents and the documents contain data, they are related
to each other. 

Database
In MongoDB, a database contains the collections of documents. One can create
multiple databases on the MongoDB server.  

View Database:

To see how many databases are present in your MongoDB server, write the following
statement in the mongo shell:  
show dbs
aming Restriction for Database:

Before creating a database you should first learn about the naming
restrictions for databases:  

 In MongoDB, the names of the database are case insensitive, but you
must always remember that the database names cannot differ only by the
case of the characters.
 For windows user, MongoDB database names cannot contain any of
these following characters: 
/\. "$*:|?
 For Unix and Linux users, MongoDB database names cannot contain any
of these following characters: 
/\. "$
 MongoDB database names cannot contain null characters(in windows,
Unix, and Linux systems).
 MongoDB database names cannot be empty and must contain less than
64 characters. 

Creating Database:

In the mongo shell, you can create a database with the help of the following
command:  
use database_name
This command actually switches you to the new database if the given name
does not exist and if the given name exists, then it will switch you to the
existing database. Now at this stage, if you use the show command to see
the database list where you will find that your new database is not present in
that database list because, in MongoDB, the database is actually created
when you start entering data in that database.
Collections: 
Collections are just like tables in relational databases, they also store data,
but in the form of documents. A single database is allowed to store multiple
collections.  

Schemaless:

As we know that MongoDB databases are schemaless. So, it is not

necessary in a collection that the schema of one document is similar to
another document. Or in other words, a single collection contains different
types of documents like as shown in the below example where
mystudentData collection contain two different types of documents: 

Naming Restrictions for Collection:

Before creating a collection you should first learn about the naming
restrictions for collections: 
 Collection name must starts with an underscore or a character.
 Collection name does not contain $, empty string, null character and does
not begin with system. prefix.
 The maximum length of the collection name is 120 bytes(including the
database name, dot separator, and the collection name).

Creating collection:

After creating database now we create a collection to store documents. The

collection is created using the following syntax: 
db.collection_name.insertOne({..})
Here, insertOne() function is used to store single data in the specified
collection. And in the curly braces {} we store our data or in other words, it is
a document. 
Document
In MongoDB, the data records are stored as BSON documents. Here, BSON
stands for binary representation of JSON documents, although BSON
contains more data types as compared to JSON. The document is created
using field-value pairs or key-value pairs and the value of the field can be of
any BSON type. 
Syntax:  
{
field1: value1
field2: value2
....
fieldN: valueN
}

Naming restriction of fields:

Before moving further first you should learn about the naming restrictions for
fields: 
 The field names are of strings.
 The _id field name is reserved to use as a primary key. And the value of
this field must be unique, immutable, and can be of any type other than
an array.
 The field name cannot contain null characters.
 The top-level field names should not start with a dollar sign ($).
Document Size: The maximum size of the BSON document is 16MB. It
ensures that the single document does not use too much amount of RAM or
bandwidth(during transmission). If a document contains more data than the
specified size, then MongoDB provides a GridFS API to store such type of
documents. 
Important Notes –  
 A single document may contain duplicate fields.
 MongoDB always saves the order of the fields in the documents except
for the _id field (which always comes in the first place) and the renaming
of fields may change the order of the fields in the documents.
 _id Field: In MongoDB, every document store in the collection must
contain a unique _id field it is just like a primary key in a relational
database. The value of the _id field can be set by the user or by the
 system (if the user does not create an _id field, then the system will
automatically generate an ObjectId for _id field). 
 When you create a collection MongoDB automatically creates a
unique index on the _id field.
 The _id field is the first field of every document.
 The value of the _id field can be of any BSON type except
arrays.
 The default value of the _id field is ObjectId.

Application Deployment
MongoDB Realm uses a deployment-based versioning scheme that allows you to
group updates to your application and make them available to client applications at
the same time. You can deploy a new version of your application with multiple
deployment methods that each fit a particular development workflow. You can also
review the historical state of your application based on the built-in deployment history
log.

Deployment Methods

You can deploy new versions of your application through the Realm UI or one of multiple
code-based deployment methods that each suit a particular development workflow.

Deployment Method Details

Realm UI Use This Method If:

You want to use a browser-based GUI to develop and manage your Realm app.

Deployment Pattern

For a detailed walkthrough, see Deploy from the Realm UI

1. Make changes in the UI that are saved in a draft state and not visible to client apps.
2. Review all draft changes and then deploy them together through the Realm UI.

Automatic GitHub Use This Method If:

Deployment
You want to use a code-first approach to app development.
You want to use Git to version control your app.
You want to automatically deploy changes when you push to GitHub.

Deployment Pattern
 Deployment Method Details

For a detailed walkthrough, see Deploy Automatically with GitHub

1. Host your exported application repository on GitHub.

2. Add, remove, or modify configuration files in a local clone of the repository to specify yo
updated application.
3. When you've made all the changes that you want to, commit them and push the change
GitHub.

realm-cli Use This Method If:

You want to use a code-first approach to app development.

You want to use a command line interface to manage and deploy your Realm app.

Deployment Pattern

For a detailed walkthrough, see Deploy Changes with Realm CLI

1. Export a copy of your application to a directory of configuration files and download it to

computer.
2. Add, remove, or modify configuration files in the directory to specify your updated appl
3. When you've made all the changes that you want to, manually deploy them by importin
updated application directory.

Realm Admin API Use This Method If:

You want to use a code-first approach to app development.

You want to use an HTTP API to manage and deploy your Realm app.

Deployment Pattern

For a detailed walkthrough, see Draft and Deploy a Group of Changes

1. Create a new draft deployment through the API.

2. Add, remove, or modify components of your application by calling relevant HTTP endpo
3. When you've made all the changes that you want to, deploy the draft through the API.

Application Components

Realm apps are composed of components like Functions, Triggers, Auth Providers,

and Values. A deployment consist of at least one new, updated, or deleted component.
Configuration Files

MongoDB Realm uses configuration files to define your application's metadata and

components. Every component is defined by its own configuration file and each type of
component uses a distinct configuration file schema. The Realm UI manages your
application's configuration files for you, but you can also use a code-based deployment
method to update your application by adding, modifying, and deleting configuration files
directly.

Application Directory

Realm apps are structured in a nested directory format called an application directory that
contains configuration files for your application components. The configuration files are
grouped into directories based on their component type. You can download a copy of the
application directory for the most recently deployed version of an app by exporting it from
the Realm UI or  realm-cli , or by cloning the underlying Git repository.

For additional information on the structure of an application directory as well as the schema
of each configuration file type, see Realm Application Configuration.

Deployment History

MongoDB Realm logs every deployment of an application and exposes a list of the
25 most recent deployments in the History tab of the Deploy in the Realm UI. Each
deployment log includes data about a set of changes, such as their status, origin,
and time of deployment.

If you choose to deploy through the Realm UI, any changes you make are grouped
in a row at the top of the deployment history table that represents draft changes
made since the previous deployment. You can use the Action buttons on this row to
manually deploy all draft changes.

The Deployment History is also where you can Export your Realm app, or use

the Re-Deploy button to rollback to a prior version.

Deployment Using Cloud Platforms:

Cloud deployment refers to the enablement of SaaS (software as a

service), PaaS (platform as a service) or IaaS (infrastructure as a
service) solutions that may be accessed on demand by end users or
consumers. A cloud deployment model refers to the type of cloud
computing architecture a cloud solution will be implemented on. Cloud
deployment includes all of the required installation and configuration
steps that must be implemented before user provisioning can occur.
SAAS DEPLOYMENT & CLOUD DEPLOYMENT MODELS

Cloud deployment can be viewed from the angle of management responsibility for
the deployment of the SaaS, PaaS and/or IaaS solutions in question. From this
perspective, there are two possible approaches: the cloud solution(s) may be
deployed by a third party (under a community cloud, public cloud or private cloud
deployment model) or the cloud solution(s) may be deployed by a single entity
(under a private cloud deployment model).

SaaS deployment is a type of cloud deployment that is typically initiated using a

public cloud or a private cloud deployment model, however SaaS deployment may
also be initiated using a hybrid cloud deployment model, when hybrid cloud
resources are owned and/or managed by the same entity. Expanding on this theme
is the existence of virtual private clouds that can be used for SaaS deployment as
well. Virtual private clouds are technically public clouds that function the same as
private clouds, since only trusted entities may gain access to the virtual private cloud
resources.

Regardless of whether or not a SaaS solution is deployed in a public cloud, a private

cloud , a virtual private cloud or a hybrid cloud; many SaaS solutions provide
automatic deployment for the cloud services being delivered. SaaS deployment
provides many additional benefits over the traditional model of software deployment,
including scalability, where application users can be added or subtracted on demand
without concerns over capital investments in additional hardware or software. SaaS
deployment also provides above average up-time for enterprise applications as
compared to on premise software deployment.

After cloud deployment has been completed for a SaaS, PaaS or IaaS solution, user
provisioning can occur based on user permissions, where access is provided for
cloud resources based on the consumer’s classification as either a trusted or
untrusted entity. Trusted entities may receive access permission to managed cloud,
private cloud or hybrid cloud resources. Untrusted entities may receive access
permission to public cloud, managed cloud or hybrid cloud resources. The key
difference between trusted and untrusted entities is that untrusted entities never
receive access permission to private cloud resources.