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。

我的问题是：

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

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

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

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

Answer 1

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

问题是当你有很多不同尺寸的SSTable时，它们不会被选为压缩的候选者。

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

Answer 2

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

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

测试一下，会发布结果。

Answer 3

为什么还有那么多sstables考虑到节点中的数据量不大而且sstables很小？这怎么可能发生？ - 这可能会发生，特别是当sstables的规模非常小时。当运行次要压缩时，所有小于min_sstable_size（默认为50mb）的sstables将被放置在同一个存储桶中。当桶被认为是压实时，最高max_threshold（默认值为32）将被考虑进行压实，其余部分将被保留。因此，对于您的数据，如果所有230个sstables都非常小，那么只有32个将被考虑用于压缩每个次要gc。

如果未触发压缩，则可能会启用自动压缩。您可以通过更改压缩参数来通过CQL更改表。例如，

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

所有这一切，我会首先调查为什么这么多小型sstables被创造出来。您的memtable或commitlog大小设置为较小的值，或者某种方式很快就会调用flush。

卡桑德拉没有压缩sstables？

3 个答案: