在2009年兴起的NoSQL运动中，Cassandra是其中重要的一个分布式key-value数据库产品，由Facebook在2008年开源，目前是Apache的顶级项目。最近twitter的一篇声明，表示将从MySQL迁移到Cassandra，更让其声名大振。Cassandra是结合了Google Bigtable的数据模型和Amazon Dynamo高可用框架的一个产品。其数据模型可以参考张瑞的blog。

    值得说一下的是Cassandra的存储机制，也是借鉴了Bigtable的设计，采用Memtable和SSTable的方式。和关系数据库一样，Cassandra在写数据之前，也需要先记录日志，称之为commitlog，然后数据才会写入到Column Family对应的Memtable中，并且Memtable中的内容是按照key排序好的。Memtable是一种内存结构，满足一定条件后批量刷新到磁盘上，存储为SSTable。这种机制，相当于缓存写回机制(Write-back Cache)，优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。SSTable一旦完成写入，就不可变更，只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说，可以认为只有顺序写，没有随机写操作。

    因为SSTable数据不可更新，可能导致同一个Column Family的数据存储在多个SSTable中，这时查询数据时，需要去合并读取Column Family所有的SSTable和Memtable，这样到一个Column Family的数量很大的时候，可能导致查询效率严重下降。因此需要有一种机制能快速定位查询的Key落在哪些SSTable中，而不需要去读取合并所有的SSTable。Cassandra采用的是Bloom Filter算法，通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。关于Bloom Filter，有兴趣的可以去看看参考文章3和4。

    为了避免大量SSTable带来的性能影响，Cassandra也提供一种定期将多个SSTable合并成一个新的SSTable的机制，因为每个SSTable中的key都是已经排序好的，因此只需要做一次合并排序就可以完成该任务，代价还是可以接受的。所以在Cassandra的数据存储目录中，可以看到三种类型的文件，格式类似于：

Column Family Name-序号-Data.dbColumn Family Name-序号-Filter.dbColumn Family Name-序号-index.db

    参考文章：

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

    [2].http://wiki.apache.org/cassandra/ArchitectureSSTable

    [3].http://blog.csdn.net/jiaomeng/archive/2007/01/27/1495500.aspx

    [4].http://www.hellodba.net/2009/04/bloom_filter.html

    [5].http://labs.google.com/papers/bigtable.html

建议继续学习：

1. HFile存储格式    (阅读：14414)
2. 淘宝图片存储架构    (阅读：9646)
3. 我对技术方向的一些反思    (阅读：9687)
4. 海量小文件存储    (阅读：7383)
5. HBase技术介绍    (阅读：6580)
6. 存储基础知识之——硬盘接口简述    (阅读：5921)
7. 在perl中连接和使用sqlite做数据存储    (阅读：4919)
8. 如果用户在5分钟内重复上线，就给他发警告，问如何设计？    (阅读：4814)
9. Redis新的存储模式diskstore    (阅读：4352)
10. HTML5本地存储初探(二)    (阅读：4334)