MongoDB Architecture & UseCases

      2 Comments on MongoDB Architecture & UseCases
banner

What is MongoDB
–MongoDB is an open source and document-oriented database that provides:
-high performance,
-high availability,
-and easy scalability,
-MongoDB works on concept of collection and document.

* Data is stored in JSON-like documents
* Dynamic schemas
* It is a No SQL database -> comes under NoSQL document-oriented  category
* It uses BSON format

 

What is JSON, BSON format & how does BSON differ from JSON
–JSON: JavaScript Object Notation (JSON) is an open, human and machine-readable standard :
that facilitates data interchange, and along with XML is the main format for data interchange used on the modern web.
-JSON supports all the basic data types: numbers, strings, and boolean values, as well as arrays and hashes.
Sample JSON:
{
item: “ABC1”,
details: {
model: “14Q3”,
manufacturer: “XYZ Company”
},
stock: [ { size: “S”, qty: 25 }, { size: “M”, qty: 50 } ],
category: “clothing”
}

JSON database: returns query results that can be easily parsed, with little or no transformation, directly by JavaScript and most popular programming languages – reducing the amount of logic you need to build into your application layer.

BSON: Binary JSON is known as BSON
– MongoDB represents JSON documents in binary-encoded format called BSON behind the scenes.
– BSON extends the JSON model to provide additional data types, ordered fields, and to be efficient for encoding and decoding within different languages.

*BSON is the binary encoding of JSON-like documents that MongoDB uses when storing documents in collections. It adds support for data types like Date and binary that aren’t supported in JSON.

* In practice, we don’t have to know much about BSON when working with MongoDB, we just need to use the native types of our language and the supplied types (e.g. ObjectId) of its driver when constructing documents and it will be mapped into the appropriate BSON type by the driver.

*By using BSON encoding on top of JSON, MongoDB gets the capability of creating indexes on top of values that resides inside the JSON document in raw format. This helps in running efficient analytical queries as NoSQL system were known for having no support for Indexes.

 

MongoDB Data Model
Data Model: Data in MongoDB has a flexible schema.documents in the same collection.
– They do not need to have the same set of fields or structure,
– and common fields in a collection’s documents may hold different types of data.
Database: is a physical container for collections. Each database gets its own set of files on the file system. A single MongoDB server typically has multiple databases.

Collection: is a group of MongoDB documents. It is the equivalent of an RDBMS table. A collection exists within a single database. Collections do not enforce a schema. Documents within a collection can have different fields. Typically, all documents in a collection are of similar or related purpose.

Document: is a set of key-value pairs. Documents have dynamic schema. Dynamic schema means that documents in the same collection do not need to have the same set of fields or structure, and common fields in a collection’s documents may hold different types of data.
Advantages of MongoDB over RDBMS:
-Schema less – MongoDB is a document database in which one collection holds different documents. Number of fields, content and size of the document can differ from one document to another.
-No complex joins.
-Ease of scale-out – MongoDB is easy to scale.
-Conversion/mapping of application objects to database objects not needed.

Relationship of RDBMS terminology with MongoDB:

RDBMS MongoDB
 Database  Database
 Table  Collection
 Tuple/Row  Document
 column  Field
 Table Join  Embedded Documents
 Primary Key  Primary Key (Default key _id provided by mongodb itself)

-sample document:
{
_id: ObjectId(587e5043357d5cde947bc6b0)
item: “ABC1”,
details: {
model: “14Q3”,
manufacturer: “XYZ Company”
},
stock: [ { size: “S”, qty: 25 }, { size: “M”, qty: 50 } ],
category: “clothing”
}

**_id is a 12 bytes hexadecimal number which assures the uniqueness of every document. we can provide _id while inserting the document. If we don’t provide then MongoDB provides a unique id for every document.
–These 12 bytes:
a)first 4 bytes for the current timestamp,
b)next 3 bytes for machine id,
c)next 2 bytes for process id of MongoDB server
d)and remaining 3 bytes are simple incremental VALUE.

 MongoDB (Applications)  Hadoop/Mapreduce/Spark (Distributed analytics)
MongoDB gives u ability to index fields  Good for longer jobs
Core differences:
-Low latency                                                  -More analytics as a batch
-Rich fast querying
-More analytics as a batch
-its highly parallel processing
 Specially good when you know the sense of data that what relations you have because we need to put them in doc   -Unknown data relation ships
 Its Great for any subset of data  -Its greate for looking at all of ur data or large subsets
– it does not give u indexing kind of structure as database does

MongoDB Architecture

Config Servers:
Very important it contains all configurations of MongoDB deployment. if the config server fails down ..then we cannot add new shards to the infrastructure.. but we can read & write in the database.

Mongos: is a scheduler. it will be the client access point. Client can be in same machine or other

Primary or Secondary Replica Sets: where actually we store the data. Write happens only in primary & then replicated to secondary for reads. Concept of primary / secondary is to have availability all the time, we call it as replicas

In a shard we have primary or secondary replica set. if any replica(seconday) fails then other secondary is there for reading and if primary itself falls then there is different primary is elected among .

Basic architecture flow:
Client gives request to Mongos . it would go to the config servers then config server will tell which of the shard has data accordingly it will request back to the mongos . Based on same mongsos will give request to corresponding Shard.. Client will perform operation on primary for writes & everything is replicated to the secondary.

2 thoughts on “MongoDB Architecture & UseCases

Leave a Reply