Cassandra Compaction的改进
有关Cassandra Compaction，我写了好多的博客。这是为什么呢？原因很简单，因为Compaction在实际应用中，影响巨大。而且似乎探讨这方面的文章还比较少。 这篇文章不是翻译的，而是要写我自己的经验，我悲催的发现，凡是写自己总结的经验，文章就会很短。我本来打算Leveled Compaction和SizeTiered Compaction的改进分开些，可是自己掂量了一下，都很少，几句话、甚至一句话就搞定了。所以我不得以把原本两篇文章合到一起写。尽管也不错，但是绝对是我的实践经验，希望对大家有帮助。 SizeTiered Compaction改进 SizeTierd Compaction适用于写多读少的场景。其实这不完全准确，因为，如果没有更新、删除，SizeTiered策略也不会降低读的性能。SizeTiered Compaction还有一个特性，就是Compaction速度快，只要空间足够，小的sstable文件会迅速合并到大的sstable文件中。那如果空间不足，会出现什么样的情况——最直接的，越来越多大的sstable文件不能够参与Compation，那重复数据过期数据就会越来越多。对于HDD来说，这就太恐怖了。空间总会紧张，无限的增加空间是不现实的。那么如何充分利用磁盘空间呢？我的想法是将足够大的以至于不能呢狗狗参与到Compaction的sstable文件，分割为小文件，再次进入Compacition循环。不断的减少重复数据和过期数据。 这个方法，我并没有实现。一个主要的原因是，目前的SizeTiered策略应对单机1T的数据量已经差不多了，再多就略显吃力。而且，写多读少的场景也比较特殊。因为这个时候，我们就不应该用Cassandra这个通用的分布式存储架构了。不过，如果单机数据量增加，仍旧使用SizeTiered策略，我想上面的策略也不失为一个可行的方案。 Leveled Compaction改进Leveled Compaction适合读多写少的场景，具体而言也是更新较少的时候。其实，这些读多写少，写多读少。都是相对概念，需要在实际应用中不断揣摩，方能有所体会。Leveled Compaction会优先Compaction比较高的Level，尽量减小Compaciton的IO操作。不过正式如此，不利于写（大家姑且认为，默认就包含了更新操作吧）多的情况，因为此时，L0积压了大量的sstable文件，在进行读取的时候，需要seek磁盘的数据急剧增加，使得整体性能严重下降。 理解了问题，那么如何改进呢？很自然的思路：减少L0的sstable数量。那剩下的问题就是如何减少L0的文件数量。L0的文件多是因为，总是优先Compaction高Level的文件。那么既想优先Compaction高Level的sstable文件，又想减少L0的文件数量。所以，每次Compaction任务，总是包含了两部分：
- 高Level（>1）的Compaction
- L0的Compaction
L0的Compaction做什么呢？是Compaction到L1么？不是，因为那样并没有减少文件的水量。根本原因大家都知道，在Levled Compaciton下，sstable文件的打下都是一致的。所以，L0只能是小文件合成大文件。大家可能觉得减少的数量有限，但就这个有限的数量，在写多的情况下，带来了17%的读性能提升。这个我们是实现了，并且进行了测试的。 果然很短，要不是我罗嗦的多了一些，其实两句话就解决了。不过不交代下前因后果，还是有些不放心。上次博客更新预告，已经完成了两篇了（本来打算三篇的-_-），继续加油！ 【完】
