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

如您所见，sstables 的数量相当大。该表使用默认压缩 SizeTieredCompactionStrategy，最小阈值 4，最大阈值 32。

我的问题是:

1. 在节点数据量不大，sstables很小的情况下，为什么还有那么多sstables？这怎么(什么时候)发生的？

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

By default, a minor compaction can begin any time Cassandra creates four SSTables on disk for a column family. A minor compaction must begin before the total number of SSTables reaches 32.

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

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

Answer 1

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

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

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