在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,有兴趣的可以去看看参考文章4,5和6。
为了避免大量SSTable带来的性能影响,Cassandra也提供一种定期将多个SSTable合并成一个新的SSTable的机制,因为每个 SSTable中的key都是已经排序好的,因此只需要做一次合并排序就可以完成该任务,代价还是可以接受的。所以在Cassandra的数据存储目录 中,可以看到三种类型的文件,格式类似于:
- Column Family Name-序号-Data.db
- Column Family Name-序号-Filter.db
- Column Family Name-序号-index.db
其中Data.db文件是SSTable数据文件,SSTable是Sorted Strings Table的缩写,按照key排序后存储key/value键值字符串。index.db是索引文件,保存的是每个key在数据文件中的偏移位置,而 Filter.db则是Bloom Filter算法生产的映射文件。
参考文章:
[1].http://wiki.apache.org/cassandra/ArchitectureOverview
[2].http://wiki.apache.org/cassandra/MemtableSSTable
[3].http://wiki.apache.org/cassandra/ArchitectureSSTable
[4].http://blog.csdn.net/jiaomeng/archive/2007/01/27/1495500.aspx
[5].http://www.hellodba.net/2009/04/bloom_filter.html
[6].http://www.googlechinablog.com/2007/07/bloom-filter.html
[7].http://labs.google.com/papers/bigtable.html