Cassandra 宽行存储和 CQL 查询

FreeGuideOnline 11阅读 2026-07-10

Cassandra 宽行存储与 CQL 查询：从零到一掌握列族的高效数据建模

1. 为什么要理解宽行存储？

Apache Cassandra 的设计灵感源自 Amazon Dynamo 和 Google Bigtable，它抛弃了传统关系型数据库的固定行列结构，采用了一种更灵活的 宽行存储 模型。如果你刚接触 Cassandra，常常会听到“不要用关系思维去建模”，究其根本，正是因为 Cassnadra 将一行数据视作一个可以无限扩展的动态列集合。理解宽行，才能真正发挥 Cassandra 写入吞吐量高、水平扩展顺滑的优势。

2. Cassandra 数据模型的核心基石

在深入 CQL 查询之前，我们必须先理清几个核心抽象概念，它们是宽行存在的前提。

2.1 分区键——确定数据物理存储位置

每一张表都必须定义一个分区键（Partition Key）。Cassandra 通过对分区键进行哈希运算，决定将这一整行数据分布在集群中的哪个节点。同一个分区键下的所有数据都会被存储在同一个分区里，这个分区正是“宽行”的物理体现。

2.2 聚类列——分区内的有序排列

如果分区键定义了一本“书”，那么聚类列（Clustering Columns）就是书里的章节顺序。在同一个分区内，数据按照聚类列的值进行排序并物理存储，这为范围查询和顺序读取提供了基础。

2.3 宽行与传统“宽表”的区别

传统关系型数据库中，要表达“一个用户拥有多个电子邮箱”这种一对多关系，通常需要建一张关联表。而在 Cassandra 里，我们可以直接将所有邮箱放在同一个分区里，每一行可以拥有无数个单元格（Column），完全突破了关系里必须预先定义列的约束。

3. CQL 快速入门：看似 SQL，实则列族

Cassandra 查询语言（CQL）刻意模仿了 SQL 的语法，这降低了学习门槛，但内部执行逻辑完全不同。下面通过建表来揭示宽行结构。

CREATE TABLE user_activity (
  user_id uuid,
  activity_time timestamp,
  event_type text,
  page_url text,
  device text,
  PRIMARY KEY ((user_id), activity_time)
) WITH CLUSTERING ORDER BY (activity_time DESC);

要点解析：

PRIMARY KEY ((user_id), activity_time) 中双括号内的 user_id 是分区键，决定数据落在哪个节点。
activity_time 是聚类列，同一个用户的所有行为会按时间降序紧密存储在同一个分区，形成一个宽行。
你可以不断为这个用户插入新行为记录，宽行将一直扩展，直到达到分区大小上限（一般建议每个分区不超过 100MB）。

4. 基于宽行结构的 CQL 查询实战

所有查询必须围绕分区键进行过滤，否则会触发全表扫描（在生产环境中通常会被 ALLOW FILTERING 限制）。

4.1 精准分区写入与读取

写入无须预先声明列名，只需要提供分区键和聚类列的值即可。读取时必须提供分区键。

-- 写入 (UPSERT 语义)
INSERT INTO user_activity (user_id, activity_time, event_type, page_url)
VALUES (123e4567-e89b-12d3-a456-426614174000, '2025-03-09 14:00:00', 'click', '/home');

-- 读取该用户全部活动，结果按 activity_time DESC 排序
SELECT * FROM user_activity WHERE user_id = 123e4567-e89b-12d3-a456-426614174000;

4.2 利用聚类列进行范围查询

因为数据已经在分区内按聚类列物理排序，范围查询效率极高，且无需 ALLOW FILTERING。

-- 查询某个用户最近一天的活动
SELECT * FROM user_activity
WHERE user_id = 123e4567-e89b-12d3-a456-426614174000
  AND activity_time >= '2025-03-09 00:00:00'
  AND activity_time <= '2025-03-09 23:59:59';

4.3 只会返回完整行的限制

CQL 查询始终以整行为单位返回。虽然可以指定列，但返回的每一行在存储层面都拥有分区键、聚类列以及其他列的值。Cassandra 不支持跨分区 JOIN，一切多表关联都应该在应用层完成。

4.4 常见错误示范

-- 错误：缺少分区键，会触发全表扫
SELECT * FROM user_activity WHERE activity_time > '2025-03-09';

-- 错误：直接对非聚类列做范围过滤
SELECT * FROM user_activity WHERE user_id = ? AND page_url = '/home';

当需要对 page_url 这类非聚类列进行过滤时，可以考虑创建二级索引或物化视图，但更推荐重新设计表结构，将经常查询的列作为分区键或聚类列。

5. 设计高效宽行的三项原则

5.1 分区键的选择要避免“过宽”与“过热”

避免巨大分区：如果分区键基数太小（如用 country 作为分区），可能导致单行过于庞大，压缩、读取、修复都会变慢。
避免热点：若大量用户共享同一个分区键（如某个热门用户的所有关注着放入同一个分区），会造成单节点压力过大。

适用策略：使用复合分区键（例如 ((tenant_id, date))）或者添加哈希桶字段。

5.2 聚类列的排序即查询能力

从一开始就要根据业务查询来设计聚类列的排序方式。CLUSTERING ORDER BY (col1 ASC, col2 DESC) 的定义会直接决定你能以什么顺序进行高效的范围扫描。如果后续需要新的排序维度，通常需要新建一张表。

5.3 宽行内的“稀疏”与“紧凑”共存

同一个分区内，不同时间点的数据可以有不同的列集合（比如旧记录没有 device 列，新记录有），这不会产生任何浪费空间，因为 Cassandra 的内部存储（SSTable）下每一列都是独立存储的。这种灵活性正是宽行的魅力。

6. 从宽行视角看 CQL 高级操作

6.1 限制返回行数与分页

宽行可能包含数百万个聚类列，因此必须控制结果集大小。可以使用 LIMIT，但真正的分页需要依靠 PagingState。

-- 仅返回最近 10 条活动
SELECT * FROM user_activity WHERE user_id = ? LIMIT 10;

在驱动程序中，会通过自动分页获取全部数据，开发者可以设置每次拉取的行数。

6.2 TTL 与宽行数据过期

可以为每一行设置过期时间（TTL），这很适合宽行中大量的时序数据自动清理，无需后台作业删除。

INSERT INTO user_activity (user_id, activity_time, event_type)
VALUES (123e4567-e89b-12d3-a456-426614174000, '2025-03-09', 'login')
USING TTL 86400; -- 24小时后自动删除

6.3 集合类型：在宽行内嵌入更多维度

Cassandra 原生支持 list、set、map 列，可在同一个宽行单元格内存储复杂数据。但要注意集合列的单个单元格不能太大（推荐小于 1MB）。对于数量可能无限增长的数据（如用户的所有好友），应采用宽行设计而非 list 列。

7. 常见误区与调试手段

认为 CQL = SQL：CQL 没有 JOIN、没有事务、不保证跨分区原子性，查询必须以分区键为起点。
随意使用 ALLOW FILTERING：仅适合极少量数据的开发环境。生产环境中一旦对宽行分区使用非键过滤，会拖垮整个集群。
宽行写入过快导致 compaction 压力：频繁向同一个分区大量写入小记录会导致读写性能抖动，可通过调整 compaction 策略或提前拆分分区缓解。

8. 总结

Cassandra 的宽行存储打破了固定列的限制，把“一行”升维为一个能够承载海量有序数据的容器。配合基于分区键和聚类列的 CQL 查询，你可以用简洁的代码实现时序数据采集、消息收件箱、物联网传感器日志等场景的高效读写。牢记建模三要素——按查询设计分区键、用聚类列定义查询顺序、控制单分区大小，你的 Cassandra 之旅将平稳且强大。