Cassandra 英文原文：Cassandra - A Decentralized Structured Storage System

摘要

Cassandra是一个分布式存储系统，可以方面管理分布在很多商业服务器节点上的非常大量的结构化数据，同时提供无单点失效的高可用服务。Cassandra目标是在几百个基础节点上运行（可能分布在不同的数据中心）。在这个规模上，大大小小的组件经常失效。Cassandra对这些失败持久状态的管理方式促使软件系统的可靠性和扩展性依赖这一服务。虽然在许多方面Cassandra类似于一个数据库，并且共享很多设计和相关实现策略，但Cassandra并不支持完整的关系数据模型；相反，它为客户提供了一个支持动态控制数据布局并且格式简单数据模型。Cassandra系统设计目标是：运行在廉价商业硬件上，高写入吞吐量处理，同时又不用以牺牲读取效率为代价。

1.简介

Facebook是世界上最大的社交网络平台，高峰时期有数以万计分布在世界各地的服务器为数百万用户提供服务。Facebook平台在性能、可靠性、效率以及支持持续增长平台所需的高扩展性等方面对操作有着严格的要求。我们的标准操作模式是在由几千个组件组成的基础设施上进行故障处理；任何时候都总有一些小型但非常重要的服务器或网络组件会发生故障。因此，软件系统需要建立处理故障（在这种情况下故障是一种常态而非异常）的机制。为了满足上述可靠性和可扩展性的需要，Facebook研发了Cassandra。

Cassandra使用了一系列总所周知的技术来实现可扩展性和可用性。Cassandra是为满足inbox搜索问题的存储需求而设计的。In- box搜索是facebook中的一项功能，允许用户通过他们Facebook的Inbox进行搜索。对于Facebook而言，这意味着系统需要处理一个非常高的写入吞吐量，数十亿计的每日写入量，以及相同规模用户量。由于用户从分布在不同地区的不同的数据中心获取数据，能够在不同数据中心复制数据是解决搜索延迟的关键。In-box搜索服务是在2008年6月推出的，到目前为止已经有累计超过2.5亿用户使用，Cassandra也达到了它的设计初衷。Cassandra现在已经被用作多个Facebook服务的备份存储系统。

本文结构如下：第2小节谈了相关研究以及Cassandra设计中一些已经非常有影响力的设计。第3小节将会给出详细的数据模型。第4小节给出了客户端API概述。第5小节介绍了Cassandra的系统设计和分布式算法。第6小节重点讲述Cassandra使用经验以及性能调优。在6.1小节中我将详细讲述Facebook平台上的应用是如何运用Cassandra的。最后第7小节进行全文总结以及Cassandra未来展望。

2. 相关研究

分布式数据的性能、可用性和耐受性在文件系统和数据库方面已经得到了广泛的研究。同仅支持命名空间的P2P存储系统相比，分布式文件系统通常都支持层级结构命名空间。像Ficus[14]和Coda[16]之类的系统以牺牲一致性为代价来获取高可用性。更新冲突通常使用专门的冲突解决流程来进行管理。Farsite[2]是一个分布式文件系统，没有使用中央服务器，通过复制来达到高可用性和扩展性。Google文件系统（GFS）[9]是另一个分布式文件系统，用来管理Google内部应用的托管状态。GFS使用了一种简单的设计，以一个主服务器来存储所有的元数据，其余数据被分成块存储到各个块服务器上。然而GFS主服务器现在使用了Chubby[3]抽象来进行容错处理。Bayou[18]是一个分布式关系数据库系统，允许断开连接下的操作并且提供最终数据一致性。在这些系统中Bayou, Coda 和Ficus允许断开连接下的操作并且可以弹性处理网络中断、停电之类的问题。这些系统的冲突解决流程各有差别。例如，Coda 和 Ficus平台提供系统级别冲突解决方案，Bayou提供应用级别的解决方案。所有的这些都是为了保证数据的最终一致性。同这些文件系统一样，Dynamo[6] 即使当网络断开的时候也允许读写操作的继续，并且通过不同冲突解决机制(某些是由客户端驱动的)来解决更新冲突。传统复制关系数据库的系统专注于保证复制数据强一致性的问题。虽然强一致性为应用开发者提供了一个方便的编程模型，但是这些系统在扩展性和可用性[10]上却被限制了。这些系统不能够处理网络中断的问题，因为他们通常都提供了强一致性的保证。

Dynamo 是一个采用Amazon的存储系统，用来存储和检索用户的购物车。Dynamo的Gossip基于成员算法来帮助每个节点保持其他的每个几点的信息。

Dynamo可以定义为在大多数单跳请求路由的结构化覆盖。Dynamo使用向量时钟计划用来检测新的冲突，但偏向于一个客户端解决冲突的机制。在Dynamo中的一个写操作同样需要读操作进行向量时间戳的管理。这在系统需要处理高吞吐量的环境中非常受限。Bigtable[4] 提供了结构和数据的分布式，但是依赖于一个分布式文件系统用来做持久化。

3. 数据模型

Cassandra中的表是一个分布式多维度由键索引的映射，值是一个高度结构化的对象。表中的行键是一个没有大小限制的字符串，尽管通常情况下是16~36的字节长度。每个单行键下的操作都是一个原子副本，不管多少读取或写入了多少列。列被统一放在一个叫做列簇的集合中，这和Bigtable[4]系统的的工作机制很相似。Cassandra 有两种列簇——简单和超级列簇。超级列簇可以用一个列簇内又有一个列簇来形象化表示。

此外，应用可以在一个超列簇或普通列簇中指定列的排序。系统允许列按照时间或者名称对列进行排序。列的时间排序是特地为像inbox搜索这类结果需要按时间排序的应用提供的。任何列簇的列都要通过列簇访问规约（列和任何超列簇中的列都需使用列簇访问规约:super column : column）来进行访问。文中6.1小结给出了一个能够非常好的体现超列簇抽象能力的例子。通常的应用使用专用的Cassandra 集群，并作为其服务的一部分来管理。尽管系统支持多表的概念，但所有部署结构中都只有一个表。

4. API

Cassandra的API包括以下三个简单的方法.

• insert(table; key; rowMutation)
• get(table; key; columnName)
• delete(table; key; columnName)

columnName 可以是含有列族的一个特殊列, 一个列族，超列族，或者带有超列的一个特定列.

5. 系统架构

需要在产品设置中进行操作的存储系统架构非常复杂。除了实际的数据持久化组件之外，系统还需要有以下特性；可扩展性和强大的负载均衡，会员和故障检测，故障修复，副本同步，负载均衡，状态转移，并发和作业调度，请求编组，请求路由，系统监控和报警以及配置管理。每种解决方法详细描述都超出了本文讨论的范围，所以我们只会讨论Cassandra系统所使用的核心分布式技术：分区、复制、会员、故障处理以及扩展。所有的这些模块都需要同步处理读/写请求。通常一个键的读/写请求需要被发送到Cassandra集群中的任何一个节点上，然后节点判断是否为这个特定键的副本。对于写操作，系统将请求路由到副本并等待法定的副本数目的响应，以确认写操作的完成。对于读取，需要依据用户的一致性需求而定，系统要么将请求路由到最近的副本上或者路由到所有副本并等待法定的副本数目的响应。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务