首页 文章

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

提问于
浏览 次
1

大约1个月，我在 nodetool cfstats 输出的Cassandra集群中看到3个节点的使用空间的以下值（我有复制因子= 3）：

Pending Tasks: 0
            Column Family: BinaryData
            SSTable count: 8145
            Space used (live): 787858513883
            Space used (total): 1060488819870

对于其他节点，我看到了很好的 Value ，例如：

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};

注意，总值在所有三个节点上保持 for month . 我依靠Cassandra自动规范化数据 .

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

  • nodetool清理

  • nodetool repair -pr

  • nodetool compact [KEYSPACE] BinaryData（没有任何反应：LeveledCompaction策略忽略主要压缩）

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

cassandra

3 回答

  • 0

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

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

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

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

    回复于
  • 0

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

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

    回复于
  • 0

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

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

    回复于

相关问题