Introduction to MongoDB & How It Works

Core concepts and functionalities

MongoDB organizes data in a hierarchy: a MongoDB server (mongod) hosts multiple databases. Each database contains collections. Each collection holds documents — the unit of storage and retrieval.

Every document has a unique _id field (ObjectId by default). Fields are key-value pairs; values can be strings, numbers, arrays, embedded documents, dates, and more.

MongoDB provides CRUD operations, rich query filters, aggregation pipelines for analytics, indexes for speed, and replication/sharding for production resilience.

Real-life example: Think of MongoDB as a company — the server is the building, databases are departments, collections are filing cabinets, and documents are individual employee files with different optional sections.

• Database — logical namespace (e.g. rishtaara, ecommerce)
• Collection — group of documents (like a table without fixed columns)
• Document — one record, up to 16 MB, stored as BSON
• Field — name/value pair inside a document
• Index — data structure that speeds up queries (like a book index)

How MongoDB stores and retrieves data

When you insert a document, the storage engine writes BSON to disk and updates indexes. When you find with a filter, the query planner picks an index or scans the collection, then returns a cursor you iterate.

Documents in one collection can sit in the same data files but have different shapes. MongoDB does not require every document to declare the same fields upfront.

Real-life example: Storing data in MongoDB is like saving photos in an album app — each photo has id and date, but some have captions, some have location tags, and some have neither. The album (collection) still works.

// Server → database → collection → document
use rishtaara          // switch to database
db.users.insertOne({   // collection: users
  name: "Rahul",
  email: "rahul@example.com"
})
db.users.find()        // retrieve documents

Advantages over traditional RDBMS for flexible modeling

Relational models shine when every entity is uniform and JOINs are cheap at your scale. MongoDB shines when entities carry nested data (addresses, order line items, comment threads) and you want one read to return everything the UI needs.

Adding a new optional field in MongoDB is often as simple as writing it on new documents — no migration script blocking deploys. You can add JSON Schema validation later when the model stabilizes.

Real-life example: Modeling a shopping cart in SQL might need cart, cart_item, and product tables joined on every page load. In MongoDB, one cart document can embed an items array — open the cart, one query, done.

• Embed related data — fewer round trips between app and database
• Natural mapping to JSON APIs — what the client sends is what you store
• Fast iteration — prototype features without schema migration meetings
• Horizontal scaling path — sharding when single-server limits are hit
• Optional validation — add rules when flexibility should tighten