Database Reference
In-Depth Information
LeveledCompaction
The LeveledCompactionStrategy is a new compaction strategy introduced into
Cassandra in the 1.0 release. It is based on (but not an exact implementation of)
Google's LevelDB. It is best suited for ColumnFamilys with read-heavy work-
loads that have frequent updates to existing rows. The key thing to monitor when
using LeveledCompaction is read latency. If a node cannot keep up with the write
workload and pending compactions as a result of the write workload, read per-
formance will begin to degrade substantially.
If you decide that you want to change the compaction strategy for a Colum-
nFamily, you can do so with a schema change using the Cassandra-cli.
Listing 7.7
shows an example of a healthy three-node ring.
Listing 7.7
Healthy Three-Node Ring
ALTER TABLE users
WITH compaction={'class': 'LeveledCompac-
tionStrategy',
'sstable_size_in_mb': 160}
Impact
When it comes to running compactions, there are a few things to keep in mind.
Since minor compactions run automatically, there is nothing to keep track of or
think about. When Cassandra needs to run one, it will. But major compactions (es-
pecially those run as a result of a
nodetool repair
) can add a lot of load to
the system. Depending on the size of your data and how out of sync it is between
replica sets, the length of the repair can range from hours to days.
It is typically best, if possible, to have repairs running during off-peak hours for
the cluster. There are even ways to tune the speed of the repair to further take ad-
vantage of the repair window. By setting the compaction and streaming thresholds,
you can increase the speed at which
nodetool
performs its work. The default for
streaming and compaction is set to 16MB/s. You can change these settings from
the command line. If network throughput and disk I/O aren't a problem, unthrot-
tling the compaction throughput and stream throughput may be a good decision.
