Cassandra SELECT DISTINCT 和超时问题答案

【问题标题】：Cassandra SELECT DISTINCT and timeout issueCassandra SELECT DISTINCT 和超时问题
【发布时间】：2017-12-08 04:53:50
【问题描述】：

运行以下 CQL 查询时：

SELECT DISTINCT partition_key FROM table_name;

这应该是为了返回给定表正在使用的分区键列表。但是，默认超时设置为 10 秒，它总是超时：

ReadTimeout: Error from server: code=1200 [Coordinator node timed out waiting for replica nodes' responses] message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'}

将超时设置更改为：

read_request_timeout_in_ms: 60000
range_request_timeout_in_ms: 60000
request_timeout_in_ms: 60000

然后运行上述查询会导致多个 Cassandra 节点崩溃，包括协调节点。该表有大约 >100M 行和大约 5000 个唯一分区键。

有没有办法找到唯一的分区键列表？

【问题讨论】：

标签： cassandra cql cqlsh

【解决方案1】：

假设您使用的客户端支持分页/获取大小，并且使用足够低的获取大小（实际限制取决于您的服务器负载），此查询应该可以在现代版本的 cassandra（2.1 和更新版本）上正常工作)。

使用第三方驱动程序，寻找降低页面/获取大小的选项。将其设置为 100，看看它是否表现更好。

使用 cqlsh，如果您有 cassandra 3.0 或更高版本，请尝试PAGING 100;

【讨论】：

谢谢，在 cqlsh 中运行查询之前设置 PAGING 100。

【解决方案2】：

还有另一种使用以下实用程序获取键列表的方法：

sstabledump -e 
     OR
$ bin/sstablekeys <sstable_name>

但是您需要在所有节点数据目录中运行它们并手动过滤不同的键。不简单但可行！

这里是实用程序Cassandra SSTabledump 和Cassandra SSTablekeys 的参考

查询超时的原因是

查询中没有 where 子句
要扫描的行太多 > 100M
协调器现在必须保持查询打开，直到从集群中的每个节点获得响应，然后过滤不同的。
distinct 操作对于这个用例来说成本太高了。
节点崩溃，因为本质上它们填满了堆，选择了整行并导致 OutOfMemory（OOM 错误）

【讨论】：

这似乎非常违反直觉。 Cassandra 是为大规模设计的，那么如果它不支持大规模表，他们为什么要添加这个功能呢？ SELECT DISTINCT 适用于小型表，但当一个开始扩展时它会中断，我认为这与 Cassandra 背后的理念背道而驰。如果我们有一个用户表，并且它开始扩展，那么有没有简单的方法来运行 CQL 查询并获取整个用户列表？肯定有办法的。
@Onst Cassandra 不适合获取所有内容。这是关于按键查找。任何分布式系统都是如此。您通过分区进行水平扩展，并且在扩展时查询所有内容变得越来越痛苦。