Cassandra CQL3 按集群键效率排序（带限制子句？）

Question

我有下表（使用 CQL3）：

create table test (
  shard text,
  tuuid timeuuid,
  some_data text,
  status text,
  primary key (shard, tuuid, some_data, status)
);

我想获取按 tuuid 排序的行。但这只有在我限制分片时才有可能 - 我明白这是由于性能。

我有纯粹用于分片的分片，我可以将它的值范围限制在某个小范围 [0-16) 之内。然后，我可以运行这样的查询：

select * from test where shard in (0,...,15) order by tuuid limit L;

我的表中可能有数百万行，所以我想了解这种order by query 的性能特点。总体而言，性能似乎很差，但有一个合理数量的限制条款（10K 的顺序），这可能不是那么糟糕 - 即 16 路合并但限制相当低。

我们将不胜感激任何提示、建议或指向代码中的查找位置。

Answer 1

您的数据根据​​您的列键排序。因此，由于 WHERE 子句而不是由于您的 LIMIT 子句，afaik 导致上述查询中合并中的性能问题。

您的列是根据 tuuid 按顺序插入的，因此不存在性能问题。

如果您一次获取太多行，我建议创建一个 test_meta 表，在其中存储每个 X-inserts 的最新 timeuuid，以获得查询将获取的行的上限。然后，您可以将查询更改为：

select * from test where shard in (0,...,15) and tuuid > x and tuuid

简而言之：利用您的列键并摆脱限制。或者，在 Cassandra 2.0 中，将有分页功能，这也将有所帮助。

我偶然发现的另一个问题，你说的是

我的表中可能有数百万行

但根据您的数据模型，您将拥有精确的 shard 行数。这是您的行键 - 与分区器一起 - 将确定数据的分布/分片。

希望有帮助！

更新

根据我的个人经验，cassandra 在大量读取和写入时的表现都非常好。如果结果集变得太大，我宁愿在接收/客户端遇到内存问题，而不是在服务器端超时。尽管如此，为了防止任何一种情况，我建议看看即将推出的 (2.0) 分页功能。

同时：

尝试使用trace functionality in 1.2 进行调查。

如果您主要阅读“最新”数据，请尝试adding a reversed type。

对于缓存等一般优化，首先阅读cassandra handles reads on a node，然后查看this tuning guide。