【问题标题】:Controlling Major Compaction in Cassandra控制 Cassandra 中的主要压缩
【发布时间】:2013-01-28 00:46:10
【问题描述】:

我对 Cassandra 比较陌生,所以如果我遗漏了一些明显的东西,我提前道歉。 因此,我在单节点集群中使用 cassandra 1.0.12 并进行大量写入和删除(大约 1000/秒)。由于我的磁盘空间不断增加,写入比删除更频繁。如果我理解正确,压缩将帮助我实现这一目标(主要和次要)。所以我将 setGc_grace_seconds 更改为 0 并将 setMin_compaction_threshold 更改为 2。即使在设置这些值之后,我看到该列族的 SSTable 计数为 4 ,当 SSTable 计数为 2 时它不应该启动压缩吗?此外,主要压缩何时开始以及如何控制它(我想更频繁地运行它)。

【问题讨论】:

  • 如果您在低于 ConsistencyLevel.ALL 的条件下进行删除,请注意将 gc_grace_seconds 设置为 0;你可以很容易地得到僵尸数据:wiki.apache.org/cassandra/DistributedDeletes
  • 我认为应该没问题,因为我使用的是单节点集群。

标签: cassandra


【解决方案1】:

如果你使用 Size-tiered compaction,minor compaction 有时会在磁盘上至少创建 类似大小的 min_compaction_threshold SSTables 之后自动触发。因此,在您的情况下,有时在创建了两个类似大小的 SSTable 之后,小型压缩将启动并将这两个 SSTable 合并到一个新的 SSTable 中。 Tuning options for Size-tiered compaction

主要压缩是通过nodetool 手动触发的。 “对于键空间中的每个列族,这会将所有现有的 SSTable 压缩为一个 SSTable”。

【讨论】:

  • 我想我忽略了 相似的大小 感谢您指出,也许这就是我们没有看到压缩启动的原因。
猜你喜欢
  • 1970-01-01
  • 2014-12-25
  • 2019-10-18
  • 2019-07-21
  • 2019-06-11
  • 2019-11-25
  • 2019-10-26
  • 2020-07-12
  • 1970-01-01
相关资源
最近更新 更多