前言

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