Cassandra没有压缩sstables？

nodetool cfstats显示我下面的输出：Cassandra没有压缩sstables？

Read Count: 746287 
Read Latency: 8.772114064696291 ms. 
Write Count: 135629 
Write Latency: 0.052691931666531494 ms. 
Pending Flushes: 0 
    Table: graphindex 
    ** SSTable count: 230 ** 
    Space used (live): 1532001 
    Space used (total): 1532001 
    Space used by snapshots (total): 0 
    SSTable Compression Ratio: 0.8071848230527264 
    Memtable cell count: 159436 
    Memtable data size: 2609278 
    Memtable switch count: 1 
    Local read count: 746287 
    ** Local read latency: 8.773 ms ** 
    Local write count: 135629 
    Local write latency: 0.053 ms 
    Pending flushes: 0 
    Bloom filter false positives: 1122 
    Bloom filter false ratio: 0.00000 
    Bloom filter space used: 39312 
    Compacted partition minimum bytes: 43 
    Compacted partition maximum bytes: 20501 
    Compacted partition mean bytes: 70 
    Average live cells per slice (last five minutes): 320.3775491198426 
    Maximum live cells per slice (last five minutes): 3183.0 
    ** Average tombstones per slice (last five minutes): 7997.852040836836 ** 
    ** Maximum tombstones per slice (last five minutes): 27078.0 **

正如你可以看到sstables的数量是相当大的。该表使用默认压缩SizeTieredCompactionStrategy与最小极限4和最大32

我的问题是：

为什么还是有那么多的sstables考虑到数据的节点的量并不大和sstables很小？如何（何时）发生这种情况？
当SizeTieredCompactionStrategy实际触发压缩？在the other post我发现：

默认情况下，未成年人可压实开始任何时候卡桑德拉为列族在磁盘上创建 4 SSTables。 A小调压实必须开始之前SSTables总数达到32

但如果sstables的数量已经超过了32我应该怎么办？手动运行主要压缩是唯一的解决方案吗？

我问的原因是由于大量的墓碑（上面输出的最后一行）和sstables，读取延迟变得非常糟糕。 gc_grace_period保持在较低的价值，但由于卡桑德拉没有紧凑的sstables，墓碑仍然在那里。或者我错过了什么？

来源

2015-02-10 Adam Dyga

我有成千上万的sstables同样的问题。你有没有找到解释？ – tbsalling 2015-03-27 18:54:47

不幸的不是。我见过很多尺寸完全相同的sstables，这些sstables没有压缩... – 2015-03-27 20:20:02

您是否尝试过在每个节点上运行'nodetool enableautocompaction'？我认为这将使STCS在后台运行。 – tbsalling 2015-03-28 21:33:39

随着SizeTieredCompactionStrategy，它只会紧凑大小相似的SSTables。

问题是，当你有许多不同大小的SSTables时，他们不会被选为压实的候选人。

在STCS中运行手动压缩时要小心，因为最终会导致不成比例的大型SSTables，因为它不会有类似大小的合作伙伴，所以它不会再次压缩，或者可能需要很长时间才会再次压缩， SSTable出现。

来源

2015-02-11 03:40:11 flightc

感谢提示。我检查了sstable的大小，发现仍然有很多大小完全相同（以字节为单位），这仍然让我想知道为什么Cassandra不会压缩它们。 nodetool compactionstats 尚未完成的任务：129 我会让几天集群运行，看看 – 2015-02-11 13:11:27

我在调查我遇到的类似问题。 cassandra问题跟踪中有这ticket。

好的，这发生在cassandra决定重新分配索引摘要时，默认每60分钟一次。处理修复，但同时这可以通过在cassandra.yaml中将index_summary_resize_interval_in_minutes设置为-1来禁用此功能来避免。

测试这个，会发布结果。

来源

2015-11-10 16:37:06

至于建议，我在cassandra.yaml 只要我重新启动节点，BAM设置index_summary_resize_interval_in_minutes为-1怎么了。 – 2015-11-10 16:48:18

-1

为什么仍然有这么多的sstables考虑到节点中的数据量不大并且sstables很小？如何（何时）发生这种情况？ - 这可能会发生，尤其是当sstables非常小时。当轻微压缩运行时，所有小于min_sstable_size（默认为50mb）的sstable将被放置在同一个桶中。当考虑压实桶时，将考虑将压力稳定在max_threshold（默认32）以进行压实，并且休息将被单独保留。因此，对于您的数据，如果所有230个sstables都非常小，则只会考虑32个用于每个次要gc的压缩。

如果压实不触发，您可能会自动压缩。您可以通过更改压实参数来通过CQL更改表格。例如，

ALTER TABLE table1 WITH compaction = {'class': 'SizeTieredCompactionStrategy', 'enabled': true} ;

所有这一切说，我会先研究为什么是造成了太多的小sstables。无论是你的memtable或commitlog大小设置为一个小值，或者某种程度上，flush过早被调用。

来源

2016-10-15 08:04:09 user2903819

它确实提供了一个可能的答案（实际上是两个）“为什么仍然有这么多sstables”。可能还有其他因素，但答案基于提供的数据。 – user2903819 2016-10-25 19:24:34

Cassandra没有压缩sstables？

回答

相关问题