0 Cassandra来自何方

Cassandra数据存储系统是一个Apache开源项目，位于http://cassandra.apache.org。2007年Facebook为了解决消息收件箱的搜索问题而开始了Cassandra项目，因为当时他们遇到了传统的方法难以解决的超大数据量存储的可扩展性问题。具体说来，项目团队需要处理大量的消息副本、消息的反向索引等不同形式的数据，需要处理很多随机读和并发随机写操作。

这个团队由Jeff Hammerbacher领导，核心工程师包括Avinash Lakshman，Karthik Ranganathan和搜索团队的工程师Prashant Malik。源代码在2008年7月公布到Google Code上，成为了一个开源项目。但2008年作为Google Code的项目时，还只有Facebook的工程师在更新项目，未形成社区力量。之后，在2009年3月，Cassandra成为了一个Apache孵化器项目，并在2010年2月17日成为了Apache顶级项目。

Facebook的Lakshman和Malik写的关于Cassandra的论文“A Decentralized Structured Storage System”可以在这里访问http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf。

如今的Cassandra似乎有某种矛盾性：感觉上Cassandra很新很激进，但它植根于很多前人建立和信奉的标准、传统的计算机科学概念和信条中。Cassandra是一个实用主义的数据库，它并不是特地做得和关系型数据库不同来标新立异，也不是某几个天才的玩物。它是被设计用来解决现有工具还不能解决的实际问题的。它了解之前方法的局限性，并专注于新的面向大规模数据的新世界。

Cassandra如何得名的总有人问我Cassandra从何得名的，让我有点奇怪。当我听到这个项目的时候，名字并不是我首先想到的问题。不过这确实挺有趣的，特别是对于这个数据库，它的名字确实是有讲究的。在希腊神话里，Cassandra是特洛伊国王Priam和Hecuba王后的女儿。Cassandra非常美丽，以至于阿波罗给了她预见未来的能力。但当她拒绝阿波罗的爱慕的时候，遭到他的诅咒。从此，她依然可以精确地预知未来，但是不会有任何人相信她。Cassandra预知了她的特洛伊城终将覆灭，但却无力阻止这一悲剧。Cassandra分布式数据库就据此命名。我怀疑这个名字有点调侃德尔斐神谕（Delphi Oracle），Oracle也是用先知命名的数据库。

我们已经介绍了Cassandra的主要特点，对Cassandra的长处有了一定理解。尽管Cassandra设计精巧、功能出色，但也不能胜任所有工作。所以，这里我们来介绍一下Cassandra最擅长的领域。

1 Cassandra的应用场景

1.1　大规模部署

你可能不会开着一辆轻型小卡车去取干洗的衣服，小卡车显然不适合这种工作。Cassandra的很多精巧设计都专注于高可用、可调一致性、P2P协议、无缝扩展等，这些都是Cassandra的卖点。这些特性在单节点工作时都是没有意义的，更无法实现它的全部能力。但是，单节点关系数据库在很多情况下可能正是我们需要的。所以，你需要做一些评估。

考虑你期望的流量、吞吐需求以及SLA等。关于评估没有什么硬性的指标和要求，但如果你认为有几种关系型数据库可以很好地应付你的流量，提供不错的性能，那可能选关系型数据库更好，简单地说，这是因为RDBMS更易于在单机上运行，你也更熟悉。

但是，如果你认为需要至少几个节点才能支撑你的业务，那Cassandra就是个不错的选择。如果你的应用可能需要数十个节点，那Cassandra可能就是个很棒的选择了。

1.2　写密集、统计和分析型工作

考虑一下你的应用的读写比例，Cassandra是为优异的写吞吐量而特别优化的。许多早期使用Cassandra的产品都用于存储用户状态更新、社交网络、建议/评价以及应用统计等。这些都是Cassandra很好的应用场景，因为这些应用大都是写多于读的，并且更新

可能随时发生并伴有突发的峰值。事实上，支撑应用负载需要很高的多客户线程并发写性能，这正是Cassandra的主要特性。根据项目的wiki，Cassandra已经被用于开发了多种不同的应用，包括一个窗口化的时间序列数据库，一个用于文档搜索的反向索引，以及一个分布式任务优先级队列。

1.3　地区分布

Cassandra直接支持多地分布的数据存储。Cassandra可以很容易配置成将数据分布到多个数据中心的存储方式。如果你有一个全球部署的应用，那么让数据贴近用户会获得不错的性能收益，Cassandra正适合这种应用场合。

1.4　变化的应用

如果你正在“初创阶段”，业务会不断改进，Cassandra这种没有Schema的数据模型可能更适合你。这让你的数据库能更好地跟上业务改进的步伐。

2 谁在使用Cassandra

不管怎么说，Cassandra还是处在初级阶段，在本书写作的时候也还没有达到1.0发布的水平。没有什么易用的图形化的管理工具可用，社区之中，也还有一些内部和外部的有争议的设计问题。但是即使是在开发的早期，它作为一种有发展前景、可用而且稳定的数据存储系统，已经被很多知名的大公司用到了产品之中。

实际上，有一种被称为“从众谬误”的逻辑谬误，即那些很流行、很大众化的东西就被认为是对的。Cassandra毫无疑问有一个火箭式的上升期，特别是在过去一年里。不过，我仍然认为这些在不同公司的不同产品中的应用至少可以证明Cassandra是有用的，而且已经随时可用。

正在使用Cassandra的公司还在增长中，这些公司如下。

（1） Twitter正在使用Cassandra做数据分析。在一篇广为引用的博客里（http://engineering.twitter.com/2010/07/cassandra-at-twitter-today.html），Twitter的主要Cassandra工程师RyanKing解释道，Twitter决定不会像开始计划的那样使用Cassandra作为其主要的tweets存储系统，但还会将Cassandra用于多个不同的地方，包括：实时分析，地理和位置信息，以及全部用户信息的数据挖掘。

（2） Mahalo使用Cassandra作为其主要的近实时数据存储。

（3） Facebook还在使用Cassandra作为其收件箱的索引，不过使用的是一个非开源分支。1译注1：根据Facebook的工程师团队在2010年11月对他们发布的新消息系统的介绍，新消息系统是基于HBase而非Cassandra的。

（4） Digg也使用Cassandra作为主要的近实时数据存储。

（5） Rackspace使用它进行云服务、监控和日志存储。

（6） Reddit使用它作为持久化的缓存。

（7） Cloudkick使用Cassandra用于监控统计和分析。

（8） Ooyala使用Cassandra存储和服务近实时的视频分析数据。

（9） SimpleGeo使用Cassandra作为实时位置信息的主要存储系统。

（10）Onespot使用它作为部分主要数据的存储系统。

Cisco和Platform64也在使用Cassandra，而且Comcast和bee.tv也准备使用Cassandra来为移动设备提供网上的个性化电视服务。其实还有更多。

最后要说的是，这些应用都是真实存在的，各种不同领域的公司都找到了Cassandra的应用场合并获得成功。在本书写作的时候，最大的Cassandra应用来自于Facebook，他们在100多台机器上存储了超过50TB的数据。很多公司都在不同的产品项目里评估Cassandra，而由ApacheCassandra项目的主席JonathanEllis等人成立的公司Riptano也于2010年4月成立了。随着更多的特性、更好的工具以及技术支持方案的加入，可以预期会有更多的人加入使用Cassandra的行列。

3 小结

本章我们介绍了Cassandra的特征、历史和主要特性。我们了解到了哪些公司使用了Cassandra和它们的使用目的。我们还回顾了数据库技术的发展史，以此可以从历史角度看待Cassandra的价值。