五、网络嗅探
网络嗅探主要用来计算不同host的相对距离,进而告诉Cassandra网络拓扑结构,以便更高效地对用户请求进行路由。主要有三种配置策略:
1) org.apache.cassandra.locator.SimpleSnitch:
将不同host逻辑上的距离(Cassandra Ring)作为他们之间的相对距离。
2) org.apache.cassandra.locator.RackInferringSnitch:
相对距离是由rack和data center决定的,分别对应ip的第3和第2个八位组。即,如果两个节点的ip的前3个八位组相同,则认为它们在同一个rack(同一个rack中不同节点,距离相同);如果两个节点的ip的前两个八位组相同,则认为它们在同一个数据中心(同一个data center中不同节点,距离相同)。
3) org.apache.cassandra.locator.PropertyFileSnitch:
相对距离是由rack和data center决定的,且它们是在配置文件cassandra-topology.properties中设置的。
六、一致性
在一致性上,Cassandra采用了最终一致性,可以根据具体情况来选择一个最佳的折衷,来满足特定操作的需求。Cassandra可以让用户指定读/插入/删除操作的一致性级别,一致性级别有多种,如图5所示。
图5 Cassandra一致性级别
注:一致性级别是由副本数决定,而不是集群的节点数目决定。
Quorum NRW
-
N: 复制的节点数量,即副本数
-
R: 成功读操作的最小节点数
-
W: 成功写操作的最小节点数
Quorum协议中,R 代表一次成功的读取操作中最小参与节点数量,W 代表一次成功的写操作中最小参与节点数量。R + W>N ,则会产生类似quorum 的效果。该模型中的读(写)延迟由最慢的 R(W)复制决定,为得到比较小的延迟,R和W有的时候的和比N小。
Quorum协议中,只需W + R > N,就可以保证强一致性。因为读取数据的节点和被同步写入的节点是有重叠的。在一个RDBMS的复制模型中(Master/salve),假如N=2,那么W=2,R=1此时是一种强一致性,但是这样造成的问题就是可用性的减低,因为要想写操作成功,必须要等 2个节点的写操作都完成以后才可以。
在分布式系统中,一般都要有容错性,因此N一般大于3的,此时根据CAP理论,我们就需要在一致性和分区容错性之间做一平衡,如果要高的一致性,那么就配置N=W,R=1,这个时候可用性就会大大降低。如果想要高的可用性,那么此时就需要放松一致性的要求,此时可以配置W=1,这样使得写操作延迟最低,同时通过异步的机制更新剩余的N-W个节点。
当存储系统保证最终一致性时,存储系统的配置一般是W+R<=N,此时读取和写入操作是不重叠的,不一致性的窗口就依赖于存储系统的异步实现方式,不一致性的窗口大小也就等于从更新开始到所有的节点都异步更新完成之间的时间。
一般来说,Quorum中比较典型的NRW为(3,2,2)。
维护最终一致性
Cassandra 通过4个技术来维护数据的最终一致性,分别为逆熵(Anti-Entropy),读修复(Read Repair),提示移交(Hinted Handoff)和分布式删除。
1) 逆熵
这是一种备份之间的同步机制。节点之间定期互相检查数据对象的一致性,这里采用的检查不一致的方法是 Merkle Tree;
2) 读修复
客户端读取某个对象的时候,触发对该对象的一致性检查:
读取Key A的数据时,系统会读取Key A的所有数据副本,如果发现有不一致,则进行一致性修复。
如果读一致性要求为ONE,会立即返回离客户端最近的一份数据副本。然后会在后台执行Read Repair。这意味着第一次读取到的数据可能不是最新的数据;如果读一致性要求为QUORUM,则会在读取超过半数的一致性的副本后返回一份副本给客户端,剩余节点的一致性检查和修复则在后台执行;如果读一致性要求高(ALL),则只有Read Repair完成后才能返回一致性的一份数据副本给客户端。可见,该机制有利于减少最终一致的时间窗口。
3) 提示移交
对写操作,如果其中一个目标节点不在线,先将该对象中继到另一个节点上,中继节点等目标节点上线再把对象给它:
Key A按照规则首要写入节点为N1,然后复制到N2。假如N1宕机,如果写入N2能满足ConsistencyLevel要求,则Key A对应的RowMutation将封装一个带hint信息的头部(包含了目标为N1的信息),然后随机写入一个节点N3,此副本不可读。同时正常复制一份数据到N2,此副本可以提供读。如果写N2不满足写一致性要求,则写会失败。 等到N1恢复后,原本应该写入N1的带hint头的信息将重新写回N1。
4) 分布式删除
单机删除非常简单,只需要把数据直接从磁盘上去掉即可,而对于分布式,则不同,分布式删除的难点在于:如果某对象的一个备份节点 A 当前不在线,而其他备份节点删除了该对象,那么等 A 再次上线时,它并不知道该数据已被删除,所以会尝试恢复其他备份节点上的这个对象,这使得删除操作无效。Cassandra 的解决方案是:本地并不立即删除一个数据对象,而是给该对象标记一个hint,定期对标记了hint的对象进行垃圾回收。在垃圾回收之前,hint一直存在,这使得其他节点可以有机会由其他几个一致性保证机制得到这个hint。Cassandra 通过将删除操作转化为一个插入操作,巧妙地解决了这个问题。
七、存储机制
Cassandra的存储机制借鉴了Bigtable的设计,采用Memtable和SSTable的方式。
CommitLog
和HBase一样,Cassandra在写数据之前,也需要先记录日志,称之为Commit Log,然后数据才会写入到Column Family对应的MemTable中,且MemTable中的数据是按照key排序好的。SSTable一旦完成写入,就不可变更,只能读取。下一次Memtable需要刷新到一个新的SSTable文件中。所以对于Cassandra来说,可以认为只有顺序写,没有随机写操作。
MenTable
MemTable是一种内存结构,当数据量达到块大小时,将批量flush到磁盘上,存储为SSTable。这种机制,相当于缓存写回机制(Write-back Cache),优势在于将随机IO写变成顺序IO写,降低大量的写操作对于存储系统的压力。所以我们可以认为Cassandra中只有顺序写操作,没有随机写操作。
SSTable
SSTable是Read Only的,且一般情况下,一个CF会对应多个SSTable,当用户检索数据时,Cassandra使用了Bloom Filter,即通过多个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,用于与其他存储节点对比以及修复数据。
详细存储数据结构参考 http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandraxu2
附
单体、模块化
Cassandra和HBase的一个重要区别是, Cassandra在每个节点是是一个单 Java 进程,而完整的HBase 解决方案却由不同部分组成:有数据库进程本身,它可能会运行在多个模式;一个配置好的 hadoop HDFS 分布式文件系统,以及一个 Zookeeper 系统来协调不同的 HBase 进程。
相关推荐
关于Cassandra数据模型的简单介绍
Cassandra个人学习笔记总结,引用请注明出处。
Cassandra 入门学习 Clauster 实例 Cassandra Log4j 下应用
nosql数据库cassandra入门的一个例子。包括简单的插入、查询、建立keyspace等
Cassandra分布式模型与源代码分析 分析了Cassandra的分布式模型
在eclipse中通过基于spring data的easyrest风格的maven项目操纵cassandra和lucened的源代码
Cassandra对象数据模型的安装包中文安装说明 以及使用例子一步到位哦
解Cassandra数据模型
Cassandra从搭建到数据插入存储 环境在XP下
cassandra的入门教程,
cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战cassandra 实战...
以Amazon专有的完全分布式的Dynamo为基础,结合了Google BigTable基于列族(Column Family)的数据模型。P2P去中心化的存储。很多方面都可以称之为Dynamo 2.0。 功能 Cassandra的主要特点就是它不是一个数据库,...
CASSANDRA分布式模型与源代码分析文茂V0.7 - CASSANDRA-SHAWN.doc
它最初由Facebook开发,用于储存收件箱等简单格式数据,集GoogleBigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身Facebook于2008将 Cassandra 开源,此后,由于Cassandra良好的可扩展性,被Digg、Twitter...
本文面描述了Cassandra基本命令cqlsh和CQL的数据模型,是学习Cassandra的入门教材