Topics Covered

Unit 5 – NoSQL Databases Page 1

 CHAPTER 1 : Introduction to NoSQL
Databases

1.1 What is NoSQL?

NoSQL (Not Only SQL) refers to a broad class of database management systems that differ from
classical relational databases. They are designed to handle large volumes of unstructured,
semi-structured, or structured data and are optimized for horizontal scalability, high availability, and
flexible schema design.

Key Idea: NoSQL databases were created to address the limitations of relational databases
when dealing with big data, real-time web applications, and distributed systems.

1.1.1 History and Evolution

• 1998: Carlo Strozzi used the term 'NoSQL' for a relational database that didn't use SQL.
• 2009: Eric Evans reintroduced 'NoSQL' for non-relational distributed databases.
• Driven by companies like Google (BigTable), Amazon (Dynamo), Facebook (Cassandra).
• Rise of Web 2.0 and social media created need for scalable, flexible databases.

1.2 Limitations of RDBMS That Led to NoSQL

Limitation Explanation

Rigid Schema Relational databases require predefined schemas; changing structure is costly.

Vertical Scaling Only RDBMS scales up (more powerful hardware), not out (more servers).

Poor with Unstructured Data Cannot efficiently handle JSON, XML, images, videos, logs.

Joins are Expensive Complex joins across large datasets become performance bottlenecks.

High Volume Performance RDBMS struggles with millions of read/write operations per second.

High Availability Master-slave setups complicate achieving true high availability.

1.3 Advantages of NoSQL Databases

• Schema Flexibility: Dynamic schema allows adding fields without restructuring the entire
database.
• Horizontal Scalability: Scale out by adding commodity servers (sharding).
• High Performance: Optimized for specific data access patterns with low latency.
• High Availability: Built-in replication and automatic failover.
• Big Data Ready: Designed to handle petabytes of data across distributed clusters.
• Variety of Data Models: Key-value, document, column-family, graph – choose what fits.
• Open Source: Most NoSQL databases are free and community-supported.
• Cloud Native: Easily deployed on cloud platforms with auto-scaling.

1.4 Disadvantages of NoSQL Databases

Unit 5 – NoSQL Databases Page 2

 • No ACID guarantees (mostly): Most NoSQL systems sacrifice full ACID for performance.
• Limited querying: No universal query language like SQL; each system has its own API.
• Maturity: Some NoSQL systems are newer with less tooling and community support.
• Consistency issues: Eventual consistency can lead to stale reads.
• No standardization: Moving between NoSQL systems requires learning new APIs.
• Limited JOIN support: Complex relationships must be handled in application code.

1.5 When to Use NoSQL?

Use NoSQL when:

• Data is unstructured or semi-structured (social posts, logs, sensor data)

• Application needs massive horizontal scaling

• Rapid development with changing requirements (agile)

• Real-time analytics on large datasets

• Content management, catalogs, e-commerce with variable attributes

Unit 5 – NoSQL Databases Page 3

 CHAPTER 2 : NoSQL Data Models

2.1 Overview of NoSQL Data Models

NoSQL databases are categorized by their data model. The four primary data models are:
Key-Value, Document, Column-Family (Wide Column), and Graph. Each is optimized for
different use cases.

2.2 Key-Value Store

Definition: Simplest NoSQL model. Data stored as key-value pairs, like a dictionary or hash
map.

• Structure: {Key → Value} where value can be string, JSON, binary, etc.
• Examples: Redis, Amazon DynamoDB, Riak, Memcached
• Operations: PUT(key, value), GET(key), DELETE(key)

Characteristics:
• Extremely fast lookups by key (O(1) hash-based access).
• No schema – value is opaque to database.
• No complex querying – cannot query on value contents.
• Ideal for caching, session management, shopping carts.

Example:
Key: "user:1001"
Value: {"name":"Rahul","age":25,"city":"Pune"}

Use Cases: Session stores, leaderboards, real-time bidding, caching layers, user
preferences.

2.3 Document Store

Definition: Stores data as documents (usually JSON/BSON/XML). Each document is

self-describing and can have a different structure.

• Examples: MongoDB, CouchDB, Amazon DocumentDB, Firestore

• Document Format: JSON (JavaScript Object Notation) or BSON (Binary JSON)
• Flexible Schema: Documents in the same collection can have different fields.
• Querying: Can query on any field within the document.
• Nesting: Supports embedded documents and arrays.

Example Document (MongoDB):

{
"_id": ObjectId("507f191e"),
"name": "Priya Sharma",
"age": 22,
"address": { "city": "Mumbai", "pin": "400001" },
"courses": ["DBMS", "OS", "CN"]
}

Unit 5 – NoSQL Databases Page 4

 Use Cases: Content management, e-commerce catalogs, user profiles, blogging platforms,
real-time analytics.

2.4 Column-Family (Wide Column) Store

Definition: Data stored in tables with rows and dynamic columns, grouped into column
families. Rows can have different columns.

• Examples: Apache Cassandra, HBase, Google Bigtable, ScyllaDB

• Column Family: A logical grouping of related columns stored together on disk.
• Row Key: Each row identified by a unique row key for fast access.
• Sparse Data: Missing columns take no storage – efficient for sparse datasets.
• Sorted: Data sorted by row key enabling efficient range scans.

Structure Example (Cassandra):

Row Key col:name col:age col:email col:phone

user001 Amit 28 amit@[Link] —

user002 Sneha — sneha@[Link] 9876543210

user003 Raj 30 — —

Use Cases: IoT sensor data, time-series data, event logging, recommendation engines,
financial data.

2.5 Graph Database

Definition: Stores data as nodes (entities) and edges (relationships). Optimized for traversing
relationships.

• Examples: Neo4j, Amazon Neptune, ArangoDB, JanusGraph

• Nodes: Represent entities (Person, Product, City).
• Edges: Represent relationships (FOLLOWS, PURCHASED, LIVES_IN).
• Properties: Both nodes and edges can have key-value properties.
• Traversal: Highly efficient for relationship queries (friend-of-a-friend, shortest path).
• Query Language: Cypher (Neo4j), Gremlin, SPARQL.

Example (Neo4j Cypher):

(Rahul:Person)-[:FOLLOWS]->(Priya:Person)
(Priya:Person)-[:LIVES_IN]->(Mumbai:City)
MATCH (p:Person)-[:FOLLOWS*2]->(fof) WHERE [Link]="Rahul" RETURN fof

Use Cases: Social networks, fraud detection, knowledge graphs, recommendation systems,
route optimization.

2.6 Comparison of NoSQL Data Models

Attribute Key-Value Document Column-Family Graph

Unit 5 – NoSQL Databases Page 5

 Data Format KV Pairs JSON/BSON Column Fam. Nodes+Edges

Schema None Flexible Semi-fixed None

Query Power Low Medium Medium High (graph)

Scalability Very High High Very High Medium

Relationships None Embedded None Native

Best For Cache/Session Content/Profile Time-series Social/Network

Example DB Redis MongoDB Cassandra Neo4j

Unit 5 – NoSQL Databases Page 6

 CHAPTER 3 : CAP Theorem & BASE
Properties

3.1 CAP Theorem

The CAP Theorem (also called Brewer's Theorem) was proposed by Eric Brewer in 2000 and
formally proven by Gilbert and Lynch in 2002. It states that a distributed data store can guarantee at
most two out of three properties simultaneously:

Property Symbol Description

Consistency Every
C read receives the most recent write or an error. All nodes see the same data at the same time.

Availability Every
A request receives a response (not necessarily the latest data). System remains operational.

Partition
P System continues to operate despite network partitions (message loss between nodes).
Tolerance

Key Insight: In a distributed system, network partitions WILL occur. Therefore, the practical
choice is between Consistency (CP) and Availability (AP). You cannot have all three
simultaneously.

3.1.1 CAP Categories of Databases

Category Guarantee Examples Explanation

Traditional RDBMS
CA C + A (no P) Consistent & Available but cannot handle partitions. Only for single-node systems.
(MySQL, PostgreSQL)

MongoDB, HBase,
CP C + P (no A) Consistent & Partition-tolerant but may return errors during partitions.
ZooKeeper, Redis

Cassandra, CouchDB,
AP A + P (no C) Available & Partition-tolerant but may return stale/inconsistent data.
DynamoDB, Riak

3.1.2 Real-World Examples of CAP Trade-offs

• Bank Transfer System (CP): Must be consistent – never show wrong balance, even if
unavailable briefly.
• Social Media Feed (AP): It's okay to see slightly stale posts; availability is more important.
• DNS System (AP): DNS prefers availability – may return cached (old) IP rather than failing.
• Google Spanner (tries CA+P): Uses TrueTime API for globally consistent distributed
transactions.

3.2 ACID Properties (Traditional RDBMS)

ACID stands for Atomicity, Consistency, Isolation, Durability – the gold standard for transaction
reliability in relational databases.

Property Meaning Example

Unit 5 – NoSQL Databases Page 7

 Atomicity
Transaction is all-or-nothing. Either all operations complete
Bankor transfer:
none. debit + credit both succeed or both fail.

Consistency
Transaction brings DB from one valid state to another, respecting
Balance
all rules.
cannot go negative after transaction.

IsolationConcurrent transactions execute as if sequential; no interference.

Two users withdrawing simultaneously don't interfere.

Durability Once committed, data persists even after system crashes.

Committed transaction survives power failure.

3.3 BASE Properties (NoSQL)

BASE is the alternative to ACID for NoSQL distributed systems. Coined by Eric Brewer, BASE
trades strict consistency for availability and performance.

BASE = Basically Available + Soft State + Eventually Consistent

Property Full Name Explanation

Basically
System guarantees
Available availability
BA(per CAP). Partial failures are tolerated; system responds to every request even if some data is

Soft State State of the system

S may change over time, even without input, due to eventual consistency propagation across n

Eventually Consistent
The system will become
E consistent over time. All replicas will converge to the same value eventually, though not imm

3.3.1 Eventual Consistency – Explained

Eventual consistency means that if no new updates are made, eventually all replicas will return the
same value. This is acceptable in many real-world scenarios:
• Your Twitter feed shows a slightly different count of likes than another user sees – eventually
both converge.
• DNS record updates propagate across servers over minutes, not instantly.
• Shopping cart in Amazon may temporarily show different items across sessions.

3.4 ACID vs BASE Comparison

Aspect ACID BASE

Consistency Strong (immediate) Eventual (over time)

Availability May sacrifice for C High priority

Transactions Full ACID transactions Limited/no transactions

Best For Financial, critical data Big data, web-scale apps

Examples MySQL, PostgreSQL, Oracle Cassandra, DynamoDB, MongoDB

Performance Lower (due to locks) Higher (no strict locks)

Scalability Vertical Horizontal

Unit 5 – NoSQL Databases Page 8

 CHAPTER 4 : Comparative Study – SQL vs
NoSQL

4.1 Detailed Comparison Table

Parameter SQL (Relational) NoSQL (Non-Relational)

Full Form Structured Query Language Not Only SQL

Data Model Tables with rows & columns Documents, K-V, Graphs, Columns

Schema Fixed, predefined schema Dynamic, flexible schema

Scalability Vertical (scale up) Horizontal (scale out)

Query Language SQL (standardized) DB-specific (MQL, CQL, Cypher)

ACID Compliance Full ACID BASE (partial ACID in some)

Joins Supports complex joins No joins (denormalization used)

Relationships Foreign keys & joins Embedded documents / references

Performance Slower for big unstructured data High speed for specific patterns

Consistency Strong consistency Eventual consistency (mostly)

Transactions Full multi-table transactions Limited transaction support

Data Types Structured data only Structured, semi, unstructured

Examples MySQL, PostgreSQL, Oracle, SQL Server MongoDB, Cassandra, Redis, Neo4j

Maturity Decades old, very mature Relatively newer

Community/Support Large, enterprise-grade Growing, active communities

Best Use Case OLTP, ERP, CRM, banking Big data, real-time web, IoT

Cost Often licensed (Oracle expensive) Mostly open-source/free

4.2 When to Choose SQL vs NoSQL

Choose SQL When… Choose NoSQL When…

Data is highly structured and relational Data is unstructured, semi-structured

Complex queries with multiple joins needed Simple, high-speed access patterns

Strong ACID transactions required Eventual consistency is acceptable

Data model is stable and well-defined Schema changes frequently (agile dev)

Financial, ERP, legacy systems Social media, IoT, real-time analytics

Medium data volume (GBs) Massive data volume (TBs to PBs)

Unit 5 – NoSQL Databases Page 9

 Reporting and analytics (OLAP) Horizontal scaling to many servers

4.3 Popular Database Examples

Database Type Category Key Feature

MySQL Relational SQL Open-source, LAMP stack staple

PostgreSQL Relational SQL Advanced ACID, JSON support

Oracle DB Relational SQL Enterprise grade, PL/SQL

MongoDB Document NoSQL JSON-like BSON, Atlas cloud

Cassandra Column-Family NoSQL High write throughput, peer-to-peer

Redis Key-Value NoSQL In-memory, sub-millisecond latency

Neo4j Graph NoSQL Cypher query, social graphs

DynamoDB Key-Value/Doc NoSQL AWS managed, serverless scaling

HBase Column-Family NoSQL Hadoop ecosystem, HDFS storage

CouchDB Document NoSQL HTTP/REST API, offline-first

Unit 5 – NoSQL Databases Page 10

 CHAPTER 5 : MongoDB – CRUD Operations

5.1 Introduction to MongoDB

MongoDB is a leading open-source document-oriented NoSQL database. It stores data in
flexible, JSON-like documents (BSON – Binary JSON). Developed by MongoDB Inc., it is widely
used for web applications, mobile apps, and real-time analytics.

• Database: Logical container of collections (≈ schema in RDBMS).

• Collection: Group of MongoDB documents (≈ table in RDBMS).
• Document: A JSON/BSON record (≈ row in RDBMS).
• Field: A key-value pair in a document (≈ column in RDBMS).
• _id: Auto-generated unique identifier for each document (ObjectId).

RDBMS MongoDB

Database Database

Table Collection

Row / Record Document

Column Field

Primary Key _id

JOIN $lookup (Aggregation) / Embedded Documents

Index Index

View View

5.2 CREATE Operations – insertOne() & insertMany()

Create operations add new documents to a collection. If the collection does not exist, MongoDB
creates it automatically.

5.2.1 insertOne() – Insert a Single Document

[Link]({
name: "Rahul Patil",
age: 20,
branch: "Computer Engineering",
marks: 85,
address: { city: "Pune", pin: "411001" },
subjects: ["DBMS", "OS", "CN"]
})

5.2.2 insertMany() – Insert Multiple Documents

[Link]([
{ name: 'Priya', age: 21, marks: 90 },
{ name: 'Amit', age: 22, marks: 78 },
{ name: 'Sneha', age: 20, marks: 92 }

Unit 5 – NoSQL Databases Page 11

 ])

Note: MongoDB auto-assigns a unique _id (ObjectId) to each document if not specified.
ObjectId = 12-byte value (4-byte timestamp + 5-byte random + 3-byte counter).

5.3 READ Operations – find() & findOne()

Read operations query and retrieve documents from collections using query filters.

5.3.1 find() – Retrieve Multiple Documents

[Link]() // All documents
[Link]({ branch: 'CE' }) // Filter by branch
[Link]({ marks: { $gt: 80 } }) // marks > 80
[Link]({}, { name:1, marks:1, _id:0 }) // Projection

5.3.2 findOne() – Retrieve First Matching Document

[Link]({ name: 'Rahul Patil' })

5.3.3 Query Operators (Comparison)

Operator Meaning Example

$eq Equal to { age: { $eq: 20 } }

$ne Not equal to { age: { $ne: 20 } }

$gt Greater than { marks: { $gt: 80 } }

$gte Greater than or equal { marks: { $gte: 80 } }

$lt Less than { marks: { $lt: 60 } }

$lte Less than or equal { marks: { $lte: 60 } }

$in In an array { city: { $in: ['Pune','Mumbai'] } }

$nin Not in array { city: { $nin: ['Delhi'] } }

5.3.4 Logical Operators

[Link]({ $and: [{ age: {$gt:18} }, { marks: {$gte:80} }] })
[Link]({ $or: [{ branch:'CE' }, { marks: {$gt:90} }] })
[Link]({ marks: { $not: { $lt: 50 } } })

5.3.5 Cursor Methods

[Link]().sort({ marks: -1 }) // Sort descending
[Link]().limit(5) // First 5 docs
[Link]().skip(10).limit(5) // Pagination
[Link]().count() // Count documents

5.4 UPDATE Operations – updateOne(), updateMany(), replaceOne()

Update operations modify existing documents. MongoDB provides update operators to change
specific fields without replacing the entire document.

Unit 5 – NoSQL Databases Page 12

 5.4.1 updateOne() – Update First Matching Document
[Link](
{ name: 'Rahul Patil' }, // filter
{ $set: { marks: 92 } } // update operator
)

5.4.2 updateMany() – Update All Matching Documents

[Link](
{ branch: 'CE' },
{ $inc: { marks: 5 } } // Increment marks by 5
)

5.4.3 Update Operators

Operator Purpose Example

$set Set a field value { $set: { age: 25 } }

$unset Remove a field { $unset: { phone: '' } }

$inc Increment/decrement a field { $inc: { marks: 5 } }

$mul Multiply field value { $mul: { salary: 1.1 } }

$rename Rename a field { $rename: { 'nm': 'name' } }

$push Add to array { $push: { subjects: 'AI' } }

$pull Remove from array { $pull: { subjects: 'OS' } }

$addToSet Add to array (no duplicates) { $addToSet: { tags: 'new' } }

$pop Remove first/last array element { $pop: { items: 1 } }

upsert Insert if no match found { upsert: true } in options

5.4.4 replaceOne() – Replace Entire Document

[Link](
{ name: 'Amit' },
{ name: 'Amit Sharma', age: 23, marks: 88 } // new doc
)

5.5 DELETE Operations – deleteOne() & deleteMany()

5.5.1 deleteOne() – Delete First Matching Document

[Link]({ name: 'Rahul Patil' })

5.5.2 deleteMany() – Delete All Matching Documents

[Link]({ marks: { $lt: 40 } }) // Delete failing
[Link]({}) // Delete ALL documents (careful!)

5.5.3 drop() – Remove Entire Collection

[Link]() // Removes the entire collection + indexes

Unit 5 – NoSQL Databases Page 13

 5.6 CRUD Summary Table

Operation Method(s) SQL Equivalent

Create insertOne(), insertMany() INSERT INTO

Read find(), findOne() SELECT

Update updateOne(), updateMany(), replaceOne() UPDATE

Delete deleteOne(), deleteMany(), drop() DELETE / DROP TABLE

Unit 5 – NoSQL Databases Page 14

 CHAPTER 6 : MongoDB – Indexing &
Aggregation

6.1 Indexing in MongoDB

An index is a special data structure that stores a small portion of a collection's data in an
easy-to-traverse form. Without indexes, MongoDB performs a collection scan (reads every
document). Indexes dramatically improve query performance.

Analogy: An index in MongoDB is like the index at the back of a textbook – instead of reading
every page to find a topic, you jump directly to the page number.

6.1.1 Default Index – _id

• Every MongoDB collection has a default index on the _id field.
• This index is unique and cannot be dropped.

6.1.2 Single Field Index

[Link]({ marks: 1 }) // 1 = ascending
[Link]({ marks: -1 }) // -1 = descending

6.1.3 Compound Index (Multiple Fields)

[Link]({ branch: 1, marks: -1 })
Creates index on branch (ascending) and marks (descending). Supports queries filtering/sorting on
both fields.

6.1.4 Unique Index

[Link]({ email: 1 }, { unique: true })
Ensures no two documents have the same value for the indexed field.

6.1.5 Text Index – Full Text Search

[Link]({ content: 'text', title: 'text' })
[Link]({ $text: { $search: 'MongoDB NoSQL' } })
Only ONE text index per collection. Supports keyword search with stemming and stop-word
removal.

6.1.6 Sparse Index

[Link]({ phone: 1 }, { sparse: true })
Only indexes documents where the field exists. Saves space when many documents lack the field.

6.1.7 TTL Index (Time To Live)

[Link]({ createdAt: 1 }, { expireAfterSeconds: 3600 })
Automatically deletes documents after specified time. Used for session data, caches, logs.

6.1.8 Geospatial Index

[Link]({ location: '2dsphere' })
Supports queries on GeoJSON data – find nearby places, within a polygon, etc.

Unit 5 – NoSQL Databases Page 15

 6.1.9 Managing Indexes
[Link]() // List all indexes
[Link]('marks_1') // Drop specific index
[Link]() // Drop all non-_id indexes

6.1.10 explain() – Query Performance Analysis

[Link]({ marks: { $gt: 80 } }).explain('executionStats')
Shows execution plan: whether index was used (IXSCAN) or full scan (COLLSCAN), documents
examined, time taken.

Index Type Syntax Use Case

Single Field createIndex({ field: 1 }) Queries on one field

Compound createIndex({ f1:1, f2:-1 }) Multi-field queries

Unique createIndex({}, { unique:true }) Email, username uniqueness

Text createIndex({ field: 'text' }) Full-text search

Sparse createIndex({}, { sparse:true }) Optional fields

TTL { expireAfterSeconds: N } Auto-expiring data

Geospatial createIndex({ loc: '2dsphere' }) Location queries

Hashed createIndex({ _id: 'hashed' }) Hash-based sharding

6.2 Aggregation in MongoDB

Aggregation operations process multiple documents and return computed results. MongoDB's
Aggregation Pipeline is the primary mechanism – documents pass through a series of stages,
each transforming the data.

Aggregation Pipeline: Input → [Stage 1] → [Stage 2] → … → [Stage N] → Output

Each stage receives documents from the previous stage and passes results to the next.

6.2.1 Core Pipeline Stages

Stage Purpose SQL Equivalent

$match Filter documents (like WHERE clause) WHERE

$group Group by field and apply accumulators GROUP BY

$project Include/exclude/compute fields SELECT

$sort Sort documents ORDER BY

$limit Limit number of output documents LIMIT

$skip Skip N documents OFFSET

$unwind Deconstruct an array field to documents Normalize

Unit 5 – NoSQL Databases Page 16

 $lookup Left outer join with another collection LEFT JOIN

$count Count of documents COUNT(*)

$addFields Add new computed fields AS (computed column)

$out Write results to a collection SELECT INTO

$facet Multiple pipelines in one aggregation CUBE/ROLLUP

6.2.2 $match – Filtering Documents

[Link]([
{ $match: { branch: 'CE', marks: { $gte: 75 } } }
])

6.2.3 $group – Grouping and Aggregating

[Link]([
{ $group: {
_id: '$branch',
avgMarks: { $avg: '$marks' },
totalStudents: { $sum: 1 },
maxMarks: { $max: '$marks' },
minMarks: { $min: '$marks' }
}}
])

6.2.4 $project – Shaping Output

[Link]([
{ $project: {
name: 1, marks: 1, _id: 0,
grade: { $cond: { if: {$gte:['$marks',75]}, then:'A', else:'B' } }
}}
])

6.2.5 Multi-Stage Pipeline Example

Find average marks per branch for students scoring above 60, sorted descending, top 3 branches:
[Link]([
{ $match: { marks: { $gt: 60 } } },
{ $group: { _id: '$branch', avgMarks: { $avg: '$marks' } } },
{ $sort: { avgMarks: -1 } },
{ $limit: 3 }
])

6.2.6 $lookup – JOIN Between Collections

[Link]([
{ $lookup: {
from: 'customers',
localField: 'customer_id',
foreignField: '_id',
as: 'customerInfo'
}}
])

Unit 5 – NoSQL Databases Page 17

 6.2.7 $unwind – Flatten Arrays
// If subjects: ['DBMS', 'OS', 'CN']
[Link]([
{ $unwind: '$subjects' }
])
Creates one document per array element – each student gets three rows, one per subject.

6.2.8 Accumulator Operators in $group

Accumulator Description Example

$sum Sum of values { $sum: '$marks' }

$avg Average of values { $avg: '$marks' }

$max Maximum value { $max: '$marks' }

$min Minimum value { $min: '$marks' }

$count Count of documents { $count: {} }

$first First value in group { $first: '$name' }

$last Last value in group { $last: '$name' }

$push Array of all values { $push: '$name' }

$addToSet Array of unique values { $addToSet: '$branch' }

6.2.9 MapReduce (Legacy Alternative)

MongoDB also supports MapReduce, though aggregation pipeline is preferred for most tasks.
[Link](
function() { emit([Link], [Link]); }, // Map
function(key, values) { return [Link](values); }, // Reduce
{ out: 'branch_avg_marks' }
)

Unit 5 – NoSQL Databases Page 18

 IMPORTANT QUESTIONS & ANSWERS (8 Marks Each)

Q1: What is NoSQL? Explain the characteristics, advantages, and

disadvantages of NoSQL databases with examples.

Answer:
Introduction to NoSQL:
NoSQL (Not Only SQL) databases are non-relational database management systems designed to
handle large-scale, distributed, and unstructured data efficiently. They emerged around 2009 to
address the scalability and flexibility limitations of traditional relational databases, driven by the
requirements of Web 2.0 companies like Google, Amazon, and Facebook.

Key Characteristics of NoSQL Databases:

• Schema-less / Schema-flexible: Documents in a collection can have different fields. No need to
define structure upfront. Fields can be added dynamically without altering the whole table.
• Horizontal Scalability (Scale-Out): NoSQL databases scale by adding more commodity
servers (sharding) rather than upgrading a single powerful server. This makes them
cost-effective for massive data.
• High Availability: Built-in replication across multiple nodes ensures that if one node fails, others
continue serving requests without downtime.
• Distributed Architecture: Data is distributed across multiple servers/data centers, often
globally, using techniques like consistent hashing.
• BASE instead of ACID: Most NoSQL systems follow BASE (Basically Available, Soft state,
Eventually consistent) rather than strict ACID properties.
• Variety of Data Models: Supports Key-Value, Document, Column-Family, and Graph models –
choose based on use case.
• High Performance: Optimized for specific access patterns; avoids expensive joins and
normalization overhead.
Advantages:
• Handles Big Data (TBs to PBs) efficiently with distributed architecture.
• Flexible schema allows rapid iteration and agile development.
• High read/write throughput – suitable for millions of operations/second.
• Lower cost using commodity hardware vs expensive enterprise servers.
• Natively handles JSON/XML/multimedia – rich data types.
Disadvantages:
• No standard query language – each system has proprietary API.
• Limited ACID transactions – not ideal for financial systems.
• Eventual consistency may return stale data temporarily.
• Less mature tooling compared to decades-old RDBMS.
• Complex joins must be handled in application code.
Examples: MongoDB (document), Cassandra (column), Redis (key-value), Neo4j (graph),
DynamoDB (key-value/document).

Q2: Explain the four types of NoSQL data models with their structure,
examples, and suitable use cases.

Unit 5 – NoSQL Databases Page 19

 Answer:
NoSQL databases are classified into four primary data models based on how they organize and
store data:

1. Key-Value Store:
The simplest NoSQL model. Data is stored as key-value pairs like a dictionary/hash map. The key
is a unique identifier and the value can be any data type – string, number, JSON, binary blob.
• Structure: KEY → VALUE
• Example: "user:1001" → {"name":"Rahul", "age":25}
• Databases: Redis, Amazon DynamoDB, Riak, Memcached.
• Use Cases: Session management, caching, user preferences, leaderboards, shopping carts.
• Advantage: O(1) lookup speed; extremely fast for simple get/set operations.
• Limitation: Cannot query on value content; no complex querying.
2. Document Store:
Stores semi-structured data as documents (JSON/BSON/XML). Documents are self-describing and
can have nested structures and arrays. Documents in the same collection can have different fields.
• Structure: Collection → Documents (JSON objects with nested fields and arrays)
• Example: { name:'Priya', age:22, subjects:['DBMS','OS'], address:{city:'Pune'} }
• Databases: MongoDB, CouchDB, Amazon DocumentDB, Google Firestore.
• Use Cases: Content management, e-commerce, user profiles, real-time analytics, blogging.
• Advantage: Rich querying on any field; nested documents avoid joins.
3. Column-Family (Wide Column) Store:
Organizes data in tables with rows and dynamic columns, grouped into column families. Columns in
a row are stored together on disk. Different rows can have different columns.
• Structure: Row Key → {Column Family: {Column: Value, ...}}
• Databases: Apache Cassandra, HBase, Google Bigtable, ScyllaDB.
• Use Cases: IoT sensor data, time-series data, activity feeds, financial records.
• Advantage: Very fast writes, efficient storage of sparse data, good for time-series.
4. Graph Database:
Stores data as nodes (entities) connected by edges (relationships). Both nodes and edges can
have properties. Optimized for traversing relationships between entities.
• Structure: (Node:Label {properties})-[:RELATIONSHIP]->(Node:Label)
• Example: (Rahul:Person)-[:FOLLOWS]->(Priya:Person)-[:LIVES_IN]->(Mumbai:City)
• Databases: Neo4j, Amazon Neptune, ArangoDB, JanusGraph.
• Use Cases: Social networks, fraud detection, recommendation engines, knowledge graphs,
routing.
• Advantage: Native relationship traversal without expensive joins.

Q3: Explain the CAP Theorem in detail. How does it influence the design
and categorization of distributed databases?

Answer:
CAP Theorem – Definition:
The CAP Theorem, proposed by Eric Brewer in 2000 and formally proven by Gilbert and Lynch in
2002, states that a distributed data store can guarantee at most TWO of the following three
properties simultaneously:

Unit 5 – NoSQL Databases Page 20

 1. Consistency (C):
Every read operation receives the most recent write or an error. All nodes in the distributed system
return the same data at the same time. If node A is updated, any subsequent read from node B
must reflect that update.
• Analogy: All ATMs of a bank show the same balance at the same instant.
2. Availability (A):
Every request (read or write) receives a non-error response, though it may not contain the most
recent data. The system remains operational and responsive at all times.
• Analogy: Every ATM always responds, even if it shows a cached balance.
3. Partition Tolerance (P):
The system continues to operate despite arbitrary network partitions (message loss or delay
between nodes). If some nodes cannot communicate, the system still processes requests.
• Analogy: Bank network still works even if some branches lose connectivity temporarily.
The CAP Trade-off:
In real distributed systems, network partitions are inevitable (hardware failures, network issues).
Therefore, partition tolerance (P) is not optional – any distributed system MUST tolerate partitions.
This means the real choice is between Consistency (CP) vs Availability (AP).

CAP Categories and Database Examples:

• CA Systems (No Partition Tolerance): Traditional RDBMS on single node (MySQL,
PostgreSQL). Provides strong consistency and availability but cannot handle network partitions.
Only suitable for single-node or tightly-coupled systems.
• CP Systems (Consistent + Partition-Tolerant): MongoDB, HBase, Zookeeper. When a
partition occurs, system becomes unavailable rather than returning inconsistent data. Returns
error or refuses request to maintain consistency.
• AP Systems (Available + Partition-Tolerant): Cassandra, CouchDB, DynamoDB. When a
partition occurs, system continues responding but may return stale data. Achieves eventual
consistency after the partition heals.
Real-world Applications of CAP:
• Banking systems choose CP – never show wrong balance, brief unavailability acceptable.
• Social media feeds choose AP – stale data acceptable, must always be available.
• DNS systems are AP – serve cached (old) IPs rather than becoming unavailable.
• E-commerce inventory can be AP – slight over-selling acceptable vs site being down.

Q4: Explain ACID and BASE properties. Compare them and discuss why
NoSQL databases prefer BASE over ACID.

Answer:
ACID Properties (Atomicity, Consistency, Isolation, Durability):
ACID is the traditional set of properties ensuring reliable database transactions in RDBMS. Each
letter represents one guarantee:

• Atomicity: A transaction is an indivisible unit – either ALL operations complete successfully, or

NONE of them are applied. If a bank transfer debits one account, the credit to the other account
must also succeed; otherwise both are rolled back.
• Consistency: A transaction brings the database from one valid state to another valid state,
respecting all integrity constraints, foreign keys, and business rules. The database is never left
in a corrupt or partial state.

Unit 5 – NoSQL Databases Page 21

 • Isolation: Concurrent transactions execute as if they were serial (one at a time). Changes made
by an uncommitted transaction are not visible to other transactions. Prevents dirty reads,
phantom reads, and non-repeatable reads.
• Durability: Once a transaction is committed, its changes are permanent and survive system
failures (crashes, power loss) due to write-ahead logging and persistent storage.
BASE Properties (Basically Available, Soft State, Eventually Consistent):
BASE is the alternative philosophy adopted by NoSQL databases, trading strict consistency for
higher availability and performance:

• Basically Available: The system guarantees availability (responding to requests) even during
partial failures. Some nodes may be down or partitioned, but the system as a whole continues
operating. May return partial or slightly old data.
• Soft State: The state of the system may change over time without any input, as updates
propagate through the distributed system. Replicas converge gradually. There is no guarantee
that all nodes are in sync at any given moment.
• Eventually Consistent: The system will become consistent over time if no new updates are
made. All replicas will eventually converge to the same value. This is weaker than ACID
consistency but sufficient for many applications.
Why NoSQL Prefers BASE over ACID:
• ACID requires coordination (locking, two-phase commit) across nodes, which is expensive and
reduces throughput.
• In distributed systems with hundreds of nodes, strict ACID becomes a bottleneck – one failed
node can hold up the entire transaction.
• Many web applications (social media, analytics) can tolerate eventual consistency – seeing
slightly old likes count is acceptable.
• BASE allows much higher write throughput – Cassandra can handle millions of writes/second
without locks.
• BASE systems can operate during network partitions (AP systems per CAP), while ACID
systems might refuse requests to maintain consistency.

Q5: Give a detailed comparative study of SQL and NoSQL databases

covering data model, scalability, consistency, and use cases.

Answer:
Introduction:
SQL (Structured Query Language) databases, also called Relational Database Management
Systems (RDBMS), have been the industry standard for decades. NoSQL databases emerged to
address their limitations in handling big data and distributed systems. A thorough comparison
follows:

1. Data Model and Schema:

• SQL: Fixed relational model with tables, rows, and columns. Schema must be defined before
data insertion (DDL: CREATE TABLE). Changing schema requires ALTER TABLE which can
be disruptive in large systems.
• NoSQL: Flexible, dynamic schema. Documents, key-value pairs, column families, or graph
structures. New fields can be added to individual documents without affecting others. Supports
polymorphic data.
2. Scalability:
• SQL: Primarily vertical scaling (scale-up) – upgrade CPU, RAM, storage of a single server. This
has physical limits and high cost.

Unit 5 – NoSQL Databases Page 22

 • NoSQL: Horizontal scaling (scale-out) – add more commodity servers. Data is sharded
(partitioned) across nodes. Systems like Cassandra can scale linearly to hundreds of nodes.
3. Query Language:
• SQL: Standardized SQL language across most RDBMS (minor variations). Rich querying:
SELECT, JOIN, GROUP BY, HAVING, subqueries, window functions.
• NoSQL: No universal query language. MongoDB uses MQL (MongoDB Query Language),
Cassandra uses CQL (Cassandra Query Language), Neo4j uses Cypher. Each system has its
own API.
4. Consistency and Transactions:
• SQL: Full ACID transactions. Multi-table transactions with rollback, commit, savepoints. Strong
consistency guaranteed.
• NoSQL: BASE properties. Most systems offer eventual consistency. Some like MongoDB (4.0+)
support multi-document ACID transactions, but with performance cost.
5. Relationships and Joins:
• SQL: Normalization with foreign keys. Complex joins across multiple tables (INNER JOIN, LEFT
JOIN, etc.).
• NoSQL: Denormalization – related data embedded in one document to avoid joins. MongoDB's
$lookup for limited joins. Graph databases handle relationships natively.
6. Performance:
• SQL: Excellent for complex queries with proper indexing. Performance degrades with very large
datasets and complex joins.
• NoSQL: Superior for simple access patterns at scale. In-memory options (Redis) offer
sub-millisecond latency. Write-optimized systems (Cassandra) outperform RDBMS for bulk
inserts.
7. Use Cases:
• SQL Best For: Banking, ERP, CRM, e-commerce transactions, healthcare records, any
application requiring strict ACID compliance.
• NoSQL Best For: Social media platforms, IoT sensor data, real-time analytics, content
management, gaming leaderboards, recommendation systems.

Q6: Explain MongoDB CRUD operations in detail with syntax and suitable
examples for each operation.

Answer:
MongoDB CRUD operations correspond to Create, Read, Update, and Delete – the four
fundamental operations of persistent storage.

1. CREATE – insertOne() and insertMany():

insertOne() inserts a single document into a collection. If the collection does not exist, MongoDB
creates it automatically.
[Link]({ name:'Amit Sharma', dept:'IT', salary:55000, skills:['
Java','MongoDB'] })
insertMany() inserts multiple documents in a single atomic operation (each document insertion is
atomic).
[Link]([ {name:'Priya', dept:'HR', salary:48000}, {name:'Ravi'
, dept:'IT', salary:60000} ])
• MongoDB auto-generates _id (ObjectId) if not provided. ObjectId encodes creation timestamp.
2. READ – find() and findOne():

Unit 5 – NoSQL Databases Page 23

 find() retrieves all documents matching the filter. Empty filter {} matches all documents.
[Link]({ dept:'IT' })
[Link]({ salary: {$gte:50000} }, { name:1, salary:1, _id:0 })
The second argument to find() is a projection – 1 to include, 0 to exclude fields.
[Link]().sort({salary:-1}).limit(3) // Top 3 earners
findOne() returns the first matching document:
[Link]({ name:'Amit Sharma' })

3. UPDATE – updateOne(), updateMany(), replaceOne():

updateOne() modifies the first document matching the filter using update operators:
[Link]({ name:'Amit Sharma' }, { $set:{salary:60000}, $push:{sk
ills:'Python'} })
updateMany() updates all matching documents:
[Link]({ dept:'IT' }, { $inc:{salary:5000} })
replaceOne() replaces the entire document (except _id):
[Link]({ name:'Priya' }, { name:'Priya Patel', dept:'Finance',
salary:52000 })
• Key update operators: $set (change value), $unset (remove field), $inc (increment), $push (add
to array), $pull (remove from array).
4. DELETE – deleteOne() and deleteMany():
[Link]({ name:'Ravi' }) // Delete first match
[Link]({ salary: {$lt:40000} }) // Delete all below threshold
[Link]({}) // Delete all documents
[Link]() // Remove entire collection

MongoDB CRUD provides atomic operations at the document level by default. For multi-document
transactions, MongoDB 4.0+ supports sessions with startTransaction()/commitTransaction().

Q7: Explain indexing in MongoDB. Describe different types of indexes with

syntax and their impact on query performance.

Answer:
What is an Index?
An index in MongoDB is a special data structure (B-tree by default) that stores a sorted
representation of field values and pointers to document locations. Without an index, MongoDB
performs a Collection Scan – examining every document in the collection. With an index, it performs
a targeted Index Scan, dramatically reducing the number of documents examined.

Impact on Performance:
• Without index: O(n) – must scan all n documents.
• With index: O(log n) – B-tree traversal to find matching entries.
• Indexes speed up reads but add overhead to writes (index must be updated on
insert/update/delete).
• Use explain('executionStats') to verify index usage: look for 'IXSCAN' vs 'COLLSCAN'.
Types of Indexes:

1. Default _id Index: Every collection has an automatic unique index on _id. Cannot be dropped.
Ensures document uniqueness.

2. Single Field Index: Created on one field. Supports ascending (1) or descending (-1) sort order.

Unit 5 – NoSQL Databases Page 24

 [Link]({ marks: 1 }) // Speeds up: find({marks:{$gt:80}})

3. Compound Index: Index on multiple fields. Order matters for query optimization.
[Link]({ branch:1, marks:-1 })
Follows the ESR rule: Equality fields first, Sort fields second, Range fields last.

4. Unique Index: Prevents duplicate values for the indexed field.

[Link]({ email:1 }, { unique:true })

5. Text Index: Enables full-text search on string fields. Only one text index per collection.
[Link]({ title:'text', body:'text' })
[Link]({ $text: { $search:'NoSQL database' } })

6. Sparse Index: Only indexes documents where the field exists. Efficient for optional fields.
[Link]({ phone:1 }, { sparse:true })

7. TTL (Time To Live) Index: Automatically expires and deletes documents after specified
seconds.
[Link]({ createdAt:1 }, { expireAfterSeconds:3600 })

8. Geospatial Index: Supports location-based queries on GeoJSON data.

[Link]({ location:'2dsphere' })

Index Management:
[Link]() // List all indexes
[Link]('marks_1') // Drop by index name
[Link]({marks:{$gt:80}}).explain('executionStats') // Analyze

Best Practices:
• Create indexes for fields frequently used in queries, sorts, and joins.
• Avoid over-indexing – each index consumes memory and slows writes.
• Use compound indexes to support multiple query patterns.
• Monitor index usage with $indexStats aggregation stage.

Q8: Explain the MongoDB Aggregation Pipeline in detail. Describe

important stages and accumulator operators with examples.

Answer:
What is Aggregation?
Aggregation in MongoDB is a framework for processing and transforming documents in a collection
to compute summarized results. The Aggregation Pipeline is a sequence of stages, where each
stage transforms the documents passed to it and passes the result to the next stage – similar to
Unix pipes.

Format: [Link]([ stage1, stage2, ..., stageN ])

Core Pipeline Stages:

1. $match – Filter Documents (like WHERE):

Filters documents to pass only those that match the specified condition. Should be placed early in
the pipeline to reduce document count.
{ $match: { dept:'IT', salary: {$gte:50000} } }

2. $group – Group and Aggregate (like GROUP BY):

Groups documents by a specified _id expression and applies accumulator operators.

Unit 5 – NoSQL Databases Page 25

 { $group: { _id:'$dept', avgSalary:{$avg:'$salary'}, count:{$sum:1}, maxSal:{$m
ax:'$salary'} } }

3. $project – Shape Output (like SELECT):

Include, exclude, or compute new fields. 1 includes, 0 excludes.
{ $project: { name:1, salary:1, _id:0, grade: { $cond: [{$gte:['$marks',75]},'A
','B'] } } }

4. $sort – Sort Documents (like ORDER BY):

{ $sort: { salary:-1 } } // -1 descending, 1 ascending

5. $limit and $skip – Pagination:

{ $limit: 5 } { $skip: 10 }

6. $unwind – Flatten Arrays:

Deconstructs an array field to output one document per array element.
// Document: { name:'Rahul', subjects:['DBMS','OS','CN'] }
{ $unwind: '$subjects' }
Output: Three separate documents, one per subject.

7. $lookup – Join Collections (like LEFT JOIN):

{ $lookup: { from:'departments', localField:'dept_id', foreignField:'_id', as:'
deptInfo' } }

Accumulator Operators for $group:

• $sum – Total sum: { $sum: '$salary' } or count: { $sum: 1 }
• $avg – Average value: { $avg: '$marks' }
• $max / $min – Maximum/Minimum value
• $first / $last – First/Last value in group
• $push – Array of all values in group
• $addToSet – Array of unique values in group
Complete Multi-Stage Example:
Find the top 3 departments by average salary for employees with salary above 40,000:
[Link]([
{ $match: { salary: { $gt: 40000 } } },
{ $group: { _id:'$dept', avgSal:{$avg:'$salary'}, count:{$sum:1} } },
{ $sort: { avgSal: -1 } },
{ $limit: 3 },
{ $project: { department:'$_id', avgSalary:'$avgSal', headcount:'$count', _id
:0 } }
])

Aggregation Pipeline is MongoDB's most powerful feature for analytics and replaces the need for
complex application-side data processing.

Q9: What is sharding in MongoDB? Explain horizontal scaling, shard key

selection, and the components of a sharded cluster.

Answer:
What is Sharding?
Sharding is MongoDB's approach to horizontal scaling. It distributes data across multiple machines
(shards) to handle datasets too large for a single server and to support high throughput operations.

Unit 5 – NoSQL Databases Page 26

 Each shard contains a subset of the data.

Why Sharding?
• Vertical scaling (adding more RAM/CPU) has physical and cost limits.
• Sharding allows distributing both data and load across many commodity servers.
• Enables handling of TBs to PBs of data with predictable performance.
• Reads and writes can be distributed across shards for parallel processing.
Components of a Sharded MongoDB Cluster:
• Shards: Each shard is a replica set holding a portion of the data. A shard can be a standalone
mongod or a replica set for high availability.
• Mongos (Query Router): Acts as the interface between client applications and the sharded
cluster. Routes queries to the appropriate shard(s). Applications connect to mongos, not
directly to shards.
• Config Servers: Store metadata and configuration for the sharded cluster – which shard
contains which chunks of data. Must be deployed as a replica set (CSRS – Config Server
Replica Set).
Shard Key:
The shard key is a field (or compound field) that determines how documents are distributed across
shards. MongoDB divides data into chunks based on shard key ranges and assigns chunks to
shards.
• Ranged Sharding: Documents with adjacent shard key values grouped together. Good for
range queries but may create hotspots.
• Hashed Sharding: Hash of shard key determines chunk. Better distribution but poor for range
queries.
Shard Key Selection Best Practices:
• High cardinality – many unique values to distribute data evenly.
• Even distribution – avoid monotonically increasing keys (like timestamp) that create hotspots.
• Query isolation – shard key appears in most queries for targeted (single-shard) queries.
Example: [Link]('myDB'); [Link]('[Link]', { customer_id: 'hashed' })

Q10: Write short notes on: (a) Replication in MongoDB (b) MongoDB Atlas
(c) Differences between Embedded and Referenced Documents.

Answer:
(a) Replication in MongoDB:
MongoDB implements replication through Replica Sets. A replica set is a group of mongod
instances that maintain the same dataset, providing redundancy and high availability.
• Primary Node: Receives all write operations. Only one primary exists at a time.
• Secondary Nodes: Maintain copies of primary data via asynchronous replication (oplog). Can
serve read operations if configured.
• Arbiter: Participates in elections but holds no data. Used to maintain odd number of votes.
• Automatic Failover: If primary is unavailable for 10 seconds, secondaries elect a new primary
automatically.
• Oplog (Operations Log): A capped collection on primary recording all data modifications.
Secondaries continuously replicate from oplog.
Benefits: Data redundancy, high availability, disaster recovery, read scalability (read from
secondaries).

Unit 5 – NoSQL Databases Page 27

 (b) MongoDB Atlas:
MongoDB Atlas is a fully managed cloud database service provided by MongoDB Inc. It automates
deployment, scaling, backup, and maintenance of MongoDB clusters on AWS, Azure, or GCP.
• Fully managed: no server administration, automatic patching, monitoring built-in.
• Multi-cloud & Multi-region deployment with global clusters.
• Automated backups with point-in-time recovery.
• Atlas Search for full-text search, Atlas Data Lake for analytics on S3 data.
• Free M0 tier available for learning and small projects.
• Atlas App Services: serverless functions, triggers, mobile sync (Realm).

(c) Embedded vs Referenced Documents:

In MongoDB, related data can be modeled in two ways:
• Embedded Documents (Denormalization): Related data stored within a single document as
nested sub-documents or arrays. Best when data is accessed together, has a one-to-one or
one-to-few relationship, and data doesn't need independent queries. Example: student
document embedding address and subjects array. Advantage: Single read operation retrieves
all data.
• Referenced Documents (Normalization): Documents store references (ObjectIds) to
documents in other collections. Best for large, frequently changing data, many-to-many
relationships, or when referenced data is accessed independently. Example: order document
with customer_id referencing customers collection. Advantage: Avoids data duplication and
update inconsistencies.
Rule of thumb: Embed when you 'get it together', reference when you 'get it separately'.

Unit 5 – NoSQL Databases | Complete Study Notes | All Rights Reserved

Unit 5 – NoSQL Databases Page 28