select count(*) 在 Cassandra 中遇到超时问题

Question

也许这是一个愚蠢的问题，但我无法确定 Cassandra 中表的大小。

这是我尝试过的：

select count(*) from articles;

如果表很小，它工作得很好，但一旦填满，我总是遇到超时问题：

cqlsh：

• OperationTimedOut：错误={}，last_host=127.0.0.1

DBeaver：

• 运行 1：225,000（7477 毫秒）
• 运行 2：233,637（8265 毫秒）
• 运行 3：216,595（7269 毫秒）

我认为它会超时并中止。表中的实际条目数可能要高得多。

我正在测试完全空闲的本地 Cassandra 实例。我不介意它是否必须进行全表扫描并且在那段时间没有响应。

有没有办法可靠地计算 Cassandra 表中的条目数？

我正在使用 Cassandra 2.1.13。

Answer 1

这是我当前的解决方法：

COPY articles TO '/dev/null';
...
3568068 rows exported to 1 files in 2 minutes and 16.606 seconds.

---

背景：Cassandra 支持 将表格导出到文本文件，例如：

COPY articles TO '/tmp/data.csv';
Output: 3568068 rows exported to 1 files in 2 minutes and 25.559 seconds

这也与生成的文件中的行数匹配：

$ wc -l /tmp/data.csv
3568068

Answer 2

据我所知，您的问题与 cqlsh 超时有关：OperationTimedOut：errors={}，last_host=127.0.0.1

您可以通过选项简单地增加它：

 --connect-timeout=CONNECT_TIMEOUT
                       Specify the connection timeout in seconds (default: 5
                       seconds).
 --request-timeout=REQUEST_TIMEOUT
                       Specify the default request timeout in seconds
                       (default: 10 seconds).

Answer 3

有没有办法可靠地计算 Cassandra 表中的条目数？

简单的答案是不。这不是Cassandra的限制，而是对分布式系统可靠地计算唯一项目的严峻挑战。

这就是像 HyperLogLog 这样的近似算法所面临的挑战。

一种可能的解决方案是在 Cassandra 中使用 counter 来计算不同行的数量，但即使是 counters 在某些极端情况下也可能会错误计数，因此您会得到几个％的错误。

Answer 4

这是一个很好的行计数实用程序，可以避免在 Cassandra 中运行大型

COUNT(*)

时发生的超时问题：

https://github.com/brianmhess/cassandra-count

Answer 5

原因很简单：

当您使用时：

SELECT count(*) FROM articles;

它对数据库具有相同的效果：

SELECT * FROM articles;

您必须查询所有节点。 Cassandra 只是遇到超时。

您可以更改超时，但这不是一个好的解决方案。 （暂时可以，但不要在常规查询中使用它。）

有一个更好的解决方案：让您的客户计算您的行数。您可以创建一个 Java 应用程序，在插入行时计算行数，并使用 Cassandra 表中的计数器列插入结果。

Answer 6

您可以使用复制来避免 cassandra 超时通常发生在 count(*) 上

使用这个bash

cqlsh -e "copy keyspace.table_name (first_partition_key_name) to '/dev/null'" | sed -n 5p | sed 's/ .*//'

Answer 7

您可以在使用 Datastax cqlsh 时将超时秒数定义为命令行选项。默认值为 10。

$ cqlsh --request-timeout=3600