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。
为了减少大量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三种策略：
默认的压缩机制：SizeTieredCompactionStrategy
在讲分层压缩之前，我们先来看一下Cassandra目前的数据存储模型和数据压缩机制。
像我们上面说的一样，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压缩，改用手动在空闲期间进行压缩。
新的压缩机制：LeveledCompactionStrategy
新的压缩机制借鉴自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和STCS很像，但是它不是基于SSTable的大小进行压缩的，DTCS通过判断SSTable的年龄（创建时间）进行压缩。可配置的时间窗口确保新旧数据不会被混淆的合并到同一个SSTable。事实上，使用TTL时间戳，DTCS经常将包含过期数据的整个SSTable逐出。如果时间序列的输出是稳定的，这个策略也会导致许多大小相似的SSTable。通过配置时间周期，SSTable会在一个确切的时间进行合并。如果一些SSTable 正好落在相同的时间区间内，SSTable仍然会合并为更大的table，就像STCS一样。另外，如果SSTable达到了配置的年龄将不会进行压缩，减少数据重复写入的次数。使用这种策略压缩的SSTable可以高效的读取"last hour's worth of data"，非常快。有个问题就是这种策略导致过期数据不容易写入，比如一条记录要写入过期的时间。读修复容易导致插入过期数据，所以需要关闭读取修复。
For more information about compaction strategies, see When to Use Leveled Compaction and Leveled Compaction in Apache Cassandra. For DateTieredCompactionStrategy, see Date-Tiered Compaction in Cassandra or DateTieredCompactionStrategy: Compaction for Time Series Data.
参考：
http://zhaoyanblog.com/archives/1011.html
https://www.cnblogs.com/didda/p/4728588.html
http://blog.chinaunix.net/uid-9162199-id-4260587.html
https://labs.spotify.com/2014/12/18/date-tiered-compaction/