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;

对于同样的＆＃39; test_3＆＃39;我插入了 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。如何解决这个问题？感谢

[我的其他节点相关设置正在使用带有2个节点EC2Snitch的m3.large]

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

Cassandra由于TTL过期而计时

1 个答案: