目前关于大家提出的Cassandra是什么这个问题，大家都希望能够得到一个答案，那么小编今天就去收集了一些Cassandra是什么相关的内容来分享给大家，如果大家感兴趣的话可以接着往下看。

Apache Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集Google BigTable的数据模型与Amazon Dynamo的完全分布式架构于一身。

Apache Cassandra 是一套开源分布式 NoSQL数据库系统。它最初由 Facebook 开发，用于储存收件箱等简单格式数据，集 Google BigTable 的数据模型与 Amazon Dynamo 的完全分布式架构于一身。

Facebook 于 2008 将 Cassandra 开源，此后，由于 Cassandra 良好的可扩展性和性能，被 Apple, Comcast,Instagram, Spotify, eBay, Rackspace, Netflix 等知名网站所采用，成为了一种流行的分布式结构化数据存储方案。

在数据库排行榜“DB-Engines Ranking”中，Cassandra 排在第七位，是非关系型数据库中排名第二高的（仅次于 MongoDB）。

Cassandra 的名称来源于希腊神话，是特洛伊的一位悲剧性的女先知的名字，因此项目的 Logo 是一只放光的眼睛。

这个项目由就职于 Facebook 的 Avinash Lakshman（也是 Amazon Dynamo 的作者之一）和 Prashant Malik 在为 Facebook 的 Inbox 编写。2008 年，Facebook 将项目开源，Cassandra 在 2009 年成为了 Apache 软件基金会的 Incubator 项目，并在 2010 年 2 月走出孵化器，成为正式的基金会项目。当前这个项目主要由专门进行 Cassandra 商业化运作的 DataStax 公司来开发，也有一些来自其他公司或独立的开发者。

Cassandra 使用了 Google 设计的 BigTable 的数据模型，与面向行(row)的传统的关系型数据库或键值存储的 key-value 数据库不同，Cassandra 使用的是宽列存储模型(Wide Column Stores)，每行数据由 row key 唯一标识之后，可以有最多 20 亿个列，每个列有一个 column key 标识，每个 column key 下对应若干 value。这种模型可以理解为是一个二维的 key-value 存储，即整个数据模型被定义成一个类似 map<key1, map<key2,value>>的类型。

旧版的 Cassandra 与客户端交互的方法是通过 thrift，而当前新版本的 Cassandra 采用与 SQL 语言类似的 CQL 语言来实现数据模型的定义和数据的读写。其中 BigTable 中的列族(Column Family)在 Cassandra 中被称作类似关系型数据库中的称呼——表(table)，而 Cassandra/BigTable 中的 row key 和 column key 并称为主键(primary key)。

Cassandra 的 row key 决定了该行数据存储在哪些节点中，因此 row key 需要按哈希来存储，不能顺序的扫描或读取，而一个 row 内的 column key 是顺序存储的，可以进行有序的扫描或范围查找。

与 BigTable 和其模仿者 HBase 不同，Cassandra 的数据并不存储在分布式文件系统如 GFS 或 HDFS 中，而是直接存于本地。与 BigTable 一样，Cassandra 也是日志型数据库，即把新写入的数据存储在内存的 Memtable 中并通过磁盘中的 CommitLog 来做持久化，内存填满后将数据按照 key 的顺序写进一个只读文件 SSTable 中，每次读取数据时将所有 SSTable 和内存中的数据进行查找和合并。这种系统的特点是写入比读取更快，因为写入一条数据是顺序计入 commit log 中，不需要随机读取磁盘以及搜索。

Cassandra 的系统架构与 Dynamo 类似，是基于一致性哈希的完全 P2P 架构，每行数据通过哈希来决定应该存在哪个或哪些节点中。集群没有 master 的概念，所有节点都是同样的角色，彻底避免了整个系统的单点问题导致的不稳定性，集群间的状态同步通过 Gossip 协议来进行 P2P 的通信。每个节点都把数据存储在本地，每个节点都接受来自客户端的请求。每次客户端随机选择集群中的一个节点来请求数据，对应接受请求的节点将对应的 key 在一致性哈希的环上定位是哪些节点应该存储这个数据，将请求转发到对应的节点上，并将对应若干节点的查询反馈返回给客户端。

在一致性、可用性和分区耐受能力（CAP）的折衷问题上，Cassandra 和 Dynamo 一样比较灵活。Cassandra 的每个 keyspace 可配置一行数据会写入多少个节点(设这个数为 N)，来保证数据不因为机器宕机或磁盘损坏而丢失数据，即保证了 CAP 中的 P。用户在读写数据时可以指定要求成功写到多少个节点才算写入成功(设为 W)，以及成功从多少个节点读取到了数据才算成功(设为 R)。可推理得出，当 W+R>N 时，读到的数据一定是上一次写入的，即维护了强一致性，确保了 CAP 中的 C。当 W+R<=N 时，数据是最终一致性因为存在一段时间可能读到的并不是最新版的数据。当 W=N 或 R=N 时，意味着系统只要有一个节点无响应或宕机，就有一部分数据无法成功写或者读，即失去了 CAP 中的可用性 A。因此，大多数系统中，都将 N 设为 3，W 和 R 设为 QUORUM，即“过半数”——在 N 为 3 时 QUORUM 是 2。

Cassandra 支持对一列数据进行 insert、update、或 delete 操作。其中 insert 和 update 虽然语法略有区别，但语义上等价，即可以针对已经存在的行进行 update 或 insert 一个不存在的行。

轻量级事务

从 0 版开始，Cassandra 支持轻量级事务。这种事务被称为“compare-and-set”，简称 CAS。通过 paxos 算法实现在满足某条件后才修改数据否则不修改。当前支持”insert if not exist”、”update if col=value”、”delete if exist”等几种操作。