宽列存储

Twitter 时间线、IoT 传感器、审计日志——写入 QPS 极高、按分区键顺序读 时，Cassandra、ScyllaDB 等 宽列（Wide Column） 库往往比传统行存更顺手。它们牺牲灵活 JOIN，换取 线性扩展写入 与 多数据中心复制。

学习目标

• 理解宽列模型：Keyspace → Table → Partition Key + Clustering Key
• 对比 Cassandra 与 ScyllaDB 的定位
• 与 dynamodb-essentials、mongodb-essentials 的分工

宽列模型要点

Partition Key → 决定数据落在哪个节点（不可跨分区事务）
Clustering Key → 分区内排序（时间线、范围扫描）
Column → 行内可变列族（稀疏宽表）

-- CQL 示例：按 user_id 分区，ts 排序的事件
CREATE TABLE events (
  user_id uuid,
  ts timestamp,
  event_type text,
  payload text,
  PRIMARY KEY (user_id, ts)
) WITH CLUSTERING ORDER BY (ts DESC);

查询必须带 Partition Key——设计表前先写访问模式，与 DynamoDB 的 PK/SK 思维类似（见 ddb-keys）。

Cassandra vs ScyllaDB

	Apache Cassandra	ScyllaDB
实现	JVM	C++，兼容 CQL
生态	最成熟，文档多	性能导向，Drop-in 替换
运维	需理解一致性级别、repair	同样需 CAP 取舍

一致性级别（ONE / QUORUM / ALL）直接对应 scale-cap 的可用性与一致性 trade-off。

与 MongoDB、DynamoDB 对照

场景	更常见选型
文档灵活、二级索引多	mongodb-essentials
AWS 托管、按请求计费	dynamodb-essentials
自建多 DC、超高写入时间序列	Cassandra / ScyllaDB
强事务、复杂 JOIN	postgresql-essentials

练习

• 为「设备 ID + 时间戳」时序数据写出 Partition Key 与 Clustering Key
• 说明为何宽列库不适合「任意字段 ad-hoc 查询」