Cassandra没有压缩sstables？

Question

nodetool cfstats 显示以下输出：

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 **

如您所见，sstable 的数量非常多。该表使用默认压缩 SizeTieredCompactionStrategy，最小阈值为 4，最大值为 32。

我的问题是：

1. 考虑到节点中的数据量不大，sstables很小，为什么还有这么多sstables？这如何（何时）发生？

2. SizeTieredCompactionStrategy 何时真正触发压缩？在the other post 我发现：

默认情况下，小压缩可以在 Cassandra 创建的任何时候开始 磁盘上的四个 SSTables 用于列族。必须进行轻微压实 在 SSTable 总数达到 32 之前开始。

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

我问的原因是由于大量的墓碑（上面输出中的最后一行）和 sstables，读取延迟变得非常糟糕。 gc_grace_period 保持低值，但由于 Cassandra 没有压缩 sstable，所以墓碑仍然存在。还是我错过了什么？

Answer 1

考虑到节点中的数据量不大，sstables很小，为什么还有这么多sstables？这如何（何时）发生？ - 这可能会发生，尤其是当 sstable 的尺寸非常小时。运行小压缩时，所有小于 min_sstable_size（默认为 50mb）的 sstable 将被放置在同一个存储桶中。当桶被考虑用于压缩时，sstables 最高 max_threshold（默认 32）将被考虑用于压缩，其余部分将被单独处理。因此，对于您的数据，如果所有 230 个 sstable 都非常小，那么每个次要 gc 只会考虑压缩 32 个。

如果未触发压缩，您可能已关闭自动压缩。您可以通过更改压缩参数来通过 CQL 更改表。例如，

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

说了这么多，我首先要调查一下为什么会创建这么多小型 sstable。您的 memtable 或 commitlog 大小设置为一个较小的值，或者以某种方式过早调用刷新。

Answer 2

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

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

对此进行测试，将发布结果。

Answer 3

使用SizeTieredCompactionStrategy，它只会压缩大小相似的SSTable。

问题是当您有很多大小不同的 SSTable 时，它​​们不会被选为压缩的候选对象。

在 STCS 中运行手动压缩时要小心，因为您最终可能会得到不成比例的大 SSTable，这些 SSTable 将永远不会再次被压缩，因为它没有类似大小的伙伴，或者可能需要很长时间才能找到另一个类似大小的 SSTable来了。