Collection Types in Cassandra

Answer:

• LIST: Ordered collection that allows duplicates. Example: ['a', 'b', 'a']. Use for: playlists, routes, history
• SET: Unordered collection of unique values. Example: {'a', 'b', 'c'}. Use for: tags, skills, categories
• MAP: Key-value pairs with unique keys. Example: {'name': 'John', 'age': 30}. Use for: attributes, settings, prices

Key Differences:

Use Collections when:

• Small datasets: Less than 100 items recommended
• Read together: Values are always accessed as a group
• Written together: Values updated as a unit
• No individual queries: Don't need to filter/search individual items

Use Separate Rows when:

• Large datasets: Thousands of items
• Individual queries: Need to search/filter specific items
• Independent updates: Items updated separately
• Range queries: Need to query by item attributes

Example:

-- ✅ GOOD: User's last 10 searches (small, read together)
recent_searches LIST<TEXT> = ['cassandra', 'nosql', 'database']

-- ❌ BAD: All user's orders (large, query individually)
-- Don't use: orders LIST<UUID>
-- Instead: Create orders_by_user table with proper partitioning

Answer:

Technical Limit: Collections can hold up to approximately 65,535 items (64KB per collection by default).

Recommended Limit: Keep collections under 100 items for optimal performance.

Why it matters:

• Read/Write Performance: Entire collection is read or written as one unit - large collections slow down operations
• Memory Pressure: Large collections require more memory to deserialize
• Network Overhead: Entire collection transferred over network
• Compaction Impact: Large collections make compaction less efficient

Performance Impact:

Collection Size | Read Time | Memory Usage
----------------|-----------|-------------
10 items        | 1-2ms     | ~10KB
100 items       | 5-10ms    | ~100KB    ← Recommended max
1,000 items     | 50-100ms  | ~1MB      ⚠️ Getting slow
10,000 items    | 500ms+    | ~10MB     ❌ Too large!

Solution for Large Data: Use separate rows with proper partitioning instead.

Answer: Collections are stored as multiple columns internally, not as serialized blobs.

LIST Storage:

-- Logical: songs = ['song1', 'song2', 'song3']
-- Physical:
column: songs:timeuuid1 → 'song1'
column: songs:timeuuid2 → 'song2'
column: songs:timeuuid3 → 'song3'
-- TimeUUID preserves order

SET Storage:

-- Logical: tags = {'java', 'python', 'cassandra'}
-- Physical:
column: tags:java → ''      (empty value)
column: tags:python → ''    (empty value)
column: tags:cassandra → '' (empty value)
-- Value is part of column name = no duplicates possible

MAP Storage:

-- Logical: prices = {'USD': 100, 'EUR': 90}
-- Physical:
column: prices:USD → 100
column: prices:EUR → 90
-- Allows partial updates!

Benefits of this storage model:

• Efficient partial updates (especially MAP)
• Tombstones only for deleted elements
• Leverages Cassandra's column-oriented storage

Answer: No, you cannot query individual collection elements.

What doesn't work:

-- ❌ These queries are NOT supported:
SELECT * FROM users WHERE interests CONTAINS 'coding';
SELECT * FROM products WHERE tags CONTAINS 'laptop';
SELECT * FROM orders WHERE items CONTAINS 'product-123';

Why not?

• Collections are stored within a single partition
• No secondary indexes on collection elements (by design)
• Would require full table scan = terrible performance
• Violates Cassandra's partition-first query model

Workaround - Denormalization:

-- Instead of querying collection, create reverse table:

-- Original table
CREATE TABLE users (
  user_id UUID PRIMARY KEY,
  interests SET<TEXT>
);

-- Add reverse lookup table
CREATE TABLE users_by_interest (
  interest TEXT,
  user_id UUID,
  PRIMARY KEY (interest, user_id)
);

-- Now you can query:
SELECT * FROM users_by_interest WHERE interest = 'coding';

Answer: Frozen collections are treated as a single immutable value, serialized as a blob.

Definition:

CREATE TABLE example (
  id UUID PRIMARY KEY,
  -- Regular collection (mutable)
  tags SET<TEXT>,
  
  -- Frozen collection (immutable)
  coordinates FROZEN<LIST<DOUBLE>>
);

Key Differences:

Use Frozen When:

• Need nested collections: FROZEN<MAP<TEXT, LIST<INT>>>
• Collection rarely changes (immutable data)
• Want entire collection as primary key
• Small collections (<10 items)

Example:

-- GPS coordinates (never partially updated)
coordinates FROZEN<LIST<DOUBLE>> = [37.7749, -122.4194]

-- Update requires replacing entire list:
UPDATE locations 
SET coordinates = [37.7849, -122.4094]
WHERE location_id = 123;

Answer: Nothing happens - the operation succeeds but the SET remains unchanged.

Example:

-- Initial state
interests = {'coding', 'music', 'travel'}

-- Try adding duplicate
UPDATE users
SET interests = interests + {'coding', 'gaming'}
WHERE user_id = 123;

-- Result:
interests = {'coding', 'music', 'travel', 'gaming'}
-- 'coding' was already there - ignored
-- 'gaming' was new - added

Why it works this way:

• SET stores elements as column names with empty values
• Same column name = overwrites (but value is empty anyway)
• Result: Idempotent operation - safe to retry
• No error thrown - this is by design

Practical Impact:

This makes SETs perfect for scenarios where you want to ensure uniqueness without checking first:

-- No need to check if tag exists - just add it!
UPDATE products
SET tags = tags + {'new-arrival'}
WHERE product_id = 456;

-- Safe to call multiple times
-- No "already exists" errors

Answer: Use the subtraction operator (-) to remove elements from a LIST.

-- Remove specific value (removes ALL occurrences!)
UPDATE user_playlists
SET songs = songs - ['Born to Run']
WHERE user_id = 123;

-- Remove multiple values
UPDATE user_playlists
SET songs = songs - ['song1', 'song2', 'song3']
WHERE user_id = 123;

⚠️ Important Gotcha:

The minus operator removes ALL occurrences of the value!

-- Initial list (note duplicates)
songs = ['song1', 'song2', 'song1', 'song3', 'song1']

-- Remove 'song1'
UPDATE ... SET songs = songs - ['song1'] ...

-- Result: ALL three 'song1' entries removed!
songs = ['song2', 'song3']

Alternative: Update by Index

-- Set specific index to null to "delete"
-- But this doesn't actually remove the element!
UPDATE user_playlists
SET songs[2] = null
WHERE user_id = 123;

-- Better approach: Read, modify in app, write back entire list

Best Practice:

If you need fine-grained control over LIST removal (e.g., remove only first occurrence), it's better to:

1. Read the current list
2. Modify it in application code
3. Write the entire updated list back

Answer: Only FROZEN collections can be used in primary keys.

-- ❌ NOT ALLOWED: Regular collection as primary key
CREATE TABLE invalid (
  user_id UUID,
  tags SET<TEXT>,
  PRIMARY KEY (user_id, tags)  -- ERROR!
);

-- ✅ ALLOWED: Frozen collection as primary key
CREATE TABLE valid (
  user_id UUID,
  tags FROZEN<SET<TEXT>>,
  PRIMARY KEY (user_id, tags)  -- OK!
);

Why frozen only?

• Primary keys must be immutable (frozen = immutable)
• Frozen collections serialize to a single comparable value
• Regular collections can change - would break partition/clustering

Real Use Case:

-- Composite key with coordinate pair
CREATE TABLE locations (
  location_id UUID,
  coordinates FROZEN<LIST<DOUBLE>>,
  name TEXT,
  PRIMARY KEY (location_id, coordinates)
);

-- Insert
INSERT INTO locations (location_id, coordinates, name)
VALUES (uuid(), [37.7749, -122.4194], 'San Francisco');

-- Query by exact coordinates
SELECT * FROM locations
WHERE location_id = ... 
AND coordinates = [37.7749, -122.4194];

Limitation:

You can only query by the exact frozen collection value - no partial matching or range queries.

Answer: Both store structured data but with different use cases and constraints.

MAP Example:

-- Flexible attributes (schema evolves)
CREATE TABLE products (
  id UUID PRIMARY KEY,
  attributes MAP<TEXT, TEXT>
);

-- Can add ANY key:
attributes = {
  'color': 'red',
  'size': 'large',
  'weight': '2kg',
  'custom_field_123': 'value'  -- Add new keys anytime!
}

UDT Example:

-- Fixed structure (typed fields)
CREATE TYPE address (
  street TEXT,
  city TEXT,
  zip INT,
  country TEXT
);

CREATE TABLE users (
  id UUID PRIMARY KEY,
  home_address FROZEN<address>
);

-- Must match structure:
home_address = {
  street: '123 Main St',
  city: 'San Francisco',
  zip: 94105,
  country: 'USA'
}

When to use MAP:

• Schema changes frequently
• Keys not known upfront
• Different items have different attributes

When to use UDT:

• Fixed structure (like addresses, coordinates)
• Need type safety
• Different field types

Answer: Collections have specific performance characteristics you need to understand.

Read Performance:

• Entire collection read: Even accessing one element reads the whole collection
• Deserialization cost: Collection must be deserialized into memory
• Network transfer: Full collection sent over network

-- This still reads entire 'prices' collection:
SELECT prices['USD'] FROM products WHERE id = 123;

-- Network and memory impact:
Collection Size | Network Bytes | Deserialize Time
----------------|---------------|------------------
10 items        | ~500 bytes    | < 1ms
100 items       | ~5KB          | 2-5ms
1,000 items     | ~50KB         | 20-50ms
10,000 items    | ~500KB        | 200ms+  ❌ Too slow!

Write Performance:

• LIST updates: Read-modify-write cycle (expensive)
• SET/MAP updates: Can do partial updates (efficient)
• Tombstones: Deleted elements create tombstones

-- MAP: Efficient partial update (O(1))
UPDATE products SET prices['USD'] = 2599 WHERE id = 123;
-- Only updates one column

-- LIST: Less efficient (O(n))
UPDATE playlists SET songs[5] = 'new_song' WHERE id = 123;
-- Requires reading position of element

Memory Impact:

Collections consume heap memory during queries:

-- Query returning 1000 rows, each with 100-item LIST
-- Memory needed: 1000 * 100 * ~50 bytes = ~5MB
-- Can cause GC pressure under load!

Best Practices for Performance:

1. Keep collections under 100 items
2. Use MAP for data you'll update partially
3. Use separate rows for large datasets
4. Monitor collection sizes in production
5. Consider frozen collections for small, immutable data

Answer: Yes, but only with FROZEN collections.

-- ❌ NOT ALLOWED: Regular nested collections
CREATE TABLE invalid (
  id UUID PRIMARY KEY,
  data MAP<TEXT, LIST<INT>>  -- ERROR!
);

-- ✅ ALLOWED: Frozen nested collections
CREATE TABLE valid (
  id UUID PRIMARY KEY,
  data MAP<TEXT, FROZEN<LIST<INT>>>  -- OK!
);

Why frozen only?

• Nested collections need to be treated as atomic values
• Partial updates of nested structures are too complex
• Frozen = immutable = can be nested safely

Common Nested Patterns:

1. Map of Lists (Categories with Items):

CREATE TABLE restaurants (
  id UUID PRIMARY KEY,
  menu_items MAP<TEXT, FROZEN<LIST<TEXT>>>
);

-- Data:
menu_items = {
  'appetizers': ['soup', 'salad', 'wings'],
  'mains': ['steak', 'fish', 'pasta'],
  'desserts': ['cake', 'ice cream']
}

-- Usage:
UPDATE restaurants
SET menu_items['appetizers'] = ['soup', 'salad']
WHERE id = 123;

2. List of Maps (Timeline Events):

CREATE TABLE user_activity (
  user_id UUID PRIMARY KEY,
  events LIST<FROZEN<MAP<TEXT, TEXT>>>
);

-- Data:
events = [
  {'type': 'login', 'time': '2025-01-15T10:00:00Z'},
  {'type': 'purchase', 'amount': '99.99', 'time': '2025-01-15T10:30:00Z'},
  {'type': 'logout', 'time': '2025-01-15T11:00:00Z'}
]

-- Must replace entire list to update
UPDATE user_activity
SET events = events + [{'type': 'login', 'time': '...'}]
WHERE user_id = 123;

⚠️ Important Limitations:

• No partial updates: Must replace entire frozen collection
• Performance cost: Entire structure serialized/deserialized
• Size matters more: Nested structures get large quickly

Alternative: Consider UDT for complex nested structures:

-- Instead of nested collections:
CREATE TYPE menu_section (
  name TEXT,
  items LIST<TEXT>
);

CREATE TABLE restaurants (
  id UUID PRIMARY KEY,
  menu LIST<FROZEN<menu_section>>
);