5

I am quite new to using Cassandra and have a basic question that I was seeking an answer to. I am using the default compaction strategy which the Size-Tiered. I am aware that this can be changed to the Levelled Compaction strategy by running a command like this:

ALTER TABLE users WITH
compaction = { 'class' :  'LeveledCompactionStrategy'  }

I am however unsure if this change takes into effect at runtime on a particular keyspace, or if I would need to restart the node for the changes to take effect. I read in the Datastax documentation (http://www.datastax.com/documentation/cassandra/1.2/cassandra/configuration/configCassandra_yaml_r.html) that changes to global configurations in the cassandra.yaml file only takes effect after a node is restarted and would like to know if the same applies for the keyspace specific properties like compaction strategy as well.

Thanks in advance for your help.

Rohit
  • 523
  • 2
  • 6
  • 25

2 Answers2

3

The newer documentation on configuring compaction indicates that the correct procedure to enable Leveled Compaction is the ALTER TABLE statement that you have above. While you are correct that changes to the cassandra.yaml file will require a node(s) restart to take effect, table configuration changes typically do not. It should use Leveled Compaction for that table the next time compaction is triggered.

Additionally, you should read through Tyler Hobbs' article titled When to Use Leveled Compaction. Since you are new to Cassandra, give that a look just to be sure you have an appropriate use case.

Aaron
  • 55,518
  • 11
  • 116
  • 132
  • 1
    Thanks for the quick reply Bryce. I did indeed take a look at the article you posted just a few hours back :) and I think we do have a strong use case for it based on the fact that we: 1) Though Cassandra is typically write optimal, we have a use case with a high read and write ratio. 2) Read latencies are equally important to us. 3) And we also update the data frequently in addition to just writes. That being said, I am still to evaluate this completely and need to gather all the facts myself (Which is what I was doing) before suggesting this to my team. – Rohit Oct 29 '14 at 21:23
  • Also, is there a way I can flip the strategy and verify that it actually uses a correct one, besides actually going in and checking the size of the SS Tables, etc. – Rohit Oct 29 '14 at 21:35
  • @Rohit That's a great question, and I do not know if there is. There doesn't appear to be anything in the logs or in the output of `nodetool compactionstats` to indicate what compaction strategy is being used. – Aaron Oct 29 '14 at 21:46
  • 1
    I also glanced through the JMX mBean data that is being exposed, but doesn't look like there is anything there either about the strategy it uses. I guess I would have to verify the hard way. Thanks Bryce. – Rohit Oct 30 '14 at 12:33
0

You can modify compaction strategy online for sure. Cassandra will recompact all sstables, so only concern is disk I/O. pre-2.1, the old sstable is replaced only after the new sstable is created. after 2.1, new sstable can serve traffic during the creation (mainly to preserve page cache, refer CASSANDRA-6916). so basically, your traffic will not be affected.

I know some companies, e.g, netflix perform this change via jmx host by host to prevent cluster-wide thundering storm. But I don't see any issue with ALTER TABLE for our cluster.

del bao
  • 1,084
  • 1
  • 11
  • 20