cassandra压缩策略

Cassandra的存储机制借鉴了Bigtable的设计，采用Memtable和SSTable的方式。和关系数据库一样，Cassandra在写数据之前，也需要先记录日志，称之为commitlog（数据库中的commit log 分为 undo-log, redo-log 以及 undo-redo-log 三类，由于 cassandra采用时间戳识别新老数据而不会覆盖已有的数据，所以无须使用 undo 操作，因此它的 commit log 使用的是 redo log），然后数据才会写入到Column Family对应的Memtable中，且Memtable中的数据是按照key排序好的。Memtable是一种内存结构，满足一定条件后批量刷新（flush）到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。

SSTable是不可修改的，且一般情况下，一个CF可能会对应多个SSTable，这样，当用户检索数据时，如果每个SSTable均扫描一遍，将大大增加工作量。Cassandra为了减少没有必要的SSTable扫描，使用了BloomFilter，即通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。

数据库写入进程将数据存储在名为SSTables的文件中。表是不可变的。数据库不会用插入或更新来覆盖现有行，而是将插入或更新数据的新时间戳版本写入新的SSTables表中。数据库不会通过删除删除的数据来执行删除。相反，数据库用墓碑标记已删除的数据。

随着时间的推移，数据库可能会在不同的表中写入一行的多个版本。每个版本可能有一组唯一的列，这些列存储有不同的时间戳。随着SSTables的累积，数据的分布可能需要访问越来越多的SSTables来检索完整的行。

为了保持数据库健康，数据库会定期合并SSTables并丢弃旧数据。这个过程叫做压实。

为了减少大量SSTable带来的开销，Cassandra会定期进行compaction，简单的说，compaction就是将同一个CF的多个SSTable合并成一个SSTable。在Cassandra中，compaction主要完成的任务是：

（1）垃圾回收： cassandra并不直接删除数据，因此磁盘空间会消耗得越来越多，compaction 会把标记为删除的数据真正删除；
（2）合并SSTable：compaction 将多个 SSTable 合并为一个（合并的文件包括索引文件，数据文件，bloom filter文件），以提高读操作的效率；
（3）生成 MerkleTree：在合并的过程中会生成关于这个 CF 中数据的 MerkleTree，用于与其他存储节点对比以及修复数据。

选择正确的压缩策略将为您的工作负载确保查询和压缩本身的最佳性能。

数据库中使用压缩策略的目的都在于加快查询速率，有以下STCS、LCS、DTCS三种策略：

Size Tiered Compaction Strategy (STCS)

默认的压缩策略。当其他策略不适合工作负载时，可用作后备策略。最适用于具有旋转磁盘的非纯时间序列工作负载，或来自LCS的I/O过高时。

压缩过程
当有（默认4个）SSTable的大小相似的时候，STCS便会启动。压缩过程将这些SSTable合并成一个大的SSTable。当大的SSTable积累了足够数量，同样的过程会再次发生，组合成更大的SSTable。在任何时候，一些不同大小的SSTable的存在都是暂时的。这种策略在写密集的负载中工作良好，当需要读数据的时候，需要尝试读取多个SSTable来找到一行中的所有的数据。策略无法保证同一行的数据被限制在一小部分的sstable中。同时可以预测删除的数据是不均匀的，因为SSTable的大小是触发压缩的条件，并且SSTable可能增长的不够快以便合并旧的数据。当最大的那些SSTable达到一定大小，合并需要的内存也会增长为同时容纳新的SSTable+ 旧的SStable，可能会超出一个典型节点的内存总量。

像我们上面说的一样，Cassandra在内存数据达到一定大小时，会将数据排序写入磁盘生成一个sstable文件块，当第一级的sstable数目达到四个时，由于这四个sstable相当于是按时间划分的一段时间的数据快照，所以这四个块中会有一些相同的数据。我们将这四个sstable会进行合并压缩，就可增减小空间。具体过程如下图所

上图绿色块就表示一个sstable，当第一级的sstable达到四个，就会合并成一个新的第二级的sstable。当然，当第二级的sstable也达到四个，就会再进行合并生成第三级的sstable，以此类推。如果下图所未，当一二三四级sstable都已经有三个，可能这个合并就会一直进行下去。

由于sstable之间可能有重复的数据，也就是同一个数据的不同版本可能存在在多个sstable中，所以上面的方式在更新比较频繁的系统中，可能会有下面一些问题：

• 第一是性能的影响，由于一条记录可能存在在多个sstable中，最BT的情况下可能某一条记录会存在在所有sstable中，所以具体需要合并多个少sstable才能保证一条记录在所有sstable中只存了一次就变得不太确定了。
• 这种方式在存储空间上也比较浪费，因为一个被删除的记录可能的老版本可能会一直存在在一些老的sstable中，直到进行一次完整的合并才行。这对于一个经常会有删除操作的系统来说会造成空间的极大浪费。
• 在不怎么删除的系统上，也会造成一些空间的浪费，最坏的情况下，如果一条记录都没有重复，那么合并操作实际上完全是浪费时间，合并后的数据大小和合并前相比不会变，但是合并操作本身会需要和当前数据集一样大的空间成本。
• 实际使用中如果内存不是很充裕，容易因为SSTable合并过程占用过多内存，导致内存不足，其他节点的Message无法和当前节点交换，最终导致节点宕机。我们可能在cassandra-env.sh中配置了一些参数控制内存的使用，但是并不能限制数据压缩的时候产生的内存损耗。多数建议是关闭自动SSTable压缩，改用手动在空闲期间进行压缩。

Leveled Compaction Strategy (LCS)

新的压缩机制借鉴自LevelDB，这种机制最大的特点在于其同一层的各个sstable之间不会有重复的数据。所以在某一层和它上一层的数据块进行合并时，可以明确的知道某个key值处在哪个数据块中，可以一个数据块一个数据块的合并，合并后生成新块就丢掉老块。不用一直到所有合并完成后才能删除老的块。

另外，新的分层式压缩方式将数据分成条个层，最底层的叫L0，其上分别是L1，L2….，每一层的数据大小是其上的那一层数据最大大小的10倍，其中最底层L0的大小为5M

如下图所未，当浅绿色的L0块生成时，它会马上和L1层的数据进行合并，并生成新的L1块（蓝色块），当L1的块越来越多，大于这一层的最大大小时，这些块又会和L2层的数据进行合并并生新的L2层的块（紫色块）

可以这样理解，层级越小的块，其保存的数据越少，也越新，比如L0层保存的就是最新的数据版本，但是其只会保存5M数据，其上的L1层会保存50M数据，但是并不是最新的。当一个系统运行的时间足够长，那么其数据结构可能会如下图所未：

这种方式的优点是同一层的块之间没有重复数据，带来的好处就是在合并操作的时候，并不需要扫描一层中的所有数据块。合并的开销变小了。具体能够保证以下一些优点：

• 可以保证90%的读操作只需要对一个sstable进行随机读操作。而最坏情况下，也能保证读操作最大只会等于层数，如果10T数据的话，也只有七层，只需要七次随机读操作。
• 在空间利用上，可以保证最多只有10%的空间会浪费在无用数据上。
• 在压缩合并操作的开销上，也最多只会使用10倍于sstable大小的空间。

你可以通过在创建Column Family时指定compaction_strategy参数为LeveledCompactionStrategy来使用新的分层压缩策略。

当然，这种策略也不是万能的，对于一个更新操作和删除操作比较多的系统，使用分层压缩是比较合适的。因为这种系统会产生同一份数据的多个版本。但是由于这种压缩会在压缩中进行更多的IO操作，所以如果是一个主要是insert操作的系统，建议不要使用分层压缩方法。

DateTieredCompactionStrategy (DTCS)

DTCS和STCS很像，但是它不是基于SSTable的大小进行压缩的，DTCS通过判断SSTable的年龄（创建时间）进行压缩。可配置的时间窗口确保新旧数据不会被混淆的合并到同一个SSTable。事实上，使用TTL时间戳，DTCS经常将包含过期数据的整个SSTable逐出。如果时间序列的输出是稳定的，这个策略也会导致许多大小相似的SSTable。通过配置时间周期，SSTable会在一个确切的时间进行合并。如果一些SSTable 正好落在相同的时间区间内，SSTable仍然会合并为更大的table，就像STCS一样。另外，如果SSTable达到了配置的年龄将不会进行压缩，减少数据重复写入的次数。使用这种策略压缩的SSTable可以高效的读取"last hour’s worth of data"，非常快。有个问题就是这种策略导致过期数据不容易写入，比如一条记录要写入过期的时间。读修复容易导致插入过期数据，所以需要关闭读取修复。

Cassandra如何选择压缩策略

SSTable的压缩是Cassandra的重要设计之一，墓碑的删除，数据的合并都依赖压缩才能完成，目前Cassandra有四种压缩策略，其中的一种已经被废弃。

压缩除了解决墓碑等根本问题外，选择不同的压缩策略也影响你的读写性能和集群稳定性。

至于如何选择压缩策略，官方有一系列问句帮你决定:

你存储的是和时间序列有关的数据吗？

如果是的，那么最佳的压缩策略就是TWCS，如果不是请继续后面的问题。

你的表是读多写少，还是写多读少？

如果读是写的两倍以上，特别是随机读的场景，建议用LCS策略，如果读和写差不多，用LCS引起的性能缺失和带来的好处相比，可能并不划算了。注意LCS策略很容易被大量的写击垮的。

你的表里的数据更新频繁吗？

LCS的一个好处就是让有关联的数据集中在一组SSTable文件里。如果你的数据更新不频繁甚至是不更新的，用STCS也可以达到这样的目的，而不会有LCS带来的性能牺牲。

你是否需要可预测的读写？

这一段比较难以理解，博主用白话描述:你是否需要服务级别的读，就是对读的tps和时延是都有要求。如果有的话，即便是你的读写比很小，还是建议用LCS，因为LCS可以控制SSTable的数量和大小，从而保证稳定的读时延，当然写性能就会受到影响，不过这一点你可以通过扩节点的方式解决～

你的表是否有大量的batch提交？

对于批量读和写，STCS的性能要优于LCS。批量提交不会引起太多的碎片文件，所以LCS的好处体现不出来，而且大量的批处理可能会击垮LCS策略的表。

你的磁盘空间是否有限？

在磁盘利用效率方面LCS要比STCS好，它只需要相比存储的数据10%的额外冗余空间，而STCS和DTCS需要50%以上的空间。注意DTCS已经废弃了。

你的系统IO是否到达瓶颈？

LCS比DTCS和STCS产生更多的密集IO操作，切换到LCS带来的额外IO开销可能会抵消它所带来的优势。

通过上述问题，你是否知道自己应该选择什么样的压缩策略了吗？不要盲目做决定，建议你在正式上线前创建三个节点，设置你选择的策略，使用cassandra-stress对你的系统做个压力测试。

参考：
https://zhaoyanblog.com/archives/1011.html
https://blog.csdn.net/weixin_34178244/article/details/92846253
http://blog.chinaunix.net/uid-9162199-id-4260587.html
https://www.cnblogs.com/ligb/p/8504759.html