浅析Cassandra LeveledCompactionStrategy

前言

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

LeveledCompactionStrategy

LeveledCompactionStrategy被用在读密集的场景，读操做的延迟相对容易估算（最坏状况读的文件数量能够肯定），旧数据能够更快被淘汰。缺点是会有更多的磁盘IO消耗，可能会影响到读写操做延迟。

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

增长SSTable：

大于L1的层级，sstable都被合并成大于或等于sstable_size_in_mb（默认：160MB）。超过L0的层级，建立的sstable大小都大体相同。每一个层级之间数据量是10倍的关系，即L2的数据量是L1的10倍。咱们假设L1能够容纳10*160MB，那么L2能够容纳100*160MB。若是在L1作压缩，结果大于10，会被移动到L2.

很是屡次写入后：

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

 

阅读原文

本文为云栖社区原创内容，未经容许不得转载。