Question

我正在使用带有预安装默认设置的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个节点。在m3large上有1 x 32（SSD）。即使在这个特定的桌子上将一致性设置为ONE，我也面临超时问题。

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

我想知道问题是否可以及时生存？或者是否有任何其他配置任何对此重要的调整。

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

感谢。

Answer 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天更频繁地清理，但根据您的应用程序可能适合或不适合。阅读删除的含义，您可以根据应用需要进行调整。

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

1 个答案: