我们已经开始在OneSpot使用Cassandra来作为我们下一代的存储引擎(使用一个EC2的机器集群代替一台非常大的PostgreSQL机器),因此,之前几周的时间我一直在使用Cassandra. 由于我本人是一个基础设施方面的书***,并且坚信需要理解系统堆栈的各个层面,因为我阅读了部分关于Cassandra如何工作的资料,并且想写出点总结以期对后来者有所帮助.由于Cassandra的写性能表现卓越这一点众所周知,我认为我的介绍应该由此开始.
需要理解的***件事是,Cassandra***运行在多台机器上.据我所知,Twitter使用了一个45台机器组成的集群.在一台机器上运行Cassandra可能不是很有意义,因为你将失去没有单点故障的系统的优势.
客户端向一个随机的Cassandra节点发出一个写请求.这个节点作为代理往集群写入数据.节点的集群存储在一个节点”环”上,写会按照复制放置策略(replication placement strategy)复制到N个节点上.当使用RackAwareStrategy策略时,为了保证可靠性(reliability)与可用性(Availability), Cassandra会按照复制节点到当前节点的距离将复制节点分为3个桶:与当前节点位于同一机架、与当前节点位于同一数据中心、或位于不同的数据中心.你配置了Cassandra写数据到N个节点来做冗余,Cassandra会将***份拷贝写入到此数据的主节点,第二份拷贝到环上的位于另一个数据中心的节点,剩余的其它拷贝到与代理节点位于同一个数据中心的机器上.这样就可以确保单点故障不会导致整个集群不可用,即使在整个数据中心都不可用时集群仍然保持可用.
因此,写请求从你的客户端出发到单一随机节点,此节点根据复制放置策略将写操作发送到N个不同的节点.我没有在此讨论很多边缘用例极端情况(节点宕机、集群中新增节点、等等),但是,节点需要等待N个节点返回成功并返回成功给客户端.(此处的描述有问题,Cassandra中,还有另外一个W的参数,也就是需要等待几份写拷贝成功才返回成功给客户端,译者加).
节点中的每一个都会以”RowMutation”消息的形式接收到此写请求.对于此消息,节点会采取以下两种行动:
◆追加此变更到提交日志(Commit log)以满足事务性目的
◆使用此变更修改一个内存内的Memtable 结构
它的工作就此结束.这就是为什么Cassandra的写操作如此快的原因:最慢的部分就是追加变更日志到文件的操作.与关系型数据库不同的是,Cassandra不会修改存储在磁盘上的数据,也不会去更新索引,因此没有密集的同步磁盘操作来阻塞这次写操作.
还有多个定期发生的异步操作:
◆当Memtable结构数据满的时候需要写入到SSTable,一个基于磁盘的结构,因此我们不会有太多只存在于内存的数据.
◆每个给定列族(ColumnFamily)的一组临时的SSTable会被合并到一个大的SSTable.此时,临时的SSTable就没有用了,它们会在将来的某个时间点被当作垃圾回收掉.
还有大量的边缘用例极端情况与复杂情况,我都没有在此讨论,我强烈建议大家至少要去阅读下Cassandra维基(Wiki)中关于ArchitectureInternals与Operations的相关描述.分布式系统相当复杂,Cassandra也不例外.
如果有发现错误或想要添加更多细节请留下意见,我不是Cassandra的开发者,因此我确定一定有1-2处的错误隐藏其中.
- 详解NoSQL数据库Apache Cassandra的配置
- 漫谈Cassandra客户端的使用
- 详解Cassandra数据模型
- 超越关系型数据库 pureXML技术应用及展望
- 新兴数据库打破整个旧规则
- 探寻关系数据库和ORM的***替代者
