Cassandra 有限分页策略

瀑布式分页

如果你的应用只需要瀑布式的分页，那么，Cassandra可以很好的支持，不过记得要指定好排序顺序。

CLUSTERING ORDER BY (add_time DESC);

常见的分页，跳页问题

许多产品喜欢设计可以跳页的分页逻辑比如下面这种

首页 1 2 3 4 5 下一页 GO [ ] 页

由于Cassandra不支持类似mysql的 "Limit start,length" 也没有其他数据库的 "top + 子查询"，遇到这种需求的时候，非常不方便。

这里提供一种有限的解决方案，可以一定程度上缓解需求矛盾，在Cassandra更加成熟之前，提供过渡。

具体思路

类似mysql的Limit start,length操作，

Mysql需要先扫描0 - start 的所有记录，然后从start开始，取length条数据。这也是Mysql在分页操作的时候的慢查询问题之一。

假设我们有一个表像下面这样，一个好友表，按添加时间逆序排序

CREATE TABLE friend(

    user_id int,

    friend_id int,

    add_time bigint,

    PRIMARY KEY (user_id,add_time)

)

WITH compaction = {'class':'LeveledCompactionStrategy'}

AND CLUSTERING ORDER BY (add_time DESC);

假设我们的分页是每页10个用户，如果要查询第二页好友，首先查出1 - 10用户的add_time，然后

--首先，只查询add_time 字段，获取偏移量

select add_time from friend where user_id = 10 limit 10;

--然后，用偏移量查询第二页

select * from friend where user_id = 10 and add_time < 第10个用户的add_time limit 10;

以上就是基本的思路。

如果用户选择跳到第10页，那么需要取limit 90的数据，获取第90条数据的偏移量，查询90 - 100的数据。

优化

优化的方案是有缺陷的，需要增加额外的cql，如果这是一个被频繁查询的业务，还是值得。

优化的思路

如果你查出了第5页，如果用户紧接着点击第6页（或者点击了下一页），直接使用第五页已经查出的数据的最后一条作为偏移量查询第6页，这一点和瀑布分页一样。
如果你查出了第5页，并且将第5页分页偏移量缓存在一张分页表中，如果用户要查第10页的时候，你只需要查询5 - 9页的数据，就可以知道第10页的偏移量，同时你也得到了5 - 9页的分页信息，

缓存6 - 10 页的数据（第5页假设已经缓存过了），那么用户继续点击6 - 9 页的任何数据，都可以直接取到。
担心分页缓存的一致性问题，可以使用using ttl 关键字给分页缓存设置过期时间，使得分页缓存会定期重建，新增的数据最坏情况是堆积在第一页，而不会查不出来。

--分页缓存表的样例

CREATE TABLE forums.page_cache (

    page_key text,

    page_num int,

    page_offset bigint,

    PRIMARY KEY (page_key, page_num)

)

潜在问题

用户可能自己修改URL参数，显然你的url可能需要类似这样

index?page=3&offset=12034

你需要2个参数才能正常工作

一种可行的方案是使用base64重新编码参数，使其保持只有一个

index?page=AAG352F3

一方面用户只会修改page，另一方面有些用户可能会因为不知道怎么改而放弃，不过这么做的用户应该数量不多。

有关优化为什么不把前后两页都优化了？

按照上面介绍的优化方案，如果你查了第5页，那么1-5页的缓存肯定都已经完成了，如果要查询第4页，偏移量已经在那。
在Cassandra并非所有的查询条件都支持order by，如果使用非主键索引，就无法进行order by 操作，也就无法通过第5页查询第4页。