Cassandra SizeTieredCompaction策略解析

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。这样做的好处有:

  1. 加速Compaction操作,减少文件数量
  2. 降低Compaction带宽,从而可以降低对读性能的影响
  3. 更加适宜更新频繁的应用场景

真心不会写源码阅读类的博客,我还是罗列一些比较重要的点吧,我尽量提到代码中的类名,方法名可以对照分析:

  1. 两个比较重要的参数:MinimumCompactionThreshold, MaximumCompactionThreshold。当每一个tier的文件数量,大于前者的时候,可以参与到Compaction中,但是参与Compaction的文件数量,不会超过后者。前者默认是4,后者默认是32.
  2. 划分tier的依据是sstable文件的大小,具体在函数getBuckets中,比如有一个1G的sstable,大于0.5G的和小于1.5G的,都可以划到一个tier中。而leveled是将level写在json文件中的
  3. 每次Compaction都是写入时间比较久的sstable优先参与合并的
  4. 一个问题,如果要合并的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账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号