Cassandra架构

参考：

cassandra简介

casssandra架构1，架构二

HQL要点

1. cassandra是p2p架构，用gossip协议，hbase是主从架构

2. 数据模型和HBase非常相似，因为他们都是基于bigtable来实现的

3. 数据的

- write：数据写到缓存，到一定大小再flush到磁盘，memtable和sstabke磁盘文件一对一）

- compaction：也是周期性地将标记为删除的数据进行删除，合并多个sstable

- update：找到primary key相同的行，找到则更新，找不到就是创建新行

- delete：用tombstone标记

- read：联合memtable和多个sstable的数据拼装出完整的数据

这些操作都和hbase的很类似都很相似

4. cassandra是一个AP系统，提供最终一致性。可以通过调整配置另它更趋向于一个CP系统，一般情况下，一个分布式存储系统只能在C和A之间权衡。而Hbase是一个CP系统，拥有强一致性，因为单份数据只能从一个region server的region里获取

5. 一致性计算

- R 是读取数据时候需要读取的节点数

- W 是更新数据时需要保证写完的节点数，写完W个节点后返回写如成功，例如写如一份就返回成功，其他的部分可以使用异步写

- N 数据的副本数

- R + W > N 是强一致性，例如关系型数据库中，主从数据库同步复制，R = 1，W = 2，N = 2

- R + W <= N 是弱一致性，例如Nosql数据库中，主从数据库异步复制，R = 1，W = 1，N = 2

6. 物化视图（materialized view）

基于另一个表来创建一个新表，原表数据更新后，新表的数据会自动更新，但数据的更新会有延迟，因为是异步更新，HBase没有找到物化视图的资料

7. 二级索引

二级索引将索引列存储到一个新的隐藏的表中，primary key是索引列，value是原表的primary key。HBase有一些二级索引的方案，有基于coprocessor的方案（phoenix）和非coprocessor的方案

适用场景：

- 表中很多行具有相同的值，表中不同的值越多，隐藏表中的索引列的值就越多，查询成本越大

不适用场景：

- high-cardinality 列，这一列有很多不同的值， 此时，查询了很多值，却只会取其中很小一部分作为结果。此时，可以用物化视图。另一个极端，如布尔值，区分度太小，也不适合。

- counter column。（频繁更新？）

- 频繁更新／删除的列（频繁更新两个表？）

- 从多个partition 取数据时，此时，涉及到多个partition，随着集群越来越大，可能越来越慢。

8. 批量操作

批量插入和更新操作是原子操作，当批量操作在一个partition里进行时，性能比较好，当批量操作是跨分区的时候，会有性能问题。coordinator负责管理所有写操作，会成为瓶颈。