背景
2007年Facebook为了解决消息收件箱搜索问题（Inbox Search problem）而开始设计Cassandra项目。 当时Facebook遇到了传统的方法难以解决的超大数据量存储可扩展性问题。具体来说，项目团队需要处理大量的消息副本、消息的反向索引等不同形式的数据，需要处理很多随机读和并发随机写操作。
该团队由Jeff Hammerbacher领导，核心工程师包括Avinash Lakshman，Karthik Ranganathan和搜索团队的Prashant Malik。2008年7月Cassandra的代码被作为开源项目发布到Google Code。虽然代码在2008年作为Google Code的一个项目，但是这段时间基本上只有Facebook工程师来更新代码，基本上没有形成社区。所以在2009年3月，Cassandra 被转移到Apache孵化器项目，并在2010年2月17日，它被投票成为一个顶级项目。在 Apache Cassandra Wiki上，您可以找到committers列表，其中许多人自2010/2011年以来就一直参与该项目。 committers主要来自Twitter，LinkedIn，Apple，其中还包括了许多独立开发者。
Cassandra的设计很大程度受Amazon Dynamo的影响，具体可参见《Dynamo: Amazon's Highly Available Key-value Store》。2010年由Facebook的Lakshman和Malik在ACM首次发表了Cassandra的论文《Cassandra: a decentralized structured storage system》，向全世界介绍了Cassandra。
随着商界对Cassandra的兴趣增加，对Cassandra的生产支持变得越来越明显。2010年4月Cassandra的Apache项目主席Jonathan Ellis和其同事Matt Pfeil成立了一家名为DataStax公司（最初名为Riptano）。DataStax雇佣了多名Cassandra Committer，为Cassandra项目提供了相关支持，并引领其发展。?
概述
Cassandra主要借鉴了Amazon Dynamo（集群管理、副本、容错）和Google Bigtable（单机存储引擎LSM Tree）两篇论文思想：
?总结了 Dynamo 使用的这些技术及每项技术的好处。
?Amazon 平台的面向服务架构
CAP理论：
特征
分布式和去中心化（Distributed and Decentralized）
Cassandra是分布式的，这意味着它可以运行在多台机器上，并呈现给用户一个一致的整体。事实上，在一个节点上运行Cassandra是没啥用的，虽然我们可以这么做，并且这可以帮助我们了解它的工作机制，但是你很快就会意识到，需要多个节点才能真正了解Cassandra的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行，更为多机架部署进行了优化，甚至一个Cassandra集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上，Cassandra 都会收到数据。
对于很多存储系统（比如 MySQL, Bigtable），一旦你开始扩展它，就需要把某些节点设为主节点，其他则作为从节点。但 Cassandra 是无中心的，也就是说每个节点都是一样的。与主从结构相反，Cassandra 的协议是 P2P 的，并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见《分布式原理：一文了解 Gossip协议》。
去中心化这一事实意味着Cassandra不会存在单点失效。Cassandra集群中的所有节点的功能都完全一样，所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称（server symmetry）。
综上所述，Cassandra 是分布式、无中心的，它不会有单点失效，所以支持高可用性。
弹性可扩展（Elastic Scalability）
可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展，是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器，每台机器提供全部或部分数据，这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。
弹性可扩展是指水平扩展的特性，意即你的集群可以不间断的情况下，方便扩展或缩减服务的规模。这样，你就不需要重新启动进程，不必修改应用的查询，也无需自己手工重新均衡数据分布。在 Cassandra 里，你只要加入新的计算机，Cassandra 就会自动地发现它并让它开始工作。
高可用和容错（High Availability and Fault Tolerance）
从一般架构的角度来看，系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障，从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况，所以它们一般都有硬件冗余，并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统，它必须由多台联网的计算机构成，并且运行于其上的软件也必须能够在集群条件下工作，有设备能够识别节点故障，并将发生故障的中端的功能在剩余系统上进行恢复。
Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点，还可以把数据分布到多个数据中心里，从而提供更好的本地访问性能，并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。
可调节的一致性（Tuneable Consistency）
2000年，加州大学伯克利分校的 Eric Brewer在ACM分布式计算原理会议提出了著名的CAP定律。CAP定律表明，对于任意给定的系统，只能在一致性（Consistency）、可用性（Availability）以及分区容错性（Partition Tolerance）之间选择两个。
关于CAP定律的详细介绍可参见《分布式系统一致性问题、CAP定律以及BASE理论》以及《一篇文章搞清楚什么是分布式系统CAP定理》。
所以Cassandra在设计的时候也不得不考虑这些问题，因为分区容错性这个是每个分布式系统必须考虑的，所以只能在一致性和可用性之间做选择，而Cassandra的应用场景更多的是为了满足可用性，所以我们只能牺牲一致性了。但是根据BASE理论，我们其实可以通过牺牲强一致性获得可用性。
Cassandra提供了可调节的一致性，允许我们选定需要的一致性水平与可用性水平，在二者间找到平衡点。因为客户端可以控制在更新到达多少个副本之前，必须阻塞系统。这是通过设置副本因子（replication factor）来调节与之相对的一致性级别。
通过副本因子（replication factor），你可以决定准备牺牲多少性能来换取一致性。副本因子是你要求更新在集群中传播到的节点数（注意，更新包括所有增加、删除和更新操作）。
客户端每次操作还必须设置一个一致性级别（consistency level）参数，这个参数决定了多少个副本写入成功才可以认定写操作是成功的，或者读取过程中读到多少个副本正确就可以认定是读成功的。这里Cassandra把决定一致性程度的权利留给了客户自己。
所以，如果需要的话，你可以设定一致性级别和副本因子相等，从而达到一个较高的一致性水平，不过这样就必须付出同步阻塞操作的代价，只有所有节点都被更新完成才能成功返回一次更新。而实际上，Cassandra一般都不会这么来用，原因显而易见（这样就丧失了可用性目标，影响性能，而且这不是你选择Cassandra的初衷）。而如果一个客户端设置一致性级别低于副本因子的话，即使有节点宕机了，仍然可以写成功。
总体来说，Cassandra更倾向于CP，虽然它也可以通过调节一致性水平达到AP；但是不推荐你这么设置。
面向行（Row-Oriented）
Cassandra经常被看做是一种面向列（Column-Oriented）的数据库，这也并不算错。它的数据结构不是关系型的，而是一个多维稀疏哈希表。稀疏（Sparse）意味着任何一行都可能会有一列或者几列，但每行都不一定（像关系模型那样）和其他行有一样的列。每行都有一个唯一的键值，用于进行数据访问。所以，更确切地说，应该把Cassandra看做是一个有索引的、面向行的存储系统。
Cassandra的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段，还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中，不必进行长达数月的预先分析。对于使用Cassandra的应用，如果业务发生变化了，只需要在运行中增加或删除某些字段就行了，不会造成服务中断。
当然， 这不是说你不需要考虑数据。相反，Cassandra需要你换个角度看数据。在RDBMS里， 你得首先设计一个完整的数据模型，然后考虑查询方式， 而在Cassandra里，你可以首先思考如何查询数据，然后提供这些数据就可以了。
灵活的模式（Flexible Schema）
Cassandra的早期版本支持无模式（schema-free）数据模型，可以动态定义新的列。无模式数据库（如Bigtable和MongoDB）在访问大量数据时具有高度可扩展性和高性能的优势。无模式数据库的主要缺点是难以确定数据的含义和格式，这限制了执行复杂查询的能力。
为了解决这些问题，Cassandra引入了Cassandra Query Language（CQL），它提供了一种通过类似于结构化查询语言（SQL）的语法来定义模式。最初，CQL 是作为Cassandra的另一个接口，并且基于Apache Thrift项目提供无模式的接口。 在这个过渡阶段，术语“模式可选”（Schema-optional）用于描述数据模型，我们可以使用CQL的模式来定义。并且可以通过Thrift API实现动态扩展以此添加新的列。在此期间，基础数据存储模型是基于Bigtable的。
从3.0版本开始，不推荐使用基于Thrift API的动态列创建的API，并且Cassandra底层存储已经重新实现了，以更紧密地与CQL保持一致。Cassandra并没有完全限制动态扩展架构的能力，但它的工作方式却截然不同。CQL集合（比如 list、set、尤其是 map）提供了在无结构化的格式里面添加内容的能力，从而能扩展现有的模式。CQL还提供了改变列的类型的能力，以支持JSON格式的文本的存储。
因此，描述Cassandra当前状态的最佳方式可能是它支持灵活的模式。
高性能（High Performance）
Cassandra在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能，并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器，存储数TB的数据。Cassandra已经显示出了高负载下的良好表现，在一个非常普通的工作站上，Cassandra也可以提供非常高的写吞吐量。而如果你增加更多的服务器，你还可以继续保持Cassandra所有的特性而无需牺牲性能。
扩展：
HBase和Cassandra几乎是一个年份发起,又都是在2010年成为Apache的顶级项目,不过如果我们去细品其内部机制,我们会发现其实两者是完全不同的架构风格
HBase
架构
原理
应用场景
1、大规模部署
Cassandra的很多精巧设计都专注于高可用、可调一致性、P2P 协议、无缝扩展等，这些都是Cassandra 的卖点。这些特性在单节点工作时都是没有意义的，更无法实现它的全部能力。
但是，单节点关系数据库在很多情况下可能正是我们需要的。所以你需要做一些评估。考虑你的期望的流量、吞吐需求以及SAL等。关于评估没有什么硬性的指标和要求。但如果你认为有几种关系型数据库可以很好地应付你的流量，提供不错的性能，那可能选关系型数据库更好。简单地说，这是因为RDBMS更易于在单机上运行，对你来说也更熟悉。
但是，如果你认为需要至少几个节点才能支撑你的业务，那Cassandra就是个不错的选择。如果你的应用可能需要数十个节点，那Cassandra可能就是个很棒的选择了。
2、写密集、统计和分析型工作
考虑一下你的应用的读写比例，Cassandra是为优异的写吞吐量而特别优化的。
许多早期使用Cassandra的产品都用于存储用户状态更新、社交网络、建议/评价以及应用统计等。这些都是Cassandra很好的应用场景，因为这些应用大都是写多于读的，并且更新可能随时发生并伴有突发的峰值。事实上，支撑应用负载需要很高的多客户线程并发写性能，这正是Cassandra的主要特性。
根据项目的wiki，Cassandra已经被用于开发了多种不同的应用，包括窗口化的时间序列数据库，用于文档搜索的反向索引，以及分布式任务优先级队列。
3、地区分布
Cassandra直接支持多地分布的数据存储，Cassandra可以很容易配置成将数据分布到多个数据中心的存储方式。如果你有一个全球部署的应用，那么让数据贴近用户会获得不错的性能收益，Cassandra正适合这种应用场合。
4、变化的应用
如果你正在“初创阶段”，业务会不断改进，Cassandra这种灵活的模式的数据模型可能更适合你。这让你的数据库能更快地跟上业务改进的步伐。
