 Why NoSQL?

NoSQL databases are used because traditional relational databases (RDBMS) struggle with
modern, large-scale, distributed applications. Key reasons are:

1. Scalability
NoSQL supports horizontal scaling (adding more servers) easily, making it suitable
for big data and high-traffic applications.

2. High Performance
Optimized for fast read/write operations with minimal latency, especially for real-
time applications.

3. Flexible Schema
No fixed schema. Data structures can evolve over time without complex
migrations—ideal for agile development.

4. Handles Big Data

Designed to store and process huge volumes of structured, semi-structured, and
unstructured data.

5. Distributed Architecture
Built for distributed systems with data replication and fault tolerance, ensuring
high availability.

6. Cost-Effective
Runs efficiently on commodity hardware, reducing infrastructure cost.

7. Variety of Data Models

Supports different models like:

o Key-Value

o Document

o Column-Family

o Graph

8. Better for Cloud & Web Apps

Works well with cloud computing, microservices, IoT, and social media
platforms.
 Value of Relational Databases

Relational databases (RDBMS) continue to be valuable because they provide strong data
consistency, reliability, and structured data management. Their key values are:

1. Structured Data Organization

Data is stored in well-defined tables with rows and columns, making it easy to
understand and manage.

2. ACID Properties
Guarantees Atomicity, Consistency, Isolation, and Durability, ensuring accurate
and reliable transactions.

3. Data Integrity & Consistency

Enforces constraints like primary keys, foreign keys, and referential integrity,
reducing data anomalies.

4. Powerful Query Language (SQL)

SQL allows complex queries, joins, aggregations, and reporting with ease.

5. Mature & Stable Technology

RDBMS are well-tested, widely adopted, and supported by strong tools and
communities.

6. Security & Access Control

Provides strong authentication, authorization, and role-based access control.

7. Ideal for Transactional Systems

Best suited for applications like banking, finance, payroll, inventory, and ERP
systems.

 Emergence of NoSQL

The emergence of NoSQL databases is driven by the limitations of traditional relational

databases in handling large-scale, distributed, and data-intensive applications. The key
factors are:

1. Explosion of Big Data

Rapid growth of data from social media, IoT, web logs, and mobile apps required
new storage models.
 2. Need for High Scalability
RDBMS scale vertically, but modern applications demanded horizontal scaling
across many servers, which NoSQL supports.

3. Performance Requirements
Real-time applications needed low-latency, high-throughput data access.

4. Flexible Data Models

Changing application requirements required schema-less or dynamic schemas,
unlike rigid relational schemas.

5. Distributed Systems & Cloud Computing

Cloud platforms and microservices favored distributed, fault-tolerant databases.

6. Limitations of ACID at Scale

Strict ACID properties reduce performance in distributed environments, leading to
BASE and eventual consistency models.

7. Industry Adoption
Companies like Google, Amazon, Facebook, and Netflix developed NoSQL
solutions to handle massive workloads.

 Aggregate Data Models

Aggregate data models are used in NoSQL databases to store and manage related data as
a single unit (aggregate) rather than splitting it across multiple tables.

Key Points:

1. Concept of Aggregate
An aggregate is a collection of related data items treated as one entity (e.g., an
order with customer details and items).

2. Data Storage
Data is stored together, reducing the need for joins and improving performance.

3. Atomic Operations
Updates and reads are performed atomically on the entire aggregate, ensuring
consistency within the aggregate.

4. Scalability
Aggregates can be easily partitioned and distributed across multiple nodes.
 5. Suitable Use Cases
Best for applications with:

o High read/write throughput

o Simple queries

o Distributed systems

6. Types of Aggregate Data Models

o Key–Value Model – data stored as key–value pairs

o Document Model – data stored as JSON/XML documents

o Column-Family Model – data stored in column groups

Example:
An Order aggregate may contain order ID, customer info, shipping address, and list of
items in one document.

 Aggregates

In NoSQL databases, an aggregate is a collection of related data that is treated as a single

unit for storage, retrieval, and updates.

Key Points:

1. Single Unit of Data

An aggregate groups related information together (e.g., a customer and their orders).

2. Atomic Operations
Read and write operations are atomic within an aggregate, ensuring consistency
for that unit.

3. Reduces Joins
Since related data is stored together, expensive join operations are avoided.

4. Improves Performance
Faster access as all required data is fetched in one operation.

5. Supports Scalability
Aggregates can be easily sharded and distributed across nodes.
 6. Common in NoSQL Models
Used in:

o Document databases (JSON documents)

o Key–Value stores

o Column-family databases

Example:
An Order aggregate includes order details, customer info, and item list stored together as
one document.

 Example of Relations and Aggregates

1. Example of Relations (Relational Database)

In a relational database, data is split into multiple tables and connected using
relationships (keys).

Example: Online Shopping System

• Customer Table
(Customer_ID, Name, Email)

• Order Table
(Order_ID, Order_Date, Customer_ID)

• Order_Items Table
(Item_ID, Order_ID, Product_Name, Quantity)

➡ Data is retrieved using JOIN operations.

➡ Strong consistency and normalized structure.

2. Example of Aggregates (NoSQL Database)

In a NoSQL database, related data is stored together as a single aggregate.

Example: Order Aggregate (Document Model)

"order_id": "O101",
 "order_date": "2026-02-03",

"customer": {

"customer_id": "C01",

"name": "John"

},

"items": [

{ "product": "Laptop", "qty": 1 },

{ "product": "Mouse", "qty": 2 }

➡ All order-related data stored as one document.

➡ No joins required; faster access and easy scaling.

Key Difference (Exam Line)

• Relations → Data split across tables, connected by keys

• Aggregates → Related data grouped and stored as one unit

Relations focus on normalization and consistency, while aggregates focus on

performance and scalability

 Consequences of Aggregate Orientation

Aggregate orientation (used in NoSQL databases) has several important consequences on

data design and system behavior:

Positive Consequences

1. Improved Performance
Related data is stored together, so read and write operations are faster and require
fewer database calls.
 2. Atomic Updates within Aggregates
Operations are atomic at the aggregate level, ensuring consistency for the entire
aggregate.

3. Better Scalability
Aggregates can be easily partitioned (sharded) across multiple nodes, supporting
horizontal scaling.

4. Reduced Need for Joins

Eliminates expensive join operations common in relational databases.

5. Simpler Data Access

Application logic becomes simpler as all related data is fetched in one request.

Negative Consequences

6. Data Duplication
Some data may be repeated across aggregates, increasing storage usage.

7. Limited Cross-Aggregate Consistency

Maintaining consistency across multiple aggregates is difficult; often relies on
eventual consistency.

8. Complex Updates for Shared Data

Updating common data across many aggregates can be costly and error-prone.

9. Less Flexibility for Complex Queries

Queries spanning multiple aggregates are harder to perform efficiently.

 Key-Value Data Model

The Key–Value data model is the simplest and fastest NoSQL data model, where data is
stored as a pair of a unique key and its associated value.

Key Features

1. Structure

o Key: Unique identifier

o Value: Data (string, number, JSON, binary, etc.)

2. Schema-less
No fixed schema; values can have different structures.
 3. High Performance
Very fast read and write operations due to direct key-based access.

4. Scalability
Easily supports horizontal scaling and data distribution.

5. Simple Operations
Supports basic operations: GET, PUT, DELETE.

6. Limited Query Capability

No complex queries or joins—data is accessed only via keys.

Example

Key: user_101

Value: { "name": "Asha", "age": 22, "city": "Bangalore" }

Use Cases

• Caching (Redis, Memcached)

• Session management

• User profiles

• Shopping carts

Examples of Key–Value Databases

• Redis

• DynamoDB

• Riak

• Amazon Dynamo

 Document Data Model

The Document Data Model is a NoSQL data model where data is stored as documents
(self-contained records) instead of rows and tables.

Key Features

1. Document-Based Storage
Data is stored in documents, usually in JSON, BSON, or XML format.
 2. Schema-less / Flexible Schema
Documents in the same collection can have different fields and structures.

3. Self-Describing Data
Each document contains both data and its structure, making it easy to understand.

4. Nested and Complex Data

Supports nested objects and arrays, reducing the need for joins.

5. Indexing Support
Indexes can be created on document fields for faster querying.

6. Scalability
Designed for horizontal scaling and distributed environments.

7. Atomic Operations
Updates are atomic at the document level.

Example

"student_id": "S101",

"name": "Rahul",

"course": "MCA",

"marks": { "AI": 85, "ML": 90 }

Use Cases

• Content management systems

• User profiles

• E-commerce product catalogs

• Real-time analytics

Examples of Document Databases

• MongoDB

• CouchDB

• Firebase Firestore
 Column-Family Stores

Column-Family Stores are a type of NoSQL database that store data in column families
rather than traditional rows, making them highly efficient for large-scale, distributed data
storage.

Key Characteristics

1. Column-Oriented Storage
Data is stored by columns, not rows, enabling fast access to specific columns.

2. Column Families
Related columns are grouped into column families. Each row can have a different
set of columns.

3. Schema-Flexible
Columns can be added dynamically; no fixed schema is required.

4. High Scalability
Designed for horizontal scaling across many servers.

5. High Performance
Efficient for read/write operations on large datasets.

6. Sparse Data Support

Rows can have missing columns without wasting storage.

7. Distributed & Fault Tolerant

Data is replicated across nodes for high availability.

Structure Example

Row Key: R1

--------------------------------

Personal: Name=Anita, Age=22

Academic: Course=MCA, CGPA=8.7

Use Cases

• Big data analytics

• Time-series data

• Recommendation systems
 • Logging and monitoring systems

Examples of Column-Family Databases

• Apache Cassandra

• HBase

• Google Bigtable

 Graph Databases

Graph databases are a type of NoSQL database designed to store and manage data based
on relationships using graph structures.

Key Components

1. Nodes
Represent entities (e.g., Person, Product).

2. Edges (Relationships)
Represent connections between nodes (e.g., FRIEND_OF, BOUGHT).

3. Properties
Key–value pairs stored in nodes and edges to describe attributes.

Key Features

4. Relationship-Focused
Relationships are first-class citizens, not computed using joins.

5. High Performance for Connected Data

Traversing relationships is fast, even with deep connections.

6. Schema-Flexible
Allows dynamic changes in structure.

7. Efficient Graph Traversals

Ideal for queries like shortest path, recommendations, and network analysis.

8. Scalability
Supports distributed graph processing (with some trade-offs).

Example

(Alice) -[FRIEND_OF]-> (Bob)

(Bob) -[WORKS_AT]-> (CompanyX)

Use Cases

• Social networks

• Recommendation systems

• Fraud detection

• Knowledge graphs

Examples of Graph Databases

• Neo4j

• Amazon Neptune

• OrientDB

• ArangoDB

 Distribution Models

• Single Server

• Sharding

• Master–Slave Replication

• Peer-to-Peer Replication

• Distribution models define how data is stored and replicated across multiple
nodes to ensure scalability, availability, and fault tolerance.

• 1. Single Server

• All data is stored on one server.

• Pros: Simple setup, easy management.

• Cons: Limited scalability, single point of failure.

• Use Case: Small applications or testing environments.

•
• 2. Sharding (Horizontal Partitioning)

• Data is split across multiple servers (shards) based on a shard key.

• Each shard stores only a subset of the data.

• Pros: High scalability, distributes load efficiently.

• Cons: Complex queries across shards, shard rebalancing is challenging.

• Use Case: Large-scale web apps, multi-terabyte databases.

• Example:
Users with user_id 1-1000 → Shard 1
Users with user_id 1001-2000 → Shard 2

• 3. Master–Slave Replication

• Master node handles writes, slave nodes replicate data for reads.

• Pros: Read scalability, data backup for fault tolerance.

• Cons: Master is a single write point (bottleneck/failure risk).

• Use Case: Systems with many reads and fewer writes.

• 4. Peer-to-Peer Replication

• All nodes are equal peers; each can read and write data.

• Changes are synchronized across peers.

• Pros: No single point of failure, high availability.

• Cons: Conflict resolution can be complex; eventual consistency.

• Use Case: Distributed, highly available systems like Cassandra or DynamoDB.

• Summary Table:

• Model • Scalability • Fault Tolerance • Complexity

• Single Server • Low • Low • Low

 • Model • Scalability • Fault Tolerance • Complexity

• Sharding • High • Medium • High

• Master–Slave • Medium • Medium • Medium

• Peer-to-Peer • High • High • High

 Combining Sharding and Replication

In NoSQL systems, sharding and replication are often combined to achieve both
scalability and high availability.

1. Concept

• Sharding (Horizontal Partitioning): Splits data into multiple shards (subsets)

across servers.

• Replication: Each shard is replicated across multiple nodes for fault tolerance.

• Combined Approach: Each shard has primary/replica nodes, enabling

distributed, scalable, and fault-tolerant storage.

2. How It Works

1. Data is divided into shards using a shard key (e.g., user_id).

2. Each shard is replicated to multiple nodes (replica set).

3. Reads can go to any replica; writes usually go to the primary node of the shard.

4. If a node fails, replicas ensure data availability.

3. Advantages

• High Scalability: Shards distribute the data and load.

• High Availability: Replicas provide redundancy in case of failures.

• Fault Tolerance: Node or shard failures do not affect the entire system.
 • Optimized Performance: Reads can be served from replicas; writes go to primary
nodes.

4. Example

• Shards:

o Shard 1 → Users 1–1000

o Shard 2 → Users 1001–2000

• Replication:

o Shard 1 → Node A (primary), Node B (replica), Node C (replica)

o Shard 2 → Node D (primary), Node E (replica), Node F (replica)

5. Use Cases

• Large-scale web applications (Facebook, Twitter)

• E-commerce platforms with millions of users

• Distributed databases requiring both scale and reliability

 Consistency

In distributed databases, consistency refers to the guarantee that all nodes see the same
data at the same time after a transaction or update.

1. Definition

• Consistency ensures that every read receives the most recent write (or an error if
data is not updated).

• It is one of the ACID properties in relational databases.

2. Types of Consistency in NoSQL / Distributed Systems

1. Strong Consistency
 o Every read reflects the most recent write.

o Ensures up-to-date data but may reduce performance.

o Example: Banking transactions.

2. Eventual Consistency

o Updates propagate to all nodes eventually.

o Reads may temporarily return outdated data.

o Optimized for availability and partition tolerance.

o Example: Social media feeds.

3. Causal Consistency

o Operations that are causally related are seen in order.

o Concurrent updates may be seen in different order.

4. Read-your-writes Consistency

o A client always sees its own updates immediately, even if other nodes lag.

3. Why Consistency Matters

• Ensures data correctness across distributed systems.

• Impacts application behavior, especially in financial, inventory, or critical systems.

4. Trade-offs

• According to the CAP theorem, in distributed systems you can have only two of
three: Consistency, Availability, Partition tolerance.

o Strong consistency may reduce availability in case of network partitions.

o Eventual consistency favors availability over immediate correctness.

 Update Consistency
Update consistency refers to how changes (updates) to data are propagated and seen
across all nodes in a distributed or NoSQL database. It is a measure of how reliably
updates are applied and synchronized.

1. Definition

• Ensures that once data is updated on one node, other nodes eventually reflect
the same update.

• Important in systems where multiple copies of data exist (replication, sharding).

2. Types of Update Consistency

1. Immediate (Strong) Update Consistency

o Updates are synchronously applied to all replicas before confirming

success.

o Guarantees all nodes have the same data immediately.

o Pros: Data is always up-to-date.

o Cons: Higher latency; slower write operations.

2. Eventual Update Consistency

o Updates are propagated asynchronously; nodes may temporarily have stale

data.

o Guarantees that eventually all replicas will converge to the same value.

o Pros: High availability and low latency.

o Cons: Temporary inconsistency possible.

3. Causal Update Consistency

o Updates that are causally related are seen in order by all nodes.

o Independent updates may be applied in different orders.

3. Why Update Consistency Matters

 • Prevents data conflicts in replicated or distributed systems.

• Ensures reliable application behavior, especially in financial, inventory, or

collaborative apps.

4. Example

• Strong consistency: Bank account balance updated; all ATMs show the new
balance immediately.

• Eventual consistency: Social media likes update; some users see the old count for
a few seconds before it converges.

 Read Consistency

Read consistency in distributed or NoSQL databases refers to the guarantee that a read
operation returns the most up-to-date or expected value of data, considering multiple
replicas and updates.

1. Definition

• Ensures that the value read reflects a certain level of consistency, depending on
the system’s consistency model.

• Important in systems with replicated data to prevent stale or conflicting reads.

2. Types of Read Consistency

1. Strong Read Consistency

o Every read returns the most recent write.

o Ensures all clients see the same, up-to-date data.

o Example: Bank account balance after a deposit.

2. Eventual Read Consistency

o Reads may return outdated values temporarily.

o Data will converge eventually as updates propagate.

 o Example: Likes count on a social media post may be slightly delayed.

3. Session (Read-Your-Writes) Consistency

o A client always sees its own writes, even if other nodes are behind.

o Useful for user-specific operations.

4. Causal Read Consistency

o Reads reflect operations in causal order.

o Concurrent operations may appear in different orders on different nodes.

3. Why Read Consistency Matters

• Ensures correct application behavior.

• Prevents conflicting data reads in replicated/distributed systems.

• Helps balance consistency vs. availability trade-offs (CAP theorem).

4. Example

• Strong consistency: Stock inventory update; all warehouses show the new quantity
immediately.

• Eventual consistency: Social media feed updates; some users see older posts
temporarily.

 CAP Theorem

The CAP Theorem is a fundamental principle in distributed systems, stating that a

distributed database can provide only two out of three guarantees at the same time:
Consistency, Availability, and Partition Tolerance.

1. Components

1. Consistency (C)

o Every read receives the most recent write.

 o All nodes return the same data at any time.

2. Availability (A)

o Every request (read/write) receives a response, even if some nodes fail.

o System is operational 100% of the time.

3. Partition Tolerance (P)

o The system continues to operate even if network partitions or failures

occur between nodes.

o Essential for distributed systems.

2. Implications

• In a distributed system, you cannot achieve all three simultaneously. You must
choose two:

Choice Meaning

CP Consistency + Partition Tolerance → May sacrifice Availability.

Consistency + Availability → No Partition Tolerance (impractical in large distributed

CA
systems).

AP Availability + Partition Tolerance → May sacrifice Consistency.

3. Examples

• CP Systems: HBase, MongoDB (strong consistency mode)

• AP Systems: Cassandra, DynamoDB

• CA Systems: Traditional RDBMS (single-node, not distributed)

4. Why It Matters

• Guides the design of distributed NoSQL databases.

• Helps understand trade-offs between data correctness, uptime, and network

failures.
 Quorums

In distributed databases, a quorum is the minimum number of nodes that must agree for
a read or write operation to be considered successful. Quorums are used to ensure
consistency in replicated systems.

1. Definition

• A quorum is a voting mechanism for replicated data to maintain consistency

across nodes.

• Ensures that reads and writes overlap sufficiently to prevent stale data.

2. How Quorums Work

1. Let N = total replicas, W = write quorum, R = read quorum.

2. To maintain strong consistency:

𝑅+𝑊 >𝑁

• Write quorum (W): Number of replicas that must acknowledge a write.

• Read quorum (R): Number of replicas that must respond for a read.

• Total replicas (N): Number of nodes storing the data.

Example:

• N = 5 replicas

• W = 3 (write must be acknowledged by 3 nodes)

• R = 3 (read must get 3 nodes’ data)

• Since R + W = 6 > N, reads always see the latest write → strong consistency.

3. Types of Quorums

1. Read Quorum: Minimum nodes to respond to a read.

 2. Write Quorum: Minimum nodes to confirm a write.

3. Combined Quorum: Used to guarantee strong consistency (R + W > N).

4. Advantages

• Balances consistency, availability, and performance.

• Reduces the chance of reading stale data.

• Flexible for tuning read/write-heavy systems.

5. Example Use Cases

• Amazon DynamoDB

• Apache Cassandra

• Riak