1

我对 Datastax 页面中关于调整 cassandra 压缩的以下几行有点不清楚。他们特别提到：

“管理员还可以通过 nodetool compact 启动主要压缩，它将所有 SSTables 合并为一个。虽然主要压缩可以释放累积的 SSTables 使用的磁盘空间，但在运行时它会暂时使磁盘空间使用量翻倍，并且是 I/O 和 CPU 密集型的。另外，一旦你运行了一次major compaction，自动的minor compactions 不再频繁触发，迫使你在例行的基础上手动运行major compactions。因此，虽然在major compaction 之后立即读取性能会很好，但它会持续降低直到下一次major compaction手动调用。因此，DataStax 不建议进行主要压缩。” （http://www.datastax.com/docs/1.0/operations/tuning）

读完这篇文章后，我想更好地理解的两个问题是：

  1. 为什么手动触发的主要压缩会更改次要压缩间隔/频率？我不太确定我是否遵循这背后的根本原因。
  2. 如果我确实需要使用 nodetool 手动运行主要压缩，是否有可能？如果可以，我如何恢复以确保次要压缩间隔不会因此受到影响并重置为默认行为。

谢谢。

4

2 回答 2

1

回答你的第二个问题：

“有可能吗？如果可以，我该如何恢复以确保较小的压实间隔不会受到影响”

[CASSANDRA_HOME]/bin/nodetool enableautocompaction

http://datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsNodetool_r.html

于 2015-03-30T10:44:12.650 回答
1

当major compaction运行时，它会将所有的SSTables合并到一个SSTable中。在大多数情况下，新创建的 SSTable 将明显大于将从 Memtable 中刷新的下一个 SSTable（使用 memtable_total_space_in_mb 定义）。如果您使用大小分层压缩，cassandra 将等待 4 个（再次默认）相同大小的 SSTable，然后再触发下一次次要压缩。这会延迟下一次自动次要压缩，因为主要压缩创建的 Cassandra SStable 不会与其他 SSTable (memtable_total_space_in_mb) 对齐。所以 Cassandra 不一定会停止自动小型压缩，但现在改变了频率。

“这甚至可能吗？如果可以，我该如何恢复以确保次要压实间隔不会因此受到影响并重置为默认行为。” - 为此，您将不得不打破由于主要压实而创建的大型稳定。为此，您可以使用名为“sstablesplit”的实用程序。

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSSTableSplit.html

于 2016-07-10T04:38:06.780 回答