MongoDB-Theory Basics

TOPICS

1. What is MongoDB?
2. Why MongoDB?
3. JSON to BSON in MongoDB
4. What is a Replica Set?
5. ACID and BASE
6. CAP THEOREM

What is MongoDB?

MongoDB is an open-source NoSQL database developed by MongoDB Inc. It stores data in a document-oriented format using BSON (a binary version of JSON). Unlike relational databases that use rows and columns, MongoDB stores data as flexible, nested documents.

Why MangoDB?

Feature	Description
Document-Based	Stores data as JSON-like documents (internally as BSON).
NoSQL	Doesn’t use tables and rows — ideal for modern, flexible data structures.
High Performance	Fast read/write operations.
Schema-less	You don’t need to define a strict structure (schema) for data.
Scalable	Easily handles large datasets across multiple servers (horizontal scaling).
Replicated	Supports automatic failover and backup through replica sets.

1. DOCUMENT-ORIENTED MODEL

Stores data as BSON (Binary JSON) documents. Each document can have a different structure — no need to define schemas upfront. Makes it ideal for storing semi-structured or unstructured data.

JSON(You Send)

{ "createdAt": "2024-01-01T12:00:00Z" }

MangoDB Stores

{ "createdAt": ISODate("2024-01-01T12:00:00Z") }

ISODate is a BSON type, not part of plain JSON.

You write in JSON, but MongoDB automatically converts it into BSON internally for performance and data type support.

JSON to BSON in MongoDB

What Happens Internally?

When you write data to MongoDB, here's what happens:

1. You (the developer) write and send data in JSON format (or something very similar, like a JavaScript object or Python dictionary).
2. MongoDB’s driver (e.g., for Node.js, Python, Java) automatically converts this JSON into BSON before storing it in the database.
3. MongoDB stores the BSON data on disk — not JSON.
4. When you query the database:
   • BSON data is decoded back into JSON (or your language’s object format),
   • So you see it as readable JSON again.

---

Why Use BSON Instead of JSON Internally?

Because BSON:

• Is more compact and binary-friendly
• Supports extra data types like:
  • Date
  • Int32, Int64, Decimal128
  • Binary
  • ObjectId
• Is faster to parse for machines

---

What is a replica set?

A replica set is a group of MongoDB servers (usually 3 or more) that maintain the same data. It includes:

• 1 Primary node: Handles all writes and reads (unless configured otherwise).
• 1 or more Secondary nodes: Copies data from the Primary and keeps it up to date.

---

ACID VS BASE

ACID-Relational Database Model

ACID stands for Atomicity, Consistency, Isolation, and Durability. These properties ensure reliable transactions in relational databases like MySQL, PostgreSQL, Oracle, etc.

1. ATOMICITY (All or Nothing)

• A transaction is treated as a single unit.
• If any part fails, the entire transaction fails.
• No partial updates are saved.

2. CONSISTENCY (Data Validity Before and After)

• Maintains data integrity constraints (like foreign keys, unique fields).
• Ensures that database rules are followed before and after a transaction.

3. ISOLATION (Transactions Don’t Interfere)

• Allows multiple transactions to run at the same time without affecting each other.
• Results are the same as if the transactions were run one by one.

4. DURABILITY (Once Done, Always Done)

• Once a transaction is committed, it stays stored — even if power fails.
• Uses mechanisms like logs, backups, and write-ahead logging.

---

BASE :Non-Relational Database

BASE stands for Basically Available, Soft state, and Eventually consistent. These are used in NoSQL systems that need high scalability and performance, like Cassandra, DynamoDB, MongoDB, etc.

1. BASICALLY AVAILABLE (System Always Responds)

• The system always replies to user requests.
• Even during failures or high traffic, you will get a response, but it might not be the most accurate or updated data
• Ecommerce-cart(old stock)

2. SOFT STATE (Data Can Temporarily Be Wrong)

• Data is not immediately consistent, and that’s okay.
• The system may show outdated or temporary values, which will get corrected over time.

You post a photo on Instagram. On your phone, it shows instantly.
But your friend in another country may see it a few seconds later.
That delay is soft state — the system is syncing.

3. EVENTUALLY CONSISTENT(Will Be Correct Later)

• The system guarantees that all users will eventually see the same correct data — but not instantly.
• Sync happens in the background.

---

CAP THEOREM:

CAP Theorem is a concept in distributed systems — systems where data is stored across multiple servers or locations (like in cloud or NoSQL databases).

3 key properties:

1. C-Consistency
2. A-Availability
3. P-Partition Tolerence

1. CONSISTENCY (C) (All nodes show the same data.)

• Like a bank app — you always want the correct, updated balance.
• Every user sees the same data no matter which server (node) they connect to.

2. AVAILABILITY (A) (The system always responds)

• Every request gets a reply (success or failure), no error or crash.
• Even if it's showing old data, the system should not go down.

3. Partition Tolerance (Works even if communication between servers breaks

• A “partition” means a network split — some servers can’t talk to each other due to a crash, cable issue, etc.
• The system keeps running despite this.

CAP COMBINATION

Combination	What It Means	Use Case Example
CP	Consistent + Partition tolerant	System is accurate, but may be unavailable temporarily(MongoDB)
AP	Available + Partition tolerant	Always responds, but data may be inconsistent briefly(HBase)
CA	Consistent + Available	Works only when no network issues — NOT practical in real distributed systems(SQL)

When NOT to Use MongoDB

• If you require complex joins across many tables — SQL might be better.
• If data consistency and ACID-compliance are top priorities.
• For applications that require strict schema enforcement.