Cassandra cfstats: Live和Total已用空间值之间的差异

Question

大约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

您可以注意到Live和Total空间之间有25%的差异(~254Gb)。似乎我在这3个节点上有很多垃圾，由于某种原因无法压缩。我所讨论的列族具有配置为SSTable大小为100Mb的LeveledCompaction策略:

create column family BinaryData with key_validation_class=UTF8Type 
  and compaction_strategy=LeveledCompactionStrategy 
  and compaction_strategy_options={sstable_size_in_mb: 100};

注意，在所有三个节点上，月份的总价值保持在。我使用Cassandra自动规范化数据。

我试图减少空间(没有结果):

1. nodetool清理
nodetool repair -pr
2. nodetool compact [KEYSPACE] BinaryData(没有发生任何事情:主要压缩被忽略的LeveledCompaction策略)

还有什么事情我应该尝试清理垃圾和空闲空间?

Answer 1

好了，我有办法了。看起来像是卡桑德拉的问题。首先，我深入研究了Cassandra 1.1.9的源代码，并注意到Cassandra在节点启动期间对sstable进行了一些重新分析。它删除标记为已压缩的sstable，重新计算已使用的空间，并执行一些其他工作。

所以，我所做的是重新启动3个问题节点。Total和Live值在重启完成后立即相等，然后压缩过程已经启动，现在使用的空间正在减少。

Answer 2

分级压缩创建固定的、相对较小的表，在您的例子中，它是100Mb，分为"级别"。在每一个层，表保证不重叠。每个级别都是是上一个的十倍。

所以基本上从cassandra doc中提供的这个陈述，我们可以得出结论，可能在你的情况下，十倍大的背景尚未形成，导致没有压实。

回到第二个问题，由于您将复制因子保持为3，因此数据有3个副本，因此您有此异常。

最后是Live和Total空间之间的25%的差异，正如您所知道的，这是由于删除操作。

Answer 3

对于LeveledCompactionStrategy，您希望将sstable大小设置为最大15 MB左右。100MB将导致您大量不必要的磁盘IO，并且它将导致数据传播到更高级别需要很长时间，使删除的数据保留很长时间。

对于大量的删除，你很可能遇到一些问题，在Cassandra 1.1中，小压缩没有很好地清理被删除的数据。在Cassandra 1.2中，有一堆修复了小压缩期间的墓碑清理。特别是当与LCS结合使用时。我会考虑在你的Dev/QA环境中测试Cassandra 1.2。1.2仍然有一些问题需要解决，所以你需要确保安装新版本，甚至在git中运行1.2分支，但是对于你的数据大小和使用模式，我认为它会给你一些明确的改进。