Apache Cassandra3.X 系列，第 1 部分 Cassnadra3.X 特性概述-1

look_w

本文是 Apache Cassandra3.X 系列的第一篇文章，主要介绍了 Cassandra 的出现原因，它解决了什么问题，3.X 版本对应的数据模型、数据副本方式、系统架构、客户端、应用工具发生了什么变化等内容。
关系型数据困局IMS 的全称是 Information Management System，1966 年由 Vern Watts 在 IBM 提出，最初是为了 Staurn V moon        rocket 项目创造的，最终在 1968 年第一次产品发布，接下来再 CICS（Customer Information Control        System）及其他的应用程序上获得成功，并沿用至今。
1970 年，Edgar F.Codd 博士发表了论文"A Relational Model for Data for Large Shared Data        Banks"，奠定了关系型数据库管理系统的功能基础。
那么，关系型数据库犯了什么错误？答案是：“Nothing” 。
为什么需要考虑替换关系型数据库？因为关系型数据库遇到了扩展问题，并且数据表之间的关联关系让查询越来越慢。
相关知识数据模型关系型模型是一个简单的模型，需要满足 ACID。ACID 是 Atomic、Consistent、Isolated、Durable 的简称。

• Atomic："All or Nothing"。
• Consistent：意味着数据从一个正确的状态移动到了另一个正确的状态，不可能读到不同的值。
• Isolated：交易之间不会互相干扰。
• Durable：一旦交易完成，更高的数据不会丢失。

扩展方式一种扩展关系型数据库的方式是 Sharding（分片）架构。eBay 采用这种方式，支持每天数十亿 SQL        访问。这种方式的原理是对数据进行纵向切分，将数据量分派到不同的机器上，这样不需要再在一台机器上存储或者备份所有的数据。
几种分片策略：

• 按照属性或者功能分片：将互相没有强依赖的数据分片在不同的数据库，例如用户表和所购商品表。
• 按照键值分片：按照 orderId 或者第一个字母。
• 查找表：加入一个"黄页"表，查询数据在哪个节点。这里有两点问题，1: 黄页表成为每次都需要访问的表，2: 黄页表本身具有单点失败的可能性。

无中心化Michael Stonebraker（University of California at Berkeley）在 1986 年的论文"The Case for Shared        Nothing."引入了"Shared-Nothing"架构，属于无中心化状态，即每一个节点互相不存在依赖关系，所以没有中心节点统计共享资源内容的问题。
Cassandra 数据库没有中心节点，没有 Master/Slave，是 Shared-Nothing 架构。
初步介绍Apache Cassandra 是一种分布式非关系型数据库，具有高性能、可扩展、无中心化等特征。Cassandra        是适用于社交网络业务场景的数据库，适合实时事务处理和提供交互型数据。以 Amazon 完全分布式的 Dynamo 数据库作为基础，结合 Google BigTable        基于列族（Column Family）的数据模型，实现 P2P 去中心化的存储。
在 CAP 原则（又称 CAP 定理，指的是在一个分布式系统中，Consistency 一致性、Availability 可用性、Partition Tolerance        分区容错性，三者不可得兼）上，HBase 选择了 CP，Cassandra 则更倾向于 AP，所以在一致性上有所减弱。
Cassandra 是无中心化的，意味着所有节点没有差异。
可扩展性一般可以通过两种方式实现：

• 纵向的（Vertical Scaling），即简单地通过增加硬件能力和机器内存实现能力提升。
• 横向的（Horizontal          Scaling），即通过增加机器实现能力提升，这种方式不会存在单一机器具有性能瓶颈的情况，但是这种设计需要软件内部机制在整个集群范围内可以保持各节点之间的数据同步。

所谓的弹性扩展是指特定属性的横向扩展能力，意味着集群内部可以无缝扩展和解散部分机器。要做到这一点，需要集群可以接收新的节点，并且通过拷贝部分或者全部数据的方式加入到集群，并开始接收新的用户请求，而不是需要大规模地调整或者配置整个集群。
与其他方案对比Cassandra 的类 Dynamo 特性有以下几点：

• 对称的，P2P 架构：点对点架构，无中心节点，集群中每一个节点都具有相同地位。
• 基于 Gossip 的分布式管理：通过 Gossip，每个节点都能知道鸡群中包含哪些节点，以及这些节点的状态。
• 通过分布式 hash 表放置数据：在默认分区策略中，每个节点都对应一个 hash 值，用于存储一定范围内的分区键的数据。
• 可插拔的分区：可添加或者删除节点，但是保证数据不会丢失。
• 可配置的放置策略：可配置不同的策略用于分布副本。
• 可配置的一致性：对读写操作均可配置不同的一致性级别。
• Cassandra 的类 BigTable 特性有以下几点：
• 列族数据模型：列族作为列的容器，是一个四维哈希表。
• SSTable 磁盘存储：SSTable 为磁盘上的存储文件，只读，多个 SSTable 可进行合并操作。
• Commit log 持久化：数据首先会写入 Commit log，提供持久化。
• Memtable 缓存：数据进行持久化时，也同时写入 memtable 进行缓存，达到队列最大值时，顺序刷入磁盘。

数据模型Cassandra 的数据模型借鉴了谷歌 BigTable 的设计思想，包括以下四个概念：

• 键空间（KeySpace）相当于关系型数据库模型中的数据库，是最上层的命令空间；
• 列族 ColumnFamily，相当于关系型数据库中的表，但它比表更稀疏；
• 行 Row 表示一个数据对象，存在于 ColumnFamily 当中；
• 列 Column 相当于属性，是存储的基本单元。

Cassandra 各主要概念之间的包含关系如图 1 所示。
图 1.  Cassandra 主要概念关系图

• Key：对应 SQL 数据库中的主键。在 Cassandra 中，每一行数据记录是以 Key/Value 的形式存储的，其中 Key 是唯一标识。
• Column：对应 SQL 数据库中的列。在 Cassandra 中，每个 Key/Value 对中的 Value 又称为          Column，它是一个三元组，即：name、value 和 timestamp，其中 name 需要是唯一的。
• Super Column：Cassandra 允许 Key/Value 中的 Value 是一个 Map（Key/Value List），即某个 Column          有多个子列。
• Standard Column Family：相当于关系型数据库中的 Table。每个 CF 由一系列 Row 组成，每个 Row 包含一个 Key 以及其对应的若干          Column。CF 中只能存储 Name/Value 形式的 Column，不能存储 Super Column，同样，SCF 中只能存储 Super Column。
• Key Space：相当于关系型数据库中的 DataBase。一个 KeySpace 中可包含若干个 CF，如果 SQL 数据中一个数据库可包含多张表。