NoSQL Data Modeling

SET user:42:session "eyJhbGciOiJIUzI1NiJ9..."   → OK
GET user:42:session                                → "eyJhbGciOiJIUzI1NiJ9..."

SET product:99:price "29.99"                       → OK
GET product:99:price                               → "29.99"

SETEX rate_limit:ip:192.168.1.1 60 "47"           → OK (expires in 60s)
GET rate_limit:ip:192.168.1.1                      → "47"

Key design matters:
  ✅ user:42:session     → namespaced, readable
  ❌ abc123              → meaningless, unmaintainable

The value can be anything:
  → String, JSON blob, binary data, serialized object
  → The database doesn't inspect or index the value
  → All queries are by key — that's it

// User document — self-contained, nested data
{
  "_id": "user_42",
  "name": "Alice Smith",
  "email": "alice@example.com",
  "address": {
    "street": "123 Main St",
    "city": "Seattle",
    "state": "WA",
    "zip": "98101"
  },
  "orders": [
    {
      "id": "order_101",
      "total": 59.99,
      "status": "delivered",
      "items": [
        { "product": "Keyboard", "qty": 1, "price": 59.99 }
      ]
    }
  ],
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

// Product document — different structure, same collection
{
  "_id": "product_99",
  "name": "Mechanical Keyboard",
  "price": 59.99,
  "category": "Electronics",
  "specs": {
    "switches": "Cherry MX Blue",
    "layout": "TKL",
    "backlight": "RGB"
  },
  "reviews_count": 1247,
  "avg_rating": 4.6
}

Table: sensor_readings
Partition Key: sensor_id
Clustering Key: timestamp (sorted)

Row key: sensor_42
  ┌──────────────────────────────────────────────────┐
  │ timestamp          │ temperature │ humidity │ pressure │
  ├────────────────────┼─────────────┼──────────┼──────────┤
  │ 2025-01-15T10:00   │ 22.5        │ 45       │          │
  │ 2025-01-15T10:01   │ 22.6        │          │ 1013.2   │
  │ 2025-01-15T10:02   │ 22.4        │ 46       │ 1013.1   │
  └──────────────────────────────────────────────────┘

Row key: sensor_99
  ┌──────────────────────────────────────────────────┐
  │ timestamp          │ temperature │ wind_speed │
  ├────────────────────┼─────────────┼────────────┤
  │ 2025-01-15T10:00   │ 18.2        │ 12.5       │
  │ 2025-01-15T10:01   │ 18.3        │ 11.8       │
  └──────────────────────────────────────────────────┘

Key concepts:
  → Partition key (sensor_id) determines which node stores the data
  → Clustering key (timestamp) determines sort order within a partition
  → Each row can have different columns (sparse)
  → Reads within a partition are sequential (fast)
  → Writes are append-only (extremely fast)

// Create nodes
CREATE (alice:Person {name: "Alice", age: 30})
CREATE (bob:Person {name: "Bob", age: 28})
CREATE (google:Company {name: "Google", founded: 1998})

// Create relationships (edges)
CREATE (alice)-[:FOLLOWS]->(bob)
CREATE (alice)-[:WORKS_AT {since: 2020}]->(google)
CREATE (bob)-[:WORKS_AT {since: 2019}]->(google)

// Query: Who does Alice follow?
MATCH (alice:Person {name: "Alice"})-[:FOLLOWS]->(friend)
RETURN friend.name
→ "Bob"

// Query: Friends of friends (2 hops)
MATCH (alice:Person {name: "Alice"})-[:FOLLOWS]->()-[:FOLLOWS]->(fof)
WHERE fof <> alice
RETURN fof.name

// Query: Shortest path between Alice and someone
MATCH path = shortestPath(
  (alice:Person {name: "Alice"})-[*]-(target:Person {name: "Eve"})
)
RETURN path

// This is where graph DBs shine:
// In SQL, each "hop" requires another JOIN
// In a graph DB, traversal depth doesn't affect query complexity