浅析Cassandra LeveledCompactionStrategy-阿里云开发者社区

开发者社区> 中国Cassandra技术社区> 正文

浅析Cassandra LeveledCompactionStrategy

简介: 前言 Cassandra是基于LSM架构的分布式数据库。LSM中有一个很重要的过程,就是压缩(Compaction)。默认的压缩策略是SizeTieredCompactionStrategy,今天主要说一下另一种压缩策略LeveledCompactionStrategy。

前言

Cassandra是基于LSM架构的分布式数据库。LSM中有一个很重要的过程,就是压缩(Compaction)。默认的压缩策略是SizeTieredCompactionStrategy,今天主要说一下另一种压缩策略LeveledCompactionStrategy。

LeveledCompactionStrategy

LeveledCompactionStrategy被用在读密集的场景,读操作的延迟相对容易估算(最坏情况读的文件数量可以确定),旧数据可以更快被淘汰。缺点是会有更多的磁盘IO消耗,可能会影响到读写操作延迟。

这个压缩算法主要是将数据分级(L0,L1,L2……)。最开始数据在内存(memtable)里,然后被flush到磁盘上,也就是到了L0这级。L0的sstable会和L1的合并成更大的sstable。

增加SSTable:
image

大于L1的层级,sstable都被合并成大于或等于sstable_size_in_mb(默认:160MB)。超过L0的层级,创建的sstable大小都大致相同。每个层级之间数据量是10倍的关系,即L2的数据量是L1的10倍。我们假设L1可以容纳10*160MB,那么L2可以容纳100*160MB。如果在L1做压缩,结果大于10,会被移动到L2.

非常多次写入后:
image

LCS compaction会保证从L1开始没有重复数据。所以对于读操作来说,只要检索1个或者2个sstable就能查到数据(L0 + LN)。事实上,90%的读操作都只需要读取1个sstable。由于L0是不压缩的,如果大量读请求集中在L0,任然可能导致大量读IO消耗。

LCS compaction发生的会更频繁,会消耗更多IO。如果是写密集型的,并不适合,因为IO开销可能大于读的收益。

更多压缩策略选择可以参考:https://docs.datastax.com/en/dse/6.7/dse-dev/datastax_enterprise/config/configChooseCompactStrategy.html

写在最后

为了营造一个开放的Cassandra技术交流环境,社区建立了微信公众号和钉钉群。为广大用户提供专业的技术分享及问答,定期开展专家技术直播,欢迎大家加入。另云Cassandra免费火爆公测中,欢迎试用:https://www.aliyun.com/product/cds

image

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
中国Cassandra技术社区
使用钉钉扫一扫加入圈子
+ 订阅

Cassandra已有10年+的沉淀,基于Amazon DynamoDB的分布式设计和 Google Bigtable 的数据模型。具备诸多优异特性:采用分布式架构、无中心、支持多活、弹性可扩展、高可用、容错、一致性可调、提供类SQL查询语言CQL等。Cassandra为互联网业务而生,已在全球广大互联网公司有成熟应用,是目前最流行的宽表数据库。阿里云在2019年8月份全球首发云Cassandra服务。

官方博客
相关链接