Question

所以我有一个物化视图定义如下（更名一个位）：

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)
...

根据定义，数据将按PROCESS_ON_DATE_TIME列以ASC顺序（最早的顺序）排序。

现在我有一个查询，运行如下：

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

有超过250行的是匹配，返回如此250。从CQLSH运行这一点，取3次 - 前两取100行，最后一个取50行。我通过CQLSH启用了LOCAL_ONE一致性跟踪。现在，前两个取的 - 他们做的都是同样的步骤，以相同的顺序，相同sstables等其中一人总是需要2秒，其他8毫秒。我不能为我的生命弄清楚为什么一个需要超过2秒。慢家伙停滞在“来自memtables和3 sstables的合并数据”上（但同样，但是前两个访存确实做同样的事情，但是一个很慢，下一个很快-相同的合并的sstables）。

继续执行步骤2。我就想，好吧，我们有一个集群列，因此它的排序。如果我添加一个ORDER BY子句什么对结果进行排序。所以我跑了：

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毫秒内。嗯？？？这就是我想要达到的目标-但是为什么REVERSE排序运行良好？

我的身影，如我所要求的记录不是一些年纪大了，一个ASC排序将是最好的，因为最早的记录将成为第一，立即抓起。另一条路线，DESC，我首先必须更新的记录，因此将不得不跳过一堆找到的第一个记录比我的日期和时间旧，然后抢下250谁能帮我这个逻辑是什么？为什么一个DESC ORDER BY反应良好，而ASC没有。

使用DSE 5.1.9

谢谢。

-吉姆

卡桑德拉集群栏和成效

0 个答案: