即使在超时 10 秒后，当查询超过 10,000 行的键时，Cassandra 也会超时

Posted 2023-03-22

【中文标题】即使在超时 10 秒后，当查询超过 10,000 行的键时，Cassandra 也会超时

【英文标题】：Cassandra timing out when queried for key that have over 10,000 rows even after giving timeout of 10sec

【发布时间】：2015-02-05 02:15:49

【问题描述】：

我正在使用带有预安装默认设置的 DataStax Community v 2.1.2-1 (AMI v 2.5)。 我有一张桌子：

CREATE TABLE notificationstore.note (
  user_id text,
  real_time timestamp,
  insert_time timeuuid,
  read boolean,
  PRIMARY KEY (user_id, real_time, insert_time))
WITH CLUSTERING ORDER BY (real_time DESC, insert_time ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = '"keys":"ALL", "rows_per_partition":"NONE"
AND **default_time_to_live** = 20160

其他配置有：

我有 2 个节点。在具有 1 x 32 (SSD) 的 m3.large 上。 即使在此特定表上将一致性设置为 ONE，我也面临超时问题。

我将堆空间增加到 3gb [ram 大小为 8gb] 我将读取超时时间增加到 10 秒。select count (*) from note where user_id = 'xxx' limit 2; // errors=, last_host=127.0.0.1.

我想知道问题是否与生存时间有关？或者是否有任何其他配置对此很重要。

数据库中的数据非常小。 此外，此问题不会在您插入后立即发生。这会在一段时间后（超过 6 小时）发生

谢谢。

【问题讨论】：

参考这个问题...***.com/questions/24899220/rpc-timeout-in-cassandra/…

我已经将超时设置为 10 秒，并在两个节点上重新启动了我的 cassandra。没有运气。即使有，考虑到我的表并不大，我想查询它需要花费 10 秒的时间。

@mehnaazm 我认为这与我在这里的答案相同：***.com/questions/27376784/…。为了完整起见，我应该在此处复制该答案吗？

@BrianC，是的，问题解决了

【参考方案1】：

[从这里复制我的答案，因为它是相同的环境/问题：amazon ec2 - Cassandra Timing out because of TTL expiration。]

您遇到的问题是墓碑（已删除值）的数量超过阈值，然后超时。

如果您打开跟踪然后尝试您的 select 语句，您可以看到这一点，例如：

cqlsh> tracing on;
cqlsh> select count(*) from test.simple;

 activity                                                                        | timestamp    | source       | source_elapsed
---------------------------------------------------------------------------------+--------------+--------------+----------------
...snip...
 Scanned over 100000 tombstones; query aborted (see tombstone_failure_threshold) | 23:36:59,324 |  172.31.0.85 |         123932
                                                    Scanned 1 rows and matched 1 | 23:36:59,325 |  172.31.0.85 |         124575
                           Timed out; received 0 of 1 responses for range 2 of 4 | 23:37:09,200 | 172.31.13.33 |       10002216

您在某种程度上遇到了 Cassandra 的反模式，其中数据在被删除之前只存储了很短的时间。有几个选项可以更好地处理这个问题，包括在需要时重新访问您的数据模型。以下是一些资源：

The cassandra.yaml configuration file - 请参阅墓碑设置部分 Cassandra anti-patterns: Queues and queue-like datasets About deletes

对于您的示例问题，我尝试将 gc_grace_seconds 设置降低到 300（5 分钟）。这会导致比默认的 10 天更频繁地清理墓碑，但根据您的应用程序，这可能合适，也可能不合适。阅读删除的含义，您可以根据应用程序的需要进行调整。