Cassandra cfstats：Live 和 Total used space 值之间的差异答案

【问题标题】：Cassandra cfstats: differences between Live and Total used space valuesCassandra cfstats：Live 和 Total used space 值之间的差异
【发布时间】：2013-04-27 07:48:18
【问题描述】：

在大约 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 个节点上有很多垃圾，由于某种原因无法压缩。我正在谈论的列族有一个 LeveledCompaction 策略，SSTable 大小配置为 100Mb：

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

请注意，总价值在所有三个节点上保持一个月。我依靠 Cassandra 自动规范化数据。

我试图减少空间的内容（没有结果）：

nodetool 清理
nodetool 修复-pr
nodetool compact [KEYSPACE] BinaryData（什么都没有发生：LeveledCompaction 策略忽略主要压缩）

还有什么我应该尝试清理垃圾和可用空间的事情吗？

【问题讨论】：

您在这个月的时间段内是否进行了大量的删除操作？
我想是的，我没有一个精确的值，可能有 100Gb-1Tb 之间的数据被删除了。但是为什么我的集群中只有 3 个节点有这个问题？为什么集群中的其余节点有 Live == Total？我正在使用 Cassandra 1.1.9

标签： cassandra

【解决方案1】：

Leveled compaction 创建一个固定的、相对较小的 sstable，在您的情况下，它是 100Mb 被分组为“级别”。每个内级别，sstables 保证不重叠。每个级别都是是以前的十倍。

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

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

最后，Live 和 Total 空间之间存在 25% 的差异，正如您所知道的那样，它是由于过度删除操作所致。

【讨论】：

谢谢。但是为什么只有3个节点，为什么其他节点不影响这个问题？无论如何，请参阅下面的解决方案
智能移动 ;)。好吧，那总是在卡上。无论如何，您使用过哪个分区程序？数据分布取决于分区器，这可能会告诉您为什么只有 3 个受影响的节点。

【解决方案2】：

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

在删除大量数据的情况下，您很可能会遇到一些小压缩问题，在 Cassandra 1.1 中清理已删除数据的工作效果不佳。在 Cassandra 1.2 中的小型压缩期间，有许多用于墓碑清理的修复。尤其是与 LCS 结合使用时。我会看看在您的开发/质量保证环境中测试 Cassandra 1.2。 1.2 仍然有一些问题需要解决，所以你需要确保及时更新安装新版本，甚至在 git 中运行 1.2 分支，但是对于你的数据大小和使用模式，我认为它会给你一些明确的改进。

【讨论】：

我会尝试 1.2。请参阅下面的解决方案

【解决方案3】：

好的，我有一个解决方案。它看起来像 Cassandra 问题。首先，我深入研究了 Cassandra 1.1.9 的源代码，并注意到 Cassandra 在节点启动期间对 SStables 进行了一些重新分析。它会删除标记为已压缩的 SStable，重新计算已用空间，并执行一些其他操作。

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

【讨论】：