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

您可以注意到实时和总空间之间有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自动规范化数据。

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

nodetool cleanup
nodetool repair -pr
nodetool compact [KEYSPACE] BinaryData（没有任何反应：LeveledCompaction策略会忽略主要压缩）

还有其他事情我应该尝试清理垃圾和自由空间吗？

Answer 1

水平压实会产生固定的，相对较小的尺寸，在你的情况下，它是100Mb，分为“级别”。在每个级别，sstables保证不重叠。每个级别都是是之前的十倍。

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

来到第二个问题，因为你已经将复制因子保持为3，所以数据有3个重复副本，你有这个异常。

最后，Live和Total空间之间有25％的差异，因为您知道它应该删除操作。

Answer 2

对于LeveledCompactionStrategy，您希望将sstable大小设置为最大约15 MB。 100MB将导致你需要大量不必要的磁盘IO，这将导致数据传播到更高级别需要很长时间，使得删除的数据长时间保持不变。

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

Answer 3

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

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

Cassandra cfstats：实时和总使用空间值之间的差异

3 个答案: