Cassandra个人学习笔记总结

Cassandra学习笔记

---李鑫(lixin.storm@https://www.360docs.net/doc/1e3379588.html,) 一、Cassandra 1.0的新特性：

1：列簇压缩。（这是此项目开始以来呼声最高的需求），可以有效提升系统的存储能力，提高读取效率。

2：增强的内存和硬盘空间管理

3：可调整的压缩策略。提出了一种新的有创造性的压缩算法。这种算法可以作用于每一列。4：允许将Cassandra安装为Windows系统服务。通过如下命令行

bin\cassandra.bat install

获得从Windows系统服务中移除:

bin\cassandra.bat uninstall

5：对写一致性的增强及效率提升

提供了对hinted handoff的2种增强方式：

◆Hint data数据存储的更有效率，有效降低了临时存储Hint data的那些节点的

加载压力

◆在原来的“失效检测”中存在一个窗口期，会导致数据写失败。目前新版本中

对Hint data数据的存储无需等到失效节点被标记为“失效”。

这意味着运行全节点修复以调和“写错误”不再是必须的了（但节点修复依然还是推荐周期性进行，仅仅在多节点同步失败或整个节点的数据都被破坏情况下才是必须的，而这两种情况均是小概率事件）。基于这个改进，数据修复的概率从100%降低到了10%。这将极大提升整个集群的数据吞吐率。（减少了“读修复”）。

二、DataStax OpsCenter

一个基于Web的Cassandra的图形化管理和监控工具，采用Python开发。注意：DataStax OpsCenter在MacOS目前不支持，其仅仅支持Linux平台。

在Linux下可以通过wget命令来获取相关的安装包，如下：

$ wget https://www.360docs.net/doc/1e3379588.html,/community/dsc-cassandra-1.0.5-bin.tar.gz

$ wget https://www.360docs.net/doc/1e3379588.html,/community/dsc-1.0.1-demo-bin.tar.gz

$ wget https://www.360docs.net/doc/1e3379588.html,/community/opscenter-1.3.1-free.tar.gz

解压这些分发包：

$ tar -xzvf dsc-cassandra-1.0.5-bin.tar.gz

$ tar -xzvf dsc-1.0.1-demo-bin.tar.gz

$ tar -xzvf opscenter-1.3.1-free.tar.gz

$ rm *.tar.gz

三、Cassandra集群部署规划

在规划正式生产环境中的Cassandra集群部署时，首先必须考虑计划存储的数据量，以及前端主要应用系统常态情况及极值情况下的负载(读/写)压力。

硬件选择：

对任何应用系统而言，合理的硬件资源选择往往意味着在内存、CPU、硬盘、网络这4项基础资源中通盘考虑并获取一个最佳的配置平衡。

内存：

Cassandra节点拥有越多的内存，集群的读取性能越优秀。更多的内存允许更大的缓存大小,同时也能减少磁盘I / O读。更多的内存也允许设置更大的内存表(memtables)来存储最近的读取的数据，这将有效减少在一次读过程中扫描及读取的文件（索引文件、SSTable文件等）。在正式生产环境中单节点采用8GB~16GB是普遍现象，建议最低不低于4GB内存，目前有部分生产集群采用32GG或更高的内存配置。理想的内存配置往往取决于频繁读取中的数据流大小。

CPU：

在实际应用Cassandra集群的系统中，“写频繁”的应用往往在达到内存的处理极限之前其CPU已经不堪重负了。Cassandra的高并发特性决定了其将直接受益于更多的处理器数量。目前，拥有8个CPU内核的节点通常能提供最好的性价比。而在虚拟服务平台上，我们可以考虑使用云服务提供商，他们往往拥有密度更高的处理器单元，能提供更强大的处理能力。（比如纽约时报就租用亚马逊的云服务平台来处理所有历史报纸的扫描件的解析存储工作）。

硬盘：

选择硬盘的两个重要依据是：容量（有多少数据要存储）及I/O（读写吞吐率）。存储方面的优化将有效减少昂贵的SATA硬盘数量，并能够通过扩展节点来增强集群的存储能力及I/O性能（当然这往往也意味着更多的内存投入）。

固态硬盘（SSDs）也是Cassandra集群的一个有效替代选择。基于SSDs，并配合Cassandra 的“顺序流”的写模式将能极大降低对写入效率的不良影响。

Cassandra通过两个操作将数据持久化到硬盘中：它首先先将“写入数据”附加到内存中的Commit Log中，并周期性的将内存中的数据顺序刷新到硬盘，写入SSTable（列簇数据

的存储文件）中。强烈推荐为CommitLog和SSTables文件采用不同的磁盘存储。CommitLog 并不需要太多的存储空间，但其能有有效平衡你的写入负载压力。数据目录不仅要满足存储持久数据的要求，同时也要有足够的吞吐率以满足可以意料到的数据“读取”压力、数据“写入”和压缩的I/O需求。

Cassandra在运行后台的数据压缩及数据修复操作时，硬盘利用率往往会临时增长到实际数据目录容积的2倍多。因此，建议在每个节点中实际使用的容量不要超过磁盘最大容量的50%。

同时考虑磁盘故障影响及数据冗余需求，有两个合适的搭配方式：

●存储采用RAID0，通过Cassandra的数据备份机制来解决硬盘故障的影响。一

旦某个节点的磁盘出现故障，我们可以通过Cassandra的修复操作来自动找回

失去的数据。

●存储采用RAID10，这样可以通过纯粹硬件上的水平扩展来解决单个磁盘的故

障，这种架构下可以关闭Cassandra的自动备份操作。

如果在磁盘存储方面由足够的投资，推荐采用RAID10，这样可以减少Cassandra副本备份策略所带来的额外存储操作，减少网络负载。反之，则推荐采用RAID0。

网络：

Cassandra是一个分布式数据存储平台，它基于网络来处理读/写请求，同时通过网络来进行节点间的数据备份。Cassandra对副本数据的选择策略是，同机架上节点的优先于不同机架上的节点。同个数据中心的节点优于不同数据中心的节点。

Cassandra使用如下端口，在实际生产环境中如果存在防火墙，必须确保同一集群中的节点

容量规划

本节所介绍的方法可以作为在Cassandra集群中进行数据容积估算的参考。为了更好的估算，我们首先要对我们在Cassandra中所操作的数据有一个客观全面的了解。同时我们也需要知道我们准备在cassandra中如何构建数据的存储模型（列簇的划分、行集、每行多少列，等等…）

可用磁盘容量计算

计算你的Cassandra集群节点们能管理多大的数据量，同时计算每个节点的可用磁盘容量，并将所有节点的容量进行叠加。要谨记，在实际生产集群中，Commit Log和实际数据目录（data directories）务必被存储在不同的磁盘上。以下公式可以用于存储最小可用容量的估算。

让我们首先计算我们的磁盘的原始容量：

原始容积=硬盘大小*硬盘数量

算上硬盘格式化所需的文件系统开销及我们所使用的磁盘阵列的层级模式，比如，假设我们使用的是RAID10模式，则容积计算公式如下：

(原始容积* 0.9) / 2 = 数据可用的磁盘空间

在日常操作中，Cassandra进行数据压缩和修复操作都需要消耗一定的磁盘空间，为了平衡性能要求和集群稳定性，强烈推荐你给你的磁盘空间留出一定的余地，仅使用少于50%的可用磁盘空间，时刻记住这一点，我们可以采用如下公式计算实际使用的空间：数据可用的磁盘空间* 0.5 = 实际使用的磁盘空间

用户数据规模计算

和所有的存储系统类似，原始数据一旦进入Cassandra中存储，由于存储开销的影响，其存储容积往往要大于原始数据大小。一般来说，入库后将膨胀到原始大小的两倍。具体膨胀多少还依赖于系统所使用的字符集及，以下内容可以用于磁盘存储数据的估算（内存临时数据的容量计算不在本节讨论范围中）。

列开销- 每一个列在Cassandra中占用15个字节的开销。因为列簇（Column Family）中的每一行都可以拥有大量不同的列及不同的列名，每一列的元数据都需要被存储起来。对于counter columns及被设置了生命周期的columns，还需要额外的8字节的定义开销（共23字节的额外开销）。因此计算一个正常列的开销的公式如下：

column总长度 = column名称长度 + column值长度 + 15字节行开销- 和列类似，每一行也需要占用23字节的开销。

主键索引开销- 每个列簇同样包含一个行集的主键索引，在我们拥有大量“窄行”的情况下，主键索引尤其重要（不用遍历整个数据集）,采用以下公式可以大概估算主键索引所占用的空间：

主键索引 = 行总数 * (32 + 主键大小的均值)

复制开销–备份策略中的复制数因子在磁盘容量使用方面扮演了一个重要角色。如果复制数因子为1，则系统没有额外的复制开销（集群中只有一份数据），一旦复制数因子大于1，可以用如下公式计算复制开销：

复制开销 = 总数据大小 * (复制数因子 - 1)

节点配置选择的合理选择

规划Cassandra集群配置的一个主要工作就是理解并合理设置各个节点的配置参数。本小节将解释针对单节点、多节点、多数据中心而言，在集群中可以采用哪些部署配置。

本节所提及的配置属性均可在cassandra.yaml这个配置文件中找到，每个集群节点均必须在启动前进行正确的配置。

存储设定：

缺省情况下，每个节点的数据存储路径被设置为/var/lib/cassandra。在实际生产集群部署中，, 我们必须修改commitlog_directory和data_file_directories这两个参数所指定的路径，以保证日志文件目录和数据文件目录在不同的磁盘存储中。

Gossip设定：

Gossip设置用来指定集群中节点的通信模式及节点如何被集群所识别。

清除节点的Gossip状态

每个节点都可以自动缓存Gossip状态信息，并在下次重启中自动加载，而不必等待Gossip服务的回复。可以在cassandra-env.sh脚本文件中添加如下定义来强制清除缓存的Gossip状态：

-Dcassandra.load_ring_state=false

cassandra-env.sh文件一般位于/usr/share/cassandra目录或$CASSANDRA_HOME/conf目录中。

分区器设置：

在实际生产环境中，我们要确保集群中的每个节点存储的数据量大体相等，这就是所谓的“负载平衡”。负载平衡是通过在每个节点中配置分区器（partitioner）并正确合理的设置initial_token的值来实现的。

强烈推荐在所有集群中采用RandomPartitioner分区器（同时它也是默认配置），基于此配置，集群中的每个节点都会被分配一个0~2**127的hash值。

对于所有节点都在同一个数据中心的Cassandra集群而言，我们可以在集群中的节点总数中换分范围来获得token值。在多数据中心的部署中，每个数据中心必须单独考虑负载平衡。多数据中心及单数据中心的不同tokens值的分配方式可以在Calculating Tokens中获得详细信息。

Snitch设置：

Snitch能够帮助你获取你在网络拓扑结构中所处的位置。它直接影响副本放置的位置以及副本间的请求路由。endpoint_snitch属性将配置节点的Snitch属性。所有节点的Snitch配置都必须一致。

对于单数据中心的集群而言，使用SimpleSnitch策略即可满足要求。但如果我们将在未来将我们的集群扩展为多机架多数据中心的话，一开始就设置每个节点所在的机架及数据中心会让事情更简单一些。

配置PropertyFileSnitch：

PropertyFileSnitch要求我们在cassandra-topology.properties配置文件中定义每个节点的详细网络信息。

如下内容是此文件的一个配置实例，其中表示共有两个数据中心，每个数据中包含了两

在以上的snitch配置中，你可以任意定义你的数据中心和机架的名称。但必须确保cassandra-topology.properties配置文件中的名称和你在keyspace strategy_options定义中所用的名称是一致的。

四、节点通信（Gossip）

Gossip是一种对等通信协议。在Cassandra中，gossip通信进程每秒都会运行，以交换节点之间以及他们所知的其它节点的状态信息。每个gossip消息都有一个版本。

每个节点都会将自身的token通过gossip通知给其它节点，每个节点都必须知道集群中所有节点各自对应的token，这样才能均衡的分配相关的存储数据。

在Cassandra中，可以通过调整“phi_convict_threshold”参数来调整基于内部Gossip通信的失效检测灵敏度。它的缺省值对绝大部分环境都是适用的，不用修改。但如果使用的是“Amazon EC2”集群的话，我们推荐将这个值调整到12，以适应频繁拥堵的网络环境。

一个节点就算失效了，其它节点也会周期性的尝试联系它，以确认它是否恢复正常，要永久性的移除一个节点，可以通过Cassandra提供的nodetool工具来进行。

一旦节点的失效时间超出“max_hint_window_in_ms”所定义的时长（默认是一个小时），则关于它的hints数据将不再被存储，因此，最好周期性的在所有节点上运行“nodetool

repaire”以保证每个副本节点有一致的数据。同样的，一旦某一个节点停止运行很长一段时间的话，重新加入集群后也最好重新运行“nodetool repaire”。

附:Gossip算法学习

1. 概述

gossip，顾名思义，类似于流言传播的概念，是一种可以按照自己的期望，自行选择与之交换信息的节点的通信方式

gossip, or anto-entropy, is an attractive way of replicating state that does not have strong consistency requirements

2. 算法描述

假设有{p, q, ...} 为协议参与者。每个参与者都有关于一个自己信息的表。

用编程语言可以描述为：

记InfoMap = Map，那么每个参与者要维护一个InfoMap 类型的变量localInfo。同时每一个参与者要知道所有其他参与者的信息, 即要维护一个全局的表，即Map 类型的变量globalMap。每个参与者更新自己的localInfo，而由Gossip 协议负责将更新的信息同步到整个网络上。

每个节点和系统中的某些节点成为peer (如果系统的规模比较小，和系统中所有的其他节点成为peer)。有三种不同的同步信息的方法：

1）push-gossip: 最简单的情况下，一个节点p 向q 发送整个GlobalMap

2）pull-gossip: p 向q 发送digest, q 根据digest 向p 发送p 过期的(key, (value, version)) 列表

3）push-pull-gossip:与pull-gossip类似，只是多了一步，A再将本地比B新的数据推送给B，B更新本地

3. 特点

gossip不要求节点知道所有其他节点，因此具有去中心化的特点，节点之间完全对等，不需要任何的中心节点。

gossip算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了Gossip的特点：

在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻节点，只要这些节可以通过网络连通，最终他们的状态都是一致的。

gossip算法是一个最终一致性算法，其无法保证在某个时刻所有节点状态一致，但可以保证在”最终“所有节点一致，”最终“是一个现实中存在，但理论上无法证明的时间点4. 协调机制

协调机制是讨论在每次2个节点通信时，如何交换数据能达到最快的一致性，也即消除两个节点的不一致性。

协调所面临的最大问题是，因为受限于网络负载，不可能每次都把一个节点上的数据发送给另外一个节点，也即每个Gossip的消息大小都有上限。在有限的空间上有效率地交换所有的消息是协调要解决的主要问题。

“Efficient Reconciliation and Flow Control for Anti-Entropy Protocols”中描述了两种同步机制

1）precise reconciliation

precise reconciliation希望在每次通信周期内都非常准确地消除双方的不一致性，具体表现为相互发送对方需要更新的数据，因为每个节点都在并发与多个节点通信，理论上很难

做到。precise reconciliation需要给每个数据项独立地维护自己的version，在每次交互是把所有的(key,value,version)发送到目标进行比对，从而找出双方不同之处从而更新。但因为Gossip消息存在大小限制，因此每次选择发送哪些数据就成了问题。当然可以随机选择一部分数据，也可确定性的选择数据。对确定性的选择而言，可以有最老优先（根据版本）和最新优先两种，最老优先会优先更新版本最新的数据，而最新更新正好相反，这样会造成老数据始终得不到机会更新，也即饥饿。

2）Scuttlebutt Reconciliation

Scuttlebutt Reconciliation 与precise reconciliation不同之处是，Scuttlebutt Reconciliation 不是为每个数据都维护单独的版本号，而是为每个节点上的宿主数据维护统一的version。比如节点P会为(p1,p2,...)维护一个一致的全局version，相当于把所有的宿主数据看作一个整体，当与其他节点进行比较时，只需比较这些宿主数据的最高version，如果最高version 相同说明这部分数据全部一致，否则再进行precise reconciliation。

5. Merkle tree

信息同步无疑是gossip的核心，Merkle tree(MT)是一个非常适合同步的数据结构。

简单来说Merkle tree就是一颗hash树，在这棵树中，叶子节点的值是一些hash值、非叶节点的值均是由其子节点值计算hash得来的，这样，一旦某个文件被修改，修改时间的信息就会迅速传播到根目录。需要同步的系统只需要不断查询跟节点的hash，一旦有变化，顺着树状结构就能够在logN级别的时间找到发生变化的内容，马上同步。

在Dynamo中，每个节点保存一个范围内的key值，不同节点间存在有相互交迭的key 值范围。在去熵操作中，考虑的仅仅是某两个节点间共有的key值范围。MT的叶子节点即是这个共有的key值范围内每个key的hash，通过叶子节点的hash自底向上便可以构建出一颗MT。Dynamo首先比对MT根处的hash，如果一致则表示两者完全一致，否则将其子节点交换并继续比较的过程。

6.总结

Gossip常见于大规模、无中心的网络系统，可以用于众多能接受“最终一致性”的领域：失败检测、路由同步、Pub/Sub、动态负载均衡。

7.参考文献

paper：Efficient Reconciliation and Flow Control for Anti-Entropy Protocols

https://www.360docs.net/doc/1e3379588.html,/1081650/530743

https://www.360docs.net/doc/1e3379588.html,/index.php/2010/09/12/merkle-tree/

五、Cassandra中的数据分区

在单个数据中心中给每个节点创建Tokens的方法：

1.创建一个新的空文件：

vi tokengentook

3.保存并关闭文件后，将文件设置为可执行:

Chmod +x tokengentool

4.运行这个脚本文件：

./tokengentool

6.编辑集群中每个节点的cassandra.yaml文件，并给initial_token属性设置对应的合适的值。

下面是一个样例：

node0

cluster_name: 'MyDemoCluster'

initial_token: 0

seed_provider:

- seeds: "110.82.155.0,110.82.155.3"

listen_address: 110.82.155.0

rpc_address: 0.0.0.0

endpoint_snitch: RackInferringSnitch

node1

cluster_name: 'MyDemoCluster'

initial_token: 28356863910078205288614550619314017621

seed_provider:

- seeds: "110.82.155.0,110.82.155.3"

listen_address: 110.82.155.1

rpc_address: 0.0.0.0

endpoint_snitch: RackInferringSnitch

node2

cluster_name: 'MyDemoCluster'

initial_token: 56713727820156410577229101238628035242

seed_provider:

- seeds: "110.82.155.0,110.82.155.3"

listen_address: 110.82.155.2

rpc_address: 0.0.0.0

endpoint_snitch: RackInferringSnitch

node3

cluster_name: 'MyDemoCluster'

initial_token: 85070591730234615865843651857942052864

seed_provider:

- seeds: "110.82.155.0,110.82.155.3"

listen_address: 110.82.155.3

rpc_address: 0.0.0.0

endpoint_snitch: RackInferringSnitch

node4

cluster_name: 'MyDemoCluster'

initial_token: 113427455640312821154458202477256070485

seed_provider:

- seeds: "110.82.155.0,110.82.155.3"

listen_address: 110.82.155.4

rpc_address: 0.0.0.0

endpoint_snitch: RackInferringSnitch

node5

cluster_name: 'MyDemoCluster'

initial_token: 141784319550391026443072753096570088106

seed_provider:

- seeds: "110.82.155.0,110.82.155.3"

listen_address: 110.82.155.5

rpc_address: 0.0.0.0

endpoint_snitch: RackInferringSnitch

Calculating Tokens for a Multi-Data Center Cluster：

In multi-data center deployments, replica placement is calculated per data center using the NetworkTopologyStrategy replica placement strategy. In each data center (or replication group) the first replica for a particular row is determined by the token value assigned to a node. Additional replicas in the same data center are placed by walking the ring clockwise until it reaches the first node in another rack.

If you do not calculate partitioner tokens so that the data ranges are evenly distributed for each data center, you could end up with uneven data distribution within a data center. The goal is to ensure that the nodes for each data center are evenly dispersed around the ring, or to calculate tokens for each replication group individually (without conflicting token assignments).

One way to avoid uneven distribution is to calculate tokens for all nodes in the cluster, and then alternate the token assignments so that the nodes for each data center are evenly dispersed around the ring.

Another way to assign tokens in a multi data center cluster is to generate tokens for the nodes in one data center, and then offset those token numbers by 1 for all nodes in the next data center, by 2 for the nodes in the next data center, and so on. This approach is good if you are adding a data center to an established cluster, or if your data centers do not have the same number of nodes.

六、Cassandra的数据模型

副本复制的控制是以keyspaces为基础的，因此，有不同副本复制需求的数据应该被放在不同的keyspaces中，cassandra中的keyspaces被设计来最主要的用途就是控制一组column families的数据副本复制。

计数器列（Counter Column）:

Super column:

要获得超级列中某个子列的值，必须把整个超级列取出。

在超级列的子列中无法创建二级索引。

超级列最适合使用的场景是：子列数量相对少。