No-SQL Unit 3: Complete Concepts Guide

1. Introduction to Key-Value StoresCopy Anchor Link

1.1 What is a Key-Value Store?Copy Anchor Link

A key-value store is a type of NoSQL database that stores data as simple key-value pairs. Each key is unique and is used to retrieve the associated value. It is highly scalable, fast, and works well for simple lookups.

1.2 How It WorksCopy Anchor Link

1.3 Real-World ExamplesCopy Anchor Link

1. E-commerce — Shopping Cart Key-value stores are often used to store shopping cart data for each user. The user ID can be the key, and the cart items can be the value.

Key: cart:user123
Value: ["item1", "item2", "item3"]

2. Caching — User Sessions Key-value stores are widely used for caching user session data in web applications. The session ID is the key and the session information is the value.

Key: session:abc123
Value: { "user_id": 101, "status": "active" }

1.4 Advantages of Key-Value StoresCopy Anchor Link

2. Redis — IntroductionCopy Anchor Link

2.1 What is Redis?Copy Anchor Link

Redis (Remote Dictionary Server) is an open-source, in-memory key-value store. It is widely used for caching, session management, real-time analytics, and message queuing. Redis supports multiple data structures beyond simple strings.

2.2 Why Redis?Copy Anchor Link

• In-memory: Extremely fast (microsecond latency)
• Data structures: Strings, Lists, Sets, Hashes, Sorted Sets, Streams
• Persistence: RDB snapshots and AOF logs
• Replication: Master-replica replication
• Pub/Sub: Messaging patterns
• Transactions: MULTI/EXEC blocks
• TTL: Automatic key expiration

2.3 Redis Data Structures OverviewCopy Anchor Link

3. Redis Data StructuresCopy Anchor Link

3.1 StringCopy Anchor Link

A simple key-value pair where the value is a string (text, number, or binary data).

Redis Commands:

SET user:101 "Ananya"
GET user:101                    # Returns "Ananya"
INCR counter                    # Increase by 1
DECR counter                    # Decrease by 1

Example Use Case: Store user names, configuration settings, counters.

3.2 ListCopy Anchor Link

An ordered collection of string elements that allows insertion and removal from both ends (like a queue or stack).

Structure:

Left ← [A] [B] [C] [D] → Right

Redis Commands:

LPUSH notifications "msg1"      # Add to left
LPUSH notifications "msg2"
RPUSH notifications "msg3"      # Add to right
LRANGE notifications 0 -1       # Get all
# Returns ["msg2", "msg1", "msg3"]
LPOP notifications               # Remove from left
RPOP notifications               # Remove from right

Example Use Case: Maintain recent activity logs, message queues, notification lists.

3.3 SetCopy Anchor Link

An unordered collection of unique string elements (no duplicate values).

Structure:

    A
  B   C

Redis Commands:

SADD tags "redis"
SADD tags "nosql"
SADD tags "database"
SMEMBERS tags                   # Returns all
# ["redis", "nosql", "database"]
SISMEMBER tags "redis"          # Check membership
SINTER tags otherSet            # Intersection

Example Use Case: Store unique items such as tags, user IDs, or followers.

3.4 HashCopy Anchor Link

A collection of field-value pairs (like a dictionary or map) suitable for storing objects.

Structure:

Key: user:101
┌──────────┬──────────────────┐
│ Field    │ Value            │
├──────────┼──────────────────┤
│ name     │ Ananya           │
│ age      │ 25               │
│ email    │ ananya@gcu.edu   │
│ role     │ faculty          │
└──────────┴──────────────────┘

Redis Commands:

HSET user:101 name "Ananya"
HSET user:101 age 25
HGET user:101 name              # Returns "Ananya"
HGETALL user:101                # Get all fields
HINCRBY user:101 age 1          # Increment numeric field

Example Use Case: Store user profiles, product details, or application settings.

3.5 Sorted Set (ZSet)Copy Anchor Link

A collection of unique elements, each with an associated score. Elements are automatically ordered by their score.

Structure:

┌─────────┬───────┐
│ Member  │ Score │
├─────────┼───────┤
│ Charlie │ 60    │
│ Bob     │ 80    │
│ Alice   │ 100   │
└─────────┴───────┘

Redis Commands:

ZADD leaderboard 100 "Alice"
ZADD leaderboard 80 "Bob"
ZADD leaderboard 60 "Charlie"
ZRANGE leaderboard 0 -1 WITHSCORES
# Returns ["Charlie", 60, "Bob", 80, "Alice", 100]
ZREVRANGE leaderboard 0 -1      # Descending order
ZSCORE leaderboard "Alice"      # Get score

Example Use Case: Leaderboards, rankings, priority queues, or scheduling.

3.6 StreamCopy Anchor Link

An append-only log-like structure for events.

Redis Commands:

XADD mystream * event "login" user "Rahul"
XREAD COUNT 10 STREAMS mystream 0
XRANGE mystream - +

Example Use Case: Event sourcing, activity feeds, real-time analytics.

4. Redis Key ManagementCopy Anchor Link

4.1 Create a Key (SET)Copy Anchor Link

SET username "Ananya"
# 127.0.0.1:6379> SET username "Ananya"
# OK

If the key already exists, SET will update its value.

4.2 Retrieve a Value (GET)Copy Anchor Link

GET username
# 127.0.0.1:6379> GET username
# "Ananya"

Returns the value stored at the key. If the key does not exist, returns (nil).

4.3 Set Expiry (EXPIRE)Copy Anchor Link

EXPIRE username 60
# 127.0.0.1:6379> EXPIRE username 60
# (integer) 1

The key will be automatically deleted after the specified time (in this case, 60 seconds).

4.4 Check TTL (TTL)Copy Anchor Link

TTL username
# 127.0.0.1:6379> TTL username
# (integer) 42

Returns the remaining time in seconds.

• 1: key exists but has no expiry
• 2: key does not exist

4.5 Common Key CommandsCopy Anchor Link

5. Redis TransactionsCopy Anchor Link

5.1 What is a Redis Transaction?Copy Anchor Link

A Redis transaction groups multiple commands into a single atomic unit. Commands are queued and executed together.

5.2 MULTI — Start a TransactionCopy Anchor Link

MULTI puts Redis into transaction mode. All subsequent commands are queued instead of being executed immediately. Redis replies with “QUEUED” for each command.

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SET user:1 "Ananya"
QUEUED
127.0.0.1:6379(TX)> INCR login_count
QUEUED
127.0.0.1:6379(TX)> EXPIRE user:1 3600
QUEUED

5.3 EXEC — Execute All Queued CommandsCopy Anchor Link

EXEC executes all the queued commands in the order they were added. All commands are executed as a single atomic unit. Returns an array with the result of each command.

127.0.0.1:6379(TX)> EXEC
1) OK
2) (integer) 1
3) (integer) 1

Important: If EXEC is called, all queued commands are executed, even if one of them fails (runtime errors do not rollback).

5.4 WATCH — Optimistic LockingCopy Anchor Link

WATCH monitors one or more keys for changes by other clients. If any watched key is modified before EXEC, the transaction is aborted (EXEC returns nil). Useful for implementing optimistic locking.

127.0.0.1:6379> WATCH balance:100
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> DECRBY balance:100 50
QUEUED
127.0.0.1:6379(TX)> EXEC
(nil)   # if balance:100 was modified by another client

5.5 DISCARD — Cancel TransactionCopy Anchor Link

127.0.0.1:6379(TX)> DISCARD
OK

5.6 Transaction Use CaseCopy Anchor Link

Transfer money between two accounts (ensure both debit and credit happen together).

MULTI
DECRBY account:A 1000
INCRBY account:B 1000
EXEC

5.7 Key TakeawaysCopy Anchor Link

Important: Redis transactions provide atomicity, but do not rollback on runtime errors. They are simple, fast, and useful for ensuring data consistency.

6. Caching Strategies — Cache-AsideCopy Anchor Link

6.1 What is Cache-Aside?Copy Anchor Link

The Cache-Aside strategy (Lazy Loading) means the application is responsible for loading data into the cache. Data is fetched from the cache first; if not found, it is loaded from the database and then stored in the cache for future requests.

6.2 How It WorksCopy Anchor Link

1. Application checks the cache for the data.
2. If found (cache hit), return directly from cache.
3. If not found (cache miss), fetch from database.
4. Store the data in cache (with TTL) and return to client.

6.3 Read Flow (Cache Miss)Copy Anchor Link

Client → Application → Redis Cache → (not found) → Database
                ↓
           Store in cache (with TTL)
                ↓
           Return data to client

After the first request, the data is cached, so subsequent requests will be faster.

6.4 Read Flow (Cache Hit)Copy Anchor Link

Client → Application → Redis Cache → (found) → Return data (fast response)

6.5 Write Flow (Cache-Aside)Copy Anchor Link

Application → Update database → Invalidate/delete cache entry

On write, the application updates the database first, then invalidates (or deletes) the cache entry so the next read will load fresh data.

6.6 Example: E-commerce Product DetailsCopy Anchor Link

When a user views a product (e.g., product ID 101), the application first checks Redis. If not found, it fetches the product details from the database, stores it in Redis (e.g., for 5 minutes), and returns it to the user.

Product ID: 101
Name: Running Shoes
Price: ₹2,999
Stock: 50
Cached for 5 minutes

6.7 Key BenefitsCopy Anchor Link

6.8 Things to ConsiderCopy Anchor Link

7. Column-Family Store (Wide-Column Store)Copy Anchor Link

7.1 What is a Column-Family Store?Copy Anchor Link

A column-family store is a type of NoSQL database that stores data in column families (groups of columns) rather than fixed tables with rows and columns. It is optimized for large-scale, distributed storage and high write/read throughput.

7.2 Key CharacteristicsCopy Anchor Link

• Stores data in column families, which are collections of columns
• Each row can have a different set of columns (sparse data)
• Designed to handle very large datasets across multiple machines
• Optimized for fast reads and writes of large amounts of data
• Examples: Apache Cassandra, HBase, Amazon DynamoDB (wide-column model)

7.3 Example: Column-Family StoreCopy Anchor Link

Table: users (Column Family)

Each row can have a different set of columns. Missing values are not stored (sparse storage).

7.4 Comparison with Relational DatabaseCopy Anchor Link

Relational Table: users

All rows follow the same fixed schema (same columns). Missing values are stored as NULL.

7.5 Key DifferencesCopy Anchor Link

7.6 When to Use a Column-Family Store?Copy Anchor Link

Use a Column-Family Store when:

• You need to store and manage very large amounts of data
• Your data is sparse or has changing attributes
• You need high write and read throughput and horizontal scalability
• Examples: Cassandra, HBase, DynamoDB

7.7 When to Use a Relational Database?Copy Anchor Link

Use a Relational Database when:

• You need complex queries and joins
• Your data is highly structured and consistent
• You need ACID transactions
• Examples: MySQL, PostgreSQL, Oracle, SQL Server

Key Takeaway: Column-Family Stores offer flexibility and scale, while Relational Databases provide structure and strong transactional support.

8. Apache Cassandra — Core ConceptsCopy Anchor Link

8.1 NodeCopy Anchor Link

A node is a single instance of Cassandra running on a machine (physical or virtual). Each node stores a portion of the data (data partitions). Nodes are equal — there is no master or slave.

┌─────────────────────┐
│ Node                │
│ (Cassandra instance)│
└─────────────────────┘

8.2 ClusterCopy Anchor Link

A cluster is a group of nodes that work together to store and manage data. All nodes in a cluster are peer-to-peer (equal). Provides high availability, fault tolerance, and horizontal scalability.

Cassandra Cluster
┌──────┐ ┌──────┐ ┌──────┐     ┌──────┐
│Node 1│ │Node 2│ │Node 3│ ... │Node N│
└──────┘ └──────┘ └──────┘     └──────┘

8.3 KeyspaceCopy Anchor Link

A keyspace is a top-level container (similar to a database in relational systems). It defines replication settings and contains one or more tables (column families). You must create a keyspace before creating tables.

Keyspace: ecom
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Table    │ │ Table    │ │ Table    │
│ users    │ │ orders   │ │ products │
└──────────┘ └──────────┘ └──────────┘

8.4 PartitionCopy Anchor Link

A partition is a subset of the total data, identified by a partition key. Rows with the same partition key are stored together in the same partition. Cassandra distributes (hashes) partitions across nodes in the cluster.

Partition Key (e.g., user_id = 101)
        ↓
┌─────────────────┐
│ Partition       │
│  Row 1          │
│  Row 2          │
│  Row 3          │
│  ...            │
└─────────────────┘

8.5 Replication Factor (RF)Copy Anchor Link

The replication factor defines how many copies of each partition are stored across different nodes in the cluster. Helps with fault tolerance and high availability.

Example: If RF = 3, each partition is stored on 3 different nodes (ideally in different racks/data centers). You can set the replication factor at the keyspace level.

        Node 1 (Replica)
           ↑
    ┌──────┴──────┐
Node 4 │  RF = 3   │ Node 2 (Replica)
(Other │3 copies of│
 data) │each part. │
    └──────┬──────┘
           ↓
        Node 3 (Replica)

8.6 Cassandra Data Model HierarchyCopy Anchor Link

Cluster (Collection of nodes)
    ↓
Keyspace (Like a database)
    ↓
Table (Stores rows of data)

9. CQL — Cassandra Query LanguageCopy Anchor Link

9.1 What is CQL?Copy Anchor Link

CQL (Cassandra Query Language) is the query language used to interact with Apache Cassandra. It is similar to SQL, but designed for distributed, scalable, NoSQL data storage. CQL allows us to define the data structure (keyspaces, tables) and perform operations like insert, select, update, and delete.

9.2 CQL vs SQL (Quick Comparison)Copy Anchor Link

9.3 Basic CQL CommandsCopy Anchor Link

a) Create a KeyspaceCopy Anchor Link

CREATE KEYSPACE university
WITH replication = {
    'class': 'SimpleStrategy',
    'replication_factor': 3
};

• Keyspace name: university
• Replication strategy: SimpleStrategy
• Replication factor: 3 (number of copies stored across nodes)

b) Use a KeyspaceCopy Anchor Link

USE university;

c) Create a TableCopy Anchor Link

CREATE TABLE students (
    student_id int,
    name text,
    department text,
    age int,
    PRIMARY KEY (student_id)
);

• Table name: students
• student_id is the primary key (which uniquely identifies each row)

d) Insert DataCopy Anchor Link

INSERT INTO students (student_id, name, department, age)
VALUES (1, 'Ananya', 'CSE', 20);

e) Query DataCopy Anchor Link

SELECT * FROM students;
SELECT * FROM students WHERE student_id = 1;

f) Update DataCopy Anchor Link

UPDATE students SET age = 21 WHERE student_id = 1;

g) Delete DataCopy Anchor Link

DELETE FROM students WHERE student_id = 1;

9.4 Verify the CreationCopy Anchor Link

-- View keyspaces
DESCRIBE KEYSPACES;

-- View tables in the current keyspace
DESCRIBE TABLES;

-- View table structure
DESCRIBE TABLE students;

Tip: Always create a keyspace first and then create tables inside it.

10. Unit SummaryCopy Anchor Link

NoSQL UNIT 3 — REDIS, COLUMN-FAMILY STORES & CASSANDRA
│
├── Key-Value Stores
│   ├── Definition and structure
│   ├── Real-world examples (cart, session)
│   └── Advantages
│
├── Redis — Introduction
│   ├── In-memory key-value store
│   ├── Data structures overview
│   └── Use cases
│
├── Redis Data Structures
│   ├── String (SET, GET, INCR, DECR)
│   ├── List (LPUSH, RPUSH, LPOP, RPOP, LRANGE)
│   ├── Set (SADD, SMEMBERS, SISMEMBER, SINTER)
│   ├── Hash (HSET, HGET, HGETALL, HINCRBY)
│   ├── Sorted Set (ZADD, ZRANGE, ZREVRANGE, ZSCORE)
│   └── Stream (XADD, XREAD, XRANGE)
│
├── Redis Key Management
│   ├── SET / GET
│   ├── EXPIRE / TTL
│   └── Common key commands
│
├── Redis Transactions
│   ├── MULTI (start)
│   ├── EXEC (execute)
│   ├── WATCH (optimistic locking)
│   ├── DISCARD (cancel)
│   └── Use case: money transfer
│
├── Caching — Cache-Aside
│   ├── Lazy loading strategy
│   ├── Read flow (hit/miss)
│   ├── Write flow (invalidate)
│   ├── E-commerce example
│   ├── Benefits
│   └── Considerations
│
├── Column-Family Store
│   ├── Definition (wide-column)
│   ├── Sparse storage
│   ├── Examples (Cassandra, HBase, DynamoDB)
│   ├── Comparison with RDBMS
│   └── When to use
│
├── Apache Cassandra — Core Concepts
│   ├── Node
│   ├── Cluster
│   ├── Keyspace
│   ├── Partition
│   ├── Partition Key
│   ├── Replication Factor
│   └── Data model hierarchy
│
└── CQL — Cassandra Query Language
    ├── CQL vs SQL
    ├── CREATE KEYSPACE
    ├── USE
    ├── CREATE TABLE
    ├── INSERT / SELECT / UPDATE / DELETE
    └── DESCRIBE commands

11. Key Commands — Quick ReferenceCopy Anchor Link

Redis CommandsCopy Anchor Link

CQL CommandsCopy Anchor Link

12. Exam-Focused PointsCopy Anchor Link

1. Key-value store — Simple key → value mapping; fast lookups.
2. Redis — In-memory key-value store with multiple data structures.
3. Redis data structures — String, List, Set, Hash, Sorted Set, Stream.
4. String commands — SET, GET, INCR, DECR.
5. List commands — LPUSH, RPUSH, LPOP, RPOP, LRANGE.
6. Set commands — SADD, SMEMBERS, SISMEMBER, SINTER.
7. Hash commands — HSET, HGET, HGETALL, HINCRBY.
8. Sorted Set commands — ZADD, ZRANGE, ZREVRANGE, ZSCORE.
9. Key expiry — EXPIRE, TTL, PERSIST.
10. Redis transactions — MULTI, EXEC, WATCH, DISCARD.
11. WATCH — Optimistic locking; aborts transaction if key changes.
12. Cache-Aside — Application manages cache; read: check cache → DB → cache; write: update DB → invalidate cache.
13. Column-family store — Wide-column; sparse; flexible schema; horizontally scalable.
14. Cassandra vs RDBMS — No joins vs joins; eventual vs strong consistency; distributed vs single server.
15. Cassandra node — Single instance; peer-to-peer; no master.
16. Cassandra cluster — Group of nodes; high availability.
17. Keyspace — Top-level container (like database).
18. Partition — Subset of data identified by partition key.
19. Partition key — Determines data distribution across nodes.
20. Replication factor — Number of copies of each partition.
21. CQL — Cassandra Query Language; similar to SQL but for NoSQL.
22. CQL vs SQL — Keyspace vs database; no joins; eventual consistency.
23. CREATE KEYSPACE — Defines replication strategy and factor.
24. USE — Switch to a keyspace.
25. CREATE TABLE — Defines table with primary key.
26. DESCRIBE — View keyspaces, tables, and structure.
27. Cache hit vs cache miss — Found in cache vs not found.
28. TTL — Time-to-live for cache entries.
29. Cache invalidation — Delete/update cache on data changes.
30. Sparse storage — Missing values not stored in column-family stores.

13. Glossary of Key TermsCopy Anchor Link