Cassandra sstables累积

我一直在测试Cassandra来存储观察值。所有“东西”属于一个或多个报告组：Cassandra sstables累积

CREATE TABLE observations (
    group_id int, 
    actual_time timestamp, /* 1 second granularity */ 
    is_something int, /* 0/1 bool */ 
    thing_id int, 

    data1 text,  /* JSON encoded dict/hash */ 
    data2 text,  /* JSON encoded dict/hash */ 
    PRIMARY KEY (group_id, actual_time, thing_id) 
) 
WITH compaction={'class': 'DateTieredCompactionStrategy', 
     'tombstone_threshold': '.01'} 
AND gc_grace_seconds = 3600; 

CREATE INDEX something_index ON observations (is_something);

所有刀片具有TTL完成，之后 “actual_time”本应到期时36小时。某些超出我们控制范围的是我们向我们发送了重复的观测结果。一些观察结果发送时间接近实际，其他时间延迟了几个小时。

的“something_index”是一个实验，看看我们是否能够在布尔属性片查询无需创建单独的表，并似乎工作。

“数据2”是不是目前正在written--是指由不同的工艺写道：“数据1”被写入，但会被赋予相同的 TTL（基于“actual_time”）。

情况：

三个节点（EC2 m3.xlarge） Datastax AMI-ada2b6c4（美国东部-1）从Python程序

插入安装使用2015年8月26日卡桑德拉2.2.0

“cql”模块（必须启用“thrift”RPC）

每三个小时（交错）在每个节点上运行“nodetool repair -pr”。

每小时插入1到4百万行。我看到数据了大量文件：

$ ls *Data* | wc -l 
42150 
$ ls | wc -l 
337201

查询不会返回过期的条目，但文件日期早36小时都不会消失！

来源

2015-09-04 Phil Budne

也许还想看看http://stackoverflow.com/questions/29431217/huge-number-of-sstables-after-adding-server-to-existing-cluster/31347085#31347085 – Aaron

大量的SSTables可能是由于您正在运行的频繁维修造成的。维修通常只会每天运行一次或每周运行一次，所以我不确定为什么每三个小时运行一次维修。如果您担心短期宕机时间缺少写入，那么您可以将提示窗口设置为三个小时，而不是频繁地运行修复。您可能会看到CASSANDRA-9644。这听起来像是描述你的情况。 CASSANDRA-10253也许是有趣的。

我不知道为什么你的TTL不能丢弃旧的SSTables。你是在整行插入还是个别列更新上设置TTL？如果你在数据文件上运行sstable2json，我想你可以看到TTL值。

来源

2015-09-04 20:30:58

我可能有当我有一组较小的节点（运行接近完整）时开始频繁修理，并且在空间不足时维修失败。 –

TTL设置在整行插入。 –

我丢下了桌子，并重新开始而没有做任何修理。 sstables不再像兔子一样繁殖。但旧文件不会被删除（重启时除外）。 sstable2json只显示删除的行。 –

完全披露：我与DTCS有爱/恨的关系。我使用DTCS管理数百TB数据的集群，它绝对可怕的一件事情是任何类型的数据流。出于这个原因，我建议替换它（https://issues.apache.org/jira/browse/CASSANDRA-9666）。

这就是说，它应该主要是工作。但是，有些参数可以发挥作用，例如timestamp_resolution，如果设置不当，可能会导致错误。

您是否检查过sstable时间戳以确保它们匹配timestamp_resolution（默认值：微秒）？

来源

2015-09-05 06:47:09

未删除的条目：[“2015-09-05 18 \\：40Z：1618637：xxx”，“yyy”，1441485944379000，“e”，3259,1441489203]，已删除的条目：[“2015-09-05 14 \\：28Z：93571：xxx“，1441463731,1441463731900000，”d“] –

我会提出'sstablemetadata'，它会给你时间戳。它看起来像你的时间戳是微型的，但我不知道你用什么工具来检查，所以我也不确定格式。 –

分组输出来自sstable2json .... sstablemetadata给出：'分区程序：org.apache.cassandra.dht.Murmur3Partitioner 布隆过滤器FP机会：0.010000 最小时间戳：1441463429477001 最大时间戳：1441463841759000 的SSTable最大本地删除时间：1441474459 压缩比：-1.0 估计可投放墓碑：0.9144014277869302 的SSTable级别：0 修复在：0 ReplayPosition（segmentId = 1441464038299，位置= 291）' –

Cassandra sstables累积

回答

相关问题