Cassandra SELECT DISTINCT和超时问题

Posted 2021-05-04

运行以下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（2.1和更新版本）上正常工作。

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

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

另一答案

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

sstabledump -e 
     OR
$ bin/sstablekeys <sstable_name>

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

以下是公用事业Cassandra SSTabledump和Cassandra SSTablekeys的参考资料

查询超时的原因是

1. 查询中没有where子句
2. 扫描超过100M的行太多
3. 协调器现在必须保持查询处于打开状态，直到从集群中的每个节点获得响应，然后过滤为distinct。
4. 对于这个用例来说，独特的操作太昂贵了。
5. 节点崩溃，因为它们基本上填满了堆，并且选择了整个行并导致OutOfMemory（OOM错误）