Tutorial 3.1: NoSQL Fundamentals

Overview

NoSQL databases emerged to address the limitations of relational databases in handling massive scale, flexible data models, and high‑velocity data. In this tutorial, you will explore the four main NoSQL families — Document, Key‑Value, Column‑Family, and Graph — understand their trade‑offs, and learn when to choose each one.

Why this matters: Modern applications often require multiple data stores. Knowing the strengths of each NoSQL type helps you design polyglot persistence architectures that are both performant and cost‑effective.

1. Why NoSQL?

Relational databases (RDBMS) are excellent for structured data and strong consistency, but they face challenges with:

Scale‑out: Horizontal scaling (sharding) is complex and often manual.
Schema flexibility: Changing schema requires migrations and downtime.
High throughput: Billions of reads/writes per second can overwhelm a single node.

NoSQL databases trade ACID guarantees for BASE (Basically Available, Soft state, Eventual consistency) to achieve partition tolerance and high availability.

CAP Theorem revisited

In a distributed system, you can have at most two of: Consistency, Availability, Partition tolerance. NoSQL systems often choose AP (Availability + Partition tolerance) with eventual consistency, while some (like HBase) choose CP.

2. Document Stores (e.g., MongoDB)

Data is stored as documents (JSON‑like structures) with a flexible schema.

Schema‑less: Each document can have different fields.
Rich querying: Supports filters, projections, aggregations.
Indexing: Supports secondary indexes on any field.
Use cases: Content management, user profiles, catalogs, real‑time analytics.

                        // Example MongoDB document (user profile)
                        {
                        "_id": "alice123",
                        "name": "Alice",
                        "email": "alice@example.com",
                        "addresses": [
                        { "type": "home", "street": "123 Main St" }
                        ],
                        "preferences": { "theme": "dark" }
                        }
                    

3. Key‑Value Stores (e.g., Redis, DynamoDB)

The simplest NoSQL model: a distributed hash map.

Extremely fast: O(1) lookups.
Often in‑memory: Redis persists to disk but operates in RAM for microsecond latency.
Use cases: Session management, caching, leaderboards, distributed locks.

                        # Redis CLI examples
                        SET user:alice '{"name":"Alice","age":30}'
                        GET user:alice
                        INCR page_views:homepage
                    

4. Column‑Family & Graph Databases

4.1 Column‑Family (e.g., Cassandra, HBase)

Data is stored in rows and columns, but grouped into column families. Optimized for massive writes and wide rows.

Use cases: Time‑series data, IoT, logging, recommendation engines.

4.2 Graph Databases (e.g., Neo4j)

Data is stored as nodes (entities) and edges (relationships), with properties on both.

Use cases: Social networks, fraud detection, knowledge graphs, pathfinding.

                        // Cypher query (Neo4j)
                        MATCH (p:Person)-[:FRIENDS_WITH]->(friend)
                        WHERE p.name = 'Alice'
                        RETURN friend.name
                    

5. Choosing the Right Database

A quick decision guide:

Relational (PostgreSQL/MySQL): Strong consistency, complex joins, schema‑fixed, financial/ACID critical.
Document (MongoDB): Flexible schema, semi‑structured data, horizontal scale, JSON‑native.
Key‑Value (Redis): Ultra‑low latency, caching, counters, transient data.
Column‑Family (Cassandra): Massive write throughput, time‑series, wide‑row partitioning.
Graph (Neo4j): Highly interconnected data, relationship‑heavy queries.

In many modern architectures, you’ll use polyglot persistence – using multiple databases side‑by‑side for different workloads.

Quiz

Question 1

What does the 'A' stand for in the BASE model?

Atomicity
Availability
Accuracy
Agility

Show answer

B. Availability. BASE stands for Basically Available, Soft state, Eventual consistency.

Question 2

Which NoSQL type is most suitable for a social network's "friend recommendations" feature?

Document store
Key‑Value store
Graph database
Column‑family store

Show answer

C. Graph database. Relationships (edges) are first‑class citizens, making traversals fast and natural.

Question 3

Which database is typically used as a primary cache layer due to its in‑memory speed?

Cassandra
MongoDB
Redis
Neo4j

Show answer

C. Redis. It is a key‑value store that holds data in memory for sub‑millisecond latency.

Exercises

Exercise 1

A ride‑sharing application needs to store driver locations in real‑time, handle millions of updates per minute, and query nearby drivers. Which NoSQL database would you recommend and why?

Sample answer

Recommendation: Redis (with Geospatial indexes) or MongoDB with 2dsphere indexes.

Why: Both support real‑time geospatial queries. Redis offers extremely low latency and high write throughput, making it ideal for frequent location updates. MongoDB provides richer querying and persistence if needed.

Exercise 2

Explain the concept of "eventual consistency" and provide an example of where it is acceptable.

Sample answer

Eventual consistency: After an update, the system will eventually converge to a consistent state, but reads may see stale data for a short period.

Example: A social media like counter. If a user sees a like count that is a few seconds old, the user experience is not significantly impacted, and the system gains availability and partition tolerance.

Homework

Homework 1

Design a MongoDB schema for an e‑commerce product catalog that includes categories, attributes (e.g., size, color), and product reviews. Include sample documents and at least one index you would create to speed up queries.

Sample answer

Schema design: Embed attributes and reviews within the product document (denormalized for fast reads).

                                    {
                                    "_id": "prod_123",
                                    "name": "Wireless Headphones",
                                    "price": 99.99,
                                    "categories": ["Electronics", "Audio"],
                                    "attributes": { "color": "black", "size": "over-ear" },
                                    "reviews": [
                                    { "user": "alice", "rating": 5, "comment": "Great!", "date": "2026-09-01" }
                                    ]
                                    }
                                

Index: db.products.createIndex({ "categories": 1, "price": 1 }) – speeds up filtering by category and sorting by price.

Mini‑Project

Social Media Feed Design

Design a NoSQL data model for a social media feed. Consider:

Users, posts, and followers.
Need to generate a timeline of posts from followed users.
High write volume (posts) and high read volume (timeline).

Which NoSQL database would you choose? Provide a data model and explain your reasoning.

Sample design

Database choice: Apache Cassandra or DynamoDB (column‑family / wide‑row).

Model: Use a timeline table with partition key user_id and clustering key post_timestamp. When a user creates a post, it is written to the timeline of all their followers (fan‑out on write).

                                    CREATE TABLE timeline (
                                    user_id uuid,
                                    post_timestamp timestamp,
                                    post_id uuid,
                                    author_name text,
                                    content text,
                                    PRIMARY KEY (user_id, post_timestamp)
                                    ) WITH CLUSTERING ORDER BY (post_timestamp DESC);
                                

Reasoning: Cassandra handles massive write throughput and allows fast retrieval of a user's timeline (single partition read, sorted by time).

Tutorial Summary

You explored the landscape of NoSQL databases: document stores (MongoDB), key‑value stores (Redis), column‑family stores (Cassandra), and graph databases (Neo4j). You learned how they trade off ACID for BASE and partition tolerance, and when to apply each type. The exercises and mini‑project gave you practice in choosing the right tool for real‑world use cases.

Key takeaway: NoSQL is not a replacement for SQL but a complement. A mature data strategy often employs multiple databases, each optimised for specific workloads.