Cassandra SizeTieredCompaction策略解析
国内研究使用Cassandra的似乎并不多，远没有Hbase那般火热。偏巧，我就在这块儿并不火热的地方，耕耘了一年多。这一年，有深入研究，有实际运维。我打算把这些东西总结出来(前面也写了一些)，希望对后来使用的同学有帮助。而且，
我坚信，使用Cassandra的团队会越来越多。
这篇博客我来解释以下SizeTiered策略，这是一个Cassandra1.0之前的比较简单的Compaction策略。我之前的博客有粗略讲过leveled策略（后面会找时间丰富以下）。SizeTiered策略比较简单，可是尽管简单，如果不深入代码，在实际运维的时候，还是会出现异常现象而无法解释，找不到解决办法。SizeTiered策略的主要内容在类SizeTieredCompactionStrategy中，继承了AbstractCompactionStrategy类。 这里还要说明以下，Cassandra1.1前后的SizeTiered策略也是不同的，API也有变化，在1.1之前，叫做getBackgroundTasks方法，在1.1以后，叫做getNextBackgroundTask。他们的主要差别在于1.1之前，会对每个tier进行计算，满足条件，就会就进行Compaction，所以，会同时有多个tier参与到Compaction中；而1.1之后，是优先处理低tier的数据进行Compaction，也就是文件比较小的那些tier。这样做的好处有：
- 加速Compaction操作，减少文件数量
- 降低Compaction带宽，从而可以降低对读性能的影响
- 更加适宜更新频繁的应用场景
真心不会写源码阅读类的博客，我还是罗列一些比较重要的点吧，我尽量提到代码中的类名，方法名可以对照分析：
- 两个比较重要的参数：MinimumCompactionThreshold， MaximumCompactionThreshold。当每一个tier的文件数量，大于前者的时候，可以参与到Compaction中，但是参与Compaction的文件数量，不会超过后者。前者默认是4，后者默认是32.
- 划分tier的依据是sstable文件的大小，具体在函数getBuckets中，比如有一个1G的sstable，大于0.5G的和小于1.5G的，都可以划到一个tier中。而leveled是将level写在json文件中的
- 每次Compaction都是写入时间比较久的sstable优先参与合并的
- 一个问题，如果要合并的sstable文件，大于磁盘剩余空间怎么处理？这个要看CompactionTask中的execute方法，方法首先会判断，空闲空间是否足够。有一个比较重要的方法partialCompactionsAcceptable，含义是：是否允许部分的sstable参与到Compaction中。SizeTiered只要不是手工启动的Compaction操作，这个函数都是返回true。而leveled永远是false。当采用SizeTiered策略，磁盘剩余空间不足的时候，会删除大小最大的文件，再进行判断。直到满足剩余空间大小为止。
总的来说，SizeTiered策略比较简单，主要特点就是快。了解了上面这些点，在实际优化，运维中，我想就会得心应手。 【完】
