UNIT – III

NoSQL Databases
Key-Value Stores | Document Databases

📚 Exam Preparation Notes

Important Questions with Detailed Answers

Topics Covered
✔ Key-Value Store – Definition, Features, Use Cases, When NOT to Use
✔ Document Databases – Definition, Features, Use Cases, When NOT to Use
✔ Comparison: Key-Value vs Document Databases
✔ NoSQL Overview & CAP Theorem
✔ Columnar Data Model
PART A: QUICK CONCEPT NOTES (Read First)

1. What is NoSQL?
NoSQL stands for 'Not Only SQL'. It refers to databases that do NOT follow the traditional relational
(table-based) model. NoSQL databases are designed for:
• Large-scale, distributed data storage
• High performance and scalability
• Flexible/schema-less data models
• Handling unstructured or semi-structured data

🔑 Key Difference: SQL databases store data in TABLES (rows & columns). NoSQL databases store
data in different formats – key-value pairs, documents, columns, or graphs.

2. Types of NoSQL Databases (Overview)

Type How Data is Stored Example

Key-Value Store Simple key → value pairs (like a Redis, DynamoDB, Riak
dictionary)
Document Database JSON/BSON documents grouped MongoDB, CouchDB
in collections
Columnar Database Columns stored together (not rows) Cassandra, HBase
Graph Database Nodes and edges (relationships) Neo4j, ArangoDB

KEY-VALUE STORE DATABASES

2.1 What is a Key-Value Store?

A Key-Value store is the simplest type of NoSQL database. Think of it like a Python dictionary or a real-
world locker system:
• You have a KEY (the locker number)
• You store a VALUE inside (whatever you want – text, number, image, JSON, etc.)
• To retrieve the value, you just use the key

📦 Real-Life Analogy: A dictionary – word (key) → meaning (value). You don't need to know the
meaning to find it, you just look up the word!
Definition: A Key-Value store is a database that uses an associative array (also called a hash
table or map) as its fundamental data model, where each key is unique and maps directly to a
value.

2.2 Features of Key-Value Stores

⚡ Core Features of Key-Value Databases

▸ Schema-less / Schema-free: No fixed structure – values can be strings, integers, JSON,
blobs, etc.
▸ Fast Lookup: O(1) retrieval time using the key – extremely fast reads and writes
▸ Horizontal Scalability: Easily scale across multiple servers (distributed)
▸ Simple API: Only 3 operations – GET(key), PUT(key, value), DELETE(key)
▸ High Availability: Supports replication for fault tolerance
▸ Partitioning / Sharding: Data is distributed across nodes using the key
▸ Atomic Operations: Operations on a single key are atomic (no partial updates)
▸ TTL (Time To Live): Keys can expire automatically after a set time (useful for caching)

Detailed Feature Breakdown:

Feature Explanation
Simple Data Model Only key-value pairs – no joins, no relationships
between data
Opaque Values The database does NOT look inside the value – it
treats it as a black box
High Performance Reads/writes are extremely fast (often in
microseconds)
Scalability Can handle millions of operations per second
across distributed nodes
Eventual Consistency Data may be slightly out-of-date across nodes
but will sync eventually
Persistence Options Some (like Redis) are in-memory; others persist
to disk
No Complex Queries Cannot query by value – can only fetch using
exact key

2.3 Suitable Use Cases for Key-Value Stores

✅ WHEN TO USE Key-Value Stores

▸ Session Management: Store user session data (login info, cart data) – fast access
needed
 ▸ Caching: Cache frequently accessed database results to reduce load (Redis is king here)
▸ User Profiles & Preferences: Store per-user settings where you lookup by user ID
▸ Real-Time Leaderboards: Gaming scores, rankings updated in real time
▸ Shopping Cart: E-commerce cart data stored per user key
▸ Pub/Sub Messaging: Redis supports publish-subscribe messaging patterns
▸ DNS Lookups: Domain name (key) → IP address (value)
▸ Configuration Data: Application settings stored as key-value pairs
▸ Counters & Analytics: Page view counters, click trackers – fast increment operations

2.4 When NOT to Use Key-Value Stores

❌ WHEN NOT TO USE Key-Value Stores

▸ Complex Queries Needed: Cannot filter by value content – no WHERE clause like SQL
▸ Relationships Between Data: No support for joins or foreign keys
▸ Need to Query Inside Values: If you need to search inside the value, use a Document DB
instead
▸ ACID Transactions Across Multiple Keys: Limited support for multi-key transactions
▸ Reporting & Analytics: Poor fit for aggregations, groupings, complex analytical queries
▸ Structured Data with Many Fields: Better to use relational DB or Document DB
▸ Data Integrity Constraints: No support for referential integrity or constraints

🆚 Key-Value vs Document DB (Similar but Different!): Key-Value stores treat the VALUE as an
opaque blob – they don't look inside. Document databases understand the internal structure of the
value (JSON fields), so you can query by any field inside the document.

DOCUMENT DATABASES

3.1 What is a Document Database?

A Document Database stores data as documents (usually in JSON, BSON, or XML format). Each
document is a self-contained unit that holds all related information together.

📄 Real-Life Analogy: Think of each document like a file in a filing cabinet. Each file (document)
contains all information about ONE thing (e.g., one customer). Files can have different fields – no
fixed template required!

Definition: A document database is a type of NoSQL database that stores semi-structured data
as documents. Each document has a unique ID and can contain nested data, arrays, and varied
fields.
Example – A MongoDB Document (JSON format):
{
"_id": "u001",
"name": "Ravi Kumar",
"age": 22,
"courses": ["NoSQL", "DBMS", "Python"],
"address": {
"city": "Hyderabad",
"state": "Telangana"
}
}

3.2 Features of Document Databases

📄 Core Features of Document Databases

▸ Flexible Schema: Each document can have different fields – no fixed schema required
▸ Rich Query Language: Can query by any field inside the document (unlike Key-Value
stores)
▸ Nested Documents: Can store arrays and embedded/nested documents within a
document
▸ Document ID: Each document has a unique identifier (_id in MongoDB)
▸ Secondary Indexes: Create indexes on any field to speed up queries
▸ CRUD Operations: Supports Create, Read, Update, Delete on documents
▸ Aggregation: Supports grouping, filtering, and computing on collections
▸ Replication & Sharding: High availability and horizontal scalability built-in
▸ ACID at Document Level: Atomic operations guaranteed within a single document

Feature Comparison – Document DB vs Key-Value Store:

Feature Document DB vs Key-Value
Can query by value? Document DB: YES ✅ | Key-Value: NO ❌
Data structure Document DB: Structured JSON | Key-Value:
Opaque blob
Nested data Document DB: YES (arrays, objects) | Key-
Value: NO
Secondary indexes Document DB: YES | Key-Value: NO (key only)
Query complexity Document DB: HIGH | Key-Value: LOW (key
only)
Read speed Both are very fast, Key-Value slightly faster for
simple lookups
Use case Document DB: Complex apps | Key-Value:
Caching, sessions
3.3 Suitable Use Cases for Document Databases

✅ WHEN TO USE Document Databases

▸ Content Management Systems (CMS): Articles, blog posts, pages – each with different
fields
▸ E-Commerce Applications: Product catalog where each product has different attributes
▸ User Profiles: Complex user data with nested preferences, addresses, history
▸ Real-Time Analytics: Analyzing user behavior, events, and logs
▸ Mobile Applications: Backend for apps – flexible and schema-free development
▸ Gaming Applications: Player profiles, game state, inventory data
▸ IoT Data: Sensor readings with varying fields per device
▸ Event Logging: Application logs, audit trails with varied fields
▸ Catalogs: Library catalogs, product catalogs with varied metadata

3.4 When NOT to Use Document Databases

❌ WHEN NOT TO USE Document Databases

▸ Complex Multi-Collection Joins: Document DBs have limited join support – use RDBMS
instead
▸ Highly Structured Data with Fixed Schema: Relational DB is more efficient
▸ Financial Transactions Requiring Full ACID: Multi-document transactions have limitations
▸ Heavy Reporting/BI Workloads: OLAP databases (Redshift, BigQuery) are better
▸ Strongly Relational Data: Data with many inter-collection relationships belongs in SQL
▸ Simple Key-Based Lookups Only: Overkill – a Key-Value store would be simpler and
faster

CAP THEOREM & NoSQL

4.1 What is CAP Theorem?

CAP Theorem (also called Brewer's Theorem) states that a distributed database system can guarantee
at most TWO out of the following THREE properties simultaneously:

Property Meaning Simple Explanation

C – Consistency All nodes see the same data at the Everyone reads the latest write
same time
A – Availability Every request gets a response System always responds
(may not be latest)
 P – Partition Tolerance System works even if network splits Works despite network failures
occur

💡 KEY INSIGHT: In a real distributed system, network partitions (P) WILL happen. So the real choice
is between Consistency (C) and Availability (A). This is why NoSQL databases choose either CP or
AP.

4.2 Where Does MongoDB Stand in CAP?

MongoDB is a CP (Consistent + Partition Tolerant) database:
• It prioritizes CONSISTENCY – all reads return the most recent write
• During a network partition, MongoDB may become UNAVAILABLE to ensure consistency
• Uses primary-secondary replication: only primary accepts writes
• If primary fails, MongoDB elects a new primary (may be briefly unavailable)

NoSQL DB Type CAP Classification

MongoDB CP (Consistent + Partition Tolerant)
Redis CP (Consistent + Partition Tolerant)
Cassandra AP (Available + Partition Tolerant)
CouchDB AP (Available + Partition Tolerant)
Riak AP (Available + Partition Tolerant)
HBase CP (Consistent + Partition Tolerant)

COLUMNAR DATA MODEL OF NoSQL

5.1 What is a Columnar Database?

A Columnar (Column-Family / Wide-Column) database stores data column by column instead of row by
row. This is fundamentally different from relational databases.

📊 Row Store vs Column Store: Row DB stores: [ID=1, Name=Ravi, Age=22] [ID=2, Name=Priya,
Age=21] → entire rows together. Column DB stores: [ID: 1,2,3] [Name: Ravi, Priya, Anu] [Age:
22,21,20] → each column together.

5.2 Key Concepts in Columnar Model

Concept Explanation
Keyspace Top-level container (like a database in RDBMS)
Column Family Group of related columns (like a table, but
flexible)
Row Key Unique identifier for each row
Column Name-value pair with a timestamp
Super Column A column that contains other columns (nested)
Wide Row A single row can have millions of columns

5.3 Advantages of Columnar Model

• Fast Analytical Queries: Reading only needed columns is very efficient
• Better Compression: Same-type data in columns compresses better
• Scalability: Distributes columns across nodes
• Flexible Schema: Rows can have different columns
• Optimized for Time-Series Data: Timestamps as column names

5.4 Examples: Cassandra (AP), HBase (CP)

Property Apache Cassandra vs HBase
CAP Type Cassandra: AP | HBase: CP
Model Both use Wide-Column / Column-Family model
Use Case Cassandra: IoT, Social Media | HBase: Hadoop,
Analytics
Consistency Cassandra: Tunable | HBase: Strong
PART B: IMPORTANT EXAM QUESTIONS WITH ANSWERS

📝 These questions cover all syllabus topics. Questions marked [2 Marks] test definitions; [5 Marks]
test explanation + use cases; [10 Marks] are full essay questions.

Q1. What is a Key-Value Store? Explain its features. [5 Marks] [5 Marks]

Definition:
A Key-Value store is the simplest form of NoSQL database that uses an associative array
(hash table/map) as its data model. Each unique KEY maps to a VALUE. The database does
not interpret the value – it treats it as an opaque blob.
Features:
1. Schema-Free: Values can be any data type – strings, numbers, JSON, binary, etc.
2. Simple API: GET(key), PUT(key, value), DELETE(key) – three operations only.
3. High Performance: O(1) lookup time makes reads/writes extremely fast.
4. Horizontal Scalability: Scales by distributing keys across multiple nodes (sharding).
5. TTL Support: Keys can have an expiry time (Time-To-Live), useful for cache
invalidation.
6. High Availability: Replication ensures data is available even when nodes fail.
Examples: Redis, Amazon DynamoDB, Riak, Memcached

Q2. What are the suitable use cases for Key-Value Stores? When should you NOT use
them? [5 Marks] [5 Marks]
Suitable Use Cases (WHEN TO USE):
7. Session Management: Storing user login sessions (fast access with session ID as
key).
8. Caching: Storing frequently used query results to avoid repeated DB hits (Redis
Cache).
9. Shopping Cart: User ID (key) → Cart items (value).
10. Real-Time Leaderboards: Gaming scores stored and ranked instantly.
11. Configuration Storage: App settings stored as key-value pairs.
When NOT to Use:
12. Complex Queries: Cannot filter/search within values – no SQL-like WHERE clause.
13. Relational Data: No support for joins between different key-value pairs.
14. Multi-Key ACID Transactions: Limited transaction support across multiple keys.
15. Analytics & Reporting: Poor for aggregation, grouping, or BI queries.

Q3. What is a Document Database? Explain its features with an example. [5 Marks] [5
Marks]

Definition:
A Document Database stores data as semi-structured documents (JSON, BSON, or XML).
Unlike Key-Value stores, document databases understand and can query the internal
structure of the document. Each document is identified by a unique ID.
Features:
16. Flexible Schema: Different documents in the same collection can have different
fields.
17. Rich Querying: Query by any field inside the document using query operators.
18. Nested Documents & Arrays: Supports embedding complex nested structures.
19. Secondary Indexes: Indexes can be created on any field to speed up queries.
20. ACID at Document Level: Atomic operations guaranteed per document.
21. Aggregation Pipeline: Supports complex data transformations and summaries.
Example: In MongoDB, a student document:
{ "_id": "s01", "name": "Ravi", "marks": [85, 90, 78], "address": { "city":
"Hyd" } }
Examples of Document DBs: MongoDB, CouchDB, Firebase Firestore, Amazon
DocumentDB.

Q4. Compare Key-Value Store and Document Database. [5 Marks] [5 Marks]

Both Key-Value Stores and Document Databases are NoSQL databases, but they differ
significantly in capabilities:
Aspect Key-Value Store Document Database
Data Model Key → Opaque Value Key → Structured Document
(JSON)
Query Ability Key only (no value querying) Query by any field inside
document
Schema Schema-free (opaque values) Flexible schema (structured
docs)
Nested Data Not supported Supported (arrays, objects)
Indexes Primary key only Secondary indexes on any field
Performance Faster (simpler model) Slightly slower, more powerful
Use Case Caching, sessions, counters CMS, e-commerce, user profiles
Example Redis, DynamoDB MongoDB, CouchDB

Q5. Explain the CAP Theorem. Where does MongoDB stand? [5 Marks] [5 Marks]
CAP Theorem (Brewer's Theorem):
CAP Theorem states that any distributed database system can guarantee only TWO of the
following three properties simultaneously:
22. C – Consistency: All nodes return the same (most recent) data at the same time.
23. A – Availability: Every request receives a response (though it may not be the latest
data).
24. P – Partition Tolerance: System continues operating even when network partition
(failure) occurs.
MongoDB and CAP:
MongoDB is a CP database (Consistent + Partition Tolerant):
• Ensures consistency – all reads reflect the latest write.
• Uses Primary-Secondary replication: only the primary node accepts writes.
• During network partition, MongoDB sacrifices availability to maintain consistency.
 • If primary fails, it elects a new primary – briefly unavailable during election.
Contrast: Cassandra is AP – prioritizes availability over consistency (eventually consistent).

Q6. Write short notes on Columnar Data Model of NoSQL. [5 Marks] [5 Marks]

A Columnar (Wide-Column) database organizes data column by column instead of row by

row. This is different from both RDBMS (row-based) and document databases.
Key Concepts:
25. Keyspace: Top-level namespace (equivalent to a database in SQL).
26. Column Family: Grouped set of columns (like a table but highly flexible).
27. Row Key: Unique identifier for each row.
28. Column: A name-value pair, optionally with a timestamp.
29. Wide Rows: A single row can have millions of different columns.
Advantages:
• Efficient for analytical queries – reads only required columns.
• Better data compression (same-type values stored together).
• Excellent for time-series data (timestamp as column name).
Examples: Apache Cassandra (AP), HBase (CP)

Q7. Compare and contrast Key-Value Store and Document Database in detail. Explain
use cases and limitations of both. [10 Marks] [5 Marks]
Introduction:
Both Key-Value stores and Document databases are popular NoSQL database types. While
they share some common traits (schema-less, scalable, distributed), they differ significantly
in data modeling, querying capability, and use cases.
KEY-VALUE STORE:
Model: Simple key → value mapping. The value is opaque (database doesn't look inside).
Supports only GET, PUT, DELETE operations. The key is always unique.
Best Use Cases:
• Caching (Redis) – Cache expensive DB query results.
• Session Management – Store login sessions with TTL.
• Leaderboards, Counters – Fast increment/decrement.
Limitations:
• Cannot query inside values – no filtering by content.
• No support for relationships, joins, or transactions across keys.
DOCUMENT DATABASE:
Model: Stores structured JSON/BSON documents with unique _id. Database understands
internal structure. Supports rich queries, aggregations, secondary indexes, and nested data.
Best Use Cases:
• E-Commerce product catalog – varied attributes per product.
• Content Management Systems – blog posts, articles.
• User profiles with complex nested data.
Limitations:
• Limited join support across collections.
• Not ideal for highly relational or strictly structured data.
• Financial ACID transactions are limited across multiple documents.
Conclusion: Key-Value stores excel in speed for simple lookups; Document
databases excel in flexibility and rich querying. The right choice depends on whether
you need to query inside the stored data.

Q8. What are the suitable use cases for Document Databases? When should they NOT
be used? [5 Marks] [5 Marks]
Suitable Use Cases (WHEN TO USE):
30. Content Management Systems (CMS): Articles, blog posts, pages with varying fields.
31. E-Commerce Product Catalog: Products with varied attributes (clothing has
size/color; electronics have specs).
32. User Profiles: Complex nested user data with preferences, address, and history.
33. Mobile Applications: Schema-free development allows rapid iteration.
34. IoT Data: Sensor readings with varying fields per device type.
35. Gaming: Player profiles, inventory, game state – all nested in one document.
When NOT to Use:
36. Highly Relational Data: Many inter-table relationships are better handled by RDBMS.
37. Complex Multi-Document Transactions: Financial systems needing full ACID.
38. BI / Analytical Reporting: OLAP systems like Redshift or BigQuery are better.
39. Simple Key-Based Access Only: Overkill – a Key-Value store would be faster and
simpler.

Q9. Define: (a) NoSQL (b) CAP Theorem (c) Partition Tolerance (d) Eventual
Consistency [2 Marks Each] [5 Marks]
(a) NoSQL:
NoSQL (Not Only SQL) refers to databases that do not follow the traditional relational model.
They store data in key-value pairs, documents, columns, or graphs. Designed for scale,
speed, and flexibility.
(b) CAP Theorem:
States that a distributed system can provide at most 2 of 3 guarantees: Consistency,
Availability, and Partition Tolerance.
(c) Partition Tolerance:
The ability of a distributed system to continue operating even when network communication
between some nodes fails (network partition).
(d) Eventual Consistency:
A consistency model where data updates eventually propagate to all nodes – data may be
temporarily inconsistent but will become consistent over time. Used by AP databases like
Cassandra.

Q10. Explain the differences between SQL and NoSQL databases. [5 Marks] [5 Marks]

Feature SQL (Relational) NoSQL

Data Model Tables (rows & columns) Documents, Key-Value, Columns,
Graph
Schema Fixed, predefined schema Flexible / Schema-free
Scalability Vertical (scale up hardware) Horizontal (add more nodes)
 ACID Full ACID compliance Limited (some support partial
ACID)
Query Language SQL (standard) Varies by DB (MongoDB uses
MQL)
Relationships Foreign keys, JOINs Embedding or references
Best For Structured, relational data Big data, unstructured, rapid dev
Examples MySQL, PostgreSQL, Oracle MongoDB, Redis, Cassandra

Q11. What are the advantages of NoSQL over traditional databases? [5 Marks] [5
Marks]

40. Horizontal Scalability: NoSQL databases scale out by adding more servers (nodes),
making them ideal for handling massive data volumes and high traffic. SQL databases
typically scale up (expensive hardware upgrades).
41. Flexible Schema: No fixed schema means you can change data structure without
painful migrations. Great for agile development and evolving requirements.
42. High Performance: Optimized for specific access patterns – key-value stores offer
O(1) reads; columnar DBs offer fast analytics.
43. Handles Unstructured Data: Can store semi-structured (JSON) or unstructured data
(blobs, text) natively.
44. High Availability & Fault Tolerance: Built-in replication across multiple nodes ensures
data is always accessible even if some nodes fail.
45. Cost Effective: Runs on commodity hardware and open-source software, reducing
infrastructure costs.
PART C: QUICK REVISION CHEAT SHEET

⚡ Read this the morning before your exam for quick recall!

Key-Value Store – Remember: FAST but SIMPLE

• Key → Value (opaque). No querying inside value.
• 3 operations: GET, PUT, DELETE
• Use for: Cache, Sessions, Cart, Leaderboard, Counters
• Do NOT use for: Complex queries, Relationships, Analytics
• Examples: Redis, DynamoDB, Riak, Memcached

Document Database – Remember: FLEXIBLE and QUERYABLE

• Stores JSON/BSON documents with unique _id
• CAN query inside documents. Supports nested arrays & objects
• Use for: CMS, E-commerce, User Profiles, IoT, Gaming, Mobile Apps
• Do NOT use for: Complex joins, Full ACID, BI/Reporting
• Examples: MongoDB, CouchDB, Firebase Firestore

CAP Theorem – Remember: Pick 2 of 3

• C = Consistency (all nodes same data)
• A = Availability (always responds)
• P = Partition Tolerance (works despite network failure)
• MongoDB = CP | Cassandra = AP | You cannot have all 3

Columnar Database – Remember: COLUMN by COLUMN

• Stores data column-wise (not row-wise)
• Best for Analytics, Time-series data, Compression
• Examples: Cassandra (AP), HBase (CP)

NoSQL Types Summary

Type Best For Examples

Key-Value Cache, Sessions, Fast lookups Redis, DynamoDB

Document CMS, E-commerce, Profiles MongoDB, CouchDB
Columnar Analytics, Time-series Cassandra, HBase
Graph Social networks, Recommendations Neo4j

✨ ALL THE BEST FOR YOUR EXAM! ✨

You've got this! 🚀 Study smart, recall clearly, write confidently.