开发者学堂课程【Cassandra数据库入门与实战：面向应用的反范式化建模】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/784
面向应用的反范式化建模
一、基础：数据分布
1、展性：scale up & scale out
举例，如果一块盘存不下的话，我们可能会换一块更大的盘，但这种往往会触及到系统的上线，因为我们不可能把一块盘做得非常大，所以说现在业界最常用的扩展的方法是，如果一块盘不够的话，不是用更大的盘，而是用更多的盘，比如说用两块盘，三块盘，当一台机器的盘达到上限的时候，一台机器不够，那就用更多的机器。
2、基本问题：数据分布策略
负载均衡：
写：均匀的写到集群的每一台机器上，每一块盘上
读：均匀的从集群的每台机器上，每块盘上读取数据
线性扩展：
机器扩缩容，磁盘上下线，系统最终处于负载均衡状态
系统容量、吞吐与系统资源成正比
两种分布策略
（1）顺序分布
顺序分布就是根据用户定义的主键，从最小的组件开始，依次往后排。
代表产品：hbase,tidb
需要region的原数据管理机制(如hbase的meta表)
优点:
region的灵活分布可以人工干预
region可以分裂合并
缺点:
依赖主键值：user_id分布不均匀时，容易产生热点，需要额外设计(例如较小的userid往往不活跃)
相同前缀的数据也可能会分开
路由表机制复杂
（2）Hash分布
对于hash分布来说，需要一个hash的算法，需要选出一个分区键，通过算法的来得到他机器的名字。
代表产品：cassandra ，dynamodb
与分库分表类似
优点：
简单无额外系统依赖
缺点：
扩缩容十需要处理所有数据（一致性hash方案）
分区无法灵活调整
超大分区问题
比如user id为1的用户是超大用户，海量记录
二、Cassandra的数据模型
1、Partition key Clustering key
分区键，partition key
聚类键，clustering key
非主键列，属性列
对于分区键和聚类键都是可以有很多个的，除了主键之外，还有一个属性列，或者叫非主键列，它存储一些数据，但是不参与数据的排序。
联合主键与前缀匹配
分区键本身来讲是不参与排序的，因为当我们进行hash排序的时候，分区键在整个的表里面是随机分布的。
多个key的排序
查询：前缀匹配原则
匹配中断：跳列，范围查询
扫描范围与filter
逻辑分区:一组具有相同前缀的行
分区键值域可能非常大，比（如long），分区键的每一个值都代表了一个分区
分区的数量可能会非常大
分区的本质，一组具有相同前缀的行，前缀即分区间的值
所有的分区都是逻辑分区
线性扩展
三、范式与反范式设计
1、范式与反范式化
范式化
目的：
（1）降低数据冗余度
（2）增加数据的完整性
（3）通常用于关系型数据库的设计
反范式化
（1）增加冗余度，用空间换时间
（2）数据在多个地方都有，存在一致性问题
例子：
反范式化
优点：
多个表的数据统一到1张表里
Join不是必须的，（大部分nosql也不支持join），查询更高效
查询简洁清晰，易维护
提高问题调查效率
缺点：
冗余，储存空间开销增加
2、原则
（1）根据读写模式来设计表，设计主键
（2）使用分区键来规划数据分布，一次查询需要的数据，尽可能在一个分区里
（3）使用聚类键来保证数据在分区内的唯一性，并控制结果集中的数据的排序
（4）使用非主键列来记录额外信息
（5）反范式化设计将原本需要通过join得到的数据都包含进来
3、物流详情
场景描述：
电商物流订单，每个订单会经历多轮中转，最后到达用户手中，每一次中转会产生一个事件，比如已揽收、装车、到达xx中转站、派送中、已签收。
需要记录全网所有物流订单的状态变化，为用户提供订变更记录的查询能力。
订单数据量极大，可能有上百亿体量，不能影响读写性能。
场景抽象：
写：记录一个订单的一次状态变更。
读：读取一个订单，最近n条记录；读取一个订单的全部记录。
4、物流详情：高表设计
高表设计：
一行描述一个订单的一个事件
一个订单的所有数据由连续性的一组行来描述
优缺点：
单个分区键下的key数量可以很多
过多的数据将导致髋分区的产生，应避免
无论数据量多大，单次next（）的RT可控：流式ResultSet
5、物流详情：宽表设计（不推荐）
宽表设计：
（1）用一行来描述一个订单的所有事件，每一列是一个事件，用事件的发生事件做列名
（2）也可将所有世界encode到一个列里
优缺点：
（1）单行独
（2）无法预知列名，列数量，每一行的列都可能不一样 强依赖schema free能力
（3）只能读所有数据，不容易实现top N读取
（4）超大行风险：单各行的列特别多
6、时序类:监控系统
7、分区键：只使用metric
单分区限制所有机器的指标都聚集在一个分区里，被监控的机器可能无限增长，但单机的承受能力不会线性增长
业务侧：识别变量和不变量
CPU指标本身是不变量，即使未来新增指标通常也是低频事件
被监控的机器是变量会不断的增加，可能数量巨大，比如物流订单的数量
8、分区键：metric+host
这种分区键的优点是很好的控制了单分区的数据量，不会出现宽分区单机的所有类别的CPU指标都在一个分区里，并发读写同一个机器的CPU指标，请求都路由给同一台机器，不利于并发。
9、分区键：metric+host+type
这种分区键的优点是同一个机器的不同CPU类别的指标，在不同的分区里，很好的支持并发访问，host和type的顺序，对采用一致性hash的cassandra来说，没有区别。
10、优化：type合并至metric中
上图中Type是可枚举的，可以直接合并至metric中，减少列数可以提高性能，减少开销（数据量较大时体量小的时候看不出来）。
上图中procid是不可枚举的，不可能合并制metric中。
11、数据点位的存储：宽表or高表
高表设计一行储存一个数据点，如上表所示
容易扩展多值监控:如经纬度
宽表设计:行储存某个机器的某个指标的所有点
单行上线
融合设计:一行记录有限个点，如一分钟一小时内采集到的所有点
粒度选择：由指标的采集频率决定，以控制单行的列数
适当的控制行数，可以配合一些内部优化机制
注意：时序的建模的原理很简单，但生产使用时有很多考量因素，各TSDB都有不同的侧重点，应根据业务实际需要，选择合适的模型，没有银弹。
12、常见误区：分页查询
流式ResultSet：
为了避免单次RPC返回过多数据导致RT过高，CQL driver会自动对请求进行拆分。
第一次next（）调用会从服务端load n行数据，之后的n- 1 次next只从内存消费数据。
下一次next（）会再加载n行数据到客户端，如此往复，直到所有结果集返回。
常见误区：修改主键
场景一，修改主键的schema
不允许，只能重新建表
场景二，修改主键的值，这本身就是错误的说法。
