CassandraCassandra表设计

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
• INLINECODE4: (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 INLINECODE7
• INLINECODE8 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
• INLINECODE11 on partition key hits multiple nodes—expensive; prefer single partition queries

Consistency Levels

• - QUORUM for most operations—majority of replicas; balances consistency and availability
• INLINECODE13 for multi-datacenter—avoids cross-DC latency
• INLINECODE14 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
• INLINECODE19—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 INLINECODE23
• 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
• INLINECODE26—better read latency, higher write amplification
• INLINECODE27—for time-series with TTL; reduces tombstone overhead
• Wrong strategy for workload = degraded performance over time

Operations

• - nodetool repair regularly—inconsistencies accumulate without repair
• INLINECODE29 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