Cassandra手册主要压实改变次要压缩的频率

时间:2014-10-29 20:58:24

标签: cassandra datastax nodetool

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

"管理员还可以通过nodetool compact启动主要压缩,将所有SSTable合并为一个。虽然主要的压缩可以释放累积的SSTable使用的磁盘空间,但在运行时它会暂时使磁盘空间使用量增加一倍,并且是I / O和CPU密集型的。此外,一旦您执行主要压缩操作,就不会再频繁触发自动次要压缩,从而迫使您按常规手动运行主要压缩。因此,虽然在主要压缩之后读取性能会很好,但它会不断降级,直到手动调用下一个主要压缩。因此,DataStax不推荐进行主要压实。" (http://www.datastax.com/docs/1.0/operations/tuning

阅读此内容之后的两个问题在我脑海中浮现,我想要更好地理解:

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

    感谢。

2 个答案:

答案 0 :(得分:1)

回答你的第二个问题:

“它是否可能,如果是这样,我怎样才能恢复以确保轻微的压实间隔不会受到影响”

[CASSANDRA_HOME]/bin/nodetool enableautocompaction

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

答案 1 :(得分:1)

当运行主要压缩时,它会将所有SSTable合并为一个SSTable。在大多数情况下,新创建的SSTable将明显大于将从Memtable刷新的下一个SSTable(使用memtable_total_space_in_mb定义)。如果您使用大小分层压缩,cassandra将在触发下一次轻微压缩之前等待4(同样默认)相同大小的SSTable。这会延迟下一次自动轻微压缩,因为主压缩创建的Cassandra SStable不会与其他SSTable(memtable_total_space_in_mb)一致。因此Cassandra不一定会停止自动轻微压缩,但频率现在已经改变了。

“它是否可能,如果是这样,我怎样才能恢复以确保次要压缩间隔不会因此而受到影响并重置为默认行为。” - 为此,你将不得不打破由于重大压缩而创建的大型sstable。为此,您可以使用名为'sstablesplit'的实用程序。

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