2

大约 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 个节点上有很多垃圾，由于某种原因无法压缩。我正在谈论的列族具有配置为 100Mb SSTable 大小的 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. 节点工具清理
  2. 节点工具修复-pr
  3. nodetool compact [KEYSPACE] BinaryData（什么都没有发生：LeveledCompaction 策略忽略主要压缩）

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

4

3 回答 3

1

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

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

于 2013-05-05T03:24:17.603 回答
0

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

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

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

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

于 2013-05-04T19:57:54.420 回答
0

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

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

于 2013-05-05T01:29:02.697 回答