Apache Cassandra数据库-Apache Cassandra分布式数据库下载 v3.11.7 官方最新版-IT猫扑网

Apache Cassandra是一个开源的混合型的非关系的数据库、很早之前Facebook开发，并且应用于苹果、360等全球很多公司，因为它具有很多同类型产品的优点，除了免费，还有分布式、无中心、弹性可扩展等优势，比Dynomite的功能更为丰富，很多网站都会应用到。

官方介绍

当您需要可伸缩性和高可用性而不影响性能时，Apache Cassandra数据库是正确的选择。线性可扩展性和在商用硬件或云基础架构上经过验证的容错能力使它成为关键任务数据的理想平台。 Cassandra对跨多个数据中心的复制提供了一流的支持，为您的用户提供了更低的延迟，并且知道您可以在区域中断中幸存，因此安心无忧。

在Windows上安装cassandra方法

一、安装配置

1)解压下载后的程序apache-cassandra-0.7.3-bin.tar.gz到某个目录，如d:\cassandra；

2)修改conf目录下配置文件

A)使用记事本打开cassandra.yaml文件，修改如下参数：

data_file_directories:

- /var/lib/cassandra/data

为 - d:\cassandra\data

注意：-后面需要有空格

commitlog_directory: /var/lib/cassandra/commitlog

为：commitlog_directory: d:\cassandra\commitlog

saved_caches_directory: /var/lib/cassandra/saved_caches

为：saved_caches_directory: d:\cassandra\saved_caches

B)使用记事本打开log4j-server.properties文件，修改如下参数：

log4j.appender.R.File=/var/log/cassandra/system.log

为：log4j.appender.R.File=D:\Cassandra\logs

二、安装jre

2.1 下载安装程序

在https://www.oracle.com/technetwork/java/javase/downloads/index.html上下载jre的安装程序；

jre和jdk区别：jre只是java环境，jdk包含了开发工具和jre；

2.2 直接双击执行jre-6u25-windows-i586.exe进行安装，默认安装在C:\Program Files\Java\jre6目录即可；

三、配置环境变量

3.1 打开windows的环境变量配置窗口

鼠标右键点击我的电脑，选择属性，在弹出界面点击【高级】页签，再点击【环境变量】按钮；

3.2 配置JAVA_HOME环境变量

在“系统变量”添加JAVA_HOME，点击【系统变量】下方的【新建】按钮，输入

变量名:JAVA_HOME

变量值:C:\Program Files\Java\jre6

3.3 配置Cassandra_HOME环境变量

在“系统变量”添加Cassandra_HOME，点击【系统变量】下方的【新建】按钮，输入

变量名:Cassandra_HOME

变量值:D:\Cassandra\apache-cassandra-0.7.3

四、启动Cassandra

开始运行中敲入cmd回车打开命令窗口，敲入cd D:\Cassandra\apache-cassandra-0.7.3\bin回车，敲入d:回车，转到D:\Cassandra\apache-cassandra-0.7.3\bin目录后，直接敲入cassandra就可以启动cassandra服务了，如下：

D:\Cassandra\apache-cassandra-0.7.3\bin>cassandra

Starting Cassandra Server

INFO 09:33:34,375 Logging initialized

INFO 09:33:34,390 Heap size: 1070399488/1070399488

INFO 09:33:34,390 JNA not found. Native methods will be disabled.

INFO 09:33:34,406 Loading settings from file:/D:/Cassandra/apache-cassandra-0.7.3/conf/cassandra.yaml

INFO 09:33:34,562 DiskaccessMode 'auto' determined to be standard, indexAccessMode is standard

INFO 09:33:34,765 Creating new commitlog segment d:\cassandra\commitlog\CommitLog-1306200814765.log

INFO 09:33:34,781 Couldn't detect any schema definitions in local storage.

INFO 09:33:34,781 Found table data in data directories. Consider using JMX to call org.apache.cassandra.service.StorageService.loadSchemaFromYaml().

INFO 09:33:34,796 No commitlog files found; skipping replay

INFO 09:33:34,828 Upgrading to 0.7. Purging hints if there are any. Old hints will be snapshotted.

INFO 09:33:34,828 Cassandra version: 0.7.3

INFO 09:33:34,828 Thrift API version: 19.4.0

INFO 09:33:34,843 Loading persisted ring state

INFO 09:33:34,843 Starting up server gossip

INFO 09:33:34,843 switching in a fresh Memtable for LocationInfo at CommitLogContext(file='d:\cassandra\commitlog\CommitLog-1306200814765.log', position=700)

INFO 09:33:34,859 Enqueuing flush of Memtable-LocationInfo@31556811(227 bytes,4 operations)

INFO 09:33:34,859 Writing Memtable-LocationInfo@31556811(227 bytes, 4 operations)

INFO 09:33:35,656 Completed flushing d:\cassandra\data\system\LocationInfo-f-1-Data.db (335 bytes)

WARN 09:33:35,718 Generated random token 152144483071909207899303400696660552068. Random tokens will result in an unbalanced ring; see https://wiki.apache.org/cassandra/Operations

INFO 09:33:35,718 switching in a fresh Memtable for LocationInfo at CommitLogContext(file='d:\cassandra\commitlog\CommitLog-1306200814765.log', position=996)

INFO 09:33:35,718 Enqueuing flush of Memtable-LocationInfo@22975191(53 bytes, 2operations)

INFO 09:33:35,734 Writing Memtable-LocationInfo@22975191(53 bytes, 2 operations)

INFO 09:33:35,828 Completed flushing d:\cassandra\data\system\LocationInfo-f-2-Data.db (163 bytes)

INFO 09:33:35,843 Will not load MX4J, mx4j-tools.jar is not in the classpath

INFO 09:33:35,890 Binding thrift service to localhost/127.0.0.1:9160

INFO 09:33:35,890 Using TFastFramedTransport with a max frame size of 15728640bytes.

INFO 09:33:35,890 Listening for thrift clients...

安装目录文件说明

各个文件或目录介绍如下：

bin：这个目录下包含了启动 Cassandra 以及客户端相关操作的可执行文件，包括 query language shell（cqlsh）以及命令行界面（CLI）等客户端。同时还包含运行 nodetool 的相关脚本，操作 SSTables 的工具等等。

conf：这个目录下面包含了 Cassandra 的配置文件。必须包含的配置文件包括：assandra.yaml 以及 logback.xml，这两个文件分别是运行 Cassandra 必须包含的配置文件以及日志相关配置文件。同时还包含 Cassandra 网络拓扑配置文件等。

doc：这个目录包含 CQL 相关的 html 文档。

interface：这个文件夹下面只包含一个名为 cassandra.thrift 的文件。这个文件定义了基于 Thrift 语法的 RPC API，这个 Thrift 主要用于在 Java, C++, php, Ruby, python, Perl, 以及 C# 等语言中创建相关客户端，但是在 CQL 出现之后，Thrift API 在 Cassandra 3.2 版本开始标记为 deprecated，并且会在 Cassandra 4.0 版本删除。

javadoc：这个文件夹包含使用 JavaDoc 工具生成的 html 文档。

lib：这个目录包含 Cassandra 运行时需要的所有外部库。

pylib：这个目录包含 cqlsh 运行时需要使用的 Python 库。

tools：这个目录包含用于维护 Cassandra 节点的相关工具。

NEWS.txt：这个文件包含当前及之前版本的 release notes 相关信息。

CHANGES.txt：这个文件主要包含一些 bug fixes 信息。

功能特性

1、弹性可扩展（Elastic Scalability）

可扩展性是指系统架构可以让系统提供更多的服务而不降低使用性能的特性。仅仅通过给现有的机器增加硬件的容量、内存进行垂直扩展，是最简单的达到可扩展性的手段。而水平扩展则需要增加更多机器，每台机器提供全部或部分数据，这样所有主机都不必负担全部业务请求。但软件自己需要有内部机制来保证集群中节点间的数据同步。

弹性可扩展是指水平扩展的特性，意即你的集群可以不间断的情况下，方便扩展或缩减服务的规模。这样，你就不需要重新启动进程，不必修改应用的查询，也无需自己手工重新均衡数据分布。在 Cassandra 里，你只要加入新的计算机，Cassandra 就会自动地发现它并让它开始工作。

2、分布式和去中心化（Distributed and Decentralized）

Cassandra 是分布式的，这意味着它可以运行在多台机器上，并呈现给用户一个一致的整体。事实上，在一个节点上运行 Cassandra 是没啥用的，虽然我们可以这么做，并且这可以帮助我们了解它的工作机制，但是你很快就会意识到，需要多个节点才能真正了解 Cassandra 的强大之处。它的很多设计和实现让系统不仅可以在多个节点上运行，更为多机架部署进行了优化，甚至一个 Cassandra 集群可以运行在分散于世界各地的数据中心上。你可以放心地将数据写到集群的任意一台机器上，Cassandra 都会收到数据。

对于很多存储系统（比如 mysql, Bigtable），一旦你开始扩展它，就需要把某些节点设为主节点，其他则作为从节点。但 Cassandra 是无中心的，也就是说每个节点都是一样的。与主从结构相反，Cassandra 的协议是 P2P 的，并使用 gossip 来维护存活或死亡节点的列表。关于 gossip 可以参见分布式原理：一文了解 Gossip 协议

去中心化这一事实意味着 Cassandra 不会存在单点失效。Cassandra 集群中的所有节点的功能都完全一样，所以不存在一个特殊的主机作为主节点来承担协调任务。有时这被叫做服务器对称（server symmetry）。

综上所述，Cassandra 是分布式、无中心的，它不会有单点失效，所以支持高可用性。

3、可调节的一致性（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；但是不推荐你这么设置。

4、高可用和容错（High Availability and Fault Tolerance）

从一般架构的角度来看，系统的可用性是由满足请求的能力来量度的。但计算机可能会有各种各样的故障，从硬件器件故障到网络中断都有可能。如何计算机都可能发生这些情况，所以它们一般都有硬件冗余，并在发生故障事件的情况下会自动响应并进行热切换。对一个需要高可用的系统，它必须由多台联网的计算机构成，并且运行于其上的软件也必须能够在集群条件下工作，有设备能够识别节点故障，并将发生故障的中端的功能在剩余系统上进行恢复。

Cassandra 就是高可用的。你可以在不中断系统的情况下替换故障节点，还可以把数据分布到多个数据中心里，从而提供更好的本地访问性能，并且在某一数据中心发生火灾、洪水等不可抗灾难的时候防止系统彻底瘫痪。

5、面向行（Row-Oriented）

Cassandra 经常被看做是一种面向列（Column-Oriented）的数据库，这也并不算错。它的数据结构不是关系型的，而是一个多维稀疏哈希表。稀疏（Sparse）意味着任何一行都可能会有一列或者几列，但每行都不一定（像关系模型那样）和其他行有一样的列。每行都有一个唯一的键值，用于进行数据访问。所以，更确切地说，应该把 Cassandra 看做是一个有索引的、面向行的存储系统。

Cassandra 的数据存储结构基本可以看做是一个多维哈希表。这意味着你不必事先精确地决定你的具体数据结构或是你的记录应该包含哪些具体字段。这特别适合处于草创阶段，还在不断增加或修改服务特性的应用。而且也特别适合应用在敏捷开发项目中，不必进行长达数月的预先分析。对于使用 Cassandra 的应用，如果业务发生变化了，只需要在运行中增加或删除某些字段就行了，不会造成服务中断。

当然，这不是说你不需要考虑数据。相反，Cassandra 需要你换个角度看数据。在 RDBMS 里，你得首先设计一个完整的数据模型，然后考虑查询方式，而在 Cassandra 里，你可以首先思考如何查询数据，然后提供这些数据就可以了。

6、灵活的模式（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 当前状态的最佳方式可能是它支持灵活的模式。

7、高性能（High Performance）

Cassandra 在设计之初就特别考虑了要充分利用多处理器和多核计算机的性能，并考虑在分布于多个数据中心的大量这类服务器上运行。它可以一致而且无缝地扩展到数百台机器，存储数 TB 的数据。Cassandra 已经显示出了高负载下的良好表现，在一个非常普通的工作站上，Cassandra 也可以提供非常高的写吞吐量。而如果你增加更多的服务器，你还可以继续保持 Cassandra 所有的特性而无需牺牲性能。

Cassandra 的应用场景

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

大规模部署

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

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

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

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

考虑一下你的应用的读写比例，Cassandra 是为优异的写吞吐量而特别优化的。

许多早期使用 Cassandra 的产品都用于存储用户状态更新、社交网络、建议/评价以及应用统计等。这些都是 Cassandra 很好的应用场景，因为这些应用大都是写多于读的，并且更新可能随时发生并伴有突发的峰值。事实上，支撑应用负载需要很高的多客户线程并发写性能，这正是 Cassandra 的主要特性。

根据项目的 wiki，Cassandra 已经被用于开发了多种不同的应用，包括窗口化的时间序列数据库，用于文档搜索的反向索引，以及分布式任务优先级队列。

地区分布

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

变化的应用

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

为什么会诞生 Apache Cassandra

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 项目提供了相关支持，并引领其发展。