Cassandra 宽列数据库实践：分区键、写入路径与最终一致性

Cassandra 是典型的宽列分布式数据库，适合高写入吞吐、大规模时间序列、事件日志、IoT 数据和跨地域部署。它的优势是无中心架构、水平扩展和高可用；代价是查询能力受模型约束，强事务能力有限，运维需要理解一致性、压缩、修复和墓碑。

使用 Cassandra 的第一原则是：查询决定表结构。不要把它当成关系数据库使用，也不要期望临时增加任意过滤条件还能保持高性能。

分区键与聚簇键

Cassandra 的 primary key 通常由 partition key 和 clustering columns 组成。partition key 决定数据分布，clustering columns 决定分区内排序。

例如按设备和日期存储指标：

CREATE TABLE metrics_by_device_day (
  device_id text,
  day date,
  ts timestamp,
  value double,
  PRIMARY KEY ((device_id, day), ts)
) WITH CLUSTERING ORDER BY (ts DESC);

这里 (device_id, day) 是分区键，避免单个设备长期数据落入一个超大分区。ts 是聚簇键，支持按时间倒序查询。

避免大分区

大分区是 Cassandra 常见问题。一个分区过大，会导致读取慢、压缩压力、修复时间长和内存压力。时间序列数据必须分桶，例如按天、小时或业务窗口。

分桶过细会增加查询分区数量，过粗会产生大分区。要根据写入速率、查询范围和保留周期压测确定。

写入路径

Cassandra 写入通常很快，因为写入先进入 commit log 和 memtable，然后异步刷到 SSTable。写入快并不代表没有成本。后续 compaction 会合并 SSTable，消耗磁盘 IO 和 CPU。

高写入场景要关注：

• commit log 磁盘性能。
• memtable flush 频率。
• compaction backlog。
• 写入延迟 p99。
• 磁盘空间放大。

磁盘空间要预留给 compaction。磁盘接近满时，Cassandra 会变得非常危险。

一致性级别

Cassandra 通过复制因子和一致性级别控制读写一致性。常见设置：

• ONE：低延迟，弱一致。
• QUORUM：多数确认，较均衡。
• LOCAL_QUORUM：本地数据中心多数确认，适合多数据中心。
• ALL：最强但可用性差。

如果写入和读取都使用 QUORUM，在单数据中心复制因子为 3 时，通常可以获得较强一致性。但网络分区、跨地域延迟和修复状态仍要考虑。

墓碑问题

删除数据在 Cassandra 中不会立刻物理删除，而是写入 tombstone。大量 tombstone 会让查询变慢，甚至触发失败。高频删除、TTL 大量过期、查询范围过宽都可能造成墓碑堆积。

建议：

• 控制 TTL 使用。
• 避免对大范围数据频繁删除。
• 查询尽量命中较小分区范围。
• 监控 tombstone warning。
• 合理配置 compaction。

二级索引与物化视图

Cassandra 的二级索引不适合高基数、大规模查询场景。很多情况下，应为每个查询模式单独建表，通过写入时冗余数据换取读取效率。

例如既要按用户查订单，又要按商户查订单，可以维护两张表：

• orders_by_user
• orders_by_merchant

这要求应用或数据管道负责多表写入一致性。最终一致是常见选择，关键业务要有补偿和校验。

修复与反熵

Cassandra 需要 repair 来修复副本间不一致。长期不 repair，会影响读取一致性和删除数据的正确清理。生产环境应建立定期 repair 计划，并避免在高峰期执行重负载 repair。

多数据中心部署时，repair、备份、扩容和节点替换都需要更谨慎。跨地域不是免费高可用，它会带来延迟和运维复杂度。

适用与不适用

适合 Cassandra：

• 写多读少的事件数据。
• 大规模时间序列。
• 多地域可用性优先。
• 查询模式固定。
• 可接受最终一致。

不适合 Cassandra：

• 复杂关联查询。
• 临时分析查询。
• 多行强事务。
• 查询模式频繁变化。

总结

Cassandra 的强大来自明确约束：按查询建模、按分区扩展、用一致性级别权衡延迟和可靠性。只要团队理解分区键、大分区、墓碑、压缩和修复，它可以承载非常大的数据规模。忽略这些基础，再强的集群也会被错误模型拖垮。