在大约1个月的时间里，我在nodetool cfstats输出中看到了cassandra集群中3个节点的已用空间值（我的复制因子为3）：
Pending Tasks: 0
Column Family: BinaryData
SSTable count: 8145
Space used (live): 787858513883
Space used (total): 1060488819870对于其他节点，我看到了很好的值，例如：
Space used (live): 780599901299
Space used (total): 780599901299您可以注意到活动空间和总空间之间有25%的差异（~254gb）。似乎我有很多垃圾在这3个节点，不能压缩的原因。我所说的列族有一个leveledcompression策略，它的表大小为100mb：
create column family BinaryData with key_validation_class=UTF8Type
and compaction_strategy=LeveledCompactionStrategy
and compaction_strategy_options={sstable_size_in_mb: 100};请注意，在所有三个节点上停留一个月的总值。我依靠Cassandra自动规范化数据。
我试图减少空间的内容（没有结果）：
节点工具清理
节点工具维修-pr
nodetool compact[keyspace]binarydata（不会发生任何情况：leveledcompression策略忽略主要压缩）
我还应该做些什么来清理垃圾和腾出空间？
3条答案
按热度按时间nvbavucw1#
好的，我有个解决办法。看起来像是Cassandra的问题。首先，我深入研究了cassandra1.1.9的源代码，注意到cassandra在节点启动期间对sstables执行了一些重新分析。它删除标记为compacted的sstables，重新计算已用空间，并执行其他一些操作。
所以，我所做的是重新启动3个问题节点。重新启动完成后，总值和活动值立即变为相等，然后开始压缩过程，现在使用的空间正在减少。
n8ghc7c12#
对于leveledcompactionstrategy，您希望将sstable大小设置为最大15mb左右。100mb将给您带来大量不必要的磁盘io，并且会导致数据需要很长时间才能传播到更高的级别，从而使删除的数据长时间保留。
在cassandra 1.1中，由于删除量很大，很可能会遇到一些小压缩的问题，而在清除已删除的数据方面做得不好。在cassandra1.2中，有一系列修复程序用于在较小的压缩过程中清理墓碑。尤其是和lcs结合的时候。我想看看在dev/qa环境中测试cassandra1.2。1.2仍然有一些问题需要解决，所以您需要确保安装新版本，甚至运行git中的1.2分支，以保持最新，但是对于您的数据大小和使用模式，我认为它会给您一些明确的改进。
db2dz4w83#
分级压缩创建一个固定的、相对较小的表，在您的情况下，100mb被分组为“级别”。在每个级别中，sstables保证不重叠。每一关都是前一关的十倍大。
所以基本上从这句话提供的Cassandra文件，我们可以得出结论，可能是在你的情况下，十倍大的水平背景尚未形成，导致没有压缩。
接下来是第二个问题，因为您将复制因子保持为3，所以数据有3个重复的副本，对于这些副本，您有这个异常。
最后是活动空间和总空间之间25%的差异，正如您所知，这是由于过度删除操作。