Cassandra 因 TTL 过期而超时

Question

我正在使用带有预安装默认设置的 DataStax Community v 2.1.2-1 (AMI v 2.5)+ 将读取时间增加到 10 秒，这是问题

 create table simplenotification_ttl (
               user_id varchar, 
               real_time timestamp,
               insert_time timeuuid,
               read boolean,
               msg varchar, PRIMARY KEY (user_id, real_time, insert_time));

插入查询：

insert into simplenotification_ttl (user_id, real_time, insert_time, read) 
  values ('test_3',14401440123, now(),false) using TTL 800;

对于相同的“test_3”，我插入了 33,000 个元组。 [24,000 个元组不会出现这个问题]

渐渐地我明白了

cqlsh:notificationstore> select count(*)  from simplenotification_ttl where user_id = 'test_3'; 

 count
-------
 15681

(1 rows)

cqlsh:notificationstore> select count(*)  from simplenotification_ttl where user_id = 'test_3'; 

 count
-------
 12737

(1 rows)

cqlsh:notificationstore> select count(*)  from simplenotification_ttl where user_id = 'test_3'; 
**errors={}, last_host=127.0.0.1**

即使在不同的桌子上，我也已经多次尝试过。一旦发生这种情况，即使我使用相同的 user_id 插入并使用限制 1 进行检索。它会超时。

我需要 TTL 才能正常工作，即在推测时间后给出计数 0。如何解决这个问题？ 谢谢

[我的其他节点相关设置是使用 m3.large 和 2 个节点 EC2Snitch]

Answer 1

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

如果您打开跟踪然后尝试您的 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 天更频繁地清理墓碑，但根据您的应用程序，这可能合适，也可能不合适。阅读删除的含义，您可以根据应用程序的需要进行调整。