Cassandra Commitlog

大致介绍了一下Cassandra的存储机制，通过将最新的写操作放在内存中的Memtable，然后定期刷新到磁盘持久化为 SSTable，Cassandra将随机写操作转换成了顺序写操作，这可以提升IO性能。

最新写入的脏数据是在内存Memtable表中，因此必须有机制来确保异常情况下，能够将内存中的数据恢复出来。和关系型数据库系统一 样，Cassandra也是采用的先写日志再写数据的方式，其日志称之为Commitlog。

和Memtable/SSTable不一样的是，Commitlog是server级别的，不是Column Family级别的 。 每个Commitlog文件的大小是固定的，称之为一个Commitlog Segment，目前版本(0.5.1)中，这个大小是128MB，这是硬编码在代码(src/Java/org/apache/cassandra /db/Commitlog.java)中的。当一个Commitlog文件写满以后，会新建一个的文件。当旧的Commitlog文件不再需要时，会自 动清除。

每个Commitlog文件(Segment)都有一个固定大小（大小根据Column Family的数目而定）的CommitlogHeader 结 构，其中有两个重要的数组，每一个Column Family在这两个数组中都存在一个对应的元素。其中一个是位图数组(BitSet dirty )，如果Column Family对应的Memtable中有脏数据，则置为1，否则为0，这在恢复的时候可以指出哪些Column Family是需要利用Commitlog进行恢复的。另外一个是整数数组(int[] lastFlushedAt )， 保存的是Column Family在上一次Flush时日志的偏移位置，恢复时则可以从这个位置读取Commitlog记录。通过这两个数组结构，Cassandra可以在异 常重启服务的时候根据持久化的SSTable和Commitlog重构内存中Memtable的内容，也就是类似Oracle等关系型数据库的实例恢复。

当Memtable flush到磁盘的SStable时，会将所有Commitlog文件的dirty数组对应的位清零，而在Commitlog达到大小限制创建新的文件 时，dirty数组会从上一个文件中继承过来。如果一个Commitlog文件的dirty数组全部被清零，则表示这个Commitlog在恢复的时候不 再需要，可以被清除。因此，在恢复的时候，所有的磁盘上存在的Commitlog文件都是需要的。

参考文章：

[1].http://wiki.apache.org/cassandra/ArchitectureCommitLog

概述

Cassandra写入数据流程是先将数据写入Commitlog中，然后写入内存Memtable中，当满足一定条件将内存中的数据刷入磁盘SSTable。

Cassandra需要两个目录来分别保存Commitlog和SSTable生成的文件，目录位置可以通过配置项修改：

[html] view plain copy

 print?

1. data_file_directories:- /var/lib/cassandra/data  
2. commitlog_directory: /var/lib/cassandra/commitlog  

Commitlog

由两个部分组成，如下：

[html] view plain copy

 print?

1. CommitLog-1396061983699.log  
2. CommitLog-1396061983699.log.header  

log文件中保存了每次更新操作，header文件记录了哪些数据已经从Memtable中写入SSTable中，head文件可以删除垃圾日志，节省空间。

SSTable

Memtable中记录一个列族的更新记录，当数据达到配置的容量上限，或者条数限制等条件时，会被写入SSTable中。SSTable会为每个keyspace建一个目录，默认会有一个system目录，供系统使用。

目录中每一次写入会生成3个文件

[html] view plain copy

 print?

1. User-e-1-Data.db  
2. User-e-1-Filter.db  
3. User-e-1-Index.db  

其中,User表示ColumnFamily， e为版本标识，1代表这是User的第一个文件，每次刷入会增长。

Filter文件

filter文件中存放着一个布隆过滤器，可以快递判断一个key是否在data文件中。布隆过滤器是一种不确定性算法：如果通过布隆过滤器判断出这个key不在SSTable中，就一定不在；如果判断出在SSTable中，不一定在。通过布隆过滤器可以减少访问index文件的次数。

Index文件

Index文件保存data文件中每个key对应的位置：

 

index文件中的key是有序的，防止index文件非常大，查找一个key花费较大开销，cassandra做了一个内存缓存，记录部分key在index文件中的位置：

这个间距是可以调节的，要判断一个key在data中的位置先查询内存缓存，得到这个key在index文件中的位置，然后再定位到data文件位置。

Data文件

data文件中存储的是真正的数据，其格式如下：

data文件不仅存储了key对应的值，还对每个key保存了一份索引columnIdx。columnIdx也包含布隆过滤器和索引两部分。cassandra中的行有宽行和窄行之分，宽行可能有上万个column，要更新某一个column时也是比较麻烦的，所以在这里做了一个索引。