【IT168 专稿】Apache Cassandra是一款免费的开源NoSQL数据库，其设计目的在于管理由大量商用服务器构建起来的庞大集群上的海量数据集(数据量通常达到PB级别)。在众多显著特性当中，Cassandra最为卓越的长处是对写入及读取操作进行规模调整，而且其不强调主集群的设计思路能够以相对直观的方式简化各集群的创建与扩展流程。对于希望寻求一套足以支持快速且规模化增长的数据存储方案的企业用户来说，Cassandra绝对是备选名单中的优先选项之一。

　　Cassandra拥有相当骄人的优秀血统。它在数据架构的继承方面不仅受到谷歌Bigtable的巨大影响，同时也从Amazon Dynamo身上汲取到了分布式机制的精髓。与Dynamo类似，Cassandra当中的集群节点完全对称，各自承担相同的处理职责。Cassandra还借用Dynamo风格的统一散列法对数据进行划分与复制。(Dynamo是Amazon推出的一套高可用性键-值存储系统，并以此为基础建立起DynamoDB数据库。)

　　Cassandra如何运作

　　Cassandra、拥有令人印象深刻的缓存机制与经过精心打造的磁盘I/O分层结构，旨在确保数据的读写速度与内容安全。其存储架构与日志结构合并树颇为相似：写入操作首先被发送到一份持久性提交日志当中(确保写入内容持久性)，而后被回写至“memtable”的缓存当中。当指向memtable的写入过程结束后，对应数据会被发往磁盘上的SSTable当中(即排序字符串表)。所有磁盘写入都属于追加操作——即大型连续写入而非随机写入——因此执行效率很高。每隔一段时间，系统都会对SSTable文件进行合并与压缩。

　　Cassandra的集群采取环状组织方式，并利用分区策略保证数据均匀分布到每个节点之上。目前较好的分区工具要数RandomPartitioner，它能够生成一组128位一致性散列以实现数据位置确定。这款分区工具还需要另一款名为“snitch”组件的辅助，后者负责将节点的IP地址与其在机架或者数据中心内的物理位置加以映射。

　　当Cassandra进行数据写入时，对应数据会被同时写入至多个节点之上、从而保证节点出现故障时这部分数据仍然处于可用状态。这些写入了特定数据元素的节点被称为“副本节点”。Cassandra利用snitch来确保这些承载着任意信息组成部分的副本节点分别处于不同机架当中。否则一旦某台机架发生故障，相应数据元素及其全部复制副本都会丢失。

　　为了在节点发生故障时保证写入能力持续有效，Cassandra采用了“hinted handoffs”机制。简单来说，某个节点在接收到写入请求时、会首先尝试将该请求提交给负责对应数据的副本节点进行处理。如果因为故障而无法正确写入，对应的副本节点(官方给出的名称为‘协调节点’)将把该请求保存为一条“hint”——用于在无法正常运作的副本节点得到修复后再次对其执行写入操作。如果该协调节点事先已经发现副本节点存在问题，则会直接保存hint信息而不再作出无谓的尝试。　　如果集群中的一个或者多个节点利用率过高，Cassandra会利用“虚拟节点”或者叫作“vnodes”功能对负载进行重新分配。在一套完全逻辑化的结构当中，每个虚拟节点在本质上都是一个容器、用于容纳一系列数据库行。由于每个物理节点都会被分配至多个虚拟节点当中，Cassandra能够借此通过将某个虚拟节点从一个负载过高的集群成员迁移至其它负载较低的集群中去、从而轻松实现负载平衡调整。

　　Hinted handoffs属于Cassandra一致性修复功能集中的组成部分。除此之外，另一项名为“read repair”的功能则在读取请求的处理流程中发挥重要作用。根据所选取的一致性级别的不同(我们将在下文中详细阐述)，Cassandra会通过只从单一副本节点中读取信息来满足该读取请求。即便如此，Cassandra仍然要在后台向全部副本节点进行读取，从而验证全部数据副本是否都已经得到正确更新并保持内容一致。

　　一致性与速度间的取舍

　　RDBMS(即关系型数据库管理系统)的突出优点之一在于始终坚持 ACID四大原则——即原子性、一致性、隔离性与持久性——从而保证各类多客户环设置下的操作确定性;这同样有助于确保系统故障状况下的数据安全。Cassandra这类非关系型数据库会从根本层面上回避ACID原则，这主要是为了避免这几类原则在数据库数据量及I/O请求规模不断拓展时所引发的性能局限。

　　Cassandra号称拥有“最终一致性。”当数据被写入到Cassandra当中时，这部分数据并不一定需要被同时写入至各个副本节点。正如我们之前所提到，某些集群成员可能暂时处于不可用状态。不过hinted handoffs的存在能够确保所有节点最终都能具备同样的内容，并由此实现系统一致性。与此同理，read repair机制可以在数据向其它方向传输时——例如由Cassandra移动至外部环境——追踪内容变更并保持其一致性。

　　集群的不同节点中可能存在与特定节点有所不同的数据元素，这种状况很可能引起大家的担忧。好消息是，我们可以对Cassandra的一致性级别加以调整。举例来说，大家可以控制写入操作所遵循的一致性级别——包括向多少个副本节点写入对应数据——然后再向客户应用程序进入实际写入。

　　同理可知，我们也能在读取操作中控制相关副本节点的数量、而后再将响应结果返回到客户端。其一致性级别的调整范围可以设定为“Any”，也就是说在任意节点返回响应结果后认定为请求完成。在“Any”与“All”之间大家还可以选择其它一致性级别，例如“Quorum”，即当多数副本节点作出响应时视为请求完成。Cassandra提供的可调整一致性机制堪称一项强大的功能，足以帮助我们在速度与一致性之间作出均衡选择。希望拥有出色的速度表现?请选择“Any”。想要将一致性级别提升至最高点?请选择“All”。

　　由于Cassandra是一套分布式方案，因此单一集群成员需要相应机制来识别彼此并进行状态信息沟通。为了实现这一目的，Cassandra的Gossip协议应运而生。与大家猜想的一样，Gossip(即‘绯闻’)这一名称源自人与人之间通过谈话传递一组人类活动信息的随机行为。

　　集群中的特定节点被设计为“seed”节点。作为Cassandra节点活动的基本计时单位，其每一秒都会随机与集群内的选定节点进行通信——而所涉及的节点中至少有一个需要是seed节点。有鉴于此，seed节点往往拥有最为实时化的集群内容视角。(当新节点被添加到集群中时，它也需要首先与seed节点进行接触。)

　　Cassandra致力于提高Gossip协议的通信效率。每一个节点都保有两种状态类别。其中HeartBeatState用于追踪节点的版本号——版本号会在节点信息发生变更时实施递增——以及节点的重启频率。而ApplicationState负责追踪节点的操作性状态(例如当前负载)。不同节点彼此之间会交换HeartBeatState信息，如果存在差异、这些节点会交换ApplicationState信息并最终交换ApplicationState数据本身。除此之外，Gossip算法还会首先寻求“远端”差异的解决办法(这里的‘远端’是指版本号差异较大的两个节点)，这是因为一般说来版本差异越大、节点内容的一致性冲突就越严重。

　　如何使用Cassandra

　　熟悉SQL的RDBMS用户应该不会对CQL——也就是Cassandra查询语言——感到陌生，这种语言能够通过基于Python的Cassandra shell程序(即cqlsh)或者其它几种客户端驱动加以运行。大家可以通过Planet Cassandra等网站下载客户端驱动，在这里我们可以找到适用于Java、C#、Node.js、PHP以及其它语言的CQL驱动程序。

　　过去，驱动程序与Cassandra集群需要依靠Thrift API实现通信——Thrift是一款用于创建面向客户端及服务器的远程程序调用数量的框架，而且与语言类型无关。Cassandra的Thrift API如今已经成为一项遗留功能，这是因为CQL规范怕定义的已经不仅仅是CQL语言、也包括一套在线通信协议。

　　CQL的语法与其关系型表亲颇为相似。它同样拥有SELECT、INSERT、UPDATE以及DELETE语句，而且这些语句都会与FROM及WHERE等子句配合使用。大家可以使用整数、浮点数、双精度以及二进制等数据类型。当然，二者之间也存在差别。其一，CQL已经取消了JOIN操作。而且在我们写入FROM子句时可以指定column family(列族)——强调一句，在CQL最新版本当中用“table”取代了原本的“column family”。CQL还允许我们为任意操作指定需要的一致性级别，不过其真正优势在于、这是一款能够为关系型程序员快速掌握的数据管理语言，而且独立于特定编程API之外。

　　Cassandra的安装流程非常简单，特别是在大家下载了DataStax Community版本的情况下——该版本绑定了一款名为OpsCenter的Web管理应用。我在自己的Ubuntu Linux系统上下载并安装了Cassandra的压缩包版本(这是由于apt-get版本由于某种原因而无法安装)，并发现真正的难点在于Cassandra集群的配置。所有与节点及其集群相关的可调节参数都被保存在configuration.yaml文件当中。

　　举例来说，大家可以设置分配给对应节点的令牌数量，这一数量决定了该节点负责处理的数据比例(相对于其它节点)。(如果大家的集群由异构式硬件组成，这项将相当实用，因为我们可以通过配置让更多集群成员处理较为繁重的负载。)令人振奋的是，对于小规模试验性安装环境，大家只需要对当前节点以及集群seed节点的IP地址监听机制进行配置即可。

　　OpsCenter会在我们的管理主机上运行一项服务器进程，旨在与运行在各集群节点上的代理进程进行通信。这些代理进程负责收集资源利用率及性能信息，并将结果发送至服务器端;服务器则通过一套基于浏览器的用户界面、旨在帮助管理员查看汇总结果。在OpsCenter的帮助下，大家可以完成浏览数据、检查工作量图表、管理列族以及启用集群负载平衡等工作。(顺带一提，我无法让OpsCenter在自己的Linux系统环境下成功运作。虽然DataStax Community版本在Windows环境下能够正常运行，但仍有部分功能无法实现——举例来说，它无法与代理服务相连接。)

　　虽然Apache Cassandra以及Planet Cassandra网站上提供说明文档——其中大部分属于常见问题解答、维基百科以及博文内容——但DataStax仍然是最具综合性的Cassandra说明文档及相关教程来源。事实上，Planet Cassandra网站的起始页面或多或少倾向于将访问者引导至DataStax页面。

　　DataStax同时提供当前及前续版本的说明文档;当Cassandra获得版本更新时，大家可以借此对尚在使用的任何前续版本进行故障排查。文档页面当中包含丰富的超链接，并提供大量图表帮助各位理解。在视频教程的引导下，大家也可以找到关于Java及C#驱动程序的相关指南以及Cassandra的内部开发者博客。

　　就目前来说，Cassandra尚不提供任何交易型功能。不过Cassandra的最新版本(也就是2.0版本)添加了“轻量级交易”机制，从而实现了原子性“比较及设置”架构。这项新特性在CQL中的实际表现就是在INSERT以及UPDATE命令中出现了条件性IF子句。如果特定条件判定为true，那么数据就会得到修改。大家可以由此想见，一条CQL INSERT语句能够只在某行不存在的情况下添加该行，而交易性IF测试的存在能够保证INSERT对于数据库而言始终具备原子性。

　　Cassandra 2.0还利用“eager retries”机制改进了响应性能。如果特定副本的读取请求响应速度太低，Cassandra就会将请求发送至其它副本节点处——前提是其它副本节点能够在响应超时之前返回结果。在2.0版本中，Cassandra会以“较为消极”的方式处理陈旧索引消除工作。在过去，陈旧索引会被立即清除，这就要求系统利用同步锁定机制保持一致性。新版本中的新技术避免了由锁定机制带来的生产能力下降。

　　尽管Cassandra是一套复杂的系统，但其对称性集群节点设计大大降低了其部署及运行的操作难度。具备大量SQL类特性的CQL同样带来巨大优势，使得原本熟悉RDBMS环境的开发人员能够更快、更轻松地在新领域中获得生产能力。

　　不过平心而论，Cassandra的学习曲线仍然不容小觑。大家最好先设置一套规模适中的小型开发集群，并以此为基础进行大量试验、特别是针对数据架构及配置参数的尝试。随着应用程序的不断扩展，性能问题可能会成为大家面临的主要障碍。

Apache Cassandra 2.0总体评价

　　原文链接：Review: Cassandra lowers the barriers to big data