Cassandra聚类列及其性能

因此,我有一个物化视图定义如下(稍微更改了名称):

CREATE MATERIALIZED VIEW MYVIEW AS
    SELECT *
    FROM XXXX
    WHERE id IS NOT NULL AND process_on_date_time IS NOT NULL AND poller_processing_status IS NOT NULL
    PRIMARY KEY (poller_processing_status, process_on_date_time, id)
    WITH CLUSTERING ORDER BY (process_on_date_time ASC, id ASC)
...

根据定义,数据将按ASC顺序(最早的第一个)中的PROCESS\u ON\u DATE\u TIME列进行排序。

SELECT JSON * FROM MYVIEW
WHERE poller_processing_status='PENDING'
AND process_on_date_time<=1548775105000  LIMIT 250  ;

匹配的行超过250行,因此返回250行。从CQLSH运行它,它获取3次—前两次获取100行,最后一次获取50行。我启用了通过CQLSH和consistency LOCAL\u ONE进行跟踪。现在,在前两次抓取中,它们执行完全相同的步骤,顺序相同,表相同,等等。其中一次总是需要2秒,另一次是8毫秒。我一辈子都搞不明白为什么一次要花2秒以上。慢家伙拖延了“来自memtables和sstables的合并数据”(但同样,前两次获取做的事情完全相同,但一次是慢的,另一次是快的-相同的合并sstables)。

继续执行步骤2。我想,好吧,我们有一个聚类列,所以它被排序了。如果我添加一个orderby子句来对结果进行排序呢。所以我运行了这个:

SELECT JSON * FROM sop_cas.notification_by_status_ptd_mv
WHERE poller_processing_status='PENDING'
AND process_on_date_time<=1548775105000
ORDER BY process_on_date_time ASC LIMIT 250  ;

因此基本上是完全相同的查询,以与排序数据(聚类列)相同的顺序指定顺序。结果?相同-超过2秒完成。没有改善。真倒霉。

最后一个测试。我将查询中的排序从ASC改为DESC,并尝试了一下。结果?每次查询在10毫秒内响应时。呵呵????这就是我想要达到的目标——但是为什么反向排序运行得很好呢?

我想,当我要求的是比某个东西更老的记录时,ASC排序是最好的,因为最老的记录会首先被抓取,然后立即被抓取。另一条路径,DESC,我会先有更新的记录,因此必须跳过一堆,找到比我的时间戳早的第一条记录,然后抓取下一条记录。有人能帮我理解这个逻辑吗?为什么DESC ORDER BY响应良好而ASC没有响应。

使用DSE 5.1.9

提前谢谢。

-吉姆