国内研究使用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策略比较简单,主要特点就是快。了解了上面这些点,在实际优化,运维中,我想就会得心应手。 【完】
转载于:https://www.cnblogs.com/sing1ee/archive/2012/06/26/2765047.html
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/110378.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...