Cassandra列表列查询结果限制及多对多关系存储与分页实践

一、为什么不能直接在Tweets表存大点赞列表？ #

在关系型数据库里我们习惯用连接表处理多对多，但Cassandra是面向查询设计的——如果直接在Tweets表中用列表存储点赞UDT，当推文获赞千万级时，这个列表会变得异常庞大：不仅会突破Cassandra集合类型的实用性能上限（单个集合列元素数建议不超过几千，否则读取性能急剧下降），而且查询时加载整个完全是资源浪费，根本不符合Cassandra的设计哲学。

二、最佳实践：为查询专门建模 #

正确的做法是反范式化，创建独立的查询表，针对“获取某推文最近N个点赞用户”这个核心查询来设计表结构：

1. 点赞记录表结构

假设你的点赞UDT定义是这样的：

CREATE TYPE like_event (
    user_id UUID,
    username TEXT,
    liked_at TIMESTAMP
);

我们创建一个tweet_likes_by_time表，用tweet_id作为分区键，liked_at作为聚类键并按倒序排列：

CREATE TABLE tweet_likes_by_time (
    tweet_id UUID,
    liked_at TIMESTAMP,
    like_info like_event,
    PRIMARY KEY (tweet_id, liked_at)
) WITH CLUSTERING ORDER BY (liked_at DESC);

这样设计的优势：

• 每个推文的点赞记录都存在同一个分区里，查询时直接定位分区，无需跨节点查找
• 聚类键倒序排列，最近的点赞会排在分区最前面，查询时直接取前N条即可
• 避免大集合的性能问题，即使千万级点赞，单个分区的存储量也在Cassandra的安全范围内（单个分区建议不超过10GB，千万条几十字节的记录完全没问题）

2. 存储点赞事件

当用户点赞时，建议分两步操作：

• 如果需要实时显示点赞总数，先更新Tweets表的计数器列（需先给表添加该列）：

  UPDATE tweets SET like_count = like_count + 1 WHERE tweet_id = 123e4567-e89b-12d3-a456-426614174000;
  

• 再往tweet_likes_by_time表插入点赞记录：

  INSERT INTO tweet_likes_by_time (tweet_id, liked_at, like_info)
  VALUES (
      123e4567-e89b-12d3-a456-426614174000,
      toTimestamp(now()),
      {user_id: 987e6543-e21b-43c2-d109-876543210987, username: 'johndoe', liked_at: toTimestamp(now())}
  );
  

三、获取千万赞推文的最近10位点赞用户 #

有了上面的表，查询就非常简单高效了，直接用LIMIT限制返回行数：

SELECT like_info FROM tweet_likes_by_time
WHERE tweet_id = 123e4567-e89b-12d3-a456-426614174000
LIMIT 10;

因为聚类键是倒序的，LIMIT 10会直接返回最新的10条点赞记录，哪怕推文有千万级点赞，这个查询也是O(1)定位分区+O(1)取前10条，性能拉满。

四、如果已经用了列表列，如何限制返回结果？ #

如果你因为某些场景确实在Tweets表中用了列表存储点赞（比如只存储少量点赞），Cassandra提供了FIRST n和LAST n函数来限制集合列返回的元素数量：

• 若列表是按点赞时间倒序存储的，取最近10个点赞：

  SELECT FIRST(10) likes FROM tweets WHERE tweet_id = ?;
  

• 若列表是按正序存储的，取最近10个点赞：

  SELECT LAST(10) likes FROM tweets WHERE tweet_id = ?;
  

⚠️ 注意：这个方法只适用于列表元素数量不多的情况，如果列表有上万个元素，查询性能还是会很差——因为Cassandra需要先加载整个列表再切片，这种场景下还是建议用独立查询表的方案。

内容的提问来源于stack exchange，提问作者M.javid