关于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

  1. jason说道:

    博主,拉一个 Cassandra 的群吧?可以参考 壹佰教程网站的玩法。想看看国内有哪些公司在用Cassandra ,还有kairosdb ==!

留言

提示:你的email不会被公布,欢迎留言^_^

*

验证码 *