Cassandra
Cassandra知识梳理
Cassandra 简介
Apache Cassandra是一个开源，分布式和分散/分布式存储系统（数据库），用于管理分布在世界各地的大量结构化数据。它提供高可用性服务，没有单点故障。
- 它具有可伸缩性，容错性和一致性。
- 它是一个面向列的数据库。
- 其分发设计基于亚马逊的Dynamo及其在Google的Bigtable上的数据模型。
- 它创建于Facebook，与关系数据库管理系统截然不同。
- Cassandra实现了Dynamo风格的复制模型，没有单点故障，但是添加了更强大的“column family”数据模型。
- 一些大型公司（例如Facebook，Twitter，Cisco，Rackspace，ebay，Twitter，Netflix等）正在使用Cassandra。
Cassandra特点
以下是Cassandra的一些功能：
- 弹性可扩展性– Cassandra具有高度可扩展性；它允许添加更多硬件，以根据需求容纳更多客户和更多数据。
- 始终在线-Cassandra没有单点故障，并且可以连续用于无法承受故障的关键业务应用程序。
- 快速的线性规模性能-Cassandra具有线性可扩展性，即，随着集群中节点数量的增加，它可以提高吞吐量。因此，它保持了快速的响应时间。
- 灵活的数据存储-Cassandra可容纳所有可能的数据格式，包括：结构化，半结构化和非结构化。它可以根据需要动态适应对数据结构的更改。
- 轻松进行数据分发-Cassandra通过在多个数据中心之间复制数据，提供了在所需位置分发数据的灵活性。
- 事务支持-Cassandra支持原子性，一致性，隔离性和持久性（ACID）等属性。
- 快速写入-Cassandra旨在在廉价的商品硬件上运行。它执行快速的写入，并且可以存储数百TB的数据，而不会牺牲读取效率
Cassandra应用场景
- 社交媒体：用户状态更新频繁场景；点赞、评论、转发
-
物联网：设备状态更新；行程轨迹；视频监控；
-
互联网/电商/娱乐/教育：用户元数据；商品品类信息；商品详情；浏览记录；监控日志；
-
金融风控：用户画像；标签；圈人；事件流；
Cassandra架构
集群架构
Cassandra集群由成节点(Node)、机架(Rack)和数据中心(Data Center)组成。
- 节点(Node)
指运行Cassandra实例的服务器。节点可以是物理主机、云上的机器实例，或者是Docker容器。 - 机架(Rack)
指一组相互靠近的Cassandra节点。机架可以是包含连接到公共网络交换机节点的物理机架。在云端，机架通常指在同一可用区域中运行机器实例集合。 - 数据中心(Data Center)
指逻辑机架的集合，通常位于同一栋建筑中，通过可靠的网络连接。在云端，数据中心通常映射到云区域。如阿里云上的华北1区，华南2区。
一致性Hash
实现数据的分区分布和扩容缩容的数据迁移
Gossip内部通信协议
Cassandra使用Gossip的协议维护集群的状态， 在对等节点的网络传播下保持集群状态一致性，这是个端对端的通信协议。通过Gossip，每个节点都能知道集群中包含哪些节点，以及这些节点的状态，
反熵机制
利用anti-entropy(反熵)机制实现数据读取过程中节点之间的比对，保证数据一致性
可调一致性
hinted handoff机制：按照最终一致性的模式，可以极大提升集群可用性
Cassandra数据存储
Cassandra的数据包括在内存中的和磁盘中的数据
这些数据主要分为三种： CommitLog：主要记录客户端提交过来的数据以及操作。这种数据被持久化到磁盘中，方便数据没有被持久化到磁盘时可以用来恢复。 Memtable：用户写的数据在内存中的形式，它的对象结构在后面详细介绍。其实还有另外一种形式是BinaryMemtable 这个格式目前 Cassandra 并没有使用，这里不再介绍了。 SSTable：数据被持久化到磁盘，这又分为 Data、Index 和 Filter 三种数据格式。
CommitLog 数据格式
Cassandra在写数据之前，需要先记录日志，保证Cassandra在任何情况下宕机都不会丢失数据，这就是CommitLog日志。要写入的数据按照一定格式组成 byte 组数，写到 IO 缓冲区中定时的被刷到磁盘中持久化。Commitlog是server级别的。每个Commitlog文件的大小是固定的，称之为一个CommitlogSegment。
当一个Commitlog文件写满以后，会新建一个的文件。当旧的Commitlog文件不再需要时，会自动清除。
Memtable 内存中数据结构
数据写入的第二个阶段，MemTable是一种内存结构，当数据量达到块大小时，将批量flush到磁盘上，存储为SSTable。优势在于将随机IO写变成顺序IO写，降低大量的写操作对于存储系统的压力。每一个columnfamily对应一个memtable。也就是每一张表对应一个。用户写的数据在内存中的形式，
SSTable 数据格式
SSTable是Read Only的，且一般情况下，一个ColumnFamily会对应多个SSTable，当用户检索数据时，Cassandra使用了Bloom Filter，即通过多个hash函数将key映射到一个位图中，来快速判断这个key属于哪个SSTable。
为了减少大量SSTable带来的开销，Cassandra会定期进行compaction，简单的说，compaction就是将同一个ColumnFamily的多个SSTable合并成一个SSTable。
在Cassandra中，compaction主要完成的任务是：
1） 垃圾回收： cassandra并不直接删除数据，因此磁盘空间会消耗得越来越多，compaction 会把标记未删除的数据真正删除；
2） 合并SSTable：compaction 将多个 SSTable 合并为一个（合并的文件包括索引文件，数据文件，bloom filter文件），以提高读操作的效率；
3） 生成 MerkleTree：在合并的过程中会生成关于这个ColumnFamily中数据的 MerkleTree，用于与其他存储节点对比以及修复数据。
每个SSTables是由多个组件存储在单个文件中：
- Data.db：实际的数据。
- Index.db：来自分区key的索引，定位到data.db文件，因此在大的分区中，也会包含分区行的索引。
- Summary.db：摘要，分区键的内容。
- Filter.db：Bloom过滤器在SSTable的分区key。
- CompressionInfo.db：关于偏移量和在data.db文件压缩的块长度的元数据。
- Statistics.db：存储SSTable的元数据，包括时间戳、tombstones、集群键、压缩率、修复等还有更多的信息。
- Digest.crc32： CRC-32算法的data.db文件。
- TOC.txt：SSTable组件文件的简单的列表。
LSM-Tree（Log-Structured-Merge-Tree） 日志结构合并树
Cassandra操作
CREATE KEYSPACE IF NOT EXISTS test WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : '0' };
DESCRIBE keyspaces;
DESCRIBE KEYSPACE test;
USE tutorial;
CREATE TABLE IF NOT EXISTS tutorial
(
id timeuuid PRIMARY KEY,
title text,
description text,
published boolean
);
DESCRIBE table tutorial;
insert into test.tutorial (id,title,description,published) values (now(),'title1','description1',true);
|
Cassandra备份与恢复
复制策略
Cassandra使用复制策略来存储和维护数据的多个副本。每个分区都有一个主分区副本和多个备份分区副本，可以根据需要进行配置。数据复制可以保证数据的高可用性和灾难恢复。
数据备份
Cassandra提供了多种数据备份方法，包括手动备份和自动备份。手动备份可以通过CQL命令或命令行工具进行，自动备份可以通过设置定期备份的时间间隔和备份文件路径来实现。
数据恢复
Cassandra提供了多种数据恢复方法，包括手动恢复和自动恢复。手动恢复可以通过CQL命令或命令行工具进行，自动恢复可以通过设置自动恢复选项来实现。
增量备份
Cassandra支持增量备份，只备份发生变化的部分，可以提高备份效率和减少备份文件大小。
Cassandra与HBase
|
对比项 |
Cassandra |
HBase |
|
一致性 |
可调一致性（AP）：在读取过程中完成最终一致性 |
强一致性（CP）：数据写入时强一致性 |
|
可用性 |
1，基于Consistent Hash相邻节点复制数据，数据存在于多个节点，无单点故障。 2，某节点宕机，hash到该节点的新数据自动路由到下一节点做 hinted handoff，源节点恢复后，推送回源节点。 3，通过Gossip协议维护集群所有节点的健康状态，并发送同步请求，维护数据一致性。 4，SSTable，纯文件，单机可靠性一般。 |
1，存在单点故障，Region Server宕机后，短时间内该server维护的region无法访问，等待failover生效。 2，通过Master维护各Region Server健康状况和Region分布。 3，多个Master，Master宕机有zookeeper的paxos投票机制选取下一任Master。Master就算全宕机，也不影响Region读写。Master仅充当一个自动运维角色。 4，HDFS为分布式存储引擎，一备三，高可靠，0数据丢失。 5，HDFS的namenode是一个SPOF。 |
|
伸缩性 |
1，Consistent Hash，快速定位数据所在节点。 2，扩容需在Hash Ring上多个节点间调整数据分布。 |
1，通过Zookeeper定位目标Region Server，最后定位Region。 2，Region Server扩容，通过将自身发布到Master，Master均匀 分布。 |
|
读写性能 |
数据读写定位非常快。 |
数据读写定位可能要通过最多6次的网络RPC，性能较低。 |
|
可维护性 |
架构无中心化，维护成本低。 新增keyspace需要重启整个集群。 |
组件过多，架构复杂，维护成本较高。 但是删除表非常方便。 |
|
二级索引 |
支持 |
不支持 |
|
锁与事务 |
Client Timestap（Dynamo使用vector lock） |
Optimistic Concurrency Control |
|
map/reduce |
支持不是很好 |
1，通过Zookeeper定位目标Region Server，最后定位Region。 2，Region Server扩容，通过将自身发布到Master，Master均匀 分布。 |
|
存储 |
LSM-Tree、本地磁盘 |
LSM-Tree、HDFS |
|
分布式架构 |
去中心化，节点无差异，支持集群没有HBase大 |
中心化，分HMaster和HReginServer节点，支持超大集群 |
|
SQL支持 |
良好，CQL语法较为全面，但不支持join |
比较差 |
|
使用场景 |
OLTP--联机事务处理 |
OLAP--联机分析处理 |
|
小结 |
1，弱一致性，数据可能丢失。AP 2，可用性高。 3，扩容方便。 4，如果不需要map/reduce的话，维护相当简单 |
1，强一致性，0数据丢失。CP 2，可用性低。 3，扩容方便。 4，组件过多，架构复杂，维护成本较高。 |
Cassandra小结
-
运维容易，机器成本低，适合小规模集群应用，可用快速支撑海量数据查询业务
-
高可用，高TPS随机读取，支持海量数据，支持CQL、支持二级索引，适合部分场景代替MySQL
- 不适合一致性要求很高应用场景
