Cassandra

Design Cassandra tables, write efficient queries, and avoid distributed database pitfalls.

Security Scan

The skill is an instruction-only Cassandra advisory that only requires cqlsh/nodetool and its instructions align with that purpose — nothing requested or installed looks out of scope.

Purpose & Capability

Name/description (Cassandra table design, queries, ops) match the declared requirements (optionally use cqlsh and nodetool). No unrelated binaries, env vars, or config paths are required.

Instruction Scope

SKILL.md content is focused on Cassandra modeling, query restrictions, consistency, tombstones, compaction, and nodetool usage. It does not instruct the agent to read unrelated files, exfiltrate data, or call external endpoints beyond typical operator commands (cqlsh/nodetool).

Install Mechanism

No install spec — instruction-only. Nothing will be downloaded or written to disk by the skill itself.

Credentials

No environment variables or credentials are requested. The declared optional binaries (cqlsh, nodetool) are appropriate for the stated functionality.

Persistence & Privilege

always is false and the skill does not request persistent system presence or modification of other skills. Default autonomous invocation is allowed (platform normal) but is not combined with extra privileges here.

Assessment

This is an instruction-only skill that provides Cassandra best-practices and references cqlsh/nodetool. It does not request credentials or install code, so its footprint is small and coherent. Things to consider before enabling: 1) If you allow the agent to run commands, cqlsh/nodetool can perform operational actions (e.g., repairs) against your cluster — ensure the agent's runtime environment and network access are limited to the intended test/production clusters. 2) Confirm those binaries on PATH are the versions you expect (to avoid surprising behavior). 3) The skill itself doesn't require credentials, but if you or the agent supply cluster credentials later, those grant real access; only provide them to trusted agents. Overall low risk, but operational commands can have real impact if executed against live clusters.

Data Modeling Mistakes

• Design tables around queries, not entities—denormalization is mandatory, not optional
• One table per query pattern—Cassandra has no JOINs; duplicate data across tables
• Partition key determines data distribution—all rows with same partition key on same node
• Wide partitions kill performance—keep under 100MB; add time bucket to partition key if growing

Primary Key Traps

• PRIMARY KEY (a, b, c): a is partition key, b and c are clustering columns
• PRIMARY KEY ((a, b), c): (a, b) together is partition key—compound partition key
• Clustering columns define sort order within partition—query must respect this order
• Can't query by clustering column without partition key—unlike SQL indexes

Query Restrictions

• WHERE must include full partition key—partial partition key fails unless ALLOW FILTERING
• ALLOW FILTERING scans all nodes—never use in production; redesign table instead
• Range queries only on last clustering column used—WHERE a = ? AND b > ? works, WHERE a = ? AND c > ? doesn't
• IN on partition key hits multiple nodes—expensive; prefer single partition queries

Consistency Levels

• QUORUM for most operations—majority of replicas; balances consistency and availability
• LOCAL_QUORUM for multi-datacenter—avoids cross-DC latency
• ONE for pure availability—may read stale data; fine for caches, bad for critical reads
• Write + read consistency must overlap for strong consistency—QUORUM + QUORUM safe

Tombstones (Silent Performance Killer)

• DELETE creates a tombstone, not actual deletion—tombstones persist until compaction
• Mass deletes destroy read performance—thousands of tombstones scanned per query
• TTL also creates tombstones—don't use short TTLs with high write volume
• Check with nodetool cfstats -H table—Tombstone columns show problem

Batch Misuse

• UNLOGGED BATCH is not faster—use only for atomic writes to same partition
• LOGGED BATCH for multi-partition atomicity—adds coordination overhead
• Don't batch unrelated writes—hurts coordinator; send individual async writes
• Batch size limit ~50KB—larger batches fail or timeout

Anti-Patterns

• Secondary indexes on high-cardinality columns—scatter-gather query, slow
• Secondary indexes on frequently updated columns—creates tombstones
• SELECT *—always list columns; schema changes break queries
• UUID as partition key without time component—random distribution, hot spots during bulk loads

Lightweight Transactions

• IF NOT EXISTS / IF column = ?—uses Paxos, 4x slower than normal write
• Serial consistency for LWTs—SERIAL or LOCAL_SERIAL
• Don't use for counters or high-frequency updates—contention kills throughput
• Returns [applied] boolean—must check if operation succeeded

Collections and Counters

• Sets/Lists/Maps stored with row—can't exceed 64KB, no pagination
• List prepend is anti-pattern—creates tombstones; use append or Set
• Counters require dedicated table—can't mix with regular columns
• Counter increment is not idempotent—retry may double-count

Compaction Strategies

• SizeTieredCompactionStrategy (default)—good for write-heavy, uses more disk space
• LeveledCompactionStrategy—better read latency, higher write amplification
• TimeWindowCompactionStrategy—for time-series with TTL; reduces tombstone overhead
• Wrong strategy for workload = degraded performance over time

Operations

• nodetool repair regularly—inconsistencies accumulate without repair
• nodetool status shows cluster health—UN (Up Normal) is good, DN is down
• Schema changes propagate eventually—wait for nodetool describecluster to show agreement
• Rolling restarts: one node at a time, wait for UN status before next