REST API的Todo数据模型优化：解决CQL查询过滤与排序问题

你当前的表结构问题核心在分区键设计：把(status, created)设为复合分区键后，每一组status+created的组合都会成为独立数据分区。当执行WHERE status = ? ORDER BY created时，Cassandra需要扫描所有包含该status的分区（每个不同的created都是一个独立分区），这种跨分区查询默认不被允许，强行执行需加ALLOW FILTERING，但会导致全集群扫描，性能完全无法满足生产需求。

针对你的两种查询需求（按ID查询、按status过滤+created降序排序），Cassandra的最佳实践是为每种查询模式单独设计表（反规范化设计），具体方案如下：

1. 用于按ID查询的表 #

这个表专门处理大部分以ID为过滤条件的查询，主键直接设为id，确保单条查询能快速命中分区：

CREATE TABLE todos_by_id (
    id UUID PRIMARY KEY,
    user_id TEXT,
    title TEXT,
    description TEXT,
    status TEXT,
    created TIMESTAMP,
    updated TIMESTAMP
);

查询时直接用SELECT * FROM todos_by_id WHERE id = ?，效率极高。

2. 用于按status过滤并排序的表 #

这个表针对WHERE status = ? ORDER BY created DESC的查询设计，将status作为分区键，created作为聚类列（指定降序存储），同时加上id作为聚类列避免重复（可能存在同一status和created的多条todo）：

CREATE TABLE todos_by_status_created (
    id UUID,
    user_id TEXT,
    title TEXT,
    description TEXT,
    status TEXT,
    created TIMESTAMP,
    updated TIMESTAMP,
    PRIMARY KEY((status), created, id)
) WITH CLUSTERING ORDER BY (created DESC);

设计逻辑：

• 同一status的所有数据都存储在同一个分区内，查询时只需定位到该分区
• 聚类列created按降序存储，查询时直接按存储顺序返回结果，不需要额外排序
• 加上id作为聚类列，保证即使status和created完全相同，也能唯一标识每条记录

3. 数据写入注意事项 #

因为采用了反规范化设计，每次新增或更新todo时，需要同时写入两个表，确保数据一致性。这是Cassandra为了查询性能做出的合理权衡，写入的冗余开销远小于查询性能的提升。

内容的提问来源于stack exchange，提问作者Stephanie Lawrence