Cassandra的内部数据存储结构

Cassandra中数据存放规则

1. data：存储真正的数据文件，既后面的SStable文件，可以指定多个目录。
2. commitlog：存储未写入SSTable中的数据（在每次写入之前先放入日志文件）。
3. cache：存储系统中的缓存数据（在服务重启的时候从这个目录中加载缓存数据）。

合理安排上面节点之间的位置以提高性能。

Commitlog

Commilog中包括两个部分： Commilog-XXXX.log和 Commilog-XXXX.log.header。 Commitlog-XXXX.log文件中保存上次更新操作的值， Commitlog-XXXX.log.header记录了那些数据已经从Memtable中写入SSTable中。Cassandra有“周期”和“批量”两种方式记录Commitlog的方式。当一个Commitlog文件的大小超过一定阀值的时候就会新建一个Commitlog。Cassandra每次更新信息将写入Commitlog中，并且每隔一定时间间隔同步文件（还要同步缓存中的数据，使其全部保存在Commitlog中）。

Memtable

数据写入Commitlog中后会缓存在Memtable中（每个Memtable为一个ColumnFamily服务）。在Memtable中容量、条数、时间间隔超过阀值后就会将数据写入磁盘形成一个SSTable文件。Memtable中保存的数据是ConcurrentSkipListMap<DecoratedKey， ColumnFamily>。写入时按照Key的顺序。使用Memtable的优势就是把随机的IO变成了顺序IO（这个好像在很多系统中都会用到）。

SSTable

Cf1的一个SSTable文件由如下文件组成：

1. Cf1-e-1-Data.db
2. Cf1-e-1-Filter.db
3. Cf1-e-1-Index.db
4. Cf1-e-1-Statistics.db

（文件名）-（版本号）-（文件ID）-（四个不同部分）

1. Filter文件的作用是快速定位某一个Key是否在该SSTable文件中（用布尔过滤器来做判断）。
2. Index文件用于索引文件，保存Key和在Data文件中对应的位置。在内存中查找的时候先哈希再二分查找（还有一个cache的优化，这个怎么感觉很像kernel中惯用的手法，哈哈）。
3. Data文件存储数据和与Key对应的一些Column的索引信息（利用索引快速地找到要找的值）。
4. Statistics文件用来存储SSTable中所包含的Column的个数和Row的个数。

系统表空间

这个部分就和很多的关系型数据库的做法很像哈。

在Cassandra中除了用户自己定义的Keyspace之外还有一个特殊的Keyspace：system。

1. 管理Cassandra的系统元数据信息。
2. 缓存HINT数据。

欢迎拍砖。