关于level压缩策略的level0问题

Cassandra一开始是要写commitlog，当commitlog写到一定大小就会刷到一个sstable文件，再加上对于cassandra，删除也是一种写，这样下去sstable文件会越来越多。必须有一种机制来合并这些文件，并删除墓碑(标记为删除的记录)，这种机制叫做compaction，先翻译为压缩。既然要合并文件，就要有合并策略。cassandra一开始只有size模式的压缩策略。后来增加了level压缩。

level压缩提高了读的性能，但是level压缩相比较size压缩更慢，因为它是要保证每个level都有一定数量的文件，新产生的文件都是level 0的状态，同时在执行的压缩任务是有限制的，当几个高level的文件在压缩的时候，可能导致level0的文件堆积。

level压缩需要保证低级别的level的文件较少，是为了提高查询的效率。

为了避免level0的文件因为大量写入而得不到压缩。cassandra采取了一种策略，就是level 0文件数目超过一定限制(默认32)，就在level 0采用size压缩，通过合并快速减少 level 0文件数量，同时暂停高level的文件压缩。

这个设计在正常情况下是有好处的。但是当我们扩容一个节点的时候，新增节点的文件全部在level 0。

sstable level 12222 0 0 0 0 0 0 0

那么cassandra会的持续进行level 0的 size压缩。直到level 0的文件减少到32以下

sstable level 32 0 0 0 0 0 0 0

这样你会发现新扩节点会一开始产生一个超大文件，然后再拆分成个个小文件的现象。

问题是:如果你有6个500G的磁盘，而你的单节点数据是2T，那么你的节点会因为空间不足而挂掉。

解决这个问题有两种方法:

一种是磁盘做raid，搞成一个大磁盘。

一种是临时关闭level 0的size压缩，这又是cassandra的一个隐藏技能，在cassandra官方文档里你不会找到。就是启动的时候加禁用level 0 使用 size压缩的参数:

./cassandra -Dcassandra.disable_stcs_in_l0=true

注意这个参数从cassandra 2.0.10以后的版本才有。当解决了问题后建议把该参数还原。因为在 level 0采用size压缩，对于突发写入大量的数据的情况还是有好处的。

参考 https://issues-test.apache.org/jira/browse/CASSANDRA-6621