NoSQL Databases

Document stores store data as flexible, JSON-like documents.

Document Store Concepts

Document: Self-contained unit of data
Collection: Group of documents (like table)
Database: Group of collections

Document:
{
  "_id": "user123",
  "name": "Alice",
  "email": "alice@example.com",
  "address": {
    "street": "123 Main St",
    "city": "New York"
  },
  "hobbies": ["reading", "hiking"]
}

MongoDB Example

// Insert
db.users.insertOne({
  name: "Alice",
  email: "alice@example.com",
  address: { street: "123 Main St", city: "NYC" }
});

// Query
db.users.find({ "address.city": "NYC" });

// Update
db.users.updateOne(
  { _id: ObjectId("...") },
  { $set: { "address.city": "Boston" } }
);

// Aggregation
db.orders.aggregate([
  { $group: { _id: "$userId", total: { $sum: "$amount" } } }
]);

Document Store Use Cases

MongoDB Features

- Rich query language
- Indexing (single, compound, text)
- Aggregation framework
- Replication ( Replica Sets)
- Sharding
- ACID transactions (since 4.0)

When to Use Document Stores

Use when:
- Data is semi-structured
- Schema changes frequently
- Need fast reads/writes
- Flexible querying needed
- Horizontal scaling required

Avoid when:
- Complex joins required
- Strong ACID needed
- Data is highly relational

Key-value stores are the simplest NoSQL databases.

Key-Value Concepts

Key: Unique identifier
Value: Any data (string, JSON, binary)

Operations:
- GET(key) → value
- PUT(key, value)
- DELETE(key)

Redis Example

-- Strings
SET user:123:name "Alice"
GET user:123:name

-- Hashes
HSET user:123 name "Alice" email "a@b.com"
HGET user:123 name

-- Lists
LPUSH notifications "msg1" "msg2"
RPOP notifications

-- Sets
SADD friends:user123 "user456" "user789"
SMEMBERS friends:user123

-- Sorted Sets
ZADD leaderboard 100 "player1" 200 "player2"
ZREVRANGE leaderboard 0 9

Key-Value Store Use Cases

Redis vs Memcached

When to Use Key-Value

Use when:
- Simple data model
- High throughput needed
- Low latency critical
- Data fits in memory

Avoid when:
- Complex queries needed
- Data larger than memory
- Complex relationships

Column-family stores organize data by columns, not rows.

Column-Family Concepts

Row Key: Unique identifier
Column Family: Group of columns
Column: Name-value pair

Row Key → Column Family → Column → Value

Example:
user:123 →
  personal: name=Alice, email=a@b.com
  activity: last_login=2024-01-15, login_count=42

Cassandra Example

-- Create table
CREATE TABLE users (
  user_id UUID PRIMARY KEY,
  name TEXT,
  email TEXT,
  created_at TIMESTAMP
);

-- Insert
INSERT INTO users (user_id, name, email)
VALUES (uuid(), 'Alice', 'alice@example.com');

-- Query (must use partition key)
SELECT * FROM users WHERE user_id = ?;

-- Query by secondary index
SELECT * FROM users WHERE email = 'alice@example.com';

Cassandra Features

- High write throughput
- Linear horizontal scaling
- Tunable consistency
- No single point of failure
- CQL (SQL-like query language)
- Time-series optimized

Column-Family Use Cases

When to Use Column-Family

Use when:
- Write-heavy workloads
- High availability needed
- Time-series data
- Linear scalability required

Avoid when:
- Complex joins needed
- ACID transactions required
- Read-heavy with complex queries

Graph databases store data as nodes and relationships.

Graph Concepts

Nodes: Entities (users, products)
Relationships: Connections between nodes
Properties: Attributes on nodes/relationships

Example:
(Alice)──FOLLOWS──→(Bob)
  │                   │
  │                   │
LIKES              LIKES
  │                   │
  ▼                   ▼
(Post1)            (Post2)

Neo4j Example

// Create nodes
CREATE (alice:Person {name: 'Alice', age: 25})
CREATE (bob:Person {name: 'Bob', age: 30})

// Create relationship
CREATE (alice)-[:FOLLOWS]->(bob)
CREATE (alice)-[:LIKES]->(post1)

// Query: Friends of friends
MATCH (me:Person {name: 'Alice'})-[:FOLLOWS]->(friend)-[:FOLLOWS]->(fof)
WHERE NOT (me)-[:FOLLOWS]->(fof) AND me <> fof
RETURN fof.name

// Query: Shortest path
MATCH path = shortestPath(
  (alice:Person {name: 'Alice'})-[*]-(charlie:Person {name: 'Charlie'})
)
RETURN path

Graph Database Use Cases

When to Use Graph Databases

Use when:
- Data has many relationships
- Relationship queries are common
- Path finding needed
- Pattern matching required

Avoid when:
- Data is tabular
- Simple CRUD operations
- High write throughput needed