Cassandra实战 笔记-《Cassandra内部数据存储结构》
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Cassandra实战 笔记-《Cassandra内部数据存储结构》相关的知识,希望对你有一定的参考价值。
参考技术A Cassandra的配置文件可以对Cassandra中的数据进行配置。cassandra.yaml 中关于存放数据信息的配置如下:数据信息一共分为以下3类:
在data目录下,Cassandra 会将每一个 Keyspace 中的数据存储在不同的文件目录下,并且 Keyspace 文件
目录的名称与 Keyspace 名称相同。
假设有两个 Keyspace,分别为 ks1 和 ks2,但在 data目录下,将看到3个不同的目录:ks1,ks2和 system。其中 ks1 和 ks2 用于存储系统定义的两个 Keyspace 的数据,另外一个 system 目录是 Cassandra 系统默认的一个 Keyspace,叫做 system,它用来存储 Cassandra 系统的相关元数据信息以及 HINT 数据信息。
当 Cassandra 有数据需要更新时,第一个记录这个更新的地方就是 Commitlog。
Commitlog由如下两个部分构成:
CommitLog - xxx.log 、 CommitLog - xxx.log.header 。
在 CommitLog - xxx.log 文件中,保存了每一次更新操作的值。
在 CommitLog - xxx.log.header 文件中,记录了哪些数据已经从 memtable 中写入 SSTable 中。
通过log. header文件中记录的元数据信息, Cassandra 可以及时删除不必要的Commitlog文件,减少磁盘的占用量,并在Cassandra重启时,加快从Commitlog中恢复数据的速度。
Commitlog文件的大小可以在配置文件中指定,默认是128MB。
当一个Commitlog文件大小超过设置的阈值后,将会新建一个Commitlog,并将更新数据写人这个新的文件中。
Cassandra提供了两种记录Commitlog的方式:周期记录( periodic)和批量记录( batch)。如果使用周期记录的方式,需要在配置文件进行如下配置:
Cassandra会每次更新信息将写人 Commitlog 中,并且每隔一定的时间间隔( commitlog-sync_ period in ms )调用 org apache. cassandra. io. util. BufferedRandomAccessFile. syne() 同步 Commitlog 文件。
如果使用批量记录的方式,需要在配置文件进行如下配置:
Cassandra会缓存每次更新信息,每隔一定的时间间隔( commitlog sync_ batch _window_in_ ms )调用 org. apache. cassandra. io. util. BuferedRandomAccessFile. syne () 同步Commitlog 文件,最后将之前缓存的更新信息写人Commitlog中。
如果不允许数据丢失,可以使用周期的方式记录 Commitlog。如果写入数据量非常大,同时可以承担由于机器可能宕机导致的数据丢失的风险,则使用批量记录的方式记录 Commitlog。
在实际的使用中,可以根据情况来选用合适的 Commitlog记录方式。
数据写入 Commitlog 后,将缓存在 Memtable 中。
Cassandra 中每一个 Memetable 只为一个 ColumnFamily 提供服务。
当下面3个条件中任意个满足后,会将Memtable中缓存的数据写入磁盘,形成一个SSTable文件。
上面提到的3个参数都可以在配置文件中进行设置,Cassandra 为每一个ColumnFamily提供单独的配置。
每当有数据进人 Memtable 中时,会将数据保存到成员变量 ColumnFarmilies 中,并解析这个数据,排除重复或者是已经过期的数据。具体实现如下:
当Cassandra需要将Memtable中缓存的数据写人磁盘时,会按照内存中Key的顺序写人SSTable中。
使用 Memtable 的优势在于:将随机 IO 写变为顺序 IO 写,降低大量的写操作对存储系统的压力。
Cassandra 中的 Memtable 会缓存客户端写入的数据,当Memtable中缓存的某一个ColumnFamily中的数据量( 对应配置文件中的 memtable_ throughput_ in mb 和 memtable_ operations_in_ millions 或者超过上一次生成SSTable的时间(对应配置文件中的 memtable flush_ after_mins )后,Cassandra 会将Memtable中对应的ColumnFamily的数据持久化到磁盘中,生成一个SSTable文件。
如ColumnFamily名称为Cfl的一个SSTable文件由如下文件组成:
其中,“Cf1”为ColumnFamily的名称;“e” 为版本的标识(这个标识在0.7之前的版本中是没有的);“1”代表这是名称为Cfl的ColumnFamily的第一个SSTable,这个数字会随着新的SSTable文件的生成不断增加;“Data”、“Filter”、 “Index"和“Statistics" 分别代表 SSTable 4个不同组成部分,它们的作用各不相同。
在Cassandra中,除了用户自己定义的 Keyspace 之外,还有一个特殊的 Keyspace :名称为system的系统表空间。
用户不能在 Cassandra 中创建名为 system 的 Keyspace,只能由 Cassandra 系统自动创建。系统表空间的主要有以下两个作用:
如果系统首次启动,Cassandra 将会自动在data目录下创建系统表空间,并将系统元数据信息存放在系统表空间中。以后启动的过程中,Cassandra 将会直接从系统表空间中读取系统元数据信息。
如果 Cassandra 发现某一个节点宕机,就会将发送给宕机节点的数据以 HINT 的形式发送给另外台 Cassandra 服务器。接收到 HINT 数据的 Cassandra 服务器将数据缓存到系统表空间中,当其发现宕机的 Cassandra 恢复后,将缓存 HINT 数据发送给恢复的服务器,完成数据传输后,将缓存的 HINT 数据从系统表空间中删除。
本章从原理上分析和讲解了 Cassandra 的内部数据存储结构Commitlog、Memtable、SSTable和构成SSTable的4个子文件。了解Cassandra的内部数据存储构造有利于为基于Cassandra的应用程序设计合理的数据模型,以及找出造成读写瓶颈的原因。另外还介绍了Cassandra的系统表空间,了解了整个系统元数据管理的机制。
Cassandra基本介绍 - Cassandra概述
上一节我们介绍RDBMS遇到的问题,这一节我们将介绍Cassandra以及Cassandra是否可以解决此问题。
通过此章节,我们将学习到:
什么是Cassandra
Cassandra数据的Hash分布
Cassandra在CAP中的权衡
Cassandra复制
Cassandra可调一致性
Cassandra多数据中心
什么是Cassandra
Apache Cassandra是一个开源的、分布式、无中心、弹性可扩展、高可用、容错、一致性可调、面向列的数据库,它基于Amazon Dynamo的分布式设计和Google BigTable的数据库,有Facebook创建。总结特点如下:
分布式与无中心
分布式意味着它可以运行在多台机器上,而呈现给用户是一个整体。无中心意味着Cassandra不会存在单点,也就是说每个节点都是一样的,没有节点会承担特殊的管理任务。与master/slave结构相反,Cassandra的协议是P2P的,并使用gossip来维护存活或死亡节点的列表。
ps:gossip算法又被称为反熵(Anti-Entropy),熵是物理学上的一个概念,代表杂乱无章,而反熵就是在杂乱无章中寻求一致,这充分说明了Gossip的特 点:在一个有界网络中,每个节点都随机地与其他节点通信,经过一番杂乱无章的通信,最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点,也可 能仅知道几个邻居节点,只要这些节可以通过网络连通,最终他们的状态都是一致的,当然这也是疫情传播的特点。
高可用与容错
从一般架构的角度看,系统的高可用性是由满足请求的能力来度量的。但计算机可能会有各种各样的故障,从硬件故障到网络中断都有可能。所以对于一个需要高可用的系统,它必须由多台联网的计算机构成,并且运行于其上的软件也必须能够在集群条件下工作,有设备能够识别节点故障,并将发生故障的中断的功能,在剩余系统上进行恢复。 Cassandra就是高可用的。可以在不中断系统的情况下替换故障节点,还可以把数据分布到多个数据中心,从而提供更好的本地访问性能,并且在某一数据中心发生火灾等不可抗拒灾难的时候防止系统彻底瘫痪。线性扩展 由于Cassandra采用P2P协议,可以很容易的进行水平扩展,而且性能也随之线性增长。ACID支持良好 Cassandra的一致性可调:严格一致性 ~ 最终一致性。同时通过CAS(CompareAndSet)来支持轻量级事务。没有SPOF( Single point of failure)容易管理操作 Cassandra很容易进行添加、删除、替换节点等操作。
Cassandra数据的Hash分布
数据围绕着ring来分区
所有的nodes都会存储数据并响应查询(既可以读也可以写)
数据通过分区键(partition key)来定位
Cassandra在CAP中的权衡
在满足partitioning情况下不可能同时满足consistency和highly available
跨数据中心延迟也导致了一致性不现实
Cassandra选择了Availability和partitioning(Cassandra的一致性是可调的)
CA:
主要支持一致性和可用性,这意味着你很有可能需要使用两阶段提交的分布式事务。也就是说,如果网络发生分裂,那么系统可能会停止响应。
AP:
主要支持可用性和分区容错性,意味着你得系统可能返回不太精确的数据,但系统将始终可用。
Cassandra复制
数据是自动复制的,你只需要选择复制服务器的数量。定义复制的数量,我们称之为“replication factor”or RF。
如果一台机器down掉,丢失的数据会通过“提示移交”(hinted handoff)回放。(hinted handoff会在后续课程讲到)
Cassandra可调一致性
每次查询都可以指定一致性级别:ALL,QUORUM,ONE。意味着有多少个副本响应。
Cassandra常被称之为“最终一致性”,这实际上有点让人误解。简单的说,Cassandra牺牲了一点一致性来换取完全的可用性。但是Cassandra实际更应该表述为“可调一致性”,它允许你方便的选择需要的严格一致性和最终一致性,在二者间找到平衡点。
Cassandra多数据中心
典型用例:clients写入本地DC,异步复制到其他DCs
每个数据中心每个keyspace都有复制因子,意味着每个数据中心都是高可用的
数据中心可以是物理的或逻辑的
本文出自 “java架构师之路” 博客,请务必保留此出处http://eric100.blog.51cto.com/2535573/1786942
以上是关于Cassandra实战 笔记-《Cassandra内部数据存储结构》的主要内容,如果未能解决你的问题,请参考以下文章
开源Nosql数据库Cassandra3.0实战-集群部署与插件使用