我们有了一个运行cassandra2.2.14的新集群，并留下了一些压缩来“整理自己”。这是在我们的uat环境中，所以负载很低。我们运行STC。
我们看到的是不断增长的墓碑。我知道一旦sstable符合压缩条件，压缩最终会处理数据。这种情况对我们来说还不够频繁，所以我启用了一些设置作为测试（我知道它们具有攻击性，这纯粹是为了测试）：

'tombstone_compaction_interval': '120', 
'unchecked_tombstone_compaction': 'true', 
'tombstone_threshold': '0.2', 
'min_threshold': '2'

这确实导致了一些压缩发生，但是下降的墓碑数量很低，也没有低于阈值（0.2）。应用这些设置后，我可以从sstablemetadata中看到：

Estimated droppable tombstones: 0.3514636277302944
Estimated droppable tombstones: 0.0
Estimated droppable tombstones: 6.007563159628437E-5

请注意，这只是一个cf，还有更糟糕的cf（90%的墓碑等）。以这个为例，但是所有的cf都有相同的症状。
表状态：

SSTable count: 3
                Space used (live): 3170892738
                Space used (total): 3170892738
                Space used by snapshots (total): 3170892750
                Off heap memory used (total): 1298648
                SSTable Compression Ratio: 0.8020960426857765
                Number of keys (estimate): 506775
                Memtable cell count: 4
                Memtable data size: 104
                Memtable off heap memory used: 0
                Memtable switch count: 2
                Local read count: 2161
                Local read latency: 14.531 ms
                Local write count: 212
                Local write latency: NaN ms
                Pending flushes: 0
                Bloom filter false positives: 0
                Bloom filter false ratio: 0.00000
                Bloom filter space used: 645872
                Bloom filter off heap memory used: 645848
                Index summary off heap memory used: 192512
                Compression metadata off heap memory used: 460288
                Compacted partition minimum bytes: 61
                Compacted partition maximum bytes: 5839588
                Compacted partition mean bytes: 8075
                Average live cells per slice (last five minutes): 1.0
                Maximum live cells per slice (last five minutes): 1
                Average tombstones per slice (last five minutes): 124.0
                Maximum tombstones per slice (last five minutes): 124

显而易见的答案是，这些墓碑没有资格被移走。
gc\u grace\u seconds设置为10天，尚未移动。我将其中一个sstable转储到了json，我可以看到2019年4月的墓碑：

{"key": "353633393435353430313436373737353036315f657370a6215211e68263740a8cc4fdec",
 "cells": [["d62cf4f420fb11e6a92baabbb43c0a93",1566793260,1566793260977489,"d"],
           ["d727faf220fb11e6a67702e5d23e41ec",1566793260,1566793260977489,"d"],
           ["d7f082ba20fb11e6ac99efca1d29dc3f",1566793260,1566793260977489,"d"],
           ["d928644a20fb11e696696e95ac5b1fdd",1566793260,1566793260977489,"d"],
           ["d9ff10bc20fb11e69d2e7d79077d0b5f",1566793260,1566793260977489,"d"],
           ["da935d4420fb11e6a960171790617986",1566793260,1566793260977489,"d"],
           ["db6617c020fb11e6925271580ce42b57",1566793260,1566793260977489,"d"],
           ["dc6c40ae20fb11e6b1163ce2bad9d115",1566793260,1566793260977489,"d"],
           ["dd32495c20fb11e68f7979c545ad06e0",1566793260,1566793260977489,"d"],
           ["ddd7d9d020fb11e6837dd479bf59486e",1566793260,1566793260977489,"d"]]},

所以我不相信这里的问题是gc\u grace\u seconds。我已经对column family文件夹中的每个data.db文件（单个data.db文件，一次一个）运行了手动用户定义的压缩。压缩运行，但墓碑值几乎没有变化。旧数据仍然存在。
事实上，我可以确认昨天已经修好了。我还可以确认维修工作一直在正常进行，日志中没有显示任何问题。
所以修理是好的。压实很好。我所能想到的就是重叠的table。
最后的测试是对柱族进行完全压实。我使用jmxterm在3个sstables上执行了一个用户定义的（不是nodetool compact）。这导致了一个单一的sstable文件，包含以下内容：

Estimated droppable tombstones: 9.89886650537452E-6

如果我查找上面的示例epoch（1566793260），它是不可见的。关键也不是。所以它被压缩了或者Cassandra做了些什么。在1.2亿行转储中，包含墓碑（“d”）标志的行总数为1317行。历元值都在10天之内。很好。
所以我假设-6值是一个非常小的百分比，sstablemetadata在显示它时遇到了问题。那么，成功是吧？但是，要把这些旧墓碑完全压实掉。据我所知，完全压实只是最后一搏。
我的问题是-
如何确定重叠的sstables是否是我的问题？我看不出有什么其他的原因，除非数据是重叠相关的，否则数据不会压缩。
如何在不执行完全压缩的情况下解析重叠的sstables？恐怕这几周后会再次发生。我不想被困在必须定期进行充分压缩，以保持在海湾墓碑。
创建重叠sstables的原因是什么？这是数据设计问题还是其他问题？
干杯。