时间戳

首页 > 解决方案 > cassandra 中的 ORDER BY 成本

cassandra - cassandra 中的 ORDER BY 成本

问题描述

我知道 cassandra 表中的数据已经按聚类列排序。因此，当我们使用该ORDER BY子句时，假设实际上没有进行任何排序（跨行时）是否安全？使用时是否只是以相反的顺序获取结果ORDER BY？我想知道这个手术的费用。

标签： cassandracql

解决方案

好的，假设我有这张表，旨在通过他们购买的音乐专辑跟踪客户：

CREATE TABLE customers_by_album (
  album TEXT,
  band TEXT,
  custno INT,
  customer_name TEXT,
  PRIMARY KEY (album,custno))
WITH CLUSTERING ORDER BY (custno ASC);

一旦我插入一些数据并运行nodetool flush（强制它到磁盘），我将运行以下查询，翻转排序方向：

aaron@cqlsh:stackoverflow> SELECT album,token(album),band,custno,customer_name
    FROM customers_by_album
    WHERE album='Moving Pictures'
    ORDER BY custno DESC;

当我查询分区键album时，album值Moving Pictures被散列到令牌 7819329704333693835。节点 10.0.0.5 负责令牌 7819329704333693835，查询被发送到那里。假设行/键缓存未命中，Cassandra 前往该目录stackoverflow/customers_by_album-e2820d00d88311e9b9dc413ae9a4e561/并找到适当的 SSTable 文件。

在文件中，它找到分区并开始顺序读取：

在此处输入图像描述

一旦请求的数据被读取，它现在必须反转它刚刚读取的数据的排序方向，返回以下结果：

 album           | system.token(album) | band | custno | customer_name
-----------------+---------------------+------+--------|---------------
 Moving Pictures | 7819329704333693835 | Rush |     14 | Mitch
 Moving Pictures | 7819329704333693835 | Rush |     13 | Jeff
 Moving Pictures | 7819329704333693835 | Rush |     12 | Ted
 Moving Pictures | 7819329704333693835 | Rush |     11 | Aaron

(4 rows)

与排序方向翻转相关的成本似乎微不足道。当我使用 运行该查询时TRACING ON，我会在20.217ms 内得到结果。当我指定ORDER BY custno ASC(ORDER BY 的排序方向与磁盘排序顺序匹配) 时，我会在10.98ms中得到结果。

现在想象在您的分区中存储数万行，拉回几十列，然后翻转排序方向。我曾与应用程序团队合作，他们对大型结果集进行查询，当乳清翻转排序方向时会超时。所以改变排序方向的“成本”肯定与读取的行数/列数成正比。

推荐阅读